Re: [Intel-gfx] [PATCH 03/11] drm/i915: Add a delay in Displayport AUX transactions for compliance testing

[Todd Previte]

Fixed the commit message. That will be in V5 of the patch set to be 
posted today.


On 4/7/2015 6:57 AM, Paulo Zanoni wrote:

2015-04-06 23:09 GMT-03:00 Todd Previte tprev...@gmail.com:

The Displayport Link Layer Compliance Testing Specification 1.2 rev 1.1
specifies that repeated AUX transactions after a failure (no response /
invalid response) must have a minimum delay of 400us before the resend can
occur. Tests 4.2.1.1 and 4.2.1.2 are two tests that require this specifically.

Also, the check for DP_AUX_CH_CTL_TIME_OUT_ERROR has been moved out into a
separate case. As of now, the only action taken is to log the error, since
the HW will have already waited the required amount of time for the
transaction to complete.

As of V6, this paragraph is no longer true. We could just remove it
while applying.

With that: Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com.


V2:
- Changed udelay() to usleep_range()
V3:
- Removed extraneous check for timeout
- Updated comment to reflect this change
V4:
- Reformatted a comment
V5:
- Added separate check for HW timeout on AUX transactions. A message
   is logged upon detection of this case.
V6:
- Add continue statement to HW timeout detect case
- Remove the log message indicating a timeout has been
   detected (review feedback)

Signed-off-by: Todd Previte tprev...@gmail.com
---
  drivers/gpu/drm/i915/intel_dp.c | 13 +++--
  1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ed2f60c..8b59458 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -877,9 +877,18 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
DP_AUX_CH_CTL_TIME_OUT_ERROR |
DP_AUX_CH_CTL_RECEIVE_ERROR);

-   if (status  (DP_AUX_CH_CTL_TIME_OUT_ERROR |
- DP_AUX_CH_CTL_RECEIVE_ERROR))
+   if (status  DP_AUX_CH_CTL_TIME_OUT_ERROR)
 continue;
+
+   /* DP CTS 1.2 Core Rev 1.1, 4.2.1.1  4.2.1.2
+*   400us delay required for errors and timeouts
+*   Timeout errors from the HW already meet this
+*   requirement so skip to next iteration
+*/
+   if (status  DP_AUX_CH_CTL_RECEIVE_ERROR) {
+   usleep_range(400, 500);
+   continue;
+   }
 if (status  DP_AUX_CH_CTL_DONE)
 break;
 }
--
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 06/11] drm/i915: Update intel_dp_hpd_pulse() to check link status for non-MST operation

[Todd Previte]

On 4/8/2015 11:53 AM, Paulo Zanoni wrote:

2015-04-01 15:00 GMT-03:00 Todd Previte tprev...@gmail.com:

Update the hot plug function to handle the SST case. Instead of placing
the SST case within the long/short pulse block, it is now handled after
determining that MST mode is not in use. This way, the topology management
layer can handle any MST-related operations while SST operations are still
correctly handled afterwards.

This patch also corrects the problem of SST mode only being handled in the
case of a short (0.5ms - 1.0ms) HPD pulse.

It's not clear to me what exactly is the problem with the current
code. Can you please clarify?
The main problem is that the comment in the code there is wrong. We 
*don't* check the link status later as it says it will. The legacy HPD 
handler (intel_dp_hot_plug) has been gutted but the function is still 
there in the code. It probably should have been removed when the new 
handler was implemented, but that's another matter entirely.


So as things stand, the only time we actually check the link status is 
when we get a short pulse on the HPD line. Long pulses (i.e. 
connect/disconnect events) don't get processed. This code corrects that 
problem and properly handles both long and short HPD pulses for the SST 
mode.



For compliance testing purposes
both short and long pulses are used by the different tests, thus both cases
need to be addressed for SST.

This patch replaces [PATCH 10/10] drm/i915: Fix intel_dp_hot_plug() in the
previous compliance testing patch sequence. Review feedback on that patch
indicated that updating intel_dp_hot_plug() was not the correct place for
the test handler.

For the SST case, the main stream is disabled for long HPD pulses as this
generally indicates either a connect/disconnect event or link failure. For
a number of case in compliance testing, the source is required to disable
the main link upon detection of a long HPD.

V2:
- N/A
V3:
- Place the SST mode link status check into the mst_fail case
- Remove obsolete comment regarding SST mode operation
- Removed an erroneous line of code that snuck in during rebasing
V4:
- Added a disable of the main stream (DP transport) for the long pulse case
   for SST to support compliance testing
V5:
- Reworked SST handling to support tests 4.2.2.7 and 4.2.2.8

Signed-off-by: Todd Previte tprev...@gmail.com
---
  drivers/gpu/drm/i915/intel_dp.c | 28 +++-
  1 file changed, 11 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 16d35903..0a77f5a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4622,16 +4622,6 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
 if (intel_dp_check_mst_status(intel_dp) == -EINVAL)
 goto mst_fail;
 }
-
-   if (!intel_dp-is_mst) {
-   /*
-* we'll check the link status via the normal hot plug 
path later -
-* but for short hpds we should check it now
-*/
-   drm_modeset_lock(dev-mode_config.connection_mutex, 
NULL);
-   intel_dp_check_link_status(intel_dp);
-   drm_modeset_unlock(dev-mode_config.connection_mutex);
-   }
 }

 ret = IRQ_HANDLED;
