Re: [Intel-gfx] [PATCH] drm/i915: Fix build warning on 32-bit

[Chris Wilson]

On Fri, Aug 14, 2015 at 12:35:23PM +0200, Thierry Reding wrote:
 From: Thierry Reding tred...@nvidia.com
 
 The gtt.stolen_size field is of type size_t, and so should be printed
 using %zu to avoid build warnings on either 32-bit and 64-bit builds.

Or better would be to convert stolen.size to u32 so that we know that it
is correctly sized for the hardware irrespective of the compilation
environment.
-Chris

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

Re: [Intel-gfx] [PATCH 1/2] Revert drm/i915: Add eDP intermediate frequencies for CHV

[Jani Nikula]

On Wed, 12 Aug 2015, Daniel Vetter dan...@ffwll.ch wrote:
 On Wed, Aug 12, 2015 at 04:02:17PM +0300, Ville Syrjälä wrote:
 On Wed, Aug 12, 2015 at 05:31:55PM +0530, Sivakumar Thulasimani wrote:
  
  
  On 8/12/2015 5:02 PM, Ville Syrjälä wrote:
   On Fri, Jul 31, 2015 at 11:32:52AM +0530, Sivakumar Thulasimani wrote:
   From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com
  
   This reverts
   commit fe51bfb95c996733150c44d21e1c9f4b6322a326.
   Author: Ville Syrjälä ville.syrj...@linux.intel.com
   Date:   Thu Mar 12 17:10:38 2015 +0200
  
   CHV does not support intermediate frequencies so reverting the
   patch that added it in the first place
   My docs still say it does. Is there some undocumented problem with the
   PLL or is this just a marketing decision?
  I don't think so, i too have just one document that shows the phy values 
  for each of
  the link rates but have not found any where else to say it is supported .
 
 Display cluster HAS says they're supported. And since the spreadsheet
 has them all in green I assume someone actually figured that they ought
 to work.
 
  Also this is not tested by anyone including us from product team so i 
  highly doubt
it will even work.
 
 Well if no one has tested them I guess we shouldn't try to use them. Not
 a big loss in any case I suppose.
 
 So based on that reasoning I can give an ack for this patch:
 Acked-by: Ville Syrjälä ville.syrj...@linux.intel.com
 
  
  regarding HBR2, it was supposed to land on a future stepping that never 
  happened
  so it is not supported at all.
 
 Hmm. Display Cluster HAS listed it as a stretch goal for early steppings. 
 Apart
 from that there isn't much else to go by. Excepth the training pattern 3
 support, but now that I look again the new bit for that has disappeared
 from the DP register in the spec. Or maybe I was looking at the k0 spec
 when I added it. It's still in the k0 spec but as you say that's been
 nuked.
 
 In light of this, I think dropping HBR2 is reasonable. HBR is anyway
 enough for 4k@30 with 4 lanes, so it's not like we really need HBR2.
 
 And could you also cook up a patch to kill the training pattern 3
 support for CHV? Should be mostly a revert of my original patch that
 added it, but you probably need to adjust the use_tps3 condition a bit
 too.

 Can we please grill the people responsible for this docs mess some more?

 Patch itself is for Jani.

There was some suggestions from Ville [1] to patch 1/2 that I haven't
seen a reply to.

BR,
Jani.

[1] http://mid.gmane.org/20150812131205.gw5...@intel.com



 -Daniel
 -- 
 Daniel Vetter
 Software Engineer, Intel Corporation
 http://blog.ffwll.ch

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

Re: [Intel-gfx] [PATCH 1/2] Revert drm/i915: Add eDP intermediate frequencies for CHV

[Sivakumar Thulasimani]

On 8/14/2015 12:29 PM, Jani Nikula wrote:

On Wed, 12 Aug 2015, Daniel Vetter dan...@ffwll.ch wrote:

On Wed, Aug 12, 2015 at 04:02:17PM +0300, Ville Syrjälä wrote:

On Wed, Aug 12, 2015 at 05:31:55PM +0530, Sivakumar Thulasimani wrote:


On 8/12/2015 5:02 PM, Ville Syrjälä wrote:

On Fri, Jul 31, 2015 at 11:32:52AM +0530, Sivakumar Thulasimani wrote:

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This reverts
commit fe51bfb95c996733150c44d21e1c9f4b6322a326.
Author: Ville Syrjälä ville.syrj...@linux.intel.com
Date:   Thu Mar 12 17:10:38 2015 +0200

CHV does not support intermediate frequencies so reverting the
patch that added it in the first place

My docs still say it does. Is there some undocumented problem with the
PLL or is this just a marketing decision?

I don't think so, i too have just one document that shows the phy values
for each of
the link rates but have not found any where else to say it is supported .

Display cluster HAS says they're supported. And since the spreadsheet
has them all in green I assume someone actually figured that they ought
to work.


Also this is not tested by anyone including us from product team so i
highly doubt
   it will even work.

Well if no one has tested them I guess we shouldn't try to use them. Not
a big loss in any case I suppose.

So based on that reasoning I can give an ack for this patch:
Acked-by: Ville Syrjälä ville.syrj...@linux.intel.com


regarding HBR2, it was supposed to land on a future stepping that never
happened
so it is not supported at all.

Hmm. Display Cluster HAS listed it as a stretch goal for early steppings. Apart
from that there isn't much else to go by. Excepth the training pattern 3
support, but now that I look again the new bit for that has disappeared
from the DP register in the spec. Or maybe I was looking at the k0 spec
when I added it. It's still in the k0 spec but as you say that's been
nuked.

In light of this, I think dropping HBR2 is reasonable. HBR is anyway
enough for 4k@30 with 4 lanes, so it's not like we really need HBR2.

And could you also cook up a patch to kill the training pattern 3
support for CHV? Should be mostly a revert of my original patch that
added it, but you probably need to adjust the use_tps3 condition a bit
too.

Can we please grill the people responsible for this docs mess some more?

Patch itself is for Jani.

There was some suggestions from Ville [1] to patch 1/2 that I haven't
seen a reply to.

BR,
Jani.

[1] http://mid.gmane.org/20150812131205.gw5...@intel.com


yes, i can make that change. i was assuming that since Daniel's reply 
had message
patch itself is for Jani that you would pick it up :), will check once 
before waiting

next time.

-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


--
regards,
Sivakumar

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

[Intel-gfx] [PATCH] drm/i915/skl: WaIgnoreDDIAStrap is forever, always init DDI A

[Jani Nikula]

There is currently conflicting documentation on which steppings the
workaround is needed, up to C vs. forever. However there is post-C
stepping hardware that doesn't report port presence on DDI A, leading to
black screen on eDP. Assume the strap isn't connected, and try to enable
DDI A on these machines. (We'll still check the VBT for the info in DDI
init.)

Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Mika Westerberg mika.westerb...@intel.com
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/i915/intel_display.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 21aa745caed1..aa208a2cfafc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13949,8 +13949,7 @@ static void intel_setup_outputs(struct drm_device *dev)
 */
found = I915_READ(DDI_BUF_CTL_A)  DDI_INIT_DISPLAY_DETECTED;
/* WaIgnoreDDIAStrap: skl */
-   if (found ||
-   (IS_SKYLAKE(dev)  INTEL_REVID(dev)  SKL_REVID_D0))
+   if (found || IS_SKYLAKE(dev))
intel_ddi_init(dev, PORT_A);
 
/* DDI B, C and D detection is indicated by the SFUSE_STRAP
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Adding break for one case

[Jani Nikula]

On Thu, 13 Aug 2015, Xiong Zhang xiong.y.zh...@intel.com wrote:
 Signed-off-by: Xiong Zhang xiong.y.zh...@intel.com

Even for a small patch like this, your commit message is inadequate.

First, it's obvious from the code that you're adding a break for one
case. Instead, you should explain what bug you fix. If someone hits this
bug and is looking for a fix, he's not going to find your patch with
this title.

Second, that break was omitted from or removed by some commit, and you
should find out which one it was, and reference it in your commit
message. It's helpful for everyone, and particularly for maintainers and
backporters who need to find that out anyway to decide where this fix
should be applied.

Thanks,
Jani.

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

 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 65cc5b1..801187c 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -1100,6 +1100,7 @@ bool ibx_digital_port_connected(struct drm_i915_private 
 *dev_priv,
   break;
   case PORT_E:
   bit = SDE_PORTE_HOTPLUG_SPT;
 + break;
   default:
   return true;
   }
 -- 
 2.1.4

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

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

Re: [Intel-gfx] [PATCH] drm/i915: fix typo causing bad memory access in ring init

[Chris Wilson]

On Fri, Aug 14, 2015 at 12:13:04PM +1000, Dave Airlie wrote:
 From: Dave Airlie airl...@redhat.com
 
 This is validating from the wrong index.
 
 testing with KASAN found it.
 
 Reported-by: Dave Jones da...@codemonkey.org.uk
 Signed-off-by: Dave Airlie airl...@redhat.com
 ---
  drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
 b/drivers/gpu/drm/i915/i915_cmd_parser.c
 index 61ae8ff..59f85e2 100644
 --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
 +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
 @@ -534,7 +534,7 @@ static bool validate_cmds_sorted(struct intel_engine_cs 
 *ring,
  
   for (j = 0; j  table-count; j++) {
   const struct drm_i915_cmd_descriptor *desc =
 - table-table[i];
 + table-table[j];
   u32 curr = desc-cmd.value  desc-cmd.mask;

Which uncovered another problem that the tables weren't sorted and
triggered a nasty BUG().

Daniel should have already sent the pair of fixes onwards.
-Chris

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

Re: [Intel-gfx] [PATCH v4 04/11] drm/i915: LVDS pixel clock check

[Mika Kahola]

On Fri, 2015-08-14 at 16:09 +0300, Ville Syrjälä wrote:
 On Fri, Aug 14, 2015 at 01:03:24PM +0300, Mika Kahola wrote:
  It is possible the we request to have a mode that has
  higher pixel clock than our HW can support. This patch
  checks if requested pixel clock is lower than the one
  supported by the HW. The requested mode is discarded
  if we cannot support the requested pixel clock.
  
  This patch applies to LVDS.
  
  V2:
  - removed computation for max pixel clock
  
  V3:
  - cleanup by removing unnecessary lines
  
  V4:
  - moved supported dotclock check from mode_valid() to intel_lvds_init()
  
  Signed-off-by: Mika Kahola mika.kah...@intel.com
  ---
   drivers/gpu/drm/i915/intel_lvds.c | 15 +++
   1 file changed, 11 insertions(+), 4 deletions(-)
  
  diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
  b/drivers/gpu/drm/i915/intel_lvds.c
  index 881b5d1..06b9d1b 100644
  --- a/drivers/gpu/drm/i915/intel_lvds.c
  +++ b/drivers/gpu/drm/i915/intel_lvds.c
  @@ -1098,8 +1098,11 @@ void intel_lvds_init(struct drm_device *dev)
  drm_mode_debug_printmodeline(scan);
   
  fixed_mode = drm_mode_duplicate(dev, scan);
  -   if (fixed_mode)
  -   goto out;
  +   if (fixed_mode) {
  +   if (fixed_mode-clock = 
  dev_priv-max_dotclk_freq)
  +   goto out;
  +   }
  +   fixed_mode = NULL;
  }
  }
   
  @@ -,8 +1114,10 @@ void intel_lvds_init(struct drm_device *dev)
  fixed_mode = drm_mode_duplicate(dev, 
  dev_priv-vbt.lfp_lvds_vbt_mode);
  if (fixed_mode) {
  fixed_mode-type |= DRM_MODE_TYPE_PREFERRED;
  -   goto out;
  +   if (fixed_mode-clock = dev_priv-max_dotclk_freq)
  +   goto out;
  }
  +   fixed_mode = NULL;
  }
   
  /*
  @@ -1135,8 +1140,10 @@ void intel_lvds_init(struct drm_device *dev)
  DRM_DEBUG_KMS(using current (BIOS) mode: );
  drm_mode_debug_printmodeline(fixed_mode);
  fixed_mode-type |= DRM_MODE_TYPE_PREFERRED;
  -   goto out;
  +   if (fixed_mode-clock = dev_priv-max_dotclk_freq)
  +   goto out;
  }
  +   fixed_mode = NULL;
 
 I don't think we want to special case just LVDS this way. Whatever we do
 with fixed_mode validation should be done for all connector types that
 have it. For now I think we can more or less ignore the issue.
 
 So in that light, your previous patch was OK except it should have just
 checked fixed_mode-clock instead of mode-clock. Sorry if my ramblings
 confused you too much.
 
No worries. I was a bit unsure if this check should have been done in
init anyway. I'll take a step back and modify the previous patch.

-Mika-
  }
   
  /* If we still don't have a mode after all that, give up. */
  -- 
  1.9.1
  
  ___
  Intel-gfx mailing list
  Intel-gfx@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/intel-gfx
 


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

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/bxt: work around HW coherency issue for cached GEM mappings

[Imre Deak]

On pe, 2015-08-14 at 14:11 +0100, Chris Wilson wrote:
 On Fri, Aug 14, 2015 at 03:38:57PM +0300, Imre Deak wrote:
  Due to a coherency issue on BXT A steppings we can't guarantee a
  coherent view of cached GPU mappings, so fall back to uncached mappings.
  Note that this still won't fix cases where userspace expects a coherent
  view without synchronizing (via a set domain call). It still makes sense
  to limit the kernel's notion of the mapping to be uncached, for example
  for relocations to work properly during execbuffer time. Also in case
  user space does synchronize the buffer, this will still guarantee that
  we'll do the proper clflushing for the buffer.
  
  v2:
  - limit the WA to A steppings, on later stepping this HW issue is fixed
 
 This has to report the failure, ENODEV otherwise userspace will be
 terribly confused (it will try to CPU coherent access assuming it will
 be fast, when it is better to use alternative paths).

Ok, I was not sure how existing user space would handle the failure, but
if it has the fall-back logic then ENODEV is the better solution. Will
change this.

 -Chris
 


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

Re: [Intel-gfx] [PATCH v2 0/2] drm/i915/bxt: work around HW coherency issue

[Imre Deak]

On pe, 2015-08-14 at 13:49 +0100, Chris Wilson wrote:
 On Fri, Aug 14, 2015 at 03:38:55PM +0300, Imre Deak wrote:
  This is a v2 of [1]. Since v1 the HW team confirmed that there is an
  HW issue in A steppings with the GPU/CPU snoop logic, which explains why
  we need this workaround.
 
 I've been testing this extensively, and I do believe we can use clflush
 for all gen - it is a measurable improvement over using the
 heavyweight/locked read of ACTHD, and none of the coherency tests have
 thrown any warnings (over a period of a couple of months now).

Ok. Do you mean only places where there is already the ACTHD w/a, or to
extend it also to other platforms?

Imo doing this as a follow-up to this patchset would make sense, to keep
platform specific changes separate.

--Imre

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

Re: [Intel-gfx] [PATCH] drm/dp/mst: Remove port after removing connector.

[shuang . he]

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
Task id: 7141
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
ILK  302/302  302/302
SNB  315/315  315/315
IVB  336/336  336/336
BYT  283/283  283/283
HSW  378/378  378/378
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/bxt: work around HW coherency issue when accessing GPU seqno

[Imre Deak]

On pe, 2015-08-14 at 14:12 +0100, Chris Wilson wrote:
 On Fri, Aug 14, 2015 at 03:38:56PM +0300, Imre Deak wrote:
  By running igt/store_dword_loop_render on BXT we can hit a coherency
  problem where the seqno written at GPU command completion time is not
  seen by the CPU. This results in __i915_wait_request seeing the stale
  seqno and not completing the request (not considering the lost
  interrupt/GPU reset mechanism). I also verified that this isn't a case
  of a lost interrupt, or that the command didn't complete somehow: when
  the coherency issue occured I read the seqno via an uncached GTT mapping
  too. While the cached version of the seqno still showed the stale value
  the one read via the uncached mapping was the correct one.
  
  Work around this issue by clflushing the corresponding CPU cacheline
  following any store of the seqno and preceding any reading of it. When
  reading it do this only when the caller expects a coherent view.
  
  v2:
  - fix using the proper logical  instead of a bitwise  (Jani, Mika)
  - limit the workaround to A stepping, on later steppings this HW issue
is fixed
 
 We have vfuncs in order to avoid the pointer dance (and boy is it a
 pretty and quite convoluted dance).

Ok, I'll add new get_seqno/set_seqno vfuncs.

 -Chris
 


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

Re: [Intel-gfx] [PATCH v2 0/2] drm/i915/bxt: work around HW coherency issue

[Chris Wilson]

On Fri, Aug 14, 2015 at 04:26:29PM +0300, Imre Deak wrote:
 On pe, 2015-08-14 at 13:49 +0100, Chris Wilson wrote:
  On Fri, Aug 14, 2015 at 03:38:55PM +0300, Imre Deak wrote:
   This is a v2 of [1]. Since v1 the HW team confirmed that there is an
   HW issue in A steppings with the GPU/CPU snoop logic, which explains why
   we need this workaround.
  
  I've been testing this extensively, and I do believe we can use clflush
  for all gen - it is a measurable improvement over using the
  heavyweight/locked read of ACTHD, and none of the coherency tests have
  thrown any warnings (over a period of a couple of months now).
 
 Ok. Do you mean only places where there is already the ACTHD w/a, or to
 extend it also to other platforms?

I mean replace the current ACTHD w/a.
 
 Imo doing this as a follow-up to this patchset would make sense, to keep
 platform specific changes separate.

Agreed. Get the w/a in place, then do the conversion so that we have a
safe fallback.
-Chris

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

Re: [Intel-gfx] [PATCH] drm/i915: fix typo causing bad memory access in ring init

[Daniel Vetter]

On Fri, Aug 14, 2015 at 08:40:47AM +0100, Chris Wilson wrote:
 On Fri, Aug 14, 2015 at 12:13:04PM +1000, Dave Airlie wrote:
  From: Dave Airlie airl...@redhat.com
  
  This is validating from the wrong index.
  
  testing with KASAN found it.
  
  Reported-by: Dave Jones da...@codemonkey.org.uk
  Signed-off-by: Dave Airlie airl...@redhat.com
  ---
   drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
  
  diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
  b/drivers/gpu/drm/i915/i915_cmd_parser.c
  index 61ae8ff..59f85e2 100644
  --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
  +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
  @@ -534,7 +534,7 @@ static bool validate_cmds_sorted(struct intel_engine_cs 
  *ring,
   
  for (j = 0; j  table-count; j++) {
  const struct drm_i915_cmd_descriptor *desc =
  -   table-table[i];
  +   table-table[j];
  u32 curr = desc-cmd.value  desc-cmd.mask;
 
 Which uncovered another problem that the tables weren't sorted and
 triggered a nasty BUG().
 
 Daniel should have already sent the pair of fixes onwards.

Yeah if you want this fixed asap you need 9f58582c7ad64f025e7f and
8453580cb8834dedffda from next for other it'll BUG.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 03/11] drm/i915: HDMI pixel clock check

[Daniel Vetter]

On Wed, Aug 12, 2015 at 09:34:54PM +0300, Ville Syrjälä wrote:
 On Fri, Jul 31, 2015 at 03:13:52PM +0300, Mika Kahola wrote:
  It is possible the we request to have a mode that has
  higher pixel clock than our HW can support. This patch
  checks if requested pixel clock is lower than the one
  supported by the HW. The requested mode is discarded
  if we cannot support the requested pixel clock.
  
  This patch applies to HDMI.
  
  V2:
  - removed computation for max dot clock
  
  V3:
  - cleanup by removing unnecessary lines
  
  Signed-off-by: Mika Kahola mika.kah...@intel.com
  ---
   drivers/gpu/drm/i915/intel_hdmi.c | 4 
   1 file changed, 4 insertions(+)
  
  diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
  b/drivers/gpu/drm/i915/intel_hdmi.c
  index 70bad5b..3149e5f 100644
  --- a/drivers/gpu/drm/i915/intel_hdmi.c
  +++ b/drivers/gpu/drm/i915/intel_hdmi.c
  @@ -1193,10 +1193,14 @@ intel_hdmi_mode_valid(struct drm_connector 
  *connector,
  struct drm_device *dev = intel_hdmi_to_dev(hdmi);
  enum drm_mode_status status;
  int clock;
  +   int max_pixclk = to_i915(connector-dev)-max_dotclk;
   
  if (mode-flags  DRM_MODE_FLAG_DBLSCAN)
  return MODE_NO_DBLESCAN;
   
  +   if (mode-clock  max_pixclk)
  +   return MODE_CLOCK_HIGH;
  +
  clock = mode-clock;
 
 I believe we should do something like this here:
 
   clock = mode-clock;
 
   if ((mode-flags  DRM_MODE_FLAG_3D_MASK) == 
 DRM_MODE_FLAG_3D_FRAME_PACKING)
   clock *= 2;

That's already done in drm_mode_set_crtcinfo, i915 uses the STEREO_DOUBLE
mode of that function.
-Daniel

 
   if (clock  max_pixclk)
   return MODE_CLOCK_HIGH;
 
  if (mode-flags  DRM_MODE_FLAG_DBLCLK)
  clock *= 2;
 
 The stero handling should probably be in a separate patch, but in
 preparation for it you could already put the dotclk check between the
 clock= assigment and the DBCLK doubling (since DBLCLK only affects the
 port_clock and not pixel clock).
 
  -- 
  1.9.1
  
  ___
  Intel-gfx mailing list
  Intel-gfx@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/intel-gfx
 
 -- 
 Ville Syrjälä
 Intel OTC
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] ACPI / video: Fix circular lock dependency issue in the video-detect code

[Rafael J. Wysocki]

On Thursday, August 13, 2015 10:39:08 PM Sedat Dilek wrote:
 
 --f46d04447e7fc2306e051d3753a5
 Content-Type: text/plain; charset=UTF-8
 
 On Thu, Aug 13, 2015 at 6:53 PM, Hans de Goede hdego...@redhat.com wrote:
  Before this commit, the following would happen:
 
  a) acpi_video_get_backlight_type() gets called
  b) acpi_video_get_backlight_type() calls acpi_video_init_backlight_type()
  c) acpi_video_init_backlight_type() locks its function static init_mutex
  d) acpi_video_init_backlight_type() calls backlight_register_notifier()
  e) backlight_register_notifier() takes its notifier-chain lock
 
  And when the backlight notifier chain gets called we've:
 
  1) blocking_notifier_call_chain() gets called
  2) blocking_notifier_call_chain() takes the notifier-chain lock
  3) blocking_notifier_call_chain() calls acpi_video_backlight_notify()
  4) acpi_video_backlight_notify() calls acpi_video_get_backlight_type()
  5) acpi_video_get_backlight_type() calls acpi_video_init_backlight_type()
  6) acpi_video_init_backlight_type() locks its function static init_mutex
 
  So in the first call sequence we have:
 
  a) init_mutex gets locked
  b) notifier-chain gets locked
 
  and in the second call sequence we have:
 
  1) notifier-chain gets locked
  2) init_mutex gets locked
 
  And we've a circular locking dependency. This specific locking dependency
  is fixable without using the big hammer otherwise known as a workqueue,
  but further analysis shows a similar problem with the backlight notifier
  chain lock vs register_count_mutex from drivers/acpi/acpi_video.c,
  and fixing that becomes problematic.
 
  So this commit simply fixes this with the big hammer, performance
  wise this is a non issue as we expect the work to get scheduled
  exactly zero or one times during normal system use.
 
 
 This patch on top of Linux v4.2-rc6 fixes the issue for me.
 
 Feel free to add my...
 
Reported-by: Sedat Dilek sedat.di...@gmail.com
Tested-by: Sedat Dilek sedat.di...@gmail.com

Applied, thanks!

Rafael

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

Re: [Intel-gfx] [PATCH 08/11] drm/i915: Add port A HPD support for IVB/HSW

[Daniel Vetter]

On Wed, Aug 12, 2015 at 06:44:17PM +0300, ville.syrj...@linux.intel.com wrote:
 From: Ville Syrjälä ville.syrj...@linux.intel.com
 
 As with ILK/SNB wire up the port A HPD on IVB/HSW.
 
 This might be more important on HSW with PSR. BSpec tells us that if the
 automagic link training performed by the hardware fails for some reason,
 we're going to get a short HPD and are supposed to re-train the link
 manyally.

