On Tue, Oct 20, 2015 at 04:11:34PM +0100, Tvrtko Ursulin wrote:
>
> On 20/10/15 16:08, Ville Syrjälä wrote:
> > On Tue, Oct 20, 2015 at 03:54:11PM +0100, Tvrtko Ursulin wrote:
> >> From: Tvrtko Ursulin
> >>
> >> Previously rotation was ignored and wrong stride programmed
> >> into the plane regis
From: Tvrtko Ursulin
Previously rotation was ignored and wrong stride programmed
into the plane registers resulting in a corrupt image on screen.
v2: Do not access potentialy old plane state at flip time,
but store the rotation value at the time of queing the flip.
(Ville)
v3: No need t
On Tue, Oct 20, 2015 at 04:01:20PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Cdclk < crtc_clock is not allowed and suggests a different problem
> elsewhere in the code.
>
> It is more robust and safe to assume no scaling is possible in
> this case with no other downsides since it w
On Tue, 2015-10-20 at 09:39 +0200, Daniel Vetter wrote:
> On Tue, Oct 20, 2015 at 10:02:21AM +0300, Jani Nikula wrote:
> > On Tue, 20 Oct 2015, Rodrigo Vivi wrote:
> > > We have an inconsistency on our code on using
> > > intel_dp_dpcd_read_wake with
> > > retries and when using drm_dp_dpcd_read
On Wed, 14 Oct 2015 15:51:39 -0700
Kevin Strasser wrote:
> On HSW the crc differs between black and disabled primary planes, causing an
> assert to fail in the kms_universal_plane test. It seems that gamma correction
> and color space conversion are causing the black primary plane case to result
On Tue, Oct 20, 2015 at 11:49:50AM -0200, Paulo Zanoni wrote:
> We're going to kill intel_fbc_find_crtc(), that's why a big part of
> the logic moved from intel_fbc_find_crtc() to crtc_is_valid().
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_fbc.c | 26 -
On Tue, Oct 20, 2015 at 11:49:58AM -0200, Paulo Zanoni wrote:
> These are the functions that lock/unlock FBC to/from a CRTC without
> changing the hardware state. The goal is to run once per modeset. For
> now the functions don't really do much, but we'll still move more
> stuff there, such as the
On Mon, 19 Oct 2015 10:13:58 -0700
Kevin Strasser wrote:
> On Mon, Oct 19, 2015 at 12:15:41PM +0200, Daniel Vetter wrote:
> > On Fri, Oct 16, 2015 at 03:53:22PM -0700, Bob Paauwe wrote:
> > > On Thu, 15 Oct 2015 15:41:30 +0300
> > > Ville Syrjälä wrote:
> > >
> > > > On Thu, Oct 15, 2015 at 02:
On Tue, Oct 20, 2015 at 11:49:49AM -0200, Paulo Zanoni wrote:
> There's no need to stop and restart FBC: a nuke should be fine.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_fbc.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm
On Tue, Oct 20, 2015 at 11:49:51AM -0200, Paulo Zanoni wrote:
> This thing where we need to get the crtc either from the work
> structure or the fbc structure itself is confusing and unnecessary.
> Set fbc.crtc right when scheduling the enable work so we can always
> use it.
Pardon? It was confusi
To stay consisent with how we're programming all the other planes,
enable gamma and CSC on the bottom color. Without this, we fail the
the kms_universal_plane functional tests because the black primary plane
is brighter (gamma corrected) than the disabled plane case. If the bottom
color is also g
On Fri, Oct 09, 2015 at 02:48:33PM -0700, 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
On Tue, Oct 20, 2015 at 08:48:36AM -0700, Bob Paauwe wrote:
> On Mon, 19 Oct 2015 10:13:58 -0700
> Kevin Strasser wrote:
>
> > On Mon, Oct 19, 2015 at 12:15:41PM +0200, Daniel Vetter wrote:
> > > On Fri, Oct 16, 2015 at 03:53:22PM -0700, Bob Paauwe wrote:
> > > > On Thu, 15 Oct 2015 15:41:30 +030
From: Tvrtko Ursulin
Cdclk < crtc_clock is not allowed and suggests a different problem
elsewhere in the code.
It is more robust and safe to assume no scaling is possible in
this case with no other downsides since it will also WARN_ON_ONCE
so that this definitely gets noticed.
Call it an assert
On Tue, 20 Oct 2015 19:13:19 +0300
Ville Syrjälä wrote:
> On Tue, Oct 20, 2015 at 08:48:36AM -0700, Bob Paauwe wrote:
> > On Mon, 19 Oct 2015 10:13:58 -0700
> > Kevin Strasser wrote:
> >
> > > On Mon, Oct 19, 2015 at 12:15:41PM +0200, Daniel Vetter wrote:
> > > > On Fri, Oct 16, 2015 at 03:53:2
On Tue, 2015-10-20 at 08:38 -0700, Rodrigo Vivi wrote:
> On Tue, 2015-10-20 at 09:39 +0200, Daniel Vetter wrote:
> > On Tue, Oct 20, 2015 at 10:02:21AM +0300, Jani Nikula wrote:
> > > On Tue, 20 Oct 2015, Rodrigo Vivi wrote:
> > > > We have an inconsistency on our code on using
> > > > intel_dp_d
On Tue, Oct 20, 2015 at 09:04:56AM -0700, Bob Paauwe wrote:
> To stay consisent with how we're programming all the other planes,
> enable gamma and CSC on the bottom color. Without this, we fail the
> the kms_universal_plane functional tests because the black primary plane
> is brighter (gamma cor
On Tue, Oct 20, 2015 at 05:45:29PM +, Vivi, Rodrigo wrote:
> On Tue, 2015-10-20 at 08:38 -0700, Rodrigo Vivi wrote:
> > On Tue, 2015-10-20 at 09:39 +0200, Daniel Vetter wrote:
> > > On Tue, Oct 20, 2015 at 10:02:21AM +0300, Jani Nikula wrote:
> > > > On Tue, 20 Oct 2015, Rodrigo Vivi wrote:
>
On Mon, Oct 19, 2015 at 05:09:23PM +0200, Maarten Lankhorst wrote:
> Op 19-10-15 om 15:16 schreef Ander Conselvan De Oliveira:
> > On Wed, 2015-09-23 at 13:27 +0200, Maarten Lankhorst wrote:
> >> Move it from intel_crtc_atomic_commit to prepare_plane_fb.
> >> Waiting is done before committing, othe
On Fri, Oct 16, 2015 at 10:43 AM, Peter Zijlstra wrote:
> On Tue, Sep 29, 2015 at 03:39:03PM +0100, Robert Bragg wrote:
>> - We're bridging two complex architectures
>>
>> To review this work I think it will be relevant to have a good
>> general familiarity with Gen graphics (e.g. thinking
This is a corner case not exercised by the other subtests. The test is
expected to pass both with the current Kernel tree and with the
patches that are on the mailing list.
The patches currently on the mailing list change how the CFB is
allocated, and this subtest is designed to make sure everythi
This will be used by the stridechange subtest.
Signed-off-by: Paulo Zanoni
---
tests/kms_frontbuffer_tracking.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index 421f949..2c0
This fixes the failures for cases where you use --run-subtest to run
single subtests that don't use any drawing patterns.
Signed-off-by: Paulo Zanoni
---
tests/kms_frontbuffer_tracking.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffe
That option is not needed anymore since:
commit 982934625ac67234c6d85c6cf29a5a487e54d4f0
Author: Thomas Wood
Date: Wed Sep 16 14:36:24 2015 +0100
lib: allow wildcard matching when specifying subtests
In fact, using "--run-subtest 'fbc-*'" is better than using --fbc-only
due to how SKIPs ar
EBUSY retries are already in place at drm level.
We don't need to replicate the job here.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_dp.c | 20 ++--
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i9
drm level already takes care of the needed retries so instead of
duplicate the effort here.
If we have no idea what caused the error let's assume something
was busy and let drm level handle the retries.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_dp.c | 69 +++
We have an inconsistency on our code on using intel_dp_dpcd_read_wake with
retries and when using drm_dp_dpcd_read helper without retry.
Must probably with the case were aux message size 0 wasn't being
properly handled.
With this in place and with drm level now taking care of all retries
let's ki
drm level already takes care of retries on EBUSY and we had
retries all over intel layer. So let's organize it a bit.
Everything started with aux communications on sink_crc
were failing a lot randomly on recent platforms.
The first solution was to try to use intel_dp_dpcd_read_wake, but then
it wa
Mainly aux communications on sink_crc
were failing a lot randomly on recent platforms.
The first solution was to try to use intel_dp_dpcd_read_wake, but then
it was suggested to move retries to drm level.
Since drm level was already taking care of retries and didn't want
to through random retries
On Tue, 20 Oct 2015 10:10:20 +0100
Tvrtko Ursulin wrote:
>
> On 20/10/15 02:14, Vivek Kasireddy wrote:
> > Hi Tvrtko,
> >
> > On Mon, 19 Oct 2015 11:20:05 +0100
> > Tvrtko Ursulin wrote:
> >
> >>
> >> Hi,
> >>
> >> On 17/10/15 03:47, Vivek Kasireddy wrote:
> >>> The main goal of this subtest is
On Tue, Oct 20, 2015 at 03:52:10PM +0300, Ville Syrjälä wrote:
> On Tue, Oct 20, 2015 at 06:13:12PM +0530, Shobhit Kumar wrote:
> > Especially in cases where pre-os does not enable display, cdclk might
> > not be in sane state. During sanitization initialize cdclk with maximum
> > value till we get
On Tue, Oct 20, 2015 at 10:00:40AM -0700, Bob Paauwe wrote:
> On Tue, 20 Oct 2015 19:13:19 +0300
> Ville Syrjälä wrote:
>
> > On Tue, Oct 20, 2015 at 08:48:36AM -0700, Bob Paauwe wrote:
> > > On Mon, 19 Oct 2015 10:13:58 -0700
> > > Kevin Strasser wrote:
> > >
> > > > On Mon, Oct 19, 2015 at 12
On Tue, Oct 20, 2015 at 03:22:01PM +0300, Jani Nikula wrote:
> Prefer inclusive ranges for revision checks rather than "below B0". Per
> specs A2 is not used, so revid <= A1 matches revid < B0.
>
> Acked-by: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.h
On Tue, Oct 20, 2015 at 03:38:33PM +0300, Jani Nikula wrote:
> Have only one if ladder for platforms and only one range check for
> size. Makes it easier to handle new platforms. Remove the use of
> negative return values in char, which might underflow to be positive for
> some negative error codes
On Tue, Oct 20, 2015 at 05:17:07PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Cdclk < crtc_clock is not allowed and suggests a different problem
> elsewhere in the code.
>
> It is more robust and safe to assume no scaling is possible in
> this case with no other downsides since it w
On Tue, Oct 20, 2015 at 11:16:20AM -0700, Matt Roper wrote:
> On Tue, Oct 20, 2015 at 09:04:56AM -0700, Bob Paauwe wrote:
> > To stay consisent with how we're programming all the other planes,
> > enable gamma and CSC on the bottom color. Without this, we fail the
> > the kms_universal_plane funct
On Tue, Oct 20, 2015 at 04:20:21PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Previously rotation was ignored and wrong stride programmed
> into the plane registers resulting in a corrupt image on screen.
>
> v2: Do not access potentialy old plane state at flip time,
> but store
On Tue, Oct 20, 2015 at 11:49:47AM -0200, Paulo Zanoni wrote:
> I wanted to add yet another check to intel_fbc_update() and realized
> I would need to create yet another enum no_fbc_reason case. So I
> remembered this patch series that Damien wrote a long time ago and
> nobody ever reviewed, so I d
101 - 138 of 138 matches
Mail list logo
