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
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: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 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 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 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 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: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, 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
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
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
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
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
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 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
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
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 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 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, 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, 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
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, 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
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
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 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
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 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: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 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 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, 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 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
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: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
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 registers resulting in a corrupt image on screen.
v2: Do not access potentialy old plane sta
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 registers resulting in a corrupt image on screen.
>
> v2: Do not access potentialy old plane state at flip time,
> but store
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
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)
Signed-off-by
On Tue, Oct 20, 2015 at 03:33:27PM +1000, Dave Airlie wrote:
> On 20 October 2015 at 07:54, Daniel Vetter wrote:
> > On Mon, Oct 19, 2015 at 04:19:08PM -0400, da...@codemonkey.org.uk wrote:
> >> On Wed, Sep 30, 2015 at 08:56:26AM +0200, Daniel Vetter wrote:
> >>
> >> > > The warning on boot
From: Ville Syrjälä
Drop the EDP_PSR_BASE() thing, and just stick the PSR register offset
under dev_priv, like we for DSI and GPIO for example.
TODO: could probably move a bunch of this kind of stuff into the device
info instead...
v2: Drop the surious whitespace change (Jani)
Reviewed-by: Jan
From: Ville Syrjälä
v2: Keep some MISSING_CASE() stuff (Jani)
s/-1/-PIPE_B/ in the register macro
Fix typo in patch subject
v3: Use PORT_B registers for invalid ports in g4x_aux_ctl_reg() (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h
From: Ville Syrjälä
Rather than computing on demand, store also the aux data reg
offsets under intel_dp.
v2: Duplicate some code to make things less magic (Jani)
v3: Use PORT_B registers for invalid ports in g4x_aux_data_reg()
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c
Hi Shashank,
[auto build test WARNING on drm-intel/for-linux-next -- if it's inappropriate
base, please suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Shashank-Sharma/Color-Management-for-DRM-framework/20151020-202959
reproduce:
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 decided to reimplement it since the code
changed a lot since then.
Cre
In function find_compression_threshold() we try to over-allocate CFB
space in order to reudce reallocations and fragmentation, and we're
not considering that at the CFB size check. Consider it.
There is also a longer-term plan to kill
dev_priv->fbc.uncompressed_size, but this will come later.
Sig
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.
Besides the immediate advantages, this is also going to make one of
the next commits much si
Hello
This series has two main goals:
- Simplify FBC handling so we don't recompute state or disable+reenable when
it's not necessary.
- Solve the CFB race we have that make it possible for the hardware to use the
CFB even after we free its drm_mm node.
Of course we can always do more
Make sure we deactivate FBC at intel_fbc_init(), so we can remove the
call from intel_display.c.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 3 ---
drivers/gpu/drm/i915/intel_fbc.c | 5 +++--
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gp
The hardware already takes care of disabling and recompressing FBC
when we do a page flip, so all we need to do is to update the fence
registers and move on.
One of the important things to notice is that on the pre-gen6
platforms the fence is programmed on the FBC control register and the
document
This change was part of the commit that makes intel_fbc_update()
receive an intel_crtc as argument instead of dev_priv, but since it
was polluting the diff with too many chunks I decided to move it to
its own commit.
It seems that our developers are favoring having this instead of the
old combinat
These also can't change without a full modeset.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index af22bc8..7f54b6f 100644
This moves the pre-gen4 check from update() to enable(). The HAS_DDI
in the original code is not needed since only gen 2/3 have the plane
swapping code.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/dr
These things can't change without a full modeset.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 48d8cfc..af22bc8 10064
The long term goal is to have enable/disable as the higher level
functions and activate/deactivate as the lower level functions, just
like we do for PSR and for the CRTC. Let's start this by renaming the
functions that touch the hardware state and their wrappers.
The conversion to the full correct
Don't try to list in comments the cases where we should enable or
disable FBC: it varies a lot with the hardware generations and the
code should be the documentation. Also notice that there's already a
huge gap between the comments and what's in the code.
Signed-off-by: Paulo Zanoni
---
drivers/
There's no need to reevaluate the status of every single crtc when a
single crtc changes its state.
With this, we're cutting the case where due to a change in pipe B,
intel_fbc_update() is called, then intel_fbc_find_crtc() concludes FBC
should be enabled on pipe A, then it completely rechecks the
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 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/dri
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 stolen memory allocations.
With this, activate/deactivate will just s
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/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 9477379..b9cfd16 10
One of the problems with the current code is that it frees the CFB and
releases its drm_mm node as soon as we flip FBC's enable bit. This is
bad because after we disbale FBC the hardware may still use the CFB
for the rest of the frame, so in theory we should only release the
drm_mm node one frame a
If we run igt/kms_frontbuffer_tracking, this message will appear
thousands of times, eating a significant part of our dmesg buffer.
It's part of the expected FBC behavior, so let's just silence it.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 2 --
1 file changed, 2 deletio
If FBC is disabled we will still call intel_fbc_invalidate(), and as a
result we may call intel_fbc_deactivate(), which will try to touch
registers.
I'm pretty sure I saw this happen on a runtime suspended device, and
I'm almost sure I was running igt/pm_rpm. It produced the "you touched
registers
v2: Also add same text to qf help.
v3: Ask submission to have a subject prefix (Jani)
---
dim.rst | 11 +++
qf | 11 +++
2 files changed, 22 insertions(+)
diff --git a/dim.rst b/dim.rst
index da5fdd3a814d..b909e1d87a40 100644
--- a/dim.rst
+++ b/dim.rst
@@ -307,3 +307,14 @@
On Tue, Oct 20, 2015 at 04:05:24PM +0300, Jani Nikula wrote:
> On Mon, 28 Sep 2015, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > v2: Keep some MISSING_CASE() stuff (Jani)
> > s/-1/-PIPE_B/ in the register macro
> > Fix typo in patch subject
> >
> > Signed-off-by: Vi
On Fri, 18 Sep 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Drop the EDP_PSR_BASE() thing, and just stick the PSR register offset
> under dev_priv, like we for DSI and GPIO for example.
>
> TODO: could probably move a bunch of this kind of stuff into the device
> info inste
On Tue, 2015-10-20 at 10:10 +0200, Daniel Vetter wrote:
> On Tue, Oct 20, 2015 at 10:38:41AM +0300, Ander Conselvan De Oliveira wrote:
> > On Mon, 2015-10-19 at 15:30 +0200, Daniel Vetter wrote:
> > > On Mon, Oct 19, 2015 at 04:16:53PM +0300, Ander Conselvan De Oliveira
> > > wrote:
> > > > On Wed,
On Mon, 28 Sep 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> v2: Keep some MISSING_CASE() stuff (Jani)
> s/-1/-PIPE_B/ in the register macro
> Fix typo in patch subject
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 102
> +
On Mon, 2015-10-19 at 17:09 +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, otherwise
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 dynamic cdclk support.
>
> v2: Check if BIOS programmed correctly rat
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 dynamic cdclk support.
v2: Check if BIOS programmed correctly rather than always calling init
- Do validation of programmed cdctl and
On Tue, Oct 20, 2015 at 02:12:21PM +0200, Daniel Vetter wrote:
> On Tue, Oct 20, 2015 at 10:23:52AM +0100, Nick Hoath wrote:
> > Break out common code from gen8_gt_irq_handler and put it in to
> > an always inlined function. gcc optimises out the shift at compile
> > time. (Thomas Daniel/Daniel Vet
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_csr.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 9e530a739354..7d9c2d42fc1a 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/driver
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_csr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 7d9c2d42fc1a..fe9a55cf8212 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/
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.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_csr.c
I915 color manager registers pipe degamma correction as palette
correction before CTM, DRM property.
This patch adds the no of coefficients(512) for degamma correction
as "num_samples_before_ctm" parameter in device info structures,
for BDW and higher platforms.
Signed-off-by: Shashank Sharma
Si
BDW/SKL/BXT supports Degamma color correction feature, which
linearizes the non-linearity due to gamma encoded color values.
This will be applied before Color Transformation.
This patch does the following:
1. Adds the core function to program DeGamma correction values for
BDW/SKL/BXT platform
2
In plane enabling sequence, plane gamma bit is by default enabled.
Plane gamma gets higher priority than pipe gamma, if both enabled.
This patch disables plane gamma from sequence. If required, plane
gamma can be enabled via the color manager drm interface.
Signed-off-by: Shashank Sharma
Signed-
Function intel_attach_color_properties_to_crtc attaches a
color property to its CRTC object. This patch calls this
function from crtc initialization sequence.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_display.c | 1 +
1 file changed, 1 insertion
On 10/20/2015 04:49 PM, Ville Syrjälä wrote:
On Tue, Oct 20, 2015 at 03:27:24PM +0530, Kumar, Shobhit wrote:
On 10/19/2015 07:18 PM, Ville Syrjälä wrote:
On Fri, Oct 16, 2015 at 06:48:53PM +0530, Shobhit Kumar wrote:
Especially in cases where pre-os does not enable display, cdclk might
not be
This patch optimizes the commit path for i915 driver, by applying
color corrections, only when required. Pipe level color correction
(like CSC/gamma/degamma) once applied, sustain until the next change.
DRM layer sets a flag in crtc state (color_correction_changed),
whenever there is new set_prope
BDW/SKL/BXT platforms support various Gamma correction modes
which are:
1. Legacy 8-bit mode
2. 10-bit mode
3. Split mode
4. 12-bit mode
This patch does the following:
1. Adds the core function to program Gamma correction values
for BDW/SKL/BXT platforms
2. Adds Gamma correction macros/defines
BDW/SKL/BXT support Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into respective CSC registers.
This patch does the following:
1. Adds the core function to program CSC correction values for
BDW/SKL/BXT platform
2. Adds CSC correction macros/defines
Signed-off-by:
I915 color manager registers pipe gamma correction as palette
correction after CTM property.
For BDW and higher platforms, split gamma correction is the best
gamma correction. This patch adds the no of coefficients(512) for
split gamma correction as "num_samples_after_ctm" parameter in device
info
The color correction blob values are loaded during set_property
calls. This patch adds a function to find the blob and apply the
correction values to the display registers, during the atomic
commit call.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel
CHV/BSW supports Color Space Conversion (CSC) using a 3x3 matrix
that needs to be programmed into CGM (Color Gamut Mapping) registers.
This patch does the following:
1. Attaches CSC property to CRTC
2. Adds the core function to program CSC correction values
3. Adds CSC correction macros
Signed-of
This patch create new files intel_color_manager.c which
will contain the core color correction code for I915 driver
and its header intel_color_manager.h
The per color property patches coming up in this patch series
will fill the appropriate functions in this file.
Signed-off-by: Shashank Sharma
DRM color manager allows the driver to showcase its best color
correction capabilities using the specific query property
cm_coeff_before_ctm_property. The driver must loads the no. of
coefficients for color correction as per the platform capability
during the init time.
This patch adds no of coeff
CHV/BSW platform supports two different pipe level gamma
correction modes, which are:
1. Legacy 8-bit mode
2. 10-bit CGM (Color Gamut Mapping) mode
This patch does the following:
1. Attaches Gamma property to CRTC
3. Adds the core Gamma correction function for CHV/BSW
4. Adds Gamma correction macr
This patch adds new structures in DRM layer for Palette color
correction.These structures will be used by user space agents
to configure appropriate number of samples and Palette LUT for
a platform.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
include/uapi/drm/drm.h | 20 +++
As per DRM color manager design, if a userspace wants to set a correction
blob, it prepares it and sends the blob_id to kernel via set_property
call. DRM framework takes this blob_id, gets the blob, and saves it
in the CRTC state, so that, during the atomic_commit, the color correction
values from
CHV/BSW supports Degamma color correction, which linearizes all
the non-linear color values. This will be applied before Color
Transformation.
This patch does the following:
1. Attach deGamma property to CRTC
2. Add the core function to program DeGamma correction values for
CHV/BSW platform
2.
As per the DRM get_property implementation for a blob, framework
is supposed to return the blob_id to the caller. All the color
management blobs are saved in CRTC state during the set call.
This patch adds get_property support for color management
properties, by referring to the existing blob for
DRM color manager allows the driver to showcase its best color
correction capabilities using the specific query property
cm_coeff_after_ctm_property. The driver must loads the no. of
coefficients for color correction as per the platform capability
during the init time.
This patch adds no of coeffi
This patch adds set property interface for intel CRTC. This
interface will be used for set operation on any DRM properties.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i
Color Manager framework defines a DRM property for color
space transformation and Gamut mapping. This property is called
CTM (Color Transformation Matrix).
This patch adds a new structure in DRM layer for CTM.
This structure can be used by all user space agents to
configure CTM coefficients for co
From DRM color management:
DRM color manager supports these color properties:
1. "ctm": Color transformation matrix property, where a
color transformation matrix of 9 correction values gets
applied as correction.
2. "palette_before_ctm": for corrections which get
1 - 100 of 138 matches
Mail list logo
