On Tue, Oct 07, 2014 at 04:18:38PM -0300, Paulo Zanoni wrote:
2014-10-07 12:15 GMT-03:00 Mika Kuoppala mika.kuopp...@linux.intel.com:
commit b680c37a4d145cf4d8f2b24e46b1163e5ceb1d35
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Fri Sep 19 18:27:27 2014 +0200
drm/i915: DocBook
On Wed, Oct 08, 2014 at 06:32:21PM +0300, Ander Conselvan de Oliveira wrote:
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
This shouldn't change the behavior of those functions, since they are
called after the new_config is made effective and that points to the
On Wed, Oct 08, 2014 at 06:32:23PM +0300, Ander Conselvan de Oliveira wrote:
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
It is possible for a mode set to fail if there aren't shared DPLLS that
match the new configuration requirement or other errors in clock
On Thu, 09 Oct 2014, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Oct 08, 2014 at 06:32:23PM +0300, Ander Conselvan de Oliveira wrote:
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
It is possible for a mode set to fail if there aren't shared DPLLS that
match the new
On Wed, Oct 08, 2014 at 06:32:21PM +0300, Ander Conselvan de Oliveira wrote:
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
This shouldn't change the behavior of those functions, since they are
called after the new_config is made effective and that points to the
On Wed, Oct 08, 2014 at 07:32:12AM -0700, Jesse Barnes wrote:
On Wed, 8 Oct 2014 07:43:34 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Tue, Oct 07, 2014 at 01:25:23PM -0700, Jesse Barnes wrote:
Gets the detect code (which may take awhile) out of the resume path,
speeding
On 7 October 2014 17:41, Adam Sampson a...@offog.org wrote:
POSIX only requires = to be supported; += works in bash but not in
dash.
Signed-off-by: Adam Sampson a...@offog.org
Both patches merged, thanks.
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Thank you for the reply!
Does your Arch use systemd?
Is your *buntu not using systemd?
Yes to both.
I am aware of the on-demand feature and did what you proposed (had
already done the same for half of the terminals).
After testing I noticed something more specific.
Suppose the following
On Thu, 9 Oct 2014 11:11:32 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Wed, Oct 08, 2014 at 07:32:12AM -0700, Jesse Barnes wrote:
On Wed, 8 Oct 2014 07:43:34 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Tue, Oct 07, 2014 at 01:25:23PM -0700, Jesse Barnes wrote:
constantine composed on 2014-10-09 13:35 (UTC):
Does your Arch use systemd?
Is your *buntu not using systemd?
Yes to both.
I am aware of the on-demand feature and did what you proposed (had
already done the same for half of the terminals).
After testing I noticed something more specific.
Gets the detect code (which may take awhile) out of the resume path,
speeding things up a bit.
v2: use a delayed work queue instead (Daniel)
v3: cancel delayed work at unload and suspend time (Jesse)
v4: make delayed work comment less scary (Chris)
Signed-off-by: Jesse Barnes
These counters are used for Displayort complinace testing to detect error
conditions
when executing certain compliance tests. Currently these are used in the EDID
tests
to determine if the video mode needs to be set to the preferred mode or the
failsafe
mode.
Cc:
Adds an interface that allows for Displayport configuration information to be
accessed
through debugfs. The information paramters provided here are as follows:
Link rate
Lane count
Bits per pixel
Voltage swing level
Preemphasis level
Display mode
These parameters are intended
Move the DPCD read to the top and check for an interrupt from the sink to catch
Displayport automated testing requests necessary to support Displayport
compliance
testing. The checks for active connectors and link status are moved below the
check for the interrupt.
Adds a check at the top to
The kernel side is responsible for the acknowledgement of the test requests and
setup of the required parameters. It also handles the necessary AUX
transactions
for reading the EDID and DPCD as well as writing response codes or checksums as
necessary. Performing these operations in userspace
Adds the capability for the driver to signal a userspace application for
Displayport
compliance testing. The userspace app must write its PID to the appropriate
debugfs file,
at which time the kernel will read and store that PID internally. PIDs are
specified on a
per-connector basis.
Add the skeleton framework for supporting automation for Displayport compliance
testing. This patch adds the necessary framework for the source device to
appropriately
respond to test automation requests from a sink device.
Signed-off-by: Todd Previte tprev...@gmail.com
---
Adds provisions in intel_dp_compute_config() to accommodate compliance testing.
Mostly
this invovles circumventing the automatic link configuration paramters and
allowing
the compliance code to set those parameters as required by the tests.
Signed-off-by: Todd Previte tprev...@gmail.com
---
The hot plug function for DP appears to have been broken somewhere along the
way. Without
this function being operational, hot plug events are not correctly received for
compliance
testing. This patch implements the necessary functionality to resolve that
issue.
Signed-off-by: Todd Previte
Adds a struct to hold link configuration parameters and several other
variables for use during Displayport compliance testing. Adding these
items here allows for efficient handling of compliance test data and
configuration parameters where necessary in the driver.
Also updates the debugfs
On Tue, Oct 07, 2014 at 08:39:38PM +0530, Vandana Kannan wrote:
Since panel power sequencing is a feature common to all internal displays,
moving relevant code to intel_panel.c. This patch series contains changes
to setup PPS data and program register values as required.
The implementation
On Thu, Oct 09, 2014 at 08:38:10AM -0700, Todd Previte wrote:
The hot plug function for DP appears to have been broken somewhere along the
way. Without
this function being operational, hot plug events are not correctly received
for compliance
testing. This patch implements the necessary
Since commit 5782eca (lib/igt_core.c: disable lowmemorykiller during
tests), igt_exit needs to be called before the test exits.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84771
Cc: Tim Gore tim.g...@intel.com
Signed-off-by: Thomas Wood thomas.w...@intel.com
---
Signed-off-by: Thomas Wood thomas.w...@intel.com
---
tests/kms_force_connector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/kms_force_connector.c b/tests/kms_force_connector.c
index 96881c7..361bf84 100644
--- a/tests/kms_force_connector.c
+++
On Thu, Oct 09, 2014 at 04:50:53PM +0100, Thomas Wood wrote:
Signed-off-by: Thomas Wood thomas.w...@intel.com
---
tests/kms_force_connector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/kms_force_connector.c b/tests/kms_force_connector.c
index 96881c7..361bf84
-Original Message-
From: Thomas Wood [mailto:thomas.w...@intel.com]
Sent: Thursday, October 09, 2014 4:51 PM
To: intel-gfx@lists.freedesktop.org
Cc: Gore, Tim
Subject: [PATCH i-g-t 1/2] tests/kms_force_connector: ensure igt_exit is
called at exit
Since commit 5782eca
On 9 October 2014 17:00, Gore, Tim tim.g...@intel.com wrote:
-Original Message-
From: Thomas Wood [mailto:thomas.w...@intel.com]
Sent: Thursday, October 09, 2014 4:51 PM
To: intel-gfx@lists.freedesktop.org
Cc: Gore, Tim
Subject: [PATCH i-g-t 1/2] tests/kms_force_connector: ensure
Reorder the function calls in chv/vlv_pre_enable_dp() such that link training
is not initiated
before the PHYs come up out of reset. Also check the status of
vlv_wait_port_ready() and
only attempt to train if the PHYs are actually running.
The specification lists the wait for the PHYs as one of
From: Ville Syrjälä ville.syrj...@linux.intel.com
On CHV the display DDC pins may be muxed to an alternate function if
there's no need for DDC on a specific port, which is the case for eDP
ports since there's no way to plug in a DP++ HDMI dongle.
This causes problems when trying to determine if
Link training for Displayport can fail in many ways and at multiple different
points
during the training process. Previously, errors were logged but no additional
action
was taken based on them. Consequently, training attempts could continue even
after
errors have occured that would prevent
Previously we didn't have a clear understanding what is necessary
for a pipeline state to be properly initialized. So we had to improvise
and use a stripped out render copy.
Now we have a more clear understanding so switch out render copy based
frankenstate to state we can call golden state.
v2:
to files where they were missing.
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
tools/null_state_gen/intel_null_state_gen.c | 27 +++
tools/null_state_gen/intel_renderstate_gen6.c | 26 ++
tools/null_state_gen/intel_renderstate_gen7.c
From: Armin Reese armin.c.re...@intel.com
Modifications to 'null_state_gen' so it can generate GEN9
golden context batch buffer source for SKL.
v2: - rebased on top of gen8 changes (Mika)
- fixed state base address command size (Mika)
- base address size macro as pages (Mika)
v3: -
Be more verbose about the state size we generate.
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
tools/null_state_gen/intel_null_state_gen.c | 36 ++---
1 file changed, 28 insertions(+), 8 deletions(-)
diff --git a/tools/null_state_gen/intel_null_state_gen.c
In null/golden context there are multiple state commands where
the actual state is always zero. For more compact batch representation
add a macro which just emits command and the rest of the state as zero.
v2: - Be more verbose about length bias (Bradley Volkin)
- strip out unrelated
Currently our kernel side buffer object is only one page.
Limit the amount of dwords to 1024 to enforce this.
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
tools/null_state_gen/intel_batchbuffer.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Paulo Zanoni paulo.r.zan...@intel.com
As far as I understand, intel_uncore_early_sanitize() was supposed to
be ran before any register access, but currently
intel_resume_prepare() is ran earlier, and it does register
access. I don't think it should be safe to be calling
I915_{READ,WRITE}
Some machines (like MBAs) might use a tiled framebuffer but not enable
display swizzling at boot time. We want to preserve that configuration
if possible to prevent a boot time mode set. On IVB+ it shouldn't
affect performance anyway since the memory controller does internal
swizzling anyway.
From: Kristian Høgsberg hoegsb...@gmail.com
Like mode_equal but w/o the clock checks. Useful for checking if modes
are close enough to re-use to avoid a boot time mode set for example.
Signed-off-by: Kristian Høgsberg hoegsb...@gmail.com
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
From: Kristian Høgsberg hoegsb...@gmail.com
The BIOS may set a native mode that doesn't quite match the preferred
mode timings. It should be ok to use however if it uses the same size,
so try to avoid a mode set in that case.
Signed-off-by: Kristian Høgsberg hoegsb...@gmail.com
Signed-off-by:
Let's clean this a bit
v2: Rebase after other Mika's patch that removed some BDW production
workarounds.
v3: Removed stepping info.
Reviewed-by: Mika Kuoppala mika.kuopp...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 10 --
On 10 October 2014 01:49, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Thu, Oct 09, 2014 at 08:38:10AM -0700, Todd Previte wrote:
The hot plug function for DP appears to have been broken somewhere along the
way. Without
this function being operational, hot plug events are not correctly
42 matches
Mail list logo
