On Thu, Jun 18, 2015 at 12:18:39PM +0100, Tomas Elf wrote:
My point was more along the lines of bailing out if the reset
request fails and not return an error message but simply keep track
of the number of times we've attempted the reset request. By not
returning an error we would allow more
On 17/06/15 13:02, Daniel Vetter wrote:
On Wed, Jun 17, 2015 at 08:23:40AM +0100, Dave Gordon wrote:
On 15/06/15 21:09, Chris Wilson wrote:
On Mon, Jun 15, 2015 at 07:36:19PM +0100, Dave Gordon wrote:
From: Alex Dai yu@intel.com
i915_gem_object_write() is a generic function to copy data
On Thu, 18 Jun 2015, Jani Nikula jani.nik...@linux.intel.com wrote:
On Thu, 18 Jun 2015, Ander Conselvan De Oliveira conselv...@gmail.com wrote:
On Fri, 2015-06-05 at 12:11 +0300, Ville Syrjälä wrote:
On Fri, Jun 05, 2015 at 11:51:42AM +0300, Jani Nikula wrote:
On Thu, 04 Jun 2015, Rodrigo
On 17/06/15 13:05, Daniel Vetter wrote:
On Mon, Jun 15, 2015 at 07:36:20PM +0100, Dave Gordon wrote:
Current devices may contain one or more programmable microcontrollers
that need to have a firmware image (aka binary blob) loaded from an
external medium and transferred to the device's memory.
On Thu, Jun 18, 2015 at 01:14:56PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison john.c.harri...@intel.com
The plan is to pass requests around as the basic submission tracking structure
rather than rings and contexts. This patch updates the i915_gem_object_sync()
code path.
An OEM may request increased I_boost beyond the recommended values
by specifying an I_boost value to be applied to all swing entries for
a port. These override values are specified in VBT.
Issue: VIZ-5676
Signed-off-by: Antti Koskipaa antti.koski...@linux.intel.com
---
From: John Harrison john.c.harri...@intel.com
The plan is to pass requests around as the basic submission tracking structure
rather than rings and contexts. This patch updates the i915_gem_object_sync()
code path.
v2: Much more complex patch to share a single request between the sync and the
On Thu, Jun 18, 2015 at 01:29:45PM +0100, Peter Antoine wrote:
@@ -1379,6 +1380,13 @@ static int gen8_init_rcs_context(struct
intel_engine_cs *ring,
if (ret)
return ret;
+ /*
+ * Failing to program the MOCS is non-fatal.The system will not
+ * run at
On Thu, Jun 18, 2015 at 1:21 PM, John Harrison
john.c.harri...@intel.com wrote:
I'm still confused by what you are saying in the above referenced email.
Part of it is about the sanity checks failing to handle the wrapping case
correctly which has been fixed in the base reserve space patch
On Thu, 18 Jun 2015, Ander Conselvan De Oliveira conselv...@gmail.com wrote:
On Fri, 2015-06-05 at 12:11 +0300, Ville Syrjälä wrote:
On Fri, Jun 05, 2015 at 11:51:42AM +0300, Jani Nikula wrote:
On Thu, 04 Jun 2015, Rodrigo Vivi rodrigo.v...@gmail.com wrote:
I just noticed that I had
On 17/06/2015 16:52, Chris Wilson wrote:
On Wed, Jun 17, 2015 at 04:54:42PM +0200, Daniel Vetter wrote:
On Wed, Jun 17, 2015 at 03:27:08PM +0100, Chris Wilson wrote:
On Wed, Jun 17, 2015 at 03:31:59PM +0200, Daniel Vetter wrote:
On Fri, May 29, 2015 at 05:44:09PM +0100,
On Thu, Jun 18, 2015 at 12:03:12PM +0100, John Harrison wrote:
On 17/06/2015 15:21, Chris Wilson wrote:
On Wed, Jun 17, 2015 at 04:06:05PM +0200, Daniel Vetter wrote:
On Fri, May 29, 2015 at 05:44:16PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison john.c.harri...@intel.com
The
On 16/06/15 14:54, Chris Wilson wrote:
On Tue, Jun 16, 2015 at 03:48:09PM +0200, Daniel Vetter wrote:
On Mon, Jun 08, 2015 at 06:33:59PM +0100, Chris Wilson wrote:
On Mon, Jun 08, 2015 at 06:03:21PM +0100, Tomas Elf wrote:
In preparation for per-engine reset add way for setting context reset
On 18/06/2015 12:10, Chris Wilson wrote:
On Thu, Jun 18, 2015 at 12:03:12PM +0100, John Harrison wrote:
On 17/06/2015 15:21, Chris Wilson wrote:
On Wed, Jun 17, 2015 at 04:06:05PM +0200, Daniel Vetter wrote:
On Fri, May 29, 2015 at 05:44:16PM +0100, john.c.harri...@intel.com wrote:
From:
On Thu, Jun 18, 2015 at 01:29:45PM +0100, Peter Antoine wrote:
@@ -1379,6 +1380,13 @@ static int gen8_init_rcs_context(struct
intel_engine_cs *ring,
if (ret)
return ret;
+ /*
+ * Failing to program the MOCS is non-fatal.The system will not
+ * run at
On 18/06/2015 13:21, Chris Wilson wrote:
On Thu, Jun 18, 2015 at 01:14:56PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison john.c.harri...@intel.com
The plan is to pass requests around as the basic submission tracking structure
rather than rings and contexts. This patch updates
On 18/06/2015 11:36, Chris Wilson wrote: On Thu, Jun 18, 2015 at
11:11:55AM +0100, Tomas Elf wrote:
On 18/06/2015 10:51, Mika Kuoppala wrote:
In order for gen8+ hardware to guarantee that no context switch
takes place during engine reset and that current context is properly
saved, the driver
On Thu, 2015-06-18 at 10:10 +0100, ch...@chris-wilson.co.uk wrote:
On Thu, Jun 18, 2015 at 08:45:10AM +, Antoine, Peter wrote:
On Thu, 2015-06-18 at 08:49 +0100, ch...@chris-wilson.co.uk wrote:
On Thu, Jun 18, 2015 at 07:36:41AM +, Antoine, Peter wrote:
On Wed, 2015-06-17 at
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 creates a fixed register set that is programmed across the different
engines so that all engines have the same
Just FYI, this patch depends on David Weinehall's Buffer translation
improvements patch from earlier today.
--
- Antti
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
From: John Harrison john.c.harri...@intel.com
It is a bad idea for i915_add_request() to fail. The work will already have been
send to the ring and will be processed, but there will not be any tracking or
management of that work.
The only way the add request call can fail is if it can't write
From: John Harrison john.c.harri...@intel.com
The i915_gem_init_hw() function calls a bunch of smaller initialisation
functions. Multiple of which have generic sections and per ring sections. This
means multiple passes are done over the rings. Each pass writes data to the ring
which floats around
On Thu, Jun 18, 2015 at 12:49:55PM +0100, Dave Gordon wrote:
On 17/06/15 13:02, Daniel Vetter wrote:
Domain handling is required for all gem objects, and the resulting bugs if
you don't for one-off objects are absolutely no fun to track down.
Is it not the case that the new object returned
intel_iosf_sb_read, intel_iosf_sb_write, intel_reg_dumper,
intel_reg_read, intel_reg_snapshot, intel_reg_write, intel_vga_read, and
intel_vga_write have been deprecated in favor of intel_reg. Remove the
deprecated tools. intel_reg does everything they do, and more.
Signed-off-by: Jani Nikula
In Indirect context w/a batch buffer,
WaClearSlmSpaceAtContextSwitch
v2: s/PIPE_CONTROL_FLUSH_RO_CACHES/PIPE_CONTROL_FLUSH_L3 (Ville)
Signed-off-by: Rafael Barbalho rafael.barba...@intel.com
Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
In Indirect context w/a batch buffer,
+WaFlushCoherentL3CacheLinesAtContextSwitch:bdw
v2: Add LRI commands to set/reset bit that invalidates coherent lines,
update WA to include programming restrictions and exclude CHV as
it is not required (Ville)
v3: Avoid unnecessary read when it can be done
From Gen8+ we have some workarounds that are applied Per context and
they are applied using special batch buffers called as WA batch buffers.
HW executes them at specific stages during context save/restore.
The patches in this series adds this framework to i915.
I did some basic testing on BDW by
Some of the WA are to be applied during context save but before restore and
some at the end of context save/restore but before executing the instructions
in the ring, WA batch buffers are created for this purpose and these WA cannot
be applied using normal means. Each context has two registers to
In Indirect and Per context w/a batch buffer,
+WaDisableCtxRestoreArbitration
Signed-off-by: Rafael Barbalho rafael.barba...@intel.com
Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 18 --
1 file changed, 8 insertions(+), 10
In Per context w/a batch buffer,
WaRsRestoreWithPerCtxtBb
v2: This patches modifies definitions of MI_LOAD_REGISTER_MEM and
MI_LOAD_REGISTER_REG; Add GEN8 specific defines for these instructions
so as to not break any future users of existing definitions (Michel)
v3: Length defined in current
Some of the WA applied using WA batch buffers perform writes to scratch page.
In the current flow WA are initialized before scratch obj is allocated.
This patch reorders intel_init_pipe_control() to have a valid scratch obj
before we initialize WA.
Signed-off-by: Michel Thierry
On Thu, Jun 18, 2015 at 01:22:36PM +0300, Mika Kuoppala wrote:
Chris Wilson ch...@chris-wilson.co.uk writes:
On Thu, Jun 18, 2015 at 12:51:40PM +0300, Mika Kuoppala wrote:
In order for gen8+ hardware to guarantee that no context switch
takes place during engine reset and that current
On to, 2015-06-18 at 13:47 +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
The same dpll p2 divider selection is repeated three times in the
gen2-4 .find_dpll() functions. Factor it out.
Signed-off-by: Ville Syrjälä
On Thu, Jun 18, 2015 at 04:25:47PM +0100, Damien Lespiau wrote:
On Thu, Jun 18, 2015 at 03:45:44PM +0100, Antoine, Peter wrote:
So, intializing the other (non-render) MOCS in gen8_init_rcs_context()
isn't the most logical thing to do I'm afraid. What happens if we
suddenly decide that we
On Thu, Jun 18, 2015 at 01:11:34PM +0100, Dave Gordon wrote:
On 17/06/15 13:05, Daniel Vetter wrote:
On Mon, Jun 15, 2015 at 07:36:20PM +0100, Dave Gordon wrote:
Current devices may contain one or more programmable microcontrollers
that need to have a firmware image (aka binary blob) loaded
On 14 June 2015 at 10:02, Sharma, Shashank shashank.sha...@intel.com wrote:
Hi, Emil Velikov
The reason behind a zero sized array is that we want to use the same variable
for various color correction possible across various driver .
Due to current blob implementation, it doesn’t look very
Although we have a fixed setting for the PLL9 and EBB4 registers, it
still makes sense to check them together with the rest of PLL registers.
While at it also remove a redundant comment about 10 bit clock enabling.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h
Add support for reading out the HW state for DDI ports. Since the actual
programming is very similar to the CHV/VLV DPIO PLL programming we can
reuse much of the logic from there.
This fixes the state checker failures I saw on my BXT with HDMI output.
Signed-off-by: Imre Deak imre.d...@intel.com
For the purpose of state checking we only care about the DPLL HW flags
that we actually program, so mask off the ones that we don't.
This fixes one set of DPLL state check failures.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 20
1
This functionality will be needed by the next patch adding HW readout
support for DDI ports on BXT, so factor it out.
No functional change.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 18 ++
drivers/gpu/drm/i915/intel_drv.h | 2 ++
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6f79680..0e5c613 100644
---
On Thu, Jun 18, 2015 at 03:05:12PM +0100, Siluvery, Arun wrote:
On 15/06/2015 06:20, Daniel Vetter wrote:
On Wed, Jun 3, 2015 at 6:14 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
I was going to suggest removing the same thing from the
lrc_setup_hardware_status_page(), but after
On Thu, Jun 18, 2015 at 12:42:55PM +0100, Chris Wilson wrote:
On Thu, Jun 18, 2015 at 12:18:39PM +0100, Tomas Elf wrote:
My point was more along the lines of bailing out if the reset
request fails and not return an error message but simply keep track
of the number of times we've attempted
On Thu, Jun 18, 2015 at 12:50:33PM +0300, David Weinehall wrote:
@@ -3520,6 +3545,9 @@ intel_dp_set_signal_levels(struct intel_dp *intel_dp,
uint32_t *DP)
} else if (HAS_DDI(dev)) {
signal_levels = hsw_signal_levels(train_set);
mask = DDI_BUF_EMP_MASK;
+
+
On Thu, Jun 18, 2015 at 03:45:44PM +0100, Antoine, Peter wrote:
So, intializing the other (non-render) MOCS in gen8_init_rcs_context()
isn't the most logical thing to do I'm afraid. What happens if we
suddenly decide that we don't want to fully initialize the default
context at startup but
On Thu, Jun 18, 2015 at 04:24:53PM +0200, Daniel Vetter wrote:
On Thu, Jun 18, 2015 at 01:59:13PM +0100, John Harrison wrote:
On 18/06/2015 13:21, Chris Wilson wrote:
On Thu, Jun 18, 2015 at 01:14:56PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison john.c.harri...@intel.com
On Thu, Jun 18, 2015 at 04:49:49PM +0200, Daniel Vetter wrote:
Guc is different since we really must have it ready for execbuf, and for
that usecase a completion at drm_open time sounds like the right thing.
But do we? It would be nice if we had a definite answer that the hw was
ready before we
On Thu, Jun 18, 2015 at 06:31:18PM +0300, Imre Deak wrote:
On to, 2015-06-11 at 09:33 +0100, Chris Wilson wrote:
On Thu, Jun 11, 2015 at 09:25:16AM +0100, Dave Gordon wrote:
On 10/06/15 15:58, Chris Wilson wrote:
As the clflush operates on cache lines, and we can flush any byte
On 15/06/2015 06:20, Daniel Vetter wrote:
On Wed, Jun 3, 2015 at 6:14 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
I was going to suggest removing the same thing from the
lrc_setup_hardware_status_page(), but after another look it seems we
sometimes call .init_hw() before the context
-Original Message-
From: Lespiau, Damien
Sent: Thursday, June 18, 2015 2:51 PM
To: Antoine, Peter
Cc: intel-gfx@lists.freedesktop.org;
daniel.vetter.intel@irsmsx102.ger.corp.intel.com; ch...@chris-wilson.co.uk;
matts...@gmail.com
Subject: Re: [PATCH v5] drm/i915 : Added
On Mon, Jun 15, 2015 at 12:33:52PM +0200, Maarten Lankhorst wrote:
Now that all planes are added during a modeset we can use the
calculated changes before disabling a plane, and then either commit
or force disable a plane before disabling the crtc.
The code is shared with atomic_begin/flush,
On Thu, Jun 18, 2015 at 04:27:52PM +0100, Chris Wilson wrote:
On Thu, Jun 18, 2015 at 04:49:49PM +0200, Daniel Vetter wrote:
Guc is different since we really must have it ready for execbuf, and for
that usecase a completion at drm_open time sounds like the right thing.
But do we? It would
On to, 2015-06-11 at 09:33 +0100, Chris Wilson wrote:
On Thu, Jun 11, 2015 at 09:25:16AM +0100, Dave Gordon wrote:
On 10/06/15 15:58, Chris Wilson wrote:
As the clflush operates on cache lines, and we can flush any byte
address, in order to flush all bytes given in the range we issue an
On Thu, Jun 18, 2015 at 12:49:55PM +0100, Dave Gordon wrote:
On 17/06/15 13:02, Daniel Vetter wrote:
On Wed, Jun 17, 2015 at 08:23:40AM +0100, Dave Gordon wrote:
On 15/06/15 21:09, Chris Wilson wrote:
On Mon, Jun 15, 2015 at 07:36:19PM +0100, Dave Gordon wrote:
From: Alex Dai
On Mon, Jun 15, 2015 at 12:33:55PM +0200, Maarten Lankhorst wrote:
All transitional plane helpers are gone, party!
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
There's also a reference in skylake_update_primary_plane() that I assume
can be removed?
Matt
---
On Thu, Jun 18, 2015 at 01:59:13PM +0100, John Harrison wrote:
On 18/06/2015 13:21, Chris Wilson wrote:
On Thu, Jun 18, 2015 at 01:14:56PM +0100, john.c.harri...@intel.com wrote:
From: John Harrison john.c.harri...@intel.com
The plan is to pass requests around as the basic submission
On Mon, Jun 15, 2015 at 12:33:52PM +0200, Maarten Lankhorst wrote:
Now that all planes are added during a modeset we can use the
calculated changes before disabling a plane, and then either commit
or force disable a plane before disabling the crtc.
The code is shared with atomic_begin/flush,
On Mon, Jun 15, 2015 at 12:33:54PM +0200, Maarten Lankhorst wrote:
By making color key atomic there are no more transitional helpers.
The plane check function will reject the color key when a scaler is
active.
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
On 18/06/2015 16:39, Chris Wilson wrote:
On Thu, Jun 18, 2015 at 04:24:53PM +0200, Daniel Vetter wrote:
On Thu, Jun 18, 2015 at 01:59:13PM +0100, John Harrison wrote:
On 18/06/2015 13:21, Chris Wilson wrote:
On Thu, Jun 18, 2015 at 01:14:56PM +0100, john.c.harri...@intel.com wrote:
From:
From: Bob Paauwe bob.j.paa...@intel.com
The registers and process differ from other platforms.
v2(Matt): Return 19.2 MHz when DE PLL is disabled (Ville)
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Cc: Imre Deak imre.d...@intel.com
Signed-off-by: Bob Paauwe bob.j.paa...@intel.com
On Thu, Jun 18, 2015 at 05:35:29PM +0200, Daniel Vetter wrote:
On Thu, Jun 18, 2015 at 04:27:52PM +0100, Chris Wilson wrote:
On Thu, Jun 18, 2015 at 04:49:49PM +0200, Daniel Vetter wrote:
Guc is different since we really must have it ready for execbuf, and for
that usecase a completion at
I'm pretty happy with the code, I was just confused by the series
changing the setup halfway through
On Thu, Jun 18, 2015 at 02:07:30PM +0100, Arun Siluvery wrote:
+static int gen8_init_indirectctx_bb(struct intel_engine_cs *ring,
+ uint32_t **wa_ctx_batch,
+
Hi,
Which option is mandatory in linux kernel to be able to act on
brightness of display ?
Regards,
Steph
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Thu, Jun 18, 2015 at 03:45:44PM +0100, Antoine, Peter wrote:
Not a blocker. It gets a little more interesting, as the L3CC
registers are shared across all engines, but is only saved in the RCS
context. But, it is reset on the context switch when ELSP is set. So
we would have to program it
Op 18-06-15 om 16:21 schreef Matt Roper:
On Mon, Jun 15, 2015 at 12:33:52PM +0200, Maarten Lankhorst wrote:
Now that all planes are added during a modeset we can use the
calculated changes before disabling a plane, and then either commit
or force disable a plane before disabling the crtc.
Op 18-06-15 om 16:21 schreef Matt Roper:
On Mon, Jun 15, 2015 at 12:33:54PM +0200, Maarten Lankhorst wrote:
By making color key atomic there are no more transitional helpers.
The plane check function will reject the color key when a scaler is
active.
Signed-off-by: Maarten Lankhorst
Op 18-06-15 om 16:21 schreef Matt Roper:
On Mon, Jun 15, 2015 at 12:33:55PM +0200, Maarten Lankhorst wrote:
All transitional plane helpers are gone, party!
Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
There's also a reference in skylake_update_primary_plane() that I
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Monday, May 18, 2015 5:21 PM
At Thu, 14 May 2015 09:10:33 +1000,
Dave Airlie wrote:
On 12 May 2015 at 13:27, Dave Airlie airl...@gmail.com wrote:
On 12 May 2015 at 11:50, Dave Airlie airl...@gmail.com wrote:
Op 18-06-15 om 17:28 schreef Ville Syrjälä:
On Mon, Jun 15, 2015 at 12:33:52PM +0200, Maarten Lankhorst wrote:
Now that all planes are added during a modeset we can use the
calculated changes before disabling a plane, and then either commit
or force disable a plane before disabling the crtc.
Op 18-06-15 om 11:25 schreef Daniel Vetter:
We use the same check already in the atomic core, so might as well
make this official. And it's also reused in e.g. i915.
Motivated by Maarten's idea to extract a connector_changed state out
of mode_changed.
Cc: Maarten Lankhorst
On 18 June 2015 at 16:04, Jani Nikula jani.nik...@intel.com wrote:
Hi Dave, i915 fixes for drm-next/v4.2.
BR,
Jani.
And my gcc says:
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i915/intel_display.c:
In function ‘__intel_set_mode’:
Some of the WA applied using WA batch buffers perform writes to scratch page.
In the current flow WA are initialized before scratch obj is allocated.
This patch reorders intel_init_pipe_control() to have a valid scratch obj
before we initialize WA.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc:
In Indirect context w/a batch buffer,
WaClearSlmSpaceAtContextSwitch
v2: s/PIPE_CONTROL_FLUSH_RO_CACHES/PIPE_CONTROL_FLUSH_L3 (Ville)
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Dave Gordon david.s.gor...@intel.com
Signed-off-by: Rafael Barbalho rafael.barba...@intel.com
Signed-off-by: Arun
By Spec we should just mask memup and hotplug detection
for hardware tracking cases. However we always masked
LPSP that is for low power tracking support because
without it PSR was constantly exiting and never really
getting activated.
Now with runtime PM being enabled by default Matthew
reported
This patch doesn't have any functional change, but organize fruntbuffer
invalidate and busy by removing unecesarry signature argument for ring.
It was unsed on mark_fb_busy and only used on fb_obj_invalidate for the
same ORIGIN_CS usage. So let's clean it a bit
Cc: Daniel Vetter
With a reliable frontbuffer tracking and all instability corner cases solved
let's re-enabled PSR by default on all supported platforms.
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On Fri, May 1, 2015 at 2:42 AM, Paul Bolle pebo...@tiscali.nl wrote:
On Wed, 2015-04-29 at 19:30 +0530, Shobhit Kumar wrote:
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
+config PWM_CRC
+ bool Intel Crystalcove (CRC) PWM support
+ depends on X86 INTEL_SOC_PMIC
+ help
+
On 06/15/2015 01:30 PM, Chris Wilson wrote:
On Mon, Jun 15, 2015 at 07:36:23PM +0100, Dave Gordon wrote:
snip
+ * Return true if get a success code from normal boot or RC6 boot
+ */
+static inline bool i915_guc_get_status(struct drm_i915_private *dev_priv,
+
I understand this patch is yet under discussion. I just re-sent to
warn that the following one depends on this. Otherwise it is better to
remove it and proceed with the last 3 patches of the series.
Thanks
On Thu, Jun 18, 2015 at 11:43 AM, Rodrigo Vivi rodrigo.v...@intel.com wrote:
From: Daniel
From: Daniel Vetter daniel.vet...@ffwll.ch
Like with every other feature that's not enabled by default we break
runtime pm support way too often by accident because the overall test
coverage isn't great. And it's been almost 2 years since we enabled
the power well code by default
commit
Before this we had some duct tapes to cover known cases where
FBDEV would cause a frontbuffer flush so we invalidate it again.
However other cases appeared like the boot splash screen doing
modeset and flushing it. So let's fix it for all cases.
FBDEV ops provides a function to fb_sync that was
On 15/06/15 21:30, Chris Wilson wrote:
On Mon, Jun 15, 2015 at 07:36:23PM +0100, Dave Gordon wrote:
+/* We can't enable contexts until all firmware is loaded */
+ret = intel_guc_ucode_load(dev, false);
Pardon. I know context initialisation is broken, but adding to that
breakage is
2015-06-18 15:43 GMT-03:00 Rodrigo Vivi rodrigo.v...@intel.com:
With a reliable frontbuffer tracking and all instability corner cases solved
let's re-enabled PSR by default on all supported platforms.
Are we now passing all the PSR tests from kms_frontbuffer_tracking too?
Signed-off-by:
In Indirect context w/a batch buffer,
+WaFlushCoherentL3CacheLinesAtContextSwitch:bdw
v2: Add LRI commands to set/reset bit that invalidates coherent lines,
update WA to include programming restrictions and exclude CHV as
it is not required (Ville)
v3: Avoid unnecessary read when it can be done
Some of the WA are to be applied during context save but before restore and
some at the end of context save/restore but before executing the instructions
in the ring, WA batch buffers are created for this purpose and these WA cannot
be applied using normal means. Each context has two registers to
In Per context w/a batch buffer,
WaRsRestoreWithPerCtxtBb
v2: This patches modifies definitions of MI_LOAD_REGISTER_MEM and
MI_LOAD_REGISTER_REG; Add GEN8 specific defines for these instructions
so as to not break any future users of existing definitions (Michel)
v3: Length defined in current
In Indirect and Per context w/a batch buffer,
+WaDisableCtxRestoreArbitration
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Dave Gordon david.s.gor...@intel.com
Signed-off-by: Rafael Barbalho rafael.barba...@intel.com
Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com
---
On 18/06/15 13:10, Chris Wilson wrote:
On Thu, Jun 18, 2015 at 12:49:55PM +0100, Dave Gordon wrote:
On 17/06/15 13:02, Daniel Vetter wrote:
Domain handling is required for all gem objects, and the resulting bugs if
you don't for one-off objects are absolutely no fun to track down.
Is it not
Hi Shobhit,
On Thu, 2015-06-18 at 23:24 +0530, Shobhit Kumar wrote:
On Fri, May 1, 2015 at 2:42 AM, Paul Bolle pebo...@tiscali.nl wrote:
On Wed, 2015-04-29 at 19:30 +0530, Shobhit Kumar wrote:
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
+config PWM_CRC
+ bool Intel
On 18/06/15 15:31, Daniel Vetter wrote:
On Thu, Jun 18, 2015 at 12:49:55PM +0100, Dave Gordon wrote:
On 17/06/15 13:02, Daniel Vetter wrote:
On Wed, Jun 17, 2015 at 08:23:40AM +0100, Dave Gordon wrote:
On 15/06/15 21:09, Chris Wilson wrote:
On Mon, Jun 15, 2015 at 07:36:19PM +0100, Dave
On Thu, Jun 18, 2015 at 10:53:10AM -0700, Yu Dai wrote:
On 06/15/2015 01:30 PM, Chris Wilson wrote:
On Mon, Jun 15, 2015 at 07:36:23PM +0100, Dave Gordon wrote:
+ /* Set the source address for the new blob */
+ offset = i915_gem_obj_ggtt_offset(fw_obj);
Why would it even have a GGTT
vblank interrupt should be disabled before starting the disable
sequence for MIPI command mode. Otherwise when pipe is disabled
TE interurpt will be still handled and one memory write command
will be sent with pipe disabled. This makes the pipe hw to get
stuck and it doesn't recover in the next
During disable sequence for MIPI encoder in command mode, disable
MIPI display self-refresh mode bit in Pipe Ctrl reg.
v2: Use crtc state flag instead of loop over encoders (Daniel)
Signed-off-by: Gaurav K Singh gaurav.k.si...@intel.com
Signed-off-by: Yogesh Mohan Marimuthu
During enable sequence for MIPI encoder in command mode, enable
MIPI display self-refresh mode bit in Pipe Ctrl reg.
v2: Use crtc state flag instead of loop over encoders (Daniel)
Signed-off-by: Gaurav K Singh gaurav.k.si...@intel.com
Signed-off-by: Yogesh Mohan Marimuthu
Allocate gem memory for MIPI DBI command buffer. This memory
will be used when sending command via DBI interface.
v2: lock mutex before gem object unreference and later set gem obj ptr to NULL
(Gaurav)
Signed-off-by: Yogesh Mohan Marimuthu yogesh.mohan.marimu...@intel.com
Signed-off-by: Gaurav
On 6/19/2015 3:32 AM, Gaurav K Singh wrote:
Allocate gem memory for MIPI DBI command buffer. This memory
will be used when sending command via DBI interface.
v2: lock mutex before gem object unreference and later set gem obj ptr to NULL
(Gaurav)
Signed-off-by: Yogesh Mohan Marimuthu
Hi Dave, i915 fixes for drm-next/v4.2.
BR,
Jani.
The following changes since commit bf546f8158e2df2656494a475e6235634121c87c:
drm/i915/skl: Fix DMC API version in firmware file name (2015-06-05 12:08:01
+0300)
are available in the git repository at:
On Thu, Jun 18, 2015 at 07:42:10AM +0200, Maarten Lankhorst wrote:
Op 18-06-15 om 03:48 schreef Matt Roper:
On Mon, Jun 15, 2015 at 12:33:43PM +0200, Maarten Lankhorst wrote:
It's easier to read separate functions for crtc and plane scaler state.
Changes since v1:
- Update
On Wed, Jun 17, 2015 at 04:19:22PM +0100, Peter Antoine wrote:
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 creates a fixed register set that is
On Thu, Jun 18, 2015 at 08:45:50AM +0200, Daniel Vetter wrote:
On Wed, Jun 17, 2015 at 06:37:03PM +0100, Chris Wilson wrote:
On Wed, Jun 17, 2015 at 05:03:19PM +0200, Daniel Vetter wrote:
On Wed, Jun 17, 2015 at 01:53:17PM +0100, Chris Wilson wrote:
On Wed, Jun 17, 2015 at 02:49:47PM
1 - 100 of 167 matches
Mail list logo
