On Fri, Mar 13, 2015 at 01:32:38PM +, John Harrison wrote:
On 10/03/2015 10:18, Daniel Vetter wrote:
On Mon, Mar 09, 2015 at 11:51:26PM +, Tomas Elf wrote:
On 19/02/2015 17:18, john.c.harri...@intel.com wrote:
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
On Fri, Mar 13, 2015 at 04:30:43PM +0200, Ville Syrjälä wrote:
On Thu, Mar 12, 2015 at 10:01:33PM +0530, Shobhit Kumar wrote:
CC: Samuel Ortiz sa...@linux.intel.com
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Alexandre Courbot gnu...@gmail.com
Cc: Thierry Reding
On Fri, Mar 13, 2015 at 05:04:40PM +, Thomas Wood wrote:
Add an optional dependency on libunwind to print stack traces when a
test assertion fails.
Signed-off-by: Thomas Wood thomas.w...@intel.com
Awesome. Also ack from me (too lazy to dig out manpages on friday evening
for proper
On Fri, Mar 13, 2015 at 02:15:46PM +, Thomas Wood wrote:
All tests now respond in a consistent way such that separate lists for
tests with and without subtests are no longer necessary.
Signed-off-by: Thomas Wood thomas.w...@intel.com
Ack on both this and the piglit one. I think we should
On Fri, Mar 13, 2015 at 04:58:47PM +, Chris Wilson wrote:
On Fri, Mar 13, 2015 at 10:27:38AM +0100, Daniel Vetter wrote:
If supporting systems without full ppgtt is a requirement for you (still
wonky on gen8 a bit, so might be a good strategy) then imo it's the
PIN_BIAS idea I've laid
Because of hash collisions tests should only ever compare crc
checksums for equality. Checking for inequality can result in random
failures.
To ensure this only expose and igt_assert function and use that.
Follow-up patches will rework the code for tests which don't follow
this requirement and
Hi all,
New -testing cycle with cool stuff:
- EU count report param for gen9+ (Jeff McGee)
- piles of pll/wm/... fixes for chv, finally out of preliminary hw support
(Ville, Vijay)
- gen9 rps support from Akash
- more work to move towards atomic from Matt, Ander and others
- runtime pm support
Regressed by this commit:
commit 3455454e18ca3f92c565700539e744c620d8276b
Author: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
Date: Tue Mar 3 15:21:56 2015 +0200
drm/i915: Add a for_each_intel_connector macro
Cc: Ander Conselvan de Oliveira
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5948
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5947
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
This will allow manual tests when crc isn't available.
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
tests/kms_psr_sink_crc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
index ba6fb1d..0a56705 100644
---
this will allow manual tests when crc isn't available.
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
tests/kms_psr_sink_crc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
index dbc09e4..b7873b4 100644
---
No functional changes. This reorg will allow to do some
operations like dpms off/on with different places to wait
for psr to get active.
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
tests/kms_psr_sink_crc.c | 138 ++-
1 file changed, 76
Sink CRC is the most reliable way to test PSR. However in some platforms
apparently auto generated packages force panel to keep calculating CRC
invalidating
our current sink crc check over debugfs.
So, this manual test help us to find possible gaps on this platforms where we
cannot
trust on
No functional changes. Just making timeout unique for any case.
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
tests/kms_psr_sink_crc.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
index ce50cdd..733083a
On 3/12/2015 8:10 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
No point in using uint32_t here, just plain old int will do.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 24
On 3/12/2015 8:10 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
The source rates don't change, so we can just point the caller at the
const arrays.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c |
This will allow manual tests when crc isn't available.
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
tests/kms_psr_sink_crc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
index 0a56705..5085fb3 100644
---
On 3/12/2015 8:10 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
No point in converting from hardware format every single time, just
store the rates in the final format under intel_dp.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5946
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
On 2015-03-09 14:02, Chris Wilson wrote:
On Mon, Mar 09, 2015 at 02:34:46AM +, Zou, Nanhai wrote:
We don't need MAP_FIXED, we just want to avoid address 0 to be allocated.
Though I think using MAP_FIXED is overkill, will bring much unnecessary
complexity on both kernel and beignet side.
I
For the atomic conversion, the mode set paths need to be changed to rely
on an atomic state instead of using the staged config. By using an
atomic state for the legacy code, we will be able to convert the code
base in small chunks.
v2: Squash patch that adds state argument to intel_set_mode().
Here's v2 with most of the comments from Daniel addressed. I didn't change
the zeroing of the crtc_state to the duplicate state function, since it
causes problems when we add the state of a crtc that isn't going through
a modeset. Specifically, this would cause the code that decides whether
pipes
With this in place, we can start converting pieces of the modeset code
to look at the connector atomic state instead of the staged config.
v2: Handle the load detect staged config changes too. (Ander)
Remove unnecessary blank line. (Daniel)
Signed-off-by: Ander Conselvan de Oliveira
So that we can add connector states to the drm_atomic_state used in the
legacy modeset.
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/intel_crt.c| 1 +
drivers/gpu/drm/i915/intel_dp.c | 1 +
drivers/gpu/drm/i915/intel_dp_mst.c
On Thu, Mar 12, 2015 at 05:26:25PM -0700, jeff.mc...@intel.com wrote:
From: Jeff McGee jeff.mc...@intel.com
New test core_getparams consists of 2 subtests, each one testing
the ability of userspace to query the correct value of a GT config
attribute: subslice total or EU total. drm/i915
On Fri, Mar 13, 2015 at 11:10:56AM +0200, David Weinehall wrote:
On 2015-03-09 14:02, Chris Wilson wrote:
On Mon, Mar 09, 2015 at 02:34:46AM +, Zou, Nanhai wrote:
We don't need MAP_FIXED, we just want to avoid address 0 to be allocated.
Though I think using MAP_FIXED is overkill, will
On Thu, Mar 12, 2015 at 12:03:51PM -0700, Jesse Barnes wrote:
On 03/12/2015 11:36 AM, Jani Nikula wrote:
On Thu, 12 Mar 2015, Jesse Barnes jbar...@virtuousgeek.org wrote:
On 02/11/2015 09:43 AM, Damien Lespiau wrote:
v2: Use the recently introduced INTEL_REVID() and SKL_REVID defines
The pattern of getting the crtc state with drm_atomic_get_crtc_state()
and then converting it to intel_crtc_state will repeat quite often in
the following patches, so add a helper function to save some typing.
v2: Fix upcasting so that crtc_state base field could be moved. (Daniel)
Signed-off-by:
Move towards atomic by using the legacy modeset's drm_atomic_state
instead.
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git
The function intel_dp_set_drrs_state() would decide which pipe to
downclock based on the staged config for the given connector. However,
the result of that function is immediate, and it uses input values from
crtc-config, so it should be looking at the current crtc instead.
Signed-off-by: Ander
Move towards atomic by using the legacy modeset's drm_atomic_state
instead.
v2: Move call to drm_atomic_add_affected_connectors() to
intel_modeset_compute_config(). (Daniel)
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
Follow up patches will convert some functions called from there to use
the atomic state, instead of directly accessing the new or current
config. This patch just changes the parameters, but shouldn't have any
functional changes.
Signed-off-by: Ander Conselvan de Oliveira
Move towards atomic by using the legacy modeset's drm_atomic_state
instead.
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/intel_lvds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Move towards atomic by using the legacy modeset's drm_atomic_state
instead.
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
Move towards atomic by using the legacy modeset's drm_atomic_state
instead.
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/intel_dp_mst.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git
Move towards atomic by using the legacy modeset's drm_atomic_state
instead.
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/intel_hdmi.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git
Keep that state updated so that we can write code that depends on it on
the follow up patches.
v2: Fix BUG() due to stale connector_state-crtc value. (Chandra)
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 41
Pass a crtc_state to it and find whether the pipe has an encoder of a
given type by looking at the drm_atomic_state the crtc_state points to.
Until recently i9xx_get_refclk() used to be called indirectly from
vlv_force_pll_on() with a dummy crtc_state. That dummy crtc state is not
converted to be
For now this is not necessary since intel_set_mode() doesn't acquire any
new locks. However, once that function is converted to atomic, that will
change, since we'll pass an atomic state to it, and that needs to have
the right acquire context set.
Signed-off-by: Ander Conselvan de Oliveira
Some of the crtc_compute_clock() still depended on encoder-new_crtc
since they didn't use intel_pipe_will_have_type() and used an open
coded version of that function instead. This patch replaces those with
the appropriate code that checks the atomic state intead.
Signed-off-by: Ander Conselvan de
Instead of using connector-new_encoder, get the same information from
the pipe_config, thus making the function ready for the atomic
conversion.
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 24 +++-
1
For consistency, allocate a new crtc_state for a crtc that is being
disabled. Previously only the enabled value of the current state would
change.
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 36
Makes that code atomic ready.
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 49 ++--
1 file changed, 42 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
On Fri, Mar 13, 2015 at 11:10:56AM +0200, David Weinehall wrote:
On 2015-03-09 14:02, Chris Wilson wrote:
On Mon, Mar 09, 2015 at 02:34:46AM +, Zou, Nanhai wrote:
We don't need MAP_FIXED, we just want to avoid address 0 to be allocated.
Though I think using MAP_FIXED is overkill, will
On Thu, Mar 12, 2015 at 05:32:26PM +, Tvrtko Ursulin wrote:
On 03/12/2015 04:50 PM, Chris Wilson wrote:
On Thu, Mar 12, 2015 at 04:41:10PM +, Tvrtko Ursulin wrote:
Yes I didn't mean that - but to have a boolean spinning-wait=on/off.
Maybe default to on on HZ=1000 with preemption, or
This statement is indented an extra space.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 959058f..028c6d4 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3905,13
My only concern is about the following macros:
+#define LOCAL_I915_PARAM_SUBSLICE_TOTAL 33
+#define LOCAL_I915_PARAM_EU_TOTAL34
How about to just use the definitons in the kernel header file?
For an example:
#include drm/i915_drm.h
#ifdef LOCAL_I915_PARAM_SUBSLICE_TOTAL
//Put
On Thursday 12 March 2015 08:40 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
intel_dp_compute_config() only really needs to know the rates supported
by both source and sink, so hide the raw source and sink arrays from it.
Signed-off-by: Ville
On Thu, Mar 12, 2015 at 10:01:27PM +0530, Shobhit Kumar wrote:
The CRC (Crystal Cove) PMIC, controls the panel enable and disable
signals for BYT for dsi panels. This is indicated in the VBT fields. Use
that to initialize and use GPIO based control for these signals.
v2: Use the newer gpiod
On Thu, Mar 12, 2015 at 10:01:33PM +0530, Shobhit Kumar wrote:
CC: Samuel Ortiz sa...@linux.intel.com
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Alexandre Courbot gnu...@gmail.com
Cc: Thierry Reding thierry.red...@gmail.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
On Fri, Mar 13, 2015 at 05:14:59PM +0530, sonika wrote:
On Thursday 12 March 2015 08:40 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
intel_dp_compute_config() only really needs to know the rates supported
by both source and sink, so hide the
vmap_batch() calculates amount of needed pages for the mapping
we are going to create. And it uses this page count as an
argument for the for_each_sg_pages() macro. The macro takes the number
of sg list entities as an argument, not the page count. So we ended
up iterating through all the pages on
On Friday 13 March 2015 05:32 PM, Ville Syrjälä wrote:
On Fri, Mar 13, 2015 at 05:14:59PM +0530, sonika wrote:
On Thursday 12 March 2015 08:40 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
intel_dp_compute_config() only really needs to know the
On Thu, 12 Mar 2015, Matt Roper matthew.d.ro...@intel.com wrote:
On Thu, Mar 12, 2015 at 02:45:31PM +0200, Jani Nikula wrote:
Matt, please review or suggest an alternative for v4.0-rc.
Thanks,
Jani.
Yep, this looks good to me. So
Reviewed-by: Matt Roper matthew.d.ro...@intel.com
On 10/03/2015 10:18, Daniel Vetter wrote:
On Mon, Mar 09, 2015 at 11:51:26PM +, Tomas Elf wrote:
On 19/02/2015 17:18, john.c.harri...@intel.com wrote:
From: John Harrison john.c.harri...@intel.com
The outstanding_lazy_request is no longer used anywhere in the driver.
Everything that was
Some chips instead of using period_ns and duty_ns can be configured
using the clock divisor and duty percent. Adds an alternative
configuration method for such chips
v2: Corrected the chip validation for config_alternate in pwmchip_add
CC: Samuel Ortiz sa...@linux.intel.com
Cc: Linus Walleij
On 03/13/2015 01:21 PM, Mika Kuoppala wrote:
vmap_batch() calculates amount of needed pages for the mapping
we are going to create. And it uses this page count as an
argument for the for_each_sg_pages() macro. The macro takes the number
of sg list entities as an argument, not the page count. So
On Fri, Mar 13, 2015 at 03:21:53PM +0200, Mika Kuoppala wrote:
vmap_batch() calculates amount of needed pages for the mapping
we are going to create. And it uses this page count as an
argument for the for_each_sg_pages() macro. The macro takes the number
of sg list entities as an argument, not
On 13/03/2015 12:46, John Harrison wrote:
On 05/03/2015 17:57, Tomas Elf wrote:
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison john.c.harri...@intel.com
The final step in removing the OLR from i915_gem_init_hw() is to pass
the newly
allocated request structure in to
All tests now respond in a consistent way such that separate lists for
tests with and without subtests are no longer necessary.
Signed-off-by: Thomas Wood thomas.w...@intel.com
---
tests/Makefile.am | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git
From: Ville Syrjälä ville.syrj...@linux.intel.com
When we get an i2c defer or short ack for i2c-over-aux write we need
to switch to WRITE_STATUS_UPDATE to poll for the completion of the
original request.
Looks like radeon doesn't do anything special with the request type,
so hopefully just
From: Ville Syrjälä ville.syrj...@linux.intel.com
Rename the I2C_STATUS request to I2C_WRITE_STATUS_UPDATE to match the
spec.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/tegra/dpaux.c | 2 +-
include/drm/drm_dp_helper.h | 2 +-
2 files changed, 2
From: Ville Syrjälä ville.syrj...@linux.intel.com
This series tries to implement support for short i2c-over-aux writes.
I did notice that my monitor (HP ZR24w) does support DDC/CI so I was
able to do some writes, but I only saw native defers instead of i2c
defers/short acks. So I've not actually
From: Ville Syrjälä ville.syrj...@linux.intel.com
A address-only I2C_WRITE can't be replied with a short i2c ack, but I
suppose it could be replied with an i2c defer. So the code should be
prepared for an address-only I2C_WRITE_STATUS_UPDATE.
Cc: Thierry Reding thierry.red...@gmail.com
Cc: Terje
On Fri, Mar 13, 2015 at 05:09:46PM +0800, Zhigang Gong wrote:
My only concern is about the following macros:
+#define LOCAL_I915_PARAM_SUBSLICE_TOTAL 33
+#define LOCAL_I915_PARAM_EU_TOTAL34
How about to just use the definitons in the kernel header file?
For an example:
On Fri, Mar 13, 2015 at 09:51:57AM -0700, Jeff McGee wrote:
On Fri, Mar 13, 2015 at 05:32:41PM +0100, Daniel Vetter wrote:
On Fri, Mar 13, 2015 at 05:09:46PM +0800, Zhigang Gong wrote:
My only concern is about the following macros:
+#define LOCAL_I915_PARAM_SUBSLICE_TOTAL 33
On Fri, Mar 13, 2015 at 10:27:38AM +0100, Daniel Vetter wrote:
If supporting systems without full ppgtt is a requirement for you (still
wonky on gen8 a bit, so might be a good strategy) then imo it's the
PIN_BIAS idea I've laid out earlier in this thread. That one will work
everywhere. softpin
On Mon, Mar 09, 2015 at 08:10:06AM +0800, Zhigang Gong wrote:
-Original Message-
From: Beignet [mailto:beignet-boun...@lists.freedesktop.org] On Behalf Of
Jeff McGee
Sent: Saturday, March 7, 2015 2:44 AM
To: Zhigang Gong
Cc: dan...@ffwll.ch; intel-gfx@lists.freedesktop.org;
Add an optional dependency on libunwind to print stack traces when a
test assertion fails.
Signed-off-by: Thomas Wood thomas.w...@intel.com
---
benchmarks/Makefile.am | 4 ++--
configure.ac | 10 ++
debugger/Makefile.am | 3 ++-
demos/Makefile.am | 4 ++--
On Fri, Mar 13, 2015 at 05:59:13PM +0100, Daniel Vetter wrote:
On Fri, Mar 13, 2015 at 09:51:57AM -0700, Jeff McGee wrote:
On Fri, Mar 13, 2015 at 05:32:41PM +0100, Daniel Vetter wrote:
On Fri, Mar 13, 2015 at 05:09:46PM +0800, Zhigang Gong wrote:
My only concern is about the following
71 matches
Mail list logo
