On 01 Jul 2015 14:52, Patrik Jakobsson wrote:
> Use pkg-config to try to find libdrm. If that fails use the standard
> include directory for kernel drm headers in /usr/include/drm.
>
> * configure.ac: Use pkg-config to find libdrm
>
> Signed-off-by: Patrik Jakobsson
> ---
> configure.ac | 4 +++
On 23 Jul 2015 13:44, Dmitry V. Levin wrote:
> On Thu, Jul 23, 2015 at 05:48:21AM -0400, Mike Frysinger wrote:
> > On 01 Jul 2015 14:52, Patrik Jakobsson wrote:
> > > Use pkg-config to try to find libdrm. If that fails use the standard
> > > include directory for kernel drm headers in /usr/include/
Any inputs on this patch ?
- Vandana
On 7/6/2015 4:35 PM, Vandana Kannan wrote:
From: Deepak M
LFP brighness control from the VBT block 43 indicates which
controller is used for brightness.
LFP1 brightness control method:
Bit 7-4 = This field controller number of the brightnes controller.
0 =
From: Rafał Sapała
It is possible to hit a race condition in create_from_prime, when trying
to import a BO that's currently being freed. In case of prime sharing
we'll succesfully get a handle, but fail on get_tiling call, potentially
confusing the caller (and requiring different locking scheme t
It is possible to race between unreference of the underlying BO and
importing it from prime_fd/name. Verify that the behaviour of libdrm
is consistent for prime/flink.
Signed-off-by: Michał Winiarski
---
tests/drm_import_export.c | 103 ++
1 file chang
On Fri, Jul 24, 2015 at 11:22:34AM +0200, Michał Winiarski wrote:
> From: Rafał Sapała
>
> It is possible to hit a race condition in create_from_prime, when trying
> to import a BO that's currently being freed. In case of prime sharing
> we'll succesfully get a handle, but fail on get_tiling call
On 21/07/2015 15:51, Tomas Elf wrote:
This patch series introduces the following features:
* Feature 1: TDR (Timeout Detection and Recovery) for gen8 execlist mode.
TDR is an umbrella term for anything that goes into detecting and recovering
from GPU hangs and is a term more widely used outsid
Sorting became confused and a few new files ended up in strange
places. Also move i915_irq.c to core since with the recent-ish
extraction of i915_gpu_error.c and intel_hotplug.c it's more and more
really just basic irq handling code.
When adding new files please don't put them somewhere randomly.
No code changes, just moving all the fence related code into a
separate file (and avoiding a bunch of forward declarations while at
it).
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.h | 16 +-
drivers/gpu/drm/i915/i915_gem.c
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl| 5 +++
drivers/gpu/drm/i915/i915_gem_fence.c | 75 +++
2 files changed, 80 insertions(+)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 458772e6ce08..86c9
On Fri, Jul 24, 2015 at 01:55:11PM +0200, Daniel Vetter wrote:
> No code changes, just moving all the fence related code into a
> separate file (and avoiding a bunch of forward declarations while at
> it).
As well as i915_gem_tiling? i915_gem_fence is a better name, so can we
move the tiling ioctl
On Fri, Jul 24, 2015 at 01:55:12PM +0200, Daniel Vetter wrote:
> Signed-off-by: Daniel Vetter
> ---
> Documentation/DocBook/drm.tmpl| 5 +++
> drivers/gpu/drm/i915/i915_gem_fence.c | 75
> +++
> 2 files changed, 80 insertions(+)
>
> diff --git a/Document
In CABC (Content Adaptive Brightness Control) content grey level
scale can be increased while simultaneously decreasing
brightness of the backlight to achieve same perceived brightness.
The CABC is not standardized and panel vendors are free to follow
their implementation. The CABC implementaion h
These benchmarks are first-and-foremost development tools, not aimed at
general users. As such they should not be installed into the system-wide
bin/ directory, but installing into libexec/ is a possibility when we
adpot a benchmarking system.
Signed-off-by: Chris Wilson
---
benchmarks/Makefile.
On Tue, 2015-07-21 at 16:09 +0200, Maarten Lankhorst wrote:
> -EDEADLK has special meaning in atomic, but get_fence may call
> i915_find_fence_reg which can return -EDEADLK.
>
> This has special meaning in the atomic world, so convert the error
> to -EBUSY for this case.
Doesn't this change the b
On 24 July 2015 at 10:24, Michał Winiarski wrote:
> It is possible to race between unreference of the underlying BO and
> importing it from prime_fd/name. Verify that the behaviour of libdrm
> is consistent for prime/flink.
Could you add this description into the source file as a comment?
There a
There are two versions of gem_exec_nop.c in benchmarks and tests
which causes the build system to have two build modules with
the same name.
This patch renames benchmarks/gem_exec_nop.c to
benchmarks/gem_exec_nop_benchmark.c using the existing
gem_userptr_benchmark.c as a naming convention.
v2: Al
On Fri, Jul 24, 2015 at 02:35:29PM +0100, Derek Morton wrote:
> There are two versions of gem_exec_nop.c in benchmarks and tests
> which causes the build system to have two build modules with
> the same name.
> This patch renames benchmarks/gem_exec_nop.c to
> benchmarks/gem_exec_nop_benchmark.c us
On Fri, Jul 24, 2015 at 04:26:27PM +0300, Ander Conselvan De Oliveira wrote:
> On Tue, 2015-07-21 at 16:09 +0200, Maarten Lankhorst wrote:
> > -EDEADLK has special meaning in atomic, but get_fence may call
> > i915_find_fence_reg which can return -EDEADLK.
> >
> > This has special meaning in the a
It is possible to race between unreference of the underlying BO and
importing it from prime_fd/name. Verify that the behaviour of libdrm
is consistent for prime/flink.
v2: more comments in source file, dropped extra whitespace
Signed-off-by: Michał Winiarski
Cc: Thomas Wood
---
tests/drm_impor
On 24 July 2015 at 14:43, Chris Wilson wrote:
> On Fri, Jul 24, 2015 at 02:35:29PM +0100, Derek Morton wrote:
>> There are two versions of gem_exec_nop.c in benchmarks and tests
>> which causes the build system to have two build modules with
>> the same name.
>> This patch renames benchmarks/gem_e
On 24 July 2015 at 15:43, Michał Winiarski wrote:
> It is possible to race between unreference of the underlying BO and
> importing it from prime_fd/name. Verify that the behaviour of libdrm
> is consistent for prime/flink.
>
> v2: more comments in source file, dropped extra whitespace
Thanks, pa
On 24 July 2015 at 14:35, Derek Morton wrote:
> There are two versions of gem_exec_nop.c in benchmarks and tests
> which causes the build system to have two build modules with
> the same name.
> This patch renames benchmarks/gem_exec_nop.c to
> benchmarks/gem_exec_nop_benchmark.c using the existin
Afaict intel_irq_fini never existed. No idea how that one came
about.
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index d7dc91b7e98c..e56bc0d01fdd 100644
--- a/D
Chris rightfully suggested that documenting fences without documenting
the BO tiling tracking doesn't make much sense, so fix that.
The important bit to stress here (since it lead to some confusion) is
the GEM doesn't really care about tiling. Except for a few select cases
where the kernel needs t
It fits more with the low-level fence code, and this move leaves only
the userspace tiling ioctl handling in i915_gem_tiling.c.
Suggested-by: Chris Wilson
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h| 8 +-
drivers/gpu/drm/i915/i915_gem_fence.c |
v2: Clarify that this is about fence _registers_. Also clarify that
the fence code revokes cpu ptes and not gtt ptes. Both suggested by
Chris.
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl| 5 +++
drivers/gpu/drm/i915/i915_gem_fence.c | 75 +++
On Fri, Jul 24, 2015 at 05:40:13PM +0200, Daniel Vetter wrote:
> Afaict intel_irq_fini never existed. No idea how that one came
> about.
It's notable by its absence. We should write it! There are a few steps
in intel_irq_init() that would be best undone intel_irq_fini(). The work
handlers could be
On Fri, Jul 24, 2015 at 05:40:12PM +0200, Daniel Vetter wrote:
> v2: Clarify that this is about fence _registers_. Also clarify that
> the fence code revokes cpu ptes and not gtt ptes. Both suggested by
> Chris.
>
> Cc: Chris Wilson
> Signed-off-by: Daniel Vetter
Quibble over 2, but 1,3,4 are
R
>
>
>-Original Message-
>From: Thomas Wood [mailto:thomas.w...@intel.com]
>Sent: Friday, July 24, 2015 4:33 PM
>To: Morton, Derek J
>Cc: Intel Graphics Development; Gore, Tim
>Subject: Re: [PATCH i-g-t v2] benchmark/: fix gem_exec_nop complie error on
>android
>
>On 24 July 2015 at 14:35,
Found a simpler way of doing this using 'LOCAL_MODULE'. Will prepare a
replacement patch.
//Derek
>
>
>-Original Message-
>From: Morton, Derek J
>Sent: Thursday, July 23, 2015 1:59 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Wood, Thomas; Gore, Tim; Morton, Derek J
>Subject: [PATCH i-g
On Thu, 23 Jul 2015 17:26:15 +0200,
David Henningsson wrote:
>
> Changes since v2 is that the patch set has diminished to not transfer
> connector/eld information, since it might be better that such information
> to be transferred by a separate call in the ordinary direction. That
> could be added
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6855
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On Thu, Jul 23, 2015 at 04:35:45PM -0700, Rodrigo Vivi wrote:
> Right now if we face any kind of error sink crc calculation
> stays enabled.
>
> So, let's give a shot and try to stop it anyway if it got enabled.
>
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_dp.c | 9 +--
On Thu, Jul 23, 2015 at 04:35:46PM -0700, Rodrigo Vivi wrote:
> If we got to the point where we are trying to stop sink CRC
> the main output of this function was already gotten properly,
> so don't return the error and let userspace use the crc data.
>
> Let's replace the errnos returns with some
On Fri, Jul 24, 2015 at 11:25 AM Rafael Antognolli <
rafael.antogno...@intel.com> wrote:
> On Thu, Jul 23, 2015 at 04:35:46PM -0700, Rodrigo Vivi wrote:
> > If we got to the point where we are trying to stop sink CRC
> > the main output of this function was already gotten properly,
> > so don't re
On Tue, Jul 21, 2015 at 08:38:35AM +0200, Daniel Vetter wrote:
> On Fri, Jul 17, 2015 at 05:38:05PM -0700, O'Rourke, Tom wrote:
> > On Thu, Jul 09, 2015 at 07:29:04PM +0100, Dave Gordon wrote:
> > > intel_guc_fwif.h contains the subset of the GuC interface that we
> > > will need for submission of
On Thu, Jul 09, 2015 at 07:29:07PM +0100, Dave Gordon wrote:
> GuC submission is basically execlist submission, but with the GuC
> handling the actual writes to the ELSP and the resulting context
> switch interrupts. So to prepare a context for submission via the
> GuC, we need some of the same fun
[TOR:] When I see "phase 1" I also look for "phase 2".
A subject that better describes the change in this patch
would help.
On Thu, Jul 09, 2015 at 07:29:08PM +0100, Dave Gordon wrote:
> From: Alex Dai
>
> This adds the first of the data structures used to communicate with the
> GuC (the pool
On Thu, Jul 09, 2015 at 07:29:09PM +0100, Dave Gordon wrote:
> From: Alex Dai
>
> Allocate a GEM object to hold GuC log data. A debugfs interface
> (i915_guc_log_dump) is provided to print out the log content.
>
> v2:
> Add struct members at point of use [Chris Wilson]
>
> v4:
> Rebased
Since active function on VLV immediately activate PSR let's give more
time for idleness. Different from core platforms where we have idle_frames
count.
Also kms_psr_sink_crc now is automated and always get this:
[drm:intel_enable_pipe] enabling pipe A
[drm:intel_edp_backlight_on]
[drm:intel_panel
We also need to call the frontbuffer flip to trigger proper
invalidations when disabling planes. Otherwise we will miss
screen updates when disabling sprites or cursor.
It was caught with kms_psr_sink_crc sprite_plane_onoff
and cursor_plane_onoff subtests.
This is probably a regression since I ca
Since active function on VLV immediately activate PSR let's give more
time for idleness. Different from core platforms where we have idle_frames
count.
Also kms_psr_sink_crc now is automated and always get this:
[drm:intel_enable_pipe] enabling pipe A
[drm:intel_edp_backlight_on]
[drm:intel_panel
On Thu, Jul 09, 2015 at 07:29:10PM +0100, Dave Gordon wrote:
> 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 subm
Changes since v1 [1]:
1/ Drop the attempt at unifying ioremap() prototypes, just focus on
converting ioremap_cache and ioremap_wt over to memremap (Christoph)
2/ Drop the unrelated cleanups to use %pa in __ioremap_caller (Thomas)
3/ Add support for memremap() attempts on "System RAM" to simpl
acpi_os_ioremap uses cached mappings, however it appears that i915
wants to read dynamic platform state. Switch to ioremap() to prevent it
reading stale state from cache.
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: intel-gfx@lists.freedesktop.org
Cc: David Airlie
Cc: dri-de...@lists.freedesktop.org
46 matches
Mail list logo
