On Thu, 11 Feb 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> intel_digital_port_connected() lacks one 'else'. There's no
> actual harm in not having it since each branch has an unconditional
> return, so it can't accidentally end up in taking two branches instead
> of just t
On Thu, Feb 11, 2016 at 09:00:47AM -0800, Rodrigo Vivi wrote:
> Framecounter register is read-only so DMC cannot restore it
> after exiting DC5 and DC6.
>
> Easiest way to go is to avoid the counter and use vblank
> interruptions for this platform and for all the following
> ones since DMC came to
This patch set adds scheduler tests.
Patch 1 adds library code used by the tests. There are other tests under
development which are planned to reuse some of these libraries.
Patch 2 adds some basic tests, read dependency tests and write dependency tests.
Patch 3 Is the patch previously submitted by
This is intended to test the scheduler behaviour is correct.
The subtests are
-basic
Tests that batch buffers of the same priority submitted to a ring
execute in the order they are submitted.
-read
Submits a batch buffer with a read dependency to a buffer object to
a ring which is held in the sched
Adds functions to create a number of different batch buffers to perform
several functions including:
Batch buffer which will run for a long duration to provide a delay on a
specified ring.
Function to calibrate the delay batch buffer to run for a specified period
of time.
Function to create a batch
From: John Harrison
The GPU scheduler has added an execution priority level to the context
object. There is an IOCTL interface to allow user apps/libraries to
set this priority. This patch updates the context paramter IOCTL test
to include the new interface.
For: VIZ-1587
Signed-off-by: John Har
Add subtests to test each ring to check batch buffers of a higher
priority will be executed before batch buffers of a lower priority.
Signed-off-by: Derek Morton
---
tests/gem_scheduler.c | 34 --
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/test
On 11/02/16 21:00, Chris Wilson wrote:
> On Thu, Feb 11, 2016 at 06:03:09PM +, Tvrtko Ursulin wrote:
>> From: Tvrtko Ursulin
>>
>> Only caller to get_context_status ensures read pointer stays in
>> range so the WARN is impossible. Also, if the WARN would be
>> triggered by a hypothetical new
On Fri, Feb 12, 2016 at 10:05:58AM +, Tvrtko Ursulin wrote:
>
> On 11/02/16 21:00, Chris Wilson wrote:
> > On Thu, Feb 11, 2016 at 06:03:09PM +, Tvrtko Ursulin wrote:
> >> From: Tvrtko Ursulin
> >>
> >> Only caller to get_context_status ensures read pointer stays in
> >> range so the WARN
From: Mayuresh Gharpure
Co-Author : Marius Vlad
Co-Author : Pratik Vishwakarma
So far we have had only two commit styles, COMMIT_LEGACY
and COMMIT_UNIVERSAL. This patch adds another commit style
COMMIT_ATOMIC which makes use of drmModeAtomicCommit()
v2: (Marius)
i)Set CRTC_ID to zero
Please fix the typo in the subject.
BR,
Jani.
On Fri, 12 Feb 2016, Pratik Vishwakarma wrote:
> From: Mayuresh Gharpure
>
> Co-Author : Marius Vlad
> Co-Author : Pratik Vishwakarma
>
> So far we have had only two commit styles, COMMIT_LEGACY
> and COMMIT_UNIVERSAL. This patch adds another com
On Thu, Feb 11, 2016 at 03:22:08PM -0800, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> Track VCO frequency of SKL instead of the boot CDCLK and allow modeset
> to set cdclk based on the max required pixel clock based on VCO
> selected.
>
> The vco should be tracked at the atomic le
On Thu, Feb 11, 2016 at 05:11:52PM -0800, Marc Herbert wrote:
> [I'm cheating and doing this code review with the author watching over my
> shoulder]
>
> On 11/02/16 15:22, clinton.a.tay...@intel.com wrote:
> > From: Clint Taylor
> >
> > Track VCO frequency of SKL instead of the boot CDCLK and
On 12/02/16 10:21, Chris Wilson wrote:
On Fri, Feb 12, 2016 at 10:05:58AM +, Tvrtko Ursulin wrote:
On 11/02/16 21:00, Chris Wilson wrote:
On Thu, Feb 11, 2016 at 06:03:09PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Only caller to get_context_status ensures read pointer stays in
On Thu, Jan 21, 2016 at 03:10:18PM -0800, Rafael Antognolli wrote:
> The module_init and module_exit functions will start here, and call the
> subsequent init's and exit's.
>
> v10:
> - Keep __init on drm_fb_helper init function.
> - Move MODULE_* macros to the common file.
>
> Signed-off-by: R
On Thu, Jan 21, 2016 at 03:10:19PM -0800, Rafael Antognolli wrote:
> This module is heavily based on i2c-dev. Once loaded, it provides one
> dev node per DP AUX channel, named drm_dp_auxN, where N is an integer.
>
> It's possible to know which connector owns this aux channel by looking
> at the re
From: Tvrtko Ursulin
Assorted changes most likely without any practical effect
apart from a tiny reduction in generated code for the interrupt
handler and request submission.
* Remove needless initialization.
* Improve cache locality by reorganizing code and/or using
branch hints to keep un
On Fri, Jan 22, 2016 at 09:15:31AM -, Patchwork wrote:
> == Summary ==
>
> Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly:
> 2016y-01m-21d-11h-02m-42s UTC integration manifest
>
> Test kms_flip:
> Subgroup basic-flip-vs-dpms:
> pass -> DMESG
Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> intel_post_plane_update did an extra vblank wait that's no longer
> needed when enabling ips.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_display.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --g
This patch sets the invert bit for hpd detection for each port
based on VBT configuration. Since each AOB can be designed to
depend on invert bit or not, it is expected if an AOB requires
invert bit, the user will set respective bit in VBT.
v2: Separated VBT parsing from the rest of the logic. (Ja
On 11/02/16 23:09, yu@intel.com wrote:
From: Alex Dai
GuC client object is always pinned during its life cycle. We cache
the kmap of its first page, which includes guc_process_desc and
doorbell. By doing so, we can simplify the code where we read from
this page to get where GuC is progress
Hi Shubhangi,
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20160212]
[cannot apply to v4.5-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Shubhangi
This patch adds new fields that are not yet added in drm code
in child devices struct
Signed-off-by: Sivakumar Thulasimani
Signed-off-by: Durgadoss R
Signed-off-by: Shubhangi Shrivastava
---
drivers/gpu/drm/i915/intel_bios.c | 15 ++-
drivers/gpu/drm/i915/intel_bios.h | 20
This patch sets the invert bit for hpd detection for each port
based on VBT configuration. Since each AOB can be designed to
depend on invert bit or not, it is expected if an AOB requires
invert bit, the user will set respective bit in VBT.
v2: Separated VBT parsing from the rest of the logic. (Ja
Hi Dave,
More drm-misc stuff:
- vgaswitcheroo support for apple gmux from Lukas Wunner
- checks for ->mode_fixup in non-atomic helpers from Carlos Palminha, plus
removing dummy funcs from drivers. Carlos promised to follow up with
more, since there's lots more silly dummy functions around.
- d
On Fri, Feb 12, 2016 at 01:53:10PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 21, 2016 at 03:10:19PM -0800, Rafael Antognolli wrote:
> > This module is heavily based on i2c-dev. Once loaded, it provides one
> > dev node per DP AUX channel, named drm_dp_auxN, where N is an integer.
> >
> > It's poss
This unbreaks distcheck target that in turn runs each test with --list-subtests.
Signed-off-by: Marius Vlad
---
tests/prime_mmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/prime_mmap.c b/tests/prime_mmap.c
index 29a0cfd..1ea61c2 100644
--- a/tests/prime_mmap.c
++
Hi Shubhangi,
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20160212]
[cannot apply to v4.5-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits
On 12/02/16 12:00, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Assorted changes most likely without any practical effect
apart from a tiny reduction in generated code for the interrupt
handler and request submission.
* Remove needless initialization.
* Improve cache locality by reorganizi
Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> Factor out intel_fbc_supports_rotation
^ not anymore
> and use it in
> pre_plane_update as well. This leaves intel_crtc->atomic
> empty, so remove it too.
>
> Changes since v1:
> - Add a intel_fbc_supports_rotation helper.
Chang
On Fri, Feb 12, 2016 at 06:39:44PM +0530, Shubhangi Shrivastava wrote:
> This patch sets the invert bit for hpd detection for each port
> based on VBT configuration. Since each AOB can be designed to
> depend on invert bit or not, it is expected if an AOB requires
> invert bit, the user will set re
On Fri, Feb 12, 2016 at 01:46:35PM +, Tvrtko Ursulin wrote:
>
>
> On 12/02/16 12:00, Tvrtko Ursulin wrote:
> >From: Tvrtko Ursulin
> >
> >Assorted changes most likely without any practical effect
> >apart from a tiny reduction in generated code for the interrupt
> >handler and request submis
On Fri, Feb 12, 2016 at 12:00:40PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Assorted changes most likely without any practical effect
> apart from a tiny reduction in generated code for the interrupt
> handler and request submission.
>
> * Remove needless initialization.
> * Imp
From: Ville Syrjälä
Bspec tells us that we can allow cdclk up to 540Mhz on BDW ULX, or
up to 675 MHz on ULT, bu only if extra cooling is provided. There
don't seem to be any strap or VBT bits to tells us this however.
But I did spot something potentially relevant in
VBIOS_GOP_Driver_SWF_Register
On Fri, Feb 12, 2016 at 05:06:07PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Bspec tells us that we can allow cdclk up to 540Mhz on BDW ULX, or
> up to 675 MHz on ULT, bu only if extra cooling is provided. There
> don't seem to be any strap or VBT bits to tells us this
ed to the wrong git tree, please drop us a
> note to help improving the system]
>
> url:https://github.com/0day-ci/linux/commits/Rodrigo-Vivi/drm-i91
> 5-Avoid-vblank-counter-for-gen9/20160212-090608
> base: git://anongit.freedesktop.org/drm-intel for-linux-next
> conf
On 12/02/16 14:42, Chris Wilson wrote:
On Fri, Feb 12, 2016 at 12:00:40PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Assorted changes most likely without any practical effect
apart from a tiny reduction in generated code for the interrupt
handler and request submission.
* Remove nee
On Fri, 2016-02-12 at 11:34 +0200, David Weinehall wrote:
> On Thu, Feb 11, 2016 at 09:00:47AM -0800, Rodrigo Vivi wrote:
> > Framecounter register is read-only so DMC cannot restore it
> > after exiting DC5 and DC6.
> >
> > Easiest way to go is to avoid the counter and use vblank
> > interruption
On Thu, Feb 11, 2016 at 09:00:47AM -0800, Rodrigo Vivi wrote:
> Framecounter register is read-only so DMC cannot restore it
> after exiting DC5 and DC6.
>
> Easiest way to go is to avoid the counter and use vblank
> interruptions for this platform and for all the following
> ones since DMC came to
On Fri, Jan 22, 2016 at 05:39:04PM -0800, abhay.ku...@intel.com wrote:
> From: Abhay Kumar
>
> Make resume/on codepath not to wait for panel_power_cycle_delay(t11_t12)
> if this time is already spent in suspend/poweron time.
>
> v2: Use CLOCK_BOOTTIME and remove jiffies for panel power cycle
>
On 04/02/2016 17:01, Jesse Barnes wrote:
On 01/11/2016 10:42 AM, john.c.harri...@intel.com wrote:
From: John Harrison
The scheduler decouples the submission of batch buffers to the driver
with their submission to the hardware. This basically means splitting
the execbuffer() function in half. T
Oh, actually please just ignore this patch completely.
More work here need to be done. This apparently helped on the issue
that I was facing here but doesnt' solve completely.
On Fri, 2016-02-12 at 07:58 -0800, Rodrigo Vivi wrote:
> On Fri, 2016-02-12 at 11:34 +0200, David Weinehall wrote:
> > On
On Fri, Feb 12, 2016 at 03:54:27PM +, Tvrtko Ursulin wrote:
>
> On 12/02/16 14:42, Chris Wilson wrote:
> >On Fri, Feb 12, 2016 at 12:00:40PM +, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>Assorted changes most likely without any practical effect
> >>apart from a tiny reduction
Caught by Klockwork.
Signed-off-by: Martin Peres
---
src/uxa/intel_display.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/uxa/intel_display.c b/src/uxa/intel_display.c
index 8bf0184..44744a5 100644
--- a/src/uxa/intel_display.c
+++ b/src/uxa/intel_display.c
@@ -688,6 +688,11 @@ i
Caught by Klockwork and I genuinely can't tell if it is safe without
it, especially since all the surrounding code is checking for NULL.
Signed-off-by: Martin Peres
---
src/sna/sna_accel.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/sna/sna_accel.c b/src/sna/sna_acc
I got lost in all the changes done on priv->flush and gpu_bo enough
not to be able to guarantee that if flush is non-null, so is gpu_bo.
Caught by Klockwork.
Signed-off-by: Martin Peres
---
src/sna/sna_accel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/sna/sna_accel.c b/src/sna/sna
Caught by Klockwork.
Signed-off-by: Martin Peres
---
src/sna/sna_accel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/sna/sna_accel.c b/src/sna/sna_accel.c
index 8ceb1e1..f1c136a 100644
--- a/src/sna/sna_accel.c
+++ b/src/sna/sna_accel.c
@@ -4376,6 +4376,7 @@ sna_pixmap_move_to_gpu(Pi
Caught by Klockwork. This will be enough to catch those issues during
bringup.
Signed-off-by: Martin Peres
---
src/sna/sna_video_sprite.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/sna/sna_video_sprite.c b/src/sna/sna_video_sprite.c
index 9e85049..ae08ef7 100644
--- a/src/sna/sna
Caught by Klockwork, but it was a false positive. However, better safe
than sorry.
Signed-off-by: Martin Peres
---
src/sna/sna_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 9215b23..78937c2 100644
--- a/src/sna
This is not a big issue to return -1 since the only codepath that uses
it is for display purposes.
Caught by Klockwork.
Signed-off-by: Martin Peres
---
src/intel_device.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/intel_device.c b/src/intel_device.c
index 54c144
The DDX clearly is making Klockwork unhappy but I found those potential
issues. Let's use them as a basis for discussion on the real code that
should be written.
Martin Peres (7):
device: prevent a NULL pointer dereference in __intel_peek_fd
display: prevent a NULL pointer dereference in
i
On Fri, Feb 12, 2016 at 06:31:26PM +0200, Martin Peres wrote:
> Caught by Klockwork.
Impossible.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailma
On Mon, 2016-02-01 at 19:27 +0530, Durgadoss R wrote:
> To support USB type C alternate DP mode, the display driver needs to
> know the number of lanes required by the DP panel as well as number
> of lanes that can be supported by the type-C cable. Sometimes, the
> type-C cable may limit the bandwi
On Fri, Feb 12, 2016 at 06:31:28PM +0200, Martin Peres wrote:
> Caught by Klockwork. This will be enough to catch those issues during
> bringup.
But you just said that klockwork didn't find a bug... :-p
I did contemplate having this stored on the CRTC instead.
Reviewed-by: Chris Wilson
-Chris
Split out of bxt_ddi_pll_select() the logic that calculates the pll
dividers and dpll_hw_state into a new function that doesn't depend on
crtc state. This will be used for enabling the port pll when doing
upfront link training.
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915
On Fri, Feb 12, 2016 at 06:31:29PM +0200, Martin Peres wrote:
> I got lost in all the changes done on priv->flush and gpu_bo enough
> not to be able to guarantee that if flush is non-null, so is gpu_bo.
>
> Caught by Klockwork.
Nope, impossible.
-Chris
--
Chris Wilson, Intel Open Source Technol
On Fri, Feb 12, 2016 at 06:31:27PM +0200, Martin Peres wrote:
> Caught by Klockwork, but it was a false positive. However, better safe
> than sorry.
No. cursor->image can be NULL for old gen/kernels.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Fri, Feb 12, 2016 at 06:31:23PM +0200, Martin Peres wrote:
> This is not a big issue to return -1 since the only codepath that uses
> it is for display purposes.
Impossible.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx m
!!! This caused a regression in the i-g-t drv_module_reload_basic test.
Reproducible easily on HSW (i5-4460) with:
#rmmod snd_hda_intel
The bisect shows this as the offending commit:
commit 25e4abb33df3aafa7d1efba8f82f9178268efab1
Author: Libin Yang
Date: Tue Jan 12 11:13:27 2016 +0800
On Fri, Feb 12, 2016 at 06:31:25PM +0200, Martin Peres wrote:
> Caught by Klockwork and I genuinely can't tell if it is safe without
> it, especially since all the surrounding code is checking for NULL.
Impossible.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_
On Mon, 2016-02-01 at 19:27 +0530, Durgadoss R wrote:
> Looping over the crtc list and finding an unused crtc
> has users other than load_detect().
Which other users? If there are other users they should be converted in this
patch. If the use will only come in a future patch, please make that cle
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
This patchset adds missing display power domain references during
modeset HW readout, which I noticed via wakeref warnings the
corresponding HW accesses triggered. The crt and ddi patches have a
concrete bugzilla reference they fix, I don't know of reports that would
be fixed by the rest of the pat
We have many places in the code where we check if a given display power
domain is enabled and if so access registers backed by this power
domain. We assumed that some modeset lock will prevent the power
reference from vanishing in the middle of the HW access, but this
assumption doesn't always hold
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
On Mon, Feb 01, 2016 at 07:27:53PM +0530, Durgadoss R wrote:
> To support USB type C alternate DP mode, the display driver needs to
> know the number of lanes required by the DP panel as well as number
> of lanes that can be supported by the type-C cable. Sometimes, the
> type-C cable may limit the
I think I mentioned something about the patch summary (the title) being too big
before. The kernel documentation on submitting patches [1] says: "the "summary"
must be no more than 70-75 characters".
[1] https://www.kernel.org/doc/Documentation/SubmittingPatches
Cheers,
Ander
On Wed, 2016-02-10
On Wed, 2016-02-10 at 14:34 +0530, Shubhangi Shrivastava wrote:
> Current DP detection has DPCD operations split across
> intel_dp_hpd_pulse and intel_dp_detect which contains
> duplicates as well. Also intel_dp_detect is called
> during modes enumeration as well which will result
> in multiple dpc
On Fri, Feb 12, 2016 at 06:31:24PM +0200, Martin Peres wrote:
> Caught by Klockwork.
>
> Signed-off-by: Martin Peres
> ---
> src/uxa/intel_display.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/src/uxa/intel_display.c b/src/uxa/intel_display.c
> index 8bf0184..44744a5 100644
>
I'm not sure this actually fix the root problem. With or without your
patch applied, I'm seeing the following in lib/tests/test-suite.log:
../../tests/prime_mmap:
Checking invalid option handling...
Checking valid option handling...
Checking subtest enumeration...
(prime_mmap:24023) ioctl-
On 02/12/2016 03:18 AM, Ville Syrjälä wrote:
On Thu, Feb 11, 2016 at 03:22:08PM -0800, clinton.a.tay...@intel.com wrote:
From: Clint Taylor
Track VCO frequency of SKL instead of the boot CDCLK and allow modeset
to set cdclk based on the max required pixel clock based on VCO
selected.
The vco
This will give us flexibility to enable PSR by default independently so
issues and corner cases in one platform won't affect others were we have
it working properly.
Cc: Paulo Zanoni
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_params.c | 5 +++--
drivers/gpu/drm/i915/intel_psr.c
With a reliable frontbuffer tracking and all instability corner cases
solved for this platform let's re-enabled PSR by default.
In case a new issue is found and PSR is the main suspect, please check
if i915.enable_psr=0 really makes your problem go away,
please report it at bugs.freedesktop.org.
For a long time we are trying to enable PSR by default everwhere
but we always end up in soem specific corner case in one
platform or another and end up not enabling in older stable platforms
that could benefit from the power saving it provides.
So, let's change the approach here and try to enable
With a reliable frontbuffer tracking and all instability corner cases
on Haswell and Broadwell solved let's re-enabled PSR by default on
these platforms.
In case a new issue is found and PSR is the main suspect, please check
if i915.enable_psr=0 really makes your problem go away. If this is the ca
On Thu, 2016-01-21 at 15:10 -0800, Rafael Antognolli wrote:
> So far, the i915 driver and some other drivers set it to the
> drm_device,
> which doesn't allow one to know which DP a given aux channel is
> related
> to. Changing this to be the drm_connector provides proper nesting,
> still
> allowin
On Thu, Jan 21, 2016 at 6:10 PM, Rafael Antognolli
wrote:
> From: Lukas Wunner
>
> Rafael Antognolli's new DRM_DP_AUX_CHARDEV feature causes a WARN_ON
> if drm_dp_aux->dev == drm_connector->kdev and drm_dp_aux_unregister()
> is called after drm_connector_unregister(). radeon is the only driver
>
On Fri, Feb 12, 2016 at 02:01:11PM +0200, Ville Syrjälä wrote:
> On Fri, Jan 22, 2016 at 09:15:31AM -, Patchwork wrote:
> > == Summary ==
> >
> > Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly:
> > 2016y-01m-21d-11h-02m-42s UTC integration manifest
> >
> > Test kms_flip:
On Fri, Feb 12, 2016 at 01:21:33PM -0800, Rafael Antognolli wrote:
> On Fri, Feb 12, 2016 at 02:01:11PM +0200, Ville Syrjälä wrote:
> > On Fri, Jan 22, 2016 at 09:15:31AM -, Patchwork wrote:
> > > == Summary ==
> > >
> > > Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly:
>
On Fri, Feb 12, 2016 at 09:52:03AM +0200, Oleksandr Natalenko wrote:
> Ville,
>
> I've applied patch you've provided and did couple of replugging with
> intel_reg in between. Here are the results.
>
> I used additional VGA cable to see what actually I type in console :).
>
My life would have be
I'm testing a new thinkpad skylake based P70 with dual graphics
legolas:~# lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Device 191b (rev 06)
01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro M600M]
(rev a2)
I'm getting these warnings at boot, althoug
From: Clint Taylor
Set cdclk based on the max required pixel clock based on VCO
selected. Track boot vco instead of boot cdclk.
The vco is now tracked at the atomic level and all CRTCs updated if
the required vco is changed. Not tested with eDP v1.4 panels that
require 8640 vco due to availabili
91 matches
Mail list logo
