On Thu, Dec 03, 2015 at 04:08:45PM +, Russell King - ARM Linux wrote:
> On Mon, Nov 23, 2015 at 10:32:45AM +0100, Daniel Vetter wrote:
> > @@ -957,11 +955,9 @@ static int armada_drm_crtc_cursor_move(struct drm_crtc
> > *crtc, int x, int y)
> > if (!dcrtc->variant->has_spu_adv_reg)
> >
On Tue, 1 Dec 2015 19:43:05 +0200
Imre Deak wrote:
> On ti, 2015-12-01 at 09:22 -0800, Bob Paauwe wrote:
> > On Tue, 1 Dec 2015 15:56:55 +0200
> > Imre Deak wrote:
> >
> > > On ma, 2015-11-30 at 16:23 -0800, Bob Paauwe wrote:
> > > > Now that the frequency can drop below the user specified mini
Since commit
commit aed242ff7ebb697e4dff912bd4dc7ec7192f7581
Author: Chris Wilson
Date: Wed Mar 18 09:48:21 2015 +
drm/i915: Relax RPS contraints to allows setting minfreq on idle
it is now possible that the current frequency will drop be the user
specified minimum frequency t
Hi Jani,
Is this version ok now?
Do you believe we could go only with this patch for now and continue the
retry and kill read_wake function later?
Thanks,
Rodrigo.
On Wed, Nov 25, 2015 at 4:04 PM Rodrigo Vivi wrote:
> Mainly aux communications on sink_crc
> were failing a lot randomly on recen
This series implement support to a drm_dp_aux chardev that allows reading and
writing an arbitrary amount of bytes to arbitrary dpcd register addresses using
regular read, write and lseek operations.
Rafael Antognolli (3):
drm/kms_helper: Add a common place to call init and exit functions.
drm
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 respective sysfs /sys/class/drm_aux_dev/drm_dp_auxN/connector, if
the connector
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
allowing one to get the drm_device from it. Some drivers already set it
to the dr
The module_init and module_exit functions will start here, and call the
subsequent init's and exit's.
Signed-off-by: Rafael Antognolli
---
drivers/gpu/drm/Makefile| 4 ++-
drivers/gpu/drm/drm_fb_helper.c | 9 +++
drivers/gpu/drm/drm_kms_helper_common.c | 43
On Thu, 2015-12-03 at 17:59 -0200, Paulo Zanoni wrote:
> 2015-12-03 17:44 GMT-02:00 Vivi, Rodrigo :
> > On Thu, 2015-12-03 at 15:05 -0200, Paulo Zanoni wrote:
> > > 2015-12-03 14:39 GMT-02:00 Rodrigo Vivi :
> > > > Even with all sink crc re-works we still have platforms
> > > > where after 6 vblank
Hi!
> Reported-by: Jens Axboe
> Link: https://lkml.org/lkml/2015/11/12/621
> Cc: Jens Axboe
> Cc; "Rogozhkin, Dmitry V"
> Cc: Daniel Vetter
> Cc: Tvrtko Ursulin
> Cc: Eero Tamminen
> Cc: "Rantala, Valtteri"
> Cc: sta...@kernel.vger.org
> ---
> drivers/gpu/drm/i915/i915_gem.c | 28 +
Hi,
On Thu, Dec 03, 2015 at 11:25:48PM +0200, Ville Syrjälä wrote:
> On Thu, Dec 03, 2015 at 10:08:05PM +0100, Takashi Iwai wrote:
> > On Thu, 03 Dec 2015 21:33:29 +0100,
> > Ville Syrjälä wrote:
> > >
> > > On Thu, Dec 03, 2015 at 09:00:55PM +0100, Takashi Iwai wrote:
> > > > Hi,
> > > >
> > >
On Thu, Dec 03, 2015 at 11:25:48PM +0200, Ville Syrjälä wrote:
> On Thu, Dec 03, 2015 at 10:08:05PM +0100, Takashi Iwai wrote:
> > On Thu, 03 Dec 2015 21:33:29 +0100,
> > Ville Syrjälä wrote:
> > >
> > > On Thu, Dec 03, 2015 at 09:00:55PM +0100, Takashi Iwai wrote:
> > > > Hi,
> > > >
> > > > I'v
On Thu, Dec 03, 2015 at 10:08:05PM +0100, Takashi Iwai wrote:
> On Thu, 03 Dec 2015 21:33:29 +0100,
> Ville Syrjälä wrote:
> >
> > On Thu, Dec 03, 2015 at 09:00:55PM +0100, Takashi Iwai wrote:
> > > Hi,
> > >
> > > I've experienced a few graphics issues recently, and I tend to believe
> > > that
On Wed, Dec 02, 2015 at 09:13:46AM +, Chris Wilson wrote:
> In commit 2e1b873072dfe3bbcc158a9c21acde1ab0d36c55 [v4.2]
> Author: Chris Wilson
> Date: Mon Apr 27 13:41:22 2015 +0100
>
> drm/i915: Convert RPS tracking to a intel_rps_client struct
>
> we converted the __i915_wait_request()
On Thu, 03 Dec 2015 21:33:29 +0100,
Ville Syrjälä wrote:
>
> On Thu, Dec 03, 2015 at 09:00:55PM +0100, Takashi Iwai wrote:
> > Hi,
> >
> > I've experienced a few graphics issues recently, and I tend to believe
> > that it has happened since 4.4-rc. Namely, after some long time usage
> > on my HS
On Thu, Dec 03, 2015 at 09:00:55PM +0100, Takashi Iwai wrote:
> Hi,
>
> I've experienced a few graphics issues recently, and I tend to believe
> that it has happened since 4.4-rc. Namely, after some long time usage
> on my HSW laptop (two or three days), the mouse cursor vanished
> suddenly. It
Hi,
I've experienced a few graphics issues recently, and I tend to believe
that it has happened since 4.4-rc. Namely, after some long time usage
on my HSW laptop (two or three days), the mouse cursor vanished
suddenly. It kept pointing but just became invisible. Also, after
some S3 cycles, some
2015-12-03 17:44 GMT-02:00 Vivi, Rodrigo :
> On Thu, 2015-12-03 at 15:05 -0200, Paulo Zanoni wrote:
>> 2015-12-03 14:39 GMT-02:00 Rodrigo Vivi :
>> > Even with all sink crc re-works we still have platforms
>> > where after 6 vblanks it is unable to calculate the
>> > sink crc. But if we don't get t
On Thu, 2015-12-03 at 15:05 -0200, Paulo Zanoni wrote:
> 2015-12-03 14:39 GMT-02:00 Rodrigo Vivi :
> > Even with all sink crc re-works we still have platforms
> > where after 6 vblanks it is unable to calculate the
> > sink crc. But if we don't get the sink crc it isn't true
> > that test failed, b
Because just running dim help doesn't give you the greater picture of
the workflow. All the text here is based on an email written by Daniel
Vetter, so the credits go to him. Any mistakes were introduced by me.
Credits-to: Daniel Vetter
Signed-off-by: Paulo Zanoni
---
dim.rst | 58 +
Today I applied/pushed patches for the first time, and noticed that
all my commits had exactly this:
Link: http://patchwork.freedesktop.org/patch/msgid/
without the actual ID there. I assumed the ID would be set by some
commit hook since our hooks seem to be able to talk to patchwork.
Looks lik
Although we can do a good job of reading out hardware state, the
graphics firmware may have programmed the watermarks in a creative way
that doesn't match how i915 would have chosen to program them. We
shouldn't trust the firmware's watermark programming, but should rather
re-calculate how we thin
Our low-level watermark calculation functions don't get called when the
CRTC is disabled or the relevant plane is invisible, so they should
never see a zero htotal or zero bpp. However add some checks to ensure
this is true so that we don't wind up dividing by zero if we make a
mistake elsewhere i
The plane information isn't important in most of the places where we
dump the pipe config; the one place where it would be valuable is during
initial HW state readout, but currently we dump the pipe config before
FB's are reconstructed, so the data dumped is misleading anyway. Even
worse, in place
When watermark calculation was moved up to the atomic check phase, the
code was updated to calculate based on in-flight atomic state rather
than already-committed state. However the hsw_compute_linetime_wm()
didn't get updated and continued to pull values out of the
currently-committed CRTC state.
Plane state objects contain two copies of src/dest coordinates: the
original (requested by userspace) coordinates in the base
drm_plane_state object, and a second, clipped copy (i.e., what we
actually want to program to the hardware) in intel_plane_state. We've
only been setting up the former set
If we fail to reconstruct the BIOS fb (e.g., because the FB is too
large), we'll be left with plane state that indicates the primary plane
is visible yet has a NULL fb. This mismatch causes problems later on
(e.g., for the watermark code). Since we've failed to reconstruct the
BIOS FB, the best s
In addition to calculating final watermarks, let's also pre-calculate a
set of intermediate watermark values at atomic check time. These
intermediate watermarks are a combination of the watermarks for the old
state and the new state; they should satisfy the requirements of both
states which means
Previous patch series was here:
http://lists.freedesktop.org/archives/intel-gfx/2015-November/081270.html
The changes since the last version are mainly minor fixes based on review
feedback from Ville and Maarten.
Matt Roper (7):
drm/i915: Disable primary plane if we fail to reconstruct BIOS
On Thu, Dec 03, 2015 at 01:06:44PM +0100, Maarten Lankhorst wrote:
> Op 25-11-15 om 17:48 schreef Matt Roper:
> > Plane state objects contain two copies of src/dest coordinates: the
> > original (requested by userspace) coordinates in the base
> > drm_plane_state object, and a second, clipped copy
2015-12-03 14:39 GMT-02:00 Rodrigo Vivi :
> Even with all sink crc re-works we still have platforms
> where after 6 vblanks it is unable to calculate the
> sink crc. But if we don't get the sink crc it isn't true
> that test failed, but that we have no ways to say test
> passed or failed.
>
> So le
2015-12-03 14:39 GMT-02:00 Rodrigo Vivi :
> Unfortunately Sink CRC is not 100% reliable for all platforms.
> So we cannot block FBC tests nor skip them when we are getting
> unreliable Sink CRC results, or not getting them at all.
>
> Cc: Paulo Zanoni
> Signed-off-by: Rodrigo Vivi
> ---
> tests/
On Tue, 01 Dec 2015 17:09:57 +0100,
Takashi Iwai wrote:
>
> The ELD notification can be received asynchronously from the graphics
> side, and this may happen just at the moment the sound driver is
> processing the suspend or the resume, and it would confuse the whole
> procedure. Since the ELD an
Hi,
On 03/12/15 08:36, Vinay Belgaumkar wrote:
These tests exercise the userptr ioctl to create shared buffers
between CPU and GPU. They contain error and normal usage scenarios.
They also contain a couple of stress tests which copy buffers between
CPU and GPU. These tests rely on the softpin p
These tests exercise the userptr ioctl to create shared buffers
between CPU and GPU. They contain error and normal usage scenarios.
They also contain a couple of stress tests which copy buffers between
CPU and GPU. These tests rely on the softpin patch in order to pin buffers
to a certain VA.
Cave
One particularly stressful scenario consists of many independent tasks
all competing for GPU time and waiting upon the results (e.g. realtime
transcoding of many, many streams). One bottleneck in particular is that
each client waits on its own results, but every client is woken up after
every batch
> >>> commit e7d6f7d708290da1b7c92f533444b042c79412e0
> >>> Author: Dave Airlie
> >>> Date: Mon Dec 8 13:23:37 2014 +1000
> >>>
> >>> drm/i915: resume MST after reading back hw state
> >> Is there anything else what I can do ?
> >>
> >> Current kernels up to 4.2.3 and 4.3-rc3 (not harde
On Mon, Nov 23, 2015 at 10:32:45AM +0100, Daniel Vetter wrote:
> @@ -957,11 +955,9 @@ static int armada_drm_crtc_cursor_move(struct drm_crtc
> *crtc, int x, int y)
> if (!dcrtc->variant->has_spu_adv_reg)
> return -EFAULT;
>
> - mutex_lock(&dev->struct_mutex);
> dcrt
On 06/10/15 12:53, Chris Wilson wrote:
On Tue, Oct 06, 2015 at 12:21:05PM +0100, Dave Gordon wrote:
... although I still think my version is (slightly) easier to read.
Or it could be improved even more by moving the increment of 'iter'
to the end, making it one line shorter and perhaps helping t
Hi Dave -
Another batch of drm/i915 fixes for v4.4, on top of the ones from
earlier this week. One timeout handling regression fix from Chris, and
backport of five patches from our -next to fix a power management
related HDMI hotplug regression.
BR,
Jani.
The following changes since commit 2540
On Thu, Dec 03, 2015 at 01:49:13PM +0100, Maarten Lankhorst wrote:
> This removes pre/post_wm_update from intel_crtc->atomic, and
> creates atomic state for it in intel_crtc.
>
> Changes since v1:
> - Rebase on top of wm changes.
> Changes since v2:
> - Split disable_cxsr into a separate patch
This removes pre/post_wm_update from intel_crtc->atomic, and
creates atomic state for it in intel_crtc.
Changes since v1:
- Rebase on top of wm changes.
Changes since v2:
- Split disable_cxsr into a separate patch.
Changes since v3:
- Move some of the changes to intel_wm_need_update.
Signed-o
On 3 December 2015 at 12:17, Morton, Derek J wrote:
> 1 comment / question inline, otherwise looks ok to me.
>
> //Derek
>
>>
>>
>>-Original Message-
>>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>>Thomas Wood
>>Sent: Thursday, December 3, 2015 11:31 AM
>
Op 25-11-15 om 17:48 schreef Matt Roper:
> We dump during HW state readout, but that's too early to reflect how the
> primary plane is actually configured.
>
> In the future it would be nice if we could just read out HW state and
> reconstruct FB's at the same point, but at the moment we don't have
Op 25-11-15 om 17:48 schreef Matt Roper:
> During state dumping, list planes that have an FB but are invisible
> (e.g., because they're offscreen or clipped by other planes) as "not
> visible" rather than "enabled." While we're at it, dump the FB format
> as a human-readable string rather than a h
Op 25-11-15 om 17:48 schreef Matt Roper:
> The intel_dump_pipe_config() always dumps the currently active plane
> state for each plane on a CRTC. If we're calling this function to dump
> CRTC state that is in-flight (not yet active), then this mismatch can be
> misleading and confusing. Let's pay
1 comment / question inline, otherwise looks ok to me.
//Derek
>
>
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Thomas Wood
>Sent: Thursday, December 3, 2015 11:31 AM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH
Signed-off-by: Thomas Wood
---
tests/.gitignore | 13 +++--
tests/Makefile.am | 4
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/tests/.gitignore b/tests/.gitignore
index ba1becd..9dfc7f3 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -1,7 +1,6 @@
-# Plea
Hi,
On 02/12/15 09:24, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
This patch verifies if the contents of the stolen backed object were
preserved across hibernation. This is to validate kernel changes related
to moving stolen-backed objects to shmem on hibernation.
Signed-
Op 25-11-15 om 17:48 schreef Matt Roper:
> Plane state objects contain two copies of src/dest coordinates: the
> original (requested by userspace) coordinates in the base
> drm_plane_state object, and a second, clipped copy (i.e., what we
> actually want to program to the hardware) in intel_plane_
Hi,
On 02/12/15 12:24, Vinay Belgaumkar wrote:
These tests exercise the userptr ioctl to create shared buffers
between CPU and GPU. They contain error and normal usage scenarios.
They also contain a couple of stress tests which copy buffers between
CPU and GPU. These tests rely on the softpin p
Signed-off-by: Thomas Wood
---
tests/check_drm_clients | 2 +-
tests/debugfs_emon_crash | 2 +-
tests/drm_lib.sh | 22 ++
tests/drv_debugfs_reader | 2 +-
tests/drv_missed_irq_hang | 14 +++---
tests/drv_module_reload_basic | 8
Op 25-11-15 om 17:48 schreef Matt Roper:
> If we fail to reconstruct the BIOS fb (e.g., because the FB is too
> large), we'll be left with plane state that indicates the primary plane
> is visible yet has a NULL fb. This mismatch causes problems later on
> (e.g., for the watermark code). Since we
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
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
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
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
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.
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 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
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
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
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
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
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 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
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 +++
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
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
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
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
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 +
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 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
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
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
On 3 December 2015 at 10:46, Morton, Derek J wrote:
>>
>>
>>-Original Message-
>>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>>Thomas Wood
>>Sent: Thursday, December 3, 2015 10:08 AM
>>To: Daniel Vetter
>>Cc: Intel Graphics Development
>>Subject: Re: [Int
On Thu, Dec 03, 2015 at 12:37:20PM +0200, Ville Syrjälä wrote:
> On Thu, Dec 03, 2015 at 09:02:12AM +0100, Daniel Vetter wrote:
> > On Wed, Nov 25, 2015 at 04:35:31PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > DPLL_SDVO_HIGH_SPEED must be set for SDVO/H
2015-12-03 8:03 GMT-02:00 Ville Syrjälä :
> On Wed, Dec 02, 2015 at 11:35:00AM -0200, Paulo Zanoni wrote:
>> 2015-12-01 11:08 GMT-02:00 :
>> > From: Ville Syrjälä
>> >
>> > When we want to use SPLL for FDI we want SSC, which means we have to
>> > disable clock bending for the PCH SSC reference (b
Op 03-12-15 om 10:53 schreef Daniel Vetter:
> On Tue, Nov 24, 2015 at 10:34:36AM +0100, Maarten Lankhorst wrote:
>> This allows iteration over encoders without requiring connection_mutex.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/drm_atomic_helper.c | 4
>> drivers/gp
>
>
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Thomas Wood
>Sent: Thursday, December 3, 2015 10:08 AM
>To: Daniel Vetter
>Cc: Intel Graphics Development
>Subject: Re: [Intel-gfx] [PATCH i-g-t 2/3] tests/drm_lib.sh: Skip when i915
>d
On Thu, Dec 03, 2015 at 09:02:12AM +0100, Daniel Vetter wrote:
> On Wed, Nov 25, 2015 at 04:35:31PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > DPLL_SDVO_HIGH_SPEED must be set for SDVO/HDMI/DP, but nowhere is it
> > forbidden to set it for LVDS/CRT as well. So let
On Wed, Dec 02, 2015 at 03:16:56PM -0200, Paulo Zanoni wrote:
> 2015-12-01 11:08 GMT-02:00 :
> > From: Ville Syrjälä
> >
> > Currently we disable some parts of FDI setup after a failed link
> > training. But despite that we continue with the modeset as if everything
> > is fine. This results in t
On Wed, Dec 02, 2015 at 03:02:20PM -0200, Paulo Zanoni wrote:
> 2015-12-01 11:08 GMT-02:00 :
> > From: Ville Syrjälä
> >
> > Currently we leave the LPT-H VGA dotclock running after turning
> > the pipe/fdi/port/etc. Propoerly disable the VGA dotclock as
>
> s/Propoerly/Properly/
>
> (DId you al
On Wed, Dec 02, 2015 at 02:56:01PM -0200, Paulo Zanoni wrote:
> 2015-12-01 11:08 GMT-02:00 :
> > From: Ville Syrjälä
> >
> > Extract the LPT-H VGA dotclock disable to a separate function in
> > anticipation of further use.
> >
> > While at it move the sb_lock locking inwards when enabling the VGA
On Wed, Dec 02, 2015 at 12:01:43PM -0200, Paulo Zanoni wrote:
> 2015-12-01 11:08 GMT-02:00 :
> > From: Ville Syrjälä
> >
> > Bspec modeset sequence tells us to disable the PCH transcoder and
> > FDI after the CRT port on LPT-H, so let's do that.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> >
On 3 December 2015 at 06:45, Daniel Vetter wrote:
> Instead of failing. We might want to move this into i915 tests
> eventually, but this is good for now.
>
> Signed-off-by: Daniel Vetter
> ---
> tests/drm_lib.sh | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/test
On Wed, Dec 02, 2015 at 11:35:00AM -0200, Paulo Zanoni wrote:
> 2015-12-01 11:08 GMT-02:00 :
> > From: Ville Syrjälä
> >
> > When we want to use SPLL for FDI we want SSC, which means we have to
> > disable clock bending for the PCH SSC reference (bend and spread are
> > mtutually exclusive). So l
On Tue, Nov 24, 2015 at 10:34:36AM +0100, Maarten Lankhorst wrote:
> This allows iteration over encoders without requiring connection_mutex.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 4
> drivers/gpu/drm/i915/intel_display.c | 3 +++
> include/drm/d
On Thu, Dec 03, 2015 at 10:49:14AM +0100, Daniel Vetter wrote:
> This can happen when we run out of encoders for a multi-crtc modeset,
> or also when userspace is silly and tries to clone multiple connectors
> that need the same encoder on the same crtc.
>
> Reported-and-Tested-and-Reviewed-by: Ma
This can happen when we run out of encoders for a multi-crtc modeset,
or also when userspace is silly and tries to clone multiple connectors
that need the same encoder on the same crtc.
Reported-and-Tested-and-Reviewed-by: Maarten Lankhorst
Cc: Maarten Lankhorst
Signed-off-by: Daniel Vetter
--
On Wed, Dec 02, 2015 at 05:02:07PM -0800, Yu Dai wrote:
> I tested this with GuC submission enabled and it fixes the issue I found
> during GPU reset.
>
> Reviewed-by: Alex Dai
Queued for -next, thanks for the patch.
-Daniel
>
> On 12/01/2015 06:48 AM, Nick Hoath wrote:
> >Use the first retire
On Thu, Dec 03, 2015 at 10:14:54AM +0100, Daniel Vetter wrote:
> > @@ -4078,9 +4067,9 @@ i915_gem_ring_throttle(struct drm_device *dev, struct
> > drm_file *file)
> > if (ret)
> > return ret;
> >
> > - ret = i915_gem_check_wedge(&dev_priv->gpu_error, false);
> > - if (ret)
>
Two reasons for that:
- This changes aligns atomic with the legacy page flip semantics as
established by the i915 driver.
- Asking for an async flip on a disabled pipe generally indicates a
userspace bug. Worst case userspace will busy-loop rendering (since
flips complete immediately). So be
On Thu, Dec 03, 2015 at 09:02:16AM +, Chris Wilson wrote:
> On Thu, Dec 03, 2015 at 09:57:01AM +0100, Daniel Vetter wrote:
> > On Tue, Dec 01, 2015 at 11:05:33AM +, Chris Wilson wrote:
> > > This is just a little bit of syntatic sugar to hide the atomic_reads()
> > > throughout the code to
On Tue, Dec 01, 2015 at 11:05:35AM +, Chris Wilson wrote:
> Reporting -EIO from i915_wait_request() has proven very troublematic
> over the years, with numerous hard-to-reproduce bugs cropping up in the
> corner case of where a reset occurs and the code wasn't expecting such
> an error.
>
> If
On Thu, Dec 03, 2015 at 09:57:01AM +0100, Daniel Vetter wrote:
> On Tue, Dec 01, 2015 at 11:05:33AM +, Chris Wilson wrote:
> > This is just a little bit of syntatic sugar to hide the atomic_reads()
> > throughout the code to retrieve the current reset_counter. It also
> > provides the other uti
1 - 100 of 106 matches
Mail list logo
