On 08/26/2016 01:10 AM, Daniel Vetter wrote:
On Thu, Aug 25, 2016 at 05:55:18PM +0530, Archit Taneja wrote:
On 08/18/2016 02:26 AM, Daniel Vetter wrote:
+void drm_mode_object_unregister(struct drm_device *dev,
+ struct drm_mode_object *object);
Alignment issue
On Thu, Aug 25, 2016 at 01:43:53PM -0700, Ian Romanick wrote:
> On 08/24/2016 12:42 PM, Chris Wilson wrote:
> > +#define I915_PARAM_MMAP_GTT_VERSION 40 /* XXX delete me with new libdrm */
> > + if (intel_get_integer(intelScreen, I915_PARAM_MMAP_GTT_VERSION) >= 1) {
> > + /* Theorectically un
On Mon, Aug 8, 2016 at 1:33 AM, Jani Nikula wrote:
> On Sat, 06 Aug 2016, Rodrigo Vivi wrote:
>> This patch is blocking PSR on panels that we know that our hardware support.
>
> And it also fixes a regression on Linus' laptop, and it's been merged
> upstream...
yeap, this patch is like setting i
On Thu, Aug 25, 2016 at 05:55:18PM +0530, Archit Taneja wrote:
> On 08/18/2016 02:26 AM, Daniel Vetter wrote:
> > +void drm_mode_object_unregister(struct drm_device *dev,
> > + struct drm_mode_object *object);
>
> Alignment issue in the declaration here.
Again I don't li
On Thu, Aug 25, 2016 at 05:53:51PM +0530, Archit Taneja wrote:
>
> Hi,
>
> On 08/18/2016 02:25 AM, Daniel Vetter wrote:
> > Same treatment as before. Only hiccup is drm_crtc_mask, which
> > unfortunately can't be resolved until drm_crtc.h is less of a monster.
> > Untangle the header loop with a
Now that we have working partial VMA and faulting support for all
objects, including fence support, advertise to userspace that it can
take advantage of unlimited GGTT mmaps.
v2: Make room in the kerneldoc for a more detailed explanation of the
limitations of the GTT mmap interface.
Signed-off-by
On Thu, Aug 25, 2016 at 02:49:59PM +0300, Joonas Lahtinen wrote:
> > + * we move the task_list from this the next ready fence to the tail of
> > + * the original fence's task_list (and so added to the list to be
> > + * woken).
> > + */
> > + smp_mb__before_spinlock();
> > + if (!li
On Thu, 25 Aug 2016 18:12:19 +0200,
Chris Wilson wrote:
>
> > Maybe But it's hard to tell exactly whether this is
> > the 100% culprit. As said, there have been multiple S4 bugs, so far.
> > IVY worked without this patch (after x86 fixes), but obviously this
> > had no negative effect, either.
>
On Thu, Aug 25, 2016 at 05:54:58PM +0200, Takashi Iwai wrote:
> On Thu, 25 Aug 2016 17:32:41 +0200,
>
> > Could you confirm that bisect has any
> > impact on the other machines, and of course double check the result?
>
> You're asking bisection on all machines from the scratch for such a
> bug ta
On Thu, 25 Aug 2016 17:32:41 +0200,
Chris Wilson wrote:
>
> On Thu, Aug 25, 2016 at 03:11:35PM +0200, Takashi Iwai wrote:
> > Hi,
> >
> > while debugging our 4.4.x based SLE12-SP2 kernel, we noticed that S4
> > resume is broken on many machines with i915 gfx, even on the upstream
> > 4.7 kernel.
On Thu, Aug 25, 2016 at 03:11:35PM +0200, Takashi Iwai wrote:
> Hi,
>
> while debugging our 4.4.x based SLE12-SP2 kernel, we noticed that S4
> resume is broken on many machines with i915 gfx, even on the upstream
> 4.7 kernel. Originally it was reported by Intel about SKL machines,
> but later on
Hi,
On ti, 2016-08-16 at 22:17 +0530, Shashank Sharma wrote:
> LSPCON is essentially a dp++->hdmi adapter with dual mode of operation.
>
> These modes are:
> - Level Shifter mode: In LS mode, this device works as a type2 dp->hdmi
> passive dongle, which steps up DP++ output to appropriate HDMI 1.
On 23/08/2016 14:33, John Harrison wrote:
On 23/08/2016 14:28, John Harrison wrote:
On 22/08/2016 13:23, Chris Wilson wrote:
On Mon, Aug 22, 2016 at 02:23:28PM +0300, Joonas Lahtinen wrote:
On ma, 2016-08-22 at 09:03 +0100, Chris Wilson wrote:
With full-ppgtt, we want the user to have full co
On Thu, Aug 25, 2016 at 03:19:15PM +0100, Arun Siluvery wrote:
> From: Armin Reese
>
> A 'cat' of the debugfs file i915_dump_lrc, dumps only the first 0x600(1536)
> bytes of each ring's register state context. It does not provide
> information about the remaining portion of the register state con
From: Armin Reese
A 'cat' of the debugfs file i915_dump_lrc, dumps only the first 0x600(1536)
bytes of each ring's register state context. It does not provide
information about the remaining portion of the register state context.
This patch adds new file i915_dump_lrc_complete which displays full
== Series Details ==
Series: drm/i915/opregion: proper handling of DIDL and CADL
URL : https://patchwork.freedesktop.org/series/11565/
State : warning
== Summary ==
Series 11565v1 drm/i915/opregion: proper handling of DIDL and CADL
http://patchwork.freedesktop.org/api/1.0/series/11565/revision
Hi,
while debugging our 4.4.x based SLE12-SP2 kernel, we noticed that S4
resume is broken on many machines with i915 gfx, even on the upstream
4.7 kernel. Originally it was reported by Intel about SKL machines,
but later on, we found that it hits on many other older chips (at
least HSW), too.
Th
Chris Wilson writes:
> Just rearrange the code to reduce churn in the next patch.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 76
>
> 1 file changed, 38 insertions(+), 38 deletions(-)
>
> diff
Op 25-08-16 om 14:53 schreef Jani Nikula:
> Previously we've just shoved the first eight devices in DIDL to CADL
> (list of active outputs). Some of the active outputs may have been left
> outside of CADL. The problem is, some BIOS implementations prevent
> laptop brightness hotkey propagation if t
The graphics driver is supposed to define the DIDL, which are used for
_DOD, not the BIOS. Restore that behaviour.
This is basically a revert of
commit 3143751ff51a163b77f7efd389043e038f3e008e
Author: Zhang Rui
Date: Mon Mar 29 15:12:16 2010 +0800
drm/i915: set DIDL using the ACPI video o
Previously we've just shoved the first eight devices in DIDL to CADL
(list of active outputs). Some of the active outputs may have been left
outside of CADL. The problem is, some BIOS implementations prevent
laptop brightness hotkey propagation if the flat panel is not active.
Now that we have con
This is the next iteration of [1] and [2]. Please review and/or test,
according to your abilities.
Thanks,
Jani.
Cc: Peter Wu
Cc: Rainer Koenig
Cc: Jan-Marek Glogowski
Cc: Maarten Lankhorst
Cc: Marcos Paulo de Souza
Cc: Paolo Stivanin
[1] http://mid.mail-archive.com/cover.1467214151.git.ja
== Series Details ==
Series: drm/i915: remove leftover for_each_intel_crtc_masked
URL : https://patchwork.freedesktop.org/series/11563/
State : failure
== Summary ==
Series 11563v1 drm/i915: remove leftover for_each_intel_crtc_masked
http://patchwork.freedesktop.org/api/1.0/series/11563/revisi
On Thu, Aug 25, 2016 at 03:08:58PM +0300, Joonas Lahtinen wrote:
> On to, 2016-08-25 at 10:08 +0100, Chris Wilson wrote:
> > @@ -462,7 +462,10 @@ static int intel_breadcrumbs_signaler(void *arg)
> > */
> > intel_engine_remove_wait(engine,
> >
On 08/18/2016 02:26 AM, Daniel Vetter wrote:
I figured an overview section here is overkill, and better
to just document the 2 structures themselves well enough.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_mode_object.c | 9 +++
include/drm/drm_mode_object.h | 50
On 08/18/2016 02:26 AM, Daniel Vetter wrote:
This just contains the base property classes and all the code to
handle blobs. I think for any kind of standardized/shared properties
it's better to have separate files - this is fairly big already as-is.
v2: resurrect misplaced hunk (Daniel Stone)
On 08/18/2016 02:26 AM, Daniel Vetter wrote:
They work exactly the same now, after the refcounting unification a bit
ago. The only reason they're distinct is backwards compat with existing
userspace.
Cc: Daniel Stone
Signed-off-by: Daniel Vetter
Reviewed-by: Archit Taneja
Archit
---
On Thu, Aug 25, 2016 at 02:49:59PM +0300, Joonas Lahtinen wrote:
> On to, 2016-08-25 at 10:08 +0100, Chris Wilson wrote:
> > +++ b/drivers/gpu/drm/i915/i915_sw_fence.c
> > @@ -0,0 +1,329 @@
> > +/*
> > + * (C) Copyright 2016 Intel Corporation
> > + *
> > + * This program is free software; you can r
On 08/18/2016 02:26 AM, Daniel Vetter wrote:
It's part of the drm fourcc handling code, mapping the old depth/bpp
values to new fourcc codes.
Reviewed-by: Archit Taneja
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 43 -
On 08/18/2016 02:26 AM, Daniel Vetter wrote:
Just for the struct drm_mode_object base class. The header file was
already partially extracted to help untangle the include loops.
v2:
- Also move the generic get/set property ioctls. At first this seemed
like a bad idea since it requires making
On 08/18/2016 02:26 AM, Daniel Vetter wrote:
It's only used in drm_mode_object_get_properties, and we can compute
it there directly with a bit of code shuffling.
Reviewed-by: Archit Taneja
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_mode_object.c | 31 -
On 08/18/2016 02:25 AM, Daniel Vetter wrote:
- Move missing bits into struct drm_encoder docs.
- Explain that encoders are 95% internal and only 5% uapi, and that in
general the uapi part is broken.
- Remove verbose comments for functions not exposed to drivers.
Signed-off-by: Daniel Vetter
Hi,
On 08/18/2016 02:25 AM, Daniel Vetter wrote:
Same treatment as before. Only hiccup is drm_crtc_mask, which
unfortunately can't be resolved until drm_crtc.h is less of a monster.
Untangle the header loop with a forward delcaration for that static
s/delcaration/declaration
inline.
Signed
On to, 2016-08-25 at 09:27 +0100, Chris Wilson wrote:
> On Thu, Aug 25, 2016 at 11:00:54AM +0300, Joonas Lahtinen wrote:
> >
> > On ke, 2016-08-24 at 20:42 +0100, Chris Wilson wrote:
> > >
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -355,6 +355,14 @@ static int i915_getparam(struct drm_d
On to, 2016-08-25 at 10:08 +0100, Chris Wilson wrote:
> @@ -462,7 +462,10 @@ static int intel_breadcrumbs_signaler(void *arg)
> */
> intel_engine_remove_wait(engine,
> &request->signaling.wait);
> +
> +
The last user of for_each_intel_crtc_masked macro was removed in
commit 0a9ab303b87a94115e361a7f3a15d9f481bc453b
Author: Ander Conselvan de Oliveira
Date: Tue Apr 21 17:13:04 2015 +0300
drm/i915: Remove all *_pipes flags from modeset
Get rid of the unused macro.
Cc: Ander Conselvan de Ol
On to, 2016-08-25 at 10:08 +0100, Chris Wilson wrote:
> +++ b/drivers/gpu/drm/i915/i915_sw_fence.c
> @@ -0,0 +1,329 @@
> +/*
> + * (C) Copyright 2016 Intel Corporation
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public
On Tue, 23 Aug 2016, Maarten Lankhorst
wrote:
> Merge commit 5e580523d9128a4d8 reverts the version bumping parts of
> commit 4aa7fb9c3c4fa0. Bump the versions again and request the specific
> firmware version.
>
> The currently recommended versions are: SKL 1.26, KBL 1.01 and BXT 1.07.
>
> Cc: Pa
Op 25-08-16 om 11:49 schreef Chris Wilson:
> On Thu, Aug 25, 2016 at 11:07:02AM +0200, Maarten Lankhorst wrote:
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/intel_dp.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> b/drivers/g
On Tue, 23 Aug 2016, Maarten Lankhorst
wrote:
> From: Jani Nikula
>
> Don't consider enabled but zero duty cycle backlight disabled. Clamp
> level between min and max for sanity.
>
> Signed-off-by: Jani Nikula
I think this is the right thing to do.
In the future, perhaps we'll want to check f
On to, 2016-08-25 at 10:15 +0100, Chris Wilson wrote:
> In an attempt to keep the hibernation image as same as possible, let's
> try and discard any unwanted pages and our own page arrays.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Sou
On Thu, Aug 25, 2016 at 11:42:41AM +0100, John Harrison wrote:
> I'm not convinced the benefit is worth the
> confusion and maintenance risk. E.g. is unsigned long guaranteed to
> always and ever be sufficient for a pointer?
Yes, unsigned long will always be sufficient for a kernel pointer. I'm
su
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Flush to GTT domain all GGTT
bound objects after hibernation
URL : https://patchwork.freedesktop.org/series/11557/
State : failure
== Summary ==
Series 11557v1 Series without cover letter
http://patchwork.freedesktop.org/api
Writing up the IRC discussion...
I think the naming of _complete() vs _done() is unnecessarily confusing
- the first being an action and the second a query. Chris says that the
idea is to match the existing naming convention of 'struct completion'.
If the plan is to eventually move this code o
On Thu, Aug 25, 2016 at 12:51:16PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > Similar to the issue with reading from the context status buffer, we
> > frequently write to the ELSP register (4 writes per interrupt) and know
> > we hold the required spinlock and forcewake throughout.
== Series Details ==
Series: series starting with [1/2] drm/i915: Fix intel_display_crc_init for
!DEBUGFS
URL : https://patchwork.freedesktop.org/series/11553/
State : failure
== Summary ==
Series 11553v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/11553/revisi
Now that we have working partial VMA and faulting support for all
objects, including fence support, advertise to userspace that it can
take advantage of unlimited GGTT mmaps.
Signed-off-by: Chris Wilson
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 8
drivers/gpu/drm
Chris Wilson writes:
> Similar to the issue with reading from the context status buffer, we
> frequently write to the ELSP register (4 writes per interrupt) and know
> we hold the required spinlock and forcewake throughout. We can
> shortcircuit the I915_WRITE() by precomputing the address of the
On Thu, Aug 25, 2016 at 11:07:02AM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_dp.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index a3c7dd8fd406..df0773afb
On Thu, Aug 25, 2016 at 11:07:01AM +0200, Maarten Lankhorst wrote:
> The mentioned commit changes intel_display_crc_init to take a dev_priv,
> but forgets to change the stub.
>
> Cc: David Weinehall
> Fixes: 36cdd0138b7f ("drm/i915: debugfs spring cleaning")
> Signed-off-by: Maarten Lankhorst
>
Chris Wilson writes:
> Rather than blindly assuming we need to advance the tail for
> resubmitting the request via the ELSP, record the position.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem_request.h | 15 +--
> drivers/gpu/drm
Recently I have been applying an optimisation to avoid stalling and
clflushing GGTT objects based on their current binding. That is we only
set-to-gtt-domain upon first bind. However, on hibernation the objects
remain bound, but they are in the CPU domain. Currently (since commit
975f7ff42edf ("drm
In an attempt to keep the hibernation image as same as possible, let's
try and discard any unwanted pages and our own page arrays.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gp
Handle querying and waiting on an external fence fd as opposed to the
internal seqno fence. The key difference with the fd fences are that we
can pass these external fences to the kernel/GPU for it to
asynchronously wait upon (internal seqno fences are ordered by the GL
command stream, hence do not
Wire up the callbacks from DRI2_FENCE for native fence support.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/intel_syncobj.c | 48 +++
1 file changed, 48 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_syncobj.c
b/src/mesa/drivers/dri/i965/in
The kernel allows implicit synchronisation to be disabled on individual
buffers. Use at your own risk.
Signed-off-by: Chris Wilson
---
intel/intel_bufmgr.h | 2 ++
intel/intel_bufmgr_gem.c | 34 ++
2 files changed, 32 insertions(+), 4 deletions(-)
diff --git
If the client is controlling serialisation on shared buffers using
EGL_ANDROID_native_fence_sync, we assume that they are capable of fully
describing the serialisation required on those buffers and disable the
implicit syncs to prevent any "undue" serialisation between rendering.
This shotgun is l
Wire up the infrastructure to pass in and receive back a file descriptor
describing a fence (a sync_file object in the kernel) associated with
the batch. Fences can be passed in that the GPU must wait for before
executing the batch. Ideally those waits with neither block the client
nor the GPU from
From: Chad Versace
This bool maps to I915_PARAM_HAS_EXEC_FENCE_FD.
TODO: The i915 param is not yet upstream. Wait for the kernel interface
before committing.
---
src/mesa/drivers/dri/i965/intel_screen.c | 4
src/mesa/drivers/dri/i965/intel_screen.h | 2 +-
2 files changed, 5 insertions(
Allow the caller to pass in an fd to an array of fences to control
serialisation of the execbuf in the kernel and on the GPU, and in return
allow creation of a fence fd for signaling the completion (and flushing)
of the batch. When the returned fence is signaled, all writes to the
buffers inside th
Separate out the underlying fence implementation for the sync object so
that we can extend the internal seqno based fence with an external fd
fence in the next few patches.
Signed-off-by: Chris Wilson
---
src/mesa/drivers/dri/i965/intel_syncobj.c | 33 ++-
1 file chan
Update reset path in preparation for engine reset which requires
identification of incomplete requests and associated context and fixing
their state so that engine can resume correctly after reset.
The request that caused the hang will be skipped and head is reset to the
start of breadcrumb. This
Now that the user can opt-out of implicit fencing, we need to give them
back control over the fencing. We employ sync_file to wrap our
drm_i915_gem_request and provide an fd that userspace can merge with
other sync_file fds and pass back to the kernel to wait upon before
future execution.
Testcase
Userspace is faced with a dilemma. The kernel requires implicit fencing
to manage resource usage (we always must wait for the GPU to finish
before releasing its PTE) and for third parties. However, userspace may
wish to avoid this serialisation if it is either using explicit fencing
between parties
Now that we have fences in place to drive request submission, we can
employ those to queue requests after their dependencies as opposed to
stalling in the middle of an execbuf ioctl. (However, we still choose to
spin before enabling the IRQ as that is faster - though contentious.)
Signed-off-by: C
Just rearrange the code to reduce churn in the next patch.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 76
1 file changed, 38 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel
Drive final request submission from a callback from the fence. This way
the request is queued until all dependencies are resolved, at which
point it is handed to the backend for queueing to hardware. At this
point, no dependencies are set on the request, so the callback is
immediate.
A side-effect
We are about to specialize object synchronisation to enable nonblocking
execbuf submission. First we make a copy of the current object
synchronisation for execbuffer. The general i915_gem_object_sync() will
be removed following the removal of CS flips in the near future.
Signed-off-by: Chris Wilso
Leave the more complicated request dequeueing to the tasklet and instead
just kick start the tasklet if we detect we are adding the first
request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 28
1 file changed, 4 insertions(+), 24 deletions(-)
Emulate HW to track and manage ELSP queue. A set of SW ports are defined
and requests are assigned to these ports before submitting them to HW. This
helps in cleaning up incomplete requests during reset recovery easier
especially after engine reset by decoupling elsp queue management. This
will bec
Now that we can wait upon fences before emitting the request, it becomes
trivial to wait upon any implicit fence provided by the dma-buf
reservation object.
Testcase: igt/prime_vgem/fence-wait
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 11 +++
1 file cha
Similar to the issue with reading from the context status buffer, we
frequently write to the ELSP register (4 writes per interrupt) and know
we hold the required spinlock and forcewake throughout. We can
shortcircuit the I915_WRITE() by precomputing the address of the ELSP
register and avoid all th
Rather than blindly assuming we need to advance the tail for
resubmitting the request via the ELSP, record the position.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_request.h | 15 +--
drivers/gpu/drm/i915/intel_lrc.c| 4 ++--
2 files changed, 11 insertions
Features: PRIME fencing, explicit sync_file fencing, nonblocking execbuf
dispatch at marginal cost (~10%) to throughput and latency
Missing: all the performance and general regression fixes.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.
This is really a core kernel struct in disguise until we can finally
place it in kernel/. There is an immediate need for a fence collection
mechanism that is more flexible than fence-array, in particular being
able to easily drive request submission via events (and not just
interrupt driven). The s
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a3c7dd8fd406..df0773afb7f5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel
The mentioned commit changes intel_display_crc_init to take a dev_priv,
but forgets to change the stub.
Cc: David Weinehall
Fixes: 36cdd0138b7f ("drm/i915: debugfs spring cleaning")
Signed-off-by: Maarten Lankhorst
Reported-and-by: Kim Lidström
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 fil
On Thu, Aug 25, 2016 at 09:51:05AM +0200, Daniel Vetter wrote:
> On Thu, Aug 25, 2016 at 08:23:14AM +0100, Chris Wilson wrote:
> > A side effect of removing the midlayer from driver loading was the loss
> > of a useful message announcing to userspace that i915 had successfully
> > started, e.g.:
>
On Thu, Aug 25, 2016 at 11:00:54AM +0300, Joonas Lahtinen wrote:
> On ke, 2016-08-24 at 20:42 +0100, Chris Wilson wrote:
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -355,6 +355,14 @@ static int i915_getparam(struct drm_device *dev, void
> > *data,
> > case I915_PARAM_MIN_EU_IN_POOL:
> >
Hi Dave, i915 fixes for v4.8.
BR,
Jani.
The following changes since commit fa8410b355251fd30341662a40ac6b22d3e38468:
Linux 4.8-rc3 (2016-08-21 16:14:10 -0700)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2016-08-25
for you to fetch
On ke, 2016-08-24 at 20:42 +0100, Chris Wilson wrote:
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -355,6 +355,14 @@ static int i915_getparam(struct drm_device *dev, void
> *data,
> case I915_PARAM_MIN_EU_IN_POOL:
> value = INTEL_INFO(dev)->min_eu_in_pool;
> break
On Thu, Aug 25, 2016 at 08:23:14AM +0100, Chris Wilson wrote:
> A side effect of removing the midlayer from driver loading was the loss
> of a useful message announcing to userspace that i915 had successfully
> started, e.g.:
>
> [drm] Initialized i915 1.6.0 20160425 for :00:02.0 on mino
== Series Details ==
Series: drm/i915: Restore lost "Initialized i915" welcome message
URL : https://patchwork.freedesktop.org/series/11550/
State : failure
== Summary ==
Series 11550v1 drm/i915: Restore lost "Initialized i915" welcome message
http://patchwork.freedesktop.org/api/1.0/series/11
On Wednesday, August 24, 2016 8:42:44 PM PDT Chris Wilson wrote:
> From about kernel 4.9, GTT mmaps are virtually unlimited. A new
> parameter, I915_PARAM_MMAP_GTT_VERSION, is added to advertise the
> feature so query it and use it to avoid limiting tiled allocations to
> only fit within the mappab
A side effect of removing the midlayer from driver loading was the loss
of a useful message announcing to userspace that i915 had successfully
started, e.g.:
[drm] Initialized i915 1.6.0 20160425 for :00:02.0 on minor 0
Reported-by: Timo Aaltonen
Signed-off-by: Chris Wilson
Fixes:
On Wed, Aug 24, 2016 at 08:42:44PM +0100, Chris Wilson wrote:
> From about kernel 4.9, GTT mmaps are virtually unlimited. A new
> parameter, I915_PARAM_MMAP_GTT_VERSION, is added to advertise the
> feature so query it and use it to avoid limiting tiled allocations to
> only fit within the mappable
On Wed, Aug 24, 2016 at 10:48:13PM +0100, ch...@chris-wilson.co.uk wrote:
> On Wed, Aug 24, 2016 at 09:14:59PM +, Zanoni, Paulo R wrote:
> > Em Qua, 2016-08-24 às 19:00 +0100, Chris Wilson escreveu:
> > > . In the meantime lets hope that all
> > > framebuffers are idle and naturally fit within
On Wed, Aug 24, 2016 at 08:42:43PM +0100, Chris Wilson wrote:
> Now that we have working partial VMA and faulting support for all
> objects, including fence support, advertise to userspace that it can
> take advantage of unlimited GGTT mmaps.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/d
88 matches
Mail list logo
