On Wed, 26 Apr 2017, Imre Deak wrote:
> An error from intel_get_pipe_from_connector() would mean a bug somewhere
> else, but we still should check for it to prevent some other more
> obscure bug later.
>
> v2:
> - Fall back to a reasonable default instead of bailing out in case of
> error. (Jani
Track the latest fence waited upon on each context, and only add a new
asynchronous wait if the new fence is more recent than the recorded
fence for that context. This requires us to filter out unordered
timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the
absence of a universal iden
On 2017.04.25 10:05:12 +0100, Colin King wrote:
> From: Colin Ian King
>
> trivial fix to typo in WARN_ONCE message
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/i915/gvt/handlers.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/h
On Thu, Apr 27, 2017 at 08:06:36AM +0100, Chris Wilson wrote:
> Track the latest fence waited upon on each context, and only add a new
> asynchronous wait if the new fence is more recent than the recorded
> fence for that context. This requires us to filter out unordered
> timelines, which are note
== Series Details ==
Series: series starting with [01/27] drm/i915/selftests: Allocate inode/file
dynamically (rev2)
URL : https://patchwork.freedesktop.org/series/23227/
State : success
== Summary ==
Series 23227v2 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/
On Tue, Apr 18, 2017 at 01:23:17PM -0700, Michel Thierry wrote:
> As all other functions related to resetting engines are using
> reset_engine.
>
> v2: remove _request_ and use start/cancel instead (Chris)
>
> Cc: Chris Wilson
> Signed-off-by: Michel Thierry
Picked up the first pair of trivial
On Thu, Apr 27, 2017 at 10:09:35AM +0300, Jani Nikula wrote:
> On Wed, 26 Apr 2017, Imre Deak wrote:
> > An error from intel_get_pipe_from_connector() would mean a bug somewhere
> > else, but we still should check for it to prevent some other more
> > obscure bug later.
> >
> > v2:
> > - Fall back
An error from intel_get_pipe_from_connector() would mean a bug somewhere
else, but we still should check for it to prevent some other more
obscure bug later.
v2:
- Fall back to a reasonable default instead of bailing out in case of
error. (Jani)
v3:
- Fix s/PIPE_INVALID/INVALID_PIPE/ typo. (Jani
On Tue, Apr 25, 2017 at 10:30:07AM -0700, Lionel Landwerlin wrote:
> +static int gen8_configure_all_contexts(struct drm_i915_private *dev_priv)
> +{
> + struct i915_gem_context *ctx;
> + int ret;
> +
> + ret = i915_mutex_lock_interruptible(&dev_priv->drm);
> + if (ret)
> +
On ke, 2017-04-26 at 14:16 +0100, Tvrtko Ursulin wrote:
> On 26/04/2017 13:20, Joonas Lahtinen wrote:
> >
> > @@ -443,21 +417,6 @@ int i915_gem_context_init(struct drm_i915_private
> > *dev_priv)
> > BUILD_BUG_ON(MAX_CONTEXT_HW_ID > INT_MAX);
> > ida_init(&dev_priv->context_hw_ida);
> >
The proposed buffering method utilizes atomic operations to manage
data buffering. This methodology does not use classic locking approach
(mutex, semaphores, blocking calls, etc.), therefore no "hard"
serialization takes place.
Signed-off-by: Krzysztof E. Olinski
---
lib/buc.c | 208
GuC logger implementation simplified and moved to a library (GuCLAW).
Adds simple buffering utility for logging routine (BUC).
Krzysztof E. Olinski (2):
A lockless Buffering Utility for Concurrency
Simplification of guc logger design
lib/Makefile.sources | 4 +
lib/buc.c
There are some compile problems for Android platform. The aim of this patch is
to simplify the current design and make it compilable both on Linux and Android.
Signed-off-by: Krzysztof E. Olinski
---
lib/Makefile.sources | 4 +
lib/igt_guclaw.c | 272 +++
l
Pre-calculate engine context size based on engine class and device
generation and store it in the engine instance.
v2:
- Squash and get rid of hw_context_size (Chris)
v3:
- Move after MMIO init for probing on Gen7 and 8 (Chris)
- Retained rounding (Tvrtko)
Signed-off-by:
On Thu, 27 Apr 2017, Imre Deak wrote:
> An error from intel_get_pipe_from_connector() would mean a bug somewhere
> else, but we still should check for it to prevent some other more
> obscure bug later.
>
> v2:
> - Fall back to a reasonable default instead of bailing out in case of
> error. (Jani
On Thu, Apr 27, 2017 at 10:59:18AM +0200, Krzysztof E. Olinski wrote:
> GuC logger implementation simplified and moved to a library (GuCLAW).
> Adds simple buffering utility for logging routine (BUC).
Bigger question, why? What designs goals do you want to achieve?
-Chris
--
Chris Wilson, Intel
From: Tvrtko Ursulin
Engine discovery uAPI allows userspace to probe for engine
configuration and features without needing to maintain the
internal PCI id based database.
This enables removal of code duplications across userspace
components.
Probing is done via the new DRM_IOCTL_I915_GEM_ENGINE
From: Tvrtko Ursulin
Building on top of the previous patch which exported the concept
of engine classes and instances, we can also use this instead of
the current awkward engine selection uAPI.
This is primarily interesting for the VCS engine selection which
is a) currently done via disjoint set
On Thu, Apr 27, 2017 at 12:01:11PM +0300, Joonas Lahtinen wrote:
> Pre-calculate engine context size based on engine class and device
> generation and store it in the engine instance.
>
> v2:
> - Squash and get rid of hw_context_size (Chris)
>
> v3:
> - Move after MMIO init for probin
On 26/04/2017 23:22, Chris Wilson wrote:
On Wed, Apr 26, 2017 at 07:56:14PM +0100, Chris Wilson wrote:
On Wed, Apr 26, 2017 at 01:13:41PM +0100, Tvrtko Ursulin wrote:
I was thinking of exactly the same thing as this patch does, u64
context id as key, u32 seqnos (wrapped in a container with
hli
On Thu, 2017-04-27 at 10:05 +0100, Chris Wilson wrote:
> On Thu, Apr 27, 2017 at 10:59:18AM +0200, Krzysztof E. Olinski wrote:
> > GuC logger implementation simplified and moved to a library
> > (GuCLAW).
> > Adds simple buffering utility for logging routine (BUC).
>
> Bigger question, why? What d
On Thu, Apr 27, 2017 at 10:10:34AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Building on top of the previous patch which exported the concept
> of engine classes and instances, we can also use this instead of
> the current awkward engine selection uAPI.
>
> This is primarily intere
On ke, 2017-04-26 at 18:27 +0300, Ville Syrjälä wrote:
> On Wed, Apr 26, 2017 at 04:40:11PM +0300, Imre Deak wrote:
> >
> > On GEN8+ (not counting CHV) the calculation can in theory result in an
> > incorrect sign extension with all upper bits set. In practice this is
> > unlikely to happen since
On Thu, Apr 27, 2017 at 10:20:36AM +0100, Tvrtko Ursulin wrote:
>
> On 26/04/2017 23:22, Chris Wilson wrote:
> >On Wed, Apr 26, 2017 at 07:56:14PM +0100, Chris Wilson wrote:
> >>On Wed, Apr 26, 2017 at 01:13:41PM +0100, Tvrtko Ursulin wrote:
> >>>I was thinking of exactly the same thing as this pa
On Thu, Apr 27, 2017 at 08:06:36AM +0100, Chris Wilson wrote:
> +int i915_gem_timeline_mock_selftests(void)
> +{
> + static const struct i915_subtest tests[] = {
> + SUBTEST(igt_seqmap),
I should add a few benchmarks here as well.
random insertion
random lookup (uses same random s
On Thu, Apr 27, 2017 at 09:22:11AM +, Olinski, Krzysztof E wrote:
> On Thu, 2017-04-27 at 10:05 +0100, Chris Wilson wrote:
> > On Thu, Apr 27, 2017 at 10:59:18AM +0200, Krzysztof E. Olinski wrote:
> > > GuC logger implementation simplified and moved to a library
> > > (GuCLAW).
> > > Adds simpl
== Series Details ==
Series: drm/i915: Sanitize engine context sizes (rev2)
URL : https://patchwork.freedesktop.org/series/23567/
State : failure
== Summary ==
Series 23567v2 drm/i915: Sanitize engine context sizes
https://patchwork.freedesktop.org/api/1.0/series/23567/revisions/2/mbox/
Test
On 27/04/2017 10:25, Chris Wilson wrote:
On Thu, Apr 27, 2017 at 10:10:34AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Building on top of the previous patch which exported the concept
of engine classes and instances, we can also use this instead of
the current awkward engine selection
== Series Details ==
Series: New engine discovery and execbuffer2 engine selection uAPI (rev3)
URL : https://patchwork.freedesktop.org/series/23189/
State : success
== Summary ==
Series 23189v3 New engine discovery and execbuffer2 engine selection uAPI
https://patchwork.freedesktop.org/api/1.0
On Thu, Apr 27, 2017 at 12:01:11PM +0300, Joonas Lahtinen wrote:
> @@ -266,11 +239,12 @@ __create_hw_context(struct drm_i915_private *dev_priv,
> list_add_tail(&ctx->link, &dev_priv->context_list);
> ctx->i915 = dev_priv;
>
> - if (dev_priv->hw_context_size) {
> + if (dev_priv
On Thu, Apr 27, 2017 at 11:09:35AM +0100, Tvrtko Ursulin wrote:
>
> On 27/04/2017 10:25, Chris Wilson wrote:
> >On Thu, Apr 27, 2017 at 10:10:34AM +0100, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>Building on top of the previous patch which exported the concept
> >>of engine classes
Almost from the outset for execlists, we used deferred allocation of the
logical context and rings. Then we ported the infrastructure for pinning
contexts back to legacy, and so now we are able to also implement
deferred allocation for context objects prior to first use on the legacy
submission.
S
Almost from the outset for execlists, we used deferred allocation of the
logical context and rings. Then we ported the infrastructure for pinning
contexts back to legacy, and so now we are able to also implement
deferred allocation for context objects prior to first use on the legacy
submission.
v
On to, 2017-04-27 at 11:46 +0100, Chris Wilson wrote:
> Almost from the outset for execlists, we used deferred allocation of the
> logical context and rings. Then we ported the infrastructure for pinning
> contexts back to legacy, and so now we are able to also implement
> deferred allocation for c
== Series Details ==
Series: drm/i915: Defer context state allocation for legacy ring submission
(rev2)
URL : https://patchwork.freedesktop.org/series/23619/
State : success
== Summary ==
Series 23619v2 drm/i915: Defer context state allocation for legacy ring
submission
https://patchwork.fre
On Wed, 26 Apr 2017, Imre Deak wrote:
> Even though an error from these functions isn't fatal we still want to
> have a diagnostic message about it.
>
> v2:
> - Don't do assignments in if statements. (Jani)
>
> Cc: Jani Nikula
> Signed-off-by: Imre Deak
Reviewed-by: Jani Nikula
> ---
> drive
On Thu, Apr 27, 2017 at 10:50:28AM +0100, Chris Wilson wrote:
> On Thu, Apr 27, 2017 at 08:06:36AM +0100, Chris Wilson wrote:
> > +int i915_gem_timeline_mock_selftests(void)
> > +{
> > + static const struct i915_subtest tests[] = {
> > + SUBTEST(igt_seqmap),
>
> I should add a few benc
On Thu, Apr 27, 2017 at 11:06:18AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Defer context state allocation for legacy ring submission
> (rev2)
> URL : https://patchwork.freedesktop.org/series/23619/
> State : success
>
> == Summary ==
>
> Series 23619v2 drm/i915: D
Track the latest fence waited upon on each context, and only add a new
asynchronous wait if the new fence is more recent than the recorded
fence for that context. This requires us to filter out unordered
timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the
absence of a universal iden
On Thu, Apr 27, 2017 at 11:36:54AM +0300, Imre Deak wrote:
> An error from intel_get_pipe_from_connector() would mean a bug somewhere
> else, but we still should check for it to prevent some other more
> obscure bug later.
>
> v2:
> - Fall back to a reasonable default instead of bailing out in cas
On Thu, Apr 27, 2017 at 02:49:55PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 27, 2017 at 11:36:54AM +0300, Imre Deak wrote:
> > An error from intel_get_pipe_from_connector() would mean a bug somewhere
> > else, but we still should check for it to prevent some other more
> > obscure bug later.
> >
On Thu, 27 Apr 2017, Imre Deak wrote:
> On Thu, Apr 27, 2017 at 02:49:55PM +0300, Ville Syrjälä wrote:
>> On Thu, Apr 27, 2017 at 11:36:54AM +0300, Imre Deak wrote:
>> > An error from intel_get_pipe_from_connector() would mean a bug somewhere
>> > else, but we still should check for it to prevent
An error from intel_get_pipe_from_connector() would mean a bug somewhere
else, but we still should check for it to prevent some other more
obscure bug later.
v2:
- Fall back to a reasonable default instead of bailing out in case of
error. (Jani)
v3:
- Fix s/PIPE_INVALID/INVALID_PIPE/ typo. (Jani
Hi Paulo,
Thanks for your review.
On Wednesday 26 April 2017 08:21 PM, Paulo Zanoni wrote:
Em Qua, 2017-04-26 às 10:46 -0300, Paulo Zanoni escreveu:
Em Sáb, 2017-03-18 às 00:45 +0530, Praveen Paneri escreveu:
This series adds Y-tiled buffer creation support into IGT libraries
and
goes on to
Atomic has a few special cases around async commits and event generation
that we need to test. This patch addresses these two tests
- kernel rejects events on a disabled pipe
- events on a pipe that is getting enabled/disabled
For: VIZ-6954
Signed-off-by: Mika Kahola
---
tests/Makefile.sources
Hi Dave, here's an assortment of drm/i915 and gvt fixes for
drm-next/v4.12.
BR,
Jani.
The following changes since commit ab6eb211b07a42a6346e284056422fd9a8576a99:
Merge tag 'drm/panel/for-4.12-rc1' of
git://anongit.freedesktop.org/tegra/linux into drm-next (2017-04-13 06:17:40
+1000)
are a
Pre-calculate engine context size based on engine class and device
generation and store it in the engine instance.
v2:
- Squash and get rid of hw_context_size (Chris)
v3:
- Move after MMIO init for probing on Gen7 and 8 (Chris)
- Retained rounding (Tvrtko)
v4:
- Rebase for deferred legacy context
According to Chris i915_gem_sanitize was meant to reset ILK too.
CCID register existed already on ILK according to the PRM (Chris
verified the address to match too).
HAS_HW_CONTEXTS in i915_l3_write is bogus because each HAS_L3_DPF
match also has .has_hw_contexts = 1 set.
This leads to us being
From: "Lee, Shawn C"
Display driver read DPCD register 0x202, 0x203 and 0x204 to identify
eDP sink status. If PSR exit is ongoing at eDP sink, and eDP source
read these registers at the same time. Panel will report EQ & symbol
lock not done. It will cause panel display flicking.
So driver have to
On Thu, Apr 27, 2017 at 10:35:22PM +0800, Lee, Shawn C wrote:
> From: "Lee, Shawn C"
>
> Display driver read DPCD register 0x202, 0x203 and 0x204 to identify
> eDP sink status. If PSR exit is ongoing at eDP sink, and eDP source
> read these registers at the same time. Panel will report EQ & symbo
Thanks, Imre
I have tested this and I confirm that it solves the pm_runtime_get_sync()
failed: -13 and the issues that follow after.
This is also the root-cause in freedesktop bug 100770, which will be solved by
your patch.
BR,
Marta
> -Original Message-
> From: Deak, Imre
> Sent: Tues
== Series Details ==
Series: series starting with [1/2] drm/i915: Sanitize engine context sizes
URL : https://patchwork.freedesktop.org/series/23630/
State : failure
== Summary ==
Series 23630v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/23630/revisions/1/mbox
On Thu, Apr 27, 2017 at 04:41:33PM +0300, Joonas Lahtinen wrote:
> According to Chris i915_gem_sanitize was meant to reset ILK too.
>
> CCID register existed already on ILK according to the PRM (Chris
> verified the address to match too).
>
> HAS_HW_CONTEXTS in i915_l3_write is bogus because each
On Thu, Apr 27, 2017 at 04:41:33PM +0300, Joonas Lahtinen wrote:
> According to Chris i915_gem_sanitize was meant to reset ILK too.
In that case drawing the line before g4x might make more sense
since it already has a GPU reset that doesn't clobber the display.
>
> CCID register existed already
On Thu, Apr 20, 2017 at 03:58:19PM +0100, Tvrtko Ursulin wrote:
> > static void record_context(struct drm_i915_error_context *e,
> >diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
> >b/drivers/gpu/drm/i915/i915_guc_submission.c
> >index 1642fff9cf13..370373c97b81 100644
> >--- a/drivers/gp
On Thu, Apr 27, 2017 at 10:35:22PM +0800, Lee, Shawn C wrote:
> From: "Lee, Shawn C"
>
> Display driver read DPCD register 0x202, 0x203 and 0x204 to identify
> eDP sink status. If PSR exit is ongoing at eDP sink, and eDP source
> read these registers at the same time. Panel will report EQ & symbo
== Series Details ==
Series: drm/i915/edp: Read link status after exit PSR
URL : https://patchwork.freedesktop.org/series/23631/
State : success
== Summary ==
Series 23631v1 drm/i915/edp: Read link status after exit PSR
https://patchwork.freedesktop.org/api/1.0/series/23631/revisions/1/mbox/
Currently, we only mark the CPU cache as dirty if we skip a clflush.
This leads to some confusion where we have to ask if the object is in
the write domain or missed a clflush. If we always mark the cache as
dirty, this becomes a much simply question to answer.
The goal remains to do as few clflus
For ease of use (i.e. avoiding a few checks and function calls), store
the object's cache coherency next to the cache is dirty bit.
Signed-off-by: Chris Wilson
Cc: Dongwon Kim
Cc: Matt Roper
---
drivers/gpu/drm/i915/i915_gem.c | 14 +++---
drivers/gpu/drm/i915/i915_gem
On Wed, Apr 26, 2017 at 06:00:41PM +0300, David Weinehall wrote:
> Add a bunch of MOCS entries for gen 9 that were missing from intel_mocs.
> Some of these are used by media-sdk; if these entries are missing
> the default will instead be to do everything uncached.
>
> This patch improves media-sdk
== Series Details ==
Series: series starting with [1/2] drm/i915: Mark CPU cache as dirty on every
transition for CPU writes
URL : https://patchwork.freedesktop.org/series/23634/
State : success
== Summary ==
Series 23634v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0
On Thu, Apr 27, 2017 at 04:55:20PM +0200, Arkadiusz Hiler wrote:
> On Wed, Apr 26, 2017 at 06:00:41PM +0300, David Weinehall wrote:
> > Add a bunch of MOCS entries for gen 9 that were missing from intel_mocs.
> > Some of these are used by media-sdk; if these entries are missing
> > the default will
On Thu, Apr 27, 2017 at 05:36:55PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 27, 2017 at 04:41:33PM +0300, Joonas Lahtinen wrote:
> > According to Chris i915_gem_sanitize was meant to reset ILK too.
>
> In that case drawing the line before g4x might make more sense
> since it already has a GPU res
On 27/04/17 12:53 AM, Christoph Hellwig wrote:
> I think you'll need to follow the existing kmap semantics and never
> fail the iomem version either. Otherwise you'll have a special case
> that's almost never used that has a different error path.
>
> Again, wrong way. Suddenly making things fai
On Thu, Apr 27, 2017 at 04:32:55PM +0100, Chris Wilson wrote:
> On Thu, Apr 27, 2017 at 05:36:55PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 27, 2017 at 04:41:33PM +0300, Joonas Lahtinen wrote:
> > > According to Chris i915_gem_sanitize was meant to reset ILK too.
> >
> > In that case drawing th
On 26/04/17 09:56 PM, Herbert Xu wrote:
> On Tue, Apr 25, 2017 at 12:20:54PM -0600, Logan Gunthorpe wrote:
>> Very straightforward conversion to the new function in the caam driver
>> and shash library.
>>
>> Signed-off-by: Logan Gunthorpe
>> Cc: Herbert Xu
>> Cc: "David S. Miller"
>> ---
>>
On 27/04/17 09:27 AM, Jason Gunthorpe wrote:
> On Thu, Apr 27, 2017 at 08:53:38AM +0200, Christoph Hellwig wrote:
> How about first switching as many call sites as possible to use
> sg_copy_X_buffer instead of kmap?
Yeah, I could look at doing that first.
One problem is we might get more Naks o
From: Ville Syrjälä
Clear the notify function pointer in the platform data before we tear
down the driver. Otherwise i915 would end up calling a stale function
pointer and possibly explode.
Cc: Takashi Iwai
Cc: Pierre-Louis Bossart
Signed-off-by: Ville Syrjälä
---
sound/x86/intel_hdmi_audio.
From: Ville Syrjälä
Okay, here's the second attempt at getting multiple pipes playing back
audio on the VLV/CHV HDMI LPE audio device. The main change from v1 is
that now the PCM devices are associated with ports instead of pipes,
so the audio from one device always gets output on the same displa
From: Ville Syrjälä
The pending_notify flag in the LPE audio platform data is pointless,
actually unused. So let's kill it off.
v2: Fix typo in patch subject
Cc: Takashi Iwai
Cc: Pierre-Louis Bossart
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_lpe_audio.c | 2 --
include/drm
From: Ville Syrjälä
Not calling pm_runtime_enable() means that runtime PM can't be
enabled at all via sysfs. So we definitely need to call it
from somewhere.
Calling it from the driver seems like a bad idea because it
would have to be paired with a pm_runtime_disable() at driver
unload time, oth
From: Ville Syrjälä
We can determine that the pipe was shut down from pipe<0, so there's
no point in duplicating that information as 'hdmi_connected'.
v2: Use pipe<0 instead of port<0 as we'll want to do per-port
PCM devices later
Initialize pipe to -1 to inidicate inactive initial state
From: Ville Syrjälä
There's no need to distinguish between the DP link rate and HDMI TMDS
clock for the purposes of the LPE audio. Both are actually the same
thing more or less, which is the link symbol clock. So let's just
call the thing ls_clock and simplify the code.
Cc: Takashi Iwai
Cc: Pie
From: Ville Syrjälä
In preparation for register a PCM device for each pipe adjust
link up the ctl elements with the corresponding PCM device.
Cc: Takashi Iwai
Cc: Pierre-Louis Bossart
Signed-off-by: Ville Syrjälä
---
sound/x86/intel_hdmi_audio.c | 23 +++
1 file changed,
From: Ville Syrjälä
Shuffle the arguments to intel_lpe_audio_notify() around a bit. Pipe
and port being the most important things, so let's put the first, and
thre rest can come in as is. Also constify the eld argument.
Cc: Takashi Iwai
Cc: Pierre-Louis Bossart
Signed-off-by: Ville Syrjälä
--
From: Ville Syrjälä
Now that the kernel driver exposes several pcm devices, update
the hdmi pcm definitions to match.
Cc: Takashi Iwai
Cc: Pierre-Louis Bossart
Signed-off-by: Ville Syrjälä
---
src/conf/cards/HdmiLpeAudio.conf | 74 ++--
1 file changed, 72
From: Ville Syrjälä
To allow multiple PCM devices to be registered for the LPE audio card,
split the private data into card and PCM specific chunks. For now we'll
stick to just one PCM device as before.
v2: Rework to do a pcm device per port instead of per pipe
Cc: Takashi Iwai
Cc: Pierre-Loui
From: Ville Syrjälä
Now that everything is in place let's register a PCM device for
each port of the display engine. This will make it possible to
actually output audio to multiple displays at the same time. And
it avoids modesets on unrelated displays from clobbering up the
ELD and whatnot for t
From: Ville Syrjälä
vlv_display_irq_postinstall() enables the LPE audio interrupts
regardless of whether the LPE audio irq chip has masked/unmasked
them. Also the irqchip masking/unmasking doesn't consider the state
of the display power well or the device, and hence just leads to
dmesg spew when
From: Ville Syrjälä
Split the LPE audio platform data into a port specific
chunk and device specific chunk. Eventually we'll have
a port specific chunk for each port, but for now we'll
stick to just one.
We'll also get rid of the intel_hdmi_lpe_audio_eld structure
which doesn't seem to have any
== Series Details ==
Series: conf: Add multiple hdmi pcm definition for Intel LPE audio
URL : https://patchwork.freedesktop.org/series/23639/
State : success
== Summary ==
Series 23639v1 conf: Add multiple hdmi pcm definition for Intel LPE audio
https://patchwork.freedesktop.org/api/1.0/series
On Thu, Apr 27, 2017 at 06:30:42PM +0300, David Weinehall wrote:
> On Thu, Apr 27, 2017 at 04:55:20PM +0200, Arkadiusz Hiler wrote:
> > On Wed, Apr 26, 2017 at 06:00:41PM +0300, David Weinehall wrote:
> > > Add a bunch of MOCS entries for gen 9 that were missing from intel_mocs.
> > > Some of these
On Wed, Apr 26, 2017 at 02:28:32PM +0200, Bastien Nocera wrote:
> On Mon, 2017-04-24 at 15:48 +0300, Ville Syrjälä wrote:
> >
>
>
> > > I've a patch for iio-sensor-proxy which fixes the rotation under
> > > Xorg /
> > > Wayland when using a desktop environment which honors iio-sensor-
> > > prox
On Thu, 2017-04-27 at 19:24 +0300, Ville Syrjälä wrote:
> On Wed, Apr 26, 2017 at 02:28:32PM +0200, Bastien Nocera wrote:
> > On Mon, 2017-04-24 at 15:48 +0300, Ville Syrjälä wrote:
> > >
> >
> >
> >
> > > > I've a patch for iio-sensor-proxy which fixes the rotation
> > > > under
> > > > Xorg /
On 27/04/2017 12:48, Chris Wilson wrote:
Track the latest fence waited upon on each context, and only add a new
asynchronous wait if the new fence is more recent than the recorded
fence for that context. This requires us to filter out unordered
timelines, which are noted by DMA_FENCE_NO_CONTEXT.
On Thu, Apr 27, 2017 at 05:47:32PM +0100, Tvrtko Ursulin wrote:
>
> On 27/04/2017 12:48, Chris Wilson wrote:
> >diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
> >b/drivers/gpu/drm/i915/i915_gem_request.c
> >index 5fa4e52ded06..d9f76665bc6b 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_reque
On 12/04/17 09:22, Michel Thierry wrote:
On 12/04/17 08:58, Chris Wilson wrote:
On Wed, Apr 12, 2017 at 04:48:42PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Looks like intel_guc_reset had the ability to sleep under the
uncore spinlock since forever but it wasn't detected until the
re
On 27/04/2017 19:14, Michel Thierry wrote:
On 12/04/17 09:22, Michel Thierry wrote:
On 12/04/17 08:58, Chris Wilson wrote:
On Wed, Apr 12, 2017 at 04:48:42PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Looks like intel_guc_reset had the ability to sleep under the
uncore spinlock since
On 27/04/17 11:20, Tvrtko Ursulin wrote:
On 27/04/2017 19:14, Michel Thierry wrote:
On 12/04/17 09:22, Michel Thierry wrote:
On 12/04/17 08:58, Chris Wilson wrote:
On Wed, Apr 12, 2017 at 04:48:42PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Looks like intel_guc_reset had the abili
On 26/04/17 01:44 AM, Christoph Hellwig wrote:
> I think we'll at least need a draft of those to make sense of these
> patches. Otherwise they just look very clumsy.
Ok, what follows is a draft patch attempting to show where I'm thinking
of going with this. Obviously it will not compile because
On 26/04/17 01:37 AM, Roger Pau Monné wrote:
> On Tue, Apr 25, 2017 at 12:21:02PM -0600, Logan Gunthorpe wrote:
>> Straightforward conversion to the new helper, except due to the lack
>> of error path, we have to use SG_MAP_MUST_NOT_FAIL which may BUG_ON in
>> certain cases in the future.
>>
>> S
On Thu, Apr 27, 2017 at 06:25:47PM +0100, Chris Wilson wrote:
> On Thu, Apr 27, 2017 at 05:47:32PM +0100, Tvrtko Ursulin wrote:
> > >+int intel_timeline_sync_set(struct intel_timeline *tl, u64 id, u32 seqno)
> > >+{
> > >+ struct intel_timeline_sync *p = tl->sync;
> > >+
> > >+ /* We expect to be
On Thu, Apr 27, 2017 at 09:34:10PM +0100, Chris Wilson wrote:
> On Thu, Apr 27, 2017 at 06:25:47PM +0100, Chris Wilson wrote:
> > On Thu, Apr 27, 2017 at 05:47:32PM +0100, Tvrtko Ursulin wrote:
> > > >+int intel_timeline_sync_set(struct intel_timeline *tl, u64 id, u32
> > > >seqno)
> > > >+{
> > >
On 27/04/17 02:53 PM, Jason Gunthorpe wrote:
> blkfront is one of the drivers I looked at, and it appears to only be
> memcpying with the bvec_data pointer, so I wonder why it does not use
> sg_copy_X_buffer instead..
Yes, sort of...
But you'd potentially end up calling sg_copy_to_buffer multip
On 27/04/17 04:11 PM, Jason Gunthorpe wrote:
> On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote:
> Well, that is in the current form, with more users it would make sense
> to optimize for the single page case, eg by providing the existing
> call, providing a faster single-page-only
From: Arun Siluvery
GuC expects a list of registers from the driver which are saved/restored
during engine reset. The type of value to be saved is controlled by
flags. We provide a minimal set of registers that we want GuC to save and
restore. This is not an issue in case of engine reset as drive
From: Mika Kuoppala
To perform engine reset we first disable engine to capture its state. This
is done by issuing a reset request. Because we are reusing existing
infrastructure, again when we actually reset an engine, reset function
checks engine mask and issues reset request again which is unne
From: Arun Siluvery
This is a preparatory patch which modifies error handler to do per engine
hang recovery. The actual patch which implements this sequence follows
later in the series. The aim is to prepare existing recovery function to
adapt to this new function where applicable (which fails at
From: Arun Siluvery
A new variable is added to export the reset counts to debugfs, this
includes full gpu reset and engine reset count. This is useful for tests
where they are expected to trigger reset; these counts are checked before
and after the test to ensure the same.
v2: Include reset engi
These patches add the reset-engine feature from Gen8. This is also
referred to as Timeout detection and recovery (TDR). This complements to
the full gpu reset feature available in i915 but it only allows to reset a
particular engine instead of all engines thus providing a light weight
engine reset
1 - 100 of 123 matches
Mail list logo
