Chris Wilson [Wed, 24 Apr 2019 20:07:17 +0000 (21:07 +0100)]
drm/i915: Invert the GEM wakeref hierarchy
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Chris Wilson [Wed, 24 Apr 2019 20:07:16 +0000 (21:07 +0100)]
drm/i915: Pass intel_context to i915_request_create()
Start acquiring the logical intel_context and using that as our primary
means for request allocation. This is the initial step to allow us to
avoid requiring struct_mutex for request allocation along the
perma-pinned kernel context, but it also provides a foundation for
breaking up the complex request allocation to handle different scenarios
inside execbuf.
For the purpose of emitting a request from inside retirement (see the
next patch for engine power management), we also need to lift control
over the timeline mutex to the caller.
v2: Note that the request carries the active reference upon construction.
Chris Wilson [Wed, 24 Apr 2019 20:07:15 +0000 (21:07 +0100)]
drm/i915: Introduce context->enter() and context->exit()
We wish to start segregating the power management into different control
domains, both with respect to the hardware and the user interface. The
first step is that at the lowest level flow of requests, we want to
process a context event (and not a global GEM operation). In this patch,
we introduce the context callbacks that in future patches will be
redirected to per-engine interfaces leading to global operations as
required.
The intent is that this will be guarded by the timeline->mutex, except
that retiring has not quite finished transitioning over from being
guarded by struct_mutex. So at the moment it is protected by
struct_mutex with a reminded to switch.
v2: Rename default handlers to intel_context_enter_engine.
Chris Wilson [Wed, 24 Apr 2019 20:07:13 +0000 (21:07 +0100)]
drm/i915: Introduce struct intel_wakeref
For controlling runtime pm of the GT and engines, we would like to have
a callback to do extra work the first time we wake up and the last time
we drop the wakeref. This first/last access needs serialisation and so
we encompass a mutex with the regular intel_wakeref_t tracker.
Chris Wilson [Wed, 24 Apr 2019 17:48:39 +0000 (18:48 +0100)]
drm/i915: Move GraphicsTechnology files under gt/
Start partitioning off the code that talks to the hardware (GT) from the
uapi layers and move the device facing code under gt/
One casualty is s/intel_ringbuffer.h/intel_engine.h/ with the plan to
subdivide that header and body further (and split out the submission
code from the ringbuffer and logical context handling). This patch aims
to be simple motion so git can fixup inflight patches with little mess.
Chris Wilson [Wed, 24 Apr 2019 11:09:41 +0000 (12:09 +0100)]
drm/i915/selftests: Verify whitelist of context registers
The RING_NONPRIV allows us to add registers to a whitelist that allows
userspace to modify them. Ideally such registers should be safe and
saved within the context such that they do not impact system behaviour
for other users. This selftest verifies that those registers we do add
are (a) then writable by userspace and (b) only affect a single client.
Opens:
- Is GEN9_SLICE_COMMON_ECO_CHICKEN1 really write-only?
v2: Remove the blatant copy-paste.
v3: Emulate userspace register writes via the batch again.
Chris Wilson [Wed, 24 Apr 2019 09:51:34 +0000 (10:51 +0100)]
drm/i915: Store the default sseu setup on the engine
As we push for better compartmentalisation, it is more convenient to
copy the default sseu configuration from the engine into the derived
logical context, than it is to dig it out from i915->runtime_info.
v2: Use intel_sseu_from_device_info() to describe the converter
drm/i915/icl: Fix clockgating issue when using scalers
Fixes the clock-gating issue when pipe scaling is enabled.
(Lineage #2006604312)
V2: Fix typo in headline(Chris)
Handle the non double buffered nature of the register(Ville)
V3: Fix checkpatch warning. BAT failure for V2 on gen3 looks unrelated.
V4: Split the icl and skl wa's(Ville)
V5: Split the checks for icl and skl(Ville)
V6: Correct the flipped checks in intel_pre_plane_update(Ville)
V7: Use enum for pipe and extend the WA for plane scalers(Ville)
V8: Eliminate the redundant use of pch_pfit(Ville)
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190417185901.14833-1-radhakrishna.sripada@intel.com
Ville Syrjälä [Thu, 18 Apr 2019 19:59:07 +0000 (22:59 +0300)]
drm/i915: Fix skl+ max plane width
The spec has changed since skl_max_plane_width() was written.
Now the SKL limits are lower than what they were initially, and
GLK and ICL have different limits. Update the code to match the
spec.
Fix the order of lane, port parameters passed to the register macro.
Note that this was already partly fixed by commit a7f35b24448fb ("drm/i915: Call MG_DP_MODE() macro with the right parameters order")
While at it simplify things by using the macro directly instead of an
unnecessary redirection via an array.
v2:
- Add a note the commit message about simplifying things. (José)
Fixes: e4573596466f0 ("drm/i915: Make MG PHY macros semantically consistent") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190419071026.32370-1-imre.deak@intel.com
Chris Wilson [Sat, 20 Apr 2019 11:55:39 +0000 (12:55 +0100)]
drm/i915: Start writeback from the shrinker
When we are called to relieve mempressue via the shrinker, the only way
we can make progress is either by discarding unwanted pages (those
objects that userspace has marked MADV_DONTNEED) or by reclaiming the
dirty objects via swap. As we know that is the only way to make further
progress, we can initiate the writeback as we invalidate the objects.
This means the objects we put onto the inactive anon lru list are
already marked for reclaim+writeback and so will trigger a wait upon the
writeback inside direct reclaim, greatly improving the success rate of
direct reclaim on i915 objects.
The corollary is that we may start a slow swap on opportunistic
mempressure from the likes of the compaction + migration kthreads. This
is limited by those threads only being allowed to shrink idle pages, but
also that if we reactivate the page before it is swapped out by gpu
activity, we only page the cost of repinning the page. The cost is most
felt when an object is reused after mempressure, which hopefully
excludes the latency sensitive tasks (as we are just extending the
impact of swap thrashing to them).
Apparently this is not the first time we've had this idea. Back in
commit 50a57f3f13ef ("drm/i915: Invalidate our pages under memory
pressure") we wanted to start writeback but settled on invalidate after
Hugh Dickins warned us about a possibility of a deadlock within shmemfs
if we started writeback from shrink_slab. Looking at the callchain,
using writeback from i915_gem_shrink should be equivalent to the pageout
also employed by shrink_slab, i.e. it should not be any riskier afaict.
v2: Leave mmapings intact. At this point, the only mmapings of our
objects will be via CPU mmaps on the shmemfs filp, which are
out-of-scope for our LRU tracking. Instead leave those pages to the
inactive anon LRU page list for aging and pageout as normal.
v3: Be selective on which paths trigger writeback, in particular
excluding paths shrinking just to reclaim vm space (e.g. mmap, vmap
reapers) and avoid starting writeback on the entire process space from
within the pm freezer.
References: https://bugs.freedesktop.org/show_bug.cgi?id=108686 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Michal Hocko <mhocko@suse.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20190420115539.29081-1-chris@chris-wilson.co.uk
Fernando Pacheco [Fri, 19 Apr 2019 23:00:13 +0000 (16:00 -0700)]
drm/i915/uc: Place uC firmware in upper range of GGTT
Currently we pin the GuC or HuC firmware image just before uploading.
Perma-pin during uC initialization instead and use the range reserved at
the top of the address space.
Moving the firmware resulted in needing to:
- use an additional pinning for the rsa signature which will be used
during HuC auth as addresses above GUC_GGTT_TOP do not map through GTT.
v2: Remove call to set to gtt domain
Do not restore fw gtt mapping unconditionally
Separate out pin/unpin functions and drop usage of pin/unpin
Use uc_fw init/fini functions to bind/unbind fw object
v3: Bind is only needed during xfer (Chris)
Remove attempts to bind outside of xfer (Chris)
Mark fw bind/unbind static
Fernando Pacheco [Fri, 19 Apr 2019 23:00:12 +0000 (16:00 -0700)]
drm/i915/uc: Reserve upper range of GGTT
GuC and HuC depend on struct_mutex for device reinitialization. Moving
away from this dependency requires perma-pinning the firmware images in
GGTT. The upper portion of the GuC address space has a sizeable hole
(several MB) that is inaccessible by GuC. Reserve this range within GGTT
as it can comfortably hold GuC/HuC firmware images.
v2: Reserve node rather than insert (Chris)
Simpler determination of node start/size (Daniele)
Move reserve/release out to intel_guc.* files
v3: Reserve starting at GUC_GGTT_TOP only and bail if this
fails (Chris)
Chris Wilson [Fri, 19 Apr 2019 20:12:07 +0000 (21:12 +0100)]
drm/i915/gtt: Skip clearing the GGTT under gen6+ full-ppgtt
If we know that the user cannot access the GGTT, by virtue of having a
segregated memory area, we can skip clearing the unused entries as they
cannot be accessed.
Chris Wilson [Fri, 19 Apr 2019 18:26:25 +0000 (19:26 +0100)]
drm/i915: Expose the busyspin durations for i915_wait_request
An interesting discussion regarding "hybrid interrupt polling" for NVMe
came to the conclusion that the ideal busyspin before sleeping was half
of the expected request latency (and better if it was already halfway
through that request). This suggested that we too should look again at
our tradeoff between spinning and waiting. Currently, our spin simply
tries to hide the cost of enabling the interrupt, which is good to avoid
penalising nop requests (i.e. test throughput) and not much else.
Studying real world workloads suggests that a spin of upto 500us can
dramatically boost performance, but the suggestion is that this is not
from avoiding interrupt latency per-se, but from secondary effects of
sleeping such as allowing the CPU reduce cstate and context switch away.
In a truly hybrid interrupt polling scheme, we would aim to sleep until
just before the request completed and then wake up in advance of the
interrupt and do a quick poll to handle completion. This is tricky for
ourselves at the moment as we are not recording request times, and since
we allow preemption, our requests are not on as a nicely ordered
timeline as IO. However, the idea is interesting, for it will certainly
help us decide when busyspinning is worthwhile.
v2: Expose the spin setting via Kconfig options for easier adjustment
and testing.
v3: Don't get caught sneaking in a change to the busyspin parameters.
v4: Explain more about the "hybrid interrupt polling" scheme that we
want to migrate towards.
Suggested-by: Sagar Kamble <sagar.a.kamble@intel.com>
References: http://events.linuxfoundation.org/sites/events/files/slides/lemoal-nvme-polling-vault-2017-final_0.pdf Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sagar Kamble <sagar.a.kamble@intel.com> Cc: Eero Tamminen <eero.t.tamminen@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Sagar Kamble <sagar.a.kamble@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190419182625.11186-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 19 Apr 2019 13:48:36 +0000 (14:48 +0100)]
drm/i915: Track HAS_RPS alongside HAS_RC6 in the device info
For consistency (and elegance!), add intel_device_info.has_rps.
The immediate boon is that RPS support is now emitted along the other
capabilities in the debug log and after errors.
The driver does not currently support unbinding from a device which is
in use. Since open file descriptors may still be pointing into kernel
memory where the device structures used to be, entirely correct kernel
panics protect the driver from being unbound as we should not be
unbinding it before those dangling pointers have been made safe.
According to the documentation found inside drivers/gpu/drm/drm_drv.c,
drm_dev_unplug() should be used instead of drm_dev_unregister() in
order to make a device inaccessible to users as soon as it is unpluged.
Follow that advice to make those possibly dangling pointers safe,
protected by DRM layer from a user who is otherwise left pointing into
possibly reused kernel memory after the driver has been unbound from
the device. Once done, also cancel inflight operations immediately by
calling i915_gem_set_wedged().
Chris Wilson [Thu, 18 Apr 2019 13:27:19 +0000 (14:27 +0100)]
drm/i915: Stop overwriting RING_IMR in rcs resume
We store the engine->imr mask and set up the RING_IMR register on
restarting the engine. We do not then want to overwrite it with
an incomplete mask later as we may then lose interrupts!
Chris Wilson [Wed, 17 Apr 2019 13:25:07 +0000 (14:25 +0100)]
drm/i915: Avoid use-after-free in reporting create.size
We have to avoid chasing after a userspace race!
<3>[ 473.114328] BUG: KASAN: use-after-free in i915_gem_create+0x1d2/0x1f0 [i915]
<3>[ 473.114389] Read of size 8 at addr ffff88815bf1d840 by task gem_flink_race/1541
Testcase: igt/gem_flink_race/flink_close Fixes: 6f34054cc25e ("drm/i915: Update size upon return from GEM_CREATE") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190417132507.27133-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 17 Apr 2019 07:56:28 +0000 (08:56 +0100)]
drm/i915: Verify the engine workarounds stick on application
Read the engine workarounds back using the GPU after loading the initial
context state to verify that we are setting them correctly, and bail if
it fails.
Jani Nikula [Tue, 16 Apr 2019 08:28:52 +0000 (11:28 +0300)]
drm/i915/ehl: inherit icl cdclk init/uninit
The cdclk init/uninit code was changed by commit 68137a972033
("drm/i915/cdclk: have only one init/uninit function") between the
versions of commit 39d4d654617f ("drm/i915/ehl: Inherit Ice Lake
conditional code"). What got merged fails to do cdclk init/uninit on
ehl.
Fixes: 39d4d654617f ("drm/i915/ehl: Inherit Ice Lake conditional code") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190416082852.18141-1-jani.nikula@intel.com
Chris Wilson [Fri, 12 Apr 2019 07:14:16 +0000 (08:14 +0100)]
drm/i915: Introduce struct class_instance for engines across the uAPI
SSEU reprogramming of the context introduced the notion of engine class
and instance for a forwards compatible method of describing any engine
beyond the old execbuf interface. We wish to adopt this class:instance
description for more interfaces, so pull it out into a separate type for
userspace convenience.
Fixes: fa72cd326a0a ("drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com> Cc: Tony Ye <tony.ye@intel.com> Cc: Andi Shyti <andi@etezian.org> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by: Tony Ye <tony.ye@intel.com> Reviewed-by: Andi Shyti <andi@etezian.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190412071416.30097-1-chris@chris-wilson.co.uk
Paulo Zanoni [Wed, 10 Apr 2019 23:53:44 +0000 (16:53 -0700)]
drm/i915: fully convert the IRQ initialization macros to intel_uncore
Make them take the uncore argument from the caller instead of passing
the implicit &dev_priv->uncore directly. This will allow us to finally
pass something that's not dev_priv->uncore in the future, and gets rid
of the implicit variables in register macros.
Paulo Zanoni [Wed, 10 Apr 2019 23:53:43 +0000 (16:53 -0700)]
drm/i915: convert the IRQ initialization functions to intel_uncore
The IRQ initialization helpers are simple and self-contained. Continue
the transition started in the recent uncore rework to get us rid of
I915_READ/WRITE and the implicit dev_priv variables.
While the implicit dev_priv is removed from the IRQ initialization
helpers, we didn't get rid of them in the macro callers. Doing that
should be very simple now.
Paulo Zanoni [Wed, 10 Apr 2019 23:53:42 +0000 (16:53 -0700)]
drm/i915: add GEN2_ prefix to the I{E, I, M, S}R registers
This discussion started because we use token pasting in the
GEN{2,3}_IRQ_INIT and GEN{2,3}_IRQ_RESET macros, so gen2-4 passes an
empty argument to those macros, making the code a little weird. The
original proposal was to just add a comment as the empty argument, but
Ville suggested we just add a prefix to the registers, and that indeed
sounds like a more elegant solution.
Now doing this is kinda against our rules for register naming since we
only add gens or platform names as register prefixes when the given
gen/platform changes a register that already existed before. On the
other hand, we have so many instances of IIR/IMR in comments that
adding a prefix would make the users of these register more easily
findable, in addition to make our token pasting macros actually
readable. So IMHO opening an exception here is worth it.
Paulo Zanoni [Wed, 10 Apr 2019 23:53:41 +0000 (16:53 -0700)]
drm/i915: don't specify the IRQ register in the gen2 macros
Like the gen3+ macros, the gen2 versions of the IRQ initialization
macros take the register name in the 'type' argument. But gen2 only
has one set of registers, so there's really no need to specify the
type. This commit removes the type argument and uses the registers
directly instead of passing them through variables.
Paulo Zanoni [Wed, 10 Apr 2019 23:53:40 +0000 (16:53 -0700)]
drm/i915: refactor the IRQ init/reset macros
The whole point of having macros here is for the token pasting
necessary to automatically have IMR, IIR and IER selected. We don't
really need or want all the inlining that happens as a consequence.
The good thing about the current code is that it works regardless of
the relative offsets between these registers (they change after gen4,
with the usual VLV/CHV exceptions).
One thing which we can do is to split the logic of what we do with
imr/ier/iir to functions separate from the macros that pick them.
That's what we do in this commit. This allows us to get rid of the
gen8 duplicates and also all the inlining:
v2:
- Make checkpatch happy with a temporary which_ (Checkpatch).
- Reorder the arguments for the INIT macros (Ville).
- Correctly explain when the register offsets change in the commit
message (Ville).
- Use more line breaks in the macro calls to make the arguments look
a little more organized/readable.
- Update the bloat-o-meter output (minor change only).
Chris Wilson [Tue, 16 Apr 2019 08:52:18 +0000 (09:52 +0100)]
drm/i915: Drop bool return from breadcrumbs signaler
Since removal of the "missed interrupt detection" nobody used the result
of whether or not we signaled anybody during that invocation, so now
remove the return value.
drm/i915/gvt: addressed guest GPU hang with HWS index mode
with the introduce of "switch to use HWS indices rather than address",
guest GPU hang observed when running workloads which will update the
seqno to the real HW HWSP, not vitural GPU HWSP and then cause GPU hang.
this patch is to revoke index mode in PIPE_CTRL and MI_FLUSH_DW and
patch guest GPU HWSP address value to these commands.
Fixes: e2f46c32f876 ("drm/i915: Switch to use HWS indices rather than addresses") Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Xiaolin Zhang <xiaolin.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Zhenyu Wang [Tue, 16 Apr 2019 08:50:34 +0000 (16:50 +0800)]
Merge tag 'drm-intel-next-2019-04-04' into gvt-next
Merge back drm-intel-next for engine name definition refinement
and e2f46c32f876 ("drm/i915: Switch to use HWS indices rather than addresses")
that would need gvt fixes to depend on.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
drm/i915: Nuke drm_crtc_state and use intel_atomic_state instead
This is one of the patches to start replacing drm pointers
and use the intel_atomic_state and intel_crtc to derive
the necessary intel state variables required for the intel
modeset functions.
v3:
* Remove the unwanted newline (Ville)
v2:
* Flip the function arguments (Ville)
* Remove some remaining instances of drm pointers (Ville)
* Use old_crtc_state and new_crtc_state (Ville)
Chris Wilson [Sat, 13 Apr 2019 12:58:20 +0000 (13:58 +0100)]
drm/i915/selftests: Skip live timeline/suspend tests if wedged
If the driver is wedged, we can not issue the requests to exercise the
timelines or the system across suspend, so skip the tests. live_hangcheck
is there to fail if we cannot recover.
Bob Paauwe [Fri, 12 Apr 2019 18:09:20 +0000 (11:09 -0700)]
drm/i915/ehl: Inherit Ice Lake conditional code
Most of the conditional code for ICELAKE also applies to ELKHARTLAKE
so use IS_GEN(dev_priv, 11) even for PM and Workarounds for now.
v2: - Rename commit (Jose)
- Include a wm workaround (Jose and Lucas)
- Include display core init (Jose and Lucas)
v3: Add a missing case of gen greater-than 11 (Jose)
Mika Kuoppala [Fri, 12 Apr 2019 16:53:53 +0000 (19:53 +0300)]
drm/i915: Handle catastrophic error on engine reset
If cat error is set, we need to clear it by acking it. Further,
if it is set, we must not do a normal request for reset.
v2: avoid goto (Chris)
v3: comment, error format, direct assign (Chris)
Bspec: 12567 Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190412165353.16432-1-mika.kuoppala@linux.intel.com
We are no longer calling bxt_ddi_phy_calc_lane_lat_optim_mask() when
intel{hdmi,dp}_compute_config() succeeds, and instead only call it
when those fail. This is fallout from the bool->int
.compute_config() conversion which failed to invert the return
value check before calling bxt_ddi_phy_calc_lane_lat_optim_mask().
Let's just replace it with an early bailout so that it's harder
to miss.
This restores the correct latency optim setting calculation
(which could fix some real failures), and avoids the
MISSING_CASE() from bxt_ddi_phy_calc_lane_lat_optim_mask()
after intel{hdmi,dp}_compute_config() has failed.
Chris Wilson [Fri, 12 Apr 2019 11:01:59 +0000 (12:01 +0100)]
drm/i915: Flush the CSB pointer reset
The HW resets it CSB tail pointer on resetting the engine. Most of the
time. In case it doesn't (and for system resume) we write the expected
value anyway. For extra paranoia, flush the write before we invalidate
the cacheline.
Ville Syrjälä [Tue, 26 Mar 2019 14:49:02 +0000 (16:49 +0200)]
drm/i915: Do not enable FEC without DSC
Currently we enable FEC even when DSC is no used. While that is
theoretically valid supposedly there isn't much of a benefit from
this. But more importantly we do not account for the FEC link
bandwidth overhead (2.4%) in the non-DSC link bandwidth computations.
So the code may think we have enough bandwidth when we in fact
do not.
Cc: stable@vger.kernel.org Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Fixes: 84f52734d068 ("i915/dp/fec: Add fec_enable to the crtc state.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190326144903.6617-1-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Chris Wilson [Tue, 9 Apr 2019 17:41:08 +0000 (18:41 +0100)]
drm/i915: Avoid reclaim taints from runtime-pm debug
As intel_runtime_pm_get/_put may be called from any blockable context,
we need to avoid allowing reclaim from our mallocs, as we need to
avoid tainting any mutexes held by the callers (as they may themselves
not allow for allocations as they are taken in the shrinker).
<4> [435.339331] WARNING: possible circular locking dependency detected
<4> [435.339364] 5.1.0-rc4-CI-Trybot_4116+ #1 Tainted: G U
<4> [435.339395] ------------------------------------------------------
<4> [435.339426] gem_caching/1334 is trying to acquire lock:
<4> [435.339456] 000000004505c39b (wakeref#3){+.+.}, at: intel_engine_pm_put+0x1b/0x40 [i915]
<4> [435.339788]
but task is already holding lock:
<4> [435.339819] 00000000ee77b4ed (fs_reclaim){+.+.}, at: fs_reclaim_acquire.part.24+0x0/0x30
<4> [435.339879]
which lock already depends on the new lock.
Chris Wilson [Thu, 11 Apr 2019 13:05:15 +0000 (14:05 +0100)]
drm/i915/execlists: Always reset the context's RING registers
During reset, we try and stop the active ring. This has the consequence
that we often clobber the RING registers within the context image. When
we find an active request, we update the context image to rerun that
request (if it was guilty, we replace the hanging user payload with
NOPs). However, we were ignoring an active context if the request had
completed, with the consequence that the next submission on that request
would start with RING_HEAD==0 and not the tail of the previous request,
causing all requests still in the ring to be rerun. Rare, but
occasionally seen within CI where we would spot that the context seqno
would reverse and complain that we were retiring an incomplete request.
Chris Wilson [Thu, 11 Apr 2019 13:05:14 +0000 (14:05 +0100)]
drm/i915/guc: Implement reset locally
Before causing guc and execlists to diverge further (breaking guc in the
process), take a copy of the current reset procedure and make it local to
the guc submission backend
Mika Kuoppala [Thu, 11 Apr 2019 08:30:34 +0000 (11:30 +0300)]
drm/i915: Disable read only ppgtt support for gen11
On gen11 writing to read only ppgtt page causes a gpu hang.
This behaviour is different than with previous gen where
read only ppgtt access is supported. On those, the write
is just dropped without visible side effects.
Disable ro ppgtt support on gen11 until a solution can
be found to bring it into line with its predecessors.
Chris Wilson [Thu, 11 Apr 2019 12:24:45 +0000 (13:24 +0100)]
drm/i915: Call i915_sw_fence_fini on request cleanup
As i915_requests are put into an RCU-freelist, they may get reused
before debugobjects notice them as being freed. On cleanup, explicitly
call i915_sw_fence_fini() so that the debugobject is properly tracked.
Reported-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Fixes: c6b7bcbe100a ("drm/i915: Bump ready tasks ahead of busywaits") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190411122445.20060-1-chris@chris-wilson.co.uk
Mika Kuoppala [Fri, 5 Apr 2019 20:46:57 +0000 (21:46 +0100)]
drm/i915/icl: Switch to using 12 deep CSB status FIFO
Now when we can support variable csb fifo sizes, disable legacy mode.
By disabling legacy we hope to get better hw testing coverage by
assuming everyone else have switched over.
v2: rebase
References: https://bugs.freedesktop.org/show_bug.cgi?id=110338 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Kelvin Gardiner <kelvin.gardiner@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190405204657.12887-2-chris@chris-wilson.co.uk
Mika Kuoppala [Fri, 5 Apr 2019 20:46:56 +0000 (21:46 +0100)]
drm/i915: Prepare for larger CSB status FIFO size
Make csb entry count variable in preparation for larger
CSB status FIFO size found on gen11+ hardware.
v2: adapt to hwsp access only (Chris)
non continuous mmio (Daniele)
v3: entries (Chris), fix macro for checkpatch
v4: num_entries (Chris)
v5: consistency on num_entries
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190405204657.12887-1-chris@chris-wilson.co.uk
Mika Kuoppala [Wed, 10 Apr 2019 10:59:22 +0000 (13:59 +0300)]
drm/i915: Use Engine1 instance for gen11 pm interrupts
With gen11 the interrupt registers are shared between 2 engines,
with Engine1 instance being upper word and Engine0 instance being
lower. Annoyingly gen11 selected the pm interrupts to be in the
Engine1 instance.
Rectify the situation by shifting the access accordingly,
based on gen.
v2: comments, warn on overzealous rps_events
Bugzilla: https://bugzilla.freedesktop.org/show_bug.cgi?id=108059
Testcase: igt/i915_pm_rps@min-max-config-loaded Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190410105923.18546-6-mika.kuoppala@linux.intel.com
Mika Kuoppala [Wed, 10 Apr 2019 10:59:18 +0000 (13:59 +0300)]
drm/i915/icl: Apply a recommended rc6 threshold
On gen11 the recommended rc6 threshold differs from previous
gens, apply it. Move the write to a correct spot in sequence.
v2: do write in 2b, fix bspec ref (Michal)
Bspec: 33149 Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190410105923.18546-2-mika.kuoppala@linux.intel.com
Chris Wilson [Tue, 9 Apr 2019 15:29:22 +0000 (16:29 +0100)]
drm/i915: Bump ready tasks ahead of busywaits
Consider two tasks that are running in parallel on a pair of engines
(vcs0, vcs1), but then must complete on a shared engine (rcs0). To
maximise throughput, we want to run the first ready task on rcs0 (i.e.
the first task that completes on either of vcs0 or vcs1). When using
semaphores, however, we will instead queue onto rcs in submission order.
To resolve this incorrect ordering, we want to re-evaluate the priority
queue when each of the request is ready. Normally this happens because
we only insert into the priority queue requests that are ready, but with
semaphores we are inserting ahead of their readiness and to compensate
we penalize those tasks with reduced priority (so that tasks that do not
need to busywait should naturally be run first). However, given a series
of tasks that each use semaphores, the queue degrades into submission
fifo rather than readiness fifo, and so to counter this we give a small
boost to semaphore users as their dependent tasks are completed (and so
we no longer require any busywait prior to running the user task as they
are then ready themselves).
Chris Wilson [Wed, 10 Apr 2019 19:01:20 +0000 (20:01 +0100)]
drm/i915: Only reset the pinned kernel contexts on resume
On resume, we know that the only pinned contexts in danger of seeing
corruption are the kernel context, and so we do not need to walk the
list of all GEM contexts as we tracked them on each engine.
drm/i915/dp: Expose force_dsc_enable through debugfs
Currently we use force_dsc_enable to force DSC from IGT, but
we dont expose this value to userspace through debugfs.
This patch exposes this through the same dsc_fec_support
debugfs node per connector so that we can restore its value
back after the tests are completed.
Mika Kuoppala [Wed, 10 Apr 2019 13:21:24 +0000 (16:21 +0300)]
drm/i915/icl: Don't warn on spurious interrupts
There is a chance we can see spurious interrupts in live
now. We have more engines enabled and that with more elaborate
access patterns with pm and display, increases the chances
hardware just makes a social call, without anything to work on.
Remove the error as we have tests to actually probe if
we really miss interrupt, instead of getting spurious ones.
Note that now we do write to intr_dw even with a zero
value. This is considered advantegous as the write
is an ack that sw is done.
snd_hdac_display_power() doesn't handle the concurrent calls carefully
enough, and it may lead to the doubly get_power or put_power calls,
when a runtime PM and an async work get called in racy way.
This patch addresses it by reusing the bus->lock mutex that has been
used for protecting the link state change in ext bus code, so that it
can protect against racy display state changes. The initialization of
bus->lock was moved from snd_hdac_ext_bus_init() to
snd_hdac_bus_init() as well accordingly.
Testcase: igt/i915_pm_rpm/module-reload #glk-dsi Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/s5h8swiunph.wl-tiwai@suse.de
Jani Nikula [Fri, 5 Apr 2019 07:52:20 +0000 (10:52 +0300)]
drm/i915/dp: revert back to max link rate and lane count on eDP
Commit 58065fd671e9 ("drm/i915/dp: optimize eDP 1.4+ link config fast
and narrow") started to optize the eDP 1.4+ link config, both per spec
and as preparation for display stream compression support.
Sadly, we again face panels that flat out fail with parameters they
claim to support. Revert, and go back to the drawing board.
v2: Actually revert to max params instead of just wide-and-slow.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109959 Fixes: 58065fd671e9 ("drm/i915/dp: optimize eDP 1.4+ link config fast and narrow") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matt Atwood <matthew.s.atwood@intel.com> Cc: "Lee, Shawn C" <shawn.c.lee@intel.com> Cc: Dave Airlie <airlied@gmail.com> Cc: intel-gfx@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v5.0+ Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Tested-by: Albert Astals Cid <aacid@kde.org> # v5.0 backport Tested-by: Emanuele Panigati <ilpanich@gmail.com> # v5.0 backport Tested-by: Matteo Iervasi <matteoiervasi@gmail.com> # v5.0 backport Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190405075220.9815-1-jani.nikula@intel.com
Chris Wilson [Mon, 8 Apr 2019 09:17:14 +0000 (10:17 +0100)]
drm/i915/guc: Replace preempt_client lookup with engine->preempt_context
Circumvent the dance we currently perform to find the preempt_client and
lookup its HW context for this engine, as we know we have already pinned
the preempt_context on the engine.
Chris Wilson [Sun, 7 Apr 2019 19:26:49 +0000 (20:26 +0100)]
drm/i915/selftests: Mark live_forcewake_ops as unreliable
A couple of machines in the farm show quite frequent errors in the
powerwells not being released. Either there is an external agent
interferring with the powerwells, or the powerwell doesn't quite behave
as we anticipate -- either way, the test is not reliable enough to be
enabled by default in CI. It has served its immediate purpose in
providing coverage as we made tweaks to forcewake, so keep it available
for future testing.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110210 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190407192649.14750-1-chris@chris-wilson.co.uk
drm/i915/psr: Initialize PSR mutex even when sink is not reliable
Even when driver is reloaded and hits this scenario the PSR mutex
should be initialized, otherwise reading PSR debugfs status will
execute mutex_lock() over a mutex that was not initialized.
PSR support for VLV and CHV was dropped in commit ee7918660bba
("drm/i915/psr: Nuke PSR support for VLV and CHV") so no need to keep
this registers around.
drm/i915/psr: Update PSR2 SU corruption workaround comment
Turn out it is not a DMC bug it is actually a HW one, so this
workaround will be needed for current gens, lets update the comment
and remove the FIXME.
Chris Wilson [Mon, 8 Apr 2019 09:17:03 +0000 (10:17 +0100)]
drm/i915: Consolidate the timeline->barrier
The timeline is strictly ordered, so by inserting the timeline->barrier
request into the timeline->last_request it naturally provides the same
barrier. Consolidate the pair of barriers into one as they serve the
same purpose.
Chris Wilson [Mon, 8 Apr 2019 09:17:02 +0000 (10:17 +0100)]
drm/i915: Use static allocation for i915_globals_park()
In order to avoid the malloc inside i915_globals_park() occurring
underneath a lock connected to the shrinker (thus causing circular
lockdeps warnings), move the rcu_worker to a global.
<4> [39.085073] ======================================================
<4> [39.085273] WARNING: possible circular locking dependency detected
<4> [39.085552] 5.1.0-rc3-CI-Trybot_4088+ #1 Tainted: G U
<4> [39.085752] ------------------------------------------------------
<4> [39.085949] kswapd0/32 is trying to acquire lock:
<4> [39.086121] 00000000004b5f91 (wakeref#3){+.+.}, at: intel_engine_pm_put+0x1b/0x40 [i915]
<4> [39.086493]
but task is already holding lock:
<4> [39.086682] 00000000dd009a9a (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x30
<4> [39.086910]
which lock already depends on the new lock.
Imre Deak [Fri, 5 Apr 2019 15:36:57 +0000 (18:36 +0300)]
drm/i915/icl: Simplify release of encoder power refs
We can unconditionally release the power references during encoder
disabling. The references for each port used by the encoder are
guaranteed to be enabled at this point.
Imre Deak [Sun, 7 Apr 2019 12:46:55 +0000 (15:46 +0300)]
drm/i915: Get power refs in encoder->get_power_domains()
Push getting the reference for the encoders' power domains into the
encoder get_power_domains() hook instead of doing this from the caller.
This way the encoder can store away the corresponding wakerefs.
This fixes the DSI encoder disabling, which didn't release these
power references it acquired during HW state readout.
Note that longtime ownership for the corresponding wakerefs can be thus
acquired / released in two ways. Nevertheless there is always only one
owner for them:
After a modeset (calling intel_atomic_commit()):
- encoder->enable*() acquires
- encoder->disable*() releases
* can be any of the encoder enable/disable hooks.
v2:
- Check that the DSI io_wakerefs are unset both during encoder HW
readout and enabling. (Chris)
Fixes: 9d37c8e612b47 ("drm/i915: Markup paired operations on display power domains") Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190407124655.31536-1-imre.deak@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:26 +0000 (14:00 +0300)]
drm/i915/cdclk: have only one init/uninit function
While transitioning to having better clarity between the modules, it's
desirable to have the function name prefixes reflect the
module. Functions in intel_foo.c should be prefixed intel_foo_.
Expose only one CDCLK init/uninit function from intel_cdclk.c instead of
one per platform. Obviously this adds one "unnecessary" if ladder within
the entry points. However it should be considered more of a CDCLK
implementation detail how this is done per platform, instead of exposing
the fact. In other words, abstract the CDCLK module better.
Jani Nikula [Fri, 5 Apr 2019 11:00:25 +0000 (14:00 +0300)]
drm/i915: extract intel_cdclk.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
Jani Nikula [Fri, 5 Apr 2019 11:00:24 +0000 (14:00 +0300)]
drm/i915: extract intel_sprite.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
Jani Nikula [Fri, 5 Apr 2019 11:00:23 +0000 (14:00 +0300)]
drm/i915: extract intel_dvo.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
Jani Nikula [Fri, 5 Apr 2019 11:00:22 +0000 (14:00 +0300)]
drm/i915: extract intel_lvds.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
Jani Nikula [Fri, 5 Apr 2019 11:00:21 +0000 (14:00 +0300)]
drm/i915: extract intel_tv.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
Jani Nikula [Fri, 5 Apr 2019 11:00:20 +0000 (14:00 +0300)]
drm/i915: extract intel_pipe_crc.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
Jani Nikula [Fri, 5 Apr 2019 11:00:19 +0000 (14:00 +0300)]
drm/i915: extract intel_atomic_plane.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
v2: revert intel_plane_destroy_state() movement within intel_atomic_plane.c
Jani Nikula [Fri, 5 Apr 2019 11:00:18 +0000 (14:00 +0300)]
drm/i915: extract intel_hdmi.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
Jani Nikula [Fri, 5 Apr 2019 11:00:17 +0000 (14:00 +0300)]
drm/i915: extract intel_dp.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
Jani Nikula [Fri, 5 Apr 2019 11:00:16 +0000 (14:00 +0300)]
drm/i915: extract intel_fbdev.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
projects / kernel.git / log