On Mon, Oct 19, 2015 at 10:27:17PM +, Smith, Gary K wrote:
> Unless legacy mode enables it of course.
I thought we decided to ignore legacy gamma stuff (at least for now, until
someone complains about the inconsistency). So yeah, I think we're fine.
-Daniel
>
> Thanks
> Gary
>
>
> "Smith,
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, 2015-09-23 at 13:27 +0200, Maarten Lankhorst wrote:
> > > @@ -13306,6 +13299,29 @@ intel_prepare_plane_fb(struct drm_plane *plane,
> > > if (ret)
> >
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 helper without retry.
>
> We're supposed to do the retries when the si
On Mon, Oct 19, 2015 at 09:20:36PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 07, 2015 at 11:01:23AM +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.
> >
>
On Mon, Oct 19, 2015 at 03:05:46PM -0700, yu@intel.com wrote:
> From: Alex Dai
>
> There is a memory leak warning message from i915_gem_context_clean
> when GuC submission is enabled. The reason is that the request (so
> the LRC associated with it) is freed early than moving the vma list
> to
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, 2015-09-23 at 13:27 +0200, Maarten Lankhorst wrote:
> > > > @@ -13306
Yes, please note that as per the discussion, the legacy gamma IOCTL is still
existing, to maintain the backward compatibility, we have not broken it.
And we have added provision to program legacy-8bit gamma via color manager
also, so everyone should be happy :)
Regards
Shashank
-Original Me
On 20/10/15 08:42, Daniel Vetter wrote:
On Mon, Oct 19, 2015 at 09:20:36PM +0300, Ville Syrjälä wrote:
On Wed, Oct 07, 2015 at 11:01:23AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Previously rotation was ignored and wrong stride programmed
into the plane registers resulting in a corr
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 to verify whether flipping a
framebuffer with a Y fb modifier (90/270 degree rotation) and
an associ
There is a desire to simplify the i915 driver by reducing the number of
different code paths introduced by the LRC / execlists support. As the
execlists request is now part of the gem request it is possible and
desirable to unify the request life-cycles for execlist and legacy
requests.
A request
Shovel all context related objects through the active queue and obj
management.
- Added callback in vma_(un)bind to add CPU (un)mapping at same time
if desired
- Inserted LRC hw context & ringbuf to vma active list
Issue: VIZ-4277
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_drv.h
Renamed tmp variable to the more descriptive iir. (Daniel Vetter/
Thomas Daniel)
Issue: VIZ-4277
Signed-off-by: Nick Hoath
Cc: Daniel Vetter
Cc: David Gordon
Cc: Thomas Daniel
---
drivers/gpu/drm/i915/i915_irq.c | 46 -
1 file changed, 23 insertions(+),
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 Vetter/Chris Wilson)
Issue: VIZ-4277
Signed-off-by: Nick Hoath
Cc: Thomas Daniel
Cc: Daniel Vetter
Cc: Chris Wilson
---
drivers/gpu/dr
We now only need to update the address of the ringbuf object in the
hw context when it is pinned, and the hw context is first CPU mapped
Issue: VIZ-4277
Signed-off-by: Nick Hoath
Cc: David Gordon
---
drivers/gpu/drm/i915/intel_lrc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff
Pin the hw ctx mapping so that it is not mapped/unmapped per bb
when doing GuC submission.
v2: Removed interim development extra mapping. (Daniel Vetter)
Issue: VIZ-4277
Signed-off-by: Nick Hoath
Cc: David Gordon
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 14 ---
driv
These changes are a result of the requests made in VIZ-4277.
Make the lrc path more like the legacy submission path.
Attach the CPU mappings to vma (un)bind, so that the shrinker
also cleans those up.
Pin the CPU mappings while context is busy (pending requests), so
that the mappings aren't release
On Tue, Oct 20, 2015 at 10:23:53AM +0100, Nick Hoath wrote:
> There is a desire to simplify the i915 driver by reducing the number of
> different code paths introduced by the LRC / execlists support. As the
> execlists request is now part of the gem request it is possible and
> desirable to unify
On Tue, Oct 20, 2015 at 10:23:54AM +0100, Nick Hoath wrote:
> Shovel all context related objects through the active queue and obj
> management.
>
> - Added callback in vma_(un)bind to add CPU (un)mapping at same time
> if desired
> - Inserted LRC hw context & ringbuf to vma active list
>
> Issu
On Tue, Oct 20, 2015 at 10:23:55AM +0100, Nick Hoath wrote:
> Pin the hw ctx mapping so that it is not mapped/unmapped per bb
> when doing GuC submission.
>
> v2: Removed interim development extra mapping. (Daniel Vetter)
You've missed the point here. I've shown how to do kmapping once neatly,
wh
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 in sane state. During sanitization initialize cdclk with maximum
value till we get dynamic cdclk support.
v2:
Hi Nick,
[auto build test WARNING on next-20151020 -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Nick-Hoath/lrc-lifecycle-cleanups/20151020-173347
config: i386-randconfig-x009-10191220 (attach
On Fri, 02 Oct 2015, Chris Wilson wrote:
> On Fri, Oct 02, 2015 at 10:50:50AM +0300, Jani Nikula wrote:
>> On Fri, 02 Oct 2015, clinton.a.tay...@intel.com wrote:
>> > From: Clint Taylor
>> >
>> > backlight minimum is a valid value so you don't need to set maximum.
>> >
>> > Signed-off-by: Clint T
On Tue, Oct 20, 2015 at 10:06:58AM +0100, Tvrtko Ursulin wrote:
>
> On 20/10/15 08:42, Daniel Vetter wrote:
> > On Mon, Oct 19, 2015 at 09:20:36PM +0300, Ville Syrjälä wrote:
> >> On Wed, Oct 07, 2015 at 11:01:23AM +0100, Tvrtko Ursulin wrote:
> >>> From: Tvrtko Ursulin
> >>>
> >>> Previously rot
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 in sane state. During sanitization
On 20/10/15 12:07, Ville Syrjälä wrote:
On Tue, Oct 20, 2015 at 10:06:58AM +0100, Tvrtko Ursulin wrote:
On 20/10/15 08:42, Daniel Vetter wrote:
On Mon, Oct 19, 2015 at 09:20:36PM +0300, Ville Syrjälä wrote:
On Wed, Oct 07, 2015 at 11:01:23AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
On Tue, Oct 20, 2015 at 12:44:05PM +0100, Tvrtko Ursulin wrote:
>
> On 20/10/15 12:07, Ville Syrjälä wrote:
> > On Tue, Oct 20, 2015 at 10:06:58AM +0100, Tvrtko Ursulin wrote:
> >>
> >> On 20/10/15 08:42, Daniel Vetter wrote:
> >>> On Mon, Oct 19, 2015 at 09:20:36PM +0300, Ville Syrjälä wrote:
> >
On 20/10/15 12:53, Ville Syrjälä wrote:
On Tue, Oct 20, 2015 at 12:44:05PM +0100, Tvrtko Ursulin wrote:
On 20/10/15 12:07, Ville Syrjälä wrote:
On Tue, Oct 20, 2015 at 10:06:58AM +0100, Tvrtko Ursulin wrote:
On 20/10/15 08:42, Daniel Vetter wrote:
On Mon, Oct 19, 2015 at 09:20:36PM +0300,
We have added two patches to optimize multiple commit calls, to address Gary's
comment, using one additional flag in CRTC state.
We have tested this, and it's working for both Android and Linux.
I am sending this new patch set now (v7), which has these two additional
patches, in total 25 in co
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 Vetter/Chris Wilson)
>
> Issue: VIZ-4277
> Signed-off-by: Nick Hoath
> C
Revision checks are almost always accompanied by a platform check. (The
exceptions are platform specific code.) Add helpers to check for a
platform and a revision range: IS_SKL_REVID() and IS_BXT_REVID(). In
most places this simplifies and clarifies the code. It will be obvious
that revid macros ar
Totally unnecessary.
Acked-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8afda459a26e..f222114981
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| 1 +
drivers/gpu/drm/i915/i915_gem.c| 2 +-
drivers/gp
On Tue, Oct 20, 2015 at 01:05:22PM +0100, Tvrtko Ursulin wrote:
>
> On 20/10/15 12:53, Ville Syrjälä wrote:
> > On Tue, Oct 20, 2015 at 12:44:05PM +0100, Tvrtko Ursulin wrote:
> >>
> >> On 20/10/15 12:07, Ville Syrjälä wrote:
> >>> On Tue, Oct 20, 2015 at 10:06:58AM +0100, Tvrtko Ursulin wrote:
>
This patch set adds Color Manager implementation in DRM layer. Color Manager
is an extension in DRM framework to support color correction/enhancement.
Various Hardware platforms can support several color correction capabilities.
Color Manager provides abstraction of these capabilities and allows a
Color Management is an extension to DRM framework. It allows
abstraction of hardware color correction and enhancement capabilities
by virtue of DRM properties.
There are two major types of color correction supported by DRM
color manager:
- CTM: color transformation matrix, properties where a corre
This patch adds new variables in CRTC state, to hold respective color
correction blobs. These blobs will be required during the atomic commit
for writing the color correction values in correction registers.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/drm_ato
Add a color correction state flag, to indicate a change in
color correction states. This flag will help a core driver to
optimize its commit calls, by appling the color correction only
when there is a change, not every commit.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_atomic.c | 6 +
DRM color management is written to extract the color correction
capabilities of various platforms, and every platform can showcase
its capabilities using the query properties.
Different hardwares can have different no of coefficients for palette
correction. Also the correction can be applied after
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
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
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.
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 +++
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
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
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
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
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
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
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
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
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-
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
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/
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
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
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 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
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 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 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 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, 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
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 @@
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
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
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
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 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 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
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
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
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
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
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:
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
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ä
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
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: 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
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 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
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
1 - 100 of 138 matches
Mail list logo
