Chris Wilson writes:
> Instead of tediously and fragilely counting up the number of dwords
> required to emit the breadcrumb to seal a request, fake a request and
> measure it automatically once during engine setup.
>
> The downside is that this requires a fair amount of mocking to create a
> pro
Hi Rodrigo and Maarten,
On 24-01-19 23:20, Rodrigo Vivi wrote:
On Thu, Jan 24, 2019 at 02:01:14PM +0100, Maarten Lankhorst wrote:
From: Hans de Goede
We really want to have fastboot enabled by default to avoid an ugly
modeset during boot.
Rather then enabling it everywhere, lets start with e
Quoting Chris Wilson (2019-01-25 02:30:01)
> We have a number of tasks that we like to run when idle and parking the
> GPU into a powersaving mode. A few of those tasks are using the global
> idle point as a convenient moment when all previous execution has been
> required (and so we know that the
On Thu, Jan 24, 2019 at 06:45:52PM +0100, Sam Ravnborg wrote:
> Hi Daniel.
>
> On Thu, Jan 24, 2019 at 05:58:11PM +0100, Daniel Vetter wrote:
> > The fbdev emulation helpers pretty much assume that this is set.
> > Let's do it for everyone.
>
> I do not know this code at all.
> But I failed to fo
On Thu, Jan 24, 2019 at 06:40:52PM +0100, Noralf Trønnes wrote:
>
>
> Den 24.01.2019 17.58, skrev Daniel Vetter:
> > The fbdev split between fix and var information is kinda
> > pointless for drm drivers since everything is fixed: The fbdev
> > emulation doesn't support changing modes at all.
> >
On Thu, Jan 24, 2019 at 05:58:29PM +0100, Daniel Vetter wrote:
> This should not result in any changes.
>
> v2: Rebase over vbox changes - vbox gained it's own line to fill
> fix.id.
>
> Signed-off-by: Daniel Vetter
> Cc: Greg Kroah-Hartman
> Cc: Hans de Goede
> Cc: Daniel Vetter
> Cc: Alexan
On Thu, Jan 24, 2019 at 07:00:11PM +0100, Sam Ravnborg wrote:
> Hi Daniel.
>
> On Thu, Jan 24, 2019 at 05:58:14PM +0100, Daniel Vetter wrote:
> > Should not result in any changes.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Dave Airlie
> > Cc: Junwei Zhang
> > Cc: Alex Deucher
> > Cc: "Chris
On Fri, Jan 25, 2019 at 07:39:26AM +0100, Gerd Hoffmann wrote:
> On Thu, Jan 24, 2019 at 05:58:24PM +0100, Daniel Vetter wrote:
> > This should not result in any changes.
>
> I'd love to merge https://patchwork.freedesktop.org/series/53951/
> instead (which will -- among other things -- switch qxl
Chris Wilson writes:
> Now that we know we measure the size of the engine->emit_breadcrumb()
> correctly, we can remove the previous manual counting.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_request.c | 4 ++--
> drivers/gpu/drm/i915/intel_engine_cs.c | 7 +++
Chris Wilson writes:
> Simplify by using sizeof(u32) to convert from the index inside the HWSP
> to the byte offset. This has the advantage of not only being shorter
> (and so not upsetting checkpatch!) but that it matches use where we are
> writing to byte addresses using other commands than MI_
On Thu, Jan 24, 2019 at 06:38:33PM +0100, Sam Ravnborg wrote:
> Hi Daniel.
>
> > +
> > + /**
> > +* @DRIVER_HAVE_DMA:
> > +*
> > +* Driver supports DMA, the userspace DMA API will be supported. Only
> > +* for legacy drivers. Do not use.
> > +*/
> > + DRIVER_HAVE_DMA
On Thu, Jan 24, 2019 at 12:41:27PM +0200, Joonas Lahtinen wrote:
Quoting Lucas De Marchi (2019-01-24 02:06:04)
From: Tomasz Lis
The table has been unified across OSes to minimize virtualization overhead.
The MOCS table is now published as part of bspec, and versioned. Entries
are supposed to
On Tue, Jan 22, 2019 at 06:35:21PM +, Chris Wilson wrote:
> Take an environment variable, SELFTESTS=foo,bar, and pass that along to
> the kernel (as i915.st_filter=foo,bar) to provide fine grained test
> selection. This can be either as an exact match to select only that
> test, or to exclude o
Den 25.01.2019 09.48, skrev Daniel Vetter:
> On Thu, Jan 24, 2019 at 06:40:52PM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 24.01.2019 17.58, skrev Daniel Vetter:
>>> The fbdev split between fix and var information is kinda
>>> pointless for drm drivers since everything is fixed: The fbdev
>>> emul
Quoting Mika Kuoppala (2019-01-25 08:34:37)
> Chris Wilson writes:
>
> > Instead of tediously and fragilely counting up the number of dwords
> > required to emit the breadcrumb to seal a request, fake a request and
> > measure it automatically once during engine setup.
> >
> > The downside is tha
Instead of tediously and fragilely counting up the number of dwords
required to emit the breadcrumb to seal a request, fake a request and
measure it automatically once during engine setup.
The downside is that this requires a fair amount of mocking to create a
proper breadcrumb. Still, should be l
Quoting Petri Latvala (2019-01-25 09:44:50)
> On Tue, Jan 22, 2019 at 06:35:21PM +, Chris Wilson wrote:
> > Take an environment variable, SELFTESTS=foo,bar, and pass that along to
> > the kernel (as i915.st_filter=foo,bar) to provide fine grained test
> > selection. This can be either as an exa
On Fri, Jan 25, 2019 at 10:46 AM Noralf Trønnes wrote:
>
>
>
> Den 25.01.2019 09.48, skrev Daniel Vetter:
> > On Thu, Jan 24, 2019 at 06:40:52PM +0100, Noralf Trønnes wrote:
> >>
> >>
> >> Den 24.01.2019 17.58, skrev Daniel Vetter:
> >>> The fbdev split between fix and var information is kinda
> >
Hi Daniel.
On Thu, Jan 24, 2019 at 05:58:06PM +0100, Daniel Vetter wrote:
> If a non-legacy driver calls these it's valid to assume there is
> interrupt support. The flag is really only needed for legacy drivers.
>
> Also remove all the flag usage from non-legacy drivers.
>
> Signed-off-by: Dani
On 22/01/2019 14:19, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-18 16:03:27)
On 18/01/2019 14:00, Chris Wilson wrote:
Our goal is to remove struct_mutex and replace it with fine grained
locking. One of the thorny issues is our eviction logic for reclaiming
space for an execbuffer (or
On 25/01/2019 02:30, Chris Wilson wrote:
Missed breadcrumb detection is defunct due to the tight coupling with
dma_fence signaling and the myriad ways we may signal fences from
everywhere but from an interrupt, i.e. we frequently signal a fence
before we even see its interrupt. This means that e
== Series Details ==
Series: drm/i915: Measure the required reserved size for request emission (rev2)
URL : https://patchwork.freedesktop.org/series/55683/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5480 -> Patchwork_12036
===
Chris Wilson writes:
> In bringup on simulated HW even rudimentary tests are slow, and so many
> may fail that we want to be able to filter out the noise to focus on the
> specific problem. Even just the tests groups provided for igt is not
> specific enough, and we would like to isolate one part
Quoting Mika Kuoppala (2019-01-25 11:44:30)
> Chris Wilson writes:
> > +static bool apply_subtest_filter(const char *caller, const char *name)
> > +{
> > + char *filter, *sep, *tok;
> > + bool result = true;
> > +
> > + filter = kstrdup(i915_selftest.filter, GFP_KERNEL);
>
> Was going
Simplify by using sizeof(u32) to convert from the index inside the HWSP
to the byte offset. This has the advantage of not only being shorter
(and so not upsetting checkpatch!) but that it matches use where we are
writing to byte addresses using other commands than MI_STORE_DWORD_IMM.
v2: Drop the
Now that we know we measure the size of the engine->emit_breadcrumb()
correctly, we can remove the previous manual counting.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_request.c | 4 ++--
drivers/gpu/drm/i915/intel_engine_cs.c | 7 +++
driver
>-Original Message-
>From: Shankar, Uma
>Sent: Wednesday, January 16, 2019 9:52 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Lankhorst, Maarten ; Syrjala, Ville
>; Sharma, Shashank ;
>Roper, Matthew D ; Shankar, Uma
>
>Subject: [v6 0/6] Add support for Gen 11 pipe color features
>
>This p
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Remove manual breadcumb counting
URL : https://patchwork.freedesktop.org/series/55726/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5481 -> Patchwork_12037
===
Chris Wilson writes:
> Now that the submission backends are controlled via their own spinlocks,
> with a wave of a magic wand we can lift the struct_mutex requirement
> around GPU reset. That is we allow the submission frontend (userspace)
> to keep on submitting while we process the GPU reset as
In preparation for the next few commits, make resetting the GPU atomic.
Currently, we have prepared gen6+ for atomic resetting of individual
engines, but now there is a requirement to perform the whole device
level reset (just the register poking) from inside an atomic context.
Signed-off-by: Chri
The guc (and huc) currently inexcruitably depend on struct_mutex for
device reinitialisation from inside the reset, and indeed taking any
mutex here is verboten (as we must be able to reset from underneath any
of our mutexes). That makes recovering the guc unviable without, for
example, reserving c
Trim the struct_mutex hold and exclude the call to i915_gem_set_wedged()
as a reminder that it must be callable without struct_mutex held.
Signed-off-by: Chris Wilson
Cc: Michal Wajdeczko
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 7 +++
Now that the submission backends are controlled via their own spinlocks,
with a wave of a magic wand we can lift the struct_mutex requirement
around GPU reset. That is we allow the submission frontend (userspace)
to keep on submitting while we process the GPU reset as we can suspend
the backend ind
Always perform the requested reset, even if we believe the engine is
idle. Presumably there was a reason the caller wanted the reset, and in
the near future we lose the easy tracking for whether the engine is
idle.
Signed-off-by: Chris Wilson
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/
Quoting Tvrtko Ursulin (2019-01-25 10:46:19)
>
> On 22/01/2019 14:19, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-01-18 16:03:27)
> >>
> >> On 18/01/2019 14:00, Chris Wilson wrote:
> >>> Our goal is to remove struct_mutex and replace it with fine grained
> >>> locking. One of the thorny i
Quoting Chris Wilson (2019-01-25 13:38:09)
> Quoting Tvrtko Ursulin (2019-01-25 10:46:19)
> >
> > On 22/01/2019 14:19, Chris Wilson wrote:
> > > Quoting Tvrtko Ursulin (2019-01-18 16:03:27)
> > >>
> > >> On 18/01/2019 14:00, Chris Wilson wrote:
> > >>> Our goal is to remove struct_mutex and replac
== Series Details ==
Series: series starting with [CI,1/5] drm/i915: Make all GPU resets atomic
URL : https://patchwork.freedesktop.org/series/55730/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4273a708fc23 drm/i915: Make all GPU resets atomic
-:33: CHECK:USLEEP_RANGE: usleep
== Series Details ==
Series: series starting with [CI,1/5] drm/i915: Make all GPU resets atomic
URL : https://patchwork.freedesktop.org/series/55730/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Make all GPU resets atomic
Okay!
Commit: drm
Our goal is to remove struct_mutex and replace it with fine grained
locking. One of the thorny issues is our eviction logic for reclaiming
space for an execbuffer (or GTT mmaping, among a few other examples).
While eviction itself is easy to move under a per-VM mutex, performing
the activity tracki
== Series Details ==
Series: drm/i915: Measure the required reserved size for request emission (rev2)
URL : https://patchwork.freedesktop.org/series/55683/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5480_full -> Patchwork_12036_full
=
On 25/01/2019 13:46, Chris Wilson wrote:
Quoting Chris Wilson (2019-01-25 13:38:09)
Quoting Tvrtko Ursulin (2019-01-25 10:46:19)
On 22/01/2019 14:19, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-18 16:03:27)
On 18/01/2019 14:00, Chris Wilson wrote:
Our goal is to remove struct_mute
On 25/01/2019 02:29, Chris Wilson wrote:
The global seqno is defunct and so we have no meaningful indicator of
forward progress for an engine. You need to listen to the request
signaling tracepoints instead.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 2 --
drivers/
== Series Details ==
Series: series starting with [CI,1/5] drm/i915: Make all GPU resets atomic
URL : https://patchwork.freedesktop.org/series/55730/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5483 -> Patchwork_12038
Sum
Quoting Tvrtko Ursulin (2019-01-25 13:54:05)
>
> On 25/01/2019 02:29, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_request.c
> > b/drivers/gpu/drm/i915/i915_request.c
> > index 2171df2d3019..c09a6644a2ab 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/
== Series Details ==
Series: drm/i915: Stop tracking MRU activity on VMA
URL : https://patchwork.freedesktop.org/series/55731/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5483 -> Patchwork_12039
Summary
---
**SUCCE
We can't safely probe Type C ports, whether they are a legacy or a
USB/Thunderbolt DP Alternate Type C port. This would require performing
the TypeC connect sequence - as described by the specification - but
that may have unwanted side-effects. These side-effects include at least
- without complete
Quoting Chris Wilson (2019-01-25 14:26:49)
> Quoting Tvrtko Ursulin (2019-01-25 13:54:05)
> >
> > On 25/01/2019 02:29, Chris Wilson wrote:
> > > +
> > > + requests[n] = i915_request_get(rq);
> > > + i915_request_add(rq);
> > > +
> > > + m
On Thu, 24 Jan 2019 at 16:58, Daniel Vetter wrote:
>
> This is only used by drm_irq_install(), which is an optional helper.
> And the right choice is to set it for all pci devices, and not for
> everything else.
>
Can you please add some information (or reference) why it's the right choice?
Thank
On Thu, 24 Jan 2019 at 17:00, Daniel Vetter wrote:
>
> It's 0.
>
I'd add a bit more information here. Feel free to reuse as much/little
of the following:
Both macros evaluate to 0. At the same time flag is already set to
zero since the struct is kzalloc'd in framebuffer_alloc().
As called by drm_
On Tue, Jan 22, 2019 at 02:49:13PM +0530, Mahesh Kumar wrote:
> Hi,
>
>
> On Mon, Jan 21, 2019 at 9:01 PM Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > The code managing the dbuf slices is borked and needs some
> > real work to fix. In the meantime let's just stop using the
> > sec
On Mon, Jan 21, 2019 at 05:31:43PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The code managing the dbuf slices is borked and needs some
> real work to fix. In the meantime let's just stop using the
> second slice.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> d
On Thu, 24 Jan 2019 at 16:58, Daniel Vetter wrote:
>
> If a non-legacy driver calls these it's valid to assume there is
> interrupt support. The flag is really only needed for legacy drivers.
... legacy drivers which issue the IRQ via the DRM_IOCTL_CONTROL legacy IOCTL.
At a later stage, we migh
On Thu, Jan 24, 2019 at 05:58:27PM +0100, Daniel Vetter wrote:
> Another driver that didn't set fbinfo->fix.id before.
>
> Signed-off-by: Daniel Vetter
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: linux-te...@vger.kernel.org
> ---
> drivers/gpu/drm/tegra/fb.c | 4 +---
> 1 file changed, 1
On Thu, Jan 24, 2019 at 05:58:31PM +0100, Daniel Vetter wrote:
> It's 0.
>
> Signed-off-by: Daniel Vetter
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Cc: Kukjin Kim
> Cc: Krzysztof Kozlowski
> Cc: Patrik Jakobsson
> Cc: Ben Skeggs
> Cc: Sandy Huang
> Cc:
From: Tvrtko Ursulin
Changes since last version:
* One patch got to drm-tip early so removed from this series.
* Two small cleanups in the area of request emission.
Lionel Landwerlin (2):
drm/i915: Record the sseu configuration per-context & engine
drm/i915/perf: lock powergating configura
From: Tvrtko Ursulin
Timeline barrier allows serialization between different timelines.
After calling i915_timeline_set_barrier with a request, all following
submissions on this timeline will be set up as depending on this request,
or barrier. Once the barrier has been completed it automatically
From: Tvrtko Ursulin
Exercise the context image reconfiguration logic for idle and busy
contexts, with the resets thrown into the mix as well.
Free from the uAPI restrictions this test runs on all Gen9+ platforms
with slice power gating.
v2:
* Rename some helpers for clarity.
* Include subtes
From: Lionel Landwerlin
If some of the contexts submitting workloads to the GPU have been
configured to shutdown slices/subslices, we might loose the NOA
configurations written in the NOA muxes.
One possible solution to this problem is to reprogram the NOA muxes
when we switch to a new context.
From: Lionel Landwerlin
We want to expose the ability to reconfigure the slices, subslice and
eu per context and per engine. To facilitate that, store the current
configuration on the context for each engine, which is initially set
to the device default upon creation.
v2: record sseu configurati
From: Tvrtko Ursulin
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
r
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Remove manual breadcumb counting
URL : https://patchwork.freedesktop.org/series/55726/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5481_full -> Patchwork_12037_full
=
On Tue, Jan 22, 2019 at 02:58:46PM +0530, Mahesh Kumar wrote:
> Hi,
>
> On Mon, Jan 21, 2019 at 9:01 PM Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > The code managing the dbuf slices is borked and needs some
> > real work to fix. In the meantime let's just stop using the
> > second
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev19)
URL : https://patchwork.freedesktop.org/series/48194/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b46b66196670 drm/i915: Record the sseu configuration per-context & engine
56a1aaefc8e7 drm/i915/p
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev19)
URL : https://patchwork.freedesktop.org/series/48194/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Record the sseu configuration per-context & engine
-drivers/
Quoting Tvrtko Ursulin (2019-01-25 15:24:39)
> From: Tvrtko Ursulin
>
> Timeline barrier allows serialization between different timelines.
>
> After calling i915_timeline_set_barrier with a request, all following
> submissions on this timeline will be set up as depending on this request,
> or ba
== Series Details ==
Series: drm/i915/icl: Add TypeC ports only if VBT is present
URL : https://patchwork.freedesktop.org/series/55733/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5484 -> Patchwork_12040
Summary
---
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev19)
URL : https://patchwork.freedesktop.org/series/48194/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5484 -> Patchwork_12041
Summary
---
On Fri, Jan 25, 2019 at 02:46:55PM +, Emil Velikov wrote:
> On Thu, 24 Jan 2019 at 16:58, Daniel Vetter wrote:
> >
> > This is only used by drm_irq_install(), which is an optional helper.
> > And the right choice is to set it for all pci devices, and not for
> > everything else.
> >
> Can you
From: Tvrtko Ursulin
Timeline barrier allows serialization between different timelines.
After calling i915_timeline_set_barrier with a request, all following
submissions on this timeline will be set up as depending on this request,
or barrier. Once the barrier has been completed it automatically
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev20)
URL : https://patchwork.freedesktop.org/series/48194/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e1d7e70fd818 drm/i915: Record the sseu configuration per-context & engine
f8dd0fb8513e drm/i915/p
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev20)
URL : https://patchwork.freedesktop.org/series/48194/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Record the sseu configuration per-context & engine
-drivers/
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev20)
URL : https://patchwork.freedesktop.org/series/48194/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5484 -> Patchwork_12042
Summary
---
On Wed, Jan 23, 2019 at 03:49:02PM +0200, Imre Deak wrote:
> On Mon, Nov 12, 2018 at 06:59:59PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > On gen3 we must disable the TV encoder vertical filter for >1024
> > pixel wide sources. Once that's done all we can is try to center
> > the
== Series Details ==
Series: series starting with [CI,1/5] drm/i915: Make all GPU resets atomic
URL : https://patchwork.freedesktop.org/series/55730/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5483_full -> Patchwork_12038_full
===
From: Ville Syrjälä
Just like the frame counter, the pixel counter also reads zero
all the time when the TV encoder is used. Fortunately the
scanline counter still works sufficiently well so let's use that
to correct the vblank timestamps. Otherwise the timestamps may
en up out of whack, and sinc
From: Ville Syrjälä
Ever since commit 204474a6b859 ("drm/i915: Pass down rc in
intel_encoder->compute_config()") we're supposed to return an
errno from .compute_config(). I failed to notice that when
pushing the TV encoder fixes which were written before said
commmit. Fix up the return value for
== Series Details ==
Series: drm/i915: Stop tracking MRU activity on VMA
URL : https://patchwork.freedesktop.org/series/55731/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5483_full -> Patchwork_12039_full
Summary
---
== Series Details ==
Series: series starting with [v2,1/2] drm/dp/mst: Provide defines for ACK vs.
NAK reply type (rev2)
URL : https://patchwork.freedesktop.org/series/55581/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b8534842e422 drm/dp/mst: Provide defines for ACK vs. NAK
On Fri, Jan 25, 2019 at 09:44:06AM +0100, Daniel Vetter wrote:
> On Thu, Jan 24, 2019 at 06:45:52PM +0100, Sam Ravnborg wrote:
> > Hi Daniel.
> >
> > On Thu, Jan 24, 2019 at 05:58:11PM +0100, Daniel Vetter wrote:
> > > The fbdev emulation helpers pretty much assume that this is set.
> > > Let's do
From: Ville Syrjälä
We're incorrectly masking off the R/V channel enable bit from
KEYMSK. Fix it up.
Cc: Maarten Lankhorst
Cc: Matt Roper
Fixes: b20815255693 ("drm/i915: Add plane alpha blending support, v2.")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
1 fil
== Series Details ==
Series: series starting with [1/2] drm/i915/tv: Fix return value for
intel_tv_compute_config()
URL : https://patchwork.freedesktop.org/series/55743/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
03b411930b07 drm/i915/tv: Fix return value for intel_tv_compu
== Series Details ==
Series: series starting with [v2,1/2] drm/dp/mst: Provide defines for ACK vs.
NAK reply type (rev2)
URL : https://patchwork.freedesktop.org/series/55581/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5486 -> Patchwork_12043
===
== Series Details ==
Series: series starting with [1/2] drm/i915/tv: Fix return value for
intel_tv_compute_config()
URL : https://patchwork.freedesktop.org/series/55743/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5486 -> Patchwork_12044
== Series Details ==
Series: drm/i915: Fix skl srckey mask bits
URL : https://patchwork.freedesktop.org/series/55744/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5486 -> Patchwork_12045
Summary
---
**SUCCESS**
N
On Fri, Jan 25, 2019 at 03:49:07PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/icl: Add TypeC ports only if VBT is present
> URL : https://patchwork.freedesktop.org/series/55733/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_5484 -> Patchwork_
On Tue, Dec 18, 2018 at 09:51:58AM -0800, Matt Roper wrote:
> We currently program userspace-provided gamma and degamma LUT's into our
> hardware without really checking to see whether they satisfy our
> hardware's rules. We should try to catch tables that are invalid for
> our hardware early and
On Fri, Jan 25, 2019 at 08:19:30PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Ever since commit 204474a6b859 ("drm/i915: Pass down rc in
> intel_encoder->compute_config()") we're supposed to return an
> errno from .compute_config(). I failed to notice that when
> pushing the TV encoder
On Fri, Jan 25, 2019 at 08:19:31PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Just like the frame counter, the pixel counter also reads zero
> all the time when the TV encoder is used. Fortunately the
> scanline counter still works sufficiently well so let's use that
> to correct the v
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev20)
URL : https://patchwork.freedesktop.org/series/48194/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5484_full -> Patchwork_12042_full
Summary
On Tue, Jan 22, 2019 at 10:38:30AM +0100, Daniel Vetter wrote:
> On Mon, Jan 21, 2019 at 10:24:28PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Only some of the drm mode object lookups have a corresponding debug
> > print for the lookup failure. That makes logs a bit hard to parse
On Tue, Jan 22, 2019 at 10:39:38AM +0100, Daniel Vetter wrote:
> On Mon, Jan 21, 2019 at 10:24:29PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Use ENOENT consistently for the case where the requested property
> > isn't found, and EINVAL for the case where the object has no
> > pr
On Sat, Dec 01, 2018 at 12:31:48PM +0100, Hans de Goede wrote:
> If we exit vlv_dsi_init() because we failed to find a fixed_mode, then
> we've already called drm_connector_init() and we should call
> drm_connector_cleanup() to unregister the connector object.
>
> Signed-off-by: Hans de Goede
Re
On Fri, 2019-01-25 at 16:34 +0200, Imre Deak wrote:
> We can't safely probe Type C ports, whether they are a legacy or a
> USB/Thunderbolt DP Alternate Type C port. This would require
> performing
> the TypeC connect sequence - as described by the specification - but
> that may have unwanted side-e
On Wed, Dec 19, 2018 at 01:59:12PM +0530, raviraj.p.sita...@intel.com wrote:
> From: P Raviraj Sitaram
>
> framebuffer for NV12 requires the pitch to the multiplier of 4, instead
> of the width. This patch corrects it.
>
> For instance, a 480p video, whose width and pitch are 854 and 896
> respe
On Fri, Jan 25, 2019 at 08:38:46PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We're incorrectly masking off the R/V channel enable bit from
> KEYMSK. Fix it up.
>
> Cc: Maarten Lankhorst
> Cc: Matt Roper
> Fixes: b20815255693 ("drm/i915: Add plane alpha blending support, v2.")
> Sig
In order to avoid preempting ourselves, we currently refuse to schedule
the tasklet if we reschedule an inflight context. However, this glosses
over a few issues such as what happens after a CS completion event and
we then preempt the newly executing context with itself, or if something
else causes
After noticing that we trigger preemption events for currently executing
requests, as well as requests that complete before the preemption and
attempting to suppress those preemption events, it is wise to not
consider the queue_priority to be authoritative. As only track the
maximum priority see be
On unwinding the active request we give it a small (limited to internal
priority levels) boost to prevent it from being gazumped a second time.
However, this means that it can be promoted to above the request that
triggered the preemption request, causing a preempt-to-idle cycle for no
change. We c
We should not pass DPLL_ID_ICL_DPLL0 or DPLL_ID_ICL_DPLL1 to this
function because the path is only taken for non-combophy ports. Let the
warning trigger if improper value is given.
While at it, rename the function to match the register name we are
trying to program.
v2: fix typo in comment
Sign
Even if we don't have the correct clock and get a warning, we should not
skip the return.
v2: improve commit message (from Joonas)
Fixes: 1fa11ee2d9d0 ("drm/i915/icl: start adding the TBT pll")
Cc: Paulo Zanoni
Cc: # v4.19+
Signed-off-by: Lucas De Marchi
Reviewed-by: Mika Kahola
---
drivers/
1 - 100 of 133 matches
Mail list logo
