Hi Paul,
On Fri, Jun 19, 2015 at 12:11 AM, Paul Bolle wrote:
> 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 wrote:
>> > On Wed, 2015-04-29 at 19:30 +0530, Shobhit Kumar wrote:
>> >> --- a/drivers/pwm/Kconfig
>> >> +++ b/dri
On Thu, 2015-06-18 at 16:50 +0100, Damien Lespiau wrote:
> 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
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Jani Nikula
> On Wed, 17 Jun 2015, Chris Wilson wrote:
> > On Wed, Jun 17, 2015 at 02:01:57PM +1000, Dave Airlie wrote:
> >> From: Dave Airlie
> >>
> >> This just adds enables for the
> -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 wrote:
> > > On 12 May 2015 at 11:50, Dave Airlie wrote:
> > >> Hi,
> > >>
> > >>
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
> Signed-o
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
> There's also a reference in skylake_update_primary_plane() that I assume
> can be removed?
>
Sur
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 Lankhors
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 c
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
On 18 June 2015 at 16:04, Jani Nikula 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’:
/home/airlied/devel/kernel/drm-next/drivers/gpu/drm/i915/intel_displa
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
Signed-
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
Signed-off-by: Gaurav K Singh
Signed-off-by: Shobhit K
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
Signed-off-by: Yogesh Mohan Marimuthu
Signed-off-by: Shobhit Kumar
---
drivers/gpu/
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
Signed-off-by: Yogesh Mohan Marimuthu
Signed-off-by: Shobhit Kumar
---
drivers/gp
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 ena
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 ev
2015-06-18 15:43 GMT-03:00 Rodrigo Vivi :
> 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: Rodrigo Vivi
> ---
>
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
> breaka
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 wrote:
> From: Daniel Vetter
>
> Like with
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 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 Crystal
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
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915
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
Signed-off-by: R
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 d
From: Daniel Vetter
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 bf51d5e2cda5d36d98e4b46ac7fca94
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 +01
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.
>>
>
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,
> +
On Fri, May 1, 2015 at 2:42 AM, Paul Bolle 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
>>
In Indirect context w/a batch buffer,
WaClearSlmSpaceAtContextSwitch
v2: s/PIPE_CONTROL_FLUSH_RO_CACHES/PIPE_CONTROL_FLUSH_L3 (Ville)
Cc: Chris Wilson
Cc: Dave Gordon
Signed-off-by: Rafael Barbalho
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915
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
Cc: Dave Gordon
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 b
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 l
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 def
In Indirect and Per context w/a batch buffer,
+WaDisableCtxRestoreArbitration
Cc: Chris Wilson
Cc: Dave Gordon
Signed-off-by: Rafael Barbalho
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/intel_lrc.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gp
From: Bob Paauwe
The registers and process differ from other platforms.
v2(Matt): Return 19.2 MHz when DE PLL is disabled (Ville)
Cc: Ville Syrjälä
Cc: Imre Deak
Signed-off-by: Bob Paauwe
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 31 ++
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 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: John
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,
> +
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 i
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 compl
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
> > >>
> > >>The pl
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
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 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
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 is
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/fl
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 w
>>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 startu
On to, 2015-06-18 at 13:47 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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ä
Looks ok to me:
Reviewed-by: Imre Deak
> ---
>
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 14 June 2015 at 10:02, Sharma, Shashank 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 efficient to have
> an
On Thu, Jun 18, 2015 at 01:22:36PM +0300, Mika Kuoppala wrote:
> Chris Wilson 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 context is properly
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 attem
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ä
> > wrote:
> >>I was going to suggest removing the same thing from the
> >>lrc_setup_hardware_status_page(), but after another look it seems w
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 blo
-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 Programming
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 Da
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
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
driv
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
---
drivers/gpu/dr
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
---
drivers/gpu/drm/i915/intel_ddi.c | 20
1 file changed, 20 inser
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
---
drivers/gpu/drm/i915/intel_display.c | 18 ++
drivers/gpu/drm/i915/intel_drv.h | 2 ++
2 files changed, 1
Signed-off-by: Imre Deak
---
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
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drive
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
> >>
> >>The plan is to pass requests around as the basic submission tracking
> >>structu
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
There's also a reference in skylake_update_primary_plane() that I assume
can be removed?
Matt
> ---
> drivers/gpu/drm/i915/intel_atomic_p
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/fl
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
> ---
> drivers/gpu/drm/i915/intel_atomic_p
On 15/06/2015 06:20, Daniel Vetter wrote:
On Wed, Jun 3, 2015 at 6:14 PM, Ville Syrjälä
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 setup. Would be nice to
have a
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
> + * ru
On Thu, Jun 18, 2015 at 1:21 PM, John Harrison
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 (patch 2 in
> the series). T
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 b
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
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c | 16
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 def
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
Signed-off-by: Aru
In Indirect and Per context w/a batch buffer,
+WaDisableCtxRestoreArbitration
Signed-off-by: Rafael Barbalho
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/intel_lrc.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
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 l
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
> + * ru
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
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()
c
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 tab
On Thu, Jun 18, 2015 at 01:14:56PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> 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 compl
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
---
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,
From: John Harrison
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
page flip. The _sync() functi
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
From: John Harrison
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 in that ring's OLR until
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 re
From: John Harrison
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 its epilogue
commands to the
On Thu, 18 Jun 2015, Jani Nikula wrote:
> On Thu, 18 Jun 2015, Ander Conselvan De Oliveira 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 wrote:
>>> > > I just noticed that
On Thu, 18 Jun 2015, Ander Conselvan De Oliveira 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 wrote:
>> > > I just noticed that I had forgotten to reply-all...
>> > >
>> > >
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
i915_gem_object_write() is a generic function to copy data
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 mor
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: John
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
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
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/d
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, john.c.harri...@intel.c
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,
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 contex
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
> >>>
> >>>The i915_ge
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
The i915_gem_object_flush_active() call used to do lots. Over time it has done
less and less.
1 - 100 of 163 matches
Mail list logo
