On Thu, Jul 30, 2015 at 09:49:30AM +0300, Mika Kahola wrote:
> It is possible the we request to have a mode that has
> higher pixel clock than our HW can support. This patch
> checks if requested pixel clock is lower than the one
> supported by the HW. The requested mode is discarded
> if we cannot
Op 29-07-15 om 15:26 schreef Ander Conselvan De Oliveira:
> On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
>> Now that everything's atomic, checking encoder->base.crtc is enough.
> Don't you need to check encoder->base.crtc->state->active too?
Not sure, I think stealing a encoder being
On Thu, Jul 30, 2015 at 09:49:33AM +0300, Mika Kahola wrote:
> It is possible the we request to have a mode that has
> higher pixel clock than our HW can support. This patch
> checks if requested pixel clock is lower than the one
> supported by the HW. The requested mode is discarded
> if we cannot
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to TV.
V2:
- r
From EDID we can read and request higher pixel clock than
our HW can support. This set of patches add checks if
requested pixel clock is lower than the one supported by the HW.
The requested mode is discarded if we cannot support the requested
pixel clock. For example for Cherryview
'cvt 2560 1600
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to SDVO.
V2:
-
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to DSI.
V2:
-
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to DisplayPort
Information on maximum supported DOT clock frequency to
i915_frequency_info.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 23a69307..4ba02b5
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to DisplayPort.
Store max dotclock into dev_priv structure so we are able
to filter out the modes that are not supported by our
platforms.
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 20
2 files changed, 21 insertions(+)
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to DVO.
V2:
-
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to CRT.
V2:
-
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to LVDS.
V2:
-
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to HDMI.
V2:
-
On Thu, Jul 30, 2015 at 4:43 AM, Dave Airlie wrote:
> (are there any closed source compositors?)
Afaik everyone's hwc driver for surface flinger is a blob and only
code-dropped for nexus devices since google requires that. So can't
really use those one-offs to develop new stuff since it's a fork
On 7/29/2015 9:54 PM, Michel Thierry wrote:
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 | 5 ++---
drivers/gpu/drm/i915/i915_params.c | 2 +-
2 files changed, 3 in
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On 7/29/2015 9:54 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
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On 7/29/2015 9:54 PM, Michel Thierry wrote:
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 c
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On 7/29/2015 9:53 PM, Michel Thierry wrote:
Otherwise it can overflow in 48-bit mode, and cause an incorrect
exec_start.
Before commit 5f19e2bffa63a91cd4ac1adcec648e14a44277ce ("drm/i915: Merged
the many do_execbuf() parameters int
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On 7/29/2015 9:53 PM, 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.
v2: Drop the warning about bind with size 0, it shouldn't hap
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On 7/29/2015 9:53 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.
v6: Rely
On Wed, Jul 29, 2015 at 6:39 PM, Theodore Ts'o wrote:
>
> It's here: https://goo.gl/photos/xHjn2Z97JQEw6k2C9
You didn't catch enough of the code line to decode the code, but it's
early enough in drm_crtc_index() (just five bytes in) that it's almost
certainly the very first dereference, so it's
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On 7/29/2015 9:53 PM, Michel Thierry wrote:
v2: For semaphore errors, object is mapped to GGTT and offset will not
be > 4GB, print only lower 32-bits (Akash)
v3: Print gtt_offset in groups of 32-bit (Chris)
Cc: Akash Goel
Cc: Chris
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On 7/29/2015 9:53 PM, Michel Thierry wrote:
Similar to PDs, while setting up a page directory pointer, make all entries
of the pdp point to the scratch pd before mapping (and make all its entries
point to the scratch page); this is t
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On 7/29/2015 9:53 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
On 7/29/2015 9:53 PM, Michel Thierry wrote:
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
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On 7/29/2015 9:53 PM, Michel Thierry wrote:
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
On 7/29/2015 9:53 PM, Michel Thierry wrote:
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, and the base address to PML4 is stor
On 7/29/2015 8:52 PM, Benjamin Tissoires wrote:
On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote:
why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you can
identify both lane count and reversal state without touching anything in the
link training code. i am yet to
On 7/29/2015 9:53 PM, Michel Thierry wrote:
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.
v2: Remove unnecessary CONFIG_X86_64 checks, ppgtt code
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On 7/29/2015 9:53 PM, Michel Thierry wrote:
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_tab
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On 7/29/2015 9:53 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.
v2: Renamed pdp_free to be similar
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On 7/29/2015 9:53 PM, Michel Thierry wrote:
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 restr
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/drm_crtc.c
between commit:
5677d67ae394 ("drm: Stop resetting connector state to unknown")
from Linus' tree and commit:
1c473be11958 ("drm: Fixup locking WARNINGs in drm_mode_config_reset")
from th
> I've discussed drm props and ABI requirements a bit with Dave on irc.
> In the past we've been pretty lax with properties since connector
> properties are mostly meant for end-users to set manually, so not
> really much point in standardizing and treating them like ABI. But now
> we have props fo
On Wed, Jul 29, 2015 at 08:49:37PM -0400, Theodore Ts'o wrote:
>
> Unfortunately the failure causes a series of recursive faults and I
> haven't been able to capture the stack trace, but on 4.2-rcX kernels,
> I can reliably cause the system to crash if my T540p is booted with
> the docking station
Unfortunately the failure causes a series of recursive faults and I
haven't been able to capture the stack trace, but on 4.2-rcX kernels,
I can reliably cause the system to crash if my T540p is booted with
the docking station attached.
It will also crash if I boot the system first, and then inser
On Wed, Jul 29, 2015 at 11:15:23PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Wednesday 29 July 2015 08:32:43 Daniel Vetter wrote:
> > With
> >
> > commit 7a3f3d6667f5f9ffd1517f6b21d64bbf5312042c
> > Author: Daniel Vetter
> > Date: Thu Jul 9 23:44:28 2015
On 07/07/2015 02:15 AM, Tvrtko Ursulin wrote:
>
> On 07/06/2015 01:58 PM, John Harrison wrote:
>> On 06/07/2015 10:29, Daniel Vetter wrote:
>>> On Fri, Jul 03, 2015 at 12:17:33PM +0100, Tvrtko Ursulin wrote:
On 07/02/2015 04:55 PM, Chris Wilson wrote:
> It would be nice if we could reuse
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Damien Lespiau
> Sent: Thursday, July 16, 2015 9:08 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 1/2] drm/i915/skl: Don't expose the top most plane
> on gen9 di
Hi Daniel,
Thank you for the patch.
On Wednesday 29 July 2015 08:32:43 Daniel Vetter wrote:
> With
>
> commit 7a3f3d6667f5f9ffd1517f6b21d64bbf5312042c
> Author: Daniel Vetter
> Date: Thu Jul 9 23:44:28 2015 +0200
>
> drm: Check locking in drm_for_each_connector
>
> we started checking t
With this simple git diff command one can see that skl_init_workarounds()
got two copies of WaBarrierPerformanceFixDisable:skl:
git diff -U21 ca6e4405779e^1 ca6e4405779e
drivers/gpu/drm/i915/intel_ringbuffer.c
This happened when the backmerge of drm-intel-fixes-2015-07-15
Merged the same fix on
If the device does not support the aliasing ppgtt, we must translate
user bind requests (PIN_USER) from LOCAL_BIND to a GLOBAL_BIND. However,
since this is device specific we cannot do this conveniently in the
upper layers and so must manage the vma->bound flags in the backend.
Partial revert of c
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Damien Lespiau
> Sent: Thursday, July 16, 2015 9:08 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 1/2] drm/i915/skl: Don't expose the top most plane
> on gen9 di
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
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 provides a means of reading status and counts relating
to GuC actions and submissions.
v2:
Remove surplus blank line in output [Chris Wilson]
v5:
Added GuC per-engine submission & seqno statistics
Signed-off-by: Dave Gordon
Signed-off-by: Alex Dai
---
drivers/gpu/drm/i915/i915_de
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 describe a context for submission via
the GuC, we need one of the same functions used in execlist mode.
This commit exposes one such function,
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
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
Signed-off-by: Dave Gordon
v5:
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 5ae4b0a..9263a7e 100644
--- a/driv
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]
v5:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drive
Turn on interrupt steering to route necessary interrupts to GuC.
v5:
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
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
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
v5:
Rebased
Issue: VIZ-4884
Signed-off-by:
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.
v2: Remove unnecessary CONFIG_X86_64 checks, ppgtt code is already
32/64-bit safe (Chris).
v3: Add goto
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 | 5 ++---
drivers/gpu/drm/i915/i915_params.c | 2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/g
Check if the required page tables are already allocated, if so, we can
skip altogether the inner loop of pdes, and move to the next page
directory.
If the new allocation is different than the existing one (i.e. new
allocation spans more ptes than already covered from earlier allocations),
the used
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
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, and the base address to PML4 is stored in the reg state.
v2: PML4 update in legacy
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.
v2: Drop the warning about bind with size 0, it shouldn't happen anyway.
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem.c | 5 +++--
1 file changed, 3 i
Similar to PDs, while setting up a page directory pointer, make all entries
of the pdp point to the scratch pd 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.
Also add a scratch pdp, which the PML4 entri
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
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
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
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+,
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
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
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:
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
v2: For semaphore errors, object is mapped to GGTT and offset will not
be > 4GB, print only lower 32-bits (Akash)
v3: Print gtt_offset in groups of 32-bit (Chris)
Cc: Akash Goel
Cc: Chris Wilson
Signed-off-by: Ben Widawsky
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.h
Otherwise it can overflow in 48-bit mode, and cause an incorrect
exec_start.
Before commit 5f19e2bffa63a91cd4ac1adcec648e14a44277ce ("drm/i915: Merged
the many do_execbuf() parameters into a structure"), it was already an u64.
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.h |
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
This clean-up version delays the 48-bit work to later patches and includes
more review comments from Akash and Chris. The first 5 patches prepare the
dynamic page allocation code to handle independent pdps, but no specific
code for 48-bit mode is added before the 5th patch.
In order expand the GPU
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:
On Wed, Jul 29, 2015 at 10:26:53AM +0200, Daniel Vetter wrote:
> On Tue, Jul 28, 2015 at 10:05:21PM +, Vivi, Rodrigo wrote:
> > On Tue, 2015-07-28 at 13:25 -0700, Rafael Antognolli wrote:
> > > On Thu, Jul 23, 2015 at 04:35:50PM -0700, Rodrigo Vivi wrote:
> > > > By Vesa DP 1.2 spec TEST_CRC_CO
As the scratch page is no longer shared between all VM, and each has
their own, forgo the small allocation and simply embed the scratch page
struct into the i915_address_space.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 81 -
drivers
Since by design, if not entirely by practice, nothing is allowed to
access the scratch page we use to background fill the VM, then we do not
need to ensure that it is coherent between the CPU and GPU.
set_pages_uc() does a stop_machine() after changing the PAT, and that
significantly impacts upon c
>
>
>-Original Message-
>From: Gordon, David S
>Sent: Wednesday, July 29, 2015 4:15 PM
>To: Chris Wilson; Gore, Tim; Morton, Derek J; intel-gfx@lists.freedesktop.org;
>Wood, Thomas
>Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/gem_render_linear_blits: Increase
>min swap required
>
>On 29
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Wednesday, July 29, 2015 4:20 PM
> To: Gordon, David S
> Cc: Gore, Tim; Morton, Derek J; intel-gfx@lists.freedesktop.org; Wood,
> Thomas
> Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/gem_render_linear_blits
On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote:
> why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you can
> identify both lane count and reversal state without touching anything in the
> link training code. i am yet to upstream my changes for CHT that i can share
>
On 09/07/2015 12:14, Chris Wilson wrote:
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 hol
On Jul 28 2015 or thereabouts, Chris Wilson wrote:
> On Tue, Jul 28, 2015 at 12:03:28PM -0400, Benjamin Tissoires wrote:
> > We check the polarity of the attached dp, so it is normal to fail.
> > Do not send errors to the users.
>
> if (probe) DRM_DEBUG else DRM_ERROR is fairly offensive.
>
> It
On Wed, Jul 29, 2015 at 04:14:55PM +0100, Dave Gordon wrote:
> On 29/07/15 14:15, Chris Wilson wrote:
> >On Wed, Jul 29, 2015 at 01:10:23PM +, Gore, Tim wrote:
> >>I don’t see how this implies a kernel bug. It seems like a test problem (my
> >>subtest as it happens). I was unaware of Android sy
On 09/07/2015 12:12, Chris Wilson wrote:
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
On 29/07/15 14:15, Chris Wilson wrote:
On Wed, Jul 29, 2015 at 01:10:23PM +, Gore, Tim wrote:
I don’t see how this implies a kernel bug. It seems like a test problem (my
subtest as it happens). I was unaware of Android systems with small swap
partitions (or indeed any swap at all). Not sure
On 7/16/2015 10:33 AM, Michel Thierry wrote:
Similar to PDs, while setting up a page directory pointer, make all entries
of the pdp point to the scratch pd 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.
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Wednesday, July 29, 2015 2:16 PM
> To: Gore, Tim
> Cc: Morton, Derek J; intel-gfx@lists.freedesktop.org; Wood, Thomas
> Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/gem_render_linear_blits: Increase
> min
On 7/16/2015 10:33 AM, Michel Thierry wrote:
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
On 7/16/2015 10:33 AM, Michel Thierry wrote:
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, and the base address to PML4 is store
On 7/16/2015 10:33 AM, 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
Undocking helps, and then I can dock again.
This happens at a hardened 64 bit Gentoo with i915, but I think, it is
not hardened related, or ?
--
Toralf, pgp key: 872AE508 0076E94E
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists
On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
> Now that everything's atomic, checking encoder->base.crtc is enough.
Don't you need to check encoder->base.crtc->state->active too?
> Cc: Ville Syrjälä
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_dp.c | 7 +
On Wed, Jul 29, 2015 at 01:10:23PM +, Gore, Tim wrote:
> I don’t see how this implies a kernel bug. It seems like a test problem (my
> subtest as it happens). I was unaware of Android systems with small swap
> partitions (or indeed any swap at all). Not sure I can understand the logic of
> such
Tim Gore
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Chris Wilson
> Sent: Wednesday, July 29, 2015 10:56 AM
> To: Morton, Derek J
> Cc: intel-gfx@list
On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
> connectors_active will be removed, so just calculate this right here.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_display.c | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> di
Op 29-07-15 om 14:31 schreef Ander Conselvan De Oliveira:
> On Wed, 2015-07-29 at 14:04 +0200, Daniel Vetter wrote:
>> On Wed, Jul 29, 2015 at 02:49:45PM +0300, Ander Conselvan De Oliveira
>> wrote:
>>> On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
Instead of allocating pipe_con
Hi all,
I've discussed drm props and ABI requirements a bit with Dave on irc.
In the past we've been pretty lax with properties since connector
properties are mostly meant for end-users to set manually, so not
really much point in standardizing and treating them like ABI. But now
we have props for
On Wed, 2015-07-29 at 14:04 +0200, Daniel Vetter wrote:
> On Wed, Jul 29, 2015 at 02:49:45PM +0300, Ander Conselvan De Oliveira
> wrote:
> > On Mon, 2015-07-27 at 14:35 +0200, Maarten Lankhorst wrote:
> > > Instead of allocating pipe_config on the stack use the old
> > > crtc_state,
> > > it's on
1 - 100 of 123 matches
Mail list logo
