On 10 October 2014 01:49, Chris Wilson 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 received
>> for comp
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
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_pm.c | 10 --
drivers/gpu/drm/i915/intel_ringbuffer.c | 5
From: Kristian Høgsberg
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
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/
From: Kristian Høgsberg
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
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_modes.c | 8
include/drm/drm_mode
Some machines may have a broken VBT or no VBT at all, but we still want
to use SSC there. So check for it and keep it enabled if we see it
already on. Based on an earlier fix from Kristian.
v2: honor modparam if set too (Daniel)
read out at init time and store for panel_use_ssc() use (Jesse)
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.
Fo
From: Paulo Zanoni
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} without calling intel_uncor
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
---
tools/null_state_gen/intel_batchbuffer.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/null_state_gen/intel_batchbuffer.h
b/
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 state_off
to files where they were missing.
Signed-off-by: Mika Kuoppala
---
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 | 9 +
tools/nu
From: Armin Reese
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: - rebased on top of current ma
Be more verbose about the state size we generate.
Signed-off-by: Mika Kuoppala
---
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
b/tools/null_state_gen/in
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:
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 succ
From: Ville Syrjälä
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 the port is present
since the
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
On 9 October 2014 17:00, Gore, Tim 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 igt_exit i
> -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 (lib
On Thu, Oct 09, 2014 at 04:50:53PM +0100, Thomas Wood wrote:
> Signed-off-by: Thomas Wood
> ---
> 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
Signed-off-by: Thomas Wood
---
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
+++ b/tests/kms_force_connector.c
@@ -54,7 +54,7
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
Signed-off-by: Thomas Wood
---
tests/kms_force_connector.c | 2 +-
1 file changed, 1 insertio
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
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 implementatio
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
---
drivers/gpu/drm/i915/
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
---
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 are handed
off to userspace so that the remainder of the test can be conducted there.
Signed-of
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 interfac
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
---
drivers/gpu/drm/i915/intel_dp.c | 82 ++
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.
Signed-of
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 wo
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 to
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: dri-de...@lists.freedesktop.org
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 veri
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
---
drivers/gpu/dr
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
On Thu, 9 Oct 2014 11:11:32 +0100
Chris Wilson 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 wrote:
> >
> > > On Tue, Oct 07, 2014 at 01:25:23PM -0700, Jesse Barnes wrote:
> > > > Gets the detect code (which may tak
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 tt
On 7 October 2014 17:41, Adam Sampson wrote:
> POSIX only requires "=" to be supported; "+=" works in bash but not in
> dash.
>
> Signed-off-by: Adam Sampson
Both patches merged, thanks.
> ---
> configure.ac | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure.ac
On Wed, Oct 08, 2014 at 07:32:12AM -0700, Jesse Barnes wrote:
> On Wed, 8 Oct 2014 07:43:34 +0100
> Chris Wilson 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 things up a bit.
>
On Wed, Oct 08, 2014 at 06:32:21PM +0300, Ander Conselvan de Oliveira wrote:
> From: Ander Conselvan de Oliveira
>
> 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
> current config. In a follow up patch,
On Thu, 09 Oct 2014, Daniel Vetter wrote:
> On Wed, Oct 08, 2014 at 06:32:23PM +0300, Ander Conselvan de Oliveira wrote:
>> From: Ander Conselvan de Oliveira
>>
>> 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
On Wed, Oct 08, 2014 at 06:32:23PM +0300, Ander Conselvan de Oliveira wrote:
> From: Ander Conselvan de Oliveira
>
> 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
> computation. Since that step was execute
On Wed, Oct 08, 2014 at 06:32:21PM +0300, Ander Conselvan de Oliveira wrote:
> From: Ander Conselvan de Oliveira
>
> 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
> current config. In a follow up patch,
On Tue, Oct 07, 2014 at 04:18:38PM -0300, Paulo Zanoni wrote:
> 2014-10-07 12:15 GMT-03:00 Mika Kuoppala :
> > commit b680c37a4d145cf4d8f2b24e46b1163e5ceb1d35
> > Author: Daniel Vetter
> > Date: Fri Sep 19 18:27:27 2014 +0200
> >
> > drm/i915: DocBook integration for frontbuffer tracking
> >
44 matches
Mail list logo