Rodrigo, could this be the cause behind our frozen screens? If we get out
of PSR and the hw link train fails then the screen will indeed freeze ...
-Daniel

 
 Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
 ---
  drivers/gpu/drm/i915/i915_irq.c | 34 +++---
  1 file changed, 27 insertions(+), 7 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
 index 152be8b..d994b80 100644
 --- a/drivers/gpu/drm/i915/i915_irq.c
 +++ b/drivers/gpu/drm/i915/i915_irq.c
 @@ -49,6 +49,10 @@ static const u32 hpd_ilk[HPD_NUM_PINS] = {
   [HPD_PORT_A] = DE_DP_A_HOTPLUG,
  };
  
 +static const u32 hpd_ivb[HPD_NUM_PINS] = {
 + [HPD_PORT_A] = DE_DP_A_HOTPLUG_IVB,
 +};
 +
  static const u32 hpd_ibx[HPD_NUM_PINS] = {
   [HPD_CRT] = SDE_CRT_HOTPLUG,
   [HPD_SDVO_B] = SDE_SDVOB_HOTPLUG,
 @@ -1940,6 +1944,19 @@ static void ivb_display_irq_handler(struct drm_device 
 *dev, u32 de_iir)
  {
   struct drm_i915_private *dev_priv = dev-dev_private;
   enum pipe pipe;
 + u32 hotplug_trigger = de_iir  DE_DP_A_HOTPLUG_IVB;
 +
 + if (hotplug_trigger) {
 + u32 dig_hotplug_reg, pin_mask, long_mask;
 +
 + dig_hotplug_reg = I915_READ(DIGITAL_PORT_HOTPLUG_CNTRL);
 + I915_WRITE(DIGITAL_PORT_HOTPLUG_CNTRL, dig_hotplug_reg);
 +
 + intel_get_hpd_pins(pin_mask, long_mask, hotplug_trigger,
 +dig_hotplug_reg, hpd_ivb,
 +ilk_port_hotplug_long_detect);
 + intel_hpd_irq_handler(dev, pin_mask, long_mask);
 + }
  
   if (de_iir  DE_ERR_INT_IVB)
   ivb_err_int_handler(dev);
 @@ -3137,8 +3154,13 @@ static void ilk_hpd_irq_setup(struct drm_device *dev)
   struct drm_i915_private *dev_priv = dev-dev_private;
   u32 hotplug_irqs, hotplug, enabled_irqs;
  
 - hotplug_irqs = DE_DP_A_HOTPLUG;
 - enabled_irqs = intel_hpd_enabled_irqs(dev, hpd_ilk);
 + if (INTEL_INFO(dev)-gen = 7) {
 + hotplug_irqs = DE_DP_A_HOTPLUG_IVB;
 + enabled_irqs = intel_hpd_enabled_irqs(dev, hpd_ivb);
 + } else {
 + hotplug_irqs = DE_DP_A_HOTPLUG;
 + enabled_irqs = intel_hpd_enabled_irqs(dev, hpd_ilk);
 + }
  
   ilk_update_display_irq(dev_priv, hotplug_irqs, enabled_irqs);
  
 @@ -3245,7 +3267,8 @@ static int ironlake_irq_postinstall(struct drm_device 
 *dev)
   DE_PLANEB_FLIP_DONE_IVB |
   DE_PLANEA_FLIP_DONE_IVB | DE_AUX_CHANNEL_A_IVB);
   extra_mask = (DE_PIPEC_VBLANK_IVB | DE_PIPEB_VBLANK_IVB |
 -   DE_PIPEA_VBLANK_IVB | DE_ERR_INT_IVB);
 +   DE_PIPEA_VBLANK_IVB | DE_ERR_INT_IVB |
 +   DE_DP_A_HOTPLUG_IVB);
   } else {
   display_mask = (DE_MASTER_IRQ_CONTROL | DE_GSE | DE_PCH_EVENT |
   DE_PLANEA_FLIP_DONE | DE_PLANEB_FLIP_DONE |
 @@ -4270,10 +4293,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
   dev-driver-irq_uninstall = ironlake_irq_uninstall;
   dev-driver-enable_vblank = ironlake_enable_vblank;
   dev-driver-disable_vblank = ironlake_disable_vblank;
 - if (INTEL_INFO(dev)-gen = 7)
 - dev_priv-display.hpd_irq_setup = ibx_hpd_irq_setup;
 - else
 - dev_priv-display.hpd_irq_setup = ilk_hpd_irq_setup;
 + dev_priv-display.hpd_irq_setup = ilk_hpd_irq_setup;
   } else {
   if (INTEL_INFO(dev_priv)-gen == 2) {
   dev-driver-irq_preinstall = i8xx_irq_preinstall;
 -- 
 2.4.6
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH igt] lib/igt_draw: add support for RGB565 and XRGB2101010

[Daniel Vetter]

On Wed, Aug 12, 2015 at 06:33:55PM -0300, Paulo Zanoni wrote:
 We need to test those pixel formats on the FBC code, so let's make
 sure the drawing library works on them first.
 
 Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com

gtkdoc update seems to be missing for the igt_draw_rect change. Even more
so that there's a line in the overview section stating that this library
assumes everything is XRGB ;-)
-Daniel

 ---
  lib/igt_draw.c   | 162 
 +++
  lib/igt_draw.h   |   2 +-
  tests/kms_draw_crc.c | 113 +--
  tests/kms_frontbuffer_tracking.c |   2 +-
  4 files changed, 206 insertions(+), 73 deletions(-)
 
 diff --git a/lib/igt_draw.c b/lib/igt_draw.c
 index 2210f77..afb937f 100644
 --- a/lib/igt_draw.c
 +++ b/lib/igt_draw.c
 @@ -57,6 +57,7 @@ struct buf_data {
   uint32_t handle;
   uint32_t size;
   uint32_t stride;
 + int bpp;
  };
  
  struct rect {
 @@ -133,27 +134,27 @@ static int swizzle_addr(int addr, int swizzle)
  
  /* It's all in pixel coordinates, so make sure you multiply/divide by the 
 bpp
   * if you need to. */
 -static int linear_x_y_to_tiled_pos(int x, int y, uint32_t stride, int 
 swizzle)
 +static int linear_x_y_to_tiled_pos(int x, int y, uint32_t stride, int 
 swizzle,
 +int bpp)
  {
   int x_tile_size, y_tile_size;
   int x_tile_n, y_tile_n, x_tile_off, y_tile_off;
   int line_size, tile_size;
   int tile_n, tile_off;
   int tiled_pos, tiles_per_line;
 - int bpp;
 + int pixel_size = bpp / 8;
  
   line_size = stride;
   x_tile_size = 512;
   y_tile_size = 8;
   tile_size = x_tile_size * y_tile_size;
   tiles_per_line = line_size / x_tile_size;
 - bpp = sizeof(uint32_t);
  
   y_tile_n = y / y_tile_size;
   y_tile_off = y % y_tile_size;
  
 - x_tile_n = (x * bpp) / x_tile_size;
 - x_tile_off = (x * bpp) % x_tile_size;
 + x_tile_n = (x * pixel_size) / x_tile_size;
 + x_tile_off = (x * pixel_size) % x_tile_size;
  
   tile_n = y_tile_n * tiles_per_line + x_tile_n;
   tile_off = y_tile_off * x_tile_size + x_tile_off;
 @@ -161,19 +162,19 @@ static int linear_x_y_to_tiled_pos(int x, int y, 
 uint32_t stride, int swizzle)
  
   tiled_pos = swizzle_addr(tiled_pos, swizzle);
  
 - return tiled_pos / bpp;
 + return tiled_pos / pixel_size;
  }
  
  /* It's all in pixel coordinates, so make sure you multiply/divide by the 
 bpp
   * if you need to. */
  static void tiled_pos_to_x_y_linear(int tiled_pos, uint32_t stride,
 - int swizzle, int *x, int *y)
 + int swizzle, int bpp, int *x, int *y)
  {
   int tile_n, tile_off, tiles_per_line, line_size;
   int x_tile_off, y_tile_off;
   int x_tile_n, y_tile_n;
   int x_tile_size, y_tile_size, tile_size;
 - int bpp;
 + int pixel_size = bpp / 8;
  
   tiled_pos = swizzle_addr(tiled_pos, swizzle);
  
 @@ -182,7 +183,6 @@ static void tiled_pos_to_x_y_linear(int tiled_pos, 
 uint32_t stride,
   y_tile_size = 8;
   tile_size = x_tile_size * y_tile_size;
   tiles_per_line = line_size / x_tile_size;
 - bpp = sizeof(uint32_t);
  
   tile_n = tiled_pos / tile_size;
   tile_off = tiled_pos % tile_size;
 @@ -193,32 +193,45 @@ static void tiled_pos_to_x_y_linear(int tiled_pos, 
 uint32_t stride,
   x_tile_n = tile_n % tiles_per_line;
   y_tile_n = tile_n / tiles_per_line;
  
 - *x = (x_tile_n * x_tile_size + x_tile_off) / bpp;
 + *x = (x_tile_n * x_tile_size + x_tile_off) / pixel_size;
   *y = y_tile_n * y_tile_size + y_tile_off;
  }
  
 -static void draw_rect_ptr_linear(uint32_t *ptr, uint32_t stride,
 -   struct rect *rect, uint32_t color)
 +static void set_pixel(void *_ptr, int index, uint32_t color, int bpp)
 +{
 + if (bpp == 16) {
 + uint16_t *ptr = _ptr;
 + ptr[index] = color;
 + } else if (bpp == 32) {
 + uint32_t *ptr = _ptr;
 + ptr[index] = color;
 + } else {
 + igt_assert_f(false, bpp: %d\n, bpp);
 + }
 +}
 +
 +static void draw_rect_ptr_linear(void *ptr, uint32_t stride,
 +  struct rect *rect, uint32_t color, int bpp)
  {
   int x, y, line_begin;
  
   for (y = rect-y; y  rect-y + rect-h; y++) {
 - line_begin = y * stride / sizeof(uint32_t);
 + line_begin = y * stride / (bpp / 8);
   for (x = rect-x; x  rect-x + rect-w; x++)
 - ptr[line_begin + x] = color;
 + set_pixel(ptr, line_begin + x, color, bpp);
   }
 -
  }
  
 -static void draw_rect_ptr_tiled(uint32_t *ptr, uint32_t stride, int swizzle,
 -  struct rect *rect, uint32_t color)
 +static void draw_rect_ptr_tiled(void *ptr, uint32_t stride, int swizzle,
 +  

Re: [Intel-gfx] [PATCH v4] mmap on the dma-buf directly

[Thomas Hellstrom]

On 08/13/2015 01:29 AM, Tiago Vignatti wrote:
 Hi,

 The idea is to create a GEM bo in one process and pass the prime handle of the
 it to another process, which in turn uses the handle only to map and write.
 This could be useful for Chrome OS architecture, where the Web content
 (unpriviledged process) maps and CPU-draws a buffer, which was previously
 allocated in the GPU process (priviledged process).

 In v2, I've added a patch that Daniel kindly drafted to allow the
 unpriviledged process flush through a prime fd. In v3, I've fixed a few
 concerns and then added end_cpu_access to i915. In v4, I fixed Sumit Semwal's
 concerns about dma-duf documentation and the FIXME missing in that same patch,
 and also removed WARN in i915 dma-buf mmap (pointed by Chris). PTAL.

 Best Regards,

 Tiago
Tiago,

I take it, this is intended to be a generic interface used mostly for 2D
rendering.

In that case, using SYNC is crucial for performance of incoherent
architectures and I'd rather see it mandatory than an option. It could
perhaps be made mandatory preferrably using an error or a one-time
kernel warning. If nobody uses the SYNC interface, it is of little use.

Also I think the syncing needs to be extended to two dimensions. A long
time ago when this was brought up people argued why we should limit it
to two dimensions, but I believe two dimensions addresses most
performance-problematic use-cases. A default implementation of
twodimensional sync can easily be made using the one-dimensional API.

Thanks,
Thomas








 Daniel Thompson (1):
   drm: prime: Honour O_RDWR during prime-handle-to-fd

 Daniel Vetter (1):
   dma-buf: Add ioctls to allow userspace to flush

 Tiago Vignatti (2):
   drm/i915: Implement end_cpu_access
   drm/i915: Use CPU mapping for userspace dma-buf mmap()

  Documentation/dma-buf-sharing.txt  | 12 
  drivers/dma-buf/dma-buf.c  | 50 
 ++
  drivers/gpu/drm/drm_prime.c| 10 ++-
  drivers/gpu/drm/i915/i915_gem_dmabuf.c | 28 ++-
  include/uapi/drm/drm.h |  1 +
  include/uapi/linux/dma-buf.h   | 43 +
  6 files changed, 136 insertions(+), 8 deletions(-)
  create mode 100644 include/uapi/linux/dma-buf.h



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

Re: [Intel-gfx] [PATCH] drm/i915/skl: WaIgnoreDDIAStrap is forever, always init DDI A

[Daniel Vetter]

On Fri, Aug 14, 2015 at 10:53:17AM +0300, Jani Nikula wrote:
 There is currently conflicting documentation on which steppings the
 workaround is needed, up to C vs. forever. However there is post-C
 stepping hardware that doesn't report port presence on DDI A, leading to
 black screen on eDP. Assume the strap isn't connected, and try to enable
 DDI A on these machines. (We'll still check the VBT for the info in DDI
 init.)
 
 Cc: Ville Syrjälä ville.syrj...@linux.intel.com
 Cc: Mika Westerberg mika.westerb...@intel.com
 Signed-off-by: Jani Nikula jani.nik...@intel.com

Queued for -next, thanks for the patch.
-Daniel

 ---
  drivers/gpu/drm/i915/intel_display.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 21aa745caed1..aa208a2cfafc 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -13949,8 +13949,7 @@ static void intel_setup_outputs(struct drm_device 
 *dev)
*/
   found = I915_READ(DDI_BUF_CTL_A)  DDI_INIT_DISPLAY_DETECTED;
   /* WaIgnoreDDIAStrap: skl */
 - if (found ||
 - (IS_SKYLAKE(dev)  INTEL_REVID(dev)  SKL_REVID_D0))
 + if (found || IS_SKYLAKE(dev))
   intel_ddi_init(dev, PORT_A);
  
   /* DDI B, C and D detection is indicated by the SFUSE_STRAP
 -- 
 2.1.4
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] sna: Fix the reduction of xy reflection onto rotations.

[Chris Wilson]

On Thu, Aug 13, 2015 at 04:51:37PM -0700, Bob Paauwe wrote:
 When reducing a xy reflection to a 180 degree rotation, make sure
 only one rotation bit is set.  Also by rotating the bit left, we
 can support cases where xy reflection happens with 90/270 degree
 rotation.
 
 Signed-off-by: Bob Paauwe bob.j.paa...@intel.com

Nice. Took me a few moments to verify the shifting works as expected, so
I left a couple of comments there for my future self.

Thanks, pushed
-Chris

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

Re: [Intel-gfx] [PATCH 0/7] drm/i915: Move DP link parameters out from intel_dp

[Daniel Vetter]

On Wed, Aug 12, 2015 at 07:04:22PM +0300, Ville Syrjälä wrote:
 On Mon, Jul 06, 2015 at 03:09:59PM +0300, ville.syrj...@linux.intel.com wrote:
  From: Ville Syrjälä ville.syrj...@linux.intel.com
  
  While working on CHV DPIO powergating I relized DP .compute_config() was
  clobbering lane_count etc. stored in intel_dp. This could cause problems
  if we do the .compute_config() but later fail the modeset for some reason.
  Any subsequent link re-training might then fail if intel_dp-lane_count
  etc. got changed.
  
  The reason I ran into this during the DPIO powergating work was that I may
  need to know which lanes he active when shutting down the link. However
  .compute_config() already clobbered that information by the time I need it.
  By moving it to the pipe config we avoid that problem as well.
  
  I also cleaned up the limited color range handling a bit while I was
  in the neighborhood.
  
 
drm/i915: Clean up DP/HDMI limited color range handling
drm/i915: Move intel_dp-lane_count into pipe_config
 
 These two are still lacking a r-b. Would be nice to get these in so that
 they don't end up blocking the CHV DPIO powergating stuff once that gets
 reviewed.
 
 Sivakumar, any chance you'd like to review those as well? Or do we have
 anyone else interested?

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

Re: [Intel-gfx] [PATCH] drm/i915: fix checksum write for automated test reply

[Jindal, Sonika]

Looks good to me.
Reviewed-by: Sonika Jindal sonika.jin...@intel.com

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Sivakumar Thulasimani
Sent: Friday, August 7, 2015 3:15 PM
To: dan...@ffwll.ch; intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH] drm/i915: fix checksum write for automated test 
reply

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

DP spec requires the checksum of the last block read to be written when 
replying to TEST_EDID_READ. This patch fixes the current code to do the same.

v2: removed loop for jumping blocks and performed direct addition as 
recommended by Daniel

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c 
index f1b9f93..fa6e202 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4090,9 +4090,16 @@ static uint8_t intel_dp_autotest_edid(struct intel_dp 
*intel_dp)
  intel_dp-aux.i2c_defer_count);
intel_dp-compliance_test_data = INTEL_DP_RESOLUTION_FAILSAFE;
} else {
+   struct edid *block = intel_connector-detect_edid;
+
+   /* We have to write the checksum
+* of the last block read
+*/
+   block += intel_connector-detect_edid-extensions;
+
if (!drm_dp_dpcd_write(intel_dp-aux,
DP_TEST_EDID_CHECKSUM,
-   intel_connector-detect_edid-checksum,
+   block-checksum,
1))
DRM_DEBUG_KMS(Failed to write EDID checksum\n);
 
--
1.7.9.5

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

Re: [Intel-gfx] [PATCH v3 08/11] drm/i915: TV pixel clock check

[Daniel Vetter]

On Wed, Aug 12, 2015 at 09:24:01PM +0300, Ville Syrjälä wrote:
 On Fri, Jul 31, 2015 at 03:13:57PM +0300, Mika Kahola wrote:
  It is possible the we request to have a mode that has
  higher pixel clock than our HW can support. This patch
  checks if requested pixel clock is lower than the one
  supported by the HW. The requested mode is discarded
  if we cannot support the requested pixel clock.
  
  This patch applies to TV.
  
  V2:
  - removed computation for max pixel clock
  
  V3:
  - cleanup by removing unnecessary lines
  
  Signed-off-by: Mika Kahola mika.kah...@intel.com
  ---
   drivers/gpu/drm/i915/intel_tv.c | 4 
   1 file changed, 4 insertions(+)
  
  diff --git a/drivers/gpu/drm/i915/intel_tv.c 
  b/drivers/gpu/drm/i915/intel_tv.c
  index 8b9d325..beeed25 100644
  --- a/drivers/gpu/drm/i915/intel_tv.c
  +++ b/drivers/gpu/drm/i915/intel_tv.c
  @@ -897,6 +897,10 @@ intel_tv_mode_valid(struct drm_connector *connector,
   {
  struct intel_tv *intel_tv = intel_attached_tv(connector);
  const struct tv_mode *tv_mode = intel_tv_mode_find(intel_tv);
  +   int max_pixclk = to_i915(connector-dev)-max_dotclk;
  +
  +   if (mode-clock  max_pixclk)
  +   return MODE_CLOCK_HIGH;
 
 The mode handling in intel_tv.c seems to be a mess. But I suppose this
 should be OK.

We set a fake mode (which is the one userspace asks for) and the hw
internally munges it to the actual tv mode with a scaler. Except that the
frame-start/dotclock are fed from the actual TV mode (which is why
kms_flip has a check for TV modes since the timings are all wrong).

Yup, giant hairball indeed ;-)
-Daniel

 
 Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
 
   
  /* Ensure TV refresh is close to desired refresh */
  if (tv_mode  abs(tv_mode-refresh - drm_mode_vrefresh(mode) * 1000)
  -- 
  1.9.1
  
  ___
  Intel-gfx mailing list
  Intel-gfx@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/intel-gfx
 
 -- 
 Ville Syrjälä
 Intel OTC
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH v3 09/11] drm/i915: DisplayPort-MST pixel clock check

[Daniel Vetter]

On Wed, Aug 12, 2015 at 09:49:12PM +0300, Ville Syrjälä wrote:
 On Fri, Jul 31, 2015 at 03:13:58PM +0300, Mika Kahola wrote:
  It is possible the we request to have a mode that has
  higher pixel clock than our HW can support. This patch
  checks if requested pixel clock is lower than the one
  supported by the HW. The requested mode is discarded
  if we cannot support the requested pixel clock.
  
  This patch applies to DisplayPort MST.
  
  V2:
  - removed computation for max pixel clock
  
  V3:
  - cleanup by removing unnecessary lines
  
  Signed-off-by: Mika Kahola mika.kah...@intel.com
  ---
   drivers/gpu/drm/i915/intel_dp_mst.c | 5 +
   1 file changed, 5 insertions(+)
  
  diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
  b/drivers/gpu/drm/i915/intel_dp_mst.c
  index 585f0a4..fcf03d0 100644
  --- a/drivers/gpu/drm/i915/intel_dp_mst.c
  +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
  @@ -347,6 +347,8 @@ static enum drm_mode_status
   intel_dp_mst_mode_valid(struct drm_connector *connector,
  struct drm_display_mode *mode)
   {
  +   int max_pixclk = to_i915(connector-dev)-max_dotclk;
 
 The pixclk vs. dotclk in every patch is tickling my ocd nerves. I'd say
 pick one and stick to it everywhere. I guess I'm probably to blame here
 since I've been using dotclock in the .get_config() paths, and pixclk
 in the cdclk calculations. With grep I can't say which one is winning,
 so I guess you could pick whichever seems more awesome.

+1 from me for a follow-up series to standardize on one and then maybe
even add a small DOC: kerneldoc comment explaining what all the different
clocks are that we have. We have much improved kerneldoc support now.
-Daniel

 
 Apart from that this patch looks good so:
 Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
 
  +
  /* TODO - validate mode against available PBN for link */
  if (mode-clock  1)
  return MODE_CLOCK_LOW;
  @@ -354,6 +356,9 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
  if (mode-flags  DRM_MODE_FLAG_DBLCLK)
  return MODE_H_ILLEGAL;
   
  +   if (mode-clock  max_pixclk)
  +   return MODE_CLOCK_HIGH;
  +
  return MODE_OK;
   }
   
  -- 
  1.9.1
  
  ___
  Intel-gfx mailing list
  Intel-gfx@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/intel-gfx
 
 -- 
 Ville Syrjälä
 Intel OTC
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 1/2 v2 addendum v2] drm/i915: Allow parsing of variable size child device entries from VBT

[Jani Nikula]

On Thu, 13 Aug 2015, David Weinehall david.weineh...@linux.intel.com wrote:
 On Wed, Aug 12, 2015 at 05:19:35PM +0300, Jani Nikula wrote:
 On Wed, 12 Aug 2015, David Weinehall david.weineh...@linux.intel.com wrote:
  Some more fixup is needed; the bits from Antti's patch
  that actually expanded the struct to fully fit the newer
  versions of the child_device_config was part of the second
  patch; since that patch hasn't been merged yet we need this bit:
 
  This applies on top of the patch you already merged
  (the Iboost patch will need corresponding adjustment to
   remove the changes I split out):
 
  Expand common_child_dev_config to be able to fit all information
  defined by the latest VBT specification.
 
  Signed-off-by: David Weinehall david.weineh...@linux.intel.com
  CC: Antti Koskipaa antti.koski...@linux.intel.com
  ---
   intel_bios.c |7 ++-
   intel_bios.h |4 
   2 files changed, 10 insertions(+), 1 deletion(-)
 
  diff --git a/drivers/gpu/drm/i915/intel_bios.c 
  b/drivers/gpu/drm/i915/intel_bios.c
  index 990acc20771a..40e2cc4e7419 100644
  --- a/drivers/gpu/drm/i915/intel_bios.c
  +++ b/drivers/gpu/drm/i915/intel_bios.c
  @@ -1038,6 +1038,10 @@ parse_device_mapping(struct drm_i915_private 
  *dev_priv,
 DRM_DEBUG_KMS(No general definition block is found, no devices 
  defined.\n);
 return;
 }
  +  /* Remember to keep this in sync with child_device_config;
  +   * whenever a new feature is added to BDB that causes that
  +   * struct to grow this needs to be updated too
  +   */
 if (bdb-version  195) {
 expected_size = 33;
 } else if (bdb-version == 195) {
  @@ -1051,7 +1055,8 @@ parse_device_mapping(struct drm_i915_private 
  *dev_priv,
 }
   
 if (expected_size  sizeof(*p_child)) {
  -  DRM_ERROR(child_device_config cannot fit in p_child\n);
  +  DRM_ERROR(child_device_config (size %u) cannot fit in p_child 
  (size %u); bdb-version: %u\n,
  +expected_size, sizeof(*p_child), bdb-version);
 
 drivers/gpu/drm/i915/intel_bios.c: In function ‘parse_device_mapping’:
 drivers/gpu/drm/i915/intel_bios.c:1058:3: warning: format ‘%u’ expects 
 argument of type ‘unsigned int’, but argument 3 has type ‘long unsigned int’ 
 [-Wformat=]
DRM_ERROR(child_device_config (size %u) cannot fit in p_child (size %u); 
 bdb-version: %u\n,
^
   CC [M]  drivers/gpu/drm/i915/intel_fifo_underrun.o

 Well spotted.  Or rather, stupid of me to forget that sizeof yields
 size_t as type, thus necessitating %zu as conversion specifier.

 Fixed version:

 Expand common_child_dev_config to be able to fit all information
 defined by the latest VBT specification.

 v2: Use proper conversion specifier for size_t (%zu)

 Signed-off-by: David Weinehall david.weineh...@linux.intel.com
 CC: Antti Koskipaa antti.koski...@linux.intel.com

  intel_bios.c |7 ++-
  intel_bios.h |4 
  2 files changed, 10 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/i915/intel_bios.c 
 b/drivers/gpu/drm/i915/intel_bios.c
 index 990acc20771a..5673ed53797b 100644
 --- a/drivers/gpu/drm/i915/intel_bios.c
 +++ b/drivers/gpu/drm/i915/intel_bios.c
 @@ -1038,6 +1038,10 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
   DRM_DEBUG_KMS(No general definition block is found, no devices 
 defined.\n);
   return;
   }
 + /* Remember to keep this in sync with child_device_config;
 +  * whenever a new feature is added to BDB that causes that
 +  * struct to grow this needs to be updated too
 +  */
   if (bdb-version  195) {
   expected_size = 33;
   } else if (bdb-version == 195) {
 @@ -1051,7 +1055,8 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
   }
  
   if (expected_size  sizeof(*p_child)) {
 - DRM_ERROR(child_device_config cannot fit in p_child\n);
 + DRM_ERROR(child_device_config (size %u) cannot fit in p_child 
 (size %zu); bdb-version: %u\n,
 +   expected_size, sizeof(*p_child), bdb-version);
   return;
   }
  
 diff --git a/drivers/gpu/drm/i915/intel_bios.h 
 b/drivers/gpu/drm/i915/intel_bios.h
 index f7ad6a585129..71cb96f77870 100644
 --- a/drivers/gpu/drm/i915/intel_bios.h
 +++ b/drivers/gpu/drm/i915/intel_bios.h
 @@ -239,6 +239,10 @@ struct common_child_dev_config {
   u8 not_common2[2];
   u8 ddc_pin;
   u16 edid_ptr;
 + u8 obsolete;
 + u8 flags_1;
 + u8 not_common3[13];
 + u8 iboost_level;

How does this impact the if (p_defs-child_dev_size != sizeof(*p_child))
check in parse_sdvo_device_mapping()?

BR,
Jani.

  } __packed;
  
  /* This field changes depending on the BDB version, so the most reliable way 
 to

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

Re: [Intel-gfx] [PATCH 0/9 v6] Batch submission via GuC

[Daniel Vetter]

On Wed, Aug 12, 2015 at 07:35:10PM -0700, O'Rourke, Tom wrote:
 On Wed, Aug 12, 2015 at 07:57:37AM -0700, Gordon, David S wrote:
  On 12/08/15 15:43, Dave Gordon wrote:
   This patch series enables command submission via the GuC. In this mode,
   instead of the host CPU driving the execlist port directly, it hands
   over work items to the GuC, using a doorbell mechanism to tell the GuC
   that new items have been added to its work queue. The GuC then dispatches
   contexts to the various GPU engines, and manages the resulting context-
   switch interrupts. Completion of a batch is however still signalled to
   the CPU; the GuC is not involved in handling user interrupts.
  
   There are two subsequences within the patch series:
  
  drm/i915: GuC-specific firmware loader
  drm/i915: Debugfs interface to read GuC load status
  
   These two patches provide the GuC loader and a debugfs interface to
   verify the resulting state.  At this point in the sequence we can load
   and activate the GuC firmware, but not submit any batches through it.
   (This is nonetheless a potentially useful state, as the GuC could do
   other useful work even when not handling batch submissions).
  
  drm/i915: Expose one LRC function for GuC submission mode
  drm/i915: Prepare for GuC-based command submission
  drm/i915: Enable GuC firmware log
  drm/i915: Implementation of GuC submission client
  drm/i915: Interrupt routing for GuC submission
  drm/i915: Integrate GuC-based command submission
  drm/i915: Debugfs interface for GuC submission statistics
  
   In this second section, we implement the GuC submission mechanism, and
   link it into the (execlist-based) submission path. At this stage, it is
   not yet enabled by default; it is activated only if the kernel command
   line explicitly switches it on.
  
   The GuC firmware itself is not included in this patchset; it is or will
   be available for download from https://01.org/linuxgraphics/downloads/
   This driver works with and requires GuC firmware revision 3.x. It will
   not work with any firmware version 1.x, as the GuC protocol in those
   revisions was incompatible and is no longer supported.
  
   On platforms where there is no GuC, or where GuC submission is not
   specifically enabled, batch submission will continue to use the execlist
   (or ringbuffer) mechanisms.  On the other hand, if GuC submission is
   requested but the GuC firmware cannot be found or is invalid, the GPU
   will be unusable.
  
   It is expected that a subsequent patch will enable GuC submission by
   default once the signed firmware is published on 01.org.
  
   Ben Widawsky (0):
   Vinit Azad (0):
   Michael H. Nguyen (0):
  created the original versions on which some of these patches are based.
  
   Alex Dai (5):
  drm/i915: GuC-specific firmware loader
  drm/i915: Debugfs interface to read GuC load status
  drm/i915: Prepare for GuC-based command submission
  drm/i915: Enable GuC firmware log
  drm/i915: Integrate GuC-based command submission
  
   Dave Gordon (4):
  drm/i915: Expose one LRC function for GuC submission mode
  drm/i915: Implementation of GuC submission client
  drm/i915: Interrupt routing for GuC submission
  drm/i915: Debugfs interface for GuC submission statistics
  
 Documentation/DocBook/drm.tmpl |  14 +
 drivers/gpu/drm/i915/Makefile  |   4 +
 drivers/gpu/drm/i915/i915_debugfs.c| 146 -
 drivers/gpu/drm/i915/i915_dma.c|   9 +
 drivers/gpu/drm/i915/i915_drv.h|  11 +
 drivers/gpu/drm/i915/i915_gem.c|  16 +
 drivers/gpu/drm/i915/i915_gpu_error.c  |  14 +-
 drivers/gpu/drm/i915/i915_guc_reg.h|  17 +-
 drivers/gpu/drm/i915/i915_guc_submission.c | 901 
   +
 drivers/gpu/drm/i915/i915_reg.h|  15 +-
 drivers/gpu/drm/i915/intel_guc.h   | 122 
 drivers/gpu/drm/i915/intel_guc_fwif.h  |   9 +-
 drivers/gpu/drm/i915/intel_guc_loader.c| 611 +++
 drivers/gpu/drm/i915/intel_lrc.c   |  65 ++-
 drivers/gpu/drm/i915/intel_lrc.h   |   8 +
 15 files changed, 1918 insertions(+), 44 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_guc_submission.c
 create mode 100644 drivers/gpu/drm/i915/intel_guc.h
 create mode 100644 drivers/gpu/drm/i915/intel_guc_loader.c
  
  Tom O'Rourke has already R-B'ed the previous [v5] versions of these, and 
  there are no substantive changes to patches 2, 3, 4, 5, 7 and 8, so we 
  can carry that over; also, the change in patch 1 is just an update to a 
  comment noted in Tom's earlier reviews as being out-of-date.
  
  I haven't included patch 10 (enable-by-default) as we've decided to wait 
  until the signed firmware is publicly available on 01.org before
  making it the default.
  
  So, it's really just patches 6/9 

Re: [Intel-gfx] [PATCH 1/2 v2 addendum v2] drm/i915: Allow parsing of variable size child device entries from VBT

[Timo Aaltonen]

On 13.08.2015 16:14, David Weinehall wrote:
 On Wed, Aug 12, 2015 at 05:19:35PM +0300, Jani Nikula wrote:
 On Wed, 12 Aug 2015, David Weinehall david.weineh...@linux.intel.com wrote:
 Some more fixup is needed; the bits from Antti's patch
 that actually expanded the struct to fully fit the newer
 versions of the child_device_config was part of the second
 patch; since that patch hasn't been merged yet we need this bit:

 This applies on top of the patch you already merged
 (the Iboost patch will need corresponding adjustment to
  remove the changes I split out):

 Expand common_child_dev_config to be able to fit all information
 defined by the latest VBT specification.

 Signed-off-by: David Weinehall david.weineh...@linux.intel.com
 CC: Antti Koskipaa antti.koski...@linux.intel.com
 ---
  intel_bios.c |7 ++-
  intel_bios.h |4 
  2 files changed, 10 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/i915/intel_bios.c 
 b/drivers/gpu/drm/i915/intel_bios.c
 index 990acc20771a..40e2cc4e7419 100644
 --- a/drivers/gpu/drm/i915/intel_bios.c
 +++ b/drivers/gpu/drm/i915/intel_bios.c
 @@ -1038,6 +1038,10 @@ parse_device_mapping(struct drm_i915_private 
 *dev_priv,
 DRM_DEBUG_KMS(No general definition block is found, no devices 
 defined.\n);
 return;
 }
 +   /* Remember to keep this in sync with child_device_config;
 +* whenever a new feature is added to BDB that causes that
 +* struct to grow this needs to be updated too
 +*/
 if (bdb-version  195) {
 expected_size = 33;
 } else if (bdb-version == 195) {
 @@ -1051,7 +1055,8 @@ parse_device_mapping(struct drm_i915_private 
 *dev_priv,
 }
  
 if (expected_size  sizeof(*p_child)) {
 -   DRM_ERROR(child_device_config cannot fit in p_child\n);
 +   DRM_ERROR(child_device_config (size %u) cannot fit in p_child 
 (size %u); bdb-version: %u\n,
 + expected_size, sizeof(*p_child), bdb-version);

 drivers/gpu/drm/i915/intel_bios.c: In function ‘parse_device_mapping’:
 drivers/gpu/drm/i915/intel_bios.c:1058:3: warning: format ‘%u’ expects 
 argument of type ‘unsigned int’, but argument 3 has type ‘long unsigned int’ 
 [-Wformat=]
DRM_ERROR(child_device_config (size %u) cannot fit in p_child (size %u); 
 bdb-version: %u\n,
^
   CC [M]  drivers/gpu/drm/i915/intel_fifo_underrun.o
 
 Well spotted.  Or rather, stupid of me to forget that sizeof yields
 size_t as type, thus necessitating %zu as conversion specifier.
 
 Fixed version:
 
 Expand common_child_dev_config to be able to fit all information
 defined by the latest VBT specification.
 
 v2: Use proper conversion specifier for size_t (%zu)
 
 Signed-off-by: David Weinehall david.weineh...@linux.intel.com
 CC: Antti Koskipaa antti.koski...@linux.intel.com
 
  intel_bios.c |7 ++-
  intel_bios.h |4 
  2 files changed, 10 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_bios.c 
 b/drivers/gpu/drm/i915/intel_bios.c
 index 990acc20771a..5673ed53797b 100644
 --- a/drivers/gpu/drm/i915/intel_bios.c
 +++ b/drivers/gpu/drm/i915/intel_bios.c
 @@ -1038,6 +1038,10 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
   DRM_DEBUG_KMS(No general definition block is found, no devices 
 defined.\n);
   return;
   }
 + /* Remember to keep this in sync with child_device_config;
 +  * whenever a new feature is added to BDB that causes that
 +  * struct to grow this needs to be updated too
 +  */
   if (bdb-version  195) {
   expected_size = 33;
   } else if (bdb-version == 195) {
 @@ -1051,7 +1055,8 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
   }
  
   if (expected_size  sizeof(*p_child)) {
 - DRM_ERROR(child_device_config cannot fit in p_child\n);
 + DRM_ERROR(child_device_config (size %u) cannot fit in p_child 
 (size %zu); bdb-version: %u\n,
 +   expected_size, sizeof(*p_child), bdb-version);
   return;
   }
  
 diff --git a/drivers/gpu/drm/i915/intel_bios.h 
 b/drivers/gpu/drm/i915/intel_bios.h
 index f7ad6a585129..71cb96f77870 100644
 --- a/drivers/gpu/drm/i915/intel_bios.h
 +++ b/drivers/gpu/drm/i915/intel_bios.h
 @@ -239,6 +239,10 @@ struct common_child_dev_config {
   u8 not_common2[2];
   u8 ddc_pin;
   u16 edid_ptr;
 + u8 obsolete;
 + u8 flags_1;
 + u8 not_common3[13];
 + u8 iboost_level;
  } __packed;
  
  /* This field changes depending on the BDB version, so the most reliable way 
 to

Please apply this, fixes issues on some machine(s) here. Probably also
cc:stable since it applies to BSW as well as SKL.

and the upstream bug could be referenced too, it's
https://bugs.freedesktop.org/show_bug.cgi?id=91613

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

Re: [Intel-gfx] [PATCH 18/18] gitignore: ignore more files

[Daniel Vetter]

On Thu, Aug 13, 2015 at 01:31:41PM -0700, Jesse Barnes wrote:

git clean fixes this all, at least over here git status is clean.
-Daniel

 ---
  .gitignore   |  3 +++
  tests/.gitignore | 13 +
  tools/.gitignore |  8 
  3 files changed, 24 insertions(+)
 
 diff --git a/.gitignore b/.gitignore
 index a438c1c..533f6f1 100644
 --- a/.gitignore
 +++ b/.gitignore
 @@ -90,3 +90,6 @@ gtk-doc.m4
  
  piglit
  results
 +
 +*.orig
 +version.h
 diff --git a/tests/.gitignore b/tests/.gitignore
 index 31d35a5..e45cbb7 100644
 --- a/tests/.gitignore
 +++ b/tests/.gitignore
 @@ -99,6 +99,7 @@ gem_set_tiling_vs_blt
  gem_set_tiling_vs_gtt
  gem_set_tiling_vs_pwrite
  gem_storedw_batches_loop
 +gem_storedw_loop
  gem_storedw_loop_blt
  gem_storedw_loop_bsd
  gem_storedw_loop_render
 @@ -169,3 +170,15 @@ prime_udl
  template
  test-list.txt
  testdisplay
 +ddi_compute_wrpll
 +gem_vmap_blits
 +gem_wait_render_timeout
 +igt_fork_helper
 +igt_list_only
 +igt_no_exit
 +igt_no_exit_list_only
 +igt_no_subtest
 +igt_simulation
 +pm_pc8
 +pm_psr
 +
 diff --git a/tools/.gitignore b/tools/.gitignore
 index 49bd24f..7bf91e3 100644
 --- a/tools/.gitignore
 +++ b/tools/.gitignore
 @@ -37,3 +37,11 @@ intel_vga_write
  intel_watermark
  skl_compute_wrpll
  skl_ddb_allocation
 +forcewaked
 +intel_dpio_read
 +intel_dpio_write
 +intel_gpu_dump
 +intel_nc_read
 +intel_nc_write
 +intel_punit_read
 +intel_punit_write
 -- 
 1.9.1
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [4.2-rc4] acpi|drm|i915: circular locking dependency: acpi_video_get_backlight_type

[Hans de Goede]

Hi,

On 13-08-15 16:33, Hans de Goede wrote:

Hi,

On 12-08-15 21:26, Ville Syrjälä wrote:

On Mon, Aug 10, 2015 at 08:29:00PM +0200, Sedat Dilek wrote:

On Sat, Aug 1, 2015 at 2:23 PM, Sedat Dilek sedat.di...@gmail.com wrote:

On Mon, Jul 27, 2015 at 12:33 AM, Sedat Dilek sedat.di...@gmail.com wrote:

Hi,

this my first build of a 4.2-rcN Linux-kernel and I see this...



Just FYI:

I am *not* seeing this with drm-intel-nightly from below url.

Also, I plan to test Linux v4.2-rc5.



[ CC Linus ]

Knock Knock Knock.

This issue still remains here (with CONFIG_DRM_I915=m)...

[   18.269792] ==
[   18.269798] [ INFO: possible circular locking dependency detected ]
[   18.269805] 4.2.0-rc6-1-iniza-small #1 Not tainted
[   18.269810] ---
[   18.269816] modprobe/727 is trying to acquire lock:
[   18.269822]  (init_mutex){+.+.+.}, at: [a0090f2d]
acpi_video_get_backlight_type+0x17/0x164 [video]
[   18.269840]
[   18.269840] but task is already holding lock:
[   18.269848]  ((backlight_notifier)-rwsem){..}, at:
[810a6519] __blocking_notifier_call_chain+0x39/0x70
[   18.269864]
[   18.269864] which lock already depends on the new lock.
[   18.269864]
[   18.269875]
[   18.269875] the existing dependency chain (in reverse order) is:
[   18.269884]
...

Full dmesg log and kernel-config attached.

Shall I add Rusty and modules/modprobe folks?


Just got back from vacation and was greeted by this same lockdep splat.

On a hunch I reverted

commit 93a291dfaf9c328ca5a9cea1733af1a128efe890
Author: Hans de Goede hdego...@redhat.com
Date:   Tue Jun 16 16:27:52 2015 +0200

 ACPI / video: Move backlight notifier to video_detect.c

and the problem seems to be gone. Hans, any thoughts?


Looking into this atm, lockdep clearly is right.

Sorry about this I have put a lot of thinking into avoiding
these kind of issues with this patch-set, but I did not realize
there was another lock hiding inside the notifier-chain.

Further analysis shows that the lock inside the notifier-chain
causes similar problems vs register_count_mutex from
drivers/acpi/acpi_video.c. I'm working on a fix for this
atm.


Heh, look at what I just found (I'm shifting my work focus
in the direction of nouveau) :

https://bugzilla.redhat.com/show_bug.cgi?id=1152876

So it looks like we have had the root cause of this issue
for a long time already, maybe my recent backlight selection
logic cleanup / rework has made it easier to trigger the
lockdep warning for this though.

Anyhow assuming people are ok with the fix I submitted
yesterday we've a fix for this now.

Regards,

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

Re: [Intel-gfx] [PATCH 6/6 v3] drm/i915: Enable HDMI on DDI-E

[Daniel Vetter]

On Thu, Aug 13, 2015 at 02:57:38AM +, Zhang, Xiong Y wrote:
  On Wed, Aug 12, 2015 at 06:39:34PM +0800, Xiong Zhang wrote:
   DDI-E doesn't have the correspondent GMBUS pin.
  
   We rely on VBT to tell us which one it being used instead.
  
   The DVI/HDMI on shared port couldn't exist.
  
   This patch isn't tested without hardware wchich has HDMI on DDI-E.
  
   v2: fix trailing whitespace
   v3: WARN() take place of BUG()
  
  I asked for MISSING_CASE, not WARN.
  -Daniel
 [Zhang, Xiong Y] Because DDI-E on SKL doesn't have correspondent GMBUS pin, 
 it should share such pin with DDI-B/C/D. We don't know the default GMBUS pin 
 for DDI-E if VBT doesn't tell us. 
 If VBT don't tell us or give us an invalid GMBUS pin, driver will fail in 
 getting HDMI info. In such case, we really need a warn which tell us why 
 driver couldn't read EDID info for HDMI on DDI-E.

Have you bothered to look at the MISSING_CASE macro?! It does boil down to
a WARN, but I prefer it much over a WARN_ON since it's nicely
standardized.

Thanks, Daniel

 
 thanks
  
  
   Signed-off-by: Xiong Zhang xiong.y.zh...@intel.com
   Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com
   ---
drivers/gpu/drm/i915/i915_drv.h   |  5 +
drivers/gpu/drm/i915/intel_bios.c | 25 +
   drivers/gpu/drm/i915/intel_hdmi.c | 18 ++
3 files changed, 44 insertions(+), 4 deletions(-)
  
   diff --git a/drivers/gpu/drm/i915/i915_drv.h
   b/drivers/gpu/drm/i915/i915_drv.h index 6d93334..5d8e7fe 100644
   --- a/drivers/gpu/drm/i915/i915_drv.h
   +++ b/drivers/gpu/drm/i915/i915_drv.h
   @@ -1414,6 +1414,10 @@ enum modeset_restore {  #define DP_AUX_C
  0x20
   #define DP_AUX_D 0x30
  
   +#define DDC_PIN_B  0x05
   +#define DDC_PIN_C  0x04
   +#define DDC_PIN_D  0x06
   +
struct ddi_vbt_port_info {
 /*
  * This is an index in the HDMI/DVI DDI buffer translation table.
   @@ -1428,6 +1432,7 @@ struct ddi_vbt_port_info {
 uint8_t supports_dp:1;
  
 uint8_t alternate_aux_channel;
   + uint8_t alternate_ddc_pin;
};
  
enum psr_lines_to_wait {
   diff --git a/drivers/gpu/drm/i915/intel_bios.c
   b/drivers/gpu/drm/i915/intel_bios.c
   index 16cdf17..8140531 100644
   --- a/drivers/gpu/drm/i915/intel_bios.c
   +++ b/drivers/gpu/drm/i915/intel_bios.c
   @@ -894,7 +894,7 @@ static void parse_ddi_port(struct drm_i915_private
  *dev_priv, enum port port,
 uint8_t hdmi_level_shift;
 int i, j;
 bool is_dvi, is_hdmi, is_dp, is_edp, is_crt;
   - uint8_t aux_channel;
   + uint8_t aux_channel, ddc_pin;
 /* Each DDI port can have more than one value on the DVO Port field,
  * so look for all the possible values for each port and abort if more
  * than one is found. */
   @@ -928,6 +928,7 @@ static void parse_ddi_port(struct drm_i915_private
  *dev_priv, enum port port,
 return;
  
 aux_channel = child-raw[25];
   + ddc_pin = child-common.ddc_pin;
  
 is_dvi = child-common.device_type 
  DEVICE_TYPE_TMDS_DVI_SIGNALING;
 is_dp = child-common.device_type 
  DEVICE_TYPE_DISPLAYPORT_OUTPUT;
   @@ -959,11 +960,27 @@ static void parse_ddi_port(struct
  drm_i915_private *dev_priv, enum port port,
 DRM_DEBUG_KMS(Port %c is internal DP\n, port_name(port));
  
 if (is_dvi) {
   - if (child-common.ddc_pin == 0x05  port != PORT_B)
   + if (port == PORT_E) {
   + info-alternate_ddc_pin = ddc_pin;
   + /* if DDIE share ddc pin with other port, then
   +  * dvi/hdmi couldn't exist on the shared port.
   +  * Otherwise they share the same ddc bin and system
   +  * couldn't communicate with them seperately. */
   + if (ddc_pin == DDC_PIN_B) {
   + 
   dev_priv-vbt.ddi_port_info[PORT_B].supports_dvi = 0;
   + 
   dev_priv-vbt.ddi_port_info[PORT_B].supports_hdmi = 0;
   + } else if (ddc_pin == DDC_PIN_C) {
   + 
   dev_priv-vbt.ddi_port_info[PORT_C].supports_dvi = 0;
   + 
   dev_priv-vbt.ddi_port_info[PORT_C].supports_hdmi = 0;
   + } else if (ddc_pin == DDC_PIN_D) {
   + 
   dev_priv-vbt.ddi_port_info[PORT_D].supports_dvi = 0;
   + 
   dev_priv-vbt.ddi_port_info[PORT_D].supports_hdmi = 0;
   + }
   + } else if (ddc_pin == DDC_PIN_B  port != PORT_B)
 DRM_DEBUG_KMS(Unexpected DDC pin for port B\n);
   - if (child-common.ddc_pin == 0x04  port != PORT_C)
   + else if (ddc_pin == DDC_PIN_C  port != PORT_C)
 DRM_DEBUG_KMS(Unexpected DDC pin for port C\n);
   - if (child-common.ddc_pin == 0x06  port != PORT_D)
   + else if (ddc_pin == DDC_PIN_D  port != PORT_D)
 DRM_DEBUG_KMS(Unexpected DDC pin for port D\n);
 }
  
   diff --git 

Re: [Intel-gfx] [PATCH v1 1/2] drm/i915: Contain the WA_REG macro

[Daniel Vetter]

On Wed, Aug 12, 2015 at 04:40:03PM +0100, Dave Gordon wrote:
 On 11/08/15 15:44, Arun Siluvery wrote:
 From: Mika Kuoppala mika.kuopp...@intel.com
 
 Prevent leaking the if scoping by containing the WA_REG
 macro inside its own scope.
 
 Reported-by: Arun Siluvery arun.siluv...@linux.intel.com
 Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
 ---
   drivers/gpu/drm/i915/intel_ringbuffer.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
 b/drivers/gpu/drm/i915/intel_ringbuffer.c
 index 1c14233..cf61262 100644
 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
 +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
 @@ -780,11 +780,11 @@ static int wa_add(struct drm_i915_private *dev_priv,
  return 0;
   }
 
 -#define WA_REG(addr, mask, val) { \
 +#define WA_REG(addr, mask, val) do { \
  const int r = wa_add(dev_priv, (addr), (mask), (val)); \
  if (r) \
  return r; \
 -}
 +} while(0)
 
   #define WA_SET_BIT_MASKED(addr, mask) \
  WA_REG(addr, (mask), _MASKED_BIT_ENABLE(mask))
 
 On the one hand, yes, this definitely needs the do-while wrapper.
 
 OTOH, hiding a conditional 'return' inside a macro is an abomination  :( At
 least it's only local to this file ...
 
 So, on the grounds that this makes it more correct if no less ugly:
 
 Reviewed-by: Dave Gordon david.s.gor...@intel.com

Queued for -next, thanks for the patch. And I fixed the checkpatch ERROR,
tsk ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v1 2/2] drm/i915/gen9: Disable gather at set shader bit

[Daniel Vetter]

On Wed, Aug 12, 2015 at 04:41:13PM +0100, Dave Gordon wrote:
 On 11/08/15 15:44, Arun Siluvery wrote:
  From Gen9, Push constant instruction parsing behaviour varies according to
 whether set shader is enabled or not. If we want legacy behaviour then it
 can be achieved by disabling set shader.
 
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89959
 
 Cc: Ben Widawsky benjamin.widaw...@intel.com
 Cc: Joonas Lahtinen joonas.lahti...@linux.intel.com
 Cc: Mika Kuoppala mika.kuopp...@intel.com
 Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com
 ---
   drivers/gpu/drm/i915/i915_reg.h |  5 +
   drivers/gpu/drm/i915/intel_ringbuffer.c | 10 ++
   2 files changed, 15 insertions(+)
 
 [snip]
 
 diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
 b/drivers/gpu/drm/i915/intel_ringbuffer.c
 index cf61262..7d284ed 100644
 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
 +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
 @@ -983,6 +983,16 @@ static int gen9_init_workarounds(struct intel_engine_cs 
 *ring)
  tmp |= HDC_FORCE_CSR_NON_COHERENT_OVR_DISABLE;
  WA_SET_BIT_MASKED(HDC_CHICKEN0, tmp);
 
 +/* Chicken bits to disable set shader is in multiple places,
 + * set bits in all required registers to disable it correctly
 + */
 +WA_SET_BIT_MASKED(COMMON_SLICE_CHICKEN2, 
 GEN9_DISABLE_GATHER_SET_SHADER_SLICE);
 +if ((IS_SKYLAKE(dev)  INTEL_REVID(dev) = SKL_REVID_D0) ||
 +(IS_BROXTON(dev)  INTEL_REVID(dev) == BXT_REVID_A0))
 +WA_SET_BIT_MASKED(RS_CHICKEN, 
 RS_CHICKEN_DISABLE_GATHER_AT_SHADER);
 +else
 +WA_SET_BIT_MASKED(CS_RCS_BE, CS_RCS_DISABLE_GATHER_AT_SHADER);
 +
  return 0;
   }
 
 This workaround isn't tagged with a specific /* WaXyz:chip */ comment.
 Also, the style isn't consistent with the other paragraphs earlier in this
 function: those have braces round the body part even when there's only one
 line of code, possibly to make it clear where the WA comment
 applies (of course, this is why the buggy WA_REG() macro wasn't spotted
 earlier).

Imo if we want to bikeshed this is should be

/*
 * WaBlaFoo:pft
 * extended comment if need
 */
if (IS_FOO(dev))
WA_SET_();

i.e. follow the style in this patch here for all of them.
-Daniel
 
 So, maybe prettify this a bit, if possible? The code actually looks correct,
 just ugly.
 
 Oh, and keep patch 1 even if you decide to abandon this one!
 
 .Dave.
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] lib/rendercopy_gen9: Setup Push constant pointer before sending BTP commands

[Daniel Vetter]

On Thu, Aug 13, 2015 at 03:49:35PM -0700, Ben Widawsky wrote:
 On Thu, Aug 13, 2015 at 10:33:00AM +0300, Joonas Lahtinen wrote:
  Hi,
  
  On ke, 2015-08-12 at 18:35 -0700, Ben Widawsky wrote:
   On Wed, Aug 12, 2015 at 03:10:18PM +0300, Joonas Lahtinen wrote:
On ke, 2015-08-12 at 12:26 +0100, Arun Siluvery wrote:
 From Gen9, by default push constant command is not committed to 
 the 
 shader unit
 untill the corresponding shader's BTP_* command is parsed. This 
 is 
 the
 behaviour when set shader is enabled. This patch updates the 
 batch to 
 follow
 this requirement otherwise it results in gpu hang.
 
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89959
 
 Set shader need to be disabled if legacy behaviour is required.
 
 Cc: Ben Widawsky benjamin.widaw...@intel.com
 Cc: Joonas Lahtinen joonas.lahti...@linux.intel.com
 Cc: Mika Kuoppala mika.kuopp...@intel.com
 Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com

Reviewed-by: Joonas Lahtinen joonas.lahti...@linux.intel.com

   
   Repeating what I said on the mesa thread:
   Does anyone understand why this actually causes a hang on the IGT 
   test? I
   certainly don't. The docs are pretty clear that the constant command 
   is not
   committed until the BTP command, but I can't make any sense of how it 
   related to
   a GPU hang.
   
  
  Changing the order makes the hang go away and come back for sure, we've
  all been experiencing that. System validation said it is a programming
  restriction, so I'm not sure how relevant it is what goes wrong if it's
  not followed. And the legacy mode bits were added to support the old
  behavior of having the order like it has been previously, so I do not
  see why question it without visibility to the actual RTL. And enabling
  the legacy bits makes the hang go away, too.
  
  If I had the RTL sources, then it would be more relevant to take
  educated guesses as to why a set of hundreds of thousands of
  transistors doesn't work as it should :) Without that, if it gets
  stuck, it gets stuck.
  
  Regards, Joonas
  
 
 Let me start by saying I do believe that questioning this shouldn't prevent
 merging the patch.
 
 rant
 I absolutely disagree with you and think we should question these kind of 
 things
 and get out of the mindset of, well, it fixes a hang, let's move on.
 Understanding these kind of things is critical to writing stable drivers.  If
 the programming guide/SV team said it can lead to a hang, that's one thing, 
 but
 AFAICT, we do not understand why it is hanging nor does any of the 
 documentation
 we do have suggest it should hang. Without clarification, next time we have a
 similar hang signature we're going to be right back here where we started.
 
 It was one thing when there were a handful of us working on the stuff and we
 didn't have time to get to the bottom of bugs like this. I'm guilty of patches
 like this myself. I really do not see any excuse for this any more though.
 /rant
 
 Could you send me the reference for where SV said it was a programming
 restriction? To me it all sounds very much like an implementation detail, and
 I'd like to try to understand what I am missing.

Fully agree, we can't just ignore hangs but have to bottom out on them.
And in the past we've had piles of examples where we discovered something
and didn't chase it correctly, then a few months later massive panic in
intel. At least this must be reflected in bspec.

Joonas, can you please work together with Ben to chase this down? If you
don't get traction please escalate the shit out of this,  we really must
at least get docs to accurately reflect reality.

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

Re: [Intel-gfx] [PATCH 1/9 v6] drm/i915: GuC-specific firmware loader

[Daniel Vetter]

On Wed, Aug 12, 2015 at 03:43:36PM +0100, Dave Gordon wrote:
 From: Alex Dai yu@intel.com
 
 This fetches the required firmware image from the filesystem,
 then loads it into the GuC's memory via a dedicated DMA engine.
 
 This patch is derived from GuC loading work originally done by
 Vinit Azad and Ben Widawsky.
 
 v2:
 Various improvements per review comments by Chris Wilson
 
 v3:
 Removed 'wait' parameter to intel_guc_ucode_load() as firmware
 prefetch is no longer supported in the common firmware loader,
   per Daniel Vetter's request.
 Firmware checker callback fn now returns errno rather than bool.
 
 v4:
 Squash uC-independent code into GuC-specifc loader [Daniel Vetter]
 Don't keep the driver working (by falling back to execlist mode)
 if GuC firmware loading fails [Daniel Vetter]
 
 v5:
 Clarify WOPCM-related #defines [Tom O'Rourke]
 Delete obsolete code no longer required with current h/w  f/w
 [Tom O'Rourke]
 Move the call to intel_guc_ucode_init() later, so that it can
 allocate GEM objects, and have it fetch the firmware; then
   intel_guc_ucode_load() doesn't need to fetch it later.
 [Daniel Vetter].
 
 v6:
 Update comment describing intel_guc_ucode_load() [Tom O'Rourke]
 
 Issue: VIZ-4884
 Signed-off-by: Alex Dai yu@intel.com
 Signed-off-by: Dave Gordon david.s.gor...@intel.com

Checkpatch was pretty unhappy with long lines and alignment of
continuations. But didn't look too bad overall so pulled it in.

 +/*
 + * Transfer the firmware image to RAM for execution by the microcontroller.
 + *
 + * GuC Firmware layout:
 + * +---+  
 + * |  CSS header   |  128B
 + * | contains major/minor version  |
 + * +---+  
 + * | uCode |
 + * +---+  
 + * | RSA signature |  256B
 + * +---+  
 + * | RSA public Key|  256B
 + * +---+  
 + * |   Public key modulus  |4B
 + * +---+  
 + *
 + * Architecturally, the DMA engine is bidirectional, and can potentially even
 + * transfer between GTT locations. This functionality is left out of the API
 + * for now as there is no need for it.
 + *
 + * Note that GuC needs the CSS header plus uKernel code to be copied by the
 + * DMA engine in one operation, whereas the RSA signature is loaded via MMIO.

Imo this should be included in the kerneldoc too, especially now that we
can handle tables with markdown.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: fix checksum write for automated test reply

[Daniel Vetter]

On Fri, Aug 14, 2015 at 08:27:45AM +, Jindal, Sonika wrote:
 Looks good to me.
 Reviewed-by: Sonika Jindal sonika.jin...@intel.com

Queued for -next, thanks for the patch.
-Daniel

 
 -Original Message-
 From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
 Sivakumar Thulasimani
 Sent: Friday, August 7, 2015 3:15 PM
 To: dan...@ffwll.ch; intel-gfx@lists.freedesktop.org
 Subject: [Intel-gfx] [PATCH] drm/i915: fix checksum write for automated test 
 reply
 
 From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com
 
 DP spec requires the checksum of the last block read to be written when 
 replying to TEST_EDID_READ. This patch fixes the current code to do the same.
 
 v2: removed loop for jumping blocks and performed direct addition as 
 recommended by Daniel
 
 Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
 ---
  drivers/gpu/drm/i915/intel_dp.c |9 -
  1 file changed, 8 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_dp.c 
 b/drivers/gpu/drm/i915/intel_dp.c index f1b9f93..fa6e202 100644
 --- a/drivers/gpu/drm/i915/intel_dp.c
 +++ b/drivers/gpu/drm/i915/intel_dp.c
 @@ -4090,9 +4090,16 @@ static uint8_t intel_dp_autotest_edid(struct intel_dp 
 *intel_dp)
 intel_dp-aux.i2c_defer_count);
   intel_dp-compliance_test_data = INTEL_DP_RESOLUTION_FAILSAFE;
   } else {
 + struct edid *block = intel_connector-detect_edid;
 +
 + /* We have to write the checksum
 +  * of the last block read
 +  */
 + block += intel_connector-detect_edid-extensions;
 +
   if (!drm_dp_dpcd_write(intel_dp-aux,
   DP_TEST_EDID_CHECKSUM,
 - intel_connector-detect_edid-checksum,
 + block-checksum,
   1))
   DRM_DEBUG_KMS(Failed to write EDID checksum\n);
  
 --
 1.7.9.5
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Adding break for one case

[Daniel Vetter]

On Thu, Aug 13, 2015 at 01:37:49PM +0300, Timo Aaltonen wrote:
 On 13.08.2015 13:36, Timo Aaltonen wrote:
  On 13.08.2015 13:00, Xiong Zhang wrote:
  Signed-off-by: Xiong Zhang xiong.y.zh...@intel.com
  ---
   drivers/gpu/drm/i915/intel_display.c | 1 +
   1 file changed, 1 insertion(+)
 
  diff --git a/drivers/gpu/drm/i915/intel_display.c 
  b/drivers/gpu/drm/i915/intel_display.c
  index 65cc5b1..801187c 100644
  --- a/drivers/gpu/drm/i915/intel_display.c
  +++ b/drivers/gpu/drm/i915/intel_display.c
  @@ -1100,6 +1100,7 @@ bool ibx_digital_port_connected(struct 
  drm_i915_private *dev_priv,
 break;
 case PORT_E:
 bit = SDE_PORTE_HOTPLUG_SPT;
  +  break;
 default:
 return true;
 }
 
  
  shouldn't this belong to [5/6]?
 
 Nevermind, I see now that it got merged already.

I dropped that patch again so that we can rectify this properly. Jani's
complaint about the sub-par commit message still holds though, like why
was this not caught in testing?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/18] tests/gem_ctx_exec: mark lrc lite restore as basic

[Jesse Barnes]

On 08/14/2015 05:32 AM, Daniel Vetter wrote:
 On Thu, Aug 13, 2015 at 01:31:30PM -0700, Jesse Barnes wrote:
 Need some LRC tests in the 'basic' subset, and this is a good simple
 one.

 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 
 This is just a testcase for a very specific lrc corner case. We do already
 exercise lrc with all the other execbuf testcases. Imo we're covered
 enough already with what we have in the basic testset - testing for all 3
 billion cornercases will make it grow out of scope I fear. I'd just drop
 this one here as not needed for BAT.
 
 If you want to extend execbuffer scope a bit then we should add a
 concurrency test, i.e. one of the gem_concurrent_blt testcases as basic
 ones. Unfortunately to be able to reliable trigger race conditions those
 all take a few seconds. But inter-batch sync is a _big_ gap across all
 archs, and something which is even more tricky with lrc (and scheduler).
 Imo that would be a lot more useful than this test here.

Yeah that's a good point; I just saw 'lrc' and though I want that, but you're 
right we should already be covered.  Definitely open to adding some concurrency 
stuff (maybe just a few seconds worth) as we get things in place.

I'll drop this one.

Jesse

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

Re: [Intel-gfx] [PATCH 08/18] tests/gem_mmap: mark basic object creation tests as basic

[Jesse Barnes]

On 08/14/2015 05:33 AM, Daniel Vetter wrote:
 On Thu, Aug 13, 2015 at 01:31:31PM -0700, Jesse Barnes wrote:
 We should be able to create small and moderate sized objects quickly and
 without errors.

 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 
 They're all super-fast basic testcases for api cornercases. I'd vote to
 rename the entire testcase to gem_mmap_basic.

Not quite, the huge ones were pretty slow in my measurements...  Not as bad as 
suspend/resume, but not super fast either.

Jesse

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

Re: [Intel-gfx] [PATCH 06/18] tests/drv_suspend: mark sysfs tests as basic

[Jesse Barnes]

On 08/14/2015 05:29 AM, Daniel Vetter wrote:
 On Thu, Aug 13, 2015 at 01:31:29PM -0700, Jesse Barnes wrote:
 debugfs may not be mounted, but sysfs should always be restored after
 suspend or hibernate.

 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 
 We already have a suspend/resume testcase in kms_pipc_crc_basic. Do we
 have enough budget for this one?

Yeah I thought about getting rid of the suspend/resume ones in pipe_crc 
(marking them as non-basic), since I really just want the one set of tests.  
Any preference?

Jesse

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

Re: [Intel-gfx] [PATCH 11/18] tests/gem_tiled_pread/pwrite: mark normal tests as basic

[Jesse Barnes]

On 08/14/2015 05:41 AM, Daniel Vetter wrote:
 On Thu, Aug 13, 2015 at 01:31:34PM -0700, Jesse Barnes wrote:
 These simple tests should always pass.

 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 
 Imo shouldn't be part of the basic set, they thrash the machine quite
 badly. Especially gem_tiled_pread_pwrite thrashes all of memory, so nack
 on that one from me. At least until we've implemented the speedup with
 memlock that's been in JIRA since years ...
 
 For gem_tiled_pread, why not just rename to gem_tiled_pread_basic?

Yeah sounds good.  Fixed.

Jesse

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

[Intel-gfx] [PATCH igt] lib/ioctl_wrappers: handle ENODEV from from GEM_SET_CACHING ioctl

[Imre Deak]

The ENODEV return value was introduced to the GEM_SET_CACHING ioctl to
mean that the given platform doesn't support the requested caching level
(currently only due to a HW issues on BXT A steppings). Handle this as
the other cases where we want to skip the related subtests.

Signed-off-by: Imre Deak imre.d...@intel.com
---
 lib/ioctl_wrappers.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 53bd635..25f0b2c 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -201,7 +201,8 @@ void gem_set_caching(int fd, uint32_t handle, uint32_t 
caching)
arg.caching = caching;
ret = ioctl(fd, LOCAL_DRM_IOCTL_I915_GEM_SET_CACHEING, arg);
 
-   igt_assert(ret == 0 || (errno == ENOTTY || errno == EINVAL));
+   igt_assert(ret == 0 || (errno == ENOTTY || errno == EINVAL ||
+   errno == ENODEV));
igt_require(ret == 0);
errno = 0;
 }
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH 18/18] gitignore: ignore more files

[Jesse Barnes]

git clean updates the .gitignore file?  Not having to run git clean is the 
whole point of this patch...

On 08/14/2015 01:09 AM, Daniel Vetter wrote:
 On Thu, Aug 13, 2015 at 01:31:41PM -0700, Jesse Barnes wrote:
 
 git clean fixes this all, at least over here git status is clean.
 -Daniel
 
 ---
  .gitignore   |  3 +++
  tests/.gitignore | 13 +
  tools/.gitignore |  8 
  3 files changed, 24 insertions(+)

 diff --git a/.gitignore b/.gitignore
 index a438c1c..533f6f1 100644
 --- a/.gitignore
 +++ b/.gitignore
 @@ -90,3 +90,6 @@ gtk-doc.m4
  
  piglit
  results
 +
 +*.orig
 +version.h
 diff --git a/tests/.gitignore b/tests/.gitignore
 index 31d35a5..e45cbb7 100644
 --- a/tests/.gitignore
 +++ b/tests/.gitignore
 @@ -99,6 +99,7 @@ gem_set_tiling_vs_blt
  gem_set_tiling_vs_gtt
  gem_set_tiling_vs_pwrite
  gem_storedw_batches_loop
 +gem_storedw_loop
  gem_storedw_loop_blt
  gem_storedw_loop_bsd
  gem_storedw_loop_render
 @@ -169,3 +170,15 @@ prime_udl
  template
  test-list.txt
  testdisplay
 +ddi_compute_wrpll
 +gem_vmap_blits
 +gem_wait_render_timeout
 +igt_fork_helper
 +igt_list_only
 +igt_no_exit
 +igt_no_exit_list_only
 +igt_no_subtest
 +igt_simulation
 +pm_pc8
 +pm_psr
 +
 diff --git a/tools/.gitignore b/tools/.gitignore
 index 49bd24f..7bf91e3 100644
 --- a/tools/.gitignore
 +++ b/tools/.gitignore
 @@ -37,3 +37,11 @@ intel_vga_write
  intel_watermark
  skl_compute_wrpll
  skl_ddb_allocation
 +forcewaked
 +intel_dpio_read
 +intel_dpio_write
 +intel_gpu_dump
 +intel_nc_read
 +intel_nc_write
 +intel_punit_read
 +intel_punit_write
 -- 
 1.9.1

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

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

[Intel-gfx] [PATCH v3 5/7] tests: update core_getversion to run on any platform

[Micah Fedke]

---
 tests/core_getversion.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/core_getversion.c b/tests/core_getversion.c
index f994315..2f481c9 100644
--- a/tests/core_getversion.c
+++ b/tests/core_getversion.c
@@ -37,7 +37,7 @@ igt_simple_main
int fd;
drmVersionPtr v;
 
-   fd = drm_open_driver(DRIVER_INTEL);
+   fd = drm_open_driver(OPEN_ANY_GPU);
v = drmGetVersion(fd);
igt_assert(strlen(v-name) != 0);
igt_assert(strlen(v-date) != 0);
-- 
2.1.4

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

[Intel-gfx] [PATCH v3 4/7] tests: update core_get_client_auth to run on any platform

[Micah Fedke]

---
 tests/core_get_client_auth.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/core_get_client_auth.c b/tests/core_get_client_auth.c
index 92313f9..3518bb7 100644
--- a/tests/core_get_client_auth.c
+++ b/tests/core_get_client_auth.c
@@ -84,7 +84,7 @@ igt_main
 {
/* root (which we run igt as) should always be authenticated */
igt_subtest(simple) {
-   int fd = drm_open_driver(DRIVER_INTEL);
+   int fd = drm_open_driver(OPEN_ANY_GPU);
 
igt_assert(check_auth(fd) == true);
 
@@ -92,8 +92,8 @@ igt_main
}
 
igt_subtest(master-drop) {
-   int fd = drm_open_driver(DRIVER_INTEL);
-   int fd2 = drm_open_driver(DRIVER_INTEL);
+   int fd = drm_open_driver(OPEN_ANY_GPU);
+   int fd2 = drm_open_driver(OPEN_ANY_GPU);
 
igt_assert(check_auth(fd2) == true);
 
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH 01/18] tests/gem_storedw_loop: add new store_dword test to unify per-ring ones

[Jesse Barnes]

On 08/14/2015 05:19 AM, Daniel Vetter wrote:
 On Thu, Aug 13, 2015 at 01:31:24PM -0700, Jesse Barnes wrote:
 There was a lot of duplication going on...  Mark as basic while we're at
 it as these should never fail.

 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 ---
  tests/Makefile.sources   |   1 +
  tests/gem_storedw_loop.c | 181 
 +++
  2 files changed, 182 insertions(+)
  create mode 100644 tests/gem_storedw_loop.c

 diff --git a/tests/Makefile.sources b/tests/Makefile.sources
 index b9a4cb4..cdcee33 100644
 --- a/tests/Makefile.sources
 +++ b/tests/Makefile.sources
 @@ -138,6 +138,7 @@ TESTS_progs = \
  gem_seqno_wrap \
  gem_set_tiling_vs_gtt \
  gem_set_tiling_vs_pwrite \
 +gem_storedw_loop \
  gem_storedw_loop_blt \
  gem_storedw_loop_bsd \
  gem_storedw_loop_render \
 
 Why not remove the old ones while at it? This just means more gunk in the
 overall igt set. Also please update .gitignore here for these ...

Yeah figured that would be a separate patch assuming this one looked ok.  I 
added it to the .gitignore in a later patch to update it all at once.

Jesse

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

Re: [Intel-gfx] [PATCH 05/18] tests/drv_getparams: mark EU and subslice fetch as basic

[Jesse Barnes]

On 08/14/2015 05:27 AM, Daniel Vetter wrote:
 On Thu, Aug 13, 2015 at 01:31:28PM -0700, Jesse Barnes wrote:
 Fundamental and simple functionality.

 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 
 Mark entire testcase as basic instead to catch future extensions?
 getparams should always complete super-fast I think.

Sure, that works too.

Jesse

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

[Intel-gfx] [PATCH v3 1/7] lib: adding drm_open_driver() interface

[Micah Fedke]

The drm_open_driver*() functions replace the drm_open_any*() functions and
provide the same utility, but in a way that is platform agnostic, not
intel-specific.  This opens the path for adopting intel-gpu-tools to non-intel
platforms.

This commit renames the calls and adds the chipset parameter which can be used
to restrict the opening to a specific hardware family.  For example,
drm_open_driver(DRIVER_INTEL) will only return a valid fd if an intel GPU is
found on the system, along with performing intel-specific initialization stuff
like gem_quiescent_gpu(), et al.  If OPEN_ANY_GPU is specified, the first
available drm device of any type will be opened.

Other hardware type flags may be added in the future.

The drm_open_any*() calls are retained as aliases of
drm_open_driver*(OPEN_ANY_GPU) but will be removed in a subsequent patch.

Signed-off-by: Micah Fedke micah.fe...@collabora.co.uk
---
 lib/drmtest.c | 97 +--
 lib/drmtest.h | 18 ---
 2 files changed, 75 insertions(+), 40 deletions(-)

diff --git a/lib/drmtest.c b/lib/drmtest.c
index ee5c123..44a0f62 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -75,23 +75,32 @@
 
 uint16_t __drm_device_id;
 
-static int is_i915_device(int fd)
+static int __get_drm_device_name(int fd, char *name)
 {
drm_version_t version;
-   char name[5] = ;
 
memset(version, 0, sizeof(version));
version.name_len = 4;
version.name = name;
 
-   if (drmIoctl(fd, DRM_IOCTL_VERSION, version))
+   if (!drmIoctl(fd, DRM_IOCTL_VERSION, version)){
return 0;
+   }
+
+   return -1;
+}
 
-   return strcmp(i915, name) == 0;
+static bool is_i915_device(int fd)
+{
+   int ret;
+   char name[5] = ;
+
+   ret = __get_drm_device_name(fd, name);
+
+   return !ret  strcmp(i915, name) == 0;
 }
 
-static int
-is_intel(int fd)
+static bool is_intel(int fd)
 {
struct drm_i915_getparam gp;
int devid = 0;
@@ -101,13 +110,13 @@ is_intel(int fd)
gp.value = devid;
 
if (ioctl(fd, DRM_IOCTL_I915_GETPARAM, gp, sizeof(gp)))
-   return 0;
+   return false;
 
if (!IS_INTEL(devid))
-   return 0;
+   return false;
 
__drm_device_id = devid;
-   return 1;
+   return true;
 }
 
 static void check_stop_rings(void)
@@ -230,19 +239,31 @@ int drm_get_card(void)
return -1;
 }
 
-/** Open the first DRM device we can find, searching up to 16 device nodes */
-int __drm_open_any(void)
+/**
+ * __drm_open_driver:
+ *
+ * Open the first DRM device we can find, searching up to 16 device nodes
+ *
+ * @chipset: OR'd flags for each chipset to search, eg. DRIVER_INTEL
+ *
+ * Returns:
+ * An open DRM fd or -1 on error
+ */
+int __drm_open_driver(int chipset)
 {
for (int i = 0; i  16; i++) {
char name[80];
int fd;
+   bool found_intel;
 
sprintf(name, /dev/dri/card%u, i);
fd = open(name, O_RDWR);
if (fd == -1)
continue;
 
-   if (is_i915_device(fd)  is_intel(fd))
+   found_intel =  is_i915_device(fd)  is_intel(fd)  (chipset  
DRIVER_INTEL);
+
+   if ((chipset  OPEN_ANY_GPU) || found_intel)
return fd;
 
close(fd);
@@ -252,7 +273,7 @@ int __drm_open_any(void)
return -1;
 }
 
-static int __drm_open_any_render(void)
+static int __drm_open_driver_render(int chipset)
 {
char *name;
int i, fd;
@@ -307,41 +328,43 @@ static void quiescent_gpu_at_exit_render(int sig)
 }
 
 /**
- * drm_open_any:
+ * drm_open_driver:
  *
- * Open an i915 drm legacy device node. This function always returns a valid
+ * Open a drm legacy device node. This function always returns a valid
  * file descriptor.
  *
- * Returns: a i915 drm file descriptor
+ * Returns: a drm file descriptor
  */
-int drm_open_any(void)
+int drm_open_driver(int chipset)
 {
static int open_count;
-   int fd = __drm_open_any();
+   int fd = __drm_open_driver(chipset);
 
igt_require(fd = 0);
 
if (__sync_fetch_and_add(open_count, 1))
return fd;
 
-   gem_quiescent_gpu(fd);
-   at_exit_drm_fd = __drm_open_any();
-   igt_install_exit_handler(quiescent_gpu_at_exit);
+   if(chipset  DRIVER_INTEL){
+   gem_quiescent_gpu(fd);
+   igt_install_exit_handler(quiescent_gpu_at_exit);
+   }
+   at_exit_drm_fd = __drm_open_driver(chipset);
 
return fd;
 }
 
 /**
- * drm_open_any_master:
+ * drm_open_driver_master:
  *
- * Open an i915 drm legacy device node and ensure that it is drm master.
+ * Open a drm legacy device node and ensure that it is drm master.
  *
  * Returns:
- * The i915 drm file descriptor or -1 on error
+ * The drm file descriptor or -1 on error
  */
-int drm_open_any_master(void)
+int 

[Intel-gfx] [PATCH v3 0/7] igt: adding parameter to drm_open_any and drm_open_any_master to allow specification of non-intel GPUs

[Micah Fedke]

Changes since last version of patch:

Now using the core_* tests as demonstrations rather than drm_read.

Micah Fedke (7):
  lib: adding drm_open_driver() interface
  convert drm_open_any*() calls to drm_open_driver*(DRIVER_INTEL) calls
with cocci
  lib: remove support for deprecated drm_open_any*() calls
  tests: update core_get_client_auth to run on any platform
  tests: update core_getversion to run on any platform
  tests: update core_getclient to run on any platform
  tests: update core_getstats to run on any platform

 benchmarks/gem_userptr_benchmark.c   |  2 +-
 benchmarks/intel_upload_blit_large.c |  2 +-
 benchmarks/intel_upload_blit_large_gtt.c |  2 +-
 benchmarks/intel_upload_blit_large_map.c |  2 +-
 benchmarks/intel_upload_blit_small.c |  2 +-
 debugger/eudb.c  |  2 +-
 lib/drmtest.c| 97 
 lib/drmtest.h| 12 ++--
 lib/igt_gt.c |  2 +-
 lib/igt_kms.c|  2 +-
 tests/core_get_client_auth.c |  6 +-
 tests/core_getclient.c   |  2 +-
 tests/core_getstats.c|  2 +-
 tests/core_getversion.c  |  2 +-
 tests/drm_import_export.c|  4 +-
 tests/drm_read.c |  2 +-
 tests/drm_vma_limiter.c  |  2 +-
 tests/drm_vma_limiter_cached.c   |  2 +-
 tests/drm_vma_limiter_cpu.c  |  2 +-
 tests/drm_vma_limiter_gtt.c  |  2 +-
 tests/drv_getparams.c|  2 +-
 tests/drv_hangman.c  |  4 +-
 tests/drv_suspend.c  |  2 +-
 tests/eviction_common.c  |  2 +-
 tests/gem_alive.c|  2 +-
 tests/gem_bad_address.c  |  2 +-
 tests/gem_bad_batch.c|  2 +-
 tests/gem_bad_blit.c |  2 +-
 tests/gem_bad_length.c   |  2 +-
 tests/gem_bad_reloc.c|  2 +-
 tests/gem_basic.c|  2 +-
 tests/gem_caching.c  |  2 +-
 tests/gem_concurrent_blit.c  |  4 +-
 tests/gem_cpu_reloc.c|  2 +-
 tests/gem_cs_prefetch.c  |  2 +-
 tests/gem_cs_tlb.c   |  2 +-
 tests/gem_ctx_bad_destroy.c  |  2 +-
 tests/gem_ctx_bad_exec.c |  2 +-
 tests/gem_ctx_basic.c|  4 +-
 tests/gem_ctx_create.c   |  2 +-
 tests/gem_ctx_exec.c |  2 +-
 tests/gem_ctx_param_basic.c  |  2 +-
 tests/gem_ctx_thrash.c   |  4 +-
 tests/gem_double_irq_loop.c  |  2 +-
 tests/gem_dummy_reloc_loop.c |  4 +-
 tests/gem_evict_alignment.c  |  2 +-
 tests/gem_evict_everything.c |  2 +-
 tests/gem_exec_bad_domains.c |  2 +-
 tests/gem_exec_big.c |  2 +-
 tests/gem_exec_blt.c |  2 +-
 tests/gem_exec_faulting_reloc.c  |  2 +-
 tests/gem_exec_lut_handle.c  |  2 +-
 tests/gem_exec_nop.c |  2 +-
 tests/gem_exec_params.c  |  2 +-
 tests/gem_exec_parse.c   |  2 +-
 tests/gem_fd_exhaustion.c|  2 +-
 tests/gem_fence_thrash.c |  2 +-
 tests/gem_fence_upload.c |  8 +--
 tests/gem_fenced_exec_thrash.c   |  2 +-
 tests/gem_flink.c|  6 +-
 tests/gem_flink_race.c   |  6 +-
 tests/gem_gpgpu_fill.c   |  2 +-
 tests/gem_gtt_cpu_tlb.c  |  2 +-
 tests/gem_gtt_hog.c  |  4 +-
 tests/gem_gtt_speed.c|  2 +-
 tests/gem_hang.c |  2 +-
 tests/gem_hangcheck_forcewake.c  |  2 +-
 tests/gem_largeobject.c  |  2 +-
 tests/gem_linear_blits.c |  2 +-
 tests/gem_lut_handle.c   |  2 +-
 tests/gem_madvise.c  |  8 +--
 tests/gem_media_fill.c   |  2 +-
 tests/gem_mmap.c |  2 +-
 tests/gem_mmap_gtt.c |  4 +-
 tests/gem_mmap_offset_exhaustion.c   |  2 +-
 tests/gem_mmap_wc.c  |  2 +-
 tests/gem_multi_bsd_sync_loop.c  |  4 +-
 tests/gem_non_secure_batch.c |  2 +-
 tests/gem_partial_pwrite_pread.c |  2 +-
 tests/gem_persistent_relocs.c|  2 +-
 tests/gem_pin.c  |  2 +-
 tests/gem_pipe_control_store_loop.c  |  2 +-
 tests/gem_ppgtt.c|  4 +-
 tests/gem_pread.c|  2 +-
 tests/gem_pread_after_blit.c |  2 +-
 tests/gem_pwrite.c   |  2 +-
 tests/gem_pwrite_pread.c |  2 +-
 tests/gem_readwrite.c|  2 +-
 tests/gem_reg_read.c  

[Intel-gfx] [PATCH v3 7/7] tests: update core_getstats to run on any platform

[Micah Fedke]

---
 tests/core_getstats.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/core_getstats.c b/tests/core_getstats.c
index cdab0e5..6f6a4ee 100644
--- a/tests/core_getstats.c
+++ b/tests/core_getstats.c
@@ -48,7 +48,7 @@ igt_simple_main
int fd, ret;
drm_stats_t stats;
 
-   fd = drm_open_driver(DRIVER_INTEL);
+   fd = drm_open_driver(OPEN_ANY_GPU);
 
ret = ioctl(fd, DRM_IOCTL_GET_STATS, stats);
igt_assert(ret == 0);
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH 03/18] tests/drv_module_reload_basic: use linear_blits after module_reload for sanity check

[Jesse Barnes]

On 08/14/2015 05:22 AM, Daniel Vetter wrote:
 On Thu, Aug 13, 2015 at 01:31:26PM -0700, Jesse Barnes wrote:
 Reduces runtime a lot...

 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 ---
  tests/drv_module_reload_basic | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/tests/drv_module_reload_basic b/tests/drv_module_reload_basic
 index bb29a64..cf7f2b8 100755
 --- a/tests/drv_module_reload_basic
 +++ b/tests/drv_module_reload_basic
 @@ -52,7 +52,7 @@ else
  fi
  
  # then try to run something
 -if ! $SOURCE_DIR/gem_exec_nop  /dev/null ; then
 +if ! $SOURCE_DIR/gem_linear_blits --r basic  /dev/null ; then
 
 Please use the full-lenght run-subtest to avoid lots of wtf when we add
 another option starting with r eventually. With that fixed:
 
 Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch

Done, thanks.

Jesse

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

[Intel-gfx] [PATCH v3 2/7] convert drm_open_any*() calls to drm_open_driver*(DRIVER_INTEL) calls with cocci

[Micah Fedke]

Apply the new API to all call sites within the test suite using the following
semantic patch:

// Semantic patch for replacing drm_open_any* with arch-specific 
drm_open_driver* calls
@@
identifier i =~ \bdrm_open_any\b;
@@
- i()
+ drm_open_driver(DRIVER_INTEL)

@@
identifier i =~ \bdrm_open_any_master\b;
@@
- i()
+ drm_open_driver_master(DRIVER_INTEL)

@@
identifier i =~ \bdrm_open_any_render\b;
@@
- i()
+ drm_open_driver_render(DRIVER_INTEL)

@@
identifier i =~ \b__drm_open_any\b;
@@
- i()
+ __drm_open_driver(DRIVER_INTEL)

Signed-off-by: Micah Fedke micah.fe...@collabora.co.uk
---
 benchmarks/gem_userptr_benchmark.c   |  2 +-
 benchmarks/intel_upload_blit_large.c |  2 +-
 benchmarks/intel_upload_blit_large_gtt.c |  2 +-
 benchmarks/intel_upload_blit_large_map.c |  2 +-
 benchmarks/intel_upload_blit_small.c |  2 +-
 debugger/eudb.c  |  2 +-
 lib/igt_gt.c |  2 +-
 lib/igt_kms.c|  2 +-
 tests/core_get_client_auth.c |  6 ++---
 tests/core_getclient.c   |  2 +-
 tests/core_getstats.c|  2 +-
 tests/core_getversion.c  |  2 +-
 tests/drm_import_export.c|  4 ++--
 tests/drm_read.c |  2 +-
 tests/drm_vma_limiter.c  |  2 +-
 tests/drm_vma_limiter_cached.c   |  2 +-
 tests/drm_vma_limiter_cpu.c  |  2 +-
 tests/drm_vma_limiter_gtt.c  |  2 +-
 tests/drv_getparams.c|  2 +-
 tests/drv_hangman.c  |  4 ++--
 tests/drv_suspend.c  |  2 +-
 tests/eviction_common.c  |  2 +-
 tests/gem_alive.c|  2 +-
 tests/gem_bad_address.c  |  2 +-
 tests/gem_bad_batch.c|  2 +-
 tests/gem_bad_blit.c |  2 +-
 tests/gem_bad_length.c   |  2 +-
 tests/gem_bad_reloc.c|  2 +-
 tests/gem_basic.c|  2 +-
 tests/gem_caching.c  |  2 +-
 tests/gem_concurrent_blit.c  |  4 ++--
 tests/gem_cpu_reloc.c|  2 +-
 tests/gem_cs_prefetch.c  |  2 +-
 tests/gem_cs_tlb.c   |  2 +-
 tests/gem_ctx_bad_destroy.c  |  2 +-
 tests/gem_ctx_bad_exec.c |  2 +-
 tests/gem_ctx_basic.c|  4 ++--
 tests/gem_ctx_create.c   |  2 +-
 tests/gem_ctx_exec.c |  2 +-
 tests/gem_ctx_param_basic.c  |  2 +-
 tests/gem_ctx_thrash.c   |  4 ++--
 tests/gem_double_irq_loop.c  |  2 +-
 tests/gem_dummy_reloc_loop.c |  4 ++--
 tests/gem_evict_alignment.c  |  2 +-
 tests/gem_evict_everything.c |  2 +-
 tests/gem_exec_bad_domains.c |  2 +-
 tests/gem_exec_big.c |  2 +-
 tests/gem_exec_blt.c |  2 +-
 tests/gem_exec_faulting_reloc.c  |  2 +-
 tests/gem_exec_lut_handle.c  |  2 +-
 tests/gem_exec_nop.c |  2 +-
 tests/gem_exec_params.c  |  2 +-
 tests/gem_exec_parse.c   |  2 +-
 tests/gem_fd_exhaustion.c|  2 +-
 tests/gem_fence_thrash.c |  2 +-
 tests/gem_fence_upload.c |  8 +++
 tests/gem_fenced_exec_thrash.c   |  2 +-
 tests/gem_flink.c|  6 ++---
 tests/gem_flink_race.c   |  6 ++---
 tests/gem_gpgpu_fill.c   |  2 +-
 tests/gem_gtt_cpu_tlb.c  |  2 +-
 tests/gem_gtt_hog.c  |  4 ++--
 tests/gem_gtt_speed.c|  2 +-
 tests/gem_hang.c |  2 +-
 tests/gem_hangcheck_forcewake.c  |  2 +-
 tests/gem_largeobject.c  |  2 +-
 tests/gem_linear_blits.c |  2 +-
 tests/gem_lut_handle.c   |  2 +-
 tests/gem_madvise.c  |  8 +++
 tests/gem_media_fill.c   |  2 +-
 tests/gem_mmap.c |  2 +-
 tests/gem_mmap_gtt.c |  4 ++--
 tests/gem_mmap_offset_exhaustion.c   |  2 +-
 tests/gem_mmap_wc.c  |  2 +-
 tests/gem_multi_bsd_sync_loop.c  |  4 ++--
 tests/gem_non_secure_batch.c |  2 +-
 tests/gem_partial_pwrite_pread.c |  2 +-
 tests/gem_persistent_relocs.c|  2 +-
 tests/gem_pin.c  |  2 +-
 tests/gem_pipe_control_store_loop.c  |  2 +-
 tests/gem_ppgtt.c|  4 ++--
 tests/gem_pread.c|  2 +-
 tests/gem_pread_after_blit.c |  2 +-
 tests/gem_pwrite.c   |  2 +-
 tests/gem_pwrite_pread.c |  2 +-
 tests/gem_readwrite.c|  2 +-
 tests/gem_reg_read.c |  2 +-
 

[Intel-gfx] [PATCH v3 6/7] tests: update core_getclient to run on any platform

[Micah Fedke]

---
 tests/core_getclient.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/core_getclient.c b/tests/core_getclient.c
index d82e349..5293741 100644
--- a/tests/core_getclient.c
+++ b/tests/core_getclient.c
@@ -39,7 +39,7 @@ igt_simple_main
int fd, ret;
drm_client_t client;
 
-   fd = drm_open_driver(DRIVER_INTEL);
+   fd = drm_open_driver(OPEN_ANY_GPU);
 
/* Look for client index 0.  This should exist whether we're operating
 * on an otherwise unused drm device, or the X Server is running on
-- 
2.1.4

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

[Intel-gfx] [PATCH v3 3/7] lib: remove support for deprecated drm_open_any*() calls

[Micah Fedke]

Signed-off-by: Micah Fedke micah.fe...@collabora.co.uk
---
 lib/drmtest.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/lib/drmtest.h b/lib/drmtest.h
index dcb0c34..41ddbe7 100644
--- a/lib/drmtest.h
+++ b/lib/drmtest.h
@@ -41,12 +41,6 @@
 #define OPEN_ANY_GPU 0x1
 #define DRIVER_INTEL (0x1  1)
 
-/* provide the deprecated drm_open_any*() calls */
-#define drm_open_any() drm_open_driver(OPEN_ANY_GPU)
-#define drm_open_any_master() drm_open_driver_master(OPEN_ANY_GPU)
-#define drm_open_any_render() drm_open_driver_render(OPEN_ANY_GPU)
-#define __drm_open_any() __drm_open_driver(OPEN_ANY_GPU)
-
 
 #ifdef ANDROID
 #ifndef HAVE_MMAP64
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH 04/18] tests/drm_import_export: mark flink and prime tests as basic

[Jesse Barnes]

On 08/14/2015 05:26 AM, Daniel Vetter wrote:
 On Thu, Aug 13, 2015 at 01:31:27PM -0700, Jesse Barnes wrote:
 They're testing basic functionality and don't involve stress or race
 induction.

 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 
 These are more stress-tests in nature I think. For basic testscases of
 prime I'd recommend instead
 
 prime_self_import: Everything not marked with *-race
 
 gem_flink: all of them.
 
 instead of this patch here.

Sounds good, done.

Jesse

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

[Intel-gfx] [PATCH v3 1/2] drm/i915/bxt: work around HW coherency issue when accessing GPU seqno

[Imre Deak]

By running igt/store_dword_loop_render on BXT we can hit a coherency
problem where the seqno written at GPU command completion time is not
seen by the CPU. This results in __i915_wait_request seeing the stale
seqno and not completing the request (not considering the lost
interrupt/GPU reset mechanism). I also verified that this isn't a case
of a lost interrupt, or that the command didn't complete somehow: when
the coherency issue occured I read the seqno via an uncached GTT mapping
too. While the cached version of the seqno still showed the stale value
the one read via the uncached mapping was the correct one.

Work around this issue by clflushing the corresponding CPU cacheline
following any store of the seqno and preceding any reading of it. When
reading it do this only when the caller expects a coherent view.

v2:
- fix using the proper logical  instead of a bitwise  (Jani, Mika)
- limit the workaround to A stepping, on later steppings this HW issue
  is fixed
v3:
- use a separate get_seqno/set_seqno vfunc (Chris)

Testcase: igt/store_dword_loop_render
Signed-off-by: Imre Deak imre.d...@intel.com
---
 drivers/gpu/drm/i915/intel_lrc.c| 64 -
 drivers/gpu/drm/i915/intel_ringbuffer.h |  7 
 2 files changed, 63 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 138964a..1269d57 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1699,6 +1699,34 @@ static void gen8_set_seqno(struct intel_engine_cs *ring, 
u32 seqno)
intel_write_status_page(ring, I915_GEM_HWS_INDEX, seqno);
 }
 
+static u32 bxt_a_get_seqno(struct intel_engine_cs *ring, bool lazy_coherency)
+{
+
+   /*
+* On BXT A steppings there is a HW coherency issue whereby the
+* MI_STORE_DATA_IMM storing the completed request's seqno
+* occasionally doesn't invalidate the CPU cache. Work around this by
+* clflushing the corresponding cacheline whenever the caller wants
+* the coherency to be guaranteed. Note that this cacheline is known
+* to be clean at this point, since we only write it in
+* bxt_a_set_seqno(), where we also do a clflush after the write. So
+* this clflush in practice becomes an invalidate operation.
+*/
+
+   if (!lazy_coherency)
+   intel_flush_status_page(ring, I915_GEM_HWS_INDEX);
+
+   return intel_read_status_page(ring, I915_GEM_HWS_INDEX);
+}
+
+static void bxt_a_set_seqno(struct intel_engine_cs *ring, u32 seqno)
+{
+   intel_write_status_page(ring, I915_GEM_HWS_INDEX, seqno);
+
+   /* See bxt_a_get_seqno() explaining the reason for the clflush. */
+   intel_flush_status_page(ring, I915_GEM_HWS_INDEX);
+}
+
 static int gen8_emit_request(struct drm_i915_gem_request *request)
 {
struct intel_ringbuffer *ringbuf = request-ringbuf;
@@ -1868,8 +1896,13 @@ static int logical_render_ring_init(struct drm_device 
*dev)
ring-init_hw = gen8_init_render_ring;
ring-init_context = gen8_init_rcs_context;
ring-cleanup = intel_fini_pipe_control;
-   ring-get_seqno = gen8_get_seqno;
-   ring-set_seqno = gen8_set_seqno;
+   if (IS_BROXTON(dev)  INTEL_REVID(dev)  BXT_REVID_B0) {
+   ring-get_seqno = bxt_a_get_seqno;
+   ring-set_seqno = bxt_a_set_seqno;
+   } else {
+   ring-get_seqno = gen8_get_seqno;
+   ring-set_seqno = gen8_set_seqno;
+   }
ring-emit_request = gen8_emit_request;
ring-emit_flush = gen8_emit_flush_render;
ring-irq_get = gen8_logical_ring_get_irq;
@@ -1915,8 +1948,13 @@ static int logical_bsd_ring_init(struct drm_device *dev)
GT_CONTEXT_SWITCH_INTERRUPT  GEN8_VCS1_IRQ_SHIFT;
 
ring-init_hw = gen8_init_common_ring;
-   ring-get_seqno = gen8_get_seqno;
-   ring-set_seqno = gen8_set_seqno;
+   if (IS_BROXTON(dev)  INTEL_REVID(dev)  BXT_REVID_B0) {
+   ring-get_seqno = bxt_a_get_seqno;
+   ring-set_seqno = bxt_a_set_seqno;
+   } else {
+   ring-get_seqno = gen8_get_seqno;
+   ring-set_seqno = gen8_set_seqno;
+   }
ring-emit_request = gen8_emit_request;
ring-emit_flush = gen8_emit_flush;
ring-irq_get = gen8_logical_ring_get_irq;
@@ -1965,8 +2003,13 @@ static int logical_blt_ring_init(struct drm_device *dev)
GT_CONTEXT_SWITCH_INTERRUPT  GEN8_BCS_IRQ_SHIFT;
 
ring-init_hw = gen8_init_common_ring;
-   ring-get_seqno = gen8_get_seqno;
-   ring-set_seqno = gen8_set_seqno;
+   if (IS_BROXTON(dev)  INTEL_REVID(dev)  BXT_REVID_B0) {
+   ring-get_seqno = bxt_a_get_seqno;
+   ring-set_seqno = bxt_a_set_seqno;
+   } else {
+   ring-get_seqno = gen8_get_seqno;
+   ring-set_seqno = gen8_set_seqno;
+   }
ring-emit_request = gen8_emit_request;
   

[Intel-gfx] [PATCH v3 2/2] drm/i915/bxt: don't allow cached GEM mappings on A stepping

[Imre Deak]

Due to a coherency issue on BXT A steppings we can't guarantee a
coherent view of cached (CPU snooped) GPU mappings, so fail such
requests. User space is supposed to fall back to uncached mappings in
this case.

v2:
- limit the WA to A steppings, on later stepping this HW issue is fixed
v3:
- return error instead of trying to work around the issue in kernel,
  since that could confuse user space (Chris)

Testcast: igt/gem_store_dword_batches_loop/cached-mapping
Signed-off-by: Imre Deak imre.d...@intel.com
---
 drivers/gpu/drm/i915/i915_gem.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 407b6b3..95fd4ff 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3742,6 +3742,15 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, 
void *data,
level = I915_CACHE_NONE;
break;
case I915_CACHING_CACHED:
+   /*
+* Due to a HW issue on BXT A stepping, GPU stores via a
+* snooped mapping may leave stale data in a corresponding CPU
+* cacheline, whereas normally such cachelines would get
+* invalidated.
+*/
+   if (IS_BROXTON(dev)  INTEL_REVID(dev)  BXT_REVID_B0)
+   return -ENODEV;
+
level = I915_CACHE_LLC;
break;
case I915_CACHING_DISPLAY:
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH 13/18] tests/kms_vblank: mark accuracy test as basic

[Jesse Barnes]

On 08/14/2015 05:44 AM, Daniel Vetter wrote:
 On Thu, Aug 13, 2015 at 01:31:36PM -0700, Jesse Barnes wrote:
 Need some simple vblank coverage in the BAT list.

 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 
 This testcase relies upon fbcon to have enabled pipe 0, which means it
 spuriously skips (when fbcon is disabled or when it's blanked the screen)
 until that's fixed. Same problem happens with drm_read.
 
 Until that's addressed imo Nack for basic igt testcase list. I'll do a
 jira about this issue.

Ok dropped.

Jesse

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

Re: [Intel-gfx] [PATCH 15/18] tests/pm_rpm: mark RTE and D3 tests as basic

[Jesse Barnes]

On 08/14/2015 05:50 AM, Daniel Vetter wrote:
 On Thu, Aug 13, 2015 at 01:31:38PM -0700, Jesse Barnes wrote:
 These always need to pass for basic PM functionality.

 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 ---
  tests/pm_rpm.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
 index d509fa8..7ae5806 100644
 --- a/tests/pm_rpm.c
 +++ b/tests/pm_rpm.c
 @@ -1832,11 +1832,11 @@ int main(int argc, char *argv[])
  stay_subtest();
  
  /* Essential things */
 -igt_subtest(rte)
 +igt_subtest(basic-rte)
 
 I thought our BAT criteria would be basic|rte?
 
 rte is runtime environment check and more along the lines of did QA set
 up their machine correctly, so imo good to keep separate.

I was hoping to keep the BAT in the 'basic' namespace only, so rte tests would 
be included as well, but we'd need to prefix them with basic- too.  Sounds like 
Paulo is ok with that, so I'll keep it here.  Makes test running that much 
simpler. :)

Jesse

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

Re: [Intel-gfx] [PATCH v4 04/11] drm/i915: LVDS pixel clock check

[Lukas Wunner]

Hi Mika,

On Fri, Aug 14, 2015 at 01:03:24PM +0300, Mika Kahola wrote:
 It is possible the we request to have a mode that has
 higher pixel clock than our HW can support. This patch
 checks if requested pixel clock is lower than the one
 supported by the HW. The requested mode is discarded
 if we cannot support the requested pixel clock.
 
 This patch applies to LVDS.

The spec lists maximum dot clocks for each connector type.
Here's the spec for IVB for instance (see section 2.3):
https://01.org/sites/default/files/documentation/ivb_ihd_os_vol3_part4.pdf

E.g. for LVDS it's 224 MHz, for DP it's 270 MHz.
If this is identical across all generations (which I haven't checked,
but seems likely), you can use these constant values, which would be
more accurate than just using the same dev_priv-max_cdclk_freq for
all connector types.

Best regards,

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

[Intel-gfx] [PATCH] drm/i915: Clear PIPE.STAT before IIR on VLV/CHV

[Chris Wilson]

The PIPE.STAT register contains some interrupt status bits per pipe, and
if assert cause the corresponding bit in the IIR to be asserted (thus
raising an interrupt). When handling an interrupt, we should clear the
PIPE.STAT generator first before clearing the IIR so that we do not miss
events or cause spurious work.

This ordering was broken by

commit 27b6c122512ca30399bb1b39cc42eda83901f304
Author: Oscar Mateo oscar.ma...@intel.com
Date:   Mon Jun 16 16:11:00 2014 +0100

drm/i915/chv: Ack interrupts before handling them (CHV)

commit 3ff60f89bc4836583f5bd195062f16c563bd97aa
Author: Oscar Mateo oscar.ma...@intel.com
Date:   Mon Jun 16 16:10:58 2014 +0100

drm/i915/vlv: Ack interrupts before handling them (VLV)

in attempting to reduce the amount of work done between receiving an
interrupt and acknowledging it. In light of this motivation, split the
pipestat interrupt handler into two, one to acknowledge and clear the
interrupt and a later pass to process it.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Oscar Mateo oscar.ma...@intel.com
Cc: Bob Beckett robert.beck...@intel.com
Cc: Imre Deak imre.d...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_irq.c | 55 +++--
 1 file changed, 31 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 66064511cffb..92bdfe6f91d8 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1457,24 +1457,21 @@ static void gen6_rps_irq_handler(struct 
drm_i915_private *dev_priv, u32 pm_iir)
}
 }
 
-static bool intel_pipe_handle_vblank(struct drm_device *dev, enum pipe pipe)
+static inline bool
+intel_pipe_handle_vblank(struct drm_device *dev, enum pipe pipe)
 {
-   if (!drm_handle_vblank(dev, pipe))
-   return false;
-
-   return true;
+   return drm_handle_vblank(dev, pipe);
 }
 
-static void valleyview_pipestat_irq_handler(struct drm_device *dev, u32 iir)
+static void valleyview_pipestat_irq_get(struct drm_i915_private *dev_priv,
+   u32 iir, u32 *pipe_stats)
 {
-   struct drm_i915_private *dev_priv = dev-dev_private;
-   u32 pipe_stats[I915_MAX_PIPES] = { };
int pipe;
 
spin_lock(dev_priv-irq_lock);
for_each_pipe(dev_priv, pipe) {
+   u32 mask, val, iir_bit = 0;
int reg;
-   u32 mask, iir_bit = 0;
 
/*
 * PIPESTAT bits get signalled even when the interrupt is
@@ -1486,6 +1483,7 @@ static void valleyview_pipestat_irq_handler(struct 
drm_device *dev, u32 iir)
 
/* fifo underruns are filterered in the underrun handler. */
mask = PIPE_FIFO_UNDERRUN_STATUS;
+   mask |= PIPESTAT_INT_ENABLE_MASK;
 
switch (pipe) {
case PIPE_A:
@@ -1501,21 +1499,25 @@ static void valleyview_pipestat_irq_handler(struct 
drm_device *dev, u32 iir)
if (iir  iir_bit)
mask |= dev_priv-pipestat_irq_mask[pipe];
 
-   if (!mask)
-   continue;
-
reg = PIPESTAT(pipe);
-   mask |= PIPESTAT_INT_ENABLE_MASK;
-   pipe_stats[pipe] = I915_READ(reg)  mask;
+   val = I915_READ(reg);
+   pipe_stats[pipe] |= val  mask;
 
/*
 * Clear the PIPE*STAT regs before the IIR
 */
-   if (pipe_stats[pipe]  (PIPE_FIFO_UNDERRUN_STATUS |
-   PIPESTAT_INT_STATUS_MASK))
-   I915_WRITE(reg, pipe_stats[pipe]);
+   if (val  (PIPE_FIFO_UNDERRUN_STATUS |
+  PIPESTAT_INT_STATUS_MASK))
+   I915_WRITE(reg, val);
}
spin_unlock(dev_priv-irq_lock);
+}
+
+static void valleyview_pipestat_irq_handler(struct drm_i915_private *dev_priv,
+   u32 *pipe_stats)
+{
+   struct drm_device *dev = dev_priv-dev;
+   int pipe;
 
for_each_pipe(dev_priv, pipe) {
if (pipe_stats[pipe]  PIPE_START_VBLANK_INTERRUPT_STATUS 
@@ -1578,6 +1580,7 @@ static irqreturn_t valleyview_irq_handler(int irq, void 
*arg)
 {
struct drm_device *dev = arg;
struct drm_i915_private *dev_priv = dev-dev_private;
+   u32 pipe_stats[I915_MAX_PIPES] = {};
u32 iir, gt_iir, pm_iir;
irqreturn_t ret = IRQ_NONE;
 
@@ -1600,6 +1603,7 @@ static irqreturn_t valleyview_irq_handler(int irq, void 
*arg)
/* Consume port before clearing IIR or we'll miss 
events */
if (iir  I915_DISPLAY_PORT_INTERRUPT)
i9xx_hpd_irq_handler(dev);
+   valleyview_pipestat_irq_get(dev_priv, iir, pipe_stats);
I915_WRITE(VLV_IIR, iir);
}
 
@@ 

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Adding Panel Filter function for DP

[Ville Syrjälä]

On Fri, Aug 14, 2015 at 05:12:57AM +, Zhang, Xiong Y wrote:
  On Mon, Aug 10, 2015 at 03:26:09PM +0800, Xiong Zhang wrote:
   Only internal eDP, LVDS, DVI screen could set scalling mode, some
   customers need to set scalling mode for external DP, HDMI, VGA screen.
   Let's fulfill this.
  
   bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90989
  
   Signed-off-by: Xiong Zhang xiong.y.zh...@intel.com
   ---
drivers/gpu/drm/i915/intel_dp.c | 63
   -
1 file changed, 44 insertions(+), 19 deletions(-)
  
   diff --git a/drivers/gpu/drm/i915/intel_dp.c
   b/drivers/gpu/drm/i915/intel_dp.c index f1b9f93..2da334b 100644
   --- a/drivers/gpu/drm/i915/intel_dp.c
   +++ b/drivers/gpu/drm/i915/intel_dp.c
   @@ -207,7 +207,13 @@ intel_dp_mode_valid(struct drm_connector
  *connector,
 int target_clock = mode-clock;
 int max_rate, mode_rate, max_lanes, max_link_clock;
  
   - if (is_edp(intel_dp)  fixed_mode) {
   + if (mode-clock  1)
   + return MODE_CLOCK_LOW;
   +
   + if (mode-flags  DRM_MODE_FLAG_DBLCLK)
   + return MODE_H_ILLEGAL;
   +
   + if (!intel_panel_scale_none(intel_connector-panel)) {
 if (mode-hdisplay  fixed_mode-hdisplay)
 return MODE_PANEL;
  
   @@ -226,12 +232,6 @@ intel_dp_mode_valid(struct drm_connector
  *connector,
 if (mode_rate  max_rate)
 return MODE_CLOCK_HIGH;
  
   - if (mode-clock  1)
   - return MODE_CLOCK_LOW;
   -
   - if (mode-flags  DRM_MODE_FLAG_DBLCLK)
   - return MODE_H_ILLEGAL;
   -
 return MODE_OK;
}
  
   @@ -1378,7 +1378,7 @@ intel_dp_compute_config(struct intel_encoder
  *encoder,
 pipe_config-has_drrs = false;
 pipe_config-has_audio = intel_dp-has_audio  port != PORT_A;
  
   - if (is_edp(intel_dp)  intel_connector-panel.fixed_mode) {
   + if (!intel_panel_scale_none(intel_connector-panel)) {
 intel_fixed_panel_mode(intel_connector-panel.fixed_mode,
adjusted_mode);
  
   @@ -4592,6 +4592,23 @@ static int intel_dp_get_modes(struct
  drm_connector *connector)
 edid = intel_connector-detect_edid;
 if (edid) {
 int ret = intel_connector_update_modes(connector, edid);
   +
   + if (ret  intel_connector-panel.fixed_mode == NULL) {
   + /* init fixed mode as preferred mode for DP */
   + struct drm_display_mode *fixed_mode = NULL;
   + struct drm_display_mode *scan;
   +
   + list_for_each_entry(scan, connector-probed_modes, 
   head) {
   + if (scan-type  DRM_MODE_TYPE_PREFERRED)
   + fixed_mode = 
   drm_mode_duplicate(connector-dev,
   + scan);
   + }
   +
   + if (fixed_mode)
   + intel_panel_init(intel_connector-panel,
   +  fixed_mode, NULL);
   + }
  
  How are we supposed to get rid of a stale fixed_mode when some other
  display gets plugged in?
 [Zhang, Xiong Y] Thanks so much for your good question. Yes, we should clear 
 the
 stale fitting_mode and fixed_mode when display is disconnect in 
 intel_dp_hpd_pulse() function.
  
  Also what would happen if the preferred mode can't be supported due to some
  source limitation?
 [Zhang, Xiong Y] In this case, which mode should be selected as fixed_mode ?

At the very least we should make sure it's a mode we can use.

 As you said maybe kernel isn't the right place to do such decision.

There are a lot of options how we could pick the mode. Eg. might want to
pick the next largest mode, and if there is none try to pick the largest
smaller mode (since pfit can't downscale by much). Also should we try to
pick an intelaced mode if the user requested one etc. Lots of open
questions how this policy should be handled. Would be easier to punt it
all to userspace, which would also avoid the kernel policy doing the
wrong thing when userspace knows what it wants.

  
  In general I'm not entirely happy with having this kind of policy in the 
  kernel.
  I'd much prefer if we could get crtc size and border properties done so that
  userspace could set up the scaling any which way it chooses.
 [Zhang, Xiong Y] Could you give more detail about your preference ?

The idea would be to expose some sort of crtc size properties that would
provide pipe_src_{w,h}, and the mode would provide the actual display
timings as it does today. And if we add some kind of border properties
to control the output size of the pfit (since the mode doesn't have that
information) userspace could do whatever it pleased.

I think the last attempt just sort of died out during review:
http://lists.freedesktop.org/archives/intel-gfx/2014-August/050732.html

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

Re: [Intel-gfx] [PATCH 06/18] tests/drv_suspend: mark sysfs tests as basic

[Jesse Barnes]

On 08/14/2015 09:01 AM, Daniel Vetter wrote:
 On Fri, Aug 14, 2015 at 08:29:40AM -0700, Jesse Barnes wrote:
 On 08/14/2015 05:29 AM, Daniel Vetter wrote:
 On Thu, Aug 13, 2015 at 01:31:29PM -0700, Jesse Barnes wrote:
 debugfs may not be mounted, but sysfs should always be restored after
 suspend or hibernate.

 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org

 We already have a suspend/resume testcase in kms_pipc_crc_basic. Do we
 have enough budget for this one?

 Yeah I thought about getting rid of the suspend/resume ones in pipe_crc
 (marking them as non-basic), since I really just want the one set of
 tests.  Any preference?
 
 Imo crc is such a basic (hah!) validation tool that we really should try
 to run all the corner cases. Otherwise we have ugly situations where some
 tests randomyl fail, depending upon when they've been run after system
 suspend/resume or not. And with all our troubles we need to reboot a few
 times for a full run, so this is likely.
 
 This actually happened (that's why we have these tests) and resulted in
 lots and lots of wtf until resolved. So yeah I think for crc we really
 want them all, even if it's a bit expensive, since if we don't there's a
 good chance for lots of flaky test results. And that's the prime problem
 we have with igt.

Ok sounds good, I'll drop the drv_suspend test then.

Jesse

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

Re: [Intel-gfx] [PATCH 0/4] Add support for Hyperlinks and Markup on kernel-doc

[Danilo Cesar Lemes de Paula]

On 08/13/2015 08:20 PM, Jonathan Corbet wrote:
 On Thu, 13 Aug 2015 20:09:35 -0300
 Danilo Cesar Lemes de Paula danilo.ce...@collabora.co.uk wrote:
 
 Did you find time to take a look on this?
 
 No.  Just when I thought things couldn't get crazier, my laptop died.  
 
   https://plus.google.com/+JonathanCorbet/posts/FBHp48dPb95
 
 What spare time I had has been dedicated to recovering from that in time
 to give my talk next week.

Those evil machines... =)

  
 I understand that there's some discussion behind the curtains regarding
 the markdown support, but the cross-reference-hyperlink patch is also in
 the same patch series. It doesn't change any text in the docbook unless
 there's really a cross-reference link to it. Different from the markdown
 support (when people start to use markdown to write docs it will be hard
 to go back), the cross-link stuff doesn't require/create any change to
 current documentation, it is pretty safe to use.

 Would you mind to share your plans about this?
 
 No behind-the-curtains discussions happening, or, let's say, if there
 are, I've not been invited either.

I meant the Kernel summit mailing list, but looks like that thread died
even before my patches.

 
 I'd like to get back to the cross-reference stuff.  Last I tried, it
 failed while building the media docs; have you been able to look at
 that?  

I did, and I didn't find anything.
Media API already spits lots of warnings without my patch. I did send
those warnings to a file and count them. My patch produces the same
amount of warnings as the original branch.
I did, however, use a clean build to test that. Daniel Vetter complained
that the Documentation was being rebuilt all the time, something wrong
with the dependencies. I did fix that in v2. Maybe the errors you got
were related to it?


 
 Longer term, as you may know from the kernel summit discussions, I'd
 really like to get rid of a lot of the XML gunk and put in something more
 straightforward, be it based on Markdown or something else.  Doing that,
 however, requires that I find the time to implement something that's
 convincingly better.  It may happen soon, but I sure can't guarantee it.
 
 Meanwhile, I think it would be a horrible mistake to delay useful work
 because I have a gleam in my eye to do something different one of these
 years, so I'll not do that.  I fully expect to merge all of the stuff
 you've done, I just need to have a good look at it and test it out a
 bit.  As I said before, I can't promise that for the 4.3 merge window,
 but I'll try.
 
 Apologies,

No need to apologize, just wanted to know what was going on.

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

Re: [Intel-gfx] [PATCH] drm/core: Set mode to NULL when connectors in a set drops to 0.

[shuang . he]

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
Task id: 7142
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
ILK -2  302/302  300/302
SNB  315/315  315/315
IVB  336/336  336/336
BYT -2  283/283  281/283
HSW  378/378  378/378
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
*ILK  igt@kms_flip@flip-vs-dpms-interruptible  PASS(1)  DMESG_WARN(1)
*ILK  igt@kms_flip@wf_vblank-vs-modeset-interruptible  PASS(1)  
DMESG_WARN(1)
*BYT  igt@gem_partial_pwrite_pread@reads-uncached  PASS(1)  FAIL(1)
*BYT  igt@gem_tiled_partial_pwrite_pread@writes-after-reads  PASS(1)  
FAIL(1)
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] drm-intel-next

[Daniel Vetter]

Hi Dave,

drm-intel-next-2015-07-31:
- kerneldoc for tiling/swizzling/fencing code
- bxt hpd port A w/a
- various other fixes all over

... not much, everyone's on vacation.

Cheers, Daniel


The following changes since commit e0548f1979bfee900fb0671a5dd3a2f217dce5df:

  drm/i915: Update DRIVER_DATE to 20150717 (2015-07-17 22:24:32 +0200)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2015-07-31

for you to fetch changes up to 5d8a0d0b44c207690adda723b8d60158c18fec8a:

  drm/i915: Update DRIVER_DATE to 20150731 (2015-07-31 09:52:56 +0200)


- kerneldoc for tiling/swizzling/fencing code
- bxt hpd port A w/a
- various other fixes all over

... not much, everyone's on vacation.


Alex Dai (1):
  drm/i915: Add GuC-related module parameters

Arun Siluvery (1):
  drm/i915: Add provision to extend Golden context batch

Chris Wilson (1):
  drm/i915: Keep the mm.bound_list in rough LRU order

Daniel Vetter (9):
  Partially revert drm/i915: s/mdelay/msleep/ in ilk rps code
  drm/i915: Clean up Makefile
  drm/i915: Extract i915_gem_fence.c
  drm/i915: kerneldoc for fences
  drm/i915: Remove bogus kerneldoc include directive
  drm/i915: Move low-level swizzling code to i915_gem_fence.c
  drm/i915: kerneldoc for tiling IOCTL and swizzle functions
  drm/i915: Fake AGP is dead
  drm/i915: Update DRIVER_DATE to 20150731

Dave Gordon (2):
  drm/i915: Add i915_gem_object_create_from_data()
  drm/i915: Add GuC-related header files

Hanno Böck (2):
  drm/i915: Properly sort MI coomand table
  drm/i915: Fix command parser table validator

Imre Deak (3):
  drm/i915: combine i9xx_get_hpd_pins and pch_get_hpd_pins
  drm/i915: don't use HPD_PORT_A as an alias for HPD_NONE
  drm/i915/bxt: add support for HPD long/short pulse detection on 
HPD_PORT_A pin

Mika Kuoppala (1):
  drm/i915: Do kunmap if renderstate parsing fails

Rodrigo Vivi (2):
  drm/i915: Try to stop sink crc calculation on error.
  drm/i915: Don't return error on sink crc stop.

Sudip Mukherjee (2):
  drm/i915: remove unnecessary null test
  drm/i915: remove redundant if check

 Documentation/DocBook/drm.tmpl   |  18 +-
 drivers/gpu/drm/i915/Makefile|  19 +-
 drivers/gpu/drm/i915/i915_cmd_parser.c   |   4 +-
 drivers/gpu/drm/i915/i915_debugfs.c  |  25 +-
 drivers/gpu/drm/i915/i915_dma.c  |  10 -
 drivers/gpu/drm/i915/i915_drv.c  |   4 -
 drivers/gpu/drm/i915/i915_drv.h  |  35 +-
 drivers/gpu/drm/i915/i915_gem.c  | 448 ++-
 drivers/gpu/drm/i915/i915_gem_fence.c| 787 +++
 drivers/gpu/drm/i915/i915_gem_render_state.c |  55 +-
 drivers/gpu/drm/i915/i915_gem_render_state.h |   2 +
 drivers/gpu/drm/i915/i915_gem_tiling.c   | 303 ++-
 drivers/gpu/drm/i915/i915_guc_reg.h  | 102 
 drivers/gpu/drm/i915/i915_irq.c  |  77 ++-
 drivers/gpu/drm/i915/i915_params.c   |   9 +
 drivers/gpu/drm/i915/i915_reg.h  |   5 +
 drivers/gpu/drm/i915/intel_dp.c  |  13 +-
 drivers/gpu/drm/i915/intel_guc_fwif.h| 245 +
 drivers/gpu/drm/i915/intel_hotplug.c |  20 +-
 drivers/gpu/drm/i915/intel_lrc.c |   6 +
 drivers/gpu/drm/i915/intel_pm.c  |   6 +-
 21 files changed, 1409 insertions(+), 784 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_gem_fence.c
 create mode 100644 drivers/gpu/drm/i915/i915_guc_reg.h
 create mode 100644 drivers/gpu/drm/i915/intel_guc_fwif.h

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

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/bxt: don't allow cached GEM mappings on A stepping

[Chris Wilson]

On Fri, Aug 14, 2015 at 06:43:30PM +0300, Imre Deak wrote:
 Due to a coherency issue on BXT A steppings we can't guarantee a
 coherent view of cached (CPU snooped) GPU mappings, so fail such
 requests. User space is supposed to fall back to uncached mappings in
 this case.
 
 v2:
 - limit the WA to A steppings, on later stepping this HW issue is fixed
 v3:
 - return error instead of trying to work around the issue in kernel,
   since that could confuse user space (Chris)
 
 Testcast: igt/gem_store_dword_batches_loop/cached-mapping
 Signed-off-by: Imre Deak imre.d...@intel.com

I checked in the two userspaces where I have used snooping that both
handle an error correctly, so

Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
-Chris

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

Re: [Intel-gfx] [PATCH 16/18] tests/kms_flip: add basic tests for flip, flip vs dpms, and flip modeset

[Jesse Barnes]

On 08/14/2015 05:56 AM, Daniel Vetter wrote:
 On Thu, Aug 13, 2015 at 01:31:39PM -0700, Jesse Barnes wrote:
 Simple variants that don't do multiple output or interruptible testing.

 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 ---
  tests/kms_flip.c | 11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)

 diff --git a/tests/kms_flip.c b/tests/kms_flip.c
 index a595d9f..a0e4112 100644
 --- a/tests/kms_flip.c
 +++ b/tests/kms_flip.c
 @@ -80,6 +80,7 @@
  #define TEST_TS_CONT(1  27)
  #define TEST_BO_TOOBIG  (1  28)
  #define TEST_HANG_ONCE  (1  29)
 +#define TEST_BASIC  (1  30)
  
  #define EVENT_FLIP  (1  0)
  #define EVENT_VBLANK(1  1)
 @@ -1649,7 +1650,7 @@ int main(int argc, char **argv)
  blt-wf_vblank-vs-modeset },
  { 60,  TEST_VBLANK | TEST_MODESET | TEST_WITH_DUMMY_RCS,
  rcs-wf_vblank-vs-modeset },
 -
 +{ 30, TEST_FLIP | TEST_BASIC, basic-plain-flip },
 
 I think for better coverage we should pick the timestamp checking ones
 here. Also we need one to cover vblank since kms_vblank can't be used. And
 we can do that all in one testcases to save testing time!
 
  { 30, TEST_FLIP , plain-flip },
  { 30, TEST_FLIP | TEST_EBUSY , busy-flip },
  { 30, TEST_FLIP | TEST_FENCE_STRESS , flip-vs-fences },
 @@ -1657,12 +1658,14 @@ int main(int argc, char **argv)
  { 30, TEST_FLIP | TEST_CHECK_TS | TEST_FB_RECREATE,
  plain-flip-fb-recreate },
  { 30, TEST_FLIP | TEST_RMFB | TEST_MODESET , flip-vs-rmfb },
 +{ 60, TEST_FLIP | TEST_DPMS | TEST_EINVAL | TEST_BASIC, 
 basic-flip-vs-dpms },
  { 60, TEST_FLIP | TEST_DPMS | TEST_EINVAL, flip-vs-dpms },
  { 60, TEST_FLIP | TEST_DPMS | TEST_WITH_DUMMY_BCS, 
 blt-flip-vs-dpms },
  { 60, TEST_FLIP | TEST_DPMS | TEST_WITH_DUMMY_RCS, 
 render-flip-vs-dpms },
  { 30,  TEST_FLIP | TEST_PAN, flip-vs-panning },
  { 60, TEST_FLIP | TEST_PAN | TEST_WITH_DUMMY_BCS, 
 blt-flip-vs-panning },
  { 60, TEST_FLIP | TEST_PAN | TEST_WITH_DUMMY_RCS, 
 render-flip-vs-panning },
 +{ 60, TEST_FLIP | TEST_MODESET | TEST_EINVAL | TEST_BASIC, 
 basic-flip-vs-modeset },
  { 60, TEST_FLIP | TEST_MODESET | TEST_EINVAL, flip-vs-modeset 
 },
  { 60, TEST_FLIP | TEST_MODESET | TEST_WITH_DUMMY_BCS, 
 blt-flip-vs-modeset },
  { 60, TEST_FLIP | TEST_MODESET | TEST_WITH_DUMMY_RCS, 
 render-flip-vs-modeset },
 @@ -1721,6 +1724,9 @@ int main(int argc, char **argv)
  igt_subtest(tests[i].name)
  run_test(tests[i].duration, tests[i].flags);
  
 +if (tests[i].flags  TEST_BASIC)
 +continue;
 
 This means you remove the tests you marked as BASIC from the 2x and
 interruptible sets. What about instead adding the basic prefix at runtime,
 i.e. for all my requests:
 diff --git a/tests/kms_flip.c b/tests/kms_flip.c
 index a595d9f1d69f..aaf03b07df87 100644
 --- a/tests/kms_flip.c
 +++ b/tests/kms_flip.c
 @@ -80,6 +80,7 @@
  #define TEST_TS_CONT (1  27)
  #define TEST_BO_TOOBIG   (1  28)
  #define TEST_HANG_ONCE   (1  29)
 +#define TEST_BASIC   (1  31)
  
  #define EVENT_FLIP   (1  0)
  #define EVENT_VBLANK (1  1)
 @@ -1650,20 +1651,20 @@ int main(int argc, char **argv)
   { 60,  TEST_VBLANK | TEST_MODESET | TEST_WITH_DUMMY_RCS,
   rcs-wf_vblank-vs-modeset },
  
 - { 30, TEST_FLIP , plain-flip },
 + { 30, TEST_FLIP, plain-flip },
   { 30, TEST_FLIP | TEST_EBUSY , busy-flip },
   { 30, TEST_FLIP | TEST_FENCE_STRESS , flip-vs-fences },
   { 30, TEST_FLIP | TEST_CHECK_TS, plain-flip-ts-check },
   { 30, TEST_FLIP | TEST_CHECK_TS | TEST_FB_RECREATE,
   plain-flip-fb-recreate },
   { 30, TEST_FLIP | TEST_RMFB | TEST_MODESET , flip-vs-rmfb },
 - { 60, TEST_FLIP | TEST_DPMS | TEST_EINVAL, flip-vs-dpms },
 + { 60, TEST_FLIP | TEST_DPMS | TEST_EINVAL | TEST_BASIC, 
 flip-vs-dpms },
   { 60, TEST_FLIP | TEST_DPMS | TEST_WITH_DUMMY_BCS, 
 blt-flip-vs-dpms },
   { 60, TEST_FLIP | TEST_DPMS | TEST_WITH_DUMMY_RCS, 
 render-flip-vs-dpms },
   { 30,  TEST_FLIP | TEST_PAN, flip-vs-panning },
   { 60, TEST_FLIP | TEST_PAN | TEST_WITH_DUMMY_BCS, 
 blt-flip-vs-panning },
   { 60, TEST_FLIP | TEST_PAN | TEST_WITH_DUMMY_RCS, 
 render-flip-vs-panning },
 - { 60, TEST_FLIP | TEST_MODESET | TEST_EINVAL, flip-vs-modeset 
 },
 + { 60, TEST_FLIP | TEST_MODESET | TEST_EINVAL | TEST_BASIC, 
 flip-vs-modeset },
   { 60, TEST_FLIP | TEST_MODESET | TEST_WITH_DUMMY_BCS, 
 

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/bxt: work around HW coherency issue when accessing GPU seqno

[Chris Wilson]

On Fri, Aug 14, 2015 at 06:35:27PM +0300, Imre Deak wrote:
 By running igt/store_dword_loop_render on BXT we can hit a coherency
 problem where the seqno written at GPU command completion time is not
 seen by the CPU. This results in __i915_wait_request seeing the stale
 seqno and not completing the request (not considering the lost
 interrupt/GPU reset mechanism). I also verified that this isn't a case
 of a lost interrupt, or that the command didn't complete somehow: when
 the coherency issue occured I read the seqno via an uncached GTT mapping
 too. While the cached version of the seqno still showed the stale value
 the one read via the uncached mapping was the correct one.
 
 Work around this issue by clflushing the corresponding CPU cacheline
 following any store of the seqno and preceding any reading of it. When
 reading it do this only when the caller expects a coherent view.
 
 v2:
 - fix using the proper logical  instead of a bitwise  (Jani, Mika)
 - limit the workaround to A stepping, on later steppings this HW issue
   is fixed
 v3:
 - use a separate get_seqno/set_seqno vfunc (Chris)
 
 Testcase: igt/store_dword_loop_render
 Signed-off-by: Imre Deak imre.d...@intel.com

I'm not going to quibble about the whitespace or the code duplication
that isn't your fault...

Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
-Chris

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

Re: [Intel-gfx] [PATCH 18/18] gitignore: ignore more files

[Jesse Barnes]

On 08/14/2015 09:07 AM, Daniel Vetter wrote:
 On Fri, Aug 14, 2015 at 08:20:22AM -0700, Jesse Barnes wrote:
 git clean updates the .gitignore file?  Not having to run git clean is the 
 whole point of this patch...
 
 I looked at this patch first, but later noticed that you have a few
 renames where you don't update the .gitignore.

 On 08/14/2015 01:09 AM, Daniel Vetter wrote:
 On Thu, Aug 13, 2015 at 01:31:41PM -0700, Jesse Barnes wrote:

 git clean fixes this all, at least over here git status is clean.
 -Daniel

 ---
  .gitignore   |  3 +++
  tests/.gitignore | 13 +
  tools/.gitignore |  8 
  3 files changed, 24 insertions(+)

 diff --git a/.gitignore b/.gitignore
 index a438c1c..533f6f1 100644
 --- a/.gitignore
 +++ b/.gitignore
 @@ -90,3 +90,6 @@ gtk-doc.m4
  
  piglit
  results
 +
 +*.orig
 +version.h
 diff --git a/tests/.gitignore b/tests/.gitignore
 index 31d35a5..e45cbb7 100644
 --- a/tests/.gitignore
 +++ b/tests/.gitignore
 @@ -99,6 +99,7 @@ gem_set_tiling_vs_blt
  gem_set_tiling_vs_gtt
  gem_set_tiling_vs_pwrite
  gem_storedw_batches_loop
 +gem_storedw_loop
  gem_storedw_loop_blt
  gem_storedw_loop_bsd
  gem_storedw_loop_render
 @@ -169,3 +170,15 @@ prime_udl
  template
  test-list.txt
  testdisplay
 +ddi_compute_wrpll
 +gem_vmap_blits
 +gem_wait_render_timeout
 +igt_fork_helper
 +igt_list_only
 +igt_no_exit
 +igt_no_exit_list_only
 +igt_no_subtest
 +igt_simulation
 
 But all the igt_* have moved to lib/tests/ so you definitely have a pile
 of old build system gunk that needs to be cleaned out first with git
 clean.
 
 +pm_pc8
 +pm_psr
 +
 diff --git a/tools/.gitignore b/tools/.gitignore
 index 49bd24f..7bf91e3 100644
 --- a/tools/.gitignore
 +++ b/tools/.gitignore
 @@ -37,3 +37,11 @@ intel_vga_write
  intel_watermark
  skl_compute_wrpll
  skl_ddb_allocation
 +forcewaked
 +intel_dpio_read
 +intel_dpio_write
 +intel_gpu_dump
 +intel_nc_read
 +intel_nc_write
 +intel_punit_read
 +intel_punit_write
 
 Same with those, Jani killed them all iirc.

ah ok, I can drop those.  I'll clean and such and just add the minimal set here.

Jesse

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

Re: [Intel-gfx] [PATCH v3 4/4] drm/i915/chv: Ack interrupts before handling them (CHV)

[Chris Wilson]

On Mon, Jun 16, 2014 at 04:11:00PM +0100, oscar.ma...@intel.com wrote:
 From: Oscar Mateo oscar.ma...@intel.com
 
 Otherwise, we might receive a new interrupt before we have time to
 ack the first one, eventually missing it.
 
 Without an atomic XCHG operation with mmio space, this patch merely
 reduces the window in which we can miss an interrupt (especially when
 you consider how heavyweight the I915_READ/I915_WRITE operations are).
 
 Notice that, before clearing a port-sourced interrupt in the IIR, the
 corresponding interrupt source status in the PORT_HOTPLUG_STAT must be
 cleared.
 
 Spotted by Bob Beckett robert.beck...@intel.com.
 
 v2:
 - Add warning to commit message and comments to the code as per Chris
   Wilson's request.
 - Imre Deak pointed out that the pipe underrun flag might not be signaled
   in IIR, so do not make valleyview_pipestat_irq_handler depend on it.
 
 v3: Improve the source code comment.

The code still talks about the necessity of clearing the PIPESTAT
interrupt generators before resetting IIR, and since it is clearly doing
so for the hpd interrupt, it probably should do so for the others. This
patch introduces a regression in how we handle PIPESTAT on CHV (+VLV
earlier).
-Chris

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

[Intel-gfx] [PATCH 16/16] drm/i915: reject invalid formats for FBC

[Paulo Zanoni]

This commit is essentially a rewrite of drm/i915: Check pixel format
for fbc from Ville Syrjälä. The idea is the same, but the code is
different due to all the changes that happened since his original
patch. So any bugs are due to my bad rewrite.

Testcases: igt/kms_frontbuffer_tracking/*fbc*-${format_name}-draw-*
Credits-to: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_fbc.c | 35 +++
 2 files changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f8f3ed3..938f69f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -947,6 +947,7 @@ struct i915_fbc {
FBC_IN_DBG_MASTER, /* kernel debugger is active */
FBC_BAD_STRIDE, /* stride is not supported */
FBC_PIXEL_RATE, /* pixel rate is too big */
+   FBC_PIXEL_FORMAT /* pixel format is invalid */
} no_fbc_reason;
 
bool (*fbc_enabled)(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 5dfe460..cd3ed90 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -505,6 +505,8 @@ const char *intel_no_fbc_reason_str(enum no_fbc_reason 
reason)
return framebuffer stride not supported;
case FBC_PIXEL_RATE:
return pixel rate is too big;
+   case FBC_PIXEL_FORMAT:
+   return pixel format is invalid;
default:
MISSING_CASE(reason);
return unknown reason;
@@ -731,6 +733,34 @@ static bool stride_is_valid(unsigned int stride)
return true;
 }
 
+static bool pixel_format_is_valid(struct drm_framebuffer *fb)
+{
+   struct drm_device *dev = fb-dev;
+   struct drm_i915_private *dev_priv = dev-dev_private;
+
+   /* Primary planes don't support alpha, so the A formats and X
+* formats are one and the same. */
+   switch (fb-pixel_format) {
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_ABGR:
+   return true;
+   case DRM_FORMAT_XRGB1555:
+   case DRM_FORMAT_ARGB1555:
+   case DRM_FORMAT_RGB565:
+   /* 16bpp not supported on gen2 */
+   if (IS_GEN2(dev))
+   return false;
+   /* WaFbcOnly1to1Ratio:ctg */
+   if (IS_G4X(dev_priv))
+   return false;
+   return true;
+   default:
+   return false;
+   }
+}
+
 /**
  * __intel_fbc_update - enable/disable FBC as needed, unlocked
  * @dev_priv: i915 device instance
@@ -846,6 +876,11 @@ static void __intel_fbc_update(struct drm_i915_private 
*dev_priv)
goto out_disable;
}
 
+   if (!pixel_format_is_valid(fb)) {
+   set_no_fbc_reason(dev_priv, FBC_PIXEL_FORMAT);
+   goto out_disable;
+   }
+
/* If the kernel debugger is active, always disable compression */
if (in_dbg_master()) {
set_no_fbc_reason(dev_priv, FBC_IN_DBG_MASTER);
-- 
2.4.6

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

[Intel-gfx] [PATCH 03/16] drm/i915: fix FBC for cases where crtc-base.y is non-zero

[Paulo Zanoni]

I only tested this on BDW, but since the register description is the
same ever since gen4, let's assume that all gens take the same
register format. If that's not true, then hopefully someone will
bisect a bug to this patch and we'll fix it.

Notice that the wrong fence offset register just means that the
hardware tracking will be wrong.

Testcases:
 - igt/kms_frontbuffer_tracking/fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt
 - igt/kms_frontbuffer_tracking/fbc-2p-primscrn-pri-shrfb-draw-mmap-gtt

Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
 drivers/gpu/drm/i915/intel_fbc.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index fa9b004..9ffa7dc 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -64,6 +64,20 @@ static void i8xx_fbc_disable(struct drm_i915_private 
*dev_priv)
DRM_DEBUG_KMS(disabled FBC\n);
 }
 
+static unsigned int get_crtc_fence_y_offset(struct intel_crtc *crtc)
+{
+   struct drm_i915_private *dev_priv = crtc-base.dev-dev_private;
+   struct drm_framebuffer *fb = crtc-base.primary-fb;
+   unsigned int tile_height;
+
+   tile_height = intel_tile_height(dev_priv-dev, fb-pixel_format,
+   fb-modifier[0]);
+
+   /* The value we want is the line number of the first tile that contains
+* the first vertical line of the CRTC. */
+   return crtc-base.y - (crtc-base.y % tile_height);
+}
+
 static void i8xx_fbc_enable(struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = crtc-base.dev-dev_private;
@@ -97,7 +111,7 @@ static void i8xx_fbc_enable(struct intel_crtc *crtc)
fbc_ctl2 = FBC_CTL_FENCE_DBL | FBC_CTL_IDLE_IMM | 
FBC_CTL_CPU_FENCE;
fbc_ctl2 |= FBC_CTL_PLANE(crtc-plane);
I915_WRITE(FBC_CONTROL2, fbc_ctl2);
-   I915_WRITE(FBC_FENCE_OFF, crtc-base.y);
+   I915_WRITE(FBC_FENCE_OFF, get_crtc_fence_y_offset(crtc));
}
 
/* enable it... */
@@ -135,7 +149,7 @@ static void g4x_fbc_enable(struct intel_crtc *crtc)
dpfc_ctl |= DPFC_CTL_LIMIT_1X;
dpfc_ctl |= DPFC_CTL_FENCE_EN | obj-fence_reg;
 
-   I915_WRITE(DPFC_FENCE_YOFF, crtc-base.y);
+   I915_WRITE(DPFC_FENCE_YOFF, get_crtc_fence_y_offset(crtc));
 
/* enable it... */
I915_WRITE(DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN);
@@ -177,6 +191,7 @@ static void ilk_fbc_enable(struct intel_crtc *crtc)
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
u32 dpfc_ctl;
int threshold = dev_priv-fbc.threshold;
+   unsigned int y_offset;
 
dev_priv-fbc.enabled = true;
 
@@ -200,7 +215,8 @@ static void ilk_fbc_enable(struct intel_crtc *crtc)
if (IS_GEN5(dev_priv))
dpfc_ctl |= obj-fence_reg;
 
-   I915_WRITE(ILK_DPFC_FENCE_YOFF, crtc-base.y);
+   y_offset = get_crtc_fence_y_offset(crtc);
+   I915_WRITE(ILK_DPFC_FENCE_YOFF, y_offset);
I915_WRITE(ILK_FBC_RT_BASE, i915_gem_obj_ggtt_offset(obj) | 
ILK_FBC_RT_VALID);
/* enable it... */
I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN);
@@ -208,7 +224,7 @@ static void ilk_fbc_enable(struct intel_crtc *crtc)
if (IS_GEN6(dev_priv)) {
I915_WRITE(SNB_DPFC_CTL_SA,
   SNB_CPU_FENCE_ENABLE | obj-fence_reg);
-   I915_WRITE(DPFC_CPU_FENCE_OFFSET, crtc-base.y);
+   I915_WRITE(DPFC_CPU_FENCE_OFFSET, y_offset);
}
 
intel_fbc_nuke(dev_priv);
@@ -288,7 +304,7 @@ static void gen7_fbc_enable(struct intel_crtc *crtc)
 
I915_WRITE(SNB_DPFC_CTL_SA,
   SNB_CPU_FENCE_ENABLE | obj-fence_reg);
-   I915_WRITE(DPFC_CPU_FENCE_OFFSET, crtc-base.y);
+   I915_WRITE(DPFC_CPU_FENCE_OFFSET, get_crtc_fence_y_offset(crtc));
 
intel_fbc_nuke(dev_priv);
 
-- 
2.4.6

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

[Intel-gfx] [PATCH 12/16] drm/i915: apply WaFbcAsynchFlipDisableFbcQueue earlier

[Paulo Zanoni]

The spec says the register should have that value for the entire time
that FBC is enabled, so apply the WA before we enable FBC.

Notice that we also have this WA for ILK/SNB, but it is implemented at
init_clock_gating(). I could move the IVB/HSW/BDW WA code to
init_clock_gating() too, but since we recently had some complaints
about WAs not staying after being set, I'm going to play safe and keep
this here for now.

Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
 drivers/gpu/drm/i915/intel_fbc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 9dee0b5..b76c19f 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -293,8 +293,6 @@ static void gen7_fbc_enable(struct intel_crtc *crtc)
if (dev_priv-fbc.false_color)
dpfc_ctl |= FBC_CTL_FALSE_COLOR;
 
-   I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN);
-
if (IS_IVYBRIDGE(dev_priv)) {
/* WaFbcAsynchFlipDisableFbcQueue:ivb */
I915_WRITE(ILK_DISPLAY_CHICKEN1,
@@ -307,6 +305,8 @@ static void gen7_fbc_enable(struct intel_crtc *crtc)
   HSW_FBCQ_DIS);
}
 
+   I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN);
+
I915_WRITE(SNB_DPFC_CTL_SA,
   SNB_CPU_FENCE_ENABLE | obj-fence_reg);
I915_WRITE(DPFC_CPU_FENCE_OFFSET, get_crtc_fence_y_offset(crtc));
-- 
2.4.6

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

[Intel-gfx] [PATCH 11/16] drm/i915/bdw: don't enable FBC when pixel rate exceeds 95%

[Paulo Zanoni]

BSpec says we shouldn't enable FBC on BDW when the pipe pixel rate
exceeds 95% of the core display clock.

Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
 drivers/gpu/drm/i915/i915_drv.h  | 1 +
 drivers/gpu/drm/i915/intel_fbc.c | 8 
 2 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f44d101..f8f3ed3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -946,6 +946,7 @@ struct i915_fbc {
FBC_ROTATION, /* rotation is not supported */
FBC_IN_DBG_MASTER, /* kernel debugger is active */
FBC_BAD_STRIDE, /* stride is not supported */
+   FBC_PIXEL_RATE, /* pixel rate is too big */
} no_fbc_reason;
 
bool (*fbc_enabled)(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index cfd4cba..9dee0b5 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -503,6 +503,8 @@ const char *intel_no_fbc_reason_str(enum no_fbc_reason 
reason)
return Kernel debugger is active;
case FBC_BAD_STRIDE:
return framebuffer stride not supported;
+   case FBC_PIXEL_RATE:
+   return pixel rate is too big;
default:
MISSING_CASE(reason);
return unknown reason;
@@ -850,6 +852,12 @@ static void __intel_fbc_update(struct drm_i915_private 
*dev_priv)
goto out_disable;
}
 
+   if (IS_BROADWELL(dev_priv)  ilk_pipe_pixel_rate(intel_crtc-config) =
+   dev_priv-max_cdclk_freq * 95 / 100) {
+   set_no_fbc_reason(dev_priv, FBC_PIXEL_RATE);
+   goto out_disable;
+   }
+
if (intel_fbc_setup_cfb(intel_crtc)) {
set_no_fbc_reason(dev_priv, FBC_STOLEN_TOO_SMALL);
goto out_disable;
-- 
2.4.6

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

[Intel-gfx] [PATCH 09/16] drm/i915: print the correct amount of bytes allocated for the CFB

[Paulo Zanoni]

And also print the threshold. I was surprised to see a log message
claiming the CFB size was 32mb when there was less than 24mb available
for it.

Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
 drivers/gpu/drm/i915/intel_fbc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 9fd7b74..dc84e67 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -655,8 +655,9 @@ static int intel_fbc_alloc_cfb(struct drm_i915_private 
*dev_priv, int size,
 
dev_priv-fbc.uncompressed_size = size;
 
-   DRM_DEBUG_KMS(reserved %d bytes of contiguous stolen space for FBC\n,
- size);
+   DRM_DEBUG_KMS(reserved %llu bytes of contiguous stolen space for FBC, 
threshold: %d\n,
+ dev_priv-fbc.compressed_fb.size,
+ dev_priv-fbc.threshold);
 
return 0;
 
-- 
2.4.6

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

[Intel-gfx] [PATCH 02/16] drm/i915: fix the FBC work allocation failure path

[Paulo Zanoni]

Always update the currrent crtc, fb and vertical offset after calling
enable_fbc. We were forgetting to do so along the failure paths when
enabling fbc synchronously. Fix this with a new helper to enable_fbc()
and update the state simultaneously.

v2: Improve commit message (Chris).

Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
 drivers/gpu/drm/i915/intel_fbc.c | 27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index c97aba2..fa9b004 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -308,6 +308,18 @@ bool intel_fbc_enabled(struct drm_i915_private *dev_priv)
return dev_priv-fbc.enabled;
 }
 
+static void intel_fbc_enable(struct intel_crtc *crtc,
+struct drm_framebuffer *fb)
+{
+   struct drm_i915_private *dev_priv = crtc-base.dev-dev_private;
+
+   dev_priv-fbc.enable_fbc(crtc);
+
+   dev_priv-fbc.crtc = crtc;
+   dev_priv-fbc.fb_id = fb-base.id;
+   dev_priv-fbc.y = crtc-base.y;
+}
+
 static void intel_fbc_work_fn(struct work_struct *__work)
 {
struct intel_fbc_work *work =
@@ -321,13 +333,8 @@ static void intel_fbc_work_fn(struct work_struct *__work)
/* Double check that we haven't switched fb without cancelling
 * the prior work.
 */
-   if (crtc_fb == work-fb) {
-   dev_priv-fbc.enable_fbc(work-crtc);
-
-   dev_priv-fbc.crtc = work-crtc;
-   dev_priv-fbc.fb_id = crtc_fb-base.id;
-   dev_priv-fbc.y = work-crtc-base.y;
-   }
+   if (crtc_fb == work-fb)
+   intel_fbc_enable(work-crtc, work-fb);
 
dev_priv-fbc.fbc_work = NULL;
}
@@ -361,7 +368,7 @@ static void intel_fbc_cancel_work(struct drm_i915_private 
*dev_priv)
dev_priv-fbc.fbc_work = NULL;
 }
 
-static void intel_fbc_enable(struct intel_crtc *crtc)
+static void intel_fbc_schedule_enable(struct intel_crtc *crtc)
 {
struct intel_fbc_work *work;
struct drm_i915_private *dev_priv = crtc-base.dev-dev_private;
@@ -373,7 +380,7 @@ static void intel_fbc_enable(struct intel_crtc *crtc)
work = kzalloc(sizeof(*work), GFP_KERNEL);
if (work == NULL) {
DRM_ERROR(Failed to allocate FBC work structure\n);
-   dev_priv-fbc.enable_fbc(crtc);
+   intel_fbc_enable(crtc, crtc-base.primary-fb);
return;
}
 
@@ -826,7 +833,7 @@ static void __intel_fbc_update(struct drm_i915_private 
*dev_priv)
__intel_fbc_disable(dev_priv);
}
 
-   intel_fbc_enable(intel_crtc);
+   intel_fbc_schedule_enable(intel_crtc);
dev_priv-fbc.no_fbc_reason = FBC_OK;
return;
 
-- 
2.4.6

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

[Intel-gfx] [PATCH 00/16] FBC bug fixes

[Paulo Zanoni]

Hello

This series contains tons of bug fixes for FBC. Some of the patches on this
series have seen the mailing list a few times already. With this series applied,
my BDW machine passes all the FBC tests that are on IGT.

This means we could even try to enable FBC on BDW by default, but I won't put
this patch as part of the series since I want QA to confirm everything passes
before we make this move. In the meantime, there are some optimizations I want
to do, and SKL to fix.

Thanks,
Paulo

Paulo Zanoni (16):
  drm/i915: make sure we're not changing the FBC CFB with FBC enabled
  drm/i915: fix the FBC work allocation failure path
  drm/i915: fix FBC for cases where crtc-base.y is non-zero
  drm/i915: set ILK_DPFC_FENCE_YOFF to 0 on SNB
  drm/i915: check for the supported strides on HSW+ FBC
  drm/i915: try a little harder to find an FBC CRTC
  drm/i915: disable FBC on FIFO underruns
  drm/i915: avoid the last 8mb of stolen on BDW/SKL
  drm/i915: print the correct amount of bytes allocated for the CFB
  drm/i915: fix CFB size calculation
  drm/i915/bdw: don't enable FBC when pixel rate exceeds 95%
  drm/i915: apply WaFbcAsynchFlipDisableFbcQueue earlier
  drm/i915: don't use the first stolen page on Broadwell
  drm/i915: don't apply WaFbcAsynchFlipDisableFbcQueue on SKL
  Revert drm/i915: Allocate fbcon from stolen memory
  drm/i915: reject invalid formats for FBC

 drivers/gpu/drm/i915/i915_drv.h|  12 ++
 drivers/gpu/drm/i915/i915_gem_gtt.h|   1 +
 drivers/gpu/drm/i915/i915_gem_stolen.c |  29 +++-
 drivers/gpu/drm/i915/intel_drv.h   |   1 +
 drivers/gpu/drm/i915/intel_fbc.c   | 233 +
 drivers/gpu/drm/i915/intel_fbdev.c |   4 +-
 drivers/gpu/drm/i915/intel_fifo_underrun.c |   2 +
 7 files changed, 242 insertions(+), 40 deletions(-)

-- 
2.4.6

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

Re: [Intel-gfx] [PATCH v1 2/2] drm/i915/gen9: Disable gather at set shader bit

[shuang . he]

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
Task id: 7150
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
ILK  302/302  302/302
SNB  315/315  315/315
IVB  336/336  336/336
BYT -2  283/283  281/283
HSW  378/378  378/378
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
*BYT  igt@gem_partial_pwrite_pread@reads-uncached  PASS(1)  FAIL(1)
*BYT  igt@gem_tiled_partial_pwrite_pread@reads  PASS(1)  FAIL(1)
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Support DDI lane reversal for DP

[Stéphane Marchesin]

On Wed, Aug 5, 2015 at 12:34 PM, Benjamin Tissoires
benjamin.tissoi...@redhat.com wrote:
 On Jul 30 2015 or thereabouts, Sivakumar Thulasimani wrote:


 On 7/29/2015 8:52 PM, Benjamin Tissoires wrote:
 On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote:
 why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you 
 can
 identify both lane count and reversal state without touching anything in 
 the
 link training code. i am yet to upstream my changes for CHT that i can 
 share
 if required that does the same in intel_dp_detect without touching any line
 in link training path.
 With my current limited knowledge of the dp hotplug (and i915 driver) I
 am not sure we could detect the reversed state without trying to train 1
 lane only. I'd be glad to look at your changes and test them on my
 system if you think that could help having a cleaner solution.
 
 Cheers,
 Benjamin
 No, what i recommended was to do link training but in intel_dp_detect. Since
 USB Type C cable
 also has its own lane count restriction (it can have different lane count
 than the one supported
 by panel) you might have to figure that out as well. so both reversal and
 lane count detection
 can be done outside the modeset path and keep the code free of type C
 changes outside
 detection path.

 Please find below the code to do the same. Do not waste time trying to apply
 this directly on
 nightly since this is based on a local tree and because this is pre- atomic
 changes code, so you
 might have to modify chv_upfront_link_train to work on top of the latest
 nightly code. we
 are supposed to upstream this and is in my todo list.


 [original patch snipped...]

 Hi Sivakumar,

 So I managed to manually re-apply your patch on top of
 drm-intel-nightly, and tried to port it to make Broadwell working too.
 It works OK if the system is already boot without any external DP used.
 In this case, the detection works and I can see my external monitor
 working properly.

 However, if the monitor is cold plugged, the cpu/GPU hangs and I can not
 understand why. I think I enabled all that is mentioned in the PRM to be
 able to train the DP link, but I am obviously missing something else.
 Can you have a look?


Hi Benjamin,

I would recommend against this approach. Some adapters will claim that
they recovered a clock even when it isn't on the lanes you enabled,
which means that the reversal detection doesn't always work. The only
reliable way to do this is to go talk to the Chrome OS EC (you can
find these patches later in the Chrome OS tree). It's not as generic,
but we might be able to abstract that logic, maybe.

Stéphane



 My patch is now:

 From 11e9c42f55ae27bd6e7b0168bf24d15082c7d517 Mon Sep 17 00:00:00 2001
 From: Durgadoss R durgados...@intel.com
 Date: Mon, 3 Aug 2015 11:51:16 -0400
 Subject: [PATCH] drm/i915: Enable Upfront link training for type-C DP support

 To support USB type C alternate DP mode, the display driver needs to know the
 number of lanes required by DP panel as well as number of lanes that can be
 supported by the type-C cable. Sometimes, the type-C cable may limit the
 bandwidth even if Panel can support more lanes. To address these scenarios,
 the display driver will start link training with max lanes, and if the link
 training fails, the driver then falls back to x2 lanes.

 * Since link training is done before modeset, planes are not enabled. Only
   encoder and the its associated PLLs are enabled.
 * Once link training is done, the encoder and its PLLs are disabled; so that
   the subsequent modeset is not aware of these changes.
 * As of now, this is tested only on CHV.

 Signed-off-by: Durgadoss R durgados...@intel.com
 [BT: add broadwell support and USB-C reverted state detection]
 Signed-off-by: Benjamin Tissoires benjamin.tissoi...@redhat.com
 ---
  drivers/gpu/drm/i915/intel_display.c | 163 
 +++
  drivers/gpu/drm/i915/intel_dp.c  |  22 -
  drivers/gpu/drm/i915/intel_drv.h |   7 ++
  3 files changed, 190 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 818f3a3..e8ddba0 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -15799,3 +15799,166 @@ void intel_modeset_preclose(struct drm_device *dev, 
 struct drm_file *file)
 spin_unlock_irq(dev-event_lock);
 }
  }
 +
 +static bool
 +intel_upfront_link_train_config(struct drm_device *dev,
 +   struct intel_dp *intel_dp,
 +   struct intel_crtc *crtc,
 +   uint8_t link_bw,
 +   uint8_t lane_count)
 +{
 +   struct drm_i915_private *dev_priv = dev-dev_private;
 +   struct intel_connector *connector = intel_dp-attached_connector;
 +   struct intel_encoder *encoder = connector-encoder;
 +   bool success;
 +
 +   intel_dp-link_bw = 

[Intel-gfx] [PATCH 15/16] Revert drm/i915: Allocate fbcon from stolen memory

[Paulo Zanoni]

This reverts commit 0ffb0ff283cca16f72caf29c44496d83b0c291fb.

Technology has evolved and now we have eDP panels with 3200x1800
resolution. In the meantime, the BIOS guys didn't change the default
32mb for stolen memory. And we can't assume our users will be able to
increase the default stolen memory size to more than 32mb - I'm not
even sure all BIOSes allow that.

So just the fbcon buffer alone eats 22mb of my stolen memroy, and due
to the BDW/SKL restriction of not using the last 8mb of stolen memory,
all that's left for FBC is 2mb! Since fbcon is not the coolest feature
ever, I think it's better to save our precious stolen resource to FBC
and the other guys.

Besides, neither the original commit message nor the review comments
showed any arguments in favor of actually allocating fbcon from
stolen.

Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
 drivers/gpu/drm/i915/intel_fbdev.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index 96476d7..f90bf72 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -139,9 +139,7 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
 
size = mode_cmd.pitches[0] * mode_cmd.height;
size = PAGE_ALIGN(size);
-   obj = i915_gem_object_create_stolen(dev, size);
-   if (obj == NULL)
-   obj = i915_gem_alloc_object(dev, size);
+   obj = i915_gem_alloc_object(dev, size);
if (!obj) {
DRM_ERROR(failed to allocate framebuffer\n);
ret = -ENOMEM;
-- 
2.4.6

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

[Intel-gfx] [PATCH 07/16] drm/i915: disable FBC on FIFO underruns

[Paulo Zanoni]

If we want to try to enable FBC by default on any platform we need to
be on the safe side and disable it in case we get an underrun while
FBC is enabled on the corresponding pipe. We currently already have
other reasons for FIFO underruns on our driver, but the ones I saw
with FBC lead to black screens that only go away when you disable FBC.

The current FIFO underrun I see happens when the CFB is using the top
8mb of stolen memory. This is reproducible with a 2560x1440 DP Monitor
on a system with 32mb of stolen memory. On this case, all the IGT
tests fail while checking the screen CRC. A later patch on this series
will fix this problem for real.

With this patch, the tests will start failing while checking if FBC is
enabled instead of failing while comparing the CRC of the black screen
against the correct CRC. So this patch is not hiding any IGT bugs: the
tests still fail, but now they fail with a different reason.

Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
 drivers/gpu/drm/i915/i915_drv.h|  5 +++
 drivers/gpu/drm/i915/intel_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_fbc.c   | 61 ++
 drivers/gpu/drm/i915/intel_fifo_underrun.c |  2 +
 4 files changed, 69 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4fd7858..e74a844 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -926,6 +926,11 @@ struct i915_fbc {
struct drm_framebuffer *fb;
} *fbc_work;
 
+   struct intel_fbc_underrun_work {
+   struct work_struct work;
+   struct intel_crtc *crtc;
+   } underrun_work;
+
enum no_fbc_reason {
FBC_OK, /* FBC is enabled */
FBC_UNSUPPORTED, /* FBC is not supported by this chipset */
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 81b7d77..246925d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1247,6 +1247,7 @@ void intel_fbc_flush(struct drm_i915_private *dev_priv,
 unsigned int frontbuffer_bits, enum fb_op_origin origin);
 const char *intel_no_fbc_reason_str(enum no_fbc_reason reason);
 void intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv);
+void intel_fbc_handle_fifo_underrun(struct intel_crtc *crtc);
 
 /* intel_hdmi.c */
 void intel_hdmi_init(struct drm_device *dev, int hdmi_reg, enum port port);
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index a63d10a..28e569c 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -955,6 +955,65 @@ void intel_fbc_flush(struct drm_i915_private *dev_priv,
mutex_unlock(dev_priv-fbc.lock);
 }
 
+static void intel_fbc_underrun_work_fn(struct work_struct *__work)
+{
+   struct intel_fbc_underrun_work *work =
+   container_of(__work, struct intel_fbc_underrun_work, work);
+   struct intel_crtc *crtc = work-crtc;
+   struct drm_i915_private *dev_priv = crtc-base.dev-dev_private;
+
+   mutex_lock(dev_priv-fbc.lock);
+   if (!intel_fbc_enabled(dev_priv) || dev_priv-fbc.crtc != crtc)
+   goto out;
+
+   DRM_DEBUG_KMS(Disabling FBC due to FIFO underrun.\n);
+   i915.enable_fbc = 0;
+   __intel_fbc_disable(dev_priv);
+
+out:
+   work-crtc = NULL;
+   mutex_unlock(dev_priv-fbc.lock);
+}
+
+/**
+ * intel_fbc_handle_fifo_underrun - handle FIFO underruns if FBC is enabled
+ * @crtc: the CRTC that caused the underrun
+ *
+ * Although we can't know for sure what caused an underrun, one of the possible
+ * reasons is FBC. And on the FBC case, the user may have a black screen until
+ * FBC is disabled. So whenever a FIFO underrun happens while FBC is enabled,
+ * disable FBC just because it may help.
+ *
+ * We disable FBC by changing the i915 param, so FBC won't come back on the 
next
+ * frame just to cause another underrun. Test suites can force FBC back by
+ * changing the module parameter again through sysfs.
+ */
+void intel_fbc_handle_fifo_underrun(struct intel_crtc *crtc)
+{
+   struct drm_i915_private *dev_priv = crtc-base.dev-dev_private;
+   struct intel_fbc_underrun_work *work = dev_priv-fbc.underrun_work;
+
+   if (!dev_priv-fbc.enable_fbc)
+   return;
+
+   /* These checks are unlocked. We can't grab the lock since we're in the
+* IRQ handler. OTOH, grabbing it wouldn't help much since the underrun
+* interrupt is asynchronous. Still, this a try to recover because we
+* have already failed function, so let's at least try, and if we fail,
+* we'll probably be able to try again next frame when another underrun
+* happens. We'll also do the checks again in the work function, where
+* we can grab the lock. */
+   if (!intel_fbc_enabled(dev_priv) || dev_priv-fbc.crtc != crtc)
+   return;
+
+   /* 

[Intel-gfx] [PATCH 14/16] drm/i915: don't apply WaFbcAsynchFlipDisableFbcQueue on SKL

[Paulo Zanoni]

This WA is only for HSW/BDW.

Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
 drivers/gpu/drm/i915/intel_fbc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index b76c19f..5dfe460 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -298,7 +298,7 @@ static void gen7_fbc_enable(struct intel_crtc *crtc)
I915_WRITE(ILK_DISPLAY_CHICKEN1,
   I915_READ(ILK_DISPLAY_CHICKEN1) |
   ILK_FBCQ_DIS);
-   } else {
+   } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
/* WaFbcAsynchFlipDisableFbcQueue:hsw,bdw */
I915_WRITE(CHICKEN_PIPESL_1(crtc-pipe),
   I915_READ(CHICKEN_PIPESL_1(crtc-pipe)) |
-- 
2.4.6

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

[Intel-gfx] [PATCH 06/16] drm/i915: try a little harder to find an FBC CRTC

[Paulo Zanoni]

Keep searching in case the candidate has a NULL primary fb. This is
only relevant for the platforms that don't have the pipe_a_only
restriction.

Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
 drivers/gpu/drm/i915/intel_fbc.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 73bd559..a63d10a 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -532,16 +532,14 @@ static struct drm_crtc *intel_fbc_find_crtc(struct 
drm_i915_private *dev_priv)
tmp_crtc = dev_priv-pipe_to_crtc_mapping[pipe];
 
if (intel_crtc_active(tmp_crtc) 
-   to_intel_plane_state(tmp_crtc-primary-state)-visible)
+   to_intel_plane_state(tmp_crtc-primary-state)-visible 
+   tmp_crtc-primary-fb != NULL)
crtc = tmp_crtc;
 
if (pipe_a_only)
break;
}
 
-   if (!crtc || crtc-primary-fb == NULL)
-   return NULL;
-
return crtc;
 }
 
-- 
2.4.6

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

[Intel-gfx] [PATCH 10/16] drm/i915: fix CFB size calculation

[Paulo Zanoni]

We were considering the whole framebuffer height, but the spec clearly
says that we should only consider the active display height size.

On my current testing machine, this moves us from 124 successes and
502 skips to 209 successes and 417 skips on kms_frontbuffer_tracking
--fbc-only. The high amount of skips is due to the --fbc-only
argument. We had those skips due to not enough stolen memory for the
tests. We're now passing the maximum possible amount: 209.

Note: when this patch was written, the amount of tests we had for FBC
was different than what we have now.

Testcase: igt/kms_frontbuffer_tracking/fbc-*
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
 drivers/gpu/drm/i915/intel_fbc.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index dc84e67..cfd4cba 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -695,9 +695,15 @@ void intel_fbc_cleanup_cfb(struct drm_i915_private 
*dev_priv)
mutex_unlock(dev_priv-fbc.lock);
 }
 
-static int intel_fbc_setup_cfb(struct drm_i915_private *dev_priv, int size,
-  int fb_cpp)
+static int intel_fbc_setup_cfb(struct intel_crtc *crtc)
 {
+   struct drm_i915_private *dev_priv = crtc-base.dev-dev_private;
+   struct drm_framebuffer *fb = crtc-base.primary-fb;
+   int size, fb_cpp;
+
+   size = crtc-config-pipe_src_h * fb-pitches[0];
+   fb_cpp = drm_format_plane_cpp(fb-pixel_format, 0);
+
if (size = dev_priv-fbc.uncompressed_size)
return 0;
 
@@ -844,8 +850,7 @@ static void __intel_fbc_update(struct drm_i915_private 
*dev_priv)
goto out_disable;
}
 
-   if (intel_fbc_setup_cfb(dev_priv, obj-base.size,
-   drm_format_plane_cpp(fb-pixel_format, 0))) {
+   if (intel_fbc_setup_cfb(intel_crtc)) {
set_no_fbc_reason(dev_priv, FBC_STOLEN_TOO_SMALL);
goto out_disable;
}
-- 
2.4.6

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

[Intel-gfx] [PATCH 01/16] drm/i915: make sure we're not changing the FBC CFB with FBC enabled

[Paulo Zanoni]

We used to have this bug in the past, but now that we properly track
the size of the CFB, we don't have it anymore. Still, add the WARN
just to make sure we don't go back to the bad state.

Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
 drivers/gpu/drm/i915/intel_fbc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 1f97fb5..c97aba2 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -589,6 +589,8 @@ static int intel_fbc_alloc_cfb(struct drm_i915_private 
*dev_priv, int size,
 
dev_priv-fbc.threshold = ret;
 
+   WARN_ON(dev_priv-fbc.enabled);
+
if (INTEL_INFO(dev_priv)-gen = 5)
I915_WRITE(ILK_DPFC_CB_BASE, dev_priv-fbc.compressed_fb.start);
else if (IS_GM45(dev_priv)) {
-- 
2.4.6

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

[Intel-gfx] [PATCH 05/16] drm/i915: check for the supported strides on HSW+ FBC

[Paulo Zanoni]

I could only find the restrictions for HSW+, but I think it's safe to
assume that the older platforms also can't support the configurations
HSW can't support. The older platforms probably have additional
restrictions, so we need to figure out those and implement them later.
Let's not block HSW+ FBC based on missing information for the older
platforms.

v2:
  - Just WARN_ON() the strides that should have been caught earlier
(Daniel)
  - Make it a new function since I expect this to grow more.
v3:
  - Document which IGT test is exercised by this.

Testcase: igt/kms_frontbuffer_tracking/fbc-badstride
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_fbc.c | 23 +++
 2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e0f3f05..4fd7858 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -940,6 +940,7 @@ struct i915_fbc {
FBC_CHIP_DEFAULT, /* disabled by default on this chip */
FBC_ROTATION, /* rotation is not supported */
FBC_IN_DBG_MASTER, /* kernel debugger is active */
+   FBC_BAD_STRIDE, /* stride is not supported */
} no_fbc_reason;
 
bool (*fbc_enabled)(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index f7be9ab8..73bd559 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -501,6 +501,8 @@ const char *intel_no_fbc_reason_str(enum no_fbc_reason 
reason)
return rotation unsupported;
case FBC_IN_DBG_MASTER:
return Kernel debugger is active;
+   case FBC_BAD_STRIDE:
+   return framebuffer stride not supported;
default:
MISSING_CASE(reason);
return unknown reason;
@@ -694,6 +696,22 @@ static int intel_fbc_setup_cfb(struct drm_i915_private 
*dev_priv, int size,
return intel_fbc_alloc_cfb(dev_priv, size, fb_cpp);
 }
 
+static bool stride_is_valid(unsigned int stride)
+{
+   /* TODO: we need to figure out what are the stride restrictions for the
+* older platforms. */
+
+   /* These should have been caught earlier. */
+   WARN_ON(stride  512);
+   WARN_ON((stride  (64 - 1)) != 0);
+
+   /* These are additional FBC restrictions. */
+   if (stride  16385)
+   return false;
+
+   return true;
+}
+
 /**
  * __intel_fbc_update - enable/disable FBC as needed, unlocked
  * @dev_priv: i915 device instance
@@ -804,6 +822,11 @@ static void __intel_fbc_update(struct drm_i915_private 
*dev_priv)
goto out_disable;
}
 
+   if (!stride_is_valid(fb-pitches[0])) {
+   set_no_fbc_reason(dev_priv, FBC_BAD_STRIDE);
+   goto out_disable;
+   }
+
/* If the kernel debugger is active, always disable compression */
if (in_dbg_master()) {
set_no_fbc_reason(dev_priv, FBC_IN_DBG_MASTER);
-- 
2.4.6

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

[Intel-gfx] [PATCH 08/16] drm/i915: avoid the last 8mb of stolen on BDW/SKL

[Paulo Zanoni]

The FBC hardware for these platforms doesn't have access to the
bios_reserved range, so it always assumes the maximum (8mb) is used.
So avoid this range while allocating.

This solves a bunch of FIFO underruns that happen if you end up
putting the CFB in that memory range. On my machine, with 32mb of
stolen, I need a 2560x1440 mode for that.

Testcase: igt/kms_frontbuffer_tracking/fbc-* (given the right setup)
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
 drivers/gpu/drm/i915/i915_drv.h|  4 
 drivers/gpu/drm/i915/i915_gem_gtt.h|  1 +
 drivers/gpu/drm/i915/i915_gem_stolen.c | 26 +++---
 drivers/gpu/drm/i915/intel_fbc.c   | 16 ++--
 4 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e74a844..f44d101 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3159,6 +3159,10 @@ static inline void i915_gem_chipset_flush(struct 
drm_device *dev)
 int i915_gem_stolen_insert_node(struct drm_i915_private *dev_priv,
struct drm_mm_node *node, u64 size,
unsigned alignment);
+int i915_gem_stolen_insert_node_in_range(struct drm_i915_private *dev_priv,
+struct drm_mm_node *node, u64 size,
+unsigned alignment, u64 start,
+u64 end);
 void i915_gem_stolen_remove_node(struct drm_i915_private *dev_priv,
 struct drm_mm_node *node);
 int i915_gem_init_stolen(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 8275007..96ebb98 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -341,6 +341,7 @@ struct i915_gtt {
struct i915_address_space base;
 
size_t stolen_size; /* Total size of stolen memory */
+   size_t stolen_usable_size;  /* Total size minus BIOS reserved */
u64 mappable_end;   /* End offset that we can CPU map */
struct io_mapping *mappable;/* Mapping to our CPU mappable region */
phys_addr_t mappable_base;  /* PA of our GMADR */
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index a36cb95..824334d 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -42,9 +42,9 @@
  * for is a boon.
  */
 
-int i915_gem_stolen_insert_node(struct drm_i915_private *dev_priv,
-   struct drm_mm_node *node, u64 size,
-   unsigned alignment)
+int i915_gem_stolen_insert_node_in_range(struct drm_i915_private *dev_priv,
+struct drm_mm_node *node, u64 size,
+unsigned alignment, u64 start, u64 end)
 {
int ret;
 
@@ -52,13 +52,23 @@ int i915_gem_stolen_insert_node(struct drm_i915_private 
*dev_priv,
return -ENODEV;
 
mutex_lock(dev_priv-mm.stolen_lock);
-   ret = drm_mm_insert_node(dev_priv-mm.stolen, node, size, alignment,
-DRM_MM_SEARCH_DEFAULT);
+   ret = drm_mm_insert_node_in_range(dev_priv-mm.stolen, node, size,
+ alignment, start, end,
+ DRM_MM_SEARCH_DEFAULT);
mutex_unlock(dev_priv-mm.stolen_lock);
 
return ret;
 }
 
+int i915_gem_stolen_insert_node(struct drm_i915_private *dev_priv,
+   struct drm_mm_node *node, u64 size,
+   unsigned alignment)
+{
+   return i915_gem_stolen_insert_node_in_range(dev_priv, node, size,
+   alignment, 0,
+   dev_priv-gtt.stolen_usable_size);
+}
+
 void i915_gem_stolen_remove_node(struct drm_i915_private *dev_priv,
 struct drm_mm_node *node)
 {
@@ -352,9 +362,11 @@ int i915_gem_init_stolen(struct drm_device *dev)
  dev_priv-gtt.stolen_size  10,
  (dev_priv-gtt.stolen_size - reserved_total)  10);
 
+   dev_priv-gtt.stolen_usable_size = dev_priv-gtt.stolen_size -
+  reserved_total;
+
/* Basic memrange allocator for stolen space */
-   drm_mm_init(dev_priv-mm.stolen, 0, dev_priv-gtt.stolen_size -
-   reserved_total);
+   drm_mm_init(dev_priv-mm.stolen, 0, dev_priv-gtt.stolen_usable_size);
 
return 0;
 }
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 28e569c..9fd7b74 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -570,6 +570,16 @@ static int find_compression_threshold(struct 

Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl: Adding DDI_E power well domain

[Rodrigo Vivi]

Sorry, but I don't get how this enables power_well_2 as well. I just see it
enabling ddi A/E as the other.

Maybe Paulo or Imre are the best one to review this.

On Thu, Aug 13, 2015 at 2:54 AM Xiong Zhang xiong.y.zh...@intel.com wrote:

 From B spec, DDI_E port belong to PowerWell 2, but
 DDI_E share the powerwell_req/staus register bit with
 DDI_A which belong to DDI_A_E_POWER_WELL.

 In order to communicate with the connector on DDI-E, both
 DDI_A_E_POWER_WELL and POWER_WELL_2 must be enabled.

 Currently intel_dp_power_get(DDI_E) only enable
 DDI_A_E_POWER_WELL, this patch will not only enable
 DDI_a_E_POWER_WELL but also enable POWER_WELL_2.

 This patch also fix the DDI-E hotplug function.

 Signed-off-by: Xiong Zhang xiong.y.zh...@intel.com
 ---
  drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
  drivers/gpu/drm/i915/i915_drv.h | 1 +
  drivers/gpu/drm/i915/intel_display.c| 3 ++-
  drivers/gpu/drm/i915/intel_runtime_pm.c | 2 ++
  4 files changed, 7 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
 b/drivers/gpu/drm/i915/i915_debugfs.c
 index 86734be..5523b6e 100644
 --- a/drivers/gpu/drm/i915/i915_debugfs.c
 +++ b/drivers/gpu/drm/i915/i915_debugfs.c
 @@ -2564,6 +2564,8 @@ static const char *power_domain_str(enum
 intel_display_power_domain domain)
 return PORT_DDI_D_2_LANES;
 case POWER_DOMAIN_PORT_DDI_D_4_LANES:
 return PORT_DDI_D_4_LANES;
 +   case POWER_DOMAIN_PORT_DDI_E_2_LANES:
 +   return PORT_DDI_E_2_LANES;
 case POWER_DOMAIN_PORT_DSI:
 return PORT_DSI;
 case POWER_DOMAIN_PORT_CRT:
 diff --git a/drivers/gpu/drm/i915/i915_drv.h
 b/drivers/gpu/drm/i915/i915_drv.h
 index b157865..ee71f90 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -182,6 +182,7 @@ enum intel_display_power_domain {
 POWER_DOMAIN_PORT_DDI_C_4_LANES,
 POWER_DOMAIN_PORT_DDI_D_2_LANES,
 POWER_DOMAIN_PORT_DDI_D_4_LANES,
 +   POWER_DOMAIN_PORT_DDI_E_2_LANES,
 POWER_DOMAIN_PORT_DSI,
 POWER_DOMAIN_PORT_CRT,
 POWER_DOMAIN_PORT_OTHER,
 diff --git a/drivers/gpu/drm/i915/intel_display.c
 b/drivers/gpu/drm/i915/intel_display.c
 index 801187c..ccd3f0b 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -5150,7 +5150,6 @@ static enum intel_display_power_domain
 port_to_power_domain(enum port port)
  {
 switch (port) {
 case PORT_A:
 -   case PORT_E:
 return POWER_DOMAIN_PORT_DDI_A_4_LANES;
 case PORT_B:
 return POWER_DOMAIN_PORT_DDI_B_4_LANES;
 @@ -5158,6 +5157,8 @@ static enum intel_display_power_domain
 port_to_power_domain(enum port port)
 return POWER_DOMAIN_PORT_DDI_C_4_LANES;
 case PORT_D:
 return POWER_DOMAIN_PORT_DDI_D_4_LANES;
 +   case PORT_E:
 +   return POWER_DOMAIN_PORT_DDI_E_2_LANES;
 default:
 WARN_ON_ONCE(1);
 return POWER_DOMAIN_PORT_OTHER;
 diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
 b/drivers/gpu/drm/i915/intel_runtime_pm.c
 index 821644d..af7fdb3 100644
 --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
 +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
 @@ -297,6 +297,7 @@ static void hsw_set_power_well(struct drm_i915_private
 *dev_priv,
 BIT(POWER_DOMAIN_PORT_DDI_C_4_LANES) |  \
 BIT(POWER_DOMAIN_PORT_DDI_D_2_LANES) |  \
 BIT(POWER_DOMAIN_PORT_DDI_D_4_LANES) |  \
 +   BIT(POWER_DOMAIN_PORT_DDI_E_2_LANES) |  \
 BIT(POWER_DOMAIN_AUX_B) |   \
 BIT(POWER_DOMAIN_AUX_C) |   \
 BIT(POWER_DOMAIN_AUX_D) |   \
 @@ -316,6 +317,7 @@ static void hsw_set_power_well(struct drm_i915_private
 *dev_priv,
  #define SKL_DISPLAY_DDI_A_E_POWER_DOMAINS (\
 BIT(POWER_DOMAIN_PORT_DDI_A_2_LANES) |  \
 BIT(POWER_DOMAIN_PORT_DDI_A_4_LANES) |  \
 +   BIT(POWER_DOMAIN_PORT_DDI_E_2_LANES) |  \
 BIT(POWER_DOMAIN_INIT))
  #define SKL_DISPLAY_DDI_B_POWER_DOMAINS (  \
 BIT(POWER_DOMAIN_PORT_DDI_B_2_LANES) |  \
 --
 2.1.4

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

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

Re: [Intel-gfx] [PATCH 1/7] prime_mmap: Add new test for calling mmap() on dma-buf fds

[Tiago Vignatti]

Hi Daniel,

On 08/13/2015 04:04 AM, Daniel Vetter wrote:

On Wed, Aug 12, 2015 at 08:29:14PM -0300, Tiago Vignatti wrote:

+   /* Map too big */
+   handle = gem_create(fd, BO_SIZE);
+   fill_bo(handle, BO_SIZE);
+   dma_buf_fd = prime_handle_to_fd(fd, handle);
+   igt_assert(errno == 0);
+   ptr = mmap(NULL, BO_SIZE * 2, PROT_READ, MAP_SHARED, dma_buf_fd, 0);
+   igt_assert(ptr == MAP_FAILED  errno == EINVAL);
+   errno = 0;
+   close(dma_buf_fd);
+   gem_close(fd, handle);


That only checks for one of the conditions, trying to map something
offset/overlapping the end of the buffer, but small enough needs to be
tested separately.


you mean test for smaller length with a non-zero offset? I don't think I 
get what you wanted to say here maybe.



Also I think a testcase for invalid buffer2fd flags would be good, just
for completeness - we seem to be missing that one.


you mean test for different flags than the ones supported by 
DRM_IOCTL_PRIME_HANDLE_TO_FD?


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

Re: [Intel-gfx] [PATCH] drm/dp/mst: Remove port after removing connector.

[Dave Airlie]

On 11 August 2015 at 17:54, Maarten Lankhorst
maarten.lankho...@linux.intel.com wrote:
 The port is removed synchronously, but the connector delayed.
 This causes a use after free which can cause a kernel BUG with
 slug_debug=FPZU. This is fixed by freeing the port after the
 connector.

Where is the use after free btw? I'm not sure I like delaying the port
destruction, there should be no need to.

The connector-port pointer shouldn't be used without validation
anywhere, and if it is that is a bug.

I'd like to reproduce this before pulling this in.

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

Re: [Intel-gfx] [PATCH v2] drm/i915: clflush on pin_to_display after pwrite to UC bo in LLC

[shuang . he]

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
Task id: 7152
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
ILK  302/302  302/302
SNB  315/315  315/315
IVB  336/336  336/336
BYT  283/283  283/283
HSW  378/378  378/378
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Only dither on 6bpc panels

[shuang . he]

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
Task id: 7155
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
ILK -1  302/302  301/302
SNB  315/315  315/315
IVB  336/336  336/336
BYT -3  283/283  280/283
HSW  378/378  378/378
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
*ILK  igt@kms_flip@wf_vblank-vs-modeset-interruptible  PASS(1)  
DMESG_WARN(1)
*BYT  igt@gem_partial_pwrite_pread@reads-uncached  PASS(1)  FAIL(1)
*BYT  igt@gem_persistent_relocs@forked-interruptible  PASS(1)  FAIL(1)
*BYT  igt@gem_tiled_partial_pwrite_pread@reads  PASS(1)  FAIL(1)
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/18] tests/drv_suspend: mark sysfs tests as basic

[Daniel Vetter]

On Fri, Aug 14, 2015 at 08:29:40AM -0700, Jesse Barnes wrote:
 On 08/14/2015 05:29 AM, Daniel Vetter wrote:
  On Thu, Aug 13, 2015 at 01:31:29PM -0700, Jesse Barnes wrote:
  debugfs may not be mounted, but sysfs should always be restored after
  suspend or hibernate.
 
  Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
  
  We already have a suspend/resume testcase in kms_pipc_crc_basic. Do we
  have enough budget for this one?
 
 Yeah I thought about getting rid of the suspend/resume ones in pipe_crc
 (marking them as non-basic), since I really just want the one set of
 tests.  Any preference?

Imo crc is such a basic (hah!) validation tool that we really should try
to run all the corner cases. Otherwise we have ugly situations where some
tests randomyl fail, depending upon when they've been run after system
suspend/resume or not. And with all our troubles we need to reboot a few
times for a full run, so this is likely.

This actually happened (that's why we have these tests) and resulted in
lots and lots of wtf until resolved. So yeah I think for crc we really
want them all, even if it's a bit expensive, since if we don't there's a
good chance for lots of flaky test results. And that's the prime problem
we have with igt.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/18] tests/gem_ctx_exec: mark lrc lite restore as basic

[Daniel Vetter]

On Fri, Aug 14, 2015 at 08:31:01AM -0700, Jesse Barnes wrote:
 On 08/14/2015 05:32 AM, Daniel Vetter wrote:
  On Thu, Aug 13, 2015 at 01:31:30PM -0700, Jesse Barnes wrote:
  Need some LRC tests in the 'basic' subset, and this is a good simple
  one.
 
  Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
  
  This is just a testcase for a very specific lrc corner case. We do already
  exercise lrc with all the other execbuf testcases. Imo we're covered
  enough already with what we have in the basic testset - testing for all 3
  billion cornercases will make it grow out of scope I fear. I'd just drop
  this one here as not needed for BAT.
  
  If you want to extend execbuffer scope a bit then we should add a
  concurrency test, i.e. one of the gem_concurrent_blt testcases as basic
  ones. Unfortunately to be able to reliable trigger race conditions those
  all take a few seconds. But inter-batch sync is a _big_ gap across all
  archs, and something which is even more tricky with lrc (and scheduler).
  Imo that would be a lot more useful than this test here.
 
 Yeah that's a good point; I just saw 'lrc' and though I want that, but
 you're right we should already be covered.  Definitely open to adding
 some concurrency stuff (maybe just a few seconds worth) as we get things
 in place.

For concurrency mabye we can do that in a 2nd round - we need to go over
gem_concurrent_* anyway and reshuffle that one into basic, full and
subtests that we're only going to expose through cmdline options for
manual testing. Atm there's way too many of those tests.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 15/18] tests/pm_rpm: mark RTE and D3 tests as basic

[Daniel Vetter]

On Fri, Aug 14, 2015 at 08:48:42AM -0700, Jesse Barnes wrote:
 On 08/14/2015 05:50 AM, Daniel Vetter wrote:
  On Thu, Aug 13, 2015 at 01:31:38PM -0700, Jesse Barnes wrote:
  These always need to pass for basic PM functionality.
 
  Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
  ---
   tests/pm_rpm.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)
 
  diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
  index d509fa8..7ae5806 100644
  --- a/tests/pm_rpm.c
  +++ b/tests/pm_rpm.c
  @@ -1832,11 +1832,11 @@ int main(int argc, char *argv[])
 stay_subtest();
   
 /* Essential things */
  -  igt_subtest(rte)
  +  igt_subtest(basic-rte)
  
  I thought our BAT criteria would be basic|rte?
  
  rte is runtime environment check and more along the lines of did QA set
  up their machine correctly, so imo good to keep separate.
 
 I was hoping to keep the BAT in the 'basic' namespace only, so rte tests
 would be included as well, but we'd need to prefix them with basic- too.
 Sounds like Paulo is ok with that, so I'll keep it here.  Makes test
 running that much simpler. :)

Yeah makes sense, ok with me if we go with just basic.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/18] tests/gem_mmap: mark basic object creation tests as basic

[Daniel Vetter]

On Fri, Aug 14, 2015 at 08:31:53AM -0700, Jesse Barnes wrote:
 On 08/14/2015 05:33 AM, Daniel Vetter wrote:
  On Thu, Aug 13, 2015 at 01:31:31PM -0700, Jesse Barnes wrote:
  We should be able to create small and moderate sized objects quickly and
  without errors.
 
  Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
  
  They're all super-fast basic testcases for api cornercases. I'd vote to
  rename the entire testcase to gem_mmap_basic.
 
 Not quite, the huge ones were pretty slow in my measurements...  Not as
 bad as suspend/resume, but not super fast either.

Right I missed those two at the bottom. But everything above small-bo
looks very basic, so perhaps just include them all with a basic-* prefix?
And keep the first one as basic-new-object?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 18/18] gitignore: ignore more files

[Daniel Vetter]

On Fri, Aug 14, 2015 at 08:20:22AM -0700, Jesse Barnes wrote:
 git clean updates the .gitignore file?  Not having to run git clean is the 
 whole point of this patch...

I looked at this patch first, but later noticed that you have a few
renames where you don't update the .gitignore.
 
 On 08/14/2015 01:09 AM, Daniel Vetter wrote:
  On Thu, Aug 13, 2015 at 01:31:41PM -0700, Jesse Barnes wrote:
  
  git clean fixes this all, at least over here git status is clean.
  -Daniel
  
  ---
   .gitignore   |  3 +++
   tests/.gitignore | 13 +
   tools/.gitignore |  8 
   3 files changed, 24 insertions(+)
 
  diff --git a/.gitignore b/.gitignore
  index a438c1c..533f6f1 100644
  --- a/.gitignore
  +++ b/.gitignore
  @@ -90,3 +90,6 @@ gtk-doc.m4
   
   piglit
   results
  +
  +*.orig
  +version.h
  diff --git a/tests/.gitignore b/tests/.gitignore
  index 31d35a5..e45cbb7 100644
  --- a/tests/.gitignore
  +++ b/tests/.gitignore
  @@ -99,6 +99,7 @@ gem_set_tiling_vs_blt
   gem_set_tiling_vs_gtt
   gem_set_tiling_vs_pwrite
   gem_storedw_batches_loop
  +gem_storedw_loop
   gem_storedw_loop_blt
   gem_storedw_loop_bsd
   gem_storedw_loop_render
  @@ -169,3 +170,15 @@ prime_udl
   template
   test-list.txt
   testdisplay
  +ddi_compute_wrpll
  +gem_vmap_blits
  +gem_wait_render_timeout
  +igt_fork_helper
  +igt_list_only
  +igt_no_exit
  +igt_no_exit_list_only
  +igt_no_subtest
  +igt_simulation

But all the igt_* have moved to lib/tests/ so you definitely have a pile
of old build system gunk that needs to be cleaned out first with git
clean.

  +pm_pc8
  +pm_psr
  +
  diff --git a/tools/.gitignore b/tools/.gitignore
  index 49bd24f..7bf91e3 100644
  --- a/tools/.gitignore
  +++ b/tools/.gitignore
  @@ -37,3 +37,11 @@ intel_vga_write
   intel_watermark
   skl_compute_wrpll
   skl_ddb_allocation
  +forcewaked
  +intel_dpio_read
  +intel_dpio_write
  +intel_gpu_dump
  +intel_nc_read
  +intel_nc_write
  +intel_punit_read
  +intel_punit_write

Same with those, Jani killed them all iirc.
-Daniel

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

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

Re: [Intel-gfx] [PATCH 01/18] tests/gem_storedw_loop: add new store_dword test to unify per-ring ones

[Daniel Vetter]

On Fri, Aug 14, 2015 at 08:21:12AM -0700, Jesse Barnes wrote:
 On 08/14/2015 05:19 AM, Daniel Vetter wrote:
  On Thu, Aug 13, 2015 at 01:31:24PM -0700, Jesse Barnes wrote:
  There was a lot of duplication going on...  Mark as basic while we're at
  it as these should never fail.
 
  Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
  ---
   tests/Makefile.sources   |   1 +
   tests/gem_storedw_loop.c | 181 
  +++
   2 files changed, 182 insertions(+)
   create mode 100644 tests/gem_storedw_loop.c
 
  diff --git a/tests/Makefile.sources b/tests/Makefile.sources
  index b9a4cb4..cdcee33 100644
  --- a/tests/Makefile.sources
  +++ b/tests/Makefile.sources
  @@ -138,6 +138,7 @@ TESTS_progs = \
 gem_seqno_wrap \
 gem_set_tiling_vs_gtt \
 gem_set_tiling_vs_pwrite \
  +  gem_storedw_loop \
 gem_storedw_loop_blt \
 gem_storedw_loop_bsd \
 gem_storedw_loop_render \
  
  Why not remove the old ones while at it? This just means more gunk in the
  overall igt set. Also please update .gitignore here for these ...
 
 Yeah figured that would be a separate patch assuming this one looked ok.
 I added it to the .gitignore in a later patch to update it all at once.

At least in the past when we renamed tests we've done it in one go. That
way QA has an easier time finding the rename in git logs, otherwise
they're just oh it's gone and don't carry over existing bug reports.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Fix build warning on 32-bit

[Thierry Reding]

From: Thierry Reding tred...@nvidia.com

The gtt.stolen_size field is of type size_t, and so should be printed
using %zu to avoid build warnings on either 32-bit and 64-bit builds.

Signed-off-by: Thierry Reding tred...@nvidia.com
---
 drivers/gpu/drm/i915/i915_gem_stolen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index a36cb95ec798..f361c4a56995 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -348,7 +348,7 @@ int i915_gem_init_stolen(struct drm_device *dev)
 * memory, so just consider the start. */
reserved_total = stolen_top - reserved_base;
 
-   DRM_DEBUG_KMS(Memory reserved for graphics device: %luK, usable: 
%luK\n,
+   DRM_DEBUG_KMS(Memory reserved for graphics device: %zuK, usable: 
%luK\n,
  dev_priv-gtt.stolen_size  10,
  (dev_priv-gtt.stolen_size - reserved_total)  10);
 
-- 
2.4.5

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

Re: [Intel-gfx] [PATCH 6/6 v3] drm/i915: Enable HDMI on DDI-E

[Zhang, Xiong Y]

 On Thu, Aug 13, 2015 at 02:57:38AM +, Zhang, Xiong Y wrote:
   On Wed, Aug 12, 2015 at 06:39:34PM +0800, Xiong Zhang wrote:
DDI-E doesn't have the correspondent GMBUS pin.
   
We rely on VBT to tell us which one it being used instead.
   
The DVI/HDMI on shared port couldn't exist.
   
This patch isn't tested without hardware wchich has HDMI on DDI-E.
   
v2: fix trailing whitespace
v3: WARN() take place of BUG()
  
   I asked for MISSING_CASE, not WARN.
   -Daniel
  [Zhang, Xiong Y] Because DDI-E on SKL doesn't have correspondent GMBUS
 pin, it should share such pin with DDI-B/C/D. We don't know the default
 GMBUS pin for DDI-E if VBT doesn't tell us.
  If VBT don't tell us or give us an invalid GMBUS pin, driver will fail in 
  getting
 HDMI info. In such case, we really need a warn which tell us why driver
 couldn't read EDID info for HDMI on DDI-E.
 
 Have you bothered to look at the MISSING_CASE macro?! It does boil down to
 a WARN, but I prefer it much over a WARN_ON since it's nicely standardized.
 
[Zhang, Xiong Y] Please forgive my innocence! I misunderstand MISSING_CASE at 
the beginning.

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