@@ -4639,18 +4629,22 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
 goto put_power;
  mst_fail:
 /* if we were in MST mode, and device is not there get out of MST mode 
*/
-   if (intel_dp-is_mst) {
-   DRM_DEBUG_KMS(MST device may have disappeared %d vs %d\n, 
intel_dp-is_mst, intel_dp-mst_mgr.mst_state);
-   intel_dp-is_mst = false;
-   drm_dp_mst_topology_mgr_set_mst(intel_dp-mst_mgr, 
intel_dp-is_mst);
-   } else {
-   /* SST mode - handle short/long pulses here */
+   DRM_DEBUG_KMS(MST device may have disappeared %d vs %d\n, 
intel_dp-is_mst, intel_dp-mst_mgr.mst_state);

So now aren't we going to get MST log messages on non-MST cases, such
as a disconnect with long_hpd? I mean, even non-MST jumps to the
mst_fail label.


Yeah that got removed by mistake. I corrected this for the next version 
of the patch.





+   intel_dp-is_mst = false;
+   drm_dp_mst_topology_mgr_set_mst(intel_dp-mst_mgr, intel_dp-is_mst);
+
+put_power:
+   /* SST mode - handle short/long pulses here */
+   if (!intel_dp-is_mst) {
+   /* TO DO: Handle short/long pulses individually
+   Can save on training times and overhead by not doing
+   full link status updating/processing for short pulses
+*/
 drm_modeset_lock(dev-mode_config.connection_mutex, NULL);
 intel_dp_check_link_status(intel_dp);
 

Re: [Intel-gfx] [PATCH] drm/i915/chv: Remove DPIO force latency causing interpair skew issue

[Ville Syrjälä]

On Thu, Apr 09, 2015 at 10:17:05AM -0700, clinton.a.tay...@intel.com wrote:
 From: Clint Taylor clinton.a.tay...@intel.com
 
 Latest version of the CHV DPIO programming notes no longer requires writes
 to TX DW 11 to fix a +2UI interpair skew issue. The current code from
 April 2014 was actually causing additional skew issues between all
 TMDS pairs.
 
 Signed-off-by: Clint Taylor clinton.a.tay...@intel.com
 ---
  drivers/gpu/drm/i915/intel_hdmi.c |5 -
  1 file changed, 5 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
 b/drivers/gpu/drm/i915/intel_hdmi.c
 index 26222e6..3cef326 100644
 --- a/drivers/gpu/drm/i915/intel_hdmi.c
 +++ b/drivers/gpu/drm/i915/intel_hdmi.c
 @@ -1515,11 +1515,6 @@ static void chv_hdmi_pre_enable(struct intel_encoder 
 *encoder)
  
   /* Program Tx latency optimal setting */
   for (i = 0; i  4; i++) {
 - /* Set the latency optimal bit */
 - data = (i == 1) ? 0x0 : 0x6;
 - vlv_dpio_write(dev_priv, pipe, CHV_TX_DW11(ch, i),
 - data  DPIO_FRC_LATENCY_SHFIT);
 -

On a huch I went and tried this same treatment on intel_dp.c and it
fixes the remaining link training issues [1] I've been seeing \o/
I still need to try with the other DP display that was having these
problems, but that'll have to wait until tomorrow.

So please respin this with the same change made to intel_dp.c (someone
should really eliminate the code duplication we have going on there), and
assuming my test with the other display goes as well I can then post
some DPIO lane power gating patches which I've been holding back because
they made the problem worse.

[1] http://lists.freedesktop.org/archives/intel-gfx/2015-February/059877.html


   /* Set the upar bit */
   data = (i == 1) ? 0x0 : 0x1;
   vlv_dpio_write(dev_priv, pipe, CHV_TX_DW14(ch, i),
 -- 
 1.7.9.5
 
 ___
 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

Re: [Intel-gfx] [PATCH] drm/i915: Fix the VBT child device parsing for BSW

[Damien Lespiau]

On Wed, Mar 25, 2015 at 06:45:58PM +0200, ville.syrj...@linux.intel.com wrote:
 +static union child_device_config *
 +child_device_ptr(struct bdb_general_definitions *p_defs, int i)
 +{
 + return (void *) p_defs-devices[i * p_defs-child_dev_size];
 +}

Actually this looks wrong. We're doing:

  p_defs-devices + sizeof(union child_device_config) * i * child_dev_size

instead of:

  (u8)p_defs-devices + i * child_dev_size

?

I wondered about the (void *) cast precedence over [], because gcc
treats void * pointer arithmetic with a size of 1, but [] will be done
first apparently.

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

[Intel-gfx] [PATCH] drm/i915: Allocate connector state together with the connectors

[Ander Conselvan de Oliveira]

Connector states were being allocated in intel_setup_outputs() in a loop
over all connectors. That meant hot-added connectors would have a NULL
state. Since the change to use a struct drm_atomic_state for the legacy
modeset, connector states are necessary for the i915 driver to function
properly, so that would lead to oopses.

Signed-off-by: Ander Conselvan de Oliveira 
ander.conselvan.de.olive...@intel.com
---

Hi Nicolas,

Could you please test if this patch solves the issue?

Thanks,
Ander



 drivers/gpu/drm/i915/intel_crt.c |  2 +-
 drivers/gpu/drm/i915/intel_ddi.c |  4 +--
 drivers/gpu/drm/i915/intel_display.c | 62 
 drivers/gpu/drm/i915/intel_dp.c  |  2 +-
 drivers/gpu/drm/i915/intel_dp_mst.c  |  2 +-
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 drivers/gpu/drm/i915/intel_dsi.c |  2 +-
 drivers/gpu/drm/i915/intel_dvo.c |  2 +-
 drivers/gpu/drm/i915/intel_hdmi.c|  2 +-
 drivers/gpu/drm/i915/intel_lvds.c|  6 
 drivers/gpu/drm/i915/intel_sdvo.c| 22 +++--
 drivers/gpu/drm/i915/intel_tv.c  |  2 +-
 12 files changed, 64 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index fa5699c..93bb515 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -851,7 +851,7 @@ void intel_crt_init(struct drm_device *dev)
if (!crt)
return;
 
-   intel_connector = kzalloc(sizeof(*intel_connector), GFP_KERNEL);
+   intel_connector = intel_connector_alloc();
if (!intel_connector) {
kfree(crt);
return;
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index db35194..2e005e3 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2102,7 +2102,7 @@ intel_ddi_init_dp_connector(struct intel_digital_port 
*intel_dig_port)
struct intel_connector *connector;
enum port port = intel_dig_port-port;
 
-   connector = kzalloc(sizeof(*connector), GFP_KERNEL);
+   connector = intel_connector_alloc();
if (!connector)
return NULL;
 
@@ -2121,7 +2121,7 @@ intel_ddi_init_hdmi_connector(struct intel_digital_port 
*intel_dig_port)
struct intel_connector *connector;
enum port port = intel_dig_port-port;
 
-   connector = kzalloc(sizeof(*connector), GFP_KERNEL);
+   connector = intel_connector_alloc();
if (!connector)
return NULL;
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 739f61f..afff86f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5666,6 +5666,34 @@ static void intel_connector_check_state(struct 
intel_connector *connector)
}
 }
 
+int intel_connector_init(struct intel_connector *connector)
+{
+   struct drm_connector_state *connector_state;
+
+   connector_state = kzalloc(sizeof *connector_state, GFP_KERNEL);
+   if (!connector_state)
+   return -ENOMEM;
+
+   connector-base.state = connector_state;
+   return 0;
+}
+
+struct intel_connector *intel_connector_alloc(void)
+{
+   struct intel_connector *connector;
+
+   connector = kzalloc(sizeof *connector, GFP_KERNEL);
+   if (!connector)
+   return NULL;
+
+   if (intel_connector_init(connector)  0) {
+   kfree(connector);
+   return NULL;
+   }
+
+   return connector;
+}
+
 /* Even simpler default implementation, if there's really no special case to
  * consider. */
 void intel_connector_dpms(struct drm_connector *connector, int mode)
@@ -13089,7 +13117,6 @@ static void intel_setup_outputs(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_encoder *encoder;
-   struct drm_connector *connector;
bool dpd_is_edp = false;
 
intel_lvds_init(dev);
@@ -13225,39 +13252,6 @@ static void intel_setup_outputs(struct drm_device *dev)
if (SUPPORTS_TV(dev))
intel_tv_init(dev);
 
-   /*
-* FIXME:  We don't have full atomic support yet, but we want to be
-* able to enable/test plane updates via the atomic interface in the
-* meantime.  However as soon as we flip DRIVER_ATOMIC on, the DRM core
-* will take some atomic codepaths to lookup properties during
-* drmModeGetConnector() that unconditionally dereference
-* connector-state.
-*
-* We create a dummy connector state here for each connector to ensure
-* the DRM core doesn't try to dereference a NULL connector-state.
-* The actual connector properties will never be updated or contain
-* useful information, but since we're doing this specifically for
-* testing/debug of the plane operations (and only when a specific
-* kernel module option is 

[Intel-gfx] [PATCH i-g-t v2 1/2] tests: create a single combined test list

[Thomas Wood]

All tests now respond in a consistent way such that separate lists for
tests with and without subtests are no longer necessary.

v2: fix other references to the test list

Signed-off-by: Thomas Wood thomas.w...@intel.com
---
 docs/reference/intel-gpu-tools/Makefile.am |  2 +-
 lib/tests/igt_command_line.sh  |  2 +-
 tests/Makefile.am  | 23 ---
 3 files changed, 6 insertions(+), 21 deletions(-)

diff --git a/docs/reference/intel-gpu-tools/Makefile.am 
b/docs/reference/intel-gpu-tools/Makefile.am
index fa19701..0033295 100644
--- a/docs/reference/intel-gpu-tools/Makefile.am
+++ b/docs/reference/intel-gpu-tools/Makefile.am
@@ -1,6 +1,6 @@
 ## Process this file with automake to produce Makefile.in
 
-TESTLISTS = $(top_builddir)/tests/single-tests.txt 
$(top_builddir)/tests/multi-tests.txt
+TESTLISTS = $(top_builddir)/tests/test-list.txt
 KEYWORDS = 
(invalid|hang|swap|thrash|crc|tiled|tiling|rte|ctx|render|blt|bsd|vebox|exec|rpm)
 
 xml/igt_test_programs_%_programs.xml: $(TESTLISTS)
diff --git a/lib/tests/igt_command_line.sh b/lib/tests/igt_command_line.sh
index a057943..e83a548 100755
--- a/lib/tests/igt_command_line.sh
+++ b/lib/tests/igt_command_line.sh
@@ -25,7 +25,7 @@
 # Check that command line handling works consistently across all tests
 #
 
-TESTLIST=`cat $top_builddir/tests/single-tests.txt 
$top_builddir/tests/multi-tests.txt`
+TESTLIST=`cat $top_builddir/tests/test-list.txt`
 if [ $? -ne 0 ]; then
echo Error: Could not read test lists
exit 99
diff --git a/tests/Makefile.am b/tests/Makefile.am
index dc864f4..11f7f96 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -5,26 +5,11 @@ if HAVE_NOUVEAU
 endif
 
 if BUILD_TESTS
-all-local: single-tests.txt multi-tests.txt
+all-local: test-list.txt
 
-list-single-tests:
-   @echo TESTLIST
-   @echo ${single_kernel_tests}
-   @echo END TESTLIST
-
-list-multi-tests:
-   @echo TESTLIST
-   @echo ${multi_kernel_tests}
-   @echo END TESTLIST
-
-single-tests.txt: Makefile.sources
-   @echo TESTLIST  $@
-   @echo ${single_kernel_tests}  $@
-   @echo END TESTLIST  $@
-
-multi-tests.txt: Makefile.sources
+test-list.txt: Makefile.sources
@echo TESTLIST  $@
-   @echo ${multi_kernel_tests}  $@
+   @echo ${single_kernel_tests} ${multi_kernel_tests}  $@
@echo END TESTLIST  $@
 
 noinst_PROGRAMS = \
@@ -52,7 +37,7 @@ dist_pkgdata_DATA = \
 EXTRA_PROGRAMS = $(HANG)
 EXTRA_DIST = $(common_files)
 
-CLEANFILES = $(EXTRA_PROGRAMS) single-tests.txt multi-tests.txt
+CLEANFILES = $(EXTRA_PROGRAMS) test-list.txt
 
 AM_CFLAGS = $(DRM_CFLAGS) $(CWARNFLAGS) $(DEBUG_CFLAGS)\
-I$(srcdir)/.. \
-- 
2.1.0

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

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Clear crtc atomic flags at beginning of transaction

[Daniel Vetter]

On Thu, Apr 09, 2015 at 08:03:35AM -0700, Matt Roper wrote:
 On Thu, Apr 09, 2015 at 02:48:43PM +0200, Daniel Vetter wrote:
  On Wed, Apr 08, 2015 at 06:56:54PM -0700, Matt Roper wrote:
   Once we have full atomic modeset, these kind of flags should be in a
   real intel_crtc_state that's tracked properly.  In the meantime, make
   sure we clear out any old flags at the beginning of a transaction so
   that we don't wind up seeing leftover flags from old transactions that
   were checked, but never went to the commit step.
   
   A simple memset would have done here, but I expect there to be a few
   more things that we *don't* want to clear that get added into this
   structure before we're ready to kill off and roll everything into the
   CRTC state.
   
   Signed-off-by: Matt Roper matthew.d.ro...@intel.com
  
  Not sure whether this helps a lot with moving intel_crtc-atomic into
  intel_crtc_state. We probably want to just move things one-by-one to
  reduce the overall churn, and then we can add them one-by-one to the intel
  crtc_state_duplicate function.
  
  Or do you have some bigger plans here?
  -Daniel
 
 My in-progress WM work had to stick some other things in
 intel_crtc-atomic, but maybe with Ander's latest patch sets we're close
 enough that I can rewrite those to use crtc_state instead; I'll have to
 go back and check.
 
 Regardless, I think we do still have a bug today where an uncommitted
 transaction (e.g., because check or prepare fail) will leave stale flags
 in intel_crtc-atomic that the next transaction doesn't realize it needs
 to clear.  We either need to clear those out (as I'm doing here,
 although a simple memset would work too), or we need to transition all
 those flags over to CRTC state and kill off the hacky intel_crtc-atomic
 structure.

Yeah I agree that we need the memset. Can you resend just that one,
without the wrapping please?
-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 4/6] drm/tegra: gem: Use drm_clflush_*() functions

[Thierry Reding]

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

Instead of going through the DMA mapping API for cache maintenance, use
the drm_clflush_*() family of functions to achieve the same effect.

Signed-off-by: Thierry Reding tred...@nvidia.com
---
 drivers/gpu/drm/tegra/Kconfig |  1 +
 drivers/gpu/drm/tegra/gem.c   | 42 +++---
 2 files changed, 12 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 74d9d621453d..4901f20f99a1 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -4,6 +4,7 @@ config DRM_TEGRA
depends on COMMON_CLK
depends on DRM
depends on RESET_CONTROLLER
+   select DRM_CACHE
select DRM_KMS_HELPER
select DRM_MIPI_DSI
select DRM_PANEL
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 499f86739786..11e97a46e63d 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -203,48 +203,28 @@ static void tegra_bo_free(struct drm_device *drm, struct 
tegra_bo *bo)
 
 static int tegra_bo_get_pages(struct drm_device *drm, struct tegra_bo *bo)
 {
-   struct scatterlist *s;
-   struct sg_table *sgt;
-   unsigned int i;
-
bo-pages = drm_gem_get_pages(bo-gem);
if (IS_ERR(bo-pages))
return PTR_ERR(bo-pages);
 
bo-num_pages = bo-gem.size  PAGE_SHIFT;
 
-   sgt = drm_prime_pages_to_sg(bo-pages, bo-num_pages);
-   if (IS_ERR(sgt))
-   goto put_pages;
+   bo-sgt = drm_prime_pages_to_sg(bo-pages, bo-num_pages);
+   if (IS_ERR(bo-sgt)) {
+   drm_gem_put_pages(bo-gem, bo-pages, false, false);
+   return PTR_ERR(bo-sgt);
+   }
 
-#ifndef CONFIG_ARM64
/*
-* Fake up the SG table so that dma_map_sg() can be used to flush the
-* pages associated with it. Note that this relies on the fact that
-* the DMA API doesn't hook into IOMMU on Tegra, therefore mapping is
-* only cache maintenance.
-*
-* TODO: Replace this by drm_clflash_sg() once it can be implemented
-* without relying on symbols that are not exported.
+* Pages allocated by shmemfs are marked dirty but not flushed on
+* ARMv7 and ARMv8. Since this memory is used to back framebuffers,
+* however, they must be forced out of caches to avoid corruption
+* on screen later on as the result of dirty cache-lines being
+* flushed.
 */
-   for_each_sg(sgt-sgl, s, sgt-nents, i)
-   sg_dma_address(s) = sg_phys(s);
-
-   if (dma_map_sg(drm-dev, sgt-sgl, sgt-nents, DMA_TO_DEVICE) == 0)
-   goto release_sgt;
-#endif
-
-   bo-sgt = sgt;
+   drm_clflush_sg(bo-sgt);
 
return 0;
-
-release_sgt:
-   sg_free_table(sgt);
-   kfree(sgt);
-   sgt = ERR_PTR(-ENOMEM);
-put_pages:
-   drm_gem_put_pages(bo-gem, bo-pages, false, false);
-   return PTR_ERR(sgt);
 }
 
 static int tegra_bo_alloc(struct drm_device *drm, struct tegra_bo *bo)
-- 
2.3.2

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

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Lookup CRTC for plane directly

[Matt Roper]

On Thu, Apr 09, 2015 at 02:44:05PM +0200, Daniel Vetter wrote:
 On Wed, Apr 08, 2015 at 06:56:52PM -0700, Matt Roper wrote:
  Various places in the atomic plane code obtain the CRTC via
  plane_state-crtc.  But plane_state-crtc is NULL when disabling the
  plane, so the code will fall back to looking at the old CRTC value in
  plane-crtc in that case.  This isn't going to work when we start
  supporting non-blocking flips (since the legacy plane-crtc pointer will
  already be updated to its new value before the asynchronous workqueue
  task runs the plane commit function).  The code is also fragile in
  general (we have to be careful when doing stuff like updating properties
  on a disabled plane).  Since Intel hardware has a fixed plane to pipe
  mapping, let's just lookup the CRTC via that fixed mapping and avoid
  future mistakes.
  
  Cc: Vivek Kasireddy vivek.kasire...@intel.com
  Reported-by: Vivek Kasireddy vivek.kasire...@intel.com
  Signed-off-by: Matt Roper matthew.d.ro...@intel.com
 
 Because I'm a lazy reviewer ... does cocci agree that you've spotted all
 the drm_plane-crtc references?
 -Daniel

According to

@@ struct drm_plane *P; @@
* P-crtc

We have four remaining uses of drm_plane-crtc in the driver.  Two of
them are just updating it to properly mirror the value of
plane-state-crtc (e.g., in the load detect code), so those are good.
The other two uses are in intel_plane_restore(), which is intentionally
looking at what's already been committed and isn't in danger of being
used in the non-blocking/async code flow.  So I think we're okay now.


Matt

 
  ---
   drivers/gpu/drm/i915/intel_atomic_plane.c | 12 ++--
   drivers/gpu/drm/i915/intel_display.c  |  8 
   drivers/gpu/drm/i915/intel_drv.h  |  7 +++
   drivers/gpu/drm/i915/intel_sprite.c   |  4 ++--
   4 files changed, 19 insertions(+), 12 deletions(-)
  
  diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
  b/drivers/gpu/drm/i915/intel_atomic_plane.c
  index 90c4a82..740d1a6 100644
  --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
  +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
  @@ -116,19 +116,19 @@ static int intel_plane_atomic_check(struct drm_plane 
  *plane,
  struct intel_plane_state *intel_state = to_intel_plane_state(state);
  bool active;
   
  -   crtc = crtc ? crtc : plane-crtc;
  +   crtc = intel_get_crtc_for_drm_plane(plane);
  intel_crtc = to_intel_crtc(crtc);
   
  intel_crtc_state = intel_crtc_state_for_plane(intel_state);
  active = intel_crtc_state-base.enable;
   
  /*
  -* Both crtc and plane-crtc could be NULL if we're updating a
  -* property while the plane is disabled.  We don't actually have
  -* anything driver-specific we need to test in that case, so
  -* just return success.
  +* Both state-crtc and plane-state-crtc could be NULL if we're
  +* updating a property while the plane is disabled.  We don't actually
  +* have anything driver-specific we need to test in that case, so just
  +* return success.
   */
  -   if (!crtc)
  +   if (!state-crtc  !plane-state-crtc)
  return 0;
   
  /*
  diff --git a/drivers/gpu/drm/i915/intel_display.c 
  b/drivers/gpu/drm/i915/intel_display.c
  index 88b0f69..1cf91ad 100644
  --- a/drivers/gpu/drm/i915/intel_display.c
  +++ b/drivers/gpu/drm/i915/intel_display.c
  @@ -12625,7 +12625,7 @@ intel_check_primary_plane(struct drm_plane *plane,
  bool active;
  int ret;
   
  -   crtc = crtc ? crtc : plane-crtc;
  +   crtc = intel_get_crtc_for_drm_plane(plane);
  intel_crtc = to_intel_crtc(crtc);
   
  intel_crtc_state = intel_crtc_state_for_plane(state);
  @@ -12694,7 +12694,7 @@ intel_commit_primary_plane(struct drm_plane *plane,
  struct drm_rect *src = state-src;
  bool active;
   
  -   crtc = crtc ? crtc : plane-crtc;
  +   crtc = intel_get_crtc_for_drm_plane(plane);
  intel_crtc = to_intel_crtc(crtc);
   
  intel_crtc_state = intel_crtc_state_for_plane(state);
  @@ -12916,7 +12916,7 @@ intel_check_cursor_plane(struct drm_plane *plane,
  bool active;
  int ret;
   
  -   crtc = crtc ? crtc : plane-crtc;
  +   crtc = intel_get_crtc_for_drm_plane(plane);
  intel_crtc = to_intel_crtc(crtc);
   
  intel_crtc_state = intel_crtc_state_for_plane(state);
  @@ -12977,7 +12977,7 @@ intel_commit_cursor_plane(struct drm_plane *plane,
  uint32_t addr;
  bool active;
   
  -   crtc = crtc ? crtc : plane-crtc;
  +   crtc = intel_get_crtc_for_drm_plane(plane);
  intel_crtc = to_intel_crtc(crtc);
   
  intel_crtc_state = intel_crtc_state_for_plane(state);
  diff --git a/drivers/gpu/drm/i915/intel_drv.h 
  b/drivers/gpu/drm/i915/intel_drv.h
  index 71e0152..d5ea24f 100644
  --- a/drivers/gpu/drm/i915/intel_drv.h
  +++ b/drivers/gpu/drm/i915/intel_drv.h
  @@ -731,6 +731,13 @@ intel_get_crtc_for_plane(struct drm_device *dev, int 
  plane)
  return dev_priv-plane_to_crtc_mapping[plane];
   

[Intel-gfx] [PATCH i-g-t 2/2] tests: install the test list

[Thomas Wood]

Cc: Joonas Lahtinen joonas.lahti...@linux.intel.com
Signed-off-by: Thomas Wood thomas.w...@intel.com
---
 tests/Makefile.am | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/Makefile.am b/tests/Makefile.am
index 11f7f96..d5fb4fd 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -5,8 +5,6 @@ if HAVE_NOUVEAU
 endif
 
 if BUILD_TESTS
-all-local: test-list.txt
-
 test-list.txt: Makefile.sources
@echo TESTLIST  $@
@echo ${single_kernel_tests} ${multi_kernel_tests}  $@
@@ -34,6 +32,8 @@ dist_pkgdata_DATA = \
$(IMAGES) \
$(NULL)
 
+pkgdata_DATA = test-list.txt
+
 EXTRA_PROGRAMS = $(HANG)
 EXTRA_DIST = $(common_files)
 
-- 
2.1.0

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

[Intel-gfx] [PATCH 1/6] drm/cache: Build-in drm_clflush_*() functions

[Thierry Reding]

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

Irrespective of whether or not the DRM core is built as a module, build
the cache flush functions into the kernel. This is required because the
implementation may require functions that shouldn't be exported to most
drivers. DRM is somewhat of a special case here because it requires the
cache maintenance functions to properly flush pages backed by shmemfs.
These pages are directly given to display hardware for scanout, so they
must be purged from any caches to avoid visual corruption on screen.

To achieve this, add a new boolean Kconfig symbol that drivers can
select if they use any of these functions. drm_cache.c is then built if
and only if this symbol is selected. TTM and the i915 driver already use
these functions, so make them select DRM_CACHE.

Suggested-by: Arnd Bergmann a...@arndb.de
Cc: Daniel Vetter daniel.vet...@intel.com
Cc: Jani Nikula jani.nik...@linux.intel.com
Signed-off-by: Thierry Reding tred...@nvidia.com
---
 drivers/gpu/drm/Kconfig  | 5 +
 drivers/gpu/drm/Makefile | 3 ++-
 drivers/gpu/drm/i915/Kconfig | 1 +
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 47f2ce81b412..25bffdb89304 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -21,6 +21,10 @@ menuconfig DRM
  details.  You should also select and configure AGP
  (/dev/agpgart) support if it is available for your platform.
 
+config DRM_CACHE
+   bool
+   depends on DRM
+
 config DRM_MIPI_DSI
bool
depends on DRM
@@ -55,6 +59,7 @@ config DRM_LOAD_EDID_FIRMWARE
 config DRM_TTM
tristate
depends on DRM
+   select DRM_CACHE
help
  GPU memory management subsystem for devices with multiple
  GPU memory types. Will be enabled automatically if a device driver
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 7d4944e1a60c..1ad54a0e4467 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -4,7 +4,7 @@
 
 ccflags-y := -Iinclude/drm
 
-drm-y   := drm_auth.o drm_bufs.o drm_cache.o \
+drm-y   := drm_auth.o drm_bufs.o \
drm_context.o drm_dma.o \
drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
drm_lock.o drm_memory.o drm_drv.o drm_vm.o \
@@ -33,6 +33,7 @@ obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
 CFLAGS_drm_trace_points.o := -I$(src)
 
 obj-$(CONFIG_DRM)  += drm.o
+obj-$(CONFIG_DRM_CACHE) += drm_cache.o
 obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
 obj-$(CONFIG_DRM_TTM)  += ttm/
 obj-$(CONFIG_DRM_TDFX) += tdfx/
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 74acca9bcd9d..237be03e8a7c 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -10,6 +10,7 @@ config DRM_I915
# the shmem_readpage() which depends upon tmpfs
select SHMEM
select TMPFS
+   select DRM_CACHE
select DRM_KMS_HELPER
select DRM_PANEL
select DRM_MIPI_DSI
-- 
2.3.2

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

[Intel-gfx] [PATCH 5/6] drm/armada: gem: Use drm_clflush_*() functions

[Thierry Reding]

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

Instead of going through the DMA mapping API for cache maintenance, use
the drm_clflush_*() family of functions to achieve the same effect.

Cc: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Thierry Reding tred...@nvidia.com
---
 drivers/gpu/drm/armada/Kconfig  |  1 +
 drivers/gpu/drm/armada/armada_gem.c | 13 ++---
 2 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/armada/Kconfig b/drivers/gpu/drm/armada/Kconfig
index 50ae88ad4d76..7b7070128a05 100644
--- a/drivers/gpu/drm/armada/Kconfig
+++ b/drivers/gpu/drm/armada/Kconfig
@@ -4,6 +4,7 @@ config DRM_ARMADA
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+   select DRM_CACHE
select DRM_KMS_HELPER
select DRM_KMS_FB_HELPER
help
diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index 580e10acaa3a..c2d4414031ab 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -453,19 +453,14 @@ armada_gem_prime_map_dma_buf(struct dma_buf_attachment 
*attach,
sg_set_page(sg, page, PAGE_SIZE, 0);
}
 
-   if (dma_map_sg(attach-dev, sgt-sgl, sgt-nents, dir) == 0) {
-   num = sgt-nents;
-   goto release;
-   }
+   drm_clflush_sg(sgt);
} else if (dobj-page) {
/* Single contiguous page */
if (sg_alloc_table(sgt, 1, GFP_KERNEL))
goto free_sgt;
 
sg_set_page(sgt-sgl, dobj-page, dobj-obj.size, 0);
-
-   if (dma_map_sg(attach-dev, sgt-sgl, sgt-nents, dir) == 0)
-   goto free_table;
+   drm_clflush_sg(sgt);
} else if (dobj-linear) {
/* Single contiguous physical region - no struct page */
if (sg_alloc_table(sgt, 1, GFP_KERNEL))
@@ -480,7 +475,6 @@ armada_gem_prime_map_dma_buf(struct dma_buf_attachment 
*attach,
  release:
for_each_sg(sgt-sgl, sg, num, i)
page_cache_release(sg_page(sg));
- free_table:
sg_free_table(sgt);
  free_sgt:
kfree(sgt);
@@ -494,9 +488,6 @@ static void armada_gem_prime_unmap_dma_buf(struct 
dma_buf_attachment *attach,
struct armada_gem_object *dobj = drm_to_armada_gem(obj);
int i;
 
-   if (!dobj-linear)
-   dma_unmap_sg(attach-dev, sgt-sgl, sgt-nents, dir);
-
if (dobj-obj.filp) {
struct scatterlist *sg;
for_each_sg(sgt-sgl, sg, sgt-nents, i)
-- 
2.3.2

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

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Make atomic use in-flight state for CRTC active value

[Matt Roper]

On Thu, Apr 09, 2015 at 04:45:04PM +0200, Daniel Vetter wrote:
 On Thu, Apr 09, 2015 at 07:00:31AM -0700, Matt Roper wrote:
  On Thu, Apr 09, 2015 at 02:42:36PM +0200, Daniel Vetter wrote:
   On Wed, Apr 08, 2015 at 06:56:51PM -0700, Matt Roper wrote:
Our atomic plane code currently uses intel_crtc-active to determine
how/when to update some derived state values.  This works fine for pure
plane updates at the moment since the CRTC state itself isn't changed as
part of the operation.  However as we convert more of our driver
internals over to atomic modesetting, we need to look at whether the
CRTC will be active at the *end* of the atomic transaction (which may
not match the currently committed state).

The in-flight value we want to use is generally in a crtc_state object
associated with our top-level atomic transaction.  However there are a
few cases where this isn't the case:

 * While using transitional atomic helpers (as we are at the moment),
   SetPlane() calls will operate on orphaned plane states that aren't
   part of a top-level atomic transaction.  In this case, we're not
   touching the CRTC state, so it's fine to use the already-committed
   value from crtc-state.

 * While updating properties of a disabled plane, we'll have a top-level
   atomic state, but it may not contain the CRTC state we're looking
   for.  Once again, this means we're not actually touching any CRTC
   state so it's safe to use the value from crtc-state directly.

Signed-off-by: Matt Roper matthew.d.ro...@intel.com
---
 drivers/gpu/drm/i915/intel_atomic_plane.c | 11 +++--
 drivers/gpu/drm/i915/intel_display.c  | 73 
+--
 drivers/gpu/drm/i915/intel_drv.h  |  3 ++
 drivers/gpu/drm/i915/intel_sprite.c   | 16 +--
 4 files changed, 93 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 976b891..90c4a82 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -111,12 +111,17 @@ static int intel_plane_atomic_check(struct 
drm_plane *plane,
 {
struct drm_crtc *crtc = state-crtc;
struct intel_crtc *intel_crtc;
+   struct intel_crtc_state *intel_crtc_state;
struct intel_plane *intel_plane = to_intel_plane(plane);
struct intel_plane_state *intel_state = 
to_intel_plane_state(state);
+   bool active;
 
crtc = crtc ? crtc : plane-crtc;
intel_crtc = to_intel_crtc(crtc);
 
+   intel_crtc_state = intel_crtc_state_for_plane(intel_state);
+   active = intel_crtc_state-base.enable;
+
/*
 * Both crtc and plane-crtc could be NULL if we're updating a
 * property while the plane is disabled.  We don't actually have
@@ -143,10 +148,8 @@ static int intel_plane_atomic_check(struct 
drm_plane *plane,
/* Clip all planes to CRTC size, or 0x0 if CRTC is disabled */
intel_state-clip.x1 = 0;
intel_state-clip.y1 = 0;
-   intel_state-clip.x2 =
-   intel_crtc-active ? intel_crtc-config-pipe_src_w : 0;
-   intel_state-clip.y2 =
-   intel_crtc-active ? intel_crtc-config-pipe_src_h : 0;
+   intel_state-clip.x2 = active ? intel_crtc_state-pipe_src_w : 
0;
+   intel_state-clip.y2 = active ? intel_crtc_state-pipe_src_h : 
0;
 
/*
 * Disabling a plane is always okay; we just need to update
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7bfe2af..88b0f69 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12562,6 +12562,53 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
}
 }
 
+/**
+ * intel_crtc_state_for_plane - Obtain CRTC state for a plane
+ * @pstate: plane state to lookup corresponding crtc state for
+ *
+ * When working with a top-level atomic transaction (drm_atomic_state),
+ * a CRTC state should be present that corresponds to the provided
+ * plane state; this function provides a quick way to fetch that
+ * CRTC state.  In cases where we have a plane state unassociated with 
any
+ * top-level atomic transaction (e.g., while using the transitional 
atomic
+ * helpers), the current CRTC state from crtc-state will be returned
+ * instead.
+ */
+struct intel_crtc_state *
+intel_crtc_state_for_plane(struct intel_plane_state *pstate)
+{
+   struct drm_atomic_state *state = pstate-base.state;
+   struct intel_plane *plane = to_intel_plane(pstate-base.plane);
+   struct drm_crtc *crtc = 

Re: [Intel-gfx] [PATCH 1/5] mutex: Export an interface to wrap a mutex lock

[Joonas Lahtinen]

Hi,

On ti, 2015-04-07 at 17:31 +0100, Chris Wilson wrote:
 In i915, we have a big mutex around our device struct - every time before
 we attempt to communicate with the GPU, we acquire the mutex. This makes
 it a convenient juncture to place our GPU error handling - before we take
 the mutex we first check whether the GPU is hung or whether we are in
 the process of recovering from a GPU hang. So we wrap the call to
 mutex_lock() alongside our additional error handling routines.
 
 The downside of using a wrapper around mutex_lock() is that lockdep and
 lockstat cannot discriminate the true callers of mutex_lock(). Unless we
 provide a means for the wrapper to pass that information down.
 
 It also appears that i915 is almost unique in this manner of wrapping
 mutex_lock(), with only one or two other potential candidates for using
 this interface.
 
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Cc: Ben Widawsky benjamin.widaw...@intel.com

Seems like reasonable thing to do, I'd split this to two completely
separate parts, the kernel change and the gem side.

You might want to CC the kernel side with a little bigger audience, as
this could be called invasive change. Not by changing existing stuff,
but maybe somebody with much experience in the mutex subsystem might
want to object exposing such functionality (maybe to keep people from
using mutexes the way we do it) for reasons beyond me.

Regards, joonas

 ---
  drivers/gpu/drm/i915/i915_gem.c |  4 +++-
  include/linux/mutex.h   |  9 +
  kernel/locking/mutex.c  | 36 
  3 files changed, 48 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
 index 267fdf0f46ae..7ab8e0039790 100644
 --- a/drivers/gpu/drm/i915/i915_gem.c
 +++ b/drivers/gpu/drm/i915/i915_gem.c
 @@ -135,7 +135,9 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
   if (ret)
   return ret;
  
 - ret = mutex_lock_interruptible(dev-struct_mutex);
 + ret = mutex_lock_wrapper(dev-struct_mutex,
 +  TASK_INTERRUPTIBLE,
 +  _RET_IP_);
   if (ret)
   return ret;
  
 diff --git a/include/linux/mutex.h b/include/linux/mutex.h
 index 2cb7531e7d7a..3f6030b3f5aa 100644
 --- a/include/linux/mutex.h
 +++ b/include/linux/mutex.h
 @@ -142,10 +142,15 @@ extern int __must_check 
 mutex_lock_interruptible_nested(struct mutex *lock,
   unsigned int subclass);
  extern int __must_check mutex_lock_killable_nested(struct mutex *lock,
   unsigned int subclass);
 +extern int __must_check mutex_lock_wrapper_nested(struct mutex *lock,
 +   unsigned int subclass,
 +   long state,
 +   unsigned long ip);
  
  #define mutex_lock(lock) mutex_lock_nested(lock, 0)
  #define mutex_lock_interruptible(lock) mutex_lock_interruptible_nested(lock, 
 0)
  #define mutex_lock_killable(lock) mutex_lock_killable_nested(lock, 0)
 +#define mutex_lock_wrapper(lock, state, ip) mutex_lock_wrapper_nested(lock, 
 0, state, ip)
  
  #define mutex_lock_nest_lock(lock, nest_lock)
 \
  do { \
 @@ -157,10 +162,14 @@ do {
 \
  extern void mutex_lock(struct mutex *lock);
  extern int __must_check mutex_lock_interruptible(struct mutex *lock);
  extern int __must_check mutex_lock_killable(struct mutex *lock);
 +extern int __must_check mutex_lock_wrapper(struct mutex *lock,
 +long state,
 +unsigned long ip);
  
  # define mutex_lock_nested(lock, subclass) mutex_lock(lock)
  # define mutex_lock_interruptible_nested(lock, subclass) 
 mutex_lock_interruptible(lock)
  # define mutex_lock_killable_nested(lock, subclass) mutex_lock_killable(lock)
 +# define mutex_lock_wrapper_nested(lock, subclass, state, ip) 
 mutex_lock_wrapper(lock, state, ip)
  # define mutex_lock_nest_lock(lock, nest_lock) mutex_lock(lock)
  #endif
  
 diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
 index 94674e5919cb..098b9e71ada1 100644
 --- a/kernel/locking/mutex.c
 +++ b/kernel/locking/mutex.c
 @@ -658,6 +658,17 @@ mutex_lock_interruptible_nested(struct mutex *lock, 
 unsigned int subclass)
  
  EXPORT_SYMBOL_GPL(mutex_lock_interruptible_nested);
  
 +int __sched
 +mutex_lock_wrapper_nested(struct mutex *lock, unsigned int subclass,
 +   long state, unsigned long ip)
 +{
 + might_sleep();
 + return __mutex_lock_common(lock, state,
 +subclass, NULL, ip, NULL, 0);
 +}
 +
 +EXPORT_SYMBOL_GPL(mutex_lock_wrapper_nested);
 +
  static inline int
  

Re: [Intel-gfx] [PATCH v2 18/18] Documentation/drm: kerneldoc for GuC

[shuang . he]

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
Task id: 6129
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV -1  276/276  275/276
ILK -2  302/302  300/302
SNB -1  313/313  312/313
IVB -1  337/337  336/337
BYT -1  286/286  285/286
HSW -1  395/395  394/395
BDW -3  321/321  318/321
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
*PNV  igt@drv_debugfs_reader  PASS(3)  DMESG_WARN(1)
(dmesg patch applied)INFO:trying_to_register_non-static_key@INFO: trying to 
register non-static key.
*ILK  igt@drv_debugfs_reader  PASS(3)  DMESG_WARN(1)
(dmesg patch applied)INFO:trying_to_register_non-static_key@INFO: trying to 
register non-static key.
*ILK  igt@gem_fenced_exec_thrash@no-spare-fences-busy  PASS(3)  
DMESG_WARN(1)
(dmesg patch 
applied)drm:i915_hangcheck_elapsed[i915]]*ERROR*Hangcheck_timer_elapsed...bsd_ring_idle@Hangcheck
 timer elapsed... bsd ring idle
*SNB  igt@drv_debugfs_reader  PASS(3)  DMESG_WARN(1)
(dmesg patch applied)INFO:trying_to_register_non-static_key@INFO: trying to 
register non-static key.
*IVB  igt@drv_debugfs_reader  PASS(3)  DMESG_WARN(1)
(dmesg patch applied)INFO:trying_to_register_non-static_key@INFO: trying to 
register non-static key.
*BYT  igt@drv_debugfs_reader  PASS(3)  DMESG_WARN(1)
(dmesg patch applied)INFO:trying_to_register_non-static_key@INFO: trying to 
register non-static key.
*HSW  igt@drv_debugfs_reader  PASS(3)  DMESG_WARN(1)
(dmesg patch applied)INFO:trying_to_register_non-static_key@INFO: trying to 
register non-static key.
*BDW  igt@drm_vma_limiter  PASS(3)  DMESG_WARN(1)
(dmesg patch applied)INFO:possible_circular_locking_dependency_detected@INFO: 
possible circular locking dependency detected
*BDW  igt@gem_dummy_reloc_loop@render  PASS(3)  DMESG_WARN(1)
(dmesg patch 
applied)drm:i915_hangcheck_elapsed[i915]]*ERROR*Hangcheck_timer_elapsed...render_ring_idle@Hangcheck
 timer elapsed... render ring idle
*BDW  igt@gem_exec_faulting_reloc@no-prefault  PASS(3)  DMESG_WARN(1)
(dmesg patch applied)INFO:possible_circular_locking_dependency_detected@INFO: 
possible circular locking dependency detected
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] [PATCH 1/2] drm/i915: Fix locking in DRRS flush/invalidate hooks

[Daniel Vetter]

We must acquire the mutex before we can check drrs.dp, otherwise
someone might sneak in with a modeset, clear the pointer after we've
checked it and then the code will Oops.

This issue has been introduced in

commit a93fad0f7fb8a3ff12e8814b630648f6d187954c
Author: Vandana Kannan vandana.kan...@intel.com
Date:   Sat Jan 10 02:25:59 2015 +0530

drm/i915: DRRS calls based on frontbuffer

v2: Don't blow up on uninitialized mutex and work item by checking
whether DRRS is support or not first. Also unconditionally initialize
the mutex/work item to avoid future trouble.

Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Ramalingam C ramalinga...@intel.com
Cc: Rodrigo Vivi rodrigo.v...@intel.com
Cc: Vandana Kannan vandana.kan...@intel.com
Cc: sta...@vger.kernel.org (4.0+ only)
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 1b87969536ff..d846738365cb 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5170,7 +5170,6 @@ static void intel_edp_drrs_downclock_work(struct 
work_struct *work)
downclock_mode-vrefresh);
 
 unlock:
-
mutex_unlock(dev_priv-drrs.mutex);
 }
 
@@ -5192,12 +5191,17 @@ void intel_edp_drrs_invalidate(struct drm_device *dev,
struct drm_crtc *crtc;
enum pipe pipe;
 
-   if (!dev_priv-drrs.dp)
+   if (dev_priv-drrs.type == DRRS_NOT_SUPPORTED)
return;
 
cancel_delayed_work_sync(dev_priv-drrs.work);
 
mutex_lock(dev_priv-drrs.mutex);
+   if (!dev_priv-drrs.dp) {
+   mutex_unlock(dev_priv-drrs.mutex);
+   return;
+   }
+
crtc = dp_to_dig_port(dev_priv-drrs.dp)-base.base.crtc;
pipe = to_intel_crtc(crtc)-pipe;
 
@@ -5231,12 +5235,17 @@ void intel_edp_drrs_flush(struct drm_device *dev,
struct drm_crtc *crtc;
enum pipe pipe;
 
-   if (!dev_priv-drrs.dp)
+   if (dev_priv-drrs.type == DRRS_NOT_SUPPORTED)
return;
 
cancel_delayed_work_sync(dev_priv-drrs.work);
 
mutex_lock(dev_priv-drrs.mutex);
+   if (!dev_priv-drrs.dp) {
+   mutex_unlock(dev_priv-drrs.mutex);
+   return;
+   }
+
crtc = dp_to_dig_port(dev_priv-drrs.dp)-base.base.crtc;
pipe = to_intel_crtc(crtc)-pipe;
dev_priv-drrs.busy_frontbuffer_bits = ~frontbuffer_bits;
@@ -5307,6 +5316,9 @@ intel_dp_drrs_init(struct intel_connector 
*intel_connector,
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_display_mode *downclock_mode = NULL;
 
+   INIT_DELAYED_WORK(dev_priv-drrs.work, intel_edp_drrs_downclock_work);
+   mutex_init(dev_priv-drrs.mutex);
+
if (INTEL_INFO(dev)-gen = 6) {
DRM_DEBUG_KMS(DRRS supported for Gen7 and above\n);
return NULL;
@@ -5325,10 +5337,6 @@ intel_dp_drrs_init(struct intel_connector 
*intel_connector,
return NULL;
}
 
-   INIT_DELAYED_WORK(dev_priv-drrs.work, intel_edp_drrs_downclock_work);
-
-   mutex_init(dev_priv-drrs.mutex);
-
dev_priv-drrs.type = dev_priv-vbt.drrs_type;
 
dev_priv-drrs.refresh_rate_type = DRRS_HIGH_RR;
-- 
2.1.0

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

[Intel-gfx] [PATCH 2/2] drm/i915: Don't cancel DRRS worker synchronously for flush/invalidate

[Daniel Vetter]

It's not needed since the worker rechecks that it didn't race. We only
need to cancel synchronously after disabling drrs to make sure the
worker really is gone (e.g. for driver unload). But for normal
operation the stall is just wasted time.

Reported-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Ramalingam C ramalinga...@intel.com
Cc: Rodrigo Vivi rodrigo.v...@intel.com
Cc: Vandana Kannan vandana.kan...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d846738365cb..b8afa2af0523 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5194,7 +5194,7 @@ void intel_edp_drrs_invalidate(struct drm_device *dev,
if (dev_priv-drrs.type == DRRS_NOT_SUPPORTED)
return;
 
-   cancel_delayed_work_sync(dev_priv-drrs.work);
+   cancel_delayed_work(dev_priv-drrs.work);
 
mutex_lock(dev_priv-drrs.mutex);
if (!dev_priv-drrs.dp) {
@@ -5238,7 +5238,7 @@ void intel_edp_drrs_flush(struct drm_device *dev,
if (dev_priv-drrs.type == DRRS_NOT_SUPPORTED)
return;
 
-   cancel_delayed_work_sync(dev_priv-drrs.work);
+   cancel_delayed_work(dev_priv-drrs.work);
 
mutex_lock(dev_priv-drrs.mutex);
if (!dev_priv-drrs.dp) {
-- 
2.1.0

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

[Intel-gfx] [PATCH] Correct kms_fbc_crc case

[liu,lei]

From: liu,lei lei.a@intel.com

Debugfs i915_fbc_status shows FBC unsupported on this chipset
not unsupported by this chipset if the platform doesn't support
FBC feature. That typo will cause case fail on some platforms such
as byt, bsw.

Signed-off-by: Lei Liu lei.a@intel.com
---
 tests/kms_fbc_crc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/kms_fbc_crc.c b/tests/kms_fbc_crc.c
index ccdec33..1320bad 100644
--- a/tests/kms_fbc_crc.c
+++ b/tests/kms_fbc_crc.c
@@ -513,7 +513,7 @@ igt_main
igt_assert_lt(0, fread(buf, 1, sizeof(buf), status));
fclose(status);
buf[sizeof(buf) - 1] = '\0';
-   igt_require_f(!strstr(buf, unsupported by this chipset) 
+   igt_require_f(!strstr(buf, unsupported on this chipset) 
  !strstr(buf, disabled per module param) 
  !strstr(buf, disabled per chip default),
  FBC not supported/enabled\n);
-- 
1.8.3.1

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

Re: [Intel-gfx] [PATCH 27/70] drm/i915: Remove vestigal DRI1 ring quiescing code

[Daniel Vetter]

On Thu, Apr 09, 2015 at 04:24:53PM +0100, Chris Wilson wrote:
 On Thu, Apr 09, 2015 at 05:02:36PM +0200, Daniel Vetter wrote:
  On Tue, Apr 07, 2015 at 04:20:51PM +0100, Chris Wilson wrote:
   @@ -640,7 +641,7 @@ static int logical_ring_wait_request(struct 
   intel_ringbuffer *ringbuf,
 break;
 }

   - if (request-list == ring-request_list)
   + if (WARN_ON(request-list == ring-request_list))
 return -ENOSPC;
  
  Checking for new_space  n (and initializing new_space to 0) would be a
  clearer check imo. But that's just a bikeshed. Same for the legacy one
  below.
 
 If you watch later, I remove the double update of ringbuf-space.
 However, I am quite found of the if (iter == list_head) return -ENOSPC,
 so I am a bit biased.

Oh it was mostly that I had to double-check the loop above (which was out
of the diff context). With context it's all good. I'm a really lazy
reviewer ;-)
-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] Correct kms_fbc_crc case Debugfs i915_fbc_status shows FBC unsupported on this chipset not unsupported by this chipset if the platform doesn't support FBC feature. That typ

[Daniel Vetter]

On Thu, Apr 09, 2015 at 01:51:24PM +0800, liu,lei wrote:
 From: liu,lei lei.a@intel.com

In igt we follow the kernel conventions for patch commit messages:
- First line (subject) summarizes the patch in at most 70 chars
- After an empty line comes the extended commit message (you have that in
  the first line so it ends up in the subject).
- signed-off-by line at the bottom.

Can you please fix that up and resubmit?

Thanks, Daniel
 
 ---
  tests/kms_fbc_crc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/tests/kms_fbc_crc.c b/tests/kms_fbc_crc.c
 index ccdec33..1320bad 100644
 --- a/tests/kms_fbc_crc.c
 +++ b/tests/kms_fbc_crc.c
 @@ -513,7 +513,7 @@ igt_main
   igt_assert_lt(0, fread(buf, 1, sizeof(buf), status));
   fclose(status);
   buf[sizeof(buf) - 1] = '\0';
 - igt_require_f(!strstr(buf, unsupported by this chipset) 
 + igt_require_f(!strstr(buf, unsupported on this chipset) 
 !strstr(buf, disabled per module param) 
 !strstr(buf, disabled per chip default),
 FBC not supported/enabled\n);
 -- 
 1.8.3.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

[Intel-gfx] [PATCH] drm/i915: Clear crtc atomic flags at beginning of transaction

[Matt Roper]

Once we have full atomic modeset, these kind of flags should be in a
real intel_crtc_state that's tracked properly.  In the meantime, make
sure we clear out any old flags at the beginning of a transaction so
that we don't wind up seeing leftover flags from old transactions that
were checked, but never went to the commit step.  At the moment, a
failed check or prepare could leave stale flags behind that interfere
with the next atomic transaction.

v2: Just do a memset; the series this patch was originally part of
placed additional fields into the structure that shouldn't be
cleared, but that's no longer the case.

Signed-off-by: Matt Roper matthew.d.ro...@intel.com
---
 drivers/gpu/drm/i915/intel_atomic.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 3903b90..b4ea676 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -76,6 +76,8 @@ int intel_atomic_check(struct drm_device *dev,
state-allow_modeset = false;
for (i = 0; i  ncrtcs; i++) {
struct intel_crtc *crtc = to_intel_crtc(state-crtcs[i]);
+   if (crtc)
+   memset(crtc-atomic, 0, sizeof(crtc-atomic));
if (crtc  crtc-pipe != nuclear_pipe)
not_nuclear = true;
}
-- 
1.8.5.1

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

Re: [Intel-gfx] [PATCH v2] uxa: Do not register hotplug without RandR

[Chris Wilson]

On Wed, Apr 08, 2015 at 01:57:35PM +0200, Olivier Fourdan wrote:
 When using Xinerama, RandR is automatically disabled, and calling RR
 routines will trigger an assert() because the RR keys/resources are
 not set, leading to an Xserver abort.
 
 Hotplug makes little sense without RandR, so no need to install a
 udev monitor if RandR is not available, as done in sna.
 
 Signed-off-by: Olivier Fourdan ofour...@redhat.com
 ---
  v2: Do not register udev monitor without RandR as done in sna.

I tweaked it so that we had an alternative check before
HAS_DIXREGISTERPRIVATEKEY and pushed. Thanks,
-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 locking in DRRS flush/invalidate hooks

[Jani Nikula]

On Thu, 09 Apr 2015, Daniel Vetter daniel.vet...@ffwll.ch wrote:
 We must acquire the mutex before we can check drrs.dp, otherwise
 someone might sneak in with a modeset, clear the pointer after we've
 checked it and then the code will Oops.

 This issue has been introduced in

 commit a93fad0f7fb8a3ff12e8814b630648f6d187954c
 Author: Vandana Kannan vandana.kan...@intel.com
 Date:   Sat Jan 10 02:25:59 2015 +0530

 drm/i915: DRRS calls based on frontbuffer

 Cc: Ramalingam C ramalinga...@intel.com
 Cc: Rodrigo Vivi rodrigo.v...@intel.com
 Cc: Vandana Kannan vandana.kan...@intel.com
 Signed-off-by: Daniel Vetter daniel.vet...@intel.com

Missed 4.0 so this is

Cc: sta...@vger.kernel.org


 ---
  drivers/gpu/drm/i915/intel_dp.c | 17 ++---
  1 file changed, 10 insertions(+), 7 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
 index 1b87969536ff..e265a0dee479 100644
 --- a/drivers/gpu/drm/i915/intel_dp.c
 +++ b/drivers/gpu/drm/i915/intel_dp.c
 @@ -5170,7 +5170,6 @@ static void intel_edp_drrs_downclock_work(struct 
 work_struct *work)
   downclock_mode-vrefresh);
  
  unlock:
 -
   mutex_unlock(dev_priv-drrs.mutex);
  }
  
 @@ -5192,12 +5191,14 @@ void intel_edp_drrs_invalidate(struct drm_device *dev,
   struct drm_crtc *crtc;
   enum pipe pipe;
  
 - if (!dev_priv-drrs.dp)
 - return;
 -
   cancel_delayed_work_sync(dev_priv-drrs.work);
  
   mutex_lock(dev_priv-drrs.mutex);
 + if (!dev_priv-drrs.dp) {
 + mutex_unlock(dev_priv-drrs.mutex);
 + return;
 + }
 +
   crtc = dp_to_dig_port(dev_priv-drrs.dp)-base.base.crtc;
   pipe = to_intel_crtc(crtc)-pipe;
  
 @@ -5231,12 +5232,14 @@ void intel_edp_drrs_flush(struct drm_device *dev,
   struct drm_crtc *crtc;
   enum pipe pipe;
  
 - if (!dev_priv-drrs.dp)
 - return;
 -
   cancel_delayed_work_sync(dev_priv-drrs.work);
  
   mutex_lock(dev_priv-drrs.mutex);
 + if (!dev_priv-drrs.dp) {
 + mutex_unlock(dev_priv-drrs.mutex);
 + return;
 + }
 +
   crtc = dp_to_dig_port(dev_priv-drrs.dp)-base.base.crtc;
   pipe = to_intel_crtc(crtc)-pipe;
   dev_priv-drrs.busy_frontbuffer_bits = ~frontbuffer_bits;
 -- 
 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 15/19] drm/i915: HSW cdclk support

[Daniel Vetter]

On Thu, Apr 09, 2015 at 04:41:26PM +0300, Mika Kahola wrote:
 On Thu, 2015-04-09 at 11:32 +0200, Daniel Vetter wrote:
  On Thu, Apr 09, 2015 at 10:24:24AM +0300, Mika Kahola wrote:
   I did some testing on audio part with HDMI-HDMI and DP-HDMI cables
   connected to my Haswell box. Before applying the patch I tested as a
   reference with the latest -nightly (04-08-2015), 4.0-rc7. Unfortunately,
   I failed to get any audio over HDMI cable. For a reference I tested with
   the very same setup the vanillla kernel from Linus tree 4.0-rc7 and with
   that kernel the audio worked ok. Then I did some GIT bisecting and it
   turned out that the first commit that I failed to get audio working was
   aa2fee4286e43b4784982b17669b02cc99c1ae55.
  
 I rerun the bisecting and this time the result was
 
 commit 0a599838737a2527c35e4d94f794aefe59df1781
 Merge: 2d846c7 a59d719
 Author: Takashi Iwai ti...@suse.de
 Date:   Wed Apr 8 11:29:56 2015 +0200
 
 Merge branch 'for-linus' into for-next
 
 Back merge HD-audio quirks to for-next branch, so that we can apply
 a couple of more quirks.
 
 Signed-off-by: Takashi Iwai ti...@suse.de

Adding Takashi and intel audio folks.
-Daniel

 
  I don't have this sha1 anywhere. Can you please double-check?
  
  Also to avoid such issues please always add at least the commit subject
  and author, so that I can find it if it's somehow rebased.
  -Daniel
  
   
   To test this patch audio functionality I checkout the -nightly version
   that works for me and apply the patch and test it. I'll come back with
   the results later on. 
   
   I had the module option i915.disable_power_well=0
   
   The test routine that I used for audio testing was
   speaker-test -c 2 -r 48000 -f S16_LE -t pink --device=plughw:0,3
   
   On Tue, 2015-04-07 at 15:52 +0200, Daniel Vetter wrote:
On Tue, Apr 07, 2015 at 12:29:25PM +0300, Mika Kahola wrote:
 Definitely a good idea to check the audio part as well if there is
 a doubt that by changing CD clock the audio would fail. I can check
 this and I'll get back once I have the results.

We force a full modeset, which should result in an interrupt on the 
audio
side, which should result in the audio driver re-reading the current
cdclk. If that's no the case it's buggy already.
-Daniel
   
   -- 
   Mika Kahola, Intel OTC
   
   
   
  
 
 -- 
 Mika Kahola, Intel OTC
 
 
 

-- 
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 4/5] mm: Export remap_io_mapping()

[Joonas Lahtinen]

On ti, 2015-04-07 at 17:31 +0100, Chris Wilson wrote:
 This is similar to remap_pfn_range(), and uses the recently refactor
 code to do the page table walking. The key difference is that is back
 propagates its error as this is required for use from within a pagefault
 handler. The other difference, is that it combine the page protection
 from io-mapping, which is known from when the io-mapping is created,
 with the per-vma page protection flags. This avoids having to walk the
 entire system description to rediscover the special page protection
 established for the io-mapping.
 
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Cc: Andrew Morton a...@linux-foundation.org
 Cc: Kirill A. Shutemov kirill.shute...@linux.intel.com
 Cc: Peter Zijlstra pet...@infradead.org
 Cc: Rik van Riel r...@redhat.com
 Cc: Mel Gorman mgor...@suse.de
 Cc: Cyrill Gorcunov gorcu...@gmail.com
 Cc: Johannes Weiner han...@cmpxchg.org
 Cc: linux...@kvack.org
 ---
  include/linux/mm.h |  4 
  mm/memory.c| 46 ++
  2 files changed, 50 insertions(+)
 
 diff --git a/include/linux/mm.h b/include/linux/mm.h
 index 47a93928b90f..3dfecd58adb0 100644
 --- a/include/linux/mm.h
 +++ b/include/linux/mm.h
 @@ -2083,6 +2083,10 @@ unsigned long change_prot_numa(struct vm_area_struct 
 *vma,
  struct vm_area_struct *find_extend_vma(struct mm_struct *, unsigned long 
 addr);
  int remap_pfn_range(struct vm_area_struct *, unsigned long addr,
   unsigned long pfn, unsigned long size, pgprot_t);
 +struct io_mapping;

This is unconditional code, so just move the struct forward declaration
to the top of the file after struct writeback_control and others.

 +int remap_io_mapping(struct vm_area_struct *,
 +  unsigned long addr, unsigned long pfn, unsigned long size,
 +  struct io_mapping *iomap);
  int vm_insert_page(struct vm_area_struct *, unsigned long addr, struct page 
 *);
  int vm_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
   unsigned long pfn);
 diff --git a/mm/memory.c b/mm/memory.c
 index acb06f40d614..83bc5df3fafc 100644
 --- a/mm/memory.c
 +++ b/mm/memory.c
 @@ -61,6 +61,7 @@
  #include linux/string.h
  #include linux/dma-debug.h
  #include linux/debugfs.h
 +#include linux/io-mapping.h
  
  #include asm/io.h
  #include asm/pgalloc.h
 @@ -1762,6 +1763,51 @@ int remap_pfn_range(struct vm_area_struct *vma, 
 unsigned long addr,
  EXPORT_SYMBOL(remap_pfn_range);
  
  /**
 + * remap_io_mapping - remap an IO mapping to userspace
 + * @vma: user vma to map to
 + * @addr: target user address to start at
 + * @pfn: physical address of kernel memory
 + * @size: size of map area
 + * @iomap: the source io_mapping
 + *
 + *  Note: this is only safe if the mm semaphore is held when called.
 + */
 +int remap_io_mapping(struct vm_area_struct *vma,
 +  unsigned long addr, unsigned long pfn, unsigned long size,
 +  struct io_mapping *iomap)
 +{
 + unsigned long end = addr + PAGE_ALIGN(size);
 + struct remap_pfn r;
 + pgd_t *pgd;
 + int err;
 +
 + if (WARN_ON(addr = end))
 + return -EINVAL;
 +
 +#define MUST_SET (VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP)
 + BUG_ON(is_cow_mapping(vma-vm_flags));
 + BUG_ON((vma-vm_flags  MUST_SET) != MUST_SET);
 +#undef MUST_SET
 +

I think that is bit general for define name, maybe something along
REMAP_IO_NEEDED_FLAGS outside of the function... and then it doesn't
have to be #undeffed. And if it is kept inside function then at least _
prefix it. But I don't see why not make it available outside too.

Otherwise looking good.

Regards, Joonas

 + r.mm = vma-vm_mm;
 + r.addr = addr;
 + r.pfn = pfn;
 + r.prot = __pgprot((pgprot_val(iomap-prot)  _PAGE_CACHE_MASK) |
 +   (pgprot_val(vma-vm_page_prot)  ~_PAGE_CACHE_MASK));
 +
 + pgd = pgd_offset(r.mm, addr);
 + do {
 + err = remap_pud_range(r, pgd++, pgd_addr_end(r.addr, end));
 + } while (err == 0  r.addr  end);
 +
 + if (err)
 + zap_page_range_single(vma, addr, r.addr - addr, NULL);
 +
 + return err;
 +}
 +EXPORT_SYMBOL(remap_io_mapping);
 +
 +/**
   * vm_iomap_memory - remap memory to userspace
   * @vma: user vma to map to
   * @start: start of area


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

Re: [Intel-gfx] [PATCH i-g-t 2/2] tests: use standard install prefix for programs, scripts and data

[Daniel Vetter]

On Thu, Apr 09, 2015 at 09:45:13AM +0300, Joonas Lahtinen wrote:
 On ke, 2015-04-08 at 14:56 +0100, Thomas Wood wrote:
  Use the pkglibexec and pkgdata prefixes rather than setting bindir and
  datadir. This also removes the extra 'tests' directory from within the
  package libexec and data directories.
  
  Cc: Joonas Lahtinen joonas.lahti...@linux.intel.com
  Signed-off-by: Thomas Wood thomas.w...@intel.com
  ---
   tests/Makefile.am  | 15 +++
   tests/Makefile.sources | 15 ---
   2 files changed, 11 insertions(+), 19 deletions(-)
  
  diff --git a/tests/Makefile.am b/tests/Makefile.am
  index d6de373..dc864f4 100644
  --- a/tests/Makefile.am
  +++ b/tests/Makefile.am
  @@ -27,18 +27,25 @@ multi-tests.txt: Makefile.sources
  @echo ${multi_kernel_tests}  $@
  @echo END TESTLIST  $@
   
  -igt_tests_bin_PROGRAMS += \
  +noinst_PROGRAMS = \
  +   $(HANG) \
  +   $(TESTS_testsuite) \
  +   $(NULL)
  +
  +pkglibexec_PROGRAMS = \
  +   gem_alive \
  +   gem_stress \
  $(TESTS_progs) \
  $(TESTS_progs_M) \
  $(NULL)
 
 Reasoning for the tests directory was that if the tests just sit under
 pkglibexec, they might be mistaken for tools (as the i-g-t package name
 suggests) by packagers or really anybody.
 
 If it's so important not to have the tests directory, I'd rather suffix
 all the programs with _test during build. It would cause some
 cascading changes too, so why do you want to get rid of the tests
 directory in the first place?

Imo libexec is a sufficient hint that this is internal stuff that we don't
need to add a prefix or subdir.
-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 04/13] drm/i915/gen8: Add dynamic allocation macros and helper functions

[Daniel Vetter]

On Wed, Apr 08, 2015 at 12:13:26PM +0100, Michel Thierry wrote:
 +static inline uint32_t gen8_pml4e_index(uint64_t address)
 +{
 + BUG(); /* For 64B */

Please never use BUG where a WARN would do too. Fixed while applying.
-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 2/6] drm/cache: Implement drm_clflush_*() for ARM

[Thierry Reding]

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

Add implementations for drm_clflush_*() on ARM by borrowing code from
the DMA mapping API implementation. Unfortunately ARM doesn't export an
API to flush caches on a page by page basis, so this replicates most of
the code.

Reviewed-by: Rob Clark robdcl...@gmail.com
Tested-by: Rob Clark robdcl...@gmail.com
Signed-off-by: Thierry Reding tred...@nvidia.com
---
 drivers/gpu/drm/drm_cache.c | 45 +
 1 file changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 9a62d7a53553..200d86c3d72d 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -67,6 +67,41 @@ static void drm_cache_flush_clflush(struct page *pages[],
 }
 #endif
 
+#if defined(CONFIG_ARM)
+
+#include asm/cacheflush.h
+#include asm/cachetype.h
+#include asm/highmem.h
+#include asm/outercache.h
+
+static void drm_clflush_page(struct page *page)
+{
+   enum dma_data_direction dir = DMA_TO_DEVICE;
+   phys_addr_t phys = page_to_phys(page);
+   size_t size = PAGE_SIZE;
+   void *virt;
+
+   if (PageHighMem(page)) {
+   if (cache_is_vipt_nonaliasing()) {
+   virt = kmap_atomic(page);
+   dmac_map_area(virt, size, dir);
+   kunmap_atomic(virt);
+   } else {
+   virt = kmap_high_get(page);
+   if (virt) {
+   dmac_map_area(virt, size, dir);
+   kunmap_high(page);
+   }
+   }
+   } else {
+   virt = page_address(page);
+   dmac_map_area(virt, size, dir);
+   }
+
+   outer_flush_range(phys, phys + PAGE_SIZE);
+}
+#endif
+
 void
 drm_clflush_pages(struct page *pages[], unsigned long num_pages)
 {
@@ -94,6 +129,11 @@ drm_clflush_pages(struct page *pages[], unsigned long 
num_pages)
   (unsigned long)page_virtual + PAGE_SIZE);
kunmap_atomic(page_virtual);
}
+#elif defined(CONFIG_ARM)
+   unsigned long i;
+
+   for (i = 0; i  num_pages; i++)
+   drm_clflush_page(pages[i]);
 #else
printk(KERN_ERR Architecture has no drm_cache.c support\n);
WARN_ON_ONCE(1);
@@ -118,6 +158,11 @@ drm_clflush_sg(struct sg_table *st)
 
if (wbinvd_on_all_cpus())
printk(KERN_ERR Timed out waiting for cache flush.\n);
+#elif defined(CONFIG_ARM)
+   struct sg_page_iter sg_iter;
+
+   for_each_sg_page(st-sgl, sg_iter, st-nents, 0)
+   drm_clflush_page(sg_page_iter_page(sg_iter));
 #else
printk(KERN_ERR Architecture has no drm_cache.c support\n);
WARN_ON_ONCE(1);
-- 
2.3.2

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

[Intel-gfx] [PATCH 3/6] drm/cache: Implement drm_clflush_*() for 64-bit ARM

[Thierry Reding]

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

Add implementations for drm_clflush_*() on 64-bit ARM. This shares a lot
of code with the 32-bit ARM implementation.

Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Will Deacon will.dea...@arm.com
Signed-off-by: Thierry Reding tred...@nvidia.com
---
 drivers/gpu/drm/drm_cache.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 200d86c3d72d..0c3072b4cdc9 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -102,6 +102,17 @@ static void drm_clflush_page(struct page *page)
 }
 #endif
 
+#if defined(CONFIG_ARM64)
+static void drm_clflush_page(struct page *page)
+{
+   void *virt;
+
+   virt = kmap_atomic(page);
+   __dma_flush_range(virt, virt + PAGE_SIZE);
+   kunmap_atomic(virt);
+}
+#endif
+
 void
 drm_clflush_pages(struct page *pages[], unsigned long num_pages)
 {
@@ -129,7 +140,7 @@ drm_clflush_pages(struct page *pages[], unsigned long 
num_pages)
   (unsigned long)page_virtual + PAGE_SIZE);
kunmap_atomic(page_virtual);
}
-#elif defined(CONFIG_ARM)
+#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64)
unsigned long i;
 
for (i = 0; i  num_pages; i++)
@@ -158,7 +169,7 @@ drm_clflush_sg(struct sg_table *st)
 
if (wbinvd_on_all_cpus())
printk(KERN_ERR Timed out waiting for cache flush.\n);
-#elif defined(CONFIG_ARM)
+#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64)
struct sg_page_iter sg_iter;
 
for_each_sg_page(st-sgl, sg_iter, st-nents, 0)
-- 
2.3.2

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

[Intel-gfx] [PATCH 6/6] drm/msm: gem: Use drm_clflush_*() functions

[Thierry Reding]

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

Instead of going through the DMA mapping API for cache maintenance, use
the drm_clflush_*() family of functions to achieve the same effect.

Cc: Rob Clark robdcl...@gmail.com
Signed-off-by: Thierry Reding tred...@nvidia.com
---
 drivers/gpu/drm/msm/Kconfig   | 1 +
 drivers/gpu/drm/msm/msm_gem.c | 9 +
 2 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 0a6f6764a37c..5da7fe793e89 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -5,6 +5,7 @@ config DRM_MSM
depends on ARCH_QCOM || (ARM  COMPILE_TEST)
depends on OF  COMMON_CLK
select REGULATOR
+   select DRM_CACHE
select DRM_KMS_HELPER
select DRM_PANEL
select SHMEM
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 52839769eb6c..ce265085fc57 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -101,8 +101,7 @@ static struct page **get_pages(struct drm_gem_object *obj)
 * because display controller, GPU, etc. are not coherent:
 */
if (msm_obj-flags  (MSM_BO_WC|MSM_BO_UNCACHED))
-   dma_map_sg(dev-dev, msm_obj-sgt-sgl,
-   msm_obj-sgt-nents, DMA_BIDIRECTIONAL);
+   drm_clflush_sg(msm_obj-sgt);
}
 
return msm_obj-pages;
@@ -113,12 +112,6 @@ static void put_pages(struct drm_gem_object *obj)
struct msm_gem_object *msm_obj = to_msm_bo(obj);
 
if (msm_obj-pages) {
-   /* For non-cached buffers, ensure the new pages are clean
-* because display controller, GPU, etc. are not coherent:
-*/
-   if (msm_obj-flags  (MSM_BO_WC|MSM_BO_UNCACHED))
-   dma_unmap_sg(obj-dev-dev, msm_obj-sgt-sgl,
-   msm_obj-sgt-nents, DMA_BIDIRECTIONAL);
sg_free_table(msm_obj-sgt);
kfree(msm_obj-sgt);
 
-- 
2.3.2

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

Re: [Intel-gfx] [PATCH i-g-t 2/2] tests: use standard install prefix for programs, scripts and data

[Thomas Wood]

On 9 April 2015 at 07:45, Joonas Lahtinen
joonas.lahti...@linux.intel.com wrote:
 On ke, 2015-04-08 at 14:56 +0100, Thomas Wood wrote:
 Use the pkglibexec and pkgdata prefixes rather than setting bindir and
 datadir. This also removes the extra 'tests' directory from within the
 package libexec and data directories.

 Cc: Joonas Lahtinen joonas.lahti...@linux.intel.com
 Signed-off-by: Thomas Wood thomas.w...@intel.com
 ---
  tests/Makefile.am  | 15 +++
  tests/Makefile.sources | 15 ---
  2 files changed, 11 insertions(+), 19 deletions(-)

 diff --git a/tests/Makefile.am b/tests/Makefile.am
 index d6de373..dc864f4 100644
 --- a/tests/Makefile.am
 +++ b/tests/Makefile.am
 @@ -27,18 +27,25 @@ multi-tests.txt: Makefile.sources
   @echo ${multi_kernel_tests}  $@
   @echo END TESTLIST  $@

 -igt_tests_bin_PROGRAMS += \
 +noinst_PROGRAMS = \
 + $(HANG) \
 + $(TESTS_testsuite) \
 + $(NULL)
 +
 +pkglibexec_PROGRAMS = \
 + gem_alive \
 + gem_stress \
   $(TESTS_progs) \
   $(TESTS_progs_M) \
   $(NULL)

 Reasoning for the tests directory was that if the tests just sit under
 pkglibexec, they might be mistaken for tools (as the i-g-t package name
 suggests) by packagers or really anybody.

I think pklibexec is sufficient since user tools ought to be install
in bin anyway. The test list should also be installed in pkgdatadir to
identify the test binaries.


 If it's so important not to have the tests directory, I'd rather suffix
 all the programs with _test during build. It would cause some
 cascading changes too, so why do you want to get rid of the tests
 directory in the first place?


 -dist_igt_tests_bin_SCRIPTS = \
 +dist_pkglibexec_SCRIPTS = \
   $(TESTS_scripts) \
   $(TESTS_scripts_M) \
   $(scripts) \
   $(NULL)


 This one was giving me complaints with automake 1.14.1 that SCRIPTS
 don't belong straight to pkglibexec, so this would have to be kept
 indirect like it is, be it with tests directory or not.

I also have automake 1.14.1 and it doesn't seem to complain. Does it
prevent automake from completing successfully?



 -dist_igt_tests_data_DATA = \
 +dist_pkgdata_DATA = \
   $(IMAGES) \
   $(NULL)

 @@ -52,7 +59,7 @@ AM_CFLAGS = $(DRM_CFLAGS) $(CWARNFLAGS) $(DEBUG_CFLAGS)\
   -I$(srcdir)/../lib \
   -include $(srcdir)/../lib/check-ndebug.h \
   -DIGT_SRCDIR=\$(abs_srcdir)\ \
 - -DIGT_DATADIR=\$(igt_tests_datadir)\ \
 + -DIGT_DATADIR=\$(pkgdatadir)\ \
   $(LIBUNWIND_CFLAGS) \
   $(NULL)

 diff --git a/tests/Makefile.sources b/tests/Makefile.sources
 index 59a06e9..4bf11bf 100644
 --- a/tests/Makefile.sources
 +++ b/tests/Makefile.sources
 @@ -1,18 +1,3 @@
 -igt_tests_bindir = $(pkglibexecdir)/tests
 -igt_tests_datadir = $(pkgdatadir)/tests
 -
 -noinst_PROGRAMS = \
 - $(HANG) \
 - $(TESTS_testsuite) \
 - $(NULL)
 -
 -igt_tests_bin_PROGRAMS = \
 - gem_alive \
 - gem_stress \
 - $(TESTS_progs) \
 - $(TESTS_progs_M) \
 - $(NULL)
 -
  NOUVEAU_TESTS_M = \
   prime_nv_api \
   prime_nv_pcopy \
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/5] io-mapping: Always create a struct to hold metadata about the io-mapping

[Joonas Lahtinen]

On ti, 2015-04-07 at 17:31 +0100, Chris Wilson wrote:
 Currently, we only allocate a structure to hold metadata if we need to
 allocate an ioremap for every access, such as on x86-32. However, it
 would be useful to store basic information about the io-mapping, such as
 its page protection, on all platforms.
 
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk

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

 Cc: linux...@kvack.org
 ---
  include/linux/io-mapping.h | 52 
 --
  1 file changed, 32 insertions(+), 20 deletions(-)
 
 diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
 index 657fab4efab3..e053011f50bb 100644
 --- a/include/linux/io-mapping.h
 +++ b/include/linux/io-mapping.h
 @@ -31,16 +31,17 @@
   * See Documentation/io-mapping.txt
   */
  
 -#ifdef CONFIG_HAVE_ATOMIC_IOMAP
 -
 -#include asm/iomap.h
 -
  struct io_mapping {
   resource_size_t base;
   unsigned long size;
   pgprot_t prot;
 + void __iomem *iomem;
  };
  
 +
 +#ifdef CONFIG_HAVE_ATOMIC_IOMAP
 +
 +#include asm/iomap.h
  /*
   * For small address space machines, mapping large objects
   * into the kernel virtual space isn't practical. Where
 @@ -119,48 +120,59 @@ io_mapping_unmap(void __iomem *vaddr)
  #else
  
  #include linux/uaccess.h
 -
 -/* this struct isn't actually defined anywhere */
 -struct io_mapping;
 +#include asm/pgtable_types.h
  
  /* Create the io_mapping object*/
  static inline struct io_mapping *
  io_mapping_create_wc(resource_size_t base, unsigned long size)
  {
 - return (struct io_mapping __force *) ioremap_wc(base, size);
 + struct io_mapping *iomap;
 +
 + iomap = kmalloc(sizeof(*iomap), GFP_KERNEL);
 + if (!iomap)
 + return NULL;
 +
 + iomap-base = base;
 + iomap-size = size;
 + iomap-iomem = ioremap_wc(base, size);
 + iomap-prot = pgprot_writecombine(PAGE_KERNEL_IO);
 +
 + return iomap;
  }
  
  static inline void
  io_mapping_free(struct io_mapping *mapping)
  {
 - iounmap((void __force __iomem *) mapping);
 + iounmap(mapping-iomem);
 + kfree(mapping);
  }
  
 -/* Atomic map/unmap */
 +/* Non-atomic map/unmap */
  static inline void __iomem *
 -io_mapping_map_atomic_wc(struct io_mapping *mapping,
 -  unsigned long offset)
 +io_mapping_map_wc(struct io_mapping *mapping, unsigned long offset)
  {
 - pagefault_disable();
 - return ((char __force __iomem *) mapping) + offset;
 + return mapping-iomem + offset;
  }
  
  static inline void
 -io_mapping_unmap_atomic(void __iomem *vaddr)
 +io_mapping_unmap(void __iomem *vaddr)
  {
 - pagefault_enable();
  }
  
 -/* Non-atomic map/unmap */
 +/* Atomic map/unmap */
  static inline void __iomem *
 -io_mapping_map_wc(struct io_mapping *mapping, unsigned long offset)
 +io_mapping_map_atomic_wc(struct io_mapping *mapping,
 +  unsigned long offset)
  {
 - return ((char __force __iomem *) mapping) + offset;
 + pagefault_disable();
 + return io_mapping_map_wc(mapping, offset);
  }
  
  static inline void
 -io_mapping_unmap(void __iomem *vaddr)
 +io_mapping_unmap_atomic(void __iomem *vaddr)
  {
 + io_mapping_unmap(vaddr);
 + pagefault_enable();
  }
  
  #endif /* HAVE_ATOMIC_IOMAP */


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

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Make atomic use in-flight state for CRTC active value

[Daniel Vetter]

On Thu, Apr 09, 2015 at 07:00:31AM -0700, Matt Roper wrote:
 On Thu, Apr 09, 2015 at 02:42:36PM +0200, Daniel Vetter wrote:
  On Wed, Apr 08, 2015 at 06:56:51PM -0700, Matt Roper wrote:
   Our atomic plane code currently uses intel_crtc-active to determine
   how/when to update some derived state values.  This works fine for pure
   plane updates at the moment since the CRTC state itself isn't changed as
   part of the operation.  However as we convert more of our driver
   internals over to atomic modesetting, we need to look at whether the
   CRTC will be active at the *end* of the atomic transaction (which may
   not match the currently committed state).
   
   The in-flight value we want to use is generally in a crtc_state object
   associated with our top-level atomic transaction.  However there are a
   few cases where this isn't the case:
   
* While using transitional atomic helpers (as we are at the moment),
  SetPlane() calls will operate on orphaned plane states that aren't
  part of a top-level atomic transaction.  In this case, we're not
  touching the CRTC state, so it's fine to use the already-committed
  value from crtc-state.
   
* While updating properties of a disabled plane, we'll have a top-level
  atomic state, but it may not contain the CRTC state we're looking
  for.  Once again, this means we're not actually touching any CRTC
  state so it's safe to use the value from crtc-state directly.
   
   Signed-off-by: Matt Roper matthew.d.ro...@intel.com
   ---
drivers/gpu/drm/i915/intel_atomic_plane.c | 11 +++--
drivers/gpu/drm/i915/intel_display.c  | 73 
   +--
drivers/gpu/drm/i915/intel_drv.h  |  3 ++
drivers/gpu/drm/i915/intel_sprite.c   | 16 +--
4 files changed, 93 insertions(+), 10 deletions(-)
   
   diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
   b/drivers/gpu/drm/i915/intel_atomic_plane.c
   index 976b891..90c4a82 100644
   --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
   +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
   @@ -111,12 +111,17 @@ static int intel_plane_atomic_check(struct 
   drm_plane *plane,
{
 struct drm_crtc *crtc = state-crtc;
 struct intel_crtc *intel_crtc;
   + struct intel_crtc_state *intel_crtc_state;
 struct intel_plane *intel_plane = to_intel_plane(plane);
 struct intel_plane_state *intel_state = to_intel_plane_state(state);
   + bool active;

 crtc = crtc ? crtc : plane-crtc;
 intel_crtc = to_intel_crtc(crtc);

   + intel_crtc_state = intel_crtc_state_for_plane(intel_state);
   + active = intel_crtc_state-base.enable;
   +
 /*
  * Both crtc and plane-crtc could be NULL if we're updating a
  * property while the plane is disabled.  We don't actually have
   @@ -143,10 +148,8 @@ static int intel_plane_atomic_check(struct drm_plane 
   *plane,
 /* Clip all planes to CRTC size, or 0x0 if CRTC is disabled */
 intel_state-clip.x1 = 0;
 intel_state-clip.y1 = 0;
   - intel_state-clip.x2 =
   - intel_crtc-active ? intel_crtc-config-pipe_src_w : 0;
   - intel_state-clip.y2 =
   - intel_crtc-active ? intel_crtc-config-pipe_src_h : 0;
   + intel_state-clip.x2 = active ? intel_crtc_state-pipe_src_w : 0;
   + intel_state-clip.y2 = active ? intel_crtc_state-pipe_src_h : 0;

 /*
  * Disabling a plane is always okay; we just need to update
   diff --git a/drivers/gpu/drm/i915/intel_display.c 
   b/drivers/gpu/drm/i915/intel_display.c
   index 7bfe2af..88b0f69 100644
   --- a/drivers/gpu/drm/i915/intel_display.c
   +++ b/drivers/gpu/drm/i915/intel_display.c
   @@ -12562,6 +12562,53 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
 }
}

   +/**
   + * intel_crtc_state_for_plane - Obtain CRTC state for a plane
   + * @pstate: plane state to lookup corresponding crtc state for
   + *
   + * When working with a top-level atomic transaction (drm_atomic_state),
   + * a CRTC state should be present that corresponds to the provided
   + * plane state; this function provides a quick way to fetch that
   + * CRTC state.  In cases where we have a plane state unassociated with 
   any
   + * top-level atomic transaction (e.g., while using the transitional 
   atomic
   + * helpers), the current CRTC state from crtc-state will be returned
   + * instead.
   + */
   +struct intel_crtc_state *
   +intel_crtc_state_for_plane(struct intel_plane_state *pstate)
   +{
   + struct drm_atomic_state *state = pstate-base.state;
   + struct intel_plane *plane = to_intel_plane(pstate-base.plane);
   + struct drm_crtc *crtc = intel_get_crtc_for_pipe(pstate-base.plane-dev,
   + plane-pipe);
   + int i;
   +
   + /*
   +  * While using transitional plane helpers, we may not have a top-level
   +  * atomic transaction.  Of course that also means that we're not
   +  * actually touching CRTC state, so just return the currently
   +  * 

Re: [Intel-gfx] Fast prefaulting for GTT mmappings

[Joonas Lahtinen]

On ti, 2015-04-07 at 17:31 +0100, Chris Wilson wrote:
 Hi Joonas,
 
   since you were looking at extending the GTT fault capabilities, I
 thought you might like to revivew these patches, as they may prove
 beneficial for your use case as well.

Did so, sent a couple cosmical comments.

Regards, Joonas

 -Chris
 


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

Re: [Intel-gfx] [PATCH 4/4] drm/i915/bxt: Support BXT in SSEU device status dump

[shuang . he]

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
Task id: 6131
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  276/276  276/276
ILK  302/302  302/302
SNB  313/313  313/313
IVB  337/337  337/337
BYT  286/286  286/286
HSW  395/395  395/395
BDW  321/321  321/321
-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 2/5] mm: Refactor remap_pfn_range()

[Joonas Lahtinen]

On ti, 2015-04-07 at 17:31 +0100, Chris Wilson wrote:
 In preparation for exporting very similar functionality through another
 interface, gut the current remap_pfn_range(). The motivating factor here
 is to reuse the PGB/PUD/PMD/PTE walker, but allow back progation of
 errors rather than BUG_ON.
 
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Cc: Andrew Morton a...@linux-foundation.org
 Cc: Kirill A. Shutemov kirill.shute...@linux.intel.com
 Cc: Peter Zijlstra pet...@infradead.org
 Cc: Rik van Riel r...@redhat.com
 Cc: Mel Gorman mgor...@suse.de
 Cc: Cyrill Gorcunov gorcu...@gmail.com
 Cc: Johannes Weiner han...@cmpxchg.org
 Cc: linux...@kvack.org
 ---
  mm/memory.c | 102 
 +---
  1 file changed, 57 insertions(+), 45 deletions(-)
 
 diff --git a/mm/memory.c b/mm/memory.c
 index 97839f5c8c30..acb06f40d614 100644
 --- a/mm/memory.c
 +++ b/mm/memory.c
 @@ -1614,71 +1614,81 @@ int vm_insert_mixed(struct vm_area_struct *vma, 
 unsigned long addr,
  }
  EXPORT_SYMBOL(vm_insert_mixed);
  
 +struct remap_pfn {
 + struct mm_struct *mm;
 + unsigned long addr;
 + unsigned long pfn;
 + pgprot_t prot;
 +};
 +
  /*
   * maps a range of physical memory into the requested pages. the old
   * mappings are removed. any references to nonexistent pages results
   * in null mappings (currently treated as copy-on-access)
   */
 -static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd,
 - unsigned long addr, unsigned long end,
 - unsigned long pfn, pgprot_t prot)
 +static inline int remap_pfn(struct remap_pfn *r, pte_t *pte)

I think add a brief own comment for this function and keep it below old
comment not to cause unnecessary noise.

Otherwise looks good.

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

 +{
 + if (!pte_none(*pte))
 + return -EBUSY;
 +
 + set_pte_at(r-mm, r-addr, pte,
 +pte_mkspecial(pfn_pte(r-pfn, r-prot)));
 + r-pfn++;
 + r-addr += PAGE_SIZE;
 + return 0;
 +}
 +
 +static int remap_pte_range(struct remap_pfn *r, pmd_t *pmd, unsigned long 
 end)
  {
   pte_t *pte;
   spinlock_t *ptl;
 + int err;
  
 - pte = pte_alloc_map_lock(mm, pmd, addr, ptl);
 + pte = pte_alloc_map_lock(r-mm, pmd, r-addr, ptl);
   if (!pte)
   return -ENOMEM;
 +
   arch_enter_lazy_mmu_mode();
   do {
 - BUG_ON(!pte_none(*pte));
 - set_pte_at(mm, addr, pte, pte_mkspecial(pfn_pte(pfn, prot)));
 - pfn++;
 - } while (pte++, addr += PAGE_SIZE, addr != end);
 + err = remap_pfn(r, pte++);
 + } while (err == 0  r-addr  end);
   arch_leave_lazy_mmu_mode();
 +
   pte_unmap_unlock(pte - 1, ptl);
 - return 0;
 + return err;
  }
  
 -static inline int remap_pmd_range(struct mm_struct *mm, pud_t *pud,
 - unsigned long addr, unsigned long end,
 - unsigned long pfn, pgprot_t prot)
 +static inline int remap_pmd_range(struct remap_pfn *r, pud_t *pud, unsigned 
 long end)
  {
   pmd_t *pmd;
 - unsigned long next;
 + int err;
  
 - pfn -= addr  PAGE_SHIFT;
 - pmd = pmd_alloc(mm, pud, addr);
 + pmd = pmd_alloc(r-mm, pud, r-addr);
   if (!pmd)
   return -ENOMEM;
   VM_BUG_ON(pmd_trans_huge(*pmd));
 +
   do {
 - next = pmd_addr_end(addr, end);
 - if (remap_pte_range(mm, pmd, addr, next,
 - pfn + (addr  PAGE_SHIFT), prot))
 - return -ENOMEM;
 - } while (pmd++, addr = next, addr != end);
 - return 0;
 + err = remap_pte_range(r, pmd++, pmd_addr_end(r-addr, end));
 + } while (err == 0  r-addr  end);
 +
 + return err;
  }
  
 -static inline int remap_pud_range(struct mm_struct *mm, pgd_t *pgd,
 - unsigned long addr, unsigned long end,
 - unsigned long pfn, pgprot_t prot)
 +static inline int remap_pud_range(struct remap_pfn *r, pgd_t *pgd, unsigned 
 long end)
  {
   pud_t *pud;
 - unsigned long next;
 + int err;
  
 - pfn -= addr  PAGE_SHIFT;
 - pud = pud_alloc(mm, pgd, addr);
 + pud = pud_alloc(r-mm, pgd, r-addr);
   if (!pud)
   return -ENOMEM;
 +
   do {
 - next = pud_addr_end(addr, end);
 - if (remap_pmd_range(mm, pud, addr, next,
 - pfn + (addr  PAGE_SHIFT), prot))
 - return -ENOMEM;
 - } while (pud++, addr = next, addr != end);
 - return 0;
 + err = remap_pmd_range(r, pud++, pud_addr_end(r-addr, end));
 + } while (err == 0  r-addr  end);
 +
 + return err;
  }
  
  /**
 @@ -1694,10 +1704,9 @@ static inline int remap_pud_range(struct mm_struct 
 *mm, pgd_t *pgd,
  int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,
   unsigned long pfn, unsigned long size, pgprot_t 

Re: [Intel-gfx] [PATCH] drm/i915: Fix the VBT child device parsing for BSW

[Daniel Vetter]

On Thu, Apr 09, 2015 at 11:56:36AM +0100, Damien Lespiau wrote:
 On Thu, Apr 09, 2015 at 01:37:10PM +0300, Ville Syrjälä wrote:
  On Thu, Apr 09, 2015 at 09:49:25AM +0100, Damien Lespiau wrote:
   On Wed, Mar 25, 2015 at 06:45:58PM +0200, ville.syrj...@linux.intel.com 
   wrote:
+static union child_device_config *
+child_device_ptr(struct bdb_general_definitions *p_defs, int i)
+{
+   return (void *) p_defs-devices[i * p_defs-child_dev_size];
+}
   
   Actually this looks wrong. We're doing:
   
 p_defs-devices + sizeof(union child_device_config) * i * child_dev_size
   
   instead of:
   
 (u8)p_defs-devices + i * child_dev_size
   
   ?
  
  The patch also had:
  - union child_device_config devices[0];
  + uint8_t devices[0];
 
 Ah, yes! oops

With the r-b reinstantiated I merged the patch, 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

[Intel-gfx] VLV: eDP: panel timings / resolution data from VBT, not via i2c from eDP EDID

[Lampersperger Andreas]

Hello Gajanan,

I'm trying to run linux on a 
valleyview hardware, which was made by my company. 

On this hardware, the display panel is connected via 
eDP, but the panel timings / resolution is not available 
in the EDID of the eDP. It is only available via VBT. 

You added once eDP support to VLV, can you 
give me some information on the following questions:

Is there a way to force the i915.ko to get the 
panel timing / resolution for the eDP from the 
VBT and not via i2c from the eDP?

Can you give me some advice, how to add this 
option to the source files of i915.ko?

I'm using 3.14.29, but I have also tried 4.0.0-rc7.

Best regards
Andreas










--
Registergericht: Traunstein / Registry Court: HRB 275 - Sitz / Head Office: 
Traunreut
Aufsichtsratsvorsitzender / Chairman of Supervisory Board: Rainer Burkhard
Geschäftsführung / Management Board: Thomas Sesselmann (Vorsitzender / 
Chairman),
Michael Grimm, Hubert Ermer

E-Mail Haftungsausschluss / E-Mail Disclaimer: 
http://www.heidenhain.de/disclaimer
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 2/2] lib: use test failure status for igt_set_timeout

[Daniel Vetter]

On Thu, Apr 09, 2015 at 12:14:29PM +0100, Thomas Wood wrote:
 Use a failure status code for timeout to avoid confusion between tests
 that take too long to execute versus a failure due to an operation
 taking longer than expected.
 
 Signed-off-by: Thomas Wood thomas.w...@intel.com
 ---
  lib/igt_core.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/lib/igt_core.c b/lib/igt_core.c
 index f9e92c9..e5bda86 100644
 --- a/lib/igt_core.c
 +++ b/lib/igt_core.c
 @@ -1705,15 +1705,15 @@ out:
  
  static void igt_alarm_handler(int signal)
  {
 - /* exit with timeout status */
 - igt_fail(IGT_EXIT_TIMEOUT);
 + /* exit with failure status */
 + igt_fail(IGT_EXIT_FAILURE);

I think an igt_info(timed out\n); right above might be useful. lgtm
otherwise for both patches.
-Daniel

  }
  
  /**
   * igt_set_timeout:
   * @seconds: number of seconds before timeout
   *
 - * Fail a test and exit with #IGT_EXIT_TIMEOUT status after the specified
 + * Fail a test and exit with #IGT_EXIT_FAILURE status after the specified
   * number of seconds have elapsed. If the current test has subtests and the
   * timeout occurs outside a subtest, subsequent subtests will be skipped and
   * marked as failed.
 -- 
 2.1.0
 
 ___
 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 15/19] drm/i915: HSW cdclk support

[Daniel Vetter]

On Thu, Apr 09, 2015 at 10:24:24AM +0300, Mika Kahola wrote:
 I did some testing on audio part with HDMI-HDMI and DP-HDMI cables
 connected to my Haswell box. Before applying the patch I tested as a
 reference with the latest -nightly (04-08-2015), 4.0-rc7. Unfortunately,
 I failed to get any audio over HDMI cable. For a reference I tested with
 the very same setup the vanillla kernel from Linus tree 4.0-rc7 and with
 that kernel the audio worked ok. Then I did some GIT bisecting and it
 turned out that the first commit that I failed to get audio working was
 aa2fee4286e43b4784982b17669b02cc99c1ae55.

I don't have this sha1 anywhere. Can you please double-check?

Also to avoid such issues please always add at least the commit subject
and author, so that I can find it if it's somehow rebased.
-Daniel

 
 To test this patch audio functionality I checkout the -nightly version
 that works for me and apply the patch and test it. I'll come back with
 the results later on. 
 
 I had the module option i915.disable_power_well=0
 
 The test routine that I used for audio testing was
 speaker-test -c 2 -r 48000 -f S16_LE -t pink --device=plughw:0,3
 
 On Tue, 2015-04-07 at 15:52 +0200, Daniel Vetter wrote:
  On Tue, Apr 07, 2015 at 12:29:25PM +0300, Mika Kahola wrote:
   Definitely a good idea to check the audio part as well if there is
   a doubt that by changing CD clock the audio would fail. I can check
   this and I'll get back once I have the results.
  
  We force a full modeset, which should result in an interrupt on the audio
  side, which should result in the audio driver re-reading the current
  cdclk. If that's no the case it's buggy already.
  -Daniel
 
 -- 
 Mika Kahola, Intel OTC
 
 
 

-- 
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 i-g-t 2/2] tests: use standard install prefix for programs, scripts and data

[Joonas Lahtinen]

On ke, 2015-04-08 at 14:56 +0100, Thomas Wood wrote:
 Use the pkglibexec and pkgdata prefixes rather than setting bindir and
 datadir. This also removes the extra 'tests' directory from within the
 package libexec and data directories.
 
 Cc: Joonas Lahtinen joonas.lahti...@linux.intel.com
 Signed-off-by: Thomas Wood thomas.w...@intel.com
 ---
  tests/Makefile.am  | 15 +++
  tests/Makefile.sources | 15 ---
  2 files changed, 11 insertions(+), 19 deletions(-)
 
 diff --git a/tests/Makefile.am b/tests/Makefile.am
 index d6de373..dc864f4 100644
 --- a/tests/Makefile.am
 +++ b/tests/Makefile.am
 @@ -27,18 +27,25 @@ multi-tests.txt: Makefile.sources
   @echo ${multi_kernel_tests}  $@
   @echo END TESTLIST  $@
  
 -igt_tests_bin_PROGRAMS += \
 +noinst_PROGRAMS = \
 + $(HANG) \
 + $(TESTS_testsuite) \
 + $(NULL)
 +
 +pkglibexec_PROGRAMS = \
 + gem_alive \
 + gem_stress \
   $(TESTS_progs) \
   $(TESTS_progs_M) \
   $(NULL)

Reasoning for the tests directory was that if the tests just sit under
pkglibexec, they might be mistaken for tools (as the i-g-t package name
suggests) by packagers or really anybody.

If it's so important not to have the tests directory, I'd rather suffix
all the programs with _test during build. It would cause some
cascading changes too, so why do you want to get rid of the tests
directory in the first place?

  
 -dist_igt_tests_bin_SCRIPTS = \
 +dist_pkglibexec_SCRIPTS = \
   $(TESTS_scripts) \
   $(TESTS_scripts_M) \
   $(scripts) \
   $(NULL)
  

This one was giving me complaints with automake 1.14.1 that SCRIPTS
don't belong straight to pkglibexec, so this would have to be kept
indirect like it is, be it with tests directory or not.

 -dist_igt_tests_data_DATA = \
 +dist_pkgdata_DATA = \
   $(IMAGES) \
   $(NULL)
  
 @@ -52,7 +59,7 @@ AM_CFLAGS = $(DRM_CFLAGS) $(CWARNFLAGS) $(DEBUG_CFLAGS)\
   -I$(srcdir)/../lib \
   -include $(srcdir)/../lib/check-ndebug.h \
   -DIGT_SRCDIR=\$(abs_srcdir)\ \
 - -DIGT_DATADIR=\$(igt_tests_datadir)\ \
 + -DIGT_DATADIR=\$(pkgdatadir)\ \
   $(LIBUNWIND_CFLAGS) \
   $(NULL)
  
 diff --git a/tests/Makefile.sources b/tests/Makefile.sources
 index 59a06e9..4bf11bf 100644
 --- a/tests/Makefile.sources
 +++ b/tests/Makefile.sources
 @@ -1,18 +1,3 @@
 -igt_tests_bindir = $(pkglibexecdir)/tests
 -igt_tests_datadir = $(pkgdatadir)/tests
 -
 -noinst_PROGRAMS = \
 - $(HANG) \
 - $(TESTS_testsuite) \
 - $(NULL)
 -
 -igt_tests_bin_PROGRAMS = \
 - gem_alive \
 - gem_stress \
 - $(TESTS_progs) \
 - $(TESTS_progs_M) \
 - $(NULL)
 -
  NOUVEAU_TESTS_M = \
   prime_nv_api \
   prime_nv_pcopy \


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

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Make atomic use in-flight state for CRTC active value

[Ville Syrjälä]

On Wed, Apr 08, 2015 at 06:56:51PM -0700, Matt Roper wrote:
 Our atomic plane code currently uses intel_crtc-active to determine
 how/when to update some derived state values.  This works fine for pure
 plane updates at the moment since the CRTC state itself isn't changed as
 part of the operation.  However as we convert more of our driver
 internals over to atomic modesetting, we need to look at whether the
 CRTC will be active at the *end* of the atomic transaction (which may
 not match the currently committed state).
 
 The in-flight value we want to use is generally in a crtc_state object
 associated with our top-level atomic transaction.  However there are a
 few cases where this isn't the case:
 
  * While using transitional atomic helpers (as we are at the moment),
SetPlane() calls will operate on orphaned plane states that aren't
part of a top-level atomic transaction.  In this case, we're not
touching the CRTC state, so it's fine to use the already-committed
value from crtc-state.
 
  * While updating properties of a disabled plane, we'll have a top-level
atomic state, but it may not contain the CRTC state we're looking
for.  Once again, this means we're not actually touching any CRTC
state so it's safe to use the value from crtc-state directly.
 
 Signed-off-by: Matt Roper matthew.d.ro...@intel.com
 ---
  drivers/gpu/drm/i915/intel_atomic_plane.c | 11 +++--
  drivers/gpu/drm/i915/intel_display.c  | 73 
 +--
  drivers/gpu/drm/i915/intel_drv.h  |  3 ++
  drivers/gpu/drm/i915/intel_sprite.c   | 16 +--
  4 files changed, 93 insertions(+), 10 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
 b/drivers/gpu/drm/i915/intel_atomic_plane.c
 index 976b891..90c4a82 100644
 --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
 +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
 @@ -111,12 +111,17 @@ static int intel_plane_atomic_check(struct drm_plane 
 *plane,
  {
   struct drm_crtc *crtc = state-crtc;
   struct intel_crtc *intel_crtc;
 + struct intel_crtc_state *intel_crtc_state;
   struct intel_plane *intel_plane = to_intel_plane(plane);
   struct intel_plane_state *intel_state = to_intel_plane_state(state);
 + bool active;
  
   crtc = crtc ? crtc : plane-crtc;
   intel_crtc = to_intel_crtc(crtc);
  
 + intel_crtc_state = intel_crtc_state_for_plane(intel_state);
 + active = intel_crtc_state-base.enable;
 +
   /*
* Both crtc and plane-crtc could be NULL if we're updating a
* property while the plane is disabled.  We don't actually have
 @@ -143,10 +148,8 @@ static int intel_plane_atomic_check(struct drm_plane 
 *plane,
   /* Clip all planes to CRTC size, or 0x0 if CRTC is disabled */
   intel_state-clip.x1 = 0;
   intel_state-clip.y1 = 0;
 - intel_state-clip.x2 =
 - intel_crtc-active ? intel_crtc-config-pipe_src_w : 0;
 - intel_state-clip.y2 =
 - intel_crtc-active ? intel_crtc-config-pipe_src_h : 0;
 + intel_state-clip.x2 = active ? intel_crtc_state-pipe_src_w : 0;
 + intel_state-clip.y2 = active ? intel_crtc_state-pipe_src_h : 0;

We depend on the clipping to keep planes from getting enabled on a
disabled pipe. So I think this is going to blow up.

  
   /*
* Disabling a plane is always okay; we just need to update
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 7bfe2af..88b0f69 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -12562,6 +12562,53 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
   }
  }
  
 +/**
 + * intel_crtc_state_for_plane - Obtain CRTC state for a plane
 + * @pstate: plane state to lookup corresponding crtc state for
 + *
 + * When working with a top-level atomic transaction (drm_atomic_state),
 + * a CRTC state should be present that corresponds to the provided
 + * plane state; this function provides a quick way to fetch that
 + * CRTC state.  In cases where we have a plane state unassociated with any
 + * top-level atomic transaction (e.g., while using the transitional atomic
 + * helpers), the current CRTC state from crtc-state will be returned
 + * instead.
 + */
 +struct intel_crtc_state *
 +intel_crtc_state_for_plane(struct intel_plane_state *pstate)
 +{
 + struct drm_atomic_state *state = pstate-base.state;
 + struct intel_plane *plane = to_intel_plane(pstate-base.plane);
 + struct drm_crtc *crtc = intel_get_crtc_for_pipe(pstate-base.plane-dev,
 + plane-pipe);
 + int i;
 +
 + /*
 +  * While using transitional plane helpers, we may not have a top-level
 +  * atomic transaction.  Of course that also means that we're not
 +  * actually touching CRTC state, so just return the currently
 +  * committed state.
 +  */
 + if (!state)
 + return 

Re: [Intel-gfx] [PATCH v5] drm/i915: add bxt gmbus support

[shuang . he]

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
Task id: 6110
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  276/276  276/276
ILK  302/302  302/302
SNB  313/313  313/313
IVB  337/337  337/337
BYT  286/286  286/286
HSW  395/395  395/395
BDW  321/321  321/321
-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 18/18] Documentation/drm: kerneldoc for GuC

[Daniel Vetter]

On Thu, Apr 09, 2015 at 06:24:01AM -0700, shuang...@intel.com wrote:
 Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
 shuang...@intel.com)
 Task id: 6129
 -Summary-
 Platform  Delta  drm-intel-nightly  Series Applied
 PNV -1  276/276  275/276
 ILK -2  302/302  300/302
 SNB -1  313/313  312/313
 IVB -1  337/337  336/337
 BYT -1  286/286  285/286
 HSW -1  395/395  394/395
 BDW -3  321/321  318/321
 -Detailed-
 Platform  Testdrm-intel-nightly  
 Series Applied
 *PNV  igt@drv_debugfs_reader  PASS(3)  DMESG_WARN(1)
 (dmesg patch applied)INFO:trying_to_register_non-static_key@INFO: trying to 
 register non-static key.
 *ILK  igt@drv_debugfs_reader  PASS(3)  DMESG_WARN(1)
 (dmesg patch applied)INFO:trying_to_register_non-static_key@INFO: trying to 
 register non-static key.
 *ILK  igt@gem_fenced_exec_thrash@no-spare-fences-busy  PASS(3)  
 DMESG_WARN(1)
 (dmesg patch 
 applied)drm:i915_hangcheck_elapsed[i915]]*ERROR*Hangcheck_timer_elapsed...bsd_ring_idle@Hangcheck
  timer elapsed... bsd ring idle
 *SNB  igt@drv_debugfs_reader  PASS(3)  DMESG_WARN(1)
 (dmesg patch applied)INFO:trying_to_register_non-static_key@INFO: trying to 
 register non-static key.
 *IVB  igt@drv_debugfs_reader  PASS(3)  DMESG_WARN(1)
 (dmesg patch applied)INFO:trying_to_register_non-static_key@INFO: trying to 
 register non-static key.
 *BYT  igt@drv_debugfs_reader  PASS(3)  DMESG_WARN(1)
 (dmesg patch applied)INFO:trying_to_register_non-static_key@INFO: trying to 
 register non-static key.
 *HSW  igt@drv_debugfs_reader  PASS(3)  DMESG_WARN(1)
 (dmesg patch applied)INFO:trying_to_register_non-static_key@INFO: trying to 
 register non-static key.
 *BDW  igt@drm_vma_limiter  PASS(3)  DMESG_WARN(1)
 (dmesg patch applied)INFO:possible_circular_locking_dependency_detected@INFO: 
 possible circular locking dependency detected
 *BDW  igt@gem_dummy_reloc_loop@render  PASS(3)  DMESG_WARN(1)
 (dmesg patch 
 applied)drm:i915_hangcheck_elapsed[i915]]*ERROR*Hangcheck_timer_elapsed...render_ring_idle@Hangcheck
  timer elapsed... render ring idle
 *BDW  igt@gem_exec_faulting_reloc@no-prefault  PASS(3)  DMESG_WARN(1)
 (dmesg patch applied)INFO:possible_circular_locking_dependency_detected@INFO: 
 possible circular locking dependency detected
 Note: You need to pay more attention to line start with '*'

Sounds like this patch series breaks lockdep pretty badly. Please retest
with CONFIG_PROVE_LOCKING (and all the other debug options while you're at
it) and fixup the fallout.

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 2/4] drm/i915/bxt: Determine BXT slice/subslice/EU info

[Imre Deak]

On Fri, 2015-04-03 at 18:13 -0700, jeff.mc...@intel.com wrote:
 From: Jeff McGee jeff.mc...@intel.com
 
 Modify the Gen9 SSEU info initialization logic to support
 Broxton. Broxton reuses the SKL fuse registers but has at most
 1 slice and 6 EU per subslice.
 
 Signed-off-by: Jeff McGee jeff.mc...@intel.com
 ---
  drivers/gpu/drm/i915/i915_dma.c | 47 
 ++---
  drivers/gpu/drm/i915/i915_reg.h |  4 +---
  2 files changed, 31 insertions(+), 20 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
 index 9691f0f..a9b7770 100644
 --- a/drivers/gpu/drm/i915/i915_dma.c
 +++ b/drivers/gpu/drm/i915/i915_dma.c
 @@ -611,9 +611,21 @@ static void gen9_sseu_info_init(struct drm_device *dev)
  {
   struct drm_i915_private *dev_priv = dev-dev_private;
   struct intel_device_info *info;
 - const int s_max = 3, ss_max = 4, eu_max = 8;
 + int s_max = 3, ss_max = 4, eu_max = 8;
   int s, ss;
 - u32 fuse2, eu_disable[s_max], s_enable, ss_disable;
 + u32 fuse2, s_enable, ss_disable, eu_disable;
 + u8 eu_mask = 0xff;
 +
 + /*
 +  * BXT has a single slice. BXT also has at most 6 EU per subslice,
 +  * and therefore only the lowest 6 bits of the 8-bit EU disable
 +  * fields are valid.
 + */
 + if (IS_BROXTON(dev)) {
 + s_max = 1;
 + eu_max = 6;
 + eu_mask = 0x3f;
 + }
  
   info = (struct intel_device_info *)dev_priv-info;
   fuse2 = I915_READ(GEN8_FUSE2);
 @@ -622,10 +634,6 @@ static void gen9_sseu_info_init(struct drm_device *dev)
   ss_disable = (fuse2  GEN9_F2_SS_DIS_MASK) 
GEN9_F2_SS_DIS_SHIFT;
  
 - eu_disable[0] = I915_READ(GEN8_EU_DISABLE0);
 - eu_disable[1] = I915_READ(GEN8_EU_DISABLE1);
 - eu_disable[2] = I915_READ(GEN8_EU_DISABLE2);
 -
   info-slice_total = hweight32(s_enable);
   /*
* The subslice disable field is global, i.e. it applies
 @@ -644,25 +652,26 @@ static void gen9_sseu_info_init(struct drm_device *dev)
   /* skip disabled slice */
   continue;
  
 + eu_disable = I915_READ(GEN9_EU_DISABLE(s));
   for (ss = 0; ss  ss_max; ss++) {
 - u32 n_disabled;
 + int eu_per_ss;
  
   if (ss_disable  (0x1  ss))
   /* skip disabled subslice */
   continue;
  
 - n_disabled = hweight8(eu_disable[s] 
 -   (ss * eu_max));
 + eu_per_ss = eu_max - hweight8((eu_disable  (ss*8)) 
 +   eu_mask);
  
   /*
* Record which subslice(s) has(have) 7 EUs. we
* can tune the hash used to spread work among
* subslices if they are unbalanced.
*/
 - if (eu_max - n_disabled == 7)
 + if (eu_per_ss == 7)
   info-subslice_7eu[s] |= 1  ss;
  
 - info-eu_total += eu_max - n_disabled;
 + info-eu_total += eu_per_ss;
   }
   }
  
 @@ -670,7 +679,8 @@ static void gen9_sseu_info_init(struct drm_device *dev)
* SKL is expected to always have a uniform distribution
* of EU across subslices with the exception that any one
* EU in any one subslice may be fused off for die
 -  * recovery.
 +  * recovery. BXT is expected to be perfectly uniform in EU
 +  * distribution.

Nitpick: I would have added here an assertion for BXT about the above.
The patchset looks otherwise ok to me, so on 1-4:
Reviewed-by: Imre Deak imre.d...@intel.com

   */
   info-eu_per_subslice = info-subslice_total ?
   DIV_ROUND_UP(info-eu_total,
 @@ -678,11 +688,14 @@ static void gen9_sseu_info_init(struct drm_device *dev)
   /*
* SKL supports slice power gating on devices with more than
* one slice, and supports EU power gating on devices with
 -  * more than one EU pair per subslice.
 +  * more than one EU pair per subslice. BXT supports subslice
 +  * power gating on devices with more than one subslice, and
 +  * supports EU power gating on devices with more than one EU
 +  * pair per subslice.
   */
 - info-has_slice_pg = (info-slice_total  1) ? 1 : 0;
 - info-has_subslice_pg = 0;
 - info-has_eu_pg = (info-eu_per_subslice  2) ? 1 : 0;
 + info-has_slice_pg = (IS_SKYLAKE(dev)  (info-slice_total  1));
 + info-has_subslice_pg = (IS_BROXTON(dev)  (info-subslice_total  1));
 + info-has_eu_pg = (info-eu_per_subslice  2);
  }
  
  /*
 @@ -747,7 +760,7 @@ static void intel_device_info_runtime_init(struct 
 drm_device *dev)
   /* Initialize slice/subslice/EU info */
   if 

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Make atomic use in-flight state for CRTC active value

[Ville Syrjälä]

On Thu, Apr 09, 2015 at 07:10:57AM -0700, Matt Roper wrote:
 On Thu, Apr 09, 2015 at 04:18:56PM +0300, Ville Syrjälä wrote:
  On Wed, Apr 08, 2015 at 06:56:51PM -0700, Matt Roper wrote:
   Our atomic plane code currently uses intel_crtc-active to determine
   how/when to update some derived state values.  This works fine for pure
   plane updates at the moment since the CRTC state itself isn't changed as
   part of the operation.  However as we convert more of our driver
   internals over to atomic modesetting, we need to look at whether the
   CRTC will be active at the *end* of the atomic transaction (which may
   not match the currently committed state).
   
   The in-flight value we want to use is generally in a crtc_state object
   associated with our top-level atomic transaction.  However there are a
   few cases where this isn't the case:
   
* While using transitional atomic helpers (as we are at the moment),
  SetPlane() calls will operate on orphaned plane states that aren't
  part of a top-level atomic transaction.  In this case, we're not
  touching the CRTC state, so it's fine to use the already-committed
  value from crtc-state.
   
* While updating properties of a disabled plane, we'll have a top-level
  atomic state, but it may not contain the CRTC state we're looking
  for.  Once again, this means we're not actually touching any CRTC
  state so it's safe to use the value from crtc-state directly.
   
   Signed-off-by: Matt Roper matthew.d.ro...@intel.com
   ---
drivers/gpu/drm/i915/intel_atomic_plane.c | 11 +++--
drivers/gpu/drm/i915/intel_display.c  | 73 
   +--
drivers/gpu/drm/i915/intel_drv.h  |  3 ++
drivers/gpu/drm/i915/intel_sprite.c   | 16 +--
4 files changed, 93 insertions(+), 10 deletions(-)
   
   diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
   b/drivers/gpu/drm/i915/intel_atomic_plane.c
   index 976b891..90c4a82 100644
   --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
   +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
   @@ -111,12 +111,17 @@ static int intel_plane_atomic_check(struct 
   drm_plane *plane,
{
 struct drm_crtc *crtc = state-crtc;
 struct intel_crtc *intel_crtc;
   + struct intel_crtc_state *intel_crtc_state;
 struct intel_plane *intel_plane = to_intel_plane(plane);
 struct intel_plane_state *intel_state = to_intel_plane_state(state);
   + bool active;

 crtc = crtc ? crtc : plane-crtc;
 intel_crtc = to_intel_crtc(crtc);

   + intel_crtc_state = intel_crtc_state_for_plane(intel_state);
   + active = intel_crtc_state-base.enable;
   +
 /*
  * Both crtc and plane-crtc could be NULL if we're updating a
  * property while the plane is disabled.  We don't actually have
   @@ -143,10 +148,8 @@ static int intel_plane_atomic_check(struct drm_plane 
   *plane,
 /* Clip all planes to CRTC size, or 0x0 if CRTC is disabled */
 intel_state-clip.x1 = 0;
 intel_state-clip.y1 = 0;
   - intel_state-clip.x2 =
   - intel_crtc-active ? intel_crtc-config-pipe_src_w : 0;
   - intel_state-clip.y2 =
   - intel_crtc-active ? intel_crtc-config-pipe_src_h : 0;
   + intel_state-clip.x2 = active ? intel_crtc_state-pipe_src_w : 0;
   + intel_state-clip.y2 = active ? intel_crtc_state-pipe_src_h : 0;
  
  We depend on the clipping to keep planes from getting enabled on a
  disabled pipe. So I think this is going to blow up.
 
 That was why I made these changes...the idea here was that we should be
 basing that clipping on what the CRTC state is going to be when the
 plane state is actually committed, not what it happens to be now.  So if
 the CRTC is going to be disabled, this should ensure that the planes are
 properly clipped to off, even if the CRTC happens to be running at the
 moment.  Conversely, if the CRTC is off at the moment, but will be on at
 the end of this transaction, we want to make sure that the planes are
 not improperly clipped to invisible, otherwise they won't show up.

Well yeah, we want to change the clipping computation to use the future
state but I don't think were ready for it yet. At least I wouldn't want
to make this change until the watermark code gets fixed and we clean up
the primary/cursor plane state handling.

For instance what happens if you dpms off and then enable a plane? If
the clipping is based on the enabled state of the crtc then it'll try
to enable the plane, no?

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

Re: [Intel-gfx] [PATCH v5] drm/i915: add bxt gmbus support

[Imre Deak]

On Wed, 2015-04-01 at 10:58 +0300, Jani Nikula wrote:
 For BXT gmbus is pulled from PCH to CPU. From implementation point of
 view only pin pair configuration will change. The existing
 implementation supports all platforms previous to GEN8 and also SKL. But
 for BXT pin pair configuration is completely different than SKL or other
 previous GEN's. This patch introduces the new pin pair configuration
 structure specific to BXT and also ensures every real gmbus port has a
 gpio pin.
 
 v3 by Jani: with the platform independent prep work in place, the bxt
 enabling reduces to a fairly trivial patch. Credits are due Sunil for
 giving me the ideas (with his patches) what the platform independent
 parts should look like.
 
 v4: Fix intel_hdmi_init_connector() for bxt. Abstract gmbus_pin access
 more. s/GPU/PCH/ in commit message.
 
 v5: Rebase.
 
 Issue: VIZ-3574
 Signed-off-by: A.Sunil Kamath sunil.kam...@intel.com
 Signed-off-by: Jani Nikula jani.nik...@intel.com
 ---
  drivers/gpu/drm/i915/i915_reg.h   |  3 +++
  drivers/gpu/drm/i915/intel_hdmi.c | 14 +++---
  drivers/gpu/drm/i915/intel_i2c.c  | 30 +++---
  3 files changed, 41 insertions(+), 6 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
 index b134fa39c5b8..a2889013088f 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -1797,6 +1797,9 @@ enum skl_disp_power_wells {
  #define   GMBUS_PIN_DPB  5 /* SDVO, HDMIB */
  #define   GMBUS_PIN_DPD  6 /* HDMID */
  #define   GMBUS_PIN_RESERVED 7 /* 7 reserved */
 +#define   GMBUS_PIN_1_BXT1
 +#define   GMBUS_PIN_2_BXT2
 +#define   GMBUS_PIN_3_BXT3

I would have called these GMBUS_PIN_DDI_{B,C,A}_BXT to have a more
descriptive name (and since the pin-port mapping is fixed). Either way
the patch looks ok:
Reviewed-by: Imre Deak imre.d...@intel.com

  #define   GMBUS_NUM_PINS 7 /* including 0 */
  #define GMBUS1   0x5104 /* command/status */
  #define   GMBUS_SW_CLR_INT   (131)
 diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
 b/drivers/gpu/drm/i915/intel_hdmi.c
 index 26222e6c1ff3..587bab6e5f60 100644
 --- a/drivers/gpu/drm/i915/intel_hdmi.c
 +++ b/drivers/gpu/drm/i915/intel_hdmi.c
 @@ -1681,15 +1681,23 @@ void intel_hdmi_init_connector(struct 
 intel_digital_port *intel_dig_port,
  
   switch (port) {
   case PORT_B:
 - intel_hdmi-ddc_bus = GMBUS_PIN_DPB;
 + if (IS_BROXTON(dev_priv))
 + intel_hdmi-ddc_bus = GMBUS_PIN_1_BXT;
 + else
 + intel_hdmi-ddc_bus = GMBUS_PIN_DPB;
   intel_encoder-hpd_pin = HPD_PORT_B;
   break;
   case PORT_C:
 - intel_hdmi-ddc_bus = GMBUS_PIN_DPC;
 + if (IS_BROXTON(dev_priv))
 + intel_hdmi-ddc_bus = GMBUS_PIN_2_BXT;
 + else
 + intel_hdmi-ddc_bus = GMBUS_PIN_DPC;
   intel_encoder-hpd_pin = HPD_PORT_C;
   break;
   case PORT_D:
 - if (IS_CHERRYVIEW(dev))
 + if (WARN_ON(IS_BROXTON(dev_priv)))
 + intel_hdmi-ddc_bus = GMBUS_PIN_DISABLED;
 + else if (IS_CHERRYVIEW(dev_priv))
   intel_hdmi-ddc_bus = GMBUS_PIN_DPD_CHV;
   else
   intel_hdmi-ddc_bus = GMBUS_PIN_DPD;
 diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
 b/drivers/gpu/drm/i915/intel_i2c.c
 index ec9cc8cf642e..cadbc17d2775 100644
 --- a/drivers/gpu/drm/i915/intel_i2c.c
 +++ b/drivers/gpu/drm/i915/intel_i2c.c
 @@ -49,10 +49,33 @@ static const struct gmbus_pin gmbus_pins[] = {
   [GMBUS_PIN_DPD] = { dpd, GPIOF },
  };
  
 +static const struct gmbus_pin gmbus_pins_bxt[] = {
 + [GMBUS_PIN_1_BXT] = { dpb, PCH_GPIOB },
 + [GMBUS_PIN_2_BXT] = { dpc, PCH_GPIOC },
 + [GMBUS_PIN_3_BXT] = { misc, PCH_GPIOD },
 +};
 +
 +/* pin is expected to be valid */
 +static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private 
 *dev_priv,
 +  unsigned int pin)
 +{
 + if (IS_BROXTON(dev_priv))
 + return gmbus_pins_bxt[pin];
 + else
 + return gmbus_pins[pin];
 +}
 +
  bool intel_gmbus_is_valid_pin(struct drm_i915_private *dev_priv,
 unsigned int pin)
  {
 - return pin  ARRAY_SIZE(gmbus_pins)  gmbus_pins[pin].reg;
 + unsigned int size;
 +
 + if (IS_BROXTON(dev_priv))
 + size = ARRAY_SIZE(gmbus_pins_bxt);
 + else
 + size = ARRAY_SIZE(gmbus_pins);
 +
 + return pin  size  get_gmbus_pin(dev_priv, pin)-reg;
  }
  
  /* Intel GPIO access functions */
 @@ -196,7 +219,8 @@ intel_gpio_setup(struct intel_gmbus *bus, unsigned int 
 pin)
  
   algo = bus-bit_algo;
  
 - bus-gpio_reg = dev_priv-gpio_mmio_base + gmbus_pins[pin].reg;
 + bus-gpio_reg = dev_priv-gpio_mmio_base +
 + 

[Intel-gfx] [PATCH] drm/i915/chv: Remove DPIO force latency causing interpair skew issue

[clinton . a . taylor]

From: Clint Taylor clinton.a.tay...@intel.com

Latest version of the CHV DPIO programming notes no longer requires writes
to TX DW 11 to fix a +2UI interpair skew issue. The current code from
April 2014 was actually causing additional skew issues between all
TMDS pairs.

Signed-off-by: Clint Taylor clinton.a.tay...@intel.com
---
 drivers/gpu/drm/i915/intel_hdmi.c |5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 26222e6..3cef326 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1515,11 +1515,6 @@ static void chv_hdmi_pre_enable(struct intel_encoder 
*encoder)
 
/* Program Tx latency optimal setting */
for (i = 0; i  4; i++) {
-   /* Set the latency optimal bit */
-   data = (i == 1) ? 0x0 : 0x6;
-   vlv_dpio_write(dev_priv, pipe, CHV_TX_DW11(ch, i),
-   data  DPIO_FRC_LATENCY_SHFIT);
-
/* Set the upar bit */
data = (i == 1) ? 0x0 : 0x1;
vlv_dpio_write(dev_priv, pipe, CHV_TX_DW14(ch, i),
-- 
1.7.9.5

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix the VBT child device parsing for BSW

[Damien Lespiau]

On Thu, Apr 09, 2015 at 01:37:10PM +0300, Ville Syrjälä wrote:
 On Thu, Apr 09, 2015 at 09:49:25AM +0100, Damien Lespiau wrote:
  On Wed, Mar 25, 2015 at 06:45:58PM +0200, ville.syrj...@linux.intel.com 
  wrote:
   +static union child_device_config *
   +child_device_ptr(struct bdb_general_definitions *p_defs, int i)
   +{
   + return (void *) p_defs-devices[i * p_defs-child_dev_size];
   +}
  
  Actually this looks wrong. We're doing:
  
p_defs-devices + sizeof(union child_device_config) * i * child_dev_size
  
  instead of:
  
(u8)p_defs-devices + i * child_dev_size
  
  ?
 
 The patch also had:
 - union child_device_config devices[0];
 + uint8_t devices[0];

Ah, yes! oops

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

Re: [Intel-gfx] [PATCH 15/19] drm/i915: HSW cdclk support

[Takashi Iwai]

At Thu, 9 Apr 2015 15:51:27 +0200,
Daniel Vetter wrote:
 
 On Thu, Apr 09, 2015 at 04:41:26PM +0300, Mika Kahola wrote:
  On Thu, 2015-04-09 at 11:32 +0200, Daniel Vetter wrote:
   On Thu, Apr 09, 2015 at 10:24:24AM +0300, Mika Kahola wrote:
I did some testing on audio part with HDMI-HDMI and DP-HDMI cables
connected to my Haswell box. Before applying the patch I tested as a
reference with the latest -nightly (04-08-2015), 4.0-rc7. Unfortunately,
I failed to get any audio over HDMI cable. For a reference I tested with
the very same setup the vanillla kernel from Linus tree 4.0-rc7 and with
that kernel the audio worked ok. Then I did some GIT bisecting and it
turned out that the first commit that I failed to get audio working was
aa2fee4286e43b4784982b17669b02cc99c1ae55.
   
  I rerun the bisecting and this time the result was
  
  commit 0a599838737a2527c35e4d94f794aefe59df1781
  Merge: 2d846c7 a59d719
  Author: Takashi Iwai ti...@suse.de
  Date:   Wed Apr 8 11:29:56 2015 +0200
  
  Merge branch 'for-linus' into for-next
  
  Back merge HD-audio quirks to for-next branch, so that we can apply
  a couple of more quirks.
  
  Signed-off-by: Takashi Iwai ti...@suse.de
 
 Adding Takashi and intel audio folks.

The bisecting looks odd.  The commit you pointed is a back-merge from
4.0-rc to next branch, so this merge itself shouldn't bring so many
stuff -- at least about the sound part.

The diff in sound/* is found below.  As you can see, the only change
relevant with HDMI is the chunk in sound/pci/hda/hda_intel.c for
HD-audio controller, but it's specific to Skylake, thus this must be
irrelevant with your hardware.

Please double-check.


thanks,

Takashi

===
% git diff 
0a599838737a2527c35e4d94f794aefe59df1781^..0a599838737a2527c35e4d94f794aefe59df1781
 sound
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 9bcc5457a83e..e1c210515581 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1967,7 +1967,7 @@ static const struct pci_device_id azx_ids[] = {
  .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
/* Sunrise Point */
{ PCI_DEVICE(0x8086, 0xa170),
- .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
+ .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_SKYLAKE },
/* Sunrise Point-LP */
{ PCI_DEVICE(0x8086, 0x9d70),
  .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_SKYLAKE },
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index e0c06f9a0e80..7f46d063af57 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -396,7 +396,7 @@ static void alc_auto_setup_eapd(struct hda_codec *codec, 
bool on)
 {
/* We currently only handle front, HP */
static hda_nid_t pins[] = {
-   0x0f, 0x10, 0x14, 0x15, 0
+   0x0f, 0x10, 0x14, 0x15, 0x17, 0
};
hda_nid_t *p;
for (p = pins; *p; p++)
@@ -2870,6 +2870,8 @@ static void alc283_init(struct hda_codec *codec)
 
if (!hp_pin)
return;
+
+   msleep(30);
hp_pin_sense = snd_hda_jack_detect(codec, hp_pin);
 
/* Index 0x43 Direct Drive HP AMP LPM Control 1 */
@@ -3564,6 +3566,7 @@ static void alc_headset_mode_unplugged(struct hda_codec 
*codec)
 
switch (codec-core.vendor_id) {
case 0x10ec0255:
+   case 0x10ec0256:
alc_process_coef_fw(codec, coef0255);
break;
case 0x10ec0233:
@@ -3619,6 +3622,7 @@ static void alc_headset_mode_mic_in(struct hda_codec 
*codec, hda_nid_t hp_pin,
 
switch (codec-core.vendor_id) {
case 0x10ec0255:
+   case 0x10ec0256:
alc_write_coef_idx(codec, 0x45, 0xc489);
snd_hda_set_pin_ctl_cache(codec, hp_pin, 0);
alc_process_coef_fw(codec, coef0255);
@@ -3688,6 +3692,7 @@ static void alc_headset_mode_default(struct hda_codec 
*codec)
 
switch (codec-core.vendor_id) {
case 0x10ec0255:
+   case 0x10ec0256:
alc_process_coef_fw(codec, coef0255);
break;
case 0x10ec0233:
@@ -3742,6 +3747,7 @@ static void alc_headset_mode_ctia(struct hda_codec *codec)
 
switch (codec-core.vendor_id) {
case 0x10ec0255:
+   case 0x10ec0256:
alc_process_coef_fw(codec, coef0255);
break;
case 0x10ec0233:
@@ -3796,6 +3802,7 @@ static void alc_headset_mode_omtp(struct hda_codec *codec)
 
switch (codec-core.vendor_id) {
case 0x10ec0255:
+   case 0x10ec0256:
alc_process_coef_fw(codec, coef0255);
break;
case 0x10ec0233:
@@ -3841,6 +3848,7 @@ static void alc_determine_headset_type(struct hda_codec 
*codec)
 
switch (codec-core.vendor_id) {
case 0x10ec0255:
+   case 0x10ec0256:
alc_process_coef_fw(codec, coef0255);

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Switch to full atomic helpers for plane updates/disable, take two

[Matt Roper]

On Thu, Apr 09, 2015 at 02:46:19PM +0200, Daniel Vetter wrote:
 On Wed, Apr 08, 2015 at 06:56:53PM -0700, Matt Roper wrote:
  Switch from our plane update/disable entrypoints to use the full atomic
  helpers (which generate a top-level atomic transaction) rather than the
  transitional helpers (which only create/manipulate orphaned plane states
  independent of a top-level transaction).  Various upcoming work (SKL
  scalers, atomic watermarks, etc.) requires a full atomic transaction to
  behave properly/cleanly.
  
  Last time we tried this, we had to back out the change because we still
  call the drm_plane vfuncs directly from within our legacy modesetting
  code.  This potentially results in nested atomic transactions, locking
  collisions, and other failures.  To avoid that problem again, we
  sidestep the issue by calling the transitional helpers directly (rather
  than through a vfunc) when we're nested inside of other legacy
  modesetting code.  However this does allow legacy SetPlane() ioctl's to
  process an entire drm_atomic_state transaction, which is important for
  upcoming patches.
  
  Cc: Chandra Konduru chandra.kond...@intel.com
  Signed-off-by: Matt Roper matthew.d.ro...@intel.com
 
 Maarten is working to fix this properly (by wiring up plane states to the
 transitional drm_atomic_state scaffolding from Ander), but seems like a
 good interim idea to get back some solid testing for our atomic code.
 
 Can I apply this without patches 12 right away or is there a tricky
 depency?
 -Daniel

I think this one can be applied independently of 12.  I think this one
might be a prereq for #4 to fully work as advertised though...without
using the full atomic helpers, we simply don't have a 'start of
transaction' point at which we can clear the existing atomic flags when
using legacy plane ioctls.


Matt

 
  ---
   drivers/gpu/drm/i915/intel_display.c | 24 
   drivers/gpu/drm/i915/intel_sprite.c  | 10 +-
   2 files changed, 17 insertions(+), 17 deletions(-)
  
  diff --git a/drivers/gpu/drm/i915/intel_display.c 
  b/drivers/gpu/drm/i915/intel_display.c
  index 1cf91ad..3a74923 100644
  --- a/drivers/gpu/drm/i915/intel_display.c
  +++ b/drivers/gpu/drm/i915/intel_display.c
  @@ -5576,7 +5576,7 @@ static void intel_crtc_disable(struct drm_crtc *crtc)
  dev_priv-display.crtc_disable(crtc);
  dev_priv-display.off(crtc);
   
  -   crtc-primary-funcs-disable_plane(crtc-primary);
  +   drm_plane_helper_disable(crtc-primary);
   
  /* Update computed state. */
  list_for_each_entry(connector, dev-mode_config.connector_list, head) {
  @@ -11731,11 +11731,11 @@ static int __intel_set_mode(struct drm_crtc *crtc,
  int vdisplay, hdisplay;
   
  drm_crtc_get_hv_timing(mode, hdisplay, vdisplay);
  -   ret = primary-funcs-update_plane(primary, intel_crtc-base,
  -  fb, 0, 0,
  -  hdisplay, vdisplay,
  -  x  16, y  16,
  -  hdisplay  16, vdisplay  
  16);
  +   ret = drm_plane_helper_update(primary, intel_crtc-base,
  + fb, 0, 0,
  + hdisplay, vdisplay,
  + x  16, y  16,
  + hdisplay  16, vdisplay  16);
  }
   
  /* Now enable the clocks, plane, pipe, and connectors that we set up. */
  @@ -12286,10 +12286,10 @@ static int intel_crtc_set_config(struct 
  drm_mode_set *set)
  int vdisplay, hdisplay;
   
  drm_crtc_get_hv_timing(set-mode, hdisplay, vdisplay);
  -   ret = primary-funcs-update_plane(primary, set-crtc, set-fb,
  -  0, 0, hdisplay, vdisplay,
  -  set-x  16, set-y  16,
  -  hdisplay  16, vdisplay  
  16);
  +   ret = drm_plane_helper_update(primary, set-crtc, set-fb,
  + 0, 0, hdisplay, vdisplay,
  + set-x  16, set-y  16,
  + hdisplay  16, vdisplay  16);
   
  /*
   * We need to make sure the primary plane is re-enabled if it
  @@ -12830,8 +12830,8 @@ void intel_plane_destroy(struct drm_plane *plane)
   }
   
   const struct drm_plane_funcs intel_plane_funcs = {
  -   .update_plane = drm_plane_helper_update,
  -   .disable_plane = drm_plane_helper_disable,
  +   .update_plane = drm_atomic_helper_update_plane,
  +   .disable_plane = drm_atomic_helper_disable_plane,
  .destroy = intel_plane_destroy,
  .set_property = drm_atomic_helper_plane_set_property,
  .atomic_get_property = intel_plane_atomic_get_property,
  diff --git a/drivers/gpu/drm/i915/intel_sprite.c 

[Intel-gfx] [PATCH i-g-t 2/2] lib: use test failure status for igt_set_timeout

[Thomas Wood]

Use a failure status code for timeout to avoid confusion between tests
that take too long to execute versus a failure due to an operation
taking longer than expected.

Signed-off-by: Thomas Wood thomas.w...@intel.com
---
 lib/igt_core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/igt_core.c b/lib/igt_core.c
index f9e92c9..e5bda86 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -1705,15 +1705,15 @@ out:
 
 static void igt_alarm_handler(int signal)
 {
-   /* exit with timeout status */
-   igt_fail(IGT_EXIT_TIMEOUT);
+   /* exit with failure status */
+   igt_fail(IGT_EXIT_FAILURE);
 }
 
 /**
  * igt_set_timeout:
  * @seconds: number of seconds before timeout
  *
- * Fail a test and exit with #IGT_EXIT_TIMEOUT status after the specified
+ * Fail a test and exit with #IGT_EXIT_FAILURE status after the specified
  * number of seconds have elapsed. If the current test has subtests and the
  * timeout occurs outside a subtest, subsequent subtests will be skipped and
  * marked as failed.
-- 
2.1.0

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

[Intel-gfx] [PATCH i-g-t 1/2] lib: add a define for test failure exit status

[Thomas Wood]

Signed-off-by: Thomas Wood thomas.w...@intel.com
---
 lib/igt.cocci  |  2 +-
 lib/igt_core.c |  6 +++---
 lib/igt_core.h | 18 --
 lib/intel_batchbuffer.c|  2 +-
 tests/gem_ring_sync_copy.c |  2 +-
 tests/kms_sink_crc_basic.c |  2 +-
 6 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/lib/igt.cocci b/lib/igt.cocci
index 156f0cf..f23b511 100644
--- a/lib/igt.cocci
+++ b/lib/igt.cocci
@@ -73,7 +73,7 @@ expression list[n] Ep;
 @@
 @@
 -abort();
-+igt_fail(1);
++igt_fail(IGT_EXIT_FAILURE);
 
 @@
 iterator name for_each_pipe;
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 8d60930..f9e92c9 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -993,8 +993,8 @@ static void print_backtrace(void)
 }
 #endif
 
-void __igt_fail_assert(int exitcode, const char *domain, const char *file,
-  const int line, const char *func, const char *assertion,
+void __igt_fail_assert(const char *domain, const char *file, const int line,
+  const char *func, const char *assertion,
   const char *f, ...)
 {
va_list args;
@@ -1020,7 +1020,7 @@ void __igt_fail_assert(int exitcode, const char *domain, 
const char *file,
 
if (run_under_gdb())
abort();
-   igt_fail(exitcode);
+   igt_fail(IGT_EXIT_FAILURE);
 }
 
 /**
diff --git a/lib/igt_core.h b/lib/igt_core.h
index 4e56be8..3a9e582 100644
--- a/lib/igt_core.h
+++ b/lib/igt_core.h
@@ -84,6 +84,12 @@ extern const char* __igt_test_description 
__attribute__((weak));
  */
 #define IGT_EXIT_INVALID 79
 
+/**
+ * IGT_EXIT_FAILURE
+ *
+ * Exit status indicating a test failure
+ */
+#define IGT_EXIT_FAILURE 99
 
 bool __igt_fixture(void);
 void __igt_fixture_complete(void);
@@ -250,8 +256,8 @@ void __igt_skip_check(const char *file, const int line,
 void igt_success(void);
 
 void igt_fail(int exitcode) __attribute__((noreturn));
-__attribute__((format(printf, 7, 8)))
-void __igt_fail_assert(int exitcode, const char *domain, const char *file,
+__attribute__((format(printf, 6, 7)))
+void __igt_fail_assert(const char *domain, const char *file,
   const int line, const char *func, const char *assertion,
   const char *format, ...)
__attribute__((noreturn));
@@ -267,7 +273,7 @@ void igt_exit(void) __attribute__((noreturn));
  */
 #define igt_assert(expr) \
do { if (!(expr)) \
-   __igt_fail_assert(99, IGT_LOG_DOMAIN, __FILE__, __LINE__, 
__func__, #expr , NULL); \
+   __igt_fail_assert(IGT_LOG_DOMAIN, __FILE__, __LINE__, __func__, 
#expr , NULL); \
} while (0)
 
 /**
@@ -284,7 +290,7 @@ void igt_exit(void) __attribute__((noreturn));
  */
 #define igt_assert_f(expr, f...) \
do { if (!(expr)) \
-   __igt_fail_assert(99, IGT_LOG_DOMAIN, __FILE__, __LINE__, 
__func__, #expr , f); \
+   __igt_fail_assert(IGT_LOG_DOMAIN, __FILE__, __LINE__, __func__, 
#expr , f); \
} while (0)
 
 /**
@@ -329,7 +335,7 @@ void igt_exit(void) __attribute__((noreturn));
do { \
int __n1 = (n1), __n2 = (n2); \
if (__n1 cmp __n2) ; else \
-   __igt_fail_assert(99, IGT_LOG_DOMAIN, __FILE__, __LINE__, 
__func__, \
+   __igt_fail_assert(IGT_LOG_DOMAIN, __FILE__, __LINE__, __func__, 
\
  #n1   #cmp   #n2, \
  error: %d  #ncmp  %d\n, __n1, __n2); \
} while (0)
@@ -338,7 +344,7 @@ void igt_exit(void) __attribute__((noreturn));
do { \
uint32_t __n1 = (n1), __n2 = (n2); \
if (__n1 cmp __n2) ; else \
-   __igt_fail_assert(99, IGT_LOG_DOMAIN, __FILE__, __LINE__, 
__func__, \
+   __igt_fail_assert(IGT_LOG_DOMAIN, __FILE__, __LINE__, __func__, 
\
  #n1   #cmp   #n2, \
  error: %#x  #ncmp  %#x\n, __n1, __n2); \
} while (0)
diff --git a/lib/intel_batchbuffer.c b/lib/intel_batchbuffer.c
index a1b0643..8b68e52 100644
--- a/lib/intel_batchbuffer.c
+++ b/lib/intel_batchbuffer.c
@@ -377,7 +377,7 @@ intel_blt_copy(struct intel_batchbuffer *batch,
XY_SRC_COPY_BLT_WRITE_RGB;
break;
default:
-   igt_fail(1);
+   igt_fail(IGT_EXIT_FAILURE);
}
 
BLIT_COPY_BATCH_START(cmd_bits);
diff --git a/tests/gem_ring_sync_copy.c b/tests/gem_ring_sync_copy.c
index f5ffddc..13af198 100644
--- a/tests/gem_ring_sync_copy.c
+++ b/tests/gem_ring_sync_copy.c
@@ -317,7 +317,7 @@ static void run_test(data_t *data, enum ring r1, enum ring 
r2, enum test test)
bo_check(data, b, 0xc);
break;
default:
-   igt_fail(1);
+   igt_fail(IGT_EXIT_FAILURE);
}
 
r1_ops-busy_fini(data);
diff --git a/tests/kms_sink_crc_basic.c b/tests/kms_sink_crc_basic.c

Re: [Intel-gfx] [PATCH] drm/i915: Fix locking in DRRS flush/invalidate hooks

[Ville Syrjälä]

On Thu, Apr 09, 2015 at 12:52:19PM +0300, Jani Nikula wrote:
 On Thu, 09 Apr 2015, Daniel Vetter daniel.vet...@ffwll.ch wrote:
  We must acquire the mutex before we can check drrs.dp, otherwise
  someone might sneak in with a modeset, clear the pointer after we've
  checked it and then the code will Oops.
 
  This issue has been introduced in
 
  commit a93fad0f7fb8a3ff12e8814b630648f6d187954c
  Author: Vandana Kannan vandana.kan...@intel.com
  Date:   Sat Jan 10 02:25:59 2015 +0530
 
  drm/i915: DRRS calls based on frontbuffer
 
  Cc: Ramalingam C ramalinga...@intel.com
  Cc: Rodrigo Vivi rodrigo.v...@intel.com
  Cc: Vandana Kannan vandana.kan...@intel.com
  Signed-off-by: Daniel Vetter daniel.vet...@intel.com
 
 Missed 4.0 so this is

Fortunately so since it makes my BSW deadlock on module load. And Mika
says his IVB is showing similar symptoms.

 
 Cc: sta...@vger.kernel.org
 
 
  ---
   drivers/gpu/drm/i915/intel_dp.c | 17 ++---
   1 file changed, 10 insertions(+), 7 deletions(-)
 
  diff --git a/drivers/gpu/drm/i915/intel_dp.c 
  b/drivers/gpu/drm/i915/intel_dp.c
  index 1b87969536ff..e265a0dee479 100644
  --- a/drivers/gpu/drm/i915/intel_dp.c
  +++ b/drivers/gpu/drm/i915/intel_dp.c
  @@ -5170,7 +5170,6 @@ static void intel_edp_drrs_downclock_work(struct 
  work_struct *work)
  downclock_mode-vrefresh);
   
   unlock:
  -
  mutex_unlock(dev_priv-drrs.mutex);
   }
   
  @@ -5192,12 +5191,14 @@ void intel_edp_drrs_invalidate(struct drm_device 
  *dev,
  struct drm_crtc *crtc;
  enum pipe pipe;
   
  -   if (!dev_priv-drrs.dp)
  -   return;
  -
  cancel_delayed_work_sync(dev_priv-drrs.work);
   
  mutex_lock(dev_priv-drrs.mutex);
  +   if (!dev_priv-drrs.dp) {
  +   mutex_unlock(dev_priv-drrs.mutex);
  +   return;
  +   }
  +
  crtc = dp_to_dig_port(dev_priv-drrs.dp)-base.base.crtc;
  pipe = to_intel_crtc(crtc)-pipe;
   
  @@ -5231,12 +5232,14 @@ void intel_edp_drrs_flush(struct drm_device *dev,
  struct drm_crtc *crtc;
  enum pipe pipe;
   
  -   if (!dev_priv-drrs.dp)
  -   return;
  -
  cancel_delayed_work_sync(dev_priv-drrs.work);
   
  mutex_lock(dev_priv-drrs.mutex);
  +   if (!dev_priv-drrs.dp) {
  +   mutex_unlock(dev_priv-drrs.mutex);
  +   return;
  +   }
  +
  crtc = dp_to_dig_port(dev_priv-drrs.dp)-base.base.crtc;
  pipe = to_intel_crtc(crtc)-pipe;
  dev_priv-drrs.busy_frontbuffer_bits = ~frontbuffer_bits;
  -- 
  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

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

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Make atomic use in-flight state for CRTC active value

[Matt Roper]

On Thu, Apr 09, 2015 at 04:18:56PM +0300, Ville Syrjälä wrote:
 On Wed, Apr 08, 2015 at 06:56:51PM -0700, Matt Roper wrote:
  Our atomic plane code currently uses intel_crtc-active to determine
  how/when to update some derived state values.  This works fine for pure
  plane updates at the moment since the CRTC state itself isn't changed as
  part of the operation.  However as we convert more of our driver
  internals over to atomic modesetting, we need to look at whether the
  CRTC will be active at the *end* of the atomic transaction (which may
  not match the currently committed state).
  
  The in-flight value we want to use is generally in a crtc_state object
  associated with our top-level atomic transaction.  However there are a
  few cases where this isn't the case:
  
   * While using transitional atomic helpers (as we are at the moment),
 SetPlane() calls will operate on orphaned plane states that aren't
 part of a top-level atomic transaction.  In this case, we're not
 touching the CRTC state, so it's fine to use the already-committed
 value from crtc-state.
  
   * While updating properties of a disabled plane, we'll have a top-level
 atomic state, but it may not contain the CRTC state we're looking
 for.  Once again, this means we're not actually touching any CRTC
 state so it's safe to use the value from crtc-state directly.
  
  Signed-off-by: Matt Roper matthew.d.ro...@intel.com
  ---
   drivers/gpu/drm/i915/intel_atomic_plane.c | 11 +++--
   drivers/gpu/drm/i915/intel_display.c  | 73 
  +--
   drivers/gpu/drm/i915/intel_drv.h  |  3 ++
   drivers/gpu/drm/i915/intel_sprite.c   | 16 +--
   4 files changed, 93 insertions(+), 10 deletions(-)
  
  diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
  b/drivers/gpu/drm/i915/intel_atomic_plane.c
  index 976b891..90c4a82 100644
  --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
  +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
  @@ -111,12 +111,17 @@ static int intel_plane_atomic_check(struct drm_plane 
  *plane,
   {
  struct drm_crtc *crtc = state-crtc;
  struct intel_crtc *intel_crtc;
  +   struct intel_crtc_state *intel_crtc_state;
  struct intel_plane *intel_plane = to_intel_plane(plane);
  struct intel_plane_state *intel_state = to_intel_plane_state(state);
  +   bool active;
   
  crtc = crtc ? crtc : plane-crtc;
  intel_crtc = to_intel_crtc(crtc);
   
  +   intel_crtc_state = intel_crtc_state_for_plane(intel_state);
  +   active = intel_crtc_state-base.enable;
  +
  /*
   * Both crtc and plane-crtc could be NULL if we're updating a
   * property while the plane is disabled.  We don't actually have
  @@ -143,10 +148,8 @@ static int intel_plane_atomic_check(struct drm_plane 
  *plane,
  /* Clip all planes to CRTC size, or 0x0 if CRTC is disabled */
  intel_state-clip.x1 = 0;
  intel_state-clip.y1 = 0;
  -   intel_state-clip.x2 =
  -   intel_crtc-active ? intel_crtc-config-pipe_src_w : 0;
  -   intel_state-clip.y2 =
  -   intel_crtc-active ? intel_crtc-config-pipe_src_h : 0;
  +   intel_state-clip.x2 = active ? intel_crtc_state-pipe_src_w : 0;
  +   intel_state-clip.y2 = active ? intel_crtc_state-pipe_src_h : 0;
 
 We depend on the clipping to keep planes from getting enabled on a
 disabled pipe. So I think this is going to blow up.

That was why I made these changes...the idea here was that we should be
basing that clipping on what the CRTC state is going to be when the
plane state is actually committed, not what it happens to be now.  So if
the CRTC is going to be disabled, this should ensure that the planes are
properly clipped to off, even if the CRTC happens to be running at the
moment.  Conversely, if the CRTC is off at the moment, but will be on at
the end of this transaction, we want to make sure that the planes are
not improperly clipped to invisible, otherwise they won't show up.

Am I overlooking something?  It seems the current 'active' value is
unrelated to what we actually want to be basing our plane programming on
and just happens to work at the moment since we don't yet let  -active
change over the course of an atomic transaction (meaning the final state
will always be the same as the current state).


Matt

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

Re: [Intel-gfx] [PATCH i-g-t 1/2] tests: ensure scripts and data are included in the distribution

[Joonas Lahtinen]

On ke, 2015-04-08 at 14:56 +0100, Thomas Wood wrote:
 Prefix the test scripts and data variables with dist_ to ensure they are
 included in the distribution.
 
 Cc: Joonas Lahtinen joonas.lahti...@linux.intel.com

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

Comment below.

 Signed-off-by: Thomas Wood thomas.w...@intel.com
 ---
  tests/Makefile.am  | 4 ++--
  tests/Makefile.sources | 6 --
  2 files changed, 2 insertions(+), 8 deletions(-)
 
 diff --git a/tests/Makefile.am b/tests/Makefile.am
 index 7fbf622..d6de373 100644
 --- a/tests/Makefile.am
 +++ b/tests/Makefile.am
 @@ -32,13 +32,13 @@ igt_tests_bin_PROGRAMS += \
   $(TESTS_progs_M) \
   $(NULL)
  
 -igt_tests_bin_SCRIPTS += \
 +dist_igt_tests_bin_SCRIPTS = \
   $(TESTS_scripts) \
   $(TESTS_scripts_M) \
   $(scripts) \
   $(NULL)
  
 -igt_tests_data_DATA += \
 +dist_igt_tests_data_DATA = \
   $(IMAGES) \
   $(NULL)
  
 diff --git a/tests/Makefile.sources b/tests/Makefile.sources
 index 3e3aa57..59a06e9 100644
 --- a/tests/Makefile.sources
 +++ b/tests/Makefile.sources
 @@ -13,12 +13,6 @@ igt_tests_bin_PROGRAMS = \
   $(TESTS_progs_M) \
   $(NULL)
  
 -igt_tests_bin_SCRIPTS = \
 - $(NULL)
 -
 -igt_tests_data_DATA = \
 - $(NULL)
 -

I'd include the movement of the variables (and removal of +=) from the
second patch to here and commit those parts already.

I seem to have myself missed that the fact that both places were adding
same variables to it.

Regards, Joonas

  NOUVEAU_TESTS_M = \
   prime_nv_api \
   prime_nv_pcopy \


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

Re: [Intel-gfx] [PATCH 27/70] drm/i915: Remove vestigal DRI1 ring quiescing code

[Chris Wilson]

On Thu, Apr 09, 2015 at 05:02:36PM +0200, Daniel Vetter wrote:
 On Tue, Apr 07, 2015 at 04:20:51PM +0100, Chris Wilson wrote:
  @@ -640,7 +641,7 @@ static int logical_ring_wait_request(struct 
  intel_ringbuffer *ringbuf,
  break;
  }
   
  -   if (request-list == ring-request_list)
  +   if (WARN_ON(request-list == ring-request_list))
  return -ENOSPC;
 
 Checking for new_space  n (and initializing new_space to 0) would be a
 clearer check imo. But that's just a bikeshed. Same for the legacy one
 below.

If you watch later, I remove the double update of ringbuf-space.
However, I am quite found of the if (iter == list_head) return -ENOSPC,
so I am a bit biased.
-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 15/19] drm/i915: HSW cdclk support

[Mika Kahola]

I did some testing on audio part with HDMI-HDMI and DP-HDMI cables
connected to my Haswell box. Before applying the patch I tested as a
reference with the latest -nightly (04-08-2015), 4.0-rc7. Unfortunately,
I failed to get any audio over HDMI cable. For a reference I tested with
the very same setup the vanillla kernel from Linus tree 4.0-rc7 and with
that kernel the audio worked ok. Then I did some GIT bisecting and it
turned out that the first commit that I failed to get audio working was
aa2fee4286e43b4784982b17669b02cc99c1ae55.

To test this patch audio functionality I checkout the -nightly version
that works for me and apply the patch and test it. I'll come back with
the results later on. 

I had the module option i915.disable_power_well=0

The test routine that I used for audio testing was
speaker-test -c 2 -r 48000 -f S16_LE -t pink --device=plughw:0,3

On Tue, 2015-04-07 at 15:52 +0200, Daniel Vetter wrote:
 On Tue, Apr 07, 2015 at 12:29:25PM +0300, Mika Kahola wrote:
  Definitely a good idea to check the audio part as well if there is
  a doubt that by changing CD clock the audio would fail. I can check
  this and I'll get back once I have the results.
 
 We force a full modeset, which should result in an interrupt on the audio
 side, which should result in the audio driver re-reading the current
 cdclk. If that's no the case it's buggy already.
 -Daniel

-- 
Mika Kahola, Intel OTC



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

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Use remap_io_mapping() to prefault all PTE in a single pass

[Joonas Lahtinen]

On ti, 2015-04-07 at 17:31 +0100, Chris Wilson wrote:
 On an Ivybridge i7-3720qm with 1600MHz DDR3, with 32 fences,
 Upload rate for 2 linear surfaces:  8134MiB/s - 8154MiB/s
 Upload rate for 2 tiled surfaces:   8625MiB/s - 8632MiB/s
 Upload rate for 4 linear surfaces:  8127MiB/s - 8134MiB/s
 Upload rate for 4 tiled surfaces:   8602MiB/s - 8629MiB/s
 Upload rate for 8 linear surfaces:  8124MiB/s - 8137MiB/s
 Upload rate for 8 tiled surfaces:   8603MiB/s - 8624MiB/s
 Upload rate for 16 linear surfaces: 8123MiB/s - 8128MiB/s
 Upload rate for 16 tiled surfaces:  8606MiB/s - 8618MiB/s
 Upload rate for 32 linear surfaces: 8121MiB/s - 8128MiB/s
 Upload rate for 32 tiled surfaces:  8605MiB/s - 8614MiB/s
 Upload rate for 64 linear surfaces: 8121MiB/s - 8127MiB/s
 Upload rate for 64 tiled surfaces:  3017MiB/s - 5202MiB/s
 
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Testcase: igt/gem_fence_upload/performance
 Testcase: igt/gem_mmap_gtt
 Reviewed-by: Brad Volkin bradley.d.vol...@intel.com

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

 Cc: linux...@kvack.org
 ---
  drivers/gpu/drm/i915/i915_gem.c | 23 ++-
  1 file changed, 6 insertions(+), 17 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
 index 7ab8e0039790..90d772f72276 100644
 --- a/drivers/gpu/drm/i915/i915_gem.c
 +++ b/drivers/gpu/drm/i915/i915_gem.c
 @@ -1667,25 +1667,14 @@ int i915_gem_fault(struct vm_area_struct *vma, struct 
 vm_fault *vmf)
   pfn = dev_priv-gtt.mappable_base + i915_gem_obj_ggtt_offset(obj);
   pfn = PAGE_SHIFT;
  
 - if (!obj-fault_mappable) {
 - unsigned long size = min_t(unsigned long,
 -vma-vm_end - vma-vm_start,
 -obj-base.size);
 - int i;
 + ret = remap_io_mapping(vma,
 +vma-vm_start, pfn, vma-vm_end - vma-vm_start,
 +dev_priv-gtt.mappable);
 + if (ret)
 + goto unpin;
  
 - for (i = 0; i  size  PAGE_SHIFT; i++) {
 - ret = vm_insert_pfn(vma,
 - (unsigned long)vma-vm_start + i * 
 PAGE_SIZE,
 - pfn + i);
 - if (ret)
 - break;
 - }
 + obj-fault_mappable = true;
  
 - obj-fault_mappable = true;
 - } else
 - ret = vm_insert_pfn(vma,
 - (unsigned long)vmf-virtual_address,
 - pfn + page_offset);
  unpin:
   i915_gem_object_ggtt_unpin(obj);
  unlock:


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

Re: [Intel-gfx] [PATCH 48/49] drm/i915/bxt: VSwing programming sequence

[Imre Deak]

Hi Sivakumar,

On Tue, 2015-03-24 at 14:49 +0530, Sivakumar Thulasimani wrote:

 On 3/17/2015 3:10 PM, Imre Deak wrote:
 
  From: Vandana Kannan vandana.kan...@intel.com
  
  VSwing programming sequence as specified in the updated BXT BSpec
  ...
  ...
   
  +void bxt_ddi_vswing_sequence(struct drm_device *dev, u32 level,
  +enum port port, int type)
  +{
  +   struct drm_i915_private *dev_priv = dev-dev_private;
  +   const struct bxt_ddi_buf_trans *ddi_translations;
  +   u32 n_entries, i;
  +   uint32_t val;
  +
  +   if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
 INTEL_OUPPUT_DP_MST might be needed here, please check once. otherwise
 fine with the changes.

Tbh, I had to check this after you brought this up: we can't get here
with INTEL_OUTPUT_DP_MST. That type is only assigned to fake encoders,
which only handle the MST aspects of the modeset. An MST encoder like
this will have an associated primary encoder (available via its
primary digital port field) which will handle the ordinary DP aspects
of the modeset. So link training as such is handled by the primary
encoder which for DP will be always either INTEL_OUTPUT_DISPLAYPORT or
INTEL_OUTPUT_EDP.

Thanks for pointing this out,
Imre

 Reviewed-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com


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

Re: [Intel-gfx] [PATCH 2/2] drm/i915/bxt: Add BXT HW status to SSEU status

[shuang . he]

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
Task id: 6105
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  276/276  276/276
ILK  302/302  302/302
SNB  313/313  313/313
IVB  337/337  337/337
BYT  286/286  286/286
HSW  395/395  395/395
BDW  321/321  321/321
-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: Fix the VBT child device parsing for BSW

[Ville Syrjälä]

On Thu, Apr 09, 2015 at 09:49:25AM +0100, Damien Lespiau wrote:
 On Wed, Mar 25, 2015 at 06:45:58PM +0200, ville.syrj...@linux.intel.com wrote:
  +static union child_device_config *
  +child_device_ptr(struct bdb_general_definitions *p_defs, int i)
  +{
  +   return (void *) p_defs-devices[i * p_defs-child_dev_size];
  +}
 
 Actually this looks wrong. We're doing:
 
   p_defs-devices + sizeof(union child_device_config) * i * child_dev_size
 
 instead of:
 
   (u8)p_defs-devices + i * child_dev_size
 
 ?

The patch also had:
- union child_device_config devices[0];
+ uint8_t devices[0];

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

Re: [Intel-gfx] [PATCH] Correct kms_fbc_crc case Debugfs i915_fbc_status shows FBC unsupported on this chipset not unsupported by this chipset if the platform doesn't support FBC feature. That typ

[Liu, Lei A]

I resend that patch. Forgive me that I forgot to add you in cc list. Pardon my 
original disordered commit message.
Really appreciate your guidance.

-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Thursday, April 09, 2015 8:24 PM
To: Liu, Lei A
Cc: intel-gfx@lists.freedesktop.org; Tian, YeX; Jin, Gordon
Subject: Re: [Intel-gfx] [PATCH] Correct kms_fbc_crc case Debugfs 
i915_fbc_status shows FBC unsupported on this chipset not unsupported by 
this chipset if the platform doesn't support FBC feature. That typo will cause 
case fail on some platforms such as byt...

On Thu, Apr 09, 2015 at 01:51:24PM +0800, liu,lei wrote:
 From: liu,lei lei.a@intel.com

In igt we follow the kernel conventions for patch commit messages:
- First line (subject) summarizes the patch in at most 70 chars
- After an empty line comes the extended commit message (you have that in
  the first line so it ends up in the subject).
- signed-off-by line at the bottom.

Can you please fix that up and resubmit?

Thanks, Daniel
 
 ---
  tests/kms_fbc_crc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/tests/kms_fbc_crc.c b/tests/kms_fbc_crc.c index 
 ccdec33..1320bad 100644
 --- a/tests/kms_fbc_crc.c
 +++ b/tests/kms_fbc_crc.c
 @@ -513,7 +513,7 @@ igt_main
   igt_assert_lt(0, fread(buf, 1, sizeof(buf), status));
   fclose(status);
   buf[sizeof(buf) - 1] = '\0';
 - igt_require_f(!strstr(buf, unsupported by this chipset) 
 + igt_require_f(!strstr(buf, unsupported on this chipset) 
 !strstr(buf, disabled per module param) 
 !strstr(buf, disabled per chip default),
 FBC not supported/enabled\n);
 --
 1.8.3.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 15/19] drm/i915: HSW cdclk support

[Mika Kahola]

On Thu, 2015-04-09 at 11:32 +0200, Daniel Vetter wrote:
 On Thu, Apr 09, 2015 at 10:24:24AM +0300, Mika Kahola wrote:
  I did some testing on audio part with HDMI-HDMI and DP-HDMI cables
  connected to my Haswell box. Before applying the patch I tested as a
  reference with the latest -nightly (04-08-2015), 4.0-rc7. Unfortunately,
  I failed to get any audio over HDMI cable. For a reference I tested with
  the very same setup the vanillla kernel from Linus tree 4.0-rc7 and with
  that kernel the audio worked ok. Then I did some GIT bisecting and it
  turned out that the first commit that I failed to get audio working was
  aa2fee4286e43b4784982b17669b02cc99c1ae55.
 
I rerun the bisecting and this time the result was

commit 0a599838737a2527c35e4d94f794aefe59df1781
Merge: 2d846c7 a59d719
Author: Takashi Iwai ti...@suse.de
Date:   Wed Apr 8 11:29:56 2015 +0200

Merge branch 'for-linus' into for-next

Back merge HD-audio quirks to for-next branch, so that we can apply
a couple of more quirks.

Signed-off-by: Takashi Iwai ti...@suse.de

 I don't have this sha1 anywhere. Can you please double-check?
 
 Also to avoid such issues please always add at least the commit subject
 and author, so that I can find it if it's somehow rebased.
 -Daniel
 
  
  To test this patch audio functionality I checkout the -nightly version
  that works for me and apply the patch and test it. I'll come back with
  the results later on. 
  
  I had the module option i915.disable_power_well=0
  
  The test routine that I used for audio testing was
  speaker-test -c 2 -r 48000 -f S16_LE -t pink --device=plughw:0,3
  
  On Tue, 2015-04-07 at 15:52 +0200, Daniel Vetter wrote:
   On Tue, Apr 07, 2015 at 12:29:25PM +0300, Mika Kahola wrote:
Definitely a good idea to check the audio part as well if there is
a doubt that by changing CD clock the audio would fail. I can check
this and I'll get back once I have the results.
   
   We force a full modeset, which should result in an interrupt on the audio
   side, which should result in the audio driver re-reading the current
   cdclk. If that's no the case it's buggy already.
   -Daniel
  
  -- 
  Mika Kahola, Intel OTC
  
  
  
 

-- 
Mika Kahola, Intel OTC



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

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Make atomic use in-flight state for CRTC active value

[Matt Roper]

On Thu, Apr 09, 2015 at 02:42:36PM +0200, Daniel Vetter wrote:
 On Wed, Apr 08, 2015 at 06:56:51PM -0700, Matt Roper wrote:
  Our atomic plane code currently uses intel_crtc-active to determine
  how/when to update some derived state values.  This works fine for pure
  plane updates at the moment since the CRTC state itself isn't changed as
  part of the operation.  However as we convert more of our driver
  internals over to atomic modesetting, we need to look at whether the
  CRTC will be active at the *end* of the atomic transaction (which may
  not match the currently committed state).
  
  The in-flight value we want to use is generally in a crtc_state object
  associated with our top-level atomic transaction.  However there are a
  few cases where this isn't the case:
  
   * While using transitional atomic helpers (as we are at the moment),
 SetPlane() calls will operate on orphaned plane states that aren't
 part of a top-level atomic transaction.  In this case, we're not
 touching the CRTC state, so it's fine to use the already-committed
 value from crtc-state.
  
   * While updating properties of a disabled plane, we'll have a top-level
 atomic state, but it may not contain the CRTC state we're looking
 for.  Once again, this means we're not actually touching any CRTC
 state so it's safe to use the value from crtc-state directly.
  
  Signed-off-by: Matt Roper matthew.d.ro...@intel.com
  ---
   drivers/gpu/drm/i915/intel_atomic_plane.c | 11 +++--
   drivers/gpu/drm/i915/intel_display.c  | 73 
  +--
   drivers/gpu/drm/i915/intel_drv.h  |  3 ++
   drivers/gpu/drm/i915/intel_sprite.c   | 16 +--
   4 files changed, 93 insertions(+), 10 deletions(-)
  
  diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
  b/drivers/gpu/drm/i915/intel_atomic_plane.c
  index 976b891..90c4a82 100644
  --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
  +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
  @@ -111,12 +111,17 @@ static int intel_plane_atomic_check(struct drm_plane 
  *plane,
   {
  struct drm_crtc *crtc = state-crtc;
  struct intel_crtc *intel_crtc;
  +   struct intel_crtc_state *intel_crtc_state;
  struct intel_plane *intel_plane = to_intel_plane(plane);
  struct intel_plane_state *intel_state = to_intel_plane_state(state);
  +   bool active;
   
  crtc = crtc ? crtc : plane-crtc;
  intel_crtc = to_intel_crtc(crtc);
   
  +   intel_crtc_state = intel_crtc_state_for_plane(intel_state);
  +   active = intel_crtc_state-base.enable;
  +
  /*
   * Both crtc and plane-crtc could be NULL if we're updating a
   * property while the plane is disabled.  We don't actually have
  @@ -143,10 +148,8 @@ static int intel_plane_atomic_check(struct drm_plane 
  *plane,
  /* Clip all planes to CRTC size, or 0x0 if CRTC is disabled */
  intel_state-clip.x1 = 0;
  intel_state-clip.y1 = 0;
  -   intel_state-clip.x2 =
  -   intel_crtc-active ? intel_crtc-config-pipe_src_w : 0;
  -   intel_state-clip.y2 =
  -   intel_crtc-active ? intel_crtc-config-pipe_src_h : 0;
  +   intel_state-clip.x2 = active ? intel_crtc_state-pipe_src_w : 0;
  +   intel_state-clip.y2 = active ? intel_crtc_state-pipe_src_h : 0;
   
  /*
   * Disabling a plane is always okay; we just need to update
  diff --git a/drivers/gpu/drm/i915/intel_display.c 
  b/drivers/gpu/drm/i915/intel_display.c
  index 7bfe2af..88b0f69 100644
  --- a/drivers/gpu/drm/i915/intel_display.c
  +++ b/drivers/gpu/drm/i915/intel_display.c
  @@ -12562,6 +12562,53 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
  }
   }
   
  +/**
  + * intel_crtc_state_for_plane - Obtain CRTC state for a plane
  + * @pstate: plane state to lookup corresponding crtc state for
  + *
  + * When working with a top-level atomic transaction (drm_atomic_state),
  + * a CRTC state should be present that corresponds to the provided
  + * plane state; this function provides a quick way to fetch that
  + * CRTC state.  In cases where we have a plane state unassociated with any
  + * top-level atomic transaction (e.g., while using the transitional atomic
  + * helpers), the current CRTC state from crtc-state will be returned
  + * instead.
  + */
  +struct intel_crtc_state *
  +intel_crtc_state_for_plane(struct intel_plane_state *pstate)
  +{
  +   struct drm_atomic_state *state = pstate-base.state;
  +   struct intel_plane *plane = to_intel_plane(pstate-base.plane);
  +   struct drm_crtc *crtc = intel_get_crtc_for_pipe(pstate-base.plane-dev,
  +   plane-pipe);
  +   int i;
  +
  +   /*
  +* While using transitional plane helpers, we may not have a top-level
  +* atomic transaction.  Of course that also means that we're not
  +* actually touching CRTC state, so just return the currently
  +* committed state.
  +*/
 
 Imo this needs a big FIXME at the top of the comment ;-)
 
  +   if (!state)
  

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Enable existing gen9 harware workarounds for Broxton

[shuang . he]

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
Task id: 6138
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  276/276  276/276
ILK  302/302  302/302
SNB  313/313  313/313
IVB  337/337  337/337
BYT  286/286  286/286
HSW  395/395  395/395
BDW  321/321  321/321
-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 1/4] drm/i915: Make atomic use in-flight state for CRTC active value

[Matt Roper]

On Thu, Apr 09, 2015 at 05:46:30PM +0300, Ville Syrjälä wrote:
 On Thu, Apr 09, 2015 at 07:10:57AM -0700, Matt Roper wrote:
  On Thu, Apr 09, 2015 at 04:18:56PM +0300, Ville Syrjälä wrote:
   On Wed, Apr 08, 2015 at 06:56:51PM -0700, Matt Roper wrote:
Our atomic plane code currently uses intel_crtc-active to determine
how/when to update some derived state values.  This works fine for pure
plane updates at the moment since the CRTC state itself isn't changed as
part of the operation.  However as we convert more of our driver
internals over to atomic modesetting, we need to look at whether the
CRTC will be active at the *end* of the atomic transaction (which may
not match the currently committed state).

The in-flight value we want to use is generally in a crtc_state object
associated with our top-level atomic transaction.  However there are a
few cases where this isn't the case:

 * While using transitional atomic helpers (as we are at the moment),
   SetPlane() calls will operate on orphaned plane states that aren't
   part of a top-level atomic transaction.  In this case, we're not
   touching the CRTC state, so it's fine to use the already-committed
   value from crtc-state.

 * While updating properties of a disabled plane, we'll have a top-level
   atomic state, but it may not contain the CRTC state we're looking
   for.  Once again, this means we're not actually touching any CRTC
   state so it's safe to use the value from crtc-state directly.

Signed-off-by: Matt Roper matthew.d.ro...@intel.com
---
 drivers/gpu/drm/i915/intel_atomic_plane.c | 11 +++--
 drivers/gpu/drm/i915/intel_display.c  | 73 
+--
 drivers/gpu/drm/i915/intel_drv.h  |  3 ++
 drivers/gpu/drm/i915/intel_sprite.c   | 16 +--
 4 files changed, 93 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 976b891..90c4a82 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -111,12 +111,17 @@ static int intel_plane_atomic_check(struct 
drm_plane *plane,
 {
struct drm_crtc *crtc = state-crtc;
struct intel_crtc *intel_crtc;
+   struct intel_crtc_state *intel_crtc_state;
struct intel_plane *intel_plane = to_intel_plane(plane);
struct intel_plane_state *intel_state = 
to_intel_plane_state(state);
+   bool active;
 
crtc = crtc ? crtc : plane-crtc;
intel_crtc = to_intel_crtc(crtc);
 
+   intel_crtc_state = intel_crtc_state_for_plane(intel_state);
+   active = intel_crtc_state-base.enable;
+
/*
 * Both crtc and plane-crtc could be NULL if we're updating a
 * property while the plane is disabled.  We don't actually have
@@ -143,10 +148,8 @@ static int intel_plane_atomic_check(struct 
drm_plane *plane,
/* Clip all planes to CRTC size, or 0x0 if CRTC is disabled */
intel_state-clip.x1 = 0;
intel_state-clip.y1 = 0;
-   intel_state-clip.x2 =
-   intel_crtc-active ? intel_crtc-config-pipe_src_w : 0;
-   intel_state-clip.y2 =
-   intel_crtc-active ? intel_crtc-config-pipe_src_h : 0;
+   intel_state-clip.x2 = active ? intel_crtc_state-pipe_src_w : 
0;
+   intel_state-clip.y2 = active ? intel_crtc_state-pipe_src_h : 
0;
   
   We depend on the clipping to keep planes from getting enabled on a
   disabled pipe. So I think this is going to blow up.
  
  That was why I made these changes...the idea here was that we should be
  basing that clipping on what the CRTC state is going to be when the
  plane state is actually committed, not what it happens to be now.  So if
  the CRTC is going to be disabled, this should ensure that the planes are
  properly clipped to off, even if the CRTC happens to be running at the
  moment.  Conversely, if the CRTC is off at the moment, but will be on at
  the end of this transaction, we want to make sure that the planes are
  not improperly clipped to invisible, otherwise they won't show up.
 
 Well yeah, we want to change the clipping computation to use the future
 state but I don't think were ready for it yet. At least I wouldn't want
 to make this change until the watermark code gets fixed and we clean up
 the primary/cursor plane state handling.
 
 For instance what happens if you dpms off and then enable a plane? If
 the clipping is based on the enabled state of the crtc then it'll try
 to enable the plane, no?

Yeah, I think that was Daniel's concern too... -enable is the wrong
field to be pulling out of the state object here and we should be using
-active instead since that takes DPMS and such into account.

I'm not 

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix locking in DRRS flush/invalidate hooks

[Chris Wilson]

On Thu, Apr 09, 2015 at 04:44:15PM +0200, Daniel Vetter wrote:
 We must acquire the mutex before we can check drrs.dp, otherwise
 someone might sneak in with a modeset, clear the pointer after we've
 checked it and then the code will Oops.
 
 This issue has been introduced in
 
 commit a93fad0f7fb8a3ff12e8814b630648f6d187954c
 Author: Vandana Kannan vandana.kan...@intel.com
 Date:   Sat Jan 10 02:25:59 2015 +0530
 
 drm/i915: DRRS calls based on frontbuffer
 
 v2: Don't blow up on uninitialized mutex and work item by checking
 whether DRRS is support or not first. Also unconditionally initialize
 the mutex/work item to avoid future trouble.
 
 Cc: Chris Wilson ch...@chris-wilson.co.uk
 Cc: Ville Syrjälä ville.syrj...@linux.intel.com
 Cc: Ramalingam C ramalinga...@intel.com
 Cc: Rodrigo Vivi rodrigo.v...@intel.com
 Cc: Vandana Kannan vandana.kan...@intel.com
 Cc: sta...@vger.kernel.org (4.0+ only)
 Signed-off-by: Daniel Vetter daniel.vet...@intel.com

Happier,
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
Tested-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 00/13] gen8 ppgtt dynamic page allocations

[Daniel Vetter]

On Thu, Apr 09, 2015 at 10:14:49AM +0300, Mika Kuoppala wrote:
 Michel Thierry michel.thie...@intel.com writes:
 
  These are the last remining patches to enable dynamic allocation in gen8+.
  All credit to Ben's original design and Mika's extensive reviews.
 
  During stress testing, the light restore context corruption problem was
  observed in some systems (resubmission with HEAD==TAIL). The workaround to
  prevent to prevent this known problem should be in place as we also update
  the PDPx registers before the context is send to execution.
 
  The last patch is only of interest in systems with less than 4GB of memory.
  Now that the PPGTT table overhead is not that big, we can use the full 
  virtual
  space address range in these systems.
 
  Michel Thierry (13):
drm/i915: Remove _entry from PPGTT page structures
drm/i915: Remove unnecessary gen8_ppgtt_unmap_pages
drm/i915/gen8: Initialize page tables
drm/i915/gen8: Add dynamic allocation macros and helper functions
drm/i915/gen8: page directories rework allocation
drm/i915/gen8: pagetable allocation rework
drm/i915/gen8: Update pdp switch and point unused PDPs to scratch page
drm/i915: num_pd_pages/num_pd_entries isn't useful
drm/i915: Extract PPGTT param from page_directory alloc
drm/i915/gen8: Split out mappings
drm/i915/gen8: begin bitmap tracking
drm/i915/gen8: Dynamic page table allocations
drm/i915: Use complete address space in true PPGTT
 
 
 Patches 1-13,
 Reviewed-by: Mika Kuoppala mika.kuopp...@intel.com

Merged the entire patch series, thanks. A few things to take care of once
this settles a bit (i.e. after the 48b stuff is merged):
- checkpatch wasn't too happy about the line breaks and long lines and
  stuff in here. But there's already a bit of that going on, so I figured
  a checkpatch pass over i915_gem_gtt.[hc] at the end is easier.
- A lot of the comments are now outdated, there's full-blown kerneldoc
  comments for static functions (which we generally don't do, that should
  all be evident from context) and I guess the existing kerneldoc also
  needs updating.
- i915_gem_gtt.h has way too many static inline functions. gcc will do a
  better job. Imo those should all/most be moved into i915_gem_gtt.c.
- i915_gem_gtt.c has a bunch of unecessary forward declarations.

Anyway just polish.
-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 3/4] drm/i915: Switch to full atomic helpers for plane updates/disable, take two

[Daniel Vetter]

On Wed, Apr 08, 2015 at 06:56:53PM -0700, Matt Roper wrote:
 Switch from our plane update/disable entrypoints to use the full atomic
 helpers (which generate a top-level atomic transaction) rather than the
 transitional helpers (which only create/manipulate orphaned plane states
 independent of a top-level transaction).  Various upcoming work (SKL
 scalers, atomic watermarks, etc.) requires a full atomic transaction to
 behave properly/cleanly.
 
 Last time we tried this, we had to back out the change because we still
 call the drm_plane vfuncs directly from within our legacy modesetting
 code.  This potentially results in nested atomic transactions, locking
 collisions, and other failures.  To avoid that problem again, we
 sidestep the issue by calling the transitional helpers directly (rather
 than through a vfunc) when we're nested inside of other legacy
 modesetting code.  However this does allow legacy SetPlane() ioctl's to
 process an entire drm_atomic_state transaction, which is important for
 upcoming patches.
 
 Cc: Chandra Konduru chandra.kond...@intel.com
 Signed-off-by: Matt Roper matthew.d.ro...@intel.com

Maarten is working to fix this properly (by wiring up plane states to the
transitional drm_atomic_state scaffolding from Ander), but seems like a
good interim idea to get back some solid testing for our atomic code.

Can I apply this without patches 12 right away or is there a tricky
depency?
-Daniel

 ---
  drivers/gpu/drm/i915/intel_display.c | 24 
  drivers/gpu/drm/i915/intel_sprite.c  | 10 +-
  2 files changed, 17 insertions(+), 17 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 1cf91ad..3a74923 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -5576,7 +5576,7 @@ static void intel_crtc_disable(struct drm_crtc *crtc)
   dev_priv-display.crtc_disable(crtc);
   dev_priv-display.off(crtc);
  
 - crtc-primary-funcs-disable_plane(crtc-primary);
 + drm_plane_helper_disable(crtc-primary);
  
   /* Update computed state. */
   list_for_each_entry(connector, dev-mode_config.connector_list, head) {
 @@ -11731,11 +11731,11 @@ static int __intel_set_mode(struct drm_crtc *crtc,
   int vdisplay, hdisplay;
  
   drm_crtc_get_hv_timing(mode, hdisplay, vdisplay);
 - ret = primary-funcs-update_plane(primary, intel_crtc-base,
 -fb, 0, 0,
 -hdisplay, vdisplay,
 -x  16, y  16,
 -hdisplay  16, vdisplay  
 16);
 + ret = drm_plane_helper_update(primary, intel_crtc-base,
 +   fb, 0, 0,
 +   hdisplay, vdisplay,
 +   x  16, y  16,
 +   hdisplay  16, vdisplay  16);
   }
  
   /* Now enable the clocks, plane, pipe, and connectors that we set up. */
 @@ -12286,10 +12286,10 @@ static int intel_crtc_set_config(struct 
 drm_mode_set *set)
   int vdisplay, hdisplay;
  
   drm_crtc_get_hv_timing(set-mode, hdisplay, vdisplay);
 - ret = primary-funcs-update_plane(primary, set-crtc, set-fb,
 -0, 0, hdisplay, vdisplay,
 -set-x  16, set-y  16,
 -hdisplay  16, vdisplay  
 16);
 + ret = drm_plane_helper_update(primary, set-crtc, set-fb,
 +   0, 0, hdisplay, vdisplay,
 +   set-x  16, set-y  16,
 +   hdisplay  16, vdisplay  16);
  
   /*
* We need to make sure the primary plane is re-enabled if it
 @@ -12830,8 +12830,8 @@ void intel_plane_destroy(struct drm_plane *plane)
  }
  
  const struct drm_plane_funcs intel_plane_funcs = {
 - .update_plane = drm_plane_helper_update,
 - .disable_plane = drm_plane_helper_disable,
 + .update_plane = drm_atomic_helper_update_plane,
 + .disable_plane = drm_atomic_helper_disable_plane,
   .destroy = intel_plane_destroy,
   .set_property = drm_atomic_helper_plane_set_property,
   .atomic_get_property = intel_plane_atomic_get_property,
 diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
 b/drivers/gpu/drm/i915/intel_sprite.c
 index 492abcd..f4094d2 100644
 --- a/drivers/gpu/drm/i915/intel_sprite.c
 +++ b/drivers/gpu/drm/i915/intel_sprite.c
 @@ -1149,11 +1149,11 @@ int intel_plane_restore(struct drm_plane *plane)
   if (!plane-crtc || !plane-state-fb)
   return 0;
  
 - return plane-funcs-update_plane(plane, plane-crtc, plane-state-fb,
 -   

Re: [Intel-gfx] [PATCH] Correct kms_fbc_crc case

[Daniel Vetter]

On Thu, Apr 09, 2015 at 09:17:33PM +0800, liu,lei wrote:
 From: liu,lei lei.a@intel.com
 
 Debugfs i915_fbc_status shows FBC unsupported on this chipset
 not unsupported by this chipset if the platform doesn't support
 FBC feature. That typo will cause case fail on some platforms such
 as byt, bsw.
 
 Signed-off-by: Lei Liu lei.a@intel.com

Applied, thanks.
-Daniel

 ---
  tests/kms_fbc_crc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/tests/kms_fbc_crc.c b/tests/kms_fbc_crc.c
 index ccdec33..1320bad 100644
 --- a/tests/kms_fbc_crc.c
 +++ b/tests/kms_fbc_crc.c
 @@ -513,7 +513,7 @@ igt_main
   igt_assert_lt(0, fread(buf, 1, sizeof(buf), status));
   fclose(status);
   buf[sizeof(buf) - 1] = '\0';
 - igt_require_f(!strstr(buf, unsupported by this chipset) 
 + igt_require_f(!strstr(buf, unsupported on this chipset) 
 !strstr(buf, disabled per module param) 
 !strstr(buf, disabled per chip default),
 FBC not supported/enabled\n);
 -- 
 1.8.3.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 4/4] drm/i915: Clear crtc atomic flags at beginning of transaction

[Daniel Vetter]

On Wed, Apr 08, 2015 at 06:56:54PM -0700, Matt Roper wrote:
 Once we have full atomic modeset, these kind of flags should be in a
 real intel_crtc_state that's tracked properly.  In the meantime, make
 sure we clear out any old flags at the beginning of a transaction so
 that we don't wind up seeing leftover flags from old transactions that
 were checked, but never went to the commit step.
 
 A simple memset would have done here, but I expect there to be a few
 more things that we *don't* want to clear that get added into this
 structure before we're ready to kill off and roll everything into the
 CRTC state.
 
 Signed-off-by: Matt Roper matthew.d.ro...@intel.com

Not sure whether this helps a lot with moving intel_crtc-atomic into
intel_crtc_state. We probably want to just move things one-by-one to
reduce the overall churn, and then we can add them one-by-one to the intel
crtc_state_duplicate function.

Or do you have some bigger plans here?
-Daniel

 ---
  drivers/gpu/drm/i915/intel_atomic.c  | 18 ++
  drivers/gpu/drm/i915/intel_display.c |  2 +-
  drivers/gpu/drm/i915/intel_drv.h |  1 +
  3 files changed, 20 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
 b/drivers/gpu/drm/i915/intel_atomic.c
 index 3903b90..542230d 100644
 --- a/drivers/gpu/drm/i915/intel_atomic.c
 +++ b/drivers/gpu/drm/i915/intel_atomic.c
 @@ -35,6 +35,22 @@
  #include drm/drm_plane_helper.h
  #include intel_drv.h
  
 +/**
 + * intel_clear_atomic_crtc_flags
 + * @crtc: CRTC to clear flags for
 + *
 + * Until we have proper atomic handling of CRTC states, we dump some atomic
 + * task flags in intel_crtc-atomic.  Those flags need to be cleared at
 + * the beginning of each transaction so that we don't carry over stale flags
 + * from previous transactions.
 + *
 + * Note that the whole intel_crtc-atomic structure is a temporary hack and
 + * should transition into the CRTC state eventually.
 + */
 +void intel_clear_atomic_crtc_flags(struct intel_crtc *crtc)
 +{
 + memset(crtc-atomic, 0, sizeof(crtc-atomic));
 +}
  
  /**
   * intel_atomic_check - validate state object
 @@ -76,6 +92,8 @@ int intel_atomic_check(struct drm_device *dev,
   state-allow_modeset = false;
   for (i = 0; i  ncrtcs; i++) {
   struct intel_crtc *crtc = to_intel_crtc(state-crtcs[i]);
 + if (crtc)
 + intel_clear_atomic_crtc_flags(crtc);
   if (crtc  crtc-pipe != nuclear_pipe)
   not_nuclear = true;
   }
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 3a74923..bb8d345 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -12812,7 +12812,7 @@ static void intel_finish_crtc_commit(struct drm_crtc 
 *crtc)
   intel_update_sprite_watermarks(p, crtc, 0, 0, 0,
  false, false);
  
 - memset(intel_crtc-atomic, 0, sizeof(intel_crtc-atomic));
 + intel_clear_atomic_crtc_flags(intel_crtc);
  }
  
  /**
 diff --git a/drivers/gpu/drm/i915/intel_drv.h 
 b/drivers/gpu/drm/i915/intel_drv.h
 index d5ea24f..28d838e 100644
 --- a/drivers/gpu/drm/i915/intel_drv.h
 +++ b/drivers/gpu/drm/i915/intel_drv.h
 @@ -1303,6 +1303,7 @@ void intel_pre_disable_primary(struct drm_crtc *crtc);
  void intel_tv_init(struct drm_device *dev);
  
  /* intel_atomic.c */
 +void intel_clear_atomic_crtc_flags(struct intel_crtc *crtc);
  int intel_atomic_check(struct drm_device *dev,
  struct drm_atomic_state *state);
  int intel_atomic_commit(struct drm_device *dev,
 -- 
 1.8.5.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 1/7] drm/i915: PSR: Remove wrong LINK_DISABLE.

[Matthew Garrett]

I've put this patchset on top of current Linus git. Switching to fbcon 
tends to result in rolling graphics, and turning the screen back on 
often gives me a static display or one that only updates every few 
seconds. This is with a Dell XPS 13 with Broadwell-U and a 3200x1800 
display.

-- 
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Fix locking in DRRS flush/invalidate hooks

[Daniel Vetter]

We must acquire the mutex before we can check drrs.dp, otherwise
someone might sneak in with a modeset, clear the pointer after we've
checked it and then the code will Oops.

This issue has been introduced in

commit a93fad0f7fb8a3ff12e8814b630648f6d187954c
Author: Vandana Kannan vandana.kan...@intel.com
Date:   Sat Jan 10 02:25:59 2015 +0530

drm/i915: DRRS calls based on frontbuffer

Cc: Ramalingam C ramalinga...@intel.com
Cc: Rodrigo Vivi rodrigo.v...@intel.com
Cc: Vandana Kannan vandana.kan...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 1b87969536ff..e265a0dee479 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5170,7 +5170,6 @@ static void intel_edp_drrs_downclock_work(struct 
work_struct *work)
downclock_mode-vrefresh);
 
 unlock:
-
mutex_unlock(dev_priv-drrs.mutex);
 }
 
@@ -5192,12 +5191,14 @@ void intel_edp_drrs_invalidate(struct drm_device *dev,
struct drm_crtc *crtc;
enum pipe pipe;
 
-   if (!dev_priv-drrs.dp)
-   return;
-
cancel_delayed_work_sync(dev_priv-drrs.work);
 
mutex_lock(dev_priv-drrs.mutex);
+   if (!dev_priv-drrs.dp) {
+   mutex_unlock(dev_priv-drrs.mutex);
+   return;
+   }
+
crtc = dp_to_dig_port(dev_priv-drrs.dp)-base.base.crtc;
pipe = to_intel_crtc(crtc)-pipe;
 
@@ -5231,12 +5232,14 @@ void intel_edp_drrs_flush(struct drm_device *dev,
struct drm_crtc *crtc;
enum pipe pipe;
 
-   if (!dev_priv-drrs.dp)
-   return;
-
cancel_delayed_work_sync(dev_priv-drrs.work);
 
mutex_lock(dev_priv-drrs.mutex);
+   if (!dev_priv-drrs.dp) {
+   mutex_unlock(dev_priv-drrs.mutex);
+   return;
+   }
+
crtc = dp_to_dig_port(dev_priv-drrs.dp)-base.base.crtc;
pipe = to_intel_crtc(crtc)-pipe;
dev_priv-drrs.busy_frontbuffer_bits = ~frontbuffer_bits;
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Update the EDID automated compliance test function

[Todd Previte]

On 4/8/2015 10:02 AM, Paulo Zanoni wrote:

2015-03-31 14:15 GMT-03:00 Todd Previte tprev...@gmail.com:

Updates the EDID compliance test function to perform the EDID read as
required by the tests. This read needs to take place in the kernel for
reasons of speed and efficiency. The results of the EDID read operations
are handed off to userspace so that the userspace app can set the display
mode appropriately for the test response.

The compliance_test_active flag now appears at the end of the individual
test handling functions. This is so that the kernel-side operations can
be completed without the risk of interruption from the userspace app
that is polling on that flag.

V2:
- Addressed mailing list feedback
- Removed excess debug messages
- Removed extraneous comments
- Fixed formatting issues (line length  80)
- Updated the debug message in compute_edid_checksum to output hex values
   instead of decimal
V3:
- Addressed more list feedback
- Added the test_active flag to the autotest function
- Removed test_active flag from handler
- Added failsafe check on the compliance test active flag
   at the end of the test handler
- Fixed checkpatch.pl issues
V4:
- Removed the checksum computation function and its use as it has been
   rendered superfluous by changes to the core DRM EDID functions
- Updated to use the raw header corruption detection mechanism
- Moved the declaration of the test_data variable here

Signed-off-by: Todd Previte tprev...@gmail.com
---
  drivers/gpu/drm/i915/intel_dp.c  | 53 
  drivers/gpu/drm/i915/intel_drv.h |  3 ++-
  2 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 57f8e43..16d35903 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -41,6 +41,16 @@

  #define DP_LINK_CHECK_TIMEOUT  (10 * 1000)

+/* Compliance test status bits  */
+#define INTEL_DP_EDID_SHIFT_MASK   0
+#define INTEL_DP_EDID_OK   (0  INTEL_DP_EDID_SHIFT_MASK)
+#define INTEL_DP_EDID_CORRUPT  (1  INTEL_DP_EDID_SHIFT_MASK)
+
+#define INTEL_DP_RESOLUTION_SHIFT_MASK 4
+#define INTEL_DP_RESOLUTION_PREFERRED  (1  INTEL_DP_RESOLUTION_SHIFT_MASK)
+#define INTEL_DP_RESOLUTION_STANDARD   (2  INTEL_DP_RESOLUTION_SHIFT_MASK)
+#define INTEL_DP_RESOLUTION_FAILSAFE   (3  INTEL_DP_RESOLUTION_SHIFT_MASK)
+
  struct dp_link_dpll {
 int link_bw;
 struct dpll dpll;
@@ -3766,7 +3776,44 @@ static uint8_t intel_dp_autotest_video_pattern(struct 
intel_dp *intel_dp)

  static uint8_t intel_dp_autotest_edid(struct intel_dp *intel_dp)
  {
+   struct drm_connector *connector = intel_dp-attached_connector-base;
+   struct i2c_adapter *adapter = intel_dp-aux.ddc;
+   struct edid *edid_read = NULL;
 uint8_t test_result = DP_TEST_NAK;
+   uint32_t ret = 0;

Variable ret is set but not used.


Well it was used but the value wasn't really checked. The next version 
of this patch checks the value and reports status based on that.





+
+   edid_read = drm_get_edid(connector, adapter);

This is the additional edid read mentioned in the review of the previous patch.


This one has been removed for the next patch revision.




+
+   if (drm_raw_edid_header_corrupt() == 1) {
+   DRM_DEBUG_DRIVER(EDID Header corrupted\n);
+   intel_dp-compliance_edid_invalid = 1;
+   }
+
+   if (edid_read == NULL || intel_dp-compliance_edid_invalid ||
+   intel_dp-aux.i2c_defer_count  6) {
+   /* Check for NACKs/DEFERs, use failsafe if detected
+  (DP CTS 1.2 Core Rev 1.1, 4.2.2.4, 4.2.2.5) */

Missing '*' char on the comment.

Fixed.




+   if (intel_dp-aux.i2c_nack_count  0 ||
+   intel_dp-aux.i2c_defer_count  0)

Since we're potentially reading edid more than once after the test
starts - as explained in the review of p4 -, do those nack/defer
counts make sense? Shouldn't we zero them before each edid read
attempt?


That's a good point. That had potential to adversely affect the test 
results for the NACKs and DEFERs. Removing the extra EDID read should 
eliminate that problem though, so I think the next version should be ok.





+   DRM_DEBUG_KMS(EDID read had %d NACKs, %d DEFERs\n,
+ intel_dp-aux.i2c_nack_count,
+ intel_dp-aux.i2c_defer_count);
+   intel_dp-compliance_test_data = DP_TEST_LINK_EDID_READ |
+INTEL_DP_EDID_CORRUPT  |
+INTEL_DP_RESOLUTION_FAILSAFE;

The compliance_test_data variable certainly needs a very good
documentation on what its bits means - possibly on top of its
definition, which is on patch 1 right now. Maybe it should be split
into more than one variable, since the bits that go inside it come
from different places. 

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Make atomic use in-flight state for CRTC active value

[Daniel Vetter]

On Wed, Apr 08, 2015 at 06:56:51PM -0700, Matt Roper wrote:
 Our atomic plane code currently uses intel_crtc-active to determine
 how/when to update some derived state values.  This works fine for pure
 plane updates at the moment since the CRTC state itself isn't changed as
 part of the operation.  However as we convert more of our driver
 internals over to atomic modesetting, we need to look at whether the
 CRTC will be active at the *end* of the atomic transaction (which may
 not match the currently committed state).
 
 The in-flight value we want to use is generally in a crtc_state object
 associated with our top-level atomic transaction.  However there are a
 few cases where this isn't the case:
 
  * While using transitional atomic helpers (as we are at the moment),
SetPlane() calls will operate on orphaned plane states that aren't
part of a top-level atomic transaction.  In this case, we're not
touching the CRTC state, so it's fine to use the already-committed
value from crtc-state.
 
  * While updating properties of a disabled plane, we'll have a top-level
atomic state, but it may not contain the CRTC state we're looking
for.  Once again, this means we're not actually touching any CRTC
state so it's safe to use the value from crtc-state directly.
 
 Signed-off-by: Matt Roper matthew.d.ro...@intel.com
 ---
  drivers/gpu/drm/i915/intel_atomic_plane.c | 11 +++--
  drivers/gpu/drm/i915/intel_display.c  | 73 
 +--
  drivers/gpu/drm/i915/intel_drv.h  |  3 ++
  drivers/gpu/drm/i915/intel_sprite.c   | 16 +--
  4 files changed, 93 insertions(+), 10 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
 b/drivers/gpu/drm/i915/intel_atomic_plane.c
 index 976b891..90c4a82 100644
 --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
 +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
 @@ -111,12 +111,17 @@ static int intel_plane_atomic_check(struct drm_plane 
 *plane,
  {
   struct drm_crtc *crtc = state-crtc;
   struct intel_crtc *intel_crtc;
 + struct intel_crtc_state *intel_crtc_state;
   struct intel_plane *intel_plane = to_intel_plane(plane);
   struct intel_plane_state *intel_state = to_intel_plane_state(state);
 + bool active;
  
   crtc = crtc ? crtc : plane-crtc;
   intel_crtc = to_intel_crtc(crtc);
  
 + intel_crtc_state = intel_crtc_state_for_plane(intel_state);
 + active = intel_crtc_state-base.enable;
 +
   /*
* Both crtc and plane-crtc could be NULL if we're updating a
* property while the plane is disabled.  We don't actually have
 @@ -143,10 +148,8 @@ static int intel_plane_atomic_check(struct drm_plane 
 *plane,
   /* Clip all planes to CRTC size, or 0x0 if CRTC is disabled */
   intel_state-clip.x1 = 0;
   intel_state-clip.y1 = 0;
 - intel_state-clip.x2 =
 - intel_crtc-active ? intel_crtc-config-pipe_src_w : 0;
 - intel_state-clip.y2 =
 - intel_crtc-active ? intel_crtc-config-pipe_src_h : 0;
 + intel_state-clip.x2 = active ? intel_crtc_state-pipe_src_w : 0;
 + intel_state-clip.y2 = active ? intel_crtc_state-pipe_src_h : 0;
  
   /*
* Disabling a plane is always okay; we just need to update
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 7bfe2af..88b0f69 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -12562,6 +12562,53 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
   }
  }
  
 +/**
 + * intel_crtc_state_for_plane - Obtain CRTC state for a plane
 + * @pstate: plane state to lookup corresponding crtc state for
 + *
 + * When working with a top-level atomic transaction (drm_atomic_state),
 + * a CRTC state should be present that corresponds to the provided
 + * plane state; this function provides a quick way to fetch that
 + * CRTC state.  In cases where we have a plane state unassociated with any
 + * top-level atomic transaction (e.g., while using the transitional atomic
 + * helpers), the current CRTC state from crtc-state will be returned
 + * instead.
 + */
 +struct intel_crtc_state *
 +intel_crtc_state_for_plane(struct intel_plane_state *pstate)
 +{
 + struct drm_atomic_state *state = pstate-base.state;
 + struct intel_plane *plane = to_intel_plane(pstate-base.plane);
 + struct drm_crtc *crtc = intel_get_crtc_for_pipe(pstate-base.plane-dev,
 + plane-pipe);
 + int i;
 +
 + /*
 +  * While using transitional plane helpers, we may not have a top-level
 +  * atomic transaction.  Of course that also means that we're not
 +  * actually touching CRTC state, so just return the currently
 +  * committed state.
 +  */

Imo this needs a big FIXME at the top of the comment ;-)

 + if (!state)
 + return to_intel_crtc_state(crtc-state);
 +
 + for (i = 0; i  

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Lookup CRTC for plane directly

[Daniel Vetter]

On Wed, Apr 08, 2015 at 06:56:52PM -0700, Matt Roper wrote:
 Various places in the atomic plane code obtain the CRTC via
 plane_state-crtc.  But plane_state-crtc is NULL when disabling the
 plane, so the code will fall back to looking at the old CRTC value in
 plane-crtc in that case.  This isn't going to work when we start
 supporting non-blocking flips (since the legacy plane-crtc pointer will
 already be updated to its new value before the asynchronous workqueue
 task runs the plane commit function).  The code is also fragile in
 general (we have to be careful when doing stuff like updating properties
 on a disabled plane).  Since Intel hardware has a fixed plane to pipe
 mapping, let's just lookup the CRTC via that fixed mapping and avoid
 future mistakes.
 
 Cc: Vivek Kasireddy vivek.kasire...@intel.com
 Reported-by: Vivek Kasireddy vivek.kasire...@intel.com
 Signed-off-by: Matt Roper matthew.d.ro...@intel.com

Because I'm a lazy reviewer ... does cocci agree that you've spotted all
the drm_plane-crtc references?
-Daniel

 ---
  drivers/gpu/drm/i915/intel_atomic_plane.c | 12 ++--
  drivers/gpu/drm/i915/intel_display.c  |  8 
  drivers/gpu/drm/i915/intel_drv.h  |  7 +++
  drivers/gpu/drm/i915/intel_sprite.c   |  4 ++--
  4 files changed, 19 insertions(+), 12 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
 b/drivers/gpu/drm/i915/intel_atomic_plane.c
 index 90c4a82..740d1a6 100644
 --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
 +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
 @@ -116,19 +116,19 @@ static int intel_plane_atomic_check(struct drm_plane 
 *plane,
   struct intel_plane_state *intel_state = to_intel_plane_state(state);
   bool active;
  
 - crtc = crtc ? crtc : plane-crtc;
 + crtc = intel_get_crtc_for_drm_plane(plane);
   intel_crtc = to_intel_crtc(crtc);
  
   intel_crtc_state = intel_crtc_state_for_plane(intel_state);
   active = intel_crtc_state-base.enable;
  
   /*
 -  * Both crtc and plane-crtc could be NULL if we're updating a
 -  * property while the plane is disabled.  We don't actually have
 -  * anything driver-specific we need to test in that case, so
 -  * just return success.
 +  * Both state-crtc and plane-state-crtc could be NULL if we're
 +  * updating a property while the plane is disabled.  We don't actually
 +  * have anything driver-specific we need to test in that case, so just
 +  * return success.
*/
 - if (!crtc)
 + if (!state-crtc  !plane-state-crtc)
   return 0;
  
   /*
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 88b0f69..1cf91ad 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -12625,7 +12625,7 @@ intel_check_primary_plane(struct drm_plane *plane,
   bool active;
   int ret;
  
 - crtc = crtc ? crtc : plane-crtc;
 + crtc = intel_get_crtc_for_drm_plane(plane);
   intel_crtc = to_intel_crtc(crtc);
  
   intel_crtc_state = intel_crtc_state_for_plane(state);
 @@ -12694,7 +12694,7 @@ intel_commit_primary_plane(struct drm_plane *plane,
   struct drm_rect *src = state-src;
   bool active;
  
 - crtc = crtc ? crtc : plane-crtc;
 + crtc = intel_get_crtc_for_drm_plane(plane);
   intel_crtc = to_intel_crtc(crtc);
  
   intel_crtc_state = intel_crtc_state_for_plane(state);
 @@ -12916,7 +12916,7 @@ intel_check_cursor_plane(struct drm_plane *plane,
   bool active;
   int ret;
  
 - crtc = crtc ? crtc : plane-crtc;
 + crtc = intel_get_crtc_for_drm_plane(plane);
   intel_crtc = to_intel_crtc(crtc);
  
   intel_crtc_state = intel_crtc_state_for_plane(state);
 @@ -12977,7 +12977,7 @@ intel_commit_cursor_plane(struct drm_plane *plane,
   uint32_t addr;
   bool active;
  
 - crtc = crtc ? crtc : plane-crtc;
 + crtc = intel_get_crtc_for_drm_plane(plane);
   intel_crtc = to_intel_crtc(crtc);
  
   intel_crtc_state = intel_crtc_state_for_plane(state);
 diff --git a/drivers/gpu/drm/i915/intel_drv.h 
 b/drivers/gpu/drm/i915/intel_drv.h
 index 71e0152..d5ea24f 100644
 --- a/drivers/gpu/drm/i915/intel_drv.h
 +++ b/drivers/gpu/drm/i915/intel_drv.h
 @@ -731,6 +731,13 @@ intel_get_crtc_for_plane(struct drm_device *dev, int 
 plane)
   return dev_priv-plane_to_crtc_mapping[plane];
  }
  
 +static inline struct drm_crtc *
 +intel_get_crtc_for_drm_plane(struct drm_plane *plane)
 +{
 + struct drm_i915_private *dev_priv = to_i915(plane-dev);
 + return dev_priv-pipe_to_crtc_mapping[to_intel_plane(plane)-pipe];
 +}
 +
  struct intel_unpin_work {
   struct work_struct work;
   struct drm_crtc *crtc;
 diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
 b/drivers/gpu/drm/i915/intel_sprite.c
 index 2016e78..492abcd 100644
 --- a/drivers/gpu/drm/i915/intel_sprite.c
 +++ b/drivers/gpu/drm/i915/intel_sprite.c
 @@ -878,7 +878,7 @@ 

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Clear crtc atomic flags at beginning of transaction

[Matt Roper]

On Thu, Apr 09, 2015 at 02:48:43PM +0200, Daniel Vetter wrote:
 On Wed, Apr 08, 2015 at 06:56:54PM -0700, Matt Roper wrote:
  Once we have full atomic modeset, these kind of flags should be in a
  real intel_crtc_state that's tracked properly.  In the meantime, make
  sure we clear out any old flags at the beginning of a transaction so
  that we don't wind up seeing leftover flags from old transactions that
  were checked, but never went to the commit step.
  
  A simple memset would have done here, but I expect there to be a few
  more things that we *don't* want to clear that get added into this
  structure before we're ready to kill off and roll everything into the
  CRTC state.
  
  Signed-off-by: Matt Roper matthew.d.ro...@intel.com
 
 Not sure whether this helps a lot with moving intel_crtc-atomic into
 intel_crtc_state. We probably want to just move things one-by-one to
 reduce the overall churn, and then we can add them one-by-one to the intel
 crtc_state_duplicate function.
 
 Or do you have some bigger plans here?
 -Daniel

My in-progress WM work had to stick some other things in
intel_crtc-atomic, but maybe with Ander's latest patch sets we're close
enough that I can rewrite those to use crtc_state instead; I'll have to
go back and check.

Regardless, I think we do still have a bug today where an uncommitted
transaction (e.g., because check or prepare fail) will leave stale flags
in intel_crtc-atomic that the next transaction doesn't realize it needs
to clear.  We either need to clear those out (as I'm doing here,
although a simple memset would work too), or we need to transition all
those flags over to CRTC state and kill off the hacky intel_crtc-atomic
structure.


Matt

 
  ---
   drivers/gpu/drm/i915/intel_atomic.c  | 18 ++
   drivers/gpu/drm/i915/intel_display.c |  2 +-
   drivers/gpu/drm/i915/intel_drv.h |  1 +
   3 files changed, 20 insertions(+), 1 deletion(-)
  
  diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
  b/drivers/gpu/drm/i915/intel_atomic.c
  index 3903b90..542230d 100644
  --- a/drivers/gpu/drm/i915/intel_atomic.c
  +++ b/drivers/gpu/drm/i915/intel_atomic.c
  @@ -35,6 +35,22 @@
   #include drm/drm_plane_helper.h
   #include intel_drv.h
   
  +/**
  + * intel_clear_atomic_crtc_flags
  + * @crtc: CRTC to clear flags for
  + *
  + * Until we have proper atomic handling of CRTC states, we dump some atomic
  + * task flags in intel_crtc-atomic.  Those flags need to be cleared at
  + * the beginning of each transaction so that we don't carry over stale 
  flags
  + * from previous transactions.
  + *
  + * Note that the whole intel_crtc-atomic structure is a temporary hack and
  + * should transition into the CRTC state eventually.
  + */
  +void intel_clear_atomic_crtc_flags(struct intel_crtc *crtc)
  +{
  +   memset(crtc-atomic, 0, sizeof(crtc-atomic));
  +}
   
   /**
* intel_atomic_check - validate state object
  @@ -76,6 +92,8 @@ int intel_atomic_check(struct drm_device *dev,
  state-allow_modeset = false;
  for (i = 0; i  ncrtcs; i++) {
  struct intel_crtc *crtc = to_intel_crtc(state-crtcs[i]);
  +   if (crtc)
  +   intel_clear_atomic_crtc_flags(crtc);
  if (crtc  crtc-pipe != nuclear_pipe)
  not_nuclear = true;
  }
  diff --git a/drivers/gpu/drm/i915/intel_display.c 
  b/drivers/gpu/drm/i915/intel_display.c
  index 3a74923..bb8d345 100644
  --- a/drivers/gpu/drm/i915/intel_display.c
  +++ b/drivers/gpu/drm/i915/intel_display.c
  @@ -12812,7 +12812,7 @@ static void intel_finish_crtc_commit(struct 
  drm_crtc *crtc)
  intel_update_sprite_watermarks(p, crtc, 0, 0, 0,
 false, false);
   
  -   memset(intel_crtc-atomic, 0, sizeof(intel_crtc-atomic));
  +   intel_clear_atomic_crtc_flags(intel_crtc);
   }
   
   /**
  diff --git a/drivers/gpu/drm/i915/intel_drv.h 
  b/drivers/gpu/drm/i915/intel_drv.h
  index d5ea24f..28d838e 100644
  --- a/drivers/gpu/drm/i915/intel_drv.h
  +++ b/drivers/gpu/drm/i915/intel_drv.h
  @@ -1303,6 +1303,7 @@ void intel_pre_disable_primary(struct drm_crtc *crtc);
   void intel_tv_init(struct drm_device *dev);
   
   /* intel_atomic.c */
  +void intel_clear_atomic_crtc_flags(struct intel_crtc *crtc);
   int intel_atomic_check(struct drm_device *dev,
 struct drm_atomic_state *state);
   int intel_atomic_commit(struct drm_device *dev,
  -- 
  1.8.5.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

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

[Intel-gfx] [PATCH v2] drm/i915/chv: Remove DPIO force latency causing interpair skew issue

[clinton . a . taylor]

From: Clint Taylor clinton.a.tay...@intel.com

Latest version of the CHV DPIO programming notes no longer requires writes
to TX DW 11 to fix a +2UI interpair skew issue. The current code from
April 2014 was actually causing additional skew issues between all
TMDS pairs.

ver2: added same treatment to intel_dp.c based on Ville's testing.

Cc: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= ville.syrj...@linux.intel.com
Signed-off-by: Clint Taylor clinton.a.tay...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c   |5 -
 drivers/gpu/drm/i915/intel_hdmi.c |5 -
 2 files changed, 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 1b87969..f106763 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2740,11 +2740,6 @@ static void chv_pre_enable_dp(struct intel_encoder 
*encoder)
 
/* Program Tx lane latency optimal setting*/
for (i = 0; i  4; i++) {
-   /* Set the latency optimal bit */
-   data = (i == 1) ? 0x0 : 0x6;
-   vlv_dpio_write(dev_priv, pipe, CHV_TX_DW11(ch, i),
-   data  DPIO_FRC_LATENCY_SHFIT);
-
/* Set the upar bit */
data = (i == 1) ? 0x0 : 0x1;
vlv_dpio_write(dev_priv, pipe, CHV_TX_DW14(ch, i),
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 26222e6..3cef326 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1515,11 +1515,6 @@ static void chv_hdmi_pre_enable(struct intel_encoder 
*encoder)
 
/* Program Tx latency optimal setting */
for (i = 0; i  4; i++) {
-   /* Set the latency optimal bit */
-   data = (i == 1) ? 0x0 : 0x6;
-   vlv_dpio_write(dev_priv, pipe, CHV_TX_DW11(ch, i),
-   data  DPIO_FRC_LATENCY_SHFIT);
-
/* Set the upar bit */
data = (i == 1) ? 0x0 : 0x1;
vlv_dpio_write(dev_priv, pipe, CHV_TX_DW14(ch, i),
-- 
1.7.9.5

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

Re: [Intel-gfx] [PATCH] tests: Fix duplicate 'kms_flip_event_leak' entry in tests/Makefile.sources

[Daniel Vetter]

On Thu, Apr 09, 2015 at 01:04:28AM +, He, Shuang wrote:
  -Original Message-
  From: He, Shuang
  Sent: Wednesday, April 8, 2015 4:16 PM
  To: Daniel Vetter
  Cc: intel-gfx@lists.freedesktop.org
  Subject: RE: [Intel-gfx] [PATCH] tests: Fix duplicate 'kms_flip_event_leak'
  entry in tests/Makefile.sources
  
   -Original Message-
   From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
   Vetter
   Sent: Wednesday, April 8, 2015 4:15 PM
   To: He, Shuang
   Cc: intel-gfx@lists.freedesktop.org
   Subject: Re: [Intel-gfx] [PATCH] tests: Fix duplicate 
   'kms_flip_event_leak'
   entry in tests/Makefile.sources
  
   On Tue, Apr 19, 2011 at 04:16:06AM +0800, Shuang He wrote:
Or, it will cause piglit failure to run I-G-T test case
   
Signed-off-by: Shuang He shuang...@intel.com
  
   How does it fail? And please fix the time on your machine, date on the
   mail is 2011 ;-)
  [He, Shuang]  Piglit is now checking duplicate case name. and duplicate
  'kms_flip_event_leak' in I-G-T will directly lead piglit abort testing from 
  start.
  Following are output of it:
  ./piglit-run.py -d tests/igt.py t
  Error: A test has already been asigned the name: igt@kms_flip_event_leak
  and both tests are the same.
 [He, Shuang] Could anyone follow up this one? It's blocking our testing, 
 though we could kind of work around it.

Sorry I forgot to push out the patch, done now.
-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 2/2] drm/i915: Don't cancel DRRS worker synchronously for flush/invalidate

[Chris Wilson]

On Thu, Apr 09, 2015 at 04:44:16PM +0200, Daniel Vetter wrote:
 It's not needed since the worker rechecks that it didn't race. We only
 need to cancel synchronously after disabling drrs to make sure the
 worker really is gone (e.g. for driver unload). But for normal
 operation the stall is just wasted time.
 
 Reported-by: Chris Wilson ch...@chris-wilson.co.uk
 Cc: Chris Wilson ch...@chris-wilson.co.uk
 Cc: Ville Syrjälä ville.syrj...@linux.intel.com
 Cc: Ramalingam C ramalinga...@intel.com
 Cc: Rodrigo Vivi rodrigo.v...@intel.com
 Cc: Vandana Kannan vandana.kan...@intel.com
 Signed-off-by: Daniel Vetter daniel.vet...@intel.com

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] drm/i915/chv: Remove DPIO force latency causing interpair skew issue

[Clint Taylor]

On 04/09/2015 01:20 PM, Ville Syrjälä wrote:

On Thu, Apr 09, 2015 at 10:17:05AM -0700, clinton.a.tay...@intel.com wrote:

From: Clint Taylor clinton.a.tay...@intel.com

Latest version of the CHV DPIO programming notes no longer requires writes
to TX DW 11 to fix a +2UI interpair skew issue. The current code from
April 2014 was actually causing additional skew issues between all
TMDS pairs.

Signed-off-by: Clint Taylor clinton.a.tay...@intel.com
---
  drivers/gpu/drm/i915/intel_hdmi.c |5 -
  1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 26222e6..3cef326 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1515,11 +1515,6 @@ static void chv_hdmi_pre_enable(struct intel_encoder 
*encoder)

/* Program Tx latency optimal setting */
for (i = 0; i  4; i++) {
-   /* Set the latency optimal bit */
-   data = (i == 1) ? 0x0 : 0x6;
-   vlv_dpio_write(dev_priv, pipe, CHV_TX_DW11(ch, i),
-   data  DPIO_FRC_LATENCY_SHFIT);
-


On a huch I went and tried this same treatment on intel_dp.c and it
fixes the remaining link training issues [1] I've been seeing \o/
I still need to try with the other DP display that was having these
problems, but that'll have to wait until tomorrow.

So please respin this with the same change made to intel_dp.c (someone
should really eliminate the code duplication we have going on there), and
assuming my test with the other display goes as well I can then post
some DPIO lane power gating patches which I've been holding back because
they made the problem worse.



v2 respin has been sent. You saved me lots of time testing the same 
change on DP. I will probably still put it on a scope to confirm the 
improvement.


I didn't take on the hint of fixing the code duplication.

-Clint


[1] http://lists.freedesktop.org/archives/intel-gfx/2015-February/059877.html



/* Set the upar bit */
data = (i == 1) ? 0x0 : 0x1;
vlv_dpio_write(dev_priv, pipe, CHV_TX_DW14(ch, i),
--
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 27/70] drm/i915: Remove vestigal DRI1 ring quiescing code

[Daniel Vetter]

On Tue, Apr 07, 2015 at 04:20:51PM +0100, Chris Wilson wrote:
 @@ -640,7 +641,7 @@ static int logical_ring_wait_request(struct 
 intel_ringbuffer *ringbuf,
   break;
   }
  
 - if (request-list == ring-request_list)
 + if (WARN_ON(request-list == ring-request_list))
   return -ENOSPC;

Checking for new_space  n (and initializing new_space to 0) would be a
clearer check imo. But that's just a bikeshed. Same for the legacy one
below.
-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 2/4] drm/i915/bxt: Determine BXT slice/subslice/EU info

[Daniel Vetter]

On Thu, Apr 09, 2015 at 04:26:19PM +0300, Imre Deak wrote:
 On Fri, 2015-04-03 at 18:13 -0700, jeff.mc...@intel.com wrote:
  From: Jeff McGee jeff.mc...@intel.com
  
  Modify the Gen9 SSEU info initialization logic to support
  Broxton. Broxton reuses the SKL fuse registers but has at most
  1 slice and 6 EU per subslice.
  
  Signed-off-by: Jeff McGee jeff.mc...@intel.com
  ---
   drivers/gpu/drm/i915/i915_dma.c | 47 
  ++---
   drivers/gpu/drm/i915/i915_reg.h |  4 +---
   2 files changed, 31 insertions(+), 20 deletions(-)
  
  diff --git a/drivers/gpu/drm/i915/i915_dma.c 
  b/drivers/gpu/drm/i915/i915_dma.c
  index 9691f0f..a9b7770 100644
  --- a/drivers/gpu/drm/i915/i915_dma.c
  +++ b/drivers/gpu/drm/i915/i915_dma.c
  @@ -611,9 +611,21 @@ static void gen9_sseu_info_init(struct drm_device *dev)
   {
  struct drm_i915_private *dev_priv = dev-dev_private;
  struct intel_device_info *info;
  -   const int s_max = 3, ss_max = 4, eu_max = 8;
  +   int s_max = 3, ss_max = 4, eu_max = 8;
  int s, ss;
  -   u32 fuse2, eu_disable[s_max], s_enable, ss_disable;
  +   u32 fuse2, s_enable, ss_disable, eu_disable;
  +   u8 eu_mask = 0xff;
  +
  +   /*
  +* BXT has a single slice. BXT also has at most 6 EU per subslice,
  +* and therefore only the lowest 6 bits of the 8-bit EU disable
  +* fields are valid.
  +   */
  +   if (IS_BROXTON(dev)) {
  +   s_max = 1;
  +   eu_max = 6;
  +   eu_mask = 0x3f;
  +   }
   
  info = (struct intel_device_info *)dev_priv-info;
  fuse2 = I915_READ(GEN8_FUSE2);
  @@ -622,10 +634,6 @@ static void gen9_sseu_info_init(struct drm_device *dev)
  ss_disable = (fuse2  GEN9_F2_SS_DIS_MASK) 
   GEN9_F2_SS_DIS_SHIFT;
   
  -   eu_disable[0] = I915_READ(GEN8_EU_DISABLE0);
  -   eu_disable[1] = I915_READ(GEN8_EU_DISABLE1);
  -   eu_disable[2] = I915_READ(GEN8_EU_DISABLE2);
  -
  info-slice_total = hweight32(s_enable);
  /*
   * The subslice disable field is global, i.e. it applies
  @@ -644,25 +652,26 @@ static void gen9_sseu_info_init(struct drm_device 
  *dev)
  /* skip disabled slice */
  continue;
   
  +   eu_disable = I915_READ(GEN9_EU_DISABLE(s));
  for (ss = 0; ss  ss_max; ss++) {
  -   u32 n_disabled;
  +   int eu_per_ss;
   
  if (ss_disable  (0x1  ss))
  /* skip disabled subslice */
  continue;
   
  -   n_disabled = hweight8(eu_disable[s] 
  - (ss * eu_max));
  +   eu_per_ss = eu_max - hweight8((eu_disable  (ss*8)) 
  + eu_mask);
   
  /*
   * Record which subslice(s) has(have) 7 EUs. we
   * can tune the hash used to spread work among
   * subslices if they are unbalanced.
   */
  -   if (eu_max - n_disabled == 7)
  +   if (eu_per_ss == 7)
  info-subslice_7eu[s] |= 1  ss;
   
  -   info-eu_total += eu_max - n_disabled;
  +   info-eu_total += eu_per_ss;
  }
  }
   
  @@ -670,7 +679,8 @@ static void gen9_sseu_info_init(struct drm_device *dev)
   * SKL is expected to always have a uniform distribution
   * of EU across subslices with the exception that any one
   * EU in any one subslice may be fused off for die
  -* recovery.
  +* recovery. BXT is expected to be perfectly uniform in EU
  +* distribution.
 
 Nitpick: I would have added here an assertion for BXT about the above.
 The patchset looks otherwise ok to me, so on 1-4:
 Reviewed-by: Imre Deak imre.d...@intel.com

Applied to topic/bxt-stage1, thanks.
-Daniel

 
  */
  info-eu_per_subslice = info-subslice_total ?
  DIV_ROUND_UP(info-eu_total,
  @@ -678,11 +688,14 @@ static void gen9_sseu_info_init(struct drm_device 
  *dev)
  /*
   * SKL supports slice power gating on devices with more than
   * one slice, and supports EU power gating on devices with
  -* more than one EU pair per subslice.
  +* more than one EU pair per subslice. BXT supports subslice
  +* power gating on devices with more than one subslice, and
  +* supports EU power gating on devices with more than one EU
  +* pair per subslice.
  */
  -   info-has_slice_pg = (info-slice_total  1) ? 1 : 0;
  -   info-has_subslice_pg = 0;
  -   info-has_eu_pg = (info-eu_per_subslice  2) ? 1 : 0;
  +   info-has_slice_pg = (IS_SKYLAKE(dev)  (info-slice_total  1));
  +   info-has_subslice_pg = (IS_BROXTON(dev)  (info-subslice_total  1));
  +   info-has_eu_pg = (info-eu_per_subslice  2);
   }
   
   /*
  @@ -747,7 +760,7 @@ static void intel_device_info_runtime_init(struct 
  

Re: [Intel-gfx] VLV: eDP: panel timings / resolution data from VBT, not via i2c from eDP EDID

[Jani Nikula]

On Thu, 09 Apr 2015, Lampersperger Andreas 
lampersperger.andr...@heidenhain.de wrote:
 Hello Gajanan,

 I'm trying to run linux on a 
 valleyview hardware, which was made by my company. 

 On this hardware, the display panel is connected via 
 eDP, but the panel timings / resolution is not available 
 in the EDID of the eDP. It is only available via VBT. 

We seem to try to use the modes from EDID if available. Does the panel
not respond to EDID requests, or does it have incorrect EDID
information?

We only fallback to trying the mode from VBT if no modes can be found
from EDID.

 You added once eDP support to VLV, can you 
 give me some information on the following questions:

 Is there a way to force the i915.ko to get the 
 panel timing / resolution for the eDP from the 
 VBT and not via i2c from the eDP?

 Can you give me some advice, how to add this 
 option to the source files of i915.ko?

 I'm using 3.14.29, but I have also tried 4.0.0-rc7.

See intel_edp_init_connector() in drivers/gpu/drm/i915/intel_dp.c, look
at how fixed_mode is set.

Maybe you can change that to prefer VBT.

An alternative would be to get EDID using the firmware loading
interface, but also for that you'd have to call drm_load_edid_firmware()
in intel_edp_init_connector() instead of drm_get_edid().

BR,
Jani.


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