I have just tried to boot 4.2-rc1 and cannot seem to reproduce the issue
anymore.
On Tue 07-07-15 10:43:58, Daniel Vetter wrote:
[...]
> Can you please
> boot with drm.debug=0xf (lots more nois in dmesg with this) and reproduce?
> I only need the last few pages before the WARNING backtrace, just t
On 20.06.2015 03:35, Vivi, Rodrigo wrote:
> Hi,
>
> Please consider pulling i915 to linux-firmware.git and let me know if
> there is anything else I should do differently on the pull request.
Pretty please, pull this in. It's blocking things downstream.
--
t
___
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6738
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
Sure I will send a patch correcting the condition.
Regards,
Animesh
-Original Message-
From: Deak, Imre
Sent: Tuesday, July 7, 2015 8:03 PM
To: David Binderman; Manna, Animesh
Cc: Vetter, Daniel; Jani Nikula; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] linux-4.2-rc1/drivers/
On 7/7/2015 6:51 PM, Ville Syrjälä wrote:
On Tue, Jul 07, 2015 at 02:22:20PM +0530, Sonika Jindal wrote:
Writing to PCH_PORT_HOTPLUG for each interrupt is not required.
Handle it only if hpd has actually occurred like we handle other
interrupts.
v2: Make few variables local to if block (Ville)
On Wednesday 08 July 2015 04:53 AM, Matt Roper wrote:
On Fri, Jul 03, 2015 at 09:01:38AM +0530, Kausal Malladi wrote:
This patch does the following:
1. Adds new files intel_color_manager(.c/.h)
2. Attaches color properties to CRTC while initialization
Signed-off-by: Shashank Sharma
Signed-off-
Thanks for your review, Matt! Our responses inline...
Kausal
On Wednesday 08 July 2015 04:53 AM, Matt Roper wrote:
On Fri, Jul 03, 2015 at 09:01:37AM +0530, Kausal Malladi wrote:
Color Management is an extension to Kernel display framework. It allows
abstraction of hardware color correction an
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6737
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On Mon, Jul 06, 2015 at 04:40:24PM +0200, Gabriel Laskar wrote:
> On Mon, 6 Jul 2015 12:35:52 +0200, Patrik Jakobsson wrote:
> > On Fri, Jul 03, 2015 at 03:36:09AM +0300, Dmitry V. Levin wrote:
> > > On Wed, Jul 01, 2015 at 02:52:47PM +0200, Patrik Jakobsson wrote:
> > > [...]
> > > > --- a/drm.c
>
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6736
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
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.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/inte
Since flush actually means invalidate + flush we need to force psr
exit on PSR flush.
On Core platforms there is no way to do the sw tracking so we
simulate it by fully disable psr and reschedule a enable back.
So a good idea is to minimize sequential disable/enable in cases we
know that HW tracki
By Spec we should only mask memup and hotplug detection
for hardware tracking cases. However we always masked
LPSP because with power well always enabled on audio
PSR was never being activated and residency was always
zeroed.
Apparently audio driver is tying power well management
and runtime PM fo
Idle frames the number of identical frames needed
before panel can enter PSR.
There are some panels that requires up to minimum of 4 idle
frames available on the market. For these cases usually
VBT should be used to configure the number of idle frames,
but unfortunately this isn't always true and
This will be useful to PSR and FBC once we start making
dirty fb calls to also flush frontbuffer.
Cc: Daniel Vetter
Cc: Paulo Zanoni
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_gem.c | 12 ++--
drivers/gpu/drm/i915/intel_drv.h | 8
drivers/gpu/d
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 was being invalidated by fbdev and Plymounth
was taking
fbdev_set_par is called when fbcon is taking over control, but
frontbuffer was being invalidated only on the first time when
moving obj to GTT domain.
However on the following calls write domain was already GTT
so invalidate was never called again.
The issue was mainly on boot with plymouth doing
On Fri, Jul 03, 2015 at 09:01:44AM +0530, Kausal Malladi wrote:
> CHV/BSW platform supports various Gamma correction modes, which are:
> 1. Legacy 8-bit mode
> 2. 10-bit CGM (Color Gamut Mapping) mode
>
> This patch does the following:
> 1. Adds the core function to program Gamma correction values
On Fri, Jul 03, 2015 at 09:01:38AM +0530, Kausal Malladi wrote:
> This patch does the following:
> 1. Adds new files intel_color_manager(.c/.h)
> 2. Attaches color properties to CRTC while initialization
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Kausal Malladi
> ---
> drivers/gpu/drm/
On Fri, Jul 03, 2015 at 09:01:37AM +0530, Kausal Malladi wrote:
> Color Management is an extension to Kernel display framework. It allows
> abstraction of hardware color correction and enhancement capabilities by
> virtue of DRM properties.
>
> This patch initializes color management framework by
On Tue, Jul 07, 2015 at 10:13:01PM +0300, 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.
If they were optimal
On 07/07/2015 09:49 AM, Yu Dai wrote:
On 07/03/2015 07:09 AM, Mika Kuoppala wrote:
> Pass around requests to carry context deeper in callchain.
>
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 30 ++
> 1 file changed, 14 insertions(+),
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6734
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On Tue, 2015-07-07 at 13:24 +0200, Daniel Vetter wrote:
> On Mon, Jul 06, 2015 at 11:19:03PM +, Vivi, Rodrigo wrote:
> > On Mon, 2015-07-06 at 19:56 +0200, Daniel Vetter wrote:
> > > On Mon, Jul 06, 2015 at 02:11:55PM -0300, Paulo Zanoni wrote:
> > > > 2015-07-06 13:43 GMT-03:00 Vivi, Rodrigo :
On Tue, Jul 07, 2015 at 04:44:30PM +0100, Michel Thierry wrote:
> On 7/7/2015 4:27 PM, Chris Wilson wrote:
> >On Tue, Jul 07, 2015 at 04:14:59PM +0100, Michel Thierry wrote:
> >>In a 48b world, users can try to allocate buffers bigger than 4GB; in
> >>these cases it is important that size is a 64b
On Tue, Jul 07, 2015 at 03:26:02PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Before I continue sending fixes, let's just do some small adjustments to the
> codebase. I really think these changes make the code better to work with, but
> maybe not everybody agrees. Let's find out :)
>
>
On Tue, Jul 07, 2015 at 03:26:04PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Because the cool kids use dev_priv and FBC wants to be cool too.
>
> We've been historically using struct drm_device on the FBC function
> arguments, but we only really need it for intel_vgpu_active():
static
wa_ctx_emit() depends on the name of a local variable; if the name of that
variable is changed then we get compile errors. In this case it is unlikely
to be changed as this macro is only used in this set of functions but
Kernel coding guidelines doesn't recommend doing this. It was my mistake
as I
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 creates a fixed register set that is programmed across the different
engines so that all eng
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6732
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -4
On Mon, Jul 06, 2015 at 04:29:47PM +0200, Daniel Vetter wrote:
> On Fri, Jul 03, 2015 at 01:30:22PM +0100, Dave Gordon wrote:
> > This patch series enables command submission via the GuC. In this mode,
[TOR:] ...
> > created the original versions on which some of these patches are based.
>
> A f
From: Paulo Zanoni
So now all the calls are inside __intel_fbc_update(). Consistency!
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
From: Paulo Zanoni
This is all internal i915.ko work, let's start using intel_crtc for
everything.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/intel_fbc.c | 79 +++-
2 files changed, 40 insertions(+), 43 del
From: Paulo Zanoni
I have two separate refactor ideas that require extracting this to a
separate function. I'm not sure which idea I'll end choosing, but
since both will require extracting this function, let's do this now.
Notice that this is just code moving. Any possible problems with the
curr
From: Paulo Zanoni
The poor in_dbg_master() check was the only one without a reason
string. Give it a reason string so it won't feel excluded.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_fbc.c | 6 +-
2 files changed, 6 insertions(+),
From: Paulo Zanoni
Before I continue sending fixes, let's just do some small adjustments to the
codebase. I really think these changes make the code better to work with, but
maybe not everybody agrees. Let's find out :)
Paulo Zanoni (6):
drm/i915: move FBC vfuncs to struct i915_fbc
drm/i915:
From: Paulo Zanoni
Because the cool kids use dev_priv and FBC wants to be cool too.
We've been historically using struct drm_device on the FBC function
arguments, but we only really need it for intel_vgpu_active(): we can
use dev_priv everywhere else. So let's fully switch to dev_priv since
I'm
From: Paulo Zanoni
Because it makes more sense there, IMHO.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.h | 7 +++---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
drivers/gpu/drm/i915/intel_fbc.c | 44 ++--
3 files changed, 28 inse
Commit 712a0dd91c4a ("Documentation/drm: Update rotation property")
left an extra 'rowspan' for the row omap, which pushed the following qxl
rows columns out to column 8 and broke the tabulation.
Remove the errant rowspan.
Signed-off-by: Graham Whaley
---
Documentation/DocBook/drm.tmpl | 2 +-
1
Hi Kausal,
On 03/07/15 04:31, Kausal Malladi wrote:
> This patch adds new structures in DRM layer for Palette color correction.
> These structures will be used by user space agents to configure
> appropriate number of samples and Palette LUT for a platform.
>
> Signed-off-by: Shashank Sharma
> S
In Indirect context w/a batch buffer,
+WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken
v2: SKL revision id was used for BXT, copy paste error found during
internal review (Bob Beckett).
Cc: Robert Beckett
Cc: Imre Deak
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/intel_lrc.c
In Indirect and Per context w/a batch buffer,
+WaDisableCtxRestoreArbitration
v2: SKL revision id was used for BXT, copy paste error found during
internal review (Bob Beckett).
Cc: Robert Beckett
Cc: Imre Deak
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/intel_lrc.c | 13 +++-
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6731
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On 07/03/2015 07:09 AM, Mika Kuoppala wrote:
Pass around requests to carry context deeper in callchain.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 30 ++
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i91
On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 14:10 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
> >> Op 07-07-15 om 11:18 schreef Daniel Vetter:
> >>> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst
On Tue, Jul 07, 2015 at 04:32:44PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 14:10 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
> >> Op 07-07-15 om 11:18 schreef Daniel Vetter:
> >>> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst
On 6 July 2015 at 08:48, Daniel Vetter wrote:
> On Fri, Jul 03, 2015 at 01:52:04PM -0300, Paulo Zanoni wrote:
>> 2015-07-03 6:23 GMT-03:00 Dave Gordon :
>> > On 01/07/15 14:02, Daniel Vetter wrote:
>> >>
>> >> On Tue, Jun 30, 2015 at 11:14:54AM -0300, Paulo Zanoni wrote:
>> >>>
>> >>> 2015-06-30 1
On 07/07/2015 02:06 AM, Daniel Vetter wrote:
On Mon, Jul 06, 2015 at 05:00:52PM -0700, Yu Dai wrote:
>
>
> On 07/06/2015 11:21 AM, Daniel Vetter wrote:
> >On Mon, Jul 06, 2015 at 05:07:31PM +0100, Dave Gordon wrote:
> >> On 06/07/15 15:14, Daniel Vetter wrote:
> >> >On Fri, Jul 03, 2015 at 01:3
On 7/7/2015 4:27 PM, Chris Wilson wrote:
On Tue, Jul 07, 2015 at 04:14:59PM +0100, Michel Thierry wrote:
In a 48b world, users can try to allocate buffers bigger than 4GB; in
these cases it is important that size is a 64b variable.
Also added a warning for illegal bind with size = 0.
Signed-of
On Tue, Jul 07, 2015 at 04:14:59PM +0100, Michel Thierry wrote:
> In a 48b world, users can try to allocate buffers bigger than 4GB; in
> these cases it is important that size is a 64b variable.
>
> Also added a warning for illegal bind with size = 0.
>
> Signed-off-by: Michel Thierry
> ---
> d
This transitional patch doesn't do much for the existing code. However,
it should make upcoming patches to use the full 48b address space a bit
easier.
v2: Renamed pdp_free to be similar to pd/pt (unmap_and_free_pdp).
v3: To facilitate testing, 48b mode will be available on Broadwell and
GEN9+,
Use 48b addresses if hw supports it (i915.enable_ppgtt=3).
Note, aliasing PPGTT remains 32b only.
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
drivers/gpu/drm/i915/i915_params.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gp
The dynamic page allocation patch series added it for GEN6, this patch
adds them for GEN8.
v2: Consolidate pagetable/page_directory events
v3: Multiple rebases.
v4: Rebase after s/page_tables/page_table/.
v5: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
v6: Rebase after gen8_map
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 with flat/heapless (0x-0xf000)
Gen
Similar to PDs, while setting up a page directory pointer, make all entries
of the pdp point to the scratch pdp before mapping (and make all its entries
point to the scratch page); this is to be safe in case of out of bound
access or proactive prefetch.
v2: Handle scratch_pdp allocation failure c
These are the rebased patches, after Mika's final ppgtt clean-up series landed
(it relies in the macros added) and Akash review comments.
In order expand the GPU address space, a 4th level translation is added, the
Page Map Level 4 (PML4). This PML4 has 256 PML4 Entries (PML4E), PML4[0-255],
each
When 48b is enabled, gen8_ppgtt_insert_entries needs to read the Page Map
Level 4 (PML4), before it selects which Page Directory Pointer (PDP)
it will write to.
Similarly, gen8_ppgtt_clear_range needs to get the correct PDP/PD range.
This patch was inspired by Ben's "Depend exclusively on map and
gen8_clamp_pd clamps to the next page directory boundary, but the macro
gen8_for_each_pde already has a check to stop at the page directory boundary.
Furthermore, i915_pte_count also restricts to the next page table
boundary.
v2: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
Su
In 64b (48bit canonical) PPGTT addressing, the PDP0 register contains
the base address to PML4, while the other PDP registers are ignored.
In LRC, the addressing mode must be specified in every context descriptor.
v2: PML4 update in legacy context switch is left for historic reasons,
the preferre
v2: For semaphore errors, object is mapped to GGTT and offset will not
be > 4GB, print only lower 32-bits (Akash)
Cc: Akash Goel
Signed-off-by: Ben Widawsky
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_gpu_error.c | 18 ++-
Otherwise it can overflow in 48-bit mode, and cause an incorrect
exec_start.
Before commit 5f19e2bff ("drm/i915: Merged the many do_execbuf()
parameters into a structure"), it was already an u64, so it could be
seen as a regression (or as an optimization that looked good at that time).
Cc: John H
GTT was only 32b and its max value is 4GB. In order to allow objects
bigger than 4GB in 48b PPGTT, i915_gem_userptr_ioctl we could check
against max 48b range (1ULL << 48).
But since the check no longer applies, just kill the limit.
v2: Use the default ctx to infer the ppgtt max size (Akash).
v3:
v2: Clean up patch after rebases.
v3: gen8_dump_ppgtt for 32b and 48b PPGTT.
v4: Use used_pml4es/pdpes (Akash).
v5: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
v6: Rely on used_px bits instead of null checking (Akash)
Cc: Akash Goel
Signed-off-by: Ben Widawsky
Signed-off-by:
The insert_entries function was the function used to write PTEs. For the
PPGTT it was "hardcoded" to only understand two level page tables, which
was the case for GEN7. We can reuse this for 4 level page tables, and
remove the concept of insert_entries, which was never viable past 2
level page tabl
As a step towards implementing 4 levels, while not discarding the
existing pte insert functions, we need to pass the sg_iter through.
The current function understands to the page directory granularity.
An object's pages may span the page directory, and so using the iter
directly as we write the PTE
PML4 has no special attributes, and there will always be a PML4.
So simply initialize it at creation, and destroy it at the end.
The code for 4lvl is able to call into the existing 3lvl page table code
to handle all of the lower levels.
v2: Return something at the end of gen8_alloc_va_range_4lvl
Introduces the Page Map Level 4 (PML4), ie. the new top level structure
of the page tables.
To facilitate testing, 48b mode will be available on Broadwell and
GEN9+, when i915.enable_ppgtt = 3.
Cc: Akash Goel
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.h | 7 ++-
d
In a 48b world, users can try to allocate buffers bigger than 4GB; in
these cases it is important that size is a 64b variable.
Also added a warning for illegal bind with size = 0.
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem.c | 5 +++--
drivers/gpu/drm/i915/i915_gem_gtt.
Up until now, ppgtt->pdp has always been the root of our page tables.
Legacy 32b addresses acted like it had 1 PDP with 4 PDPEs.
In preparation for 4 level page tables, we need to stop use ppgtt->pdp
directly unless we know it's what we want. The future structure will use
ppgtt->pml4 for the top l
Op 07-07-15 om 14:10 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 11:18 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
This allows the first atomic call during hw init to be a real m
On ti, 2015-07-07 at 10:51 +, David Binderman wrote:
> Hello there,
>
> [linux-4.2-rc1/drivers/gpu/drm/i915/intel_csr.c:353]: (warning) Logical
> conjunction always evaluates to false: EXPR < 524288 && EXPR> 589823.
>
> Source code is
>
> if (dmc_header->mmioaddr[i] < CSR_MMIO_START_R
Op 07-07-15 om 14:10 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 11:18 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
This allows the first atomic call during hw init to be a real m
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6729
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -1
Op 07-07-15 om 14:39 schreef Patrik Jakobsson:
> On Tue, Jul 07, 2015 at 12:22:12PM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 11:18 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 09:08:14AM +0200, Maarten Lankhorst wrote:
This should fix suspend on newer platforms.
>>> Which patch
Op 07-07-15 om 13:16 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 09:08:18AM +0200, Maarten Lankhorst wrote:
>> Make sure the primary plane is set up correctly. This is done by
>> setting plane_state->src and plane_state->crtc.
>>
>> All non-primary planes get disabled.
> Too terse commit messa
Watermark calculations depend on the intel_crtc->active flag to be set
properly. Suspend/resume is broken on SKL and we also get DDB mismatches
without this patch.
The regression was introduced in:
commit eddfcbcdc27fbecb33bff098967bbdd7ca75bfa6
Author: Maarten Lankhorst
Date: Mon Jun 15 12:33
On 7/7/2015 1:56 PM, Goel, Akash wrote:
On 7/1/2015 8:57 PM, Michel Thierry wrote:
v2: Clean up patch after rebases.
v3: gen8_dump_ppgtt for 32b and 48b PPGTT.
v4: Use used_pml4es/pdpes (Akash).
v5: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
Signed-off-by: Ben Widawsky
Sig
On 7/7/2015 1:53 PM, Goel, Akash wrote:
On 7/1/2015 8:57 PM, Michel Thierry wrote:
@@ -476,13 +477,13 @@ int i915_error_state_to_str(struct
drm_i915_error_state_buf *m,
if ((obj = error->ring[i].ctx)) {
err_printf(m, "%s --- HW Context = 0x%08x\n",
de
On 7/7/2015 1:43 PM, Goel, Akash wrote:
On 7/1/2015 8:57 PM, Michel Thierry wrote:
@@ -795,13 +821,15 @@ static void gen8_ppgtt_cleanup(struct
i915_address_space *vm)
*
* Return: 0 if success; negative error code otherwise.
*/
-static int gen8_ppgtt_alloc_pagetabs(struct i915_hw_ppgtt
On 7/7/2015 1:51 PM, Goel, Akash wrote:
On 7/1/2015 8:57 PM, Michel Thierry wrote:
static void
@@ -781,9 +793,9 @@ gen8_ppgtt_insert_pte_entries(struct
i915_address_space *vm,
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
gen8_pte_t *pt_vaddr
On 7/7/2015 1:48 PM, Goel, Akash wrote:
On 7/1/2015 8:57 PM, Michel Thierry wrote:
@@ -1087,8 +1137,62 @@ static int gen8_alloc_va_range_4lvl(struct
i915_address_space *vm,
uint64_t start,
uint64_t length)
{
-WARN_ON(1); /* to be implemented la
On Tue, Jul 07, 2015 at 09:08:11AM +0200, Maarten Lankhorst wrote:
> This patch series requires
> [PATCH] drm/atomic: pass old crtc state to atomic_begin/flush.
> and highly recommends, but optional:
> [PATCH 2/2] drm/atomic: Cleanup on error properly in the atomic ioctl.
>
> This series adds full
On Tue, Jul 07, 2015 at 02:22:20PM +0530, Sonika Jindal wrote:
> Writing to PCH_PORT_HOTPLUG for each interrupt is not required.
> Handle it only if hpd has actually occurred like we handle other
> interrupts.
> v2: Make few variables local to if block (Ville)
> v3: Add check for ibx/cpt both (Vill
On Tue, Jul 07, 2015 at 12:51:06PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 11:33 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 09:08:29AM +0200, Maarten Lankhorst wrote:
> >> No point in applying vblank evasion if there's nothing to evade.
> >>
> >> Signed-off-by: Maarten Lankhorst
>
On Tue, Jul 07, 2015 at 12:50:39PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 11:48 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 09:08:25AM +0200, Maarten Lankhorst wrote:
> >> Calculate all state using a normal transition, but afterwards fudge
> >> crtc->state->active back to its old v
On Tue, Jul 07, 2015 at 03:14:57PM +0200, Daniel Vetter wrote:
> On Tue, Jul 07, 2015 at 12:33:25PM +0200, Maarten Lankhorst wrote:
> > Op 07-07-15 om 11:57 schreef Daniel Vetter:
> > > On Tue, Jul 07, 2015 at 09:08:21AM +0200, Maarten Lankhorst wrote:
> > > Since we've only badly bruised escape th
On Tue, Jul 07, 2015 at 06:10:12PM +0530, Animesh Manna wrote:
> v1: Based on review comments from Daniel following changes are done.
> - More focus is given for better synchronization.
> - Replaced async firmware loading by using request_firmawre() call.
> - Prevented entering in dc5/dc6 while fir
On Tue, Jul 07, 2015 at 12:48:36PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 12:17 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 09:08:24AM +0200, Maarten Lankhorst wrote:
> >> And get rid of things that are no longer true. This function is only
> >> used for forcing a modeset when enco
On Tue, Jul 07, 2015 at 12:33:25PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 11:57 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 09:08:21AM +0200, Maarten Lankhorst wrote:
> >> @@ -10421,10 +10414,6 @@ void intel_release_load_detect_pipe(struct
> >> drm_connector *connector,
> >>
On 7/7/2015 1:36 PM, Goel, Akash wrote:
On 7/1/2015 8:57 PM, Michel Thierry wrote:
This transitional patch doesn't do much for the existing code. However,
it should make upcoming patches to use the full 48b address space a bit
easier. The patch also introduces the PML4, ie. the new top level
s
On 7/1/2015 8:57 PM, Michel Thierry wrote:
v2: Clean up patch after rebases.
v3: gen8_dump_ppgtt for 32b and 48b PPGTT.
v4: Use used_pml4es/pdpes (Akash).
v5: Rebase after Mika's ppgtt cleanup / scratch merge patch series.
Signed-off-by: Ben Widawsky
Signed-off-by: Michel Thierry (v2+)
---
On 7/1/2015 8:57 PM, Michel Thierry wrote:
Signed-off-by: Ben Widawsky
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_gpu_error.c | 17 +
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/
On 7/1/2015 8:57 PM, Michel Thierry wrote:
When 48b is enabled, gen8_ppgtt_insert_entries needs to read the Page Map
Level 4 (PML4), before it selects which Page Directory Pointer (PDP)
it will write to.
Similarly, gen8_ppgtt_clear_range needs to get the correct PDP/PD range.
This patch was i
On 7/1/2015 8:57 PM, Michel Thierry wrote:
PML4 has no special attributes, and there will always be a PML4.
So simply initialize it at creation, and destroy it at the end.
The code for 4lvl is able to call into the existing 3lvl page table code
to handle all of the lower levels.
v2: Return so
On 7/1/2015 8:57 PM, Michel Thierry wrote:
Up until now, ppgtt->pdp has always been the root of our page tables.
Legacy 32b addresses acted like it had 1 PDP with 4 PDPEs.
In preparation for 4 level page tables, we need to stop use ppgtt->pdp
directly unless we know it's what we want. The futu
v1: Based on review comments from Daniel following changes are done.
- More focus is given for better synchronization.
- Replaced async firmware loading by using request_firmawre() call.
- Prevented entering in dc5/dc6 while firmware loading in process.
Now register programming for dc5/dc6 always w
On Tue, Jul 07, 2015 at 12:22:12PM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 11:18 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 09:08:14AM +0200, Maarten Lankhorst wrote:
> >> This should fix suspend on newer platforms.
> > Which patch broke this? Also what is "newer platform" and what
On 7/1/2015 8:57 PM, Michel Thierry wrote:
This transitional patch doesn't do much for the existing code. However,
it should make upcoming patches to use the full 48b address space a bit
easier. The patch also introduces the PML4, ie. the new top level structure
of the page tables.
Would be
Thanks! I had question about power context.
I was curious about HW context and once dumped the GEM context object on
GEN6 before.
According to B-spec, Gen Graphics » BSpec » 3D-Media-GPGPU Engine »
Registers in Render Engine » Render Logical Context Data » Register
State Context [SNB+] » Reg
On 7/7/2015 5:24 PM, Ville Syrjälä wrote:
On Tue, Jul 07, 2015 at 02:37:46PM +0300, Ville Syrjälä wrote:
On Tue, Jul 07, 2015 at 04:45:11PM +0530, Sivakumar Thulasimani wrote:
On 7/7/2015 4:40 PM, Ville Syrjälä wrote:
On Tue, Jul 07, 2015 at 03:26:36PM +0530, Sivakumar Thulasimani wrote:
O
1 - 100 of 190 matches
Mail list logo
