On Wed, 29 Mar 2017, Tobias Regnery wrote:
> With CONFIG_ACPI=n and CONFIG_BACKLIGHT_CLASS_DEVICE=n we see the following
> link error in the i915 driver:
>
> drivers/built-in.o: In function 'intel_backlight_device_register':
> (.text+0x2a921d): undefined reference to 'backlight_device_register'
>
On 30.03.2017 09:43, Petri Latvala wrote:
> On Wed, Mar 29, 2017 at 12:52:29PM +0300, Abdiel Janulgue wrote:
>> Original author: Marius Vlad. Includes fixes below.
>>
>> v4: Add a unit test to make sure synthetic EDID blocks generated by
>> IGT is valid (suggested by Petri).
>>
>
>
> No no,
On Wed, Mar 29, 2017 at 12:52:29PM +0300, Abdiel Janulgue wrote:
> Original author: Marius Vlad. Includes fixes below.
>
> v4: Add a unit test to make sure synthetic EDID blocks generated by
> IGT is valid (suggested by Petri).
>
No no, I meant a build-time test, in lib/tests, run by 'make [
On Wed, 29 Mar 2017, Lukas Wunner wrote:
> Just a bunch of trivial typos that caught my eye while perusing the
> documentation.
>
> Signed-off-by: Lukas Wunner
Reviewed-by: Jani Nikula
Thanks, please push yourself!
> ---
> dim.rst | 14 +++---
> drm-intel.rst | 10 +-
>
On Thu, 30 Mar 2017, "Zhang, Xiong Y" wrote:
>> On Wed, Mar 29, 2017 at 05:02:47PM +0800, Xiong Zhang wrote:
>> I'm not 100% sure the ULT/ULX <=> LP thing always holds. I *think* it
>> should but I've never been able to convince myself totally.
> [Zhang, Xiong Y] For BDW ULT/ULX, it should be LP.
On Wed, 29 Mar 2017, Bob Paauwe wrote:
> On Wed, 29 Mar 2017 13:32:58 +0300
> Jani Nikula wrote:
>
>> Sometimes it would be most enlightening to debug systems by replacing
>> the VBT to be used. For example, in the referenced bug the BIOS provides
>> different VBT depending on the boot mode (UEFI
On Thu, 30 Mar 2017 02:24:37 +0200,
Lyude Paul wrote:
>
> On Wed, 2017-03-29 at 15:54 +0200, Takashi Iwai wrote:
> > On Wed, 29 Mar 2017 15:34:15 +0200,
> > Ville Syrjälä wrote:
> > >
> > > On Wed, Mar 29, 2017 at 03:10:09PM +0200, Takashi Iwai wrote:
> > > > On Mon, 27 Mar 2017 18:02:13 +0200,
>
> On Wed, Mar 29, 2017 at 05:02:47PM +0800, Xiong Zhang wrote:
> > In a virtual passthrough environment, the ISA bridge isn't able to
> > be passed through. So pch_id couldn't be gotten from ISA bridge, but
> > pch_id is used to identify LPT_H and LPT_LP, this patch set pch_id
> > according to IGD
Friendly ping. Can anyone please review this?
Thanks
On Wed, Mar 22, 2017 at 3:54 PM, Puthikorn Voravootivat wrote:
> Rebase since this is not applied cleanly now.
>
> This patch set contain 6 patches.
> - First two patches allow enable DPCD backlight control when panel
> can also do that via
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/intel_ringbuffer.h
between commit:
dd68f2ba0720 ("drm/i915/execlists: Wrap tail pointer after reset tweaking")
from the drm-intel-fixes tree and commit:
73dec95e6ba3 ("drm/i915: Emit to ringbuffer
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/intel_lrc.c
between commit:
dd68f2ba0720 ("drm/i915/execlists: Wrap tail pointer after reset tweaking")
from the drm-intel-fixes tree and commit:
944a36d472be ("drm/i915: Assert that the request->t
On Wed, 2017-03-29 at 15:54 +0200, Takashi Iwai wrote:
> On Wed, 29 Mar 2017 15:34:15 +0200,
> Ville Syrjälä wrote:
> >
> > On Wed, Mar 29, 2017 at 03:10:09PM +0200, Takashi Iwai wrote:
> > > On Mon, 27 Mar 2017 18:02:13 +0200,
> > > Takashi Iwai wrote:
> > > >
> > > > Hi,
> > > >
> > > > the up
On Wed, Mar 29, 2017 at 10:36:16PM +0100, Chris Wilson wrote:
> Some GPUs may have writes inflight much longer than expected, so before
> declaring the GPU is idle, try to flush them using any
> engine->irq_seqno_barrier() if available. By allowing them to be
> flushed, we can be a little more conf
On Wed, Mar 29, 2017 at 10:36:17PM +0100, Chris Wilson wrote:
> Make i915_gem_wait_for_idle() be a little heavier in order to try and
> guarantee that the GPU is indeed idle (by checking each engine
> individually is idle, i.e. all writes are complete and the rings
> stopped) after waiting for in-f
On 17-03-29 23:17:13, Ville Syrjälä wrote:
On Fri, Mar 24, 2017 at 02:29:50PM -0700, Ben Widawsky wrote:
This was based on a patch originally by Kristian. It has been modified
pretty heavily to use the new callbacks from the previous patch.
v2:
- Add LINEAR and Yf modifiers to list (Ville)
On Wed, Mar 29, 2017 at 10:36:17PM +0100, Chris Wilson wrote:
> Make i915_gem_wait_for_idle() be a little heavier in order to try and
> guarantee that the GPU is indeed idle (by checking each engine
> individually is idle, i.e. all writes are complete and the rings
> stopped) after waiting for in-f
We pretty print the name of an engine in several places, mostly for
debug, but also in the GPU hang report. Using "ring" in the name is
archaic (we call those engines now to differentiate them from the
multiple rings of commands we execute on each engine), quite verbose and
often tautological. We r
== Series Details ==
Series: series starting with [1/4] drm/i915: Wait for inflight writes before
checking intel_engine_is_idle() (rev2)
URL : https://patchwork.freedesktop.org/series/22126/
State : success
== Summary ==
Series 22126v2 Series without cover letter
https://patchwork.freedesktop
We can merge the pair of loops over the engines and their timelines into
a single loop, making it easier to read and more consistent with the
commentary.
Signed-off-by: Chris Wilson
---
git add ftw
---
drivers/gpu/drm/i915/i915_gem_request.c | 14 +-
1 file changed, 5 insertions(+),
== Series Details ==
Series: series starting with [1/4] drm/i915: Wait for inflight writes before
checking intel_engine_is_idle()
URL : https://patchwork.freedesktop.org/series/22126/
State : failure
== Summary ==
LD [M] drivers/net/ethernet/broadcom/genet/genet.o
LD net/packet/buil
Having added the wait upon each engine to idle into the central
i915_gem_wait_for_idle(), we can remove the now redundant wait from
reset_all_global_seqno(). This has the advantage of removing the late
detection of an error (an engine still busy) which left the seqno reset
only partially complete (
We can merge the pair of loops over the engines and their timelines into
a single loop, making it easier to read and more consistent with the
commentary.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_request.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
dif
Make i915_gem_wait_for_idle() be a little heavier in order to try and
guarantee that the GPU is indeed idle (by checking each engine
individually is idle, i.e. all writes are complete and the rings
stopped) after waiting for in-flight requests to be completed.
References: https://bugs.freedesktop.
Some GPUs may have writes inflight much longer than expected, so before
declaring the GPU is idle, try to flush them using any
engine->irq_seqno_barrier() if available. By allowing them to be
flushed, we can be a little more confident that the GPU really is idle
when we think it is!
References: ht
On Wed, 2017-03-29 at 11:50 +0300, Ville Syrjälä wrote:
> On Tue, Mar 07, 2017 at 04:12:52PM -0800, Dhinakaran Pandiyan wrote:
> > According to BSpec, "The CD clock frequency must be at least twice the
> > frequency of the Azalia BCLK." and BCLK is configured to 96 MHz by
> > default. This check is
Just a bunch of trivial typos that caught my eye while perusing the
documentation.
Signed-off-by: Lukas Wunner
---
dim.rst | 14 +++---
drm-intel.rst | 10 +-
drm-misc.rst | 2 +-
3 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/dim.rst b/dim.rst
index aed
The kfree on line 926 would only be a problem for the references to e on
lines 933 and 937 if the return value of drm_event_reserve_init can be
-EDEADLK.
julia
-- Forwarded message --
Date: Thu, 30 Mar 2017 00:48:54 +0800
From: kbuild test robot
To: kbu...@01.org
Cc: Julia Lawall
On Wed, Mar 29, 2017 at 11:03:40PM +0300, Ville Syrjälä wrote:
> On Fri, Mar 24, 2017 at 02:29:48PM -0700, Ben Widawsky wrote:
> > They're the same, so use the one which makes more sense.
> >
> > Signed-off-by: Ben Widawsky
>
> Reviewed-by: Ville Syrjälä
And pushed to dinq immediately. Thanks
On Fri, Mar 24, 2017 at 02:29:50PM -0700, Ben Widawsky wrote:
> This was based on a patch originally by Kristian. It has been modified
> pretty heavily to use the new callbacks from the previous patch.
>
> v2:
> - Add LINEAR and Yf modifiers to list (Ville)
> - Combine i8xx and i965 into one l
On Fri, Mar 24, 2017 at 02:29:48PM -0700, Ben Widawsky wrote:
> They're the same, so use the one which makes more sense.
>
> Signed-off-by: Ben Widawsky
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 28 ++--
> 1 file changed, 14 insertions(+
Of course. I totally missed that.
Reviewed-by: Harry Wentland
Harry
On 2017-03-29 01:41 PM, Daniel Vetter wrote:
I've screwed this up when removing the legacy backoff hack.
Fixes: 38b6441e4e75 ("drm/atomic-helper: Remove the backoff hack from
set_config")
Cc: Harry Wentland
Cc: Daniel Vett
Create a substruct to hold all the global context state under
drm_i915_private.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 +--
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 20 +++--
Whilst the contents of the context is still protected by the big
struct_mutex, this is not much of an improvement. It is just one tiny
step towards reducing our BKL.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h| 16 +--
drivers/gpu/drm/i915/i915_gem_context.c
If we move the actual cleanup of the context to a worker, we can allow
the final free to be called from any context and avoid undue latency in
the caller.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gvt/scheduler.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h | 23 ++-
== Series Details ==
Series: drm: Fixup failure paths in drm_atomic_helper_set_config
URL : https://patchwork.freedesktop.org/series/22106/
State : success
== Summary ==
Series 22106v1 drm: Fixup failure paths in drm_atomic_helper_set_config
https://patchwork.freedesktop.org/api/1.0/series/221
On Wed, 29 Mar 2017 13:32:58 +0300
Jani Nikula wrote:
> Sometimes it would be most enlightening to debug systems by replacing
> the VBT to be used. For example, in the referenced bug the BIOS provides
> different VBT depending on the boot mode (UEFI vs. legacy). It would be
> interesting to try t
On Wed, 29 Mar 2017 13:32:57 +0300
Jani Nikula wrote:
> Leave more breadcrumbs for debuggers.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Bob Paauwe
> ---
> drivers/gpu/drm/i915/intel_opregion.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_opregio
On Wed, 29 Mar 2017 13:32:56 +0300
Jani Nikula wrote:
> Seems more sensible this way, and reduces indent for the more common
> case.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Bob Paauwe
> ---
> drivers/gpu/drm/i915/intel_opregion.c | 41
> +--
> 1 file cha
On Wed, 29 Mar 2017 13:32:55 +0300
Jani Nikula wrote:
> Reduce indent. No functional changes.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Bob Paauwe
> ---
> drivers/gpu/drm/i915/intel_opregion.c | 64
> +--
> 1 file changed, 32 insertions(+), 32 deletions(-)
On Wed, Mar 29, 2017 at 04:43:58PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> The FB helper core now supports deferred setup, so the driver's custom
> implementation can be removed.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 6 --
>
I've screwed this up when removing the legacy backoff hack.
Fixes: 38b6441e4e75 ("drm/atomic-helper: Remove the backoff hack from
set_config")
Cc: Harry Wentland
Cc: Daniel Vetter
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sean Paul
Cc: David Airlie
Cc: dri-de...@lists.freedesktop.org
Signed-off
On Wed, Mar 29, 2017 at 03:11:46PM +0300, Jani Nikula wrote:
> On Wed, 29 Mar 2017, Ville Syrjälä wrote:
> > On Wed, Mar 29, 2017 at 10:29:24AM +0300, Jani Nikula wrote:
> >> On Tue, 28 Mar 2017, Manasi Navare wrote:
> >> > Jani,
> >> >
> >> > Should I just hold on to this until your patch series
From: Clint Taylor
P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
channel video format.
P012 is a planar 4:2:0 YUV 12 bits per channel
P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
channel video format.
V3: Added P012 and fixed cpp for P010
V4: format def
== Series Details ==
Series: series starting with [01/13] drm/i915: Reinstate reservation_object
zapping for batch_pool objects
URL : https://patchwork.freedesktop.org/series/22099/
State : success
== Summary ==
Series 22099v1 Series without cover letter
https://patchwork.freedesktop.org/api/
On Wed, Mar 29, 2017 at 03:58:26PM +0100, Chris Wilson wrote:
> Currently, we allow read-read CPU/GPU concurrency via set-domain-ioctl,
> but we don't have a similar facility for a plain wait-ioctl. If we add a
> new flag that userspace can use to opt-in for only waiting for GPU
> writes, userspace
Use a priority stored in the context as the initial value when
submitting a request. This allows us to change the default priority on a
per-context basis, allowing different contexts to be favoured with GPU
time at the expense of lower importance work. The user can adjust the
context's priority via
The major scaling bottleneck in execbuffer is the processing of the
execobjects. Creating an auxiliary list is inefficient when compared to
using the execobject array we already have allocated.
Reservation is then split into phases. As we lookup up the VMA, we
try and bind it back into active loca
If the user requires patching of their batch or auxiliary buffers, we
currently make the alterations on the cpu. If they are active on the GPU
at the time, we wait under the struct_mutex for them to finish executing
before we rewrite the contents. This happens if shared relocation trees
are used be
When choosing a slot for an execbuffer, we ideally want to use the same
address as last time (so that we don't have to rebind it) and the same
address as expected by the user (so that we don't have to fixup any
relocations pointing to it). If we first try to bind the incoming
execbuffer->offset fro
Combine the two slightly overlapping parameter structures we pass around
the execbuffer routines into one.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 550 -
1 file changed, 233 insertions(+), 317 deletion
This simply hides the EAGAIN caused by userptr when userspace causes
resource contention. However, it is quite beneficial with highly
contended userptr users as we avoid repeating the setup costs and
kernel-user context switches.
Signed-off-by: Chris Wilson
Reviewed-by: Michał Winiarski
---
dri
Currently, the last object in the execlist is the always the batch.
However, when building the batch buffer we often know the batch object
first and if we can use the first slot in the execlist we can emit
relocation instructions relative to it immediately and avoid a separate
pass to adjust the re
The advent of full-ppgtt lead to an extra indirection between the object
and its binding. That extra indirection has a noticeable impact on how
fast we can convert from the user handles to our internal vma for
execbuffer. In order to bypass the extra indirection, we use a
resizable hashtable to jum
We can simplify our tracking of pending writes in an execbuf to the
single bit in the vma->exec_entry->flags, but that requires the
relocation function knowing the object's vma. Pass it along.
Note we have only been using a single bit to track flushing since
commit cc889e0f6ce6a63c62db17d702ecfed
This has the benefit of not requiring us to manipulate the
vma->exec_link list when tearing down the execbuffer, and is a
marginally cheaper test to detect the user error.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_evict.c | 17 ++-
drivers/gpu/drm/i915/i915_gem_execb
Introduce a new execobject.flag (EXEC_OBJECT_CAPTURE) that userspace may
use to indicate that it wants the contents of this buffer preserved in
the error state (/sys/class/drm/cardN/error) following a GPU hang
involving this batch.
Use this at your discretion, the contents of the error state. alth
Just to remind everyone that this series is unstoppable and we want the
green, not to mention the small boosts we get from dramatically reducing
overhead of execbuf for many typical submission paths.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.free
I removed the zapping of the reservation_object->fence array of shared
fences prematurely. We don't yet have the code to zap that array when
retiring the object, and so currently it remains possible to continually
grow the shared array trapping requests when reusing the batch_pool
object across man
Currently the vma has one link member that is used for both holding its
place in the execbuf reservation list, and in any eviction list. This
dual property is quite tricky and error prone.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_evict.c | 14
== Series Details ==
Series: drm/i915: Extend wait-ioctl to only wait on writes
URL : https://patchwork.freedesktop.org/series/22093/
State : success
== Summary ==
Series 22093v1 drm/i915: Extend wait-ioctl to only wait on writes
https://patchwork.freedesktop.org/api/1.0/series/22093/revisions
tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly
head: 2f9f22b419350cafb06ba7e5342bc461fcb0afca
commit: 43dc7fe2b2118c76fbc2808dec0c57b3158e6dc0 [1077/1091] drm: Mark up
accesses of vblank->enabled outside of its spinlock
config: tile-tilegx_defconfig (attached as .config)
compi
== Series Details ==
Series: drm/fb-helper: Deferred setup support (rev3)
URL : https://patchwork.freedesktop.org/series/8410/
State : warning
== Summary ==
Series 8410v3 drm/fb-helper: Deferred setup support
https://patchwork.freedesktop.org/api/1.0/series/8410/revisions/3/mbox/
Test core_au
Currently, we allow read-read CPU/GPU concurrency via set-domain-ioctl,
but we don't have a similar facility for a plain wait-ioctl. If we add a
new flag that userspace can use to opt-in for only waiting for GPU
writes, userspace can use it to co-ordinate its own read-read
concurrency (without the
On Wed, Mar 29, 2017 at 04:43:56PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> The existing drm_fb_helper_hotplug_event() function needs to take the
> top-level fb-helper lock. However, the function can also be called from
> code that has already taken this lock. Introduce an unlocked
From: Thierry Reding
FB helper code falls back to a 1024x768 mode if no outputs are connected
or don't report back any modes upon initialization. This can be annoying
because outputs that are added to FB helper later on can't be used with
FB helper if they don't support a matching mode.
The fall
From: Thierry Reding
The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 6 --
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 23 ---
2 files ch
From: Thierry Reding
Move the modeset locking from drivers into FB helpers.
Tested-by: John Stultz
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_fb_helper.c| 40 +-
drivers/gpu/drm/i915/intel_dp_mst.c| 3 ---
dri
From: Thierry Reding
drm_fbdev_cma_hotplug_event() already checks for NULL pointers before
dereferencing, so callers don't need to do that.
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 3 +--
1 file changed, 1 insertion(+), 2 dele
From: Thierry Reding
Add a couple of temporary variables and use shorter names for existing
variables in drm_fb_helper_add_one_connector() for better readability.
Tested-by: John Stultz
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_fb_helper.c | 25
From: Thierry Reding
The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 21 +++--
1 file changed, 11 insertions(+),
From: Thierry Reding
The expression &private->fbdev_helper can never be NULL, so the check is
completely unnecessary.
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/
From: Thierry Reding
The existing drm_fb_helper_hotplug_event() function needs to take the
top-level fb-helper lock. However, the function can also be called from
code that has already taken this lock. Introduce an unlocked variant of
this function that can be used in the latter case.
This funct
From: Thierry Reding
An unlocked version of the drm_fb_helper_add_one_connector() function
will be added in a subsequent patch. Reshuffle the code separately to
make the diff more readable later on.
Tested-by: John Stultz
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/g
From: Thierry Reding
Introduce a new top-level lock for the FB helper code. This will allow
better locking granularity and avoid the need to abuse modeset locking
for this purpose instead.
Tested-by: John Stultz
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm
From: Thierry Reding
Fix up a couple of checkpatch warnings, such as whitespace or coding
style issues.
Tested-by: John Stultz
Reviewed-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_fb_helper.c | 54 -
1 file changed, 32 inser
From: Thierry Reding
This set of patches adds support for deferring FB helper setup, which is
useful to obtain a sane configuration even when no outputs are available
during probe.
One example is HDMI, where fbdev will currently fallback to a 1024x786
resolution if no monitor is connected, and w
== Series Details ==
Series: drm/i915: Make legacy cursor updates more unsynced (rev2)
URL : https://patchwork.freedesktop.org/series/22031/
State : success
== Summary ==
Series 22031v2 drm/i915: Make legacy cursor updates more unsynced
https://patchwork.freedesktop.org/api/1.0/series/22031/re
== Series Details ==
Series: series starting with [RFC,1/3] drm/i915: Rename intel_engine_cs.exec_id
to uabi_id
URL : https://patchwork.freedesktop.org/series/22088/
State : success
== Summary ==
Series 22088v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/22088
From: Ville Syrjälä
We're clearing the legacy_cursor_update flag before calling
drm_atomic_helper_setup_commit() which means the helper will
wait for the flip to complete before cleaning up the framebuffers.
That's not what we want for the legacy cursor, so let's clear
the flag after setting up t
Op 29-03-17 om 16:06 schreef Daniel Vetter:
> On Wed, Mar 29, 2017 at 03:51:08PM +0200, Maarten Lankhorst wrote:
>> Op 29-03-17 om 15:31 schreef Boris Brezillon:
>>> On Wed, 29 Mar 2017 15:26:45 +0200
>>> Daniel Vetter wrote:
>>>
On Wed, Mar 29, 2017 at 12:16:50PM +0200, Maarten Lankhorst wro
On Wed, Mar 29, 2017 at 03:51:08PM +0200, Maarten Lankhorst wrote:
> Op 29-03-17 om 15:31 schreef Boris Brezillon:
> > On Wed, 29 Mar 2017 15:26:45 +0200
> > Daniel Vetter wrote:
> >
> >> On Wed, Mar 29, 2017 at 12:16:50PM +0200, Maarten Lankhorst wrote:
> >>> mode_valid() and get_modes() called
>
We want to refer to the index of the engine consistently throughout the
userspace ABI. We already have such an index through the execbuffer
engine specifier, that needs to be able to refer to each engine
specifically.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 8 +
We have to mix a static UABI engine id with the potential for a varying
hw_id and layout, and so we need a way to map from the userspace id for
an engine to our internal pointers.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 17 +
drivers/gpu/drm/i915
3 years too late, but hopefully better late than never, start to
rectify the damage caused by commit a8ebba75b358 ("drm/i915: Use the
coarse ping-pong mechanism based on drm fd to dispatch the BSD command
on BDW GT3") and compounded by commit 8d360dffd6d8 ("drm/i915: Specify
bsd rings through exec
Op 28-03-17 om 21:35 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä
>
> We're clearing the legacy_cursor_update flag before calling
> drm_atomic_helper_setup_commit() which means the helper will
> wait for the flip to complete before cleaning up the framebuffers.
> That's not what we
On Wed, 29 Mar 2017 15:34:15 +0200,
Ville Syrjälä wrote:
>
> On Wed, Mar 29, 2017 at 03:10:09PM +0200, Takashi Iwai wrote:
> > On Mon, 27 Mar 2017 18:02:13 +0200,
> > Takashi Iwai wrote:
> > >
> > > Hi,
> > >
> > > the upstream fix a16b7658f4e0d4aec9bc3e75a5f0cc3f7a3a0422
> > > drm/i915: Cal
Op 29-03-17 om 15:31 schreef Boris Brezillon:
> On Wed, 29 Mar 2017 15:26:45 +0200
> Daniel Vetter wrote:
>
>> On Wed, Mar 29, 2017 at 12:16:50PM +0200, Maarten Lankhorst wrote:
>>> mode_valid() and get_modes() called
>>> from drm_helper_probe_single_connector_modes()
>>> may need to look at conne
On Wed, 29 Mar 2017 15:26:45 +0200
Daniel Vetter wrote:
> On Wed, Mar 29, 2017 at 12:16:50PM +0200, Maarten Lankhorst wrote:
> > mode_valid() and get_modes() called
> > from drm_helper_probe_single_connector_modes()
> > may need to look at connector->state because what a valid mode is may
> > dep
On Wed, Mar 29, 2017 at 03:10:09PM +0200, Takashi Iwai wrote:
> On Mon, 27 Mar 2017 18:02:13 +0200,
> Takashi Iwai wrote:
> >
> > Hi,
> >
> > the upstream fix a16b7658f4e0d4aec9bc3e75a5f0cc3f7a3a0422
> > drm/i915: Call intel_dp_mst_resume() before resuming displays
> >
> > seems to trigger a
On Wed, Mar 29, 2017 at 12:16:50PM +0200, Maarten Lankhorst wrote:
> mode_valid() and get_modes() called
> from drm_helper_probe_single_connector_modes()
> may need to look at connector->state because what a valid mode is may
> depend on connector properties being set. For example some HDMI modes
>
On Mon, 27 Mar 2017 18:02:13 +0200,
Takashi Iwai wrote:
>
> Hi,
>
> the upstream fix a16b7658f4e0d4aec9bc3e75a5f0cc3f7a3a0422
> drm/i915: Call intel_dp_mst_resume() before resuming displays
>
> seems to trigger a kernel panic when some modeset change happens after
> S3 resume. The details a
== Series Details ==
Series: drm/i915/guc: Skip enabling GuC submission if the driver is wedged
URL : https://patchwork.freedesktop.org/series/22084/
State : success
== Summary ==
Series 22084v1 drm/i915/guc: Skip enabling GuC submission if the driver is
wedged
https://patchwork.freedesktop.o
On Wed, Mar 29, 2017 at 01:35:00PM +0100, Chris Wilson wrote:
> If the driver is wedged, we will not be using the GPU. (Userspace will
> be told NO!) As we won't be using the GPU until the wedged status is
> cleared and the device restarted, we can skip enabling the guc whilst
> the driver is termi
On Wed, 29 Mar 2017, Chris Wilson wrote:
> On Wed, Mar 29, 2017 at 01:45:38PM +0300, Jani Nikula wrote:
>> On Tue, 21 Mar 2017, Jani Nikula wrote:
>> > On Mon, 13 Mar 2017, Jani Nikula wrote:
>> >> I'm already scripting my fixes backports quite a bit, and frankly don't
>> >> really manually back
If the driver is wedged, we will not be using the GPU. (Userspace will
be told NO!) As we won't be using the GPU until the wedged status is
cleared and the device restarted, we can skip enabling the guc whilst
the driver is terminally wedged, and so avoid trying to use a truly
wedged device.
Signe
On Wed, Mar 29, 2017 at 10:33:47AM +0100, Tvrtko Ursulin wrote:
>
> On 27/03/2017 21:21, Chris Wilson wrote:
> >Unlocking is dangerous. In this case we combine an early update to the
> >out-of-queue request, because we know that it will be inserted into the
> >correct FIFO priority-ordered slot wh
On Wed, Mar 29, 2017 at 01:45:38PM +0300, Jani Nikula wrote:
> On Tue, 21 Mar 2017, Jani Nikula wrote:
> > On Mon, 13 Mar 2017, Jani Nikula wrote:
> >> I'm already scripting my fixes backports quite a bit, and frankly don't
> >> really manually backport anything that doesn't apply cleanly. I'm
>
If the request->wa_tail is 0 (because it landed exactly on the end of
the ringbuffer), when we reconstruct request->tail following a reset we
fill in an illegal value (-8 or 0x0018). As a result, RING_HEAD is
never able to catch up with RING_TAIL and the GPU spins endlessly. If
the ring contain
On Wed, 29 Mar 2017, Ville Syrjälä wrote:
> On Wed, Mar 29, 2017 at 10:29:24AM +0300, Jani Nikula wrote:
>> On Tue, 28 Mar 2017, Manasi Navare wrote:
>> > Jani,
>> >
>> > Should I just hold on to this until your patch series
>> > gets merged so I can rebase this on top of it?
>>
>> I think I'd p
On Wed, Mar 29, 2017 at 12:18:57PM +0100, Chris Wilson wrote:
> On Wed, Mar 29, 2017 at 11:00:52AM +0100, Chris Wilson wrote:
> > This reverts commit 6c943de6686f ("drm/i915: Skip execlists_dequeue()
> > early if the list is empty").
> >
> > The validity of using READ_ONCE there depends upon havin
1 - 100 of 143 matches
Mail list logo
