On Wed, Jul 08, 2015 at 03:05:49PM -0300, Paulo Zanoni wrote:
2015-07-07 20:28 GMT-03:00 Rodrigo Vivi rodrigo.v...@intel.com:
This fbdev restore mode was another corner case that was now
calling frontbuffer flip and flush and making we miss
screen updates with PSR enabled.
So let's also
Hi Dave,
Non-i915 fixes I picked up in your absence: kerneldoc + 2x cc: stable. The
rockchip fix is just in here to make sure it won't get lost, I kept it
since I didn't yet see a rockchip fixes pull nor confirmation from Mark
that he pulled it into his tree.
Cheers, Daniel
The following
The hang checker needs to inspect whether or not the ring request list is empty
as well as if the given engine has reached or passed the most recently
submitted request. The problem with this is that the hang checker cannot grab
the struct_mutex, which is required in order to safely inspect
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6762
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On Thu, Jul 09, 2015 at 10:04:20AM -0300, Paulo Zanoni wrote:
2015-07-08 20:22 GMT-03:00 Rodrigo Vivi rodrigo.v...@intel.com:
Let's do a frontbuffer flush on dirty fb.
To be used for DIRTYFB drm ioctl.
This patch solves the biggest PSR known issue, that is
missed screen updates during
Hi Dave,
Pile of fixes for either 4.2 issues or cc: stable. This should fix the 2nd
kind of WARNING Linus's been seeing, please ask him to scream if that's
not the case.
Cheers, Daniel
The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
Linux 4.2-rc1 (2015-07-05
On Thu, Jul 09, 2015 at 03:30:57PM +0100, Tomas Elf wrote:
The hang checker needs to inspect whether or not the ring request list is
empty
as well as if the given engine has reached or passed the most recently
submitted request. The problem with this is that the hang checker cannot grab
the
Siluvery, Arun arun.siluv...@linux.intel.com writes:
On 07/07/2015 20:13, Francisco Jerez wrote:
From: Peter Antoine peter.anto...@intel.com
This change adds the programming of the MOCS registers to the gen 9+
platforms. This change set programs the MOCS register values to a set
of values
On Thu, Jul 09, 2015 at 06:22:01PM +0530, Sivakumar Thulasimani wrote:
On 7/8/2015 8:50 PM, Daniel Vetter wrote:
On Wed, Jul 08, 2015 at 06:54:06PM +0530, Sivakumar Thulasimani wrote:
On 7/7/2015 5:01 PM, Daniel Vetter wrote:
On Tue, Jul 07, 2015 at 04:10:49PM +0530, Sivakumar
On Wed, Jul 08, 2015 at 11:45:59PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Currently we relesar the lane soft reset before lane stagger settings
release
have been programmed. I believe that means we don't actually do lane
On Wed, Jul 08, 2015 at 05:58:58PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
I could only find the restrictions for HSW+, but I think it's safe to
assume that the older platforms also can't support the configurations
HSW can't support. The older platforms
On Thu, Jul 09, 2015 at 07:10:04PM +0200, Daniel Vetter wrote:
On Wed, Jul 08, 2015 at 05:58:57PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
The doc is pretty clear that this register should be set to 0 on SNB.
We already write y_offset to
2015-07-09 14:15 GMT-03:00 Daniel Vetter dan...@ffwll.ch:
On Wed, Jul 08, 2015 at 05:58:58PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
I could only find the restrictions for HSW+, but I think it's safe to
assume that the older platforms also can't support the
On Thu, 2015-07-09 at 10:10 -0300, Paulo Zanoni wrote:
2015-07-08 20:24 GMT-03:00 Rodrigo Vivi rodrigo.v...@intel.com:
fbdev_set_par is called when fbcon is taking over control.
In the past frontbuffer was being invalidated on
set_to_gtt_domain, but it moved to set_domain fixing that case,
On Thu, Jul 09, 2015 at 04:07:05PM +0100, Chris Wilson wrote:
On Thu, Jul 09, 2015 at 03:30:57PM +0100, Tomas Elf wrote:
The hang checker needs to inspect whether or not the ring request list is
empty
as well as if the given engine has reached or passed the most recently
submitted
On 07/09/2015 03:57 AM, 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 the request
fbdev_set_par is called when fbcon is taking over control.
In the past frontbuffer was being invalidated on
set_to_gtt_domain, but it moved to set_domain fixing that case,
but left this behind.
Commit that changed this fixing set_domain case was:
commit 031b698a77a70a6c394568034437b5486a44e868
On Wed, Jul 08, 2015 at 05:58:57PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
The doc is pretty clear that this register should be set to 0 on SNB.
We already write y_offset to DPFC_CPU_FENCE_OFFSET a few lines below.
Signed-off-by: Paulo Zanoni
From: Ville Syrjälä ville.syrj...@linux.intel.com
Currently we release the lane soft reset before lane stagger settings
have been programmed. I believe that means we don't actually do lane
staggering. So move the soft reset deassert to happen after lane
staggering has been programmed.
The one
On Thu, Jul 09, 2015 at 05:00:57PM +, Rodrigo Vivi wrote:
ops... Sorry..
I could swear I had added this... or probably forgot to send the version
that had it...
Anyway:
Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
On Thu, Jul 09, 2015 at 05:34:29PM +0530, Sonika Jindal wrote:
Adding this for SKL onwards.
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
I think this is the critical piece really, and I'd like to roll it out for
all platforms. git has the code for all the old ones, so no big deal to
ops... Sorry..
I could swear I had added this... or probably forgot to send the version
that had it...
Anyway:
Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com
On Wed, Jul 8, 2015 at 2:09 PM Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Reported by the
From: Paulo Zanoni paulo.r.zan...@intel.com
This test should test the interactions between fbcon and the
frontbuffer tracking infrastructure.
Right now the PSR test fails, but as soon as we merge the following
kernel patches, the test wills tart passing:
- drm/i915: PSR: Flush means invalidate
2015-07-09 14:10 GMT-03:00 Daniel Vetter dan...@ffwll.ch:
On Wed, Jul 08, 2015 at 05:58:57PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
The doc is pretty clear that this register should be set to 0 on SNB.
We already write y_offset to DPFC_CPU_FENCE_OFFSET a few
On Wed, Jul 08, 2015 at 06:08:39PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Reported by the kbuild test robot.
Regression introduced by:
commit fdbff9282c0f5f61ffc87d57461b04d943250910
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Thu Jun 18 11:23:24
2015-07-09 14:15 GMT-03:00 Paulo Zanoni przan...@gmail.com:
2015-07-09 14:10 GMT-03:00 Daniel Vetter dan...@ffwll.ch:
On Wed, Jul 08, 2015 at 05:58:57PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
The doc is pretty clear that this register should be set to 0 on SNB.
On Wed, Jul 08, 2015 at 07:54:47PM +0530, Animesh Manna wrote:
Signed-off-by: Animesh Manna animesh.ma...@intel.com
---
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
On Wed, Jul 08, 2015 at 07:54:44PM +0530, Animesh Manna wrote:
v1: As per review comments from Daniel, replaced async firmware
loading with request_firmware() which will load the dmc firmware and
once firmware is loaded, dc5/dc6 register programming can be done
in the same thread.
From: Alex Dai yu@intel.com
The new node provides access to the status of the GuC-specific loader;
also the scratch registers used for communication between the i915
driver and the GuC firmware.
v2:
Changes to output formats per Chris Wilson's suggestions
v4:
Rebased
Issue:
From: Alex Dai yu@intel.com
Two new module parameters: enable_guc_submission which will turn
on submission of batchbuffers via the GuC (when implemented), and
guc_log_level which controls the level of debugging logged by the
GuC and captured by the host.
Signed-off-by: Alex Dai
From: Alex Dai yu@intel.com
Allocate a GEM object to hold GuC log data. A debugfs interface
(i915_guc_log_dump) is provided to print out the log content.
v2:
Add struct members at point of use [Chris Wilson]
v4:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai yu@intel.com
i915_gem_object_create_from_data() is a generic function to save data
from a plain linear buffer in a new pageable gem object that can later
be accessed by the CPU and/or GPU.
We will need this for the microcontroller firmware loading support code.
Derived from i915_gem_object_write(),
On Wed, Jul 08, 2015 at 07:54:42PM +0530, Animesh Manna wrote:
v1: As per review comments from Daniel, removed the csr-lock
and csr-state which was used before in dmc firmware loading.
Planning to have a single async task which will responsible
for firmware loading and register programming for
2015-07-08 20:25 GMT-03:00 Rodrigo Vivi rodrigo.v...@intel.com:
This fbdev restore mode was another corner case that was now
calling frontbuffer flip and flush and making we miss
screen updates with PSR enabled.
So let's also add the invalidate hack here while we don't have
a reliable dirty
On Thu, Jul 09, 2015 at 02:31:15PM -0300, Paulo Zanoni wrote:
2015-07-09 14:22 GMT-03:00 Ville Syrjälä ville.syrj...@linux.intel.com:
On Thu, Jul 09, 2015 at 07:10:04PM +0200, Daniel Vetter wrote:
On Wed, Jul 08, 2015 at 05:58:57PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni
A GuC client has its own doorbell and workqueue. It maintains the
doorbell cache line, process description object and work queue item.
A default guc_client is created for the i915 driver to use for
normal-priority in-order submission.
Note that the created client is not yet ready for use;
Turn on interrupt steering to route necessary interrupts to GuC.
v4:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai yu@intel.com
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 11 +--
drivers/gpu/drm/i915/intel_guc_loader.c | 51
From: Alex Dai yu@intel.com
GuC-based submission is mostly the same as execlist mode, up to
intel_logical_ring_advance_and_submit(), where the context being
dispatched would be added to the execlist queue; at this point
we submit the context to the GuC backend instead.
There are, however, a
Signed-off-by: Dave Gordon david.s.gor...@intel.com
v4:
Rebased
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
From: Alex Dai yu@intel.com
This fetches the required firmware image from the filesystem,
then loads it into the GuC's memory via a dedicated DMA engine.
This patch is derived from GuC loading work originally done by
Vinit Azad and Ben Widawsky.
v2:
Various improvements per review
This patch series enables command submission via the GuC. In this mode,
instead of the host CPU driving the execlist port directly, it hands
over work items to the GuC, using a doorbell mechanism to tell the GuC
that new items have been added to its work queue. The GuC then dispatches
contexts to
From: Alex Dai yu@intel.com
This adds the first of the data structures used to communicate with the
GuC (the pool of guc_context structures).
We create a GuC-specific wrapper round the GEM object allocator as all
GEM objects shared with the GuC must be pinned into GGTT space at an
address
intel_guc_fwif.h contains the subset of the GuC interface that we
will need for submission of commands through the GuC. These MUST
be kept in sync with the definitions used by the GuC firmware, and
updates to this file will (or should) be autogenerated from the
source files used to build the
GuC submission is basically execlist submission, but with the GuC
handling the actual writes to the ELSP and the resulting context
switch interrupts. So to prepare a context for submission via the
GuC, we need some of the same functions used in execlist mode.
This commit exposes two such
This provides a means of reading status and counts relating
to GuC actions and submissions.
v2:
Remove surplus blank line in output [Chris Wilson]
v4:
Rebased
Signed-off-by: Dave Gordon david.s.gor...@intel.com
Signed-off-by: Alex Dai yu@intel.com
---
Those FIXME are for atomic fb ops callbacks what I don't believe that applies
for this case.
-Original Message-
From: Paulo Zanoni [mailto:przan...@gmail.com]
Sent: Thursday, July 09, 2015 11:54 AM
To: Vivi, Rodrigo
Cc: Intel Graphics Development; Zanoni, Paulo R
Subject: Re:
2015-07-09 13:56 GMT-03:00 Rodrigo Vivi rodrigo.v...@intel.com:
fbdev_set_par is called when fbcon is taking over control.
In the past frontbuffer was being invalidated on
set_to_gtt_domain, but it moved to set_domain fixing that case,
but left this behind.
Commit that changed this fixing
2015-07-09 14:22 GMT-03:00 Ville Syrjälä ville.syrj...@linux.intel.com:
On Thu, Jul 09, 2015 at 07:10:04PM +0200, Daniel Vetter wrote:
On Wed, Jul 08, 2015 at 05:58:57PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
The doc is pretty clear that this register should
On Wed, Jul 08, 2015 at 07:54:45PM +0530, Animesh Manna wrote:
Firmware loading can be optimized by setting the dmc_present flag
for the first time and later internallly stored firmware data
can be used.
Signed-off-by: Animesh Manna animesh.ma...@intel.com
---
On Mon, Jun 08, 2015 at 06:03:18PM +0100, Tomas Elf wrote:
This patch series introduces the following features:
* Feature 1: TDR (Timeout Detection and Recovery) for gen8 execlist mode.
* Feature 2: Watchdog Timeout (a.k.a media engine reset) for gen8.
* Feature 3. Context Submission Status
On 7/9/2015 10:57 PM, Daniel Vetter wrote:
On Thu, Jul 09, 2015 at 05:34:29PM +0530, Sonika Jindal wrote:
Adding this for SKL onwards.
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
I think this is the critical piece really, and I'd like to roll it out for
all platforms. git has the
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/i915_drv.h
between commit:
8146ba1637a7 (drm/i915: Store device pointer in contexts for late tracepoint
usafe)
from the drm-intel-fixes tree and commit:
b1b38278e12b (drm/i915: add a context
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/intel_ringbuffer.h
between commit:
ee412ecc74c4 (drm/i915: Snapshot seqno of most recently submitted request.)
from the drm-intel-fixes tree and commit:
bccca494f75c (drm/i915: Remove the now
This set of patches cleans up a number of issues that
were pushed out in the initial execlist submission.
Nick Hoath (5):
drm/i915: Clean up gen8 irq handler
drm/i915: Unify execlist and legacy request life-cycles
drm/i915: Simplify runtime_pm reference for execlists
drm/i915: Reorder
Clean up lrc context init by:
- Move context initialisation in to i915_gem_init_hw
- Move one off initialisation for render ring to
i915_gem_validate_context
- Move default context initialisation to logical_ring_init
Rename intel_lr_context_deferred_create to
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.
Added a
Moved common code handling command streamer interrupts into a function.
Renamed tmp variable to the more descriptive iir.
Signed-off-by: Thomas Daniel thomas.dan...@intel.com
Signed-off-by: Nick Hoath nicholas.ho...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 68
Issue: VIZ-4798
Signed-off-by: Nick Hoath nicholas.ho...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 86
1 file changed, 43 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index
No longer take a runtime_pm reference for each execlist request. Only
take a single reference when the execlist queue becomes nonempty and
release it when it becomes empty.
Signed-off-by: Thomas Daniel thomas.dan...@intel.com
Signed-off-by: Nick Hoath nicholas.ho...@intel.com
---
On Thu, Jul 09, 2015 at 11:57:40AM +0100, Nick Hoath wrote:
Moved common code handling command streamer interrupts into a function.
Renamed tmp variable to the more descriptive iir.
Does the compiler eliminate those shifts you added?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Thu, Jul 09, 2015 at 11:57:41AM +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 the
On Thu, Jul 09, 2015 at 11:57:42AM +0100, Nick Hoath wrote:
No longer take a runtime_pm reference for each execlist request. Only
take a single reference when the execlist queue becomes nonempty and
release it when it becomes empty.
Nak. We already hold the runtime_pm for GPU activity.
-Chris
On Thu, Jul 09, 2015 at 11:57:44AM +0100, Nick Hoath wrote:
Clean up lrc context init by:
- Move context initialisation in to i915_gem_init_hw
- Move one off initialisation for render ring to
i915_gem_validate_context
- Move default context initialisation to logical_ring_init
On 2015.07.09 13:50:14 +0800, Zhenyu Wang wrote:
GT-Pin has got new kit release (5923). As GT-Pin team has built auto testing
system for GT-Pin on Linux, we now have aligned kit release regularly.
Please check wiki page for details and the link to download the kit.
On Mon, Jun 29, 2015 at 02:01:19PM +0100, Chris Wilson wrote:
The old style of memory interleaving swizzled upto the end of the
first even bank of memory, and then used the remainder as unswizzled on
the unpaired bank - i.e. swizzling is not constant for all memory. This
causes problems when
Signed-off-by: Martin Peres martin.pe...@linux.intel.com
---
src/compat-api.h | 4
1 file changed, 4 insertions(+)
diff --git a/src/compat-api.h b/src/compat-api.h
index aa93bee..1ca4380 100644
--- a/src/compat-api.h
+++ b/src/compat-api.h
@@ -247,3 +247,7 @@ static inline void
Signed-off-by: Martin Peres martin.pe...@linux.intel.com
---
src/sna/sna_dri2.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/sna/sna_dri2.c b/src/sna/sna_dri2.c
index 47bc046..1f34ebe 100644
--- a/src/sna/sna_dri2.c
+++ b/src/sna/sna_dri2.c
@@ -3605,11
On Thu, Jul 09, 2015 at 11:26:38AM +0300, Martin Peres wrote:
Signed-off-by: Martin Peres martin.pe...@linux.intel.com
I would prefer this to be testing for the unstable release that
introduces the ABI change (i.e. rather than =), but it fixes the
build from git today and you said you would
Hi,
I'm hitting a NULL pointer dereference when I enable the
i915_context_free tracepoint (call trace attached). This is caused by
the fact that the trace tries to access ctx-file_priv, which however
may have already been deleted (even if the pointer is != NULL). I've
used that trace
On Thu, Jul 09, 2015 at 10:08:08AM +0100, Ceraolo Spurio, Daniele wrote:
Hi,
I'm hitting a NULL pointer dereference when I enable the
i915_context_free tracepoint (call trace attached). This is caused
by the fact that the trace tries to access ctx-file_priv, which
however may have already
From: Shashank Sharma shashank.sha...@intel.com
This patch adds a separate probe function for HDMI
EDID read over DDC channel. This function has been
registered as a .hot_plug handler for HDMI encoder.
The reason behind addition of this separate function needs
brief explaination. The current
From: Shashank Sharma shashank.sha...@intel.com
This patch adds the intel_connector initialized to intel_hdmi
display, during the init phase, just like the other encoders do.
This attachment is very useful when we need to extract the connector
pointer during the hotplug handler function
During init_connector set the edid, then edid will be set/unset only during
hotplug. For the sake of older platforms where HPD is not stable, let edid
read happen from detect as well only if it is forced to do so.
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
Adding this for SKL onwards.
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
drivers/gpu/drm/i915/intel_hdmi.c | 49 ++---
1 file changed, 45 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
This series adds some optimization related to reading of edid only when
required and when live status says so.
The comments in the patches explain more.
First 3 patches were posted earlier(last week) too.
Sending them again along with the live status patch as part of the series.
Shashank Sharma
From: Shashank Sharma shashank.sha...@intel.com
This patch makes sure that the HDMI detect function
reads EDID only when its forced to do it. All the other
times, it uses the connector-detect_edid which was cached
during hotplug handling in the hdmi_probe() function. As the
probe function gets
Please just use
#ifdef HAS_DIRTYTRACKING_ROTATION
avoids the pain of versions.
Dave.
On 9 July 2015 at 18:44, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Thu, Jul 09, 2015 at 11:26:38AM +0300, Martin Peres wrote:
Signed-off-by: Martin Peres martin.pe...@linux.intel.com
I would prefer
On 29/06/2015 12:49, Jani Nikula wrote:
On Mon, 29 Jun 2015, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, Jun 29, 2015 at 02:40:15PM +0300, Jani Nikula wrote:
On Thu, 07 May 2015, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Wed, May 06, 2015 at 01:16:30PM +0200, Daniel Vetter
We have 3 types of DMA mappings for GEM objects:
1. physically contiguous for stolen and for objects needing contiguous
memory
2. DMA-buf mappings imported via a DMA-buf attach operation
3. SG DMA mappings for shmem backed and userptr objects
For 1. and 2. the lifetime of the DMA mapping
On Thu, Jul 09, 2015 at 12:59:05PM +0300, Imre Deak wrote:
We have 3 types of DMA mappings for GEM objects:
1. physically contiguous for stolen and for objects needing contiguous
memory
2. DMA-buf mappings imported via a DMA-buf attach operation
3. SG DMA mappings for shmem backed and
On 7/8/2015 8:50 PM, Daniel Vetter wrote:
On Wed, Jul 08, 2015 at 06:54:06PM +0530, Sivakumar Thulasimani wrote:
On 7/7/2015 5:01 PM, Daniel Vetter wrote:
On Tue, Jul 07, 2015 at 04:10:49PM +0530, Sivakumar Thulasimani wrote:
From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com
2015-07-08 20:21 GMT-03:00 Rodrigo Vivi rodrigo.v...@intel.com:
Since flush actually means invalidate + flush we need to force psr
exit on PSR flush.
On Core platforms there is no way to disable hw tracking and
do the pure sw tracking so we simulate it by fully disable psr and
reschedule a
2015-07-08 20:22 GMT-03:00 Rodrigo Vivi rodrigo.v...@intel.com:
Let's do a frontbuffer flush on dirty fb.
To be used for DIRTYFB drm ioctl.
This patch solves the biggest PSR known issue, that is
missed screen updates during boot, mainly when there is a splash
screen involved like Plymouth.
The hang checker needs to inspect whether or not the ring request list is empty
as well as if the given engine has reached or passed the most recently
submitted request. The problem with this is that the hang checker cannot grab
the struct_mutex, which is required in order to safely inspect
2015-07-08 20:24 GMT-03:00 Rodrigo Vivi rodrigo.v...@intel.com:
fbdev_set_par is called when fbcon is taking over control.
In the past frontbuffer was being invalidated on
set_to_gtt_domain, but it moved to set_domain fixing that case,
but left this behind.
Commit that changed this fixing
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6761
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On Thursday 09 July 2015 02:15 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Here's the new version of the CHV DPIO powergating feature. In short,
it allows us to power off unused lanes in the display PHY. So should
save some power when stuff is
From: Paulo Zanoni paulo.r.zan...@intel.com
Always update the currrent crtc, fb and vertical offset after calling
enable_fbc. We were forgetting to do so along the failure paths when
enabling fbc synchronously. Fix this with a new helper to enable_fbc()
and update the state simultaneously.
v2:
It really doesn't protect anything which doesn't have other locks
already. It also doesn't seem to be wired up into the driver unload
code fwiw, but that's a different issue.
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
drivers/gpu/drm/qxl/qxl_object.c | 4 +---
1 file changed, 1
It doesn't protect anything at all. fbdev helper state is all
protected by modeset locks, and nouveau bo state is taken care of by
ttm. There's also nothing else grabbing struct_mutex that might need
to coordinate with this code. Also this is driver load code, no one
can get at the device yet
This is only called in driver load/unload paths, no need to grab any
locks at all. Also, ttm takes care of itself anyway.
Cc: Ben Skeggs bske...@redhat.com
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 --
1 file changed, 2 deletions(-)
diff
Since David Herrmann's mmap vma manager rework we don't need to grab
dev-struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Signed-off-by: Daniel Vetter
This function takes two locks, both of them the wrong ones. This
wasn't an oversight from my fb locking rework since both patches
landed in parallel. We really only need fb_lock when walking that
list, since everything we can reach from that is refcounted properly
already.
Cc: Rob Clark
It really doesn't protect anything which doesn't have other locks
already. Also this is run from driver unload code so not much need for
locks anyway.
Same changes as for readone really.
Cc: Alex Deucher alexander.deuc...@amd.com
Cc: Christian König christian.koe...@amd.com
Signed-off-by: Daniel
We already grab 2 device-global locks (write-sema rdev-pm.mclk_lock
and rdev-ring_lock), adding another global mutex won't serialize this
code more. And since there's really nothing interesting that gets
protected in radeon by dev-struct mutex (we only have the global z
buffer owners and it's
Similar to radeon, except that amdgpu doesn't even use struct_mutex to
protect anything like the shared z buffer (sane gpu architecture,
yay!). And the code already grabs the globa adev-ring_lock, so this
code can't race with itself. Which makes struct_mutex completely
redundnant. Remove it.
Cc:
Since David Herrmann's mmap vma manager rework we don't need to grab
dev-struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Aside: I stumbled over the mmap handler which
Since David Herrmann's mmap vma manager rework we don't need to grab
dev-struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Signed-off-by: Daniel Vetter
Looking up an obj, immediate dropping the acquired reference and then
continuing to use it isn't how this is supposed to work. Fix this by
holding a reference for the entire function.
While at it stop grabbing dev-struct_mutex, it doesn't protect
anything here.
Signed-off-by: Daniel Vetter
It really doesn't protect anything which doesn't have other locks
already. Also this is run from driver unload code so not much need for
locks anyway.
Cc: Alex Deucher alexander.deuc...@amd.com
Cc: Christian König christian.koe...@amd.com
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
1 - 100 of 143 matches
Mail list logo
