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 whe
Signed-off-by: Martin Peres
---
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 FreePixmap(PixmapPtr pixmap)
#endif
#
Signed-off-by: Martin Peres
---
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 +3605,14 @@ bool sna_dri2_open(str
On Thu, Jul 09, 2015 at 11:26:38AM +0300, Martin Peres wrote:
> Signed-off-by: Martin Peres
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 follow through later if we
ca
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 extensi
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 alr
Please just use
#ifdef HAS_DIRTYTRACKING_ROTATION
avoids the pain of versions.
Dave.
On 9 July 2015 at 18:44, Chris Wilson wrote:
> On Thu, Jul 09, 2015 at 11:26:38AM +0300, Martin Peres wrote:
>> Signed-off-by: Martin Peres
>
> I would prefer this to be testing for the unstable release that
On 29/06/2015 12:49, Jani Nikula wrote:
On Mon, 29 Jun 2015, Chris Wilson wrote:
On Mon, Jun 29, 2015 at 02:40:15PM +0300, Jani Nikula wrote:
On Thu, 07 May 2015, Chris Wilson wrote:
On Wed, May 06, 2015 at 01:16:30PM +0200, Daniel Vetter wrote:
On Tue, May 05, 2015 at 09:17:29AM +0100, Chr
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 matche
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
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 make
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
intel_lr_context_defe
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 c
Moved common code handling command streamer interrupts into a function.
Renamed tmp variable to the more descriptive iir.
Signed-off-by: Thomas Daniel
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_irq.c | 68 +
1 file changed, 35 insertions(+),
Issue: VIZ-4798
Signed-off-by: Nick Hoath
---
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 adc4942..770a6f6 100644
--- a/dri
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
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_gem.c | 10 +++---
drivers/gpu/
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 Centr
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
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.
-Chr
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_in
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
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 called before detect in the
From: Shashank Sharma
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 implementation of hdmi_detect
From: Shashank Sharma
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
Signed-off-by: Shashank Sharma
--
Adding this for SKL onwards.
Signed-off-by: Sonika Jindal
---
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
b/drivers/gpu/drm/i915/intel_hdmi.c
index 1fb6919..769cf
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
---
drivers/gpu/drm/i915/intel_hdmi.c |6 +-
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"
Update the hotplug documentation
2015-07-08 20:21 GMT-03:00 Rodrigo Vivi :
> 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 enable back.
> So
2015-07-08 20:22 GMT-03:00 Rodrigo Vivi :
> 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.
>
> Previously PSR
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 request
2015-07-08 20:24 GMT-03:00 Rodrigo Vivi :
> 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
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ä
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 either disabled, or when running
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 11:0
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 change
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 request
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
>
On Thu, Jul 09, 2015 at 10:41:36AM +0100, Ceraolo Spurio, Daniele wrote:
> On 29/06/2015 12:49, Jani Nikula wrote:
> >On Mon, 29 Jun 2015, Chris Wilson wrote:
> >>On Mon, Jun 29, 2015 at 02:40:15PM +0300, Jani Nikula wrote:
> >>>On Thu, 07 May 2015, Chris Wilson wrote:
> On Wed, May 06, 2015
On Thu, Jul 09, 2015 at 10:04:20AM -0300, Paulo Zanoni wrote:
> 2015-07-08 20:22 GMT-03:00 Rodrigo Vivi :
> > 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
On Wed, Jul 08, 2015 at 03:05:49PM -0300, Paulo Zanoni wrote:
> 2015-07-07 20:28 GMT-03:00 Rodrigo Vivi :
> > 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 inv
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
"Siluvery, Arun" writes:
> On 07/07/2015 20:13, Francisco Jerez wrote:
>> From: Peter Antoine
>>
>> 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 that are defined to be optimal.
>>
>> It
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
> > submitte
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, Sivaku
On 7/7/2015 4:15 PM, Michel Thierry wrote:
There are some allocations that must be only referenced by 32-bit
offsets. To limit the chances of having the first 4GB already full,
objects not requiring this workaround use DRM_MM_SEARCH_BELOW/
DRM_MM_CREATE_TOP flags
In specific, any resource used w
On Wed, Jul 08, 2015 at 11:45:59PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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
> staggering. So move the s
On Thu, 2015-07-09 at 10:10 -0300, Paulo Zanoni wrote:
> 2015-07-08 20:24 GMT-03:00 Rodrigo Vivi :
> > 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 thi
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 life-cycle
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
Au
ops... Sorry..
I could swear I had added this... or probably forgot to send the version
that had it...
Anyway:
Reviewed-by: Rodrigo Vivi
On Wed, Jul 8, 2015 at 2:09 PM Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Reported by the kbuild test robot.
>
> Regression introduced by:
> commit de15
On Wed, Jul 08, 2015 at 05:58:57PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> 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
Hm, do we have testcases where we
From: Paulo Zanoni
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 + flush
- drm/i915: fbde
On Wed, Jul 08, 2015 at 05:58:58PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> 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 probably have additional
>
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
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Enginee
From: Ville Syrjälä
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 confusing thing in this is that
On Wed, Jul 08, 2015 at 06:08:39PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Reported by the kbuild test robot.
>
> Regression introduced by:
> commit fdbff9282c0f5f61ffc87d57461b04d943250910
> Author: Daniel Vetter
> Date: Thu Jun 18 11:23:24 2015 +0200
> drm/i915: Clear fb_tra
2015-07-09 14:10 GMT-03:00 Daniel Vetter :
> On Wed, Jul 08, 2015 at 05:58:57PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> 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:
2015-07-09 14:15 GMT-03:00 Paulo Zanoni :
> 2015-07-09 14:10 GMT-03:00 Daniel Vetter :
>> On Wed, Jul 08, 2015 at 05:58:57PM -0300, Paulo Zanoni wrote:
>>> From: Paulo Zanoni
>>>
>>> The doc is pretty clear that this register should be set to 0 on SNB.
>>> We already write y_offset to DPFC_CPU_FEN
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
> >
> > 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 be
On Thu, Jul 09, 2015 at 05:34:29PM +0530, Sonika Jindal wrote:
> Adding this for SKL onwards.
>
> Signed-off-by: Sonika Jindal
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
digg that out. Also we
2015-07-09 14:15 GMT-03:00 Daniel Vetter :
> On Wed, Jul 08, 2015 at 05:58:58PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> 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
On Wed, Jul 08, 2015 at 07:54:47PM +0530, Animesh Manna wrote:
> Signed-off-by: Animesh Manna
> ---
> 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 d600640..
2015-07-09 14:22 GMT-03:00 Ville Syrjälä :
> 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
>> >
>> > The doc is pretty clear that this register should be set to 0 on SNB.
>> > We already write
On Thu, Jul 09, 2015 at 02:31:15PM -0300, Paulo Zanoni wrote:
> 2015-07-09 14:22 GMT-03:00 Ville Syrjälä :
> > 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
> >> >
> >> > The doc is pretty
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
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
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> dr
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.
>
> Sign
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(), originally
From: Alex Dai
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: VIZ-4884
Signed-off-by:
From: Alex Dai
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
v4:
Mark "enable_guc
From: Alex Dai
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
Signed-off-by: Dave Gordon
---
drive
From: Alex Dai
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 comments by Chris Wils
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 t
From: Alex Dai
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 that is NOT in the
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 firmwa
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 functions,
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; doorbel
Turn on interrupt steering to route necessary interrupts to GuC.
v4:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_reg.h | 11 +--
drivers/gpu/drm/i915/intel_guc_loader.c | 51 +
2 files
From: Alex Dai
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 few other changes
Signed-off-by: Dave Gordon
v4:
Rebased
Signed-off-by: Dave Gordon
---
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
b/drivers/gpu/drm/i915/i915_params.c
index 2791b5a..8bb1719 100644
--- a/driv
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
Signed-off-by: Alex Dai
---
drivers/gpu/drm/i915/i915_debugfs.c | 40 ++
2015-07-09 13:56 GMT-03:00 Rodrigo Vivi :
> 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
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 S
2015-07-08 20:25 GMT-03:00 Rodrigo Vivi :
> 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 fbdev op.
>
> v2:
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: [Intel-gf
From: Paulo Zanoni
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: Improve commit message (Ch
From: Paulo Zanoni
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 probably have additional
restrictions, so we need to figure out those and implement them later.
Let
On Thu, Jul 09, 2015 at 07:00:34PM +, Vivi, Rodrigo wrote:
> Those "FIXME" are for atomic fb ops callbacks what I don't believe that
> applies for this case.
Yeah intel_fbdev_restore_mode can't be called from atomic context, no need
for a FIXME here.
-Daniel
--
Daniel Vetter
Software Enginee
On Thu, Jul 09, 2015 at 03:46:17PM -0300, Paulo Zanoni wrote:
> 2015-07-09 13:56 GMT-03:00 Rodrigo Vivi :
> > 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 l
Instead of trying to deal with this complexity we'll simply require
that the dmc firmware is available for runtime pm support. We do that
by not releasing the rpm reference we acquire when starting the
firmware loader work. Note that since we hold a rpm reference (and rpm
get/put is synchronized wi
Grabbing a runtime pm reference with intel_runtime_pm_get will only
prevent device D3. But dmc firmware is required even earlier (namely
for the skl power well 2).
Hence we need to grab a rpm reference higher up in the hierarchy. For
simplicity just grab the _INIT display power well. That's a bit
They don't serve a purpose any more after the preceding patches.
This removes two anti-patterns:
- Locking shouldn't be used to synchronize with async work (of any
form, whether callbacks, workers or other threads). This is what the
mutex_lock/unlock seems to have been for in intel_csr_load_pr
The loader function will get a bit more complicated soon, extract the
parsing code to make the control flow clearer. While doing that just
use dev_priv->csr.dmc_payload as the indicator for whether it all
suceeded or not.
Also restrict the forced big-edian casting to just one place.
Cc: Animesh M
I have just placed them at the exact spot the old code had a
set_state. This probably needs to be moved earlier into the suspend
sequence, but I didn't audit that.
FIXME:
- Do this audit and move the flush_work to the right places.
- For consistency and since we have the work already it would be n
We need to make sure we don't put garbage into the hw if dmc firmware
loading failed mid-thru.
Cc: Animesh Manna
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_csr.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/driv
It's the new style!
Cc: Animesh Manna
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 6 +++---
drivers/gpu/drm/i915/i915_drv.c | 4 +---
drivers/gpu/drm/i915/intel_csr.c | 27 +++
drivers/gpu/drm/i915/intel_drv.h | 6 +++---
4 files changed, 18 i
Standard is to align continuations of parameter lists and if
conditions to the opening ( in i915 and drm code.
Apply this across the entire file since it was sticking out a bit too
much.
Also align register definitions while at it.
Cc: Animesh Manna
Signed-off-by: Daniel Vetter
---
drivers/gp
Avoids non-static functions since all the callers are in intel_rpm.c.
Only thing we need for that is to move the register definitions into
i915_reg.h.
Cc: Animesh Manna
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_reg.h | 16
drivers/gpu/drm/i915/intel_csr
If we really want to we can be more verbose here, but we really don't
need an entire function for this.
Cc: Animesh Manna
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 20
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/intel_csr.c | 8 +
Two benefits:
- We can use FW_LOADER_USERSPACE_FALLBACK.
- We can use flush_work to synchronize with the oustanding worker,
which is a notch more obvious what it does than having a special
completion.
The next patch will properly synchronize against the async loader in
the resume and unload co
1 - 100 of 143 matches
Mail list logo
