On Mon, 21 Jan 2019 at 23:53, Rafael J. Wysocki wrote:
>
> On Mon, Jan 21, 2019 at 4:17 PM Vincent Guittot
> wrote:
> >
> > On Fri, 18 Jan 2019 at 13:08, Guenter Roeck wrote:
> > >
> > > On 1/18/19 3:05 AM, Rafael J. Wysocki wrote:
> > > > On Fri, Jan 18, 2019 at 11:53 AM Vincent Guittot
> > >
== Series Details ==
Series: Define MOCS table for Icelake (rev2)
URL : https://patchwork.freedesktop.org/series/54070/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5459_full -> Patchwork_12002_full
Summary
---
On 08-01-19 17:08, Maarten Lankhorst wrote:
Now that we've solved the backlight issue, I think it's time to enable
this again by default. We've enabled it in the past, but backlight
issues prevented us from enabling it by default.
Our hardware readout is pretty complete, and with all of the
On 08-01-19 17:08, Maarten Lankhorst wrote:
On lynxpoint the bios sometimes sets up the backlight using the CPU
display, but the driver expects using the PWM PCH override register.
Read the value from the CPU register, then convert it to the other
units by converting from the old duty cycle,
On 08-01-19 17:08, Maarten Lankhorst wrote:
Now that our state comparison functions are pretty complete, we should
enable fastset by default when a modeset can be avoided. Even if we're
not completely certain about the inherited state, we can be certain
after the first modeset that our sw
== Series Details ==
Series: Define MOCS table for Icelake (rev2)
URL : https://patchwork.freedesktop.org/series/54070/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5459 -> Patchwork_12002
Summary
---
**SUCCESS**
== Series Details ==
Series: Define MOCS table for Icelake (rev2)
URL : https://patchwork.freedesktop.org/series/54070/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
42a8e03cdfa2 drm/i915: initialize unused MOCS entries to PTE
392416ee2864 drm/i915: Simplify MOCS table
Instead of checking the gen number every time we need to know the max
number of entries, just save it into the table struct so we don't need
extra branches throughout the code. This will be useful for Ice Lake
that has 64 rather than 62 defined entries. Ice Lake changes will be
added in a follow
Let's use a macro to make tables smaller and at the same time allow us
to add fields that apply to all entries in future.
For the sake of readability, I'm calling an exception on 80 chars limit.
Lines are aligned for easy comparison of the entry values.
Signed-off-by: Lucas De Marchi
---
Instead of initializing them to uncached, let's set them to PTE for
kernel tracking. While at it do some minor adjustments to comments and
coding style.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_mocs.c | 56 +--
1 file changed, 23 insertions(+),
From: Tomasz Lis
The MOCS tables are going to be very similar across platforms.
To reduce the amount of copied code, this patch rips the common part and
puts it into a definition valid for all gen9 platforms.
v2: Made defines for or-ing flags. Renamed macros from MOCS_TABLE
to
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 never be modified, but new ones can be added. Adding
entries increases table version. The patch includes version
Instead of considering we have defined entries for any index in the
table, let's keep track of the ones we explicitly defined. This will
allow Gen 11 to have it's new table defined in which we have holes of
undefined entries.
Repeated comments about the meaning of undefined entries were removed
This reworks v7 of the series
(https://patchwork.freedesktop.org/series/54070/) to handle the comments
there and some more of my own.
Changes:
- Initialize undefined entries to PTE rather than uncached (suggested
by Chris)
- Add a new macro to define MOCS entries: this allows to make the
Make the defines for LE and L3 caching options to contain the shifts and
remove the zeros from the tables as shifting zeros always result in
zero.
Starting from Ice Lake the MOCS table is defined in the spec and
contains all entries. So to simplify checking the table with the values
set in code,
== Series Details ==
Series: series starting with [01/34] drm/i915/execlists: Mark up priority boost
on preemption
URL : https://patchwork.freedesktop.org/series/55528/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5459_full -> Patchwork_12001_full
== Series Details ==
Series: dma-buf: Enhance dma-fence tracing
URL : https://patchwork.freedesktop.org/series/55531/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5459_full -> Patchwork_12000_full
Summary
---
== Series Details ==
Series: series starting with [01/34] drm/i915/execlists: Mark up priority boost
on preemption
URL : https://patchwork.freedesktop.org/series/55528/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5459 -> Patchwork_12001
== Series Details ==
Series: series starting with [01/34] drm/i915/execlists: Mark up priority boost
on preemption
URL : https://patchwork.freedesktop.org/series/55528/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/execlists: Mark up
== Series Details ==
Series: series starting with [01/34] drm/i915/execlists: Mark up priority boost
on preemption
URL : https://patchwork.freedesktop.org/series/55528/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
096d4f120d3e drm/i915/execlists: Mark up priority boost on
== Series Details ==
Series: dma-buf: Enhance dma-fence tracing
URL : https://patchwork.freedesktop.org/series/55531/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5459 -> Patchwork_12000
Summary
---
**SUCCESS**
== Series Details ==
Series: dma-buf: Enhance dma-fence tracing
URL : https://patchwork.freedesktop.org/series/55531/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e620fc0f05f3 dma-buf: Enhance dma-fence tracing
-:461: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'e' - possible
Replace the open-coding of advance with a call instead.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/mock_engine.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/mock_engine.c
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
---
drivers/gpu/drm/i915/i915_reset.c |
Some tests (e.g. igt_vma_pin1) presume that we have a completely clean
GGTT so that it can probe boundaries without fear that something is
already allocated there. However, the mock device is starting to get
complicated and following similar rules to the live device, i.e. we
can't guarantee that
A repeated pattern is to test the signaled bit of our
request->fence.flags. Make this an inline to shorten a few lines and
remove unnecessary line continuations.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 3 +--
drivers/gpu/drm/i915/i915_request.c | 2 +-
Supplement the per-engine HWSP with a per-timeline HWSP. That is a
per-request pointer through which we can check a local seqno,
abstracting away the presumption of a global seqno. In this first step,
we point each request back into the engine's HWSP so everything
continues to work with the global
Prior to adding a third instance of intel_context_init() and extending
the information stored therewithin, refactor out the common assignments.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c | 7 ++-
drivers/gpu/drm/i915/i915_gem_context.h | 8
Rather than every backend and GPU driver reinventing the same wheel for
user level debugging of HW execution, the common dma-fence framework
should include the tracing infrastructure required for most client API
level flow visualisation.
With these common dma-fence level tracepoints, the
== Series Details ==
Series: series starting with [1/3] drm: Add debug prints for the various object
lookup errors
URL : https://patchwork.freedesktop.org/series/55524/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5459_full -> Patchwork_11999_full
On Mon, Jan 21, 2019 at 4:17 PM Vincent Guittot
wrote:
>
> On Fri, 18 Jan 2019 at 13:08, Guenter Roeck wrote:
> >
> > On 1/18/19 3:05 AM, Rafael J. Wysocki wrote:
> > > On Fri, Jan 18, 2019 at 11:53 AM Vincent Guittot
> > > wrote:
> > >>
> > >> On Fri, 18 Jan 2019 at 11:42, Vincent Guittot
> >
Quoting Chris Wilson (2019-01-21 22:37:13)
> Quoting Chris Wilson (2019-01-21 22:21:13)
> > In preparation for enabling HW semaphores, we need to keep in flight
> > timeline HWSP alive until the entire system is idle, as any other
> > timeline active on the GPU may still refer back to the already
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
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
Quoting Chris Wilson (2019-01-21 22:21:13)
> In preparation for enabling HW semaphores, we need to keep in flight
> timeline HWSP alive until the entire system is idle, as any other
> timeline active on the GPU may still refer back to the already retired
> timeline. We both have to delay recycling
In the next patch, we add another user that wants to check whether
requests can be merge into a single HW execution, and in the future we
want to add more conditions under which requests from the same context
cannot be merge. In preparation, extract out can_merge_rq().
Signed-off-by: Chris Wilson
If we restrict ourselves to only using a cacheline for each timeline's
HWSP (we could go smaller, but want to avoid needless polluting
cachelines on different engines between different contexts), then we can
suballocate a single 4k page into 64 different timeline HWSP. By
treating each fresh
Currently, the list of timelines is serialised by the struct_mutex, but
to alleviate difficulties with using that mutex in future, move the
list management under its own dedicated mutex.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h |
During review of commit 71fc448c1aaf ("drm/i915/selftests: Make evict
tolerant of foreign objects"), Matthew mentioned it would be better if
we explicitly tracked the objects we created. We have an obj->st_link
hook for this purpose, so add the corresponding list of objects and
reduce our loops to
Now that we pin timelines around use, we have a clearly defined lifetime
and convenient points at which we can track only the active timelines.
This allows us to reduce the list iteration to only consider those
active timelines and not all.
Signed-off-by: Chris Wilson
---
To allow requests to forgo a common execution timeline, one question we
need to be able to answer is "is this request running?". To track
whether a request has started on HW, we can emit a breadcrumb at the
beginning of the request and check its timeline's HWSP to see if the
breadcrumb has
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
A starting point to counter the pervasive struct_mutex. For the goal of
avoiding (or at least blocking under them!) global locks during user
request submission, a simple but important step is being able to manage
each clients GTT separately. For which, we want to replace using the
struct_mutex as
Remove the struct_mutex requirement for looking up the vma for an
object.
v2: Highlight how the race for duplicate vma creation is resolved on
reacquiring the lock with a short comment.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 6
To determine whether an engine has 'struck', we simply check whether or
not is still on the same seqno for several seconds. To keep this simple
mechanism intact over the loss of a global seqno, we can simply add a
new global heartbeat seqno instead. As we cannot know the sequence in
which requests
A few years ago, see commit 688e6c725816 ("drm/i915: Slaughter the
thundering i915_wait_request herd"), the issue of handling multiple
clients waiting in parallel was brought to our attention. The
requirement was that every client should be woken immediately upon its
request being signaled,
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/gpu/drm/i915/i915_trace.h | 25
Record the priority boost we giving to the preempted client or else we
may end up in a situation where the priority queue no longer matches the
request priority order and so we can end up in an infinite loop of
preempting the same pair of requests.
Fixes: e9eaf82d97a2 ("drm/i915: Priority boost
Now that we have allocated ourselves a cacheline to store a breadcrumb,
we can emit a write from the GPU into the timeline's HWSP of the
per-context seqno as we complete each request. This drops the mirroring
of the per-engine HWSP and allows each context to operate independently.
We do not need
In preparation for enabling HW semaphores, we need to keep in flight
timeline HWSP alive until the entire system is idle, as any other
timeline active on the GPU may still refer back to the already retired
timeline. We both have to delay recycling available cachelines and
unpinning old HWSP until
We don't want to busywait on the GPU if we have other work to do. If we
give non-busywaiting workloads higher (initial) priority than workloads
that require a busywait, we will prioritise work that is ready to run
immediately.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c
Having introduced per-context seqno, we know have a means to identity
progress across the system without feel of rollback as befell the
global_seqno. That is we can program a MI_SEMAPHORE_WAIT operation in
advance of submission safe in the knowledge that our target seqno and
address is stable.
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
Allocate a page for use as a status page by a group of timelines, as we
only need a dword of storage for each (rounded up to the cacheline for
safety) we can pack multiple timelines into the same page. Each timeline
will then be able to track its own HW seqno.
v2: Reuse the common per-engine HWSP
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 even if we miss an
interrupt for a fence, it
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
Before adding yet another copy of struct live_test and its handler,
refactor the existing code into a common framework for live selftests.
For many live selftests, we want to know if the GPU hung or otherwise
misbehaved during the execution of the test (beyond any infraction in
the behaviour under
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:
I extended the HWSP implementation to consider the impact of using it
for HW semaphores, one of the end goals of per-context seqno. That opens
up an interesting problem in that we need to keep the HWSP around until
all external GPU references to it are retired. For simplicity, this is
until the
Currently we only allocate an object and vma if we are using a GGTT
virtual HWSP, and a plain struct page for a physical HWSP. For
convenience later on with global timelines, it will be useful to always
have the status page being tracked by a struct i915_vma. Make it so.
Signed-off-by: Chris
This turns out to be quite useful if one happens to be debugging
semaphore deadlocks.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_hangcheck.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c
Previously we only accommodated having a vma pinned by a small number of
users, with the maximum being pinned for use by the display engine. As
such, we used a small bitfield only large enough to allow the vma to
be pinned twice (for back/front buffers) in each scanout plane. Keeping
the maximum
Hi Daniel et al.
> >
> > Yeah the drm_crtc_helper.h header is a bit the miniature drmP.h for legacy
> > kms drivers. Just removing it from all the atomic drivers caused lots of
> > fallout, I expect even more if you entirely remove the includes it has.
> > Maybe a todo, care to pls create that
== Series Details ==
Series: drm/i915: Don't use the second dbuf slice on icl
URL : https://patchwork.freedesktop.org/series/55517/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5459_full -> Patchwork_11998_full
Summary
On Tue, 15 Jan 2019 15:47:32 +0100,
Joonas Lahtinen wrote:
>
> 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
== Series Details ==
Series: series starting with [1/3] drm: Add debug prints for the various object
lookup errors
URL : https://patchwork.freedesktop.org/series/55524/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5459 -> Patchwork_11999
== Series Details ==
Series: drm/i915: Refactor out intel_context_init()
URL : https://patchwork.freedesktop.org/series/55516/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5459_full -> Patchwork_11997_full
Summary
---
From: Ville Syrjälä
Logs can get confusing when some operations are done multiple times
due to the ww mutex backoff. Add a debug print into
drm_modeset_backoff() so that at least the reason for the odd
looking logs will be obvious.
Signed-off-by: Ville Syrjälä
---
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
when you can't see where the bad object ID is being used. Add a bunch
more debug prints, and unify their appearance.
Signed-off-by: Ville
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
properties whatsoever. Currenrly these are handled differently
in the atomic and legacy codepaths.
Signed-off-by: Ville Syrjälä
---
On Mon, Jan 21, 2019 at 04:21:34PM +0200, Jani Nikula wrote:
> Clarify that the name is specific to PCH platforms.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_display.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
On Mon, Jan 21, 2019 at 04:21:33PM +0200, Jani Nikula wrote:
> With most platforms not having TV support, only call intel_tv_init() on
> platforms that might actually have TV, specifically gens 3 and 4.
>
> This puts intel_tv_init() more in line with the rest of the outputs, and
> makes it
On Mon, Jan 21, 2019 at 04:21:32PM +0200, Jani Nikula wrote:
> Now that intel_lvds_init() is only called for platforms that might have
> LVDS, move the remaining checks to intel_setup_outputs(), again similar
> to other outputs, and remove the overlapping checks.
>
> Signed-off-by: Jani Nikula
>
On Mon, Jan 21, 2019 at 04:21:31PM +0200, Jani Nikula wrote:
> With new platforms not having LVDS support, only call intel_lvds_init()
> on platforms that might actually have LVDS. Move the comment about eDP
> init to the PCH block where it's relevant.
>
> This puts intel_lvds_init() more in line
On Mon, Jan 21, 2019 at 04:21:30PM +0200, Jani Nikula wrote:
> With new platforms not having CRT support and most conditions in
> intel_crt_present() being specific to DDI, split out the CRT
> initialization to platform specific blocks in the if ladder. Add new
> Pineview block for this.
>
> This
== Series Details ==
Series: series starting with [1/5] drm/i915/crt: split out intel_crt_present()
to platform specific setup
URL : https://patchwork.freedesktop.org/series/55513/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5458_full -> Patchwork_11996_full
== Series Details ==
Series: drm/i915: Don't use the second dbuf slice on icl
URL : https://patchwork.freedesktop.org/series/55517/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5459 -> Patchwork_11998
Summary
---
== Series Details ==
Series: drm/i915: Refactor out intel_context_init()
URL : https://patchwork.freedesktop.org/series/55516/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5459 -> Patchwork_11997
Summary
---
== Series Details ==
Series: drm/i915: Don't use the second dbuf slice on icl
URL : https://patchwork.freedesktop.org/series/55517/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
143de466f689 drm/i915: Don't use the second dbuf slice on icl
-:40: CHECK:CAMELCASE: Avoid
== Series Details ==
Series: drm/dp: use DRM_DEBUG_DP() instead of drm_dbg for logging
URL : https://patchwork.freedesktop.org/series/55509/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5458_full -> Patchwork_11995_full
== Series Details ==
Series: series starting with [1/5] drm/i915/crt: split out intel_crt_present()
to platform specific setup
URL : https://patchwork.freedesktop.org/series/55513/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5458 -> Patchwork_11996
== Series Details ==
Series: drm/i915: Fix dinq debug build
URL : https://patchwork.freedesktop.org/series/55506/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5458_full -> Patchwork_11994_full
Summary
---
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ä
---
drivers/gpu/drm/i915/intel_pm.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff
Hi,
On 21-01-19 15:26, Hans de Goede wrote:
Hi,
On 15-01-19 16:00, Ville Syrjälä wrote:
On Sat, Dec 01, 2018 at 12:31:47PM +0100, Hans de Goede wrote:
On devices with a burst_mode_ratio which is not 100 (1:1), the pclk
will have a different value then drm_display_mode.clock .
On a Prowise
== Series Details ==
Series: drm/i915/gvt: switch to kernel types
URL : https://patchwork.freedesktop.org/series/55503/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5458_full -> Patchwork_11993_full
Summary
---
Prior to adding a third instance of intel_context_init() and extending
the information stored therewithin, refactor out the common assignments.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c | 7 ++-
drivers/gpu/drm/i915/i915_gem_context.h | 8
== Series Details ==
Series: series starting with [1/6] drm/i915/execlists: Mark up priority boost
on preemption
URL : https://patchwork.freedesktop.org/series/55501/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5458_full -> Patchwork_11992_full
On 1/21/19 7:17 AM, Vincent Guittot wrote:
On Fri, 18 Jan 2019 at 13:08, Guenter Roeck wrote:
On 1/18/19 3:05 AM, Rafael J. Wysocki wrote:
On Fri, Jan 18, 2019 at 11:53 AM Vincent Guittot
wrote:
On Fri, 18 Jan 2019 at 11:42, Vincent Guittot
wrote:
Hi Guenter,
Le Thursday 17 Jan 2019 à
On Fri, 18 Jan 2019 at 13:08, Guenter Roeck wrote:
>
> On 1/18/19 3:05 AM, Rafael J. Wysocki wrote:
> > On Fri, Jan 18, 2019 at 11:53 AM Vincent Guittot
> > wrote:
> >>
> >> On Fri, 18 Jan 2019 at 11:42, Vincent Guittot
> >> wrote:
> >>>
> >>> Hi Guenter,
> >>>
> >>> Le Thursday 17 Jan 2019 à
On Mon, Jan 21, 2019 at 01:27:58PM +0200, Jani Nikula wrote:
> We have a wrapper for a reason.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_dp_helper.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git
On Sun, Jan 20, 2019 at 08:45:18PM +0100, Mario Kleiner wrote:
> On Mon, Oct 15, 2018 at 6:21 PM Ville Syrjälä
> wrote:
>
> > On Tue, Jun 12, 2018 at 06:20:35PM +0200, Mario Kleiner wrote:
> > > The various clut handling functions like a setup
> > > consistent with the x-screen color depth.
Hi,
On 08-01-19 17:08, Maarten Lankhorst wrote:
Restore our saved values for backlight. This way even with fastset on
S4 resume we will correctly restore the backlight to the active values.
Changes since v1:
- Call enable_backlight() when backlight.level is set. On suspend
backlight.enabled
Hi,
On 15-01-19 16:00, Ville Syrjälä wrote:
On Sat, Dec 01, 2018 at 12:31:47PM +0100, Hans de Goede wrote:
On devices with a burst_mode_ratio which is not 100 (1:1), the pclk
will have a different value then drm_display_mode.clock .
On a Prowise PT301 tablet where vbt.lfp_lvds_vbt_mode.clock
Now that intel_lvds_init() is only called for platforms that might have
LVDS, move the remaining checks to intel_setup_outputs(), again similar
to other outputs, and remove the overlapping checks.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c | 6 --
With new platforms not having LVDS support, only call intel_lvds_init()
on platforms that might actually have LVDS. Move the comment about eDP
init to the PCH block where it's relevant.
This puts intel_lvds_init() more in line with the rest of the outputs,
and makes it slightly easier for the
Clarify that the name is specific to PCH platforms.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index
With most platforms not having TV support, only call intel_tv_init() on
platforms that might actually have TV, specifically gens 3 and 4.
This puts intel_tv_init() more in line with the rest of the outputs, and
makes it slightly easier for the uninitiated to figure out which
platforms actually
With new platforms not having CRT support and most conditions in
intel_crt_present() being specific to DDI, split out the CRT
initialization to platform specific blocks in the if ladder. Add new
Pineview block for this.
This puts intel_crt_init() more in line with the rest of the outputs,
and
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: 9f58892ea9962002399132fd3f40c6a273f8d9e1
commit: 9f58892ea9962002399132fd3f40c6a273f8d9e1 [2/2] drm/i915: Pull all the
reset functionality together into i915_reset.c
config: i386-randconfig-x007-201903 (attached as
On 15.1.2019 16.47, Joonas Lahtinen wrote:
> 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,
1 - 100 of 127 matches
Mail list logo
