Jani Nikula [Mon, 29 Apr 2019 12:29:38 +0000 (15:29 +0300)]
drm/i915: extract intel_combo_phy.h from i915_drv.h
It used to be handy that we only had a couple of headers, but over time
i915_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 [Mon, 29 Apr 2019 12:29:36 +0000 (15:29 +0300)]
drm/i915: extract intel_runtime_pm.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 [Mon, 29 Apr 2019 12:53:31 +0000 (15:53 +0300)]
drm/i915: extract intel_atomic.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: fix sparse warnings on undeclared global functions
Jani Nikula [Mon, 29 Apr 2019 12:29:34 +0000 (15:29 +0300)]
drm/i915: extract intel_dsi_dcs_backlight.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 [Mon, 29 Apr 2019 12:29:33 +0000 (15:29 +0300)]
drm/i915: extract intel_dp_mst.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 [Mon, 29 Apr 2019 12:29:32 +0000 (15:29 +0300)]
drm/i915: extract intel_vdsc.h from intel_drv.h and i915_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 [Mon, 29 Apr 2019 12:29:31 +0000 (15:29 +0300)]
drm/i915: extract intel_overlay.h from intel_drv.h and i915_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 [Mon, 29 Apr 2019 12:29:30 +0000 (15:29 +0300)]
drm/i915: extract intel_quirks.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 [Mon, 29 Apr 2019 12:29:29 +0000 (15:29 +0300)]
drm/i915: extract intel_bios.h functions from i915_drv.h
It used to be handy that we only had a couple of headers, but over time
i915_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 header remains self-contained, and do so with minimal further
includes, using forward declarations as needed.
Jani Nikula [Mon, 29 Apr 2019 12:50:11 +0000 (15:50 +0300)]
drm/i915: extract intel_hotplug.h from intel_drv.h and i915_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: fix sparse warnings on undeclared global functions
Jani Nikula [Mon, 29 Apr 2019 12:29:27 +0000 (15:29 +0300)]
drm/i915: extract i915_irq.h from intel_drv.h and i915_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 [Mon, 29 Apr 2019 12:29:26 +0000 (15:29 +0300)]
drm/i915: extract intel_dp_aux_backlight.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 [Mon, 29 Apr 2019 12:29:25 +0000 (15:29 +0300)]
drm/i915: extract intel_dp_link_training.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 [Mon, 29 Apr 2019 12:29:24 +0000 (15:29 +0300)]
drm/i915: extract intel_fifo_underrun.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.
Lucas De Marchi [Thu, 4 Apr 2019 23:04:26 +0000 (16:04 -0700)]
drm/i915: do not mix workaround with normal flow
Separate the two comments: one is a workaround and the other is a sanity
check. We could just compare != 1, but let's treat them differently due
to having different meaning.
Chris Wilson [Fri, 26 Apr 2019 16:33:36 +0000 (17:33 +0100)]
drm/i915: Move i915_request_alloc into selftests/
Having transitioned GEM over to using intel_context as its primary means
of tracking the GEM context and engine combined and using
i915_request_create(), we can move the older i915_request_alloc()
helper function into selftests/ where the remaining users are confined.
Chris Wilson [Fri, 26 Apr 2019 16:33:35 +0000 (17:33 +0100)]
drm/i915: Remove intel_context.active_link
We no longer need to track the active intel_contexts within each engine,
allowing us to drop a tricky mutex_lock from inside unpin (which may
occur inside fs_reclaim).
Chris Wilson [Fri, 26 Apr 2019 16:33:34 +0000 (17:33 +0100)]
drm/i915: Switch back to an array of logical per-engine HW contexts
We switched to a tree of per-engine HW context to accommodate the
introduction of virtual engines. However, we plan to also support
multiple instances of the same engine within the GEM context, defeating
our use of the engine as a key to looking up the HW context. Just
allocate a logical per-engine instance and always use an index into the
ctx->engines[]. Later on, this ctx->engines[] may be replaced by a user
specified map.
v2: Add for_each_gem_engine() helper to iterator within the engines lock
v3: intel_context_create_request() helper
v4: s/unsigned long/unsigned int/ 4 billion engines is quite enough.
v5: Push iterator locking to caller
Chris Wilson [Fri, 26 Apr 2019 16:33:33 +0000 (17:33 +0100)]
drm/i915: Split engine setup/init into two phases
In the next patch, we require the engine vfuncs setup prior to
initialising the pinned kernel contexts, so split the vfunc setup from
the engine initialisation and call it earlier.
v2: s/setup_xcs/setup_common/ for intel_ring_submission_setup()
Chris Wilson [Fri, 26 Apr 2019 16:33:28 +0000 (17:33 +0100)]
drm/i915/gvt: Pin the per-engine GVT shadow contexts
Our eventual goal is to rid request construction of struct_mutex, with
the short term step of lifting the struct_mutex requirements into the
higher levels (i.e. the caller must ensure that the context is already
pinned into the GTT). In this patch, we pin GVT's shadow context upon
allocation and so keep them pinned into the GGTT for as long as the
virtual machine is alive, and so we can use the simpler request
construction path safe in the knowledge that the hard work is already
done.
Ville Syrjälä [Mon, 8 Apr 2019 12:18:15 +0000 (15:18 +0300)]
drm/i915: Clean up cherryview_load_luts()
I like my functions simple, so split up the low level bits from
cherryview_load_luts() into separate functions. Also rename the
whole thing to chv_load_luts() to match the new world order.
Ville Syrjälä [Thu, 25 Apr 2019 19:24:19 +0000 (22:24 +0300)]
drm/i915: Fix ICL output CSC programming
When I refactored the code into its own function I accidentally
misplaced the <<16 shifts for some of the registers causing us
to lose the blue channel entirely.
Chris Wilson [Fri, 19 Apr 2019 17:27:20 +0000 (18:27 +0100)]
drm/i915: Enable render context support for gen4 (Broadwater to Cantiga)
Broadwater and the rest of gen4 do support being able to saving and
reloading context specific registers between contexts, providing isolation
of the basic GPU state (as programmable by userspace). This allows
userspace to assume that the GPU retains their state from one batch to the
next, minimising the amount of state it needs to reload and manually save
across batches.
v2: CONSTANT_BUFFER woes
Running through piglit turned up an interesting issue, a GPU hang inside
the context load. The context image includes the CONSTANT_BUFFER command
that loads an address into a on-gpu buffer, and the context load was
executing that immediately. However, since it was reading from the GTT
there is no guarantee that the GTT retains the same configuration as
when the context was saved, resulting in stray reads and a GPU hang.
Having tried issuing a CONSTANT_BUFFER (to disable the command) from the
ring before saving the context to no avail, we resort to patching out
the instruction inside the context image before loading.
This does impose that gen4 always reissues CONSTANT_BUFFER commands on
each batch, but due to the use of a shared GTT that was and will remain
a requirement.
v3: ECOSKPD to the rescue
Ville found the magic bit in the ECOSKPD to disable saving and restoring
the CONSTANT_BUFFER from the context image, thereby completely avoiding
the GPU hangs from chasing invalid pointers. This appears to be the
default behaviour for gen5, and so we just need to tweak gen4 to match.
v4: Fix spelling of ECOSKPD and discover it already exists
Chris Wilson [Fri, 19 Apr 2019 11:17:48 +0000 (12:17 +0100)]
drm/i915: Enable render context support for Ironlake (gen5)
Ironlake does support being able to saving and reloading context specific
registers between contexts, providing isolation of the basic GPU state
(as programmable by userspace). This allows userspace to assume that the
GPU retains their state from one batch to the next, minimising the
amount of state it needs to reload, or manually save and restore.
v2: Fix off-by-one in reading CXT_SIZE, and add a comment that the
CXT_SIZE and context-layout do not match in bspec, but the difference is
irrelevant as we overallocate the full page anyway (Ville).
Despite what I think the prm recommends, commit f2253bd9859b
("drm/i915/ringbuffer: EMIT_INVALIDATE after switch context") turned out
to be a huge mistake when enabling Ironlake contexts as the GPU would
hang on either a MI_FLUSH or PIPE_CONTROL immediately following the
MI_SET_CONTEXT of an active mesa context (more vanilla contexts, e.g.
simple rendercopies with igt, do not suffer).
Ville found the following clue,
"[DevCTG+]: For the invalidate operation of the pipe control, the
following pointers are affected. The
invalidate operation affects the restore of these packets. If the pipe
control invalidate operation is completed
before the context save, the indirect pointers will not be restored from
memory.
1. Pipeline State Pointer
2. Media State Pointer
3. Constant Buffer Packet"
which suggests by us emitting the INVALIDATE prior to the MI_SET_CONTEXT,
we prevent the context-restore from chasing the dangling pointers within
the image, and explains why this likely prevents the GPU hang.
Chris Wilson [Fri, 26 Apr 2019 08:17:24 +0000 (09:17 +0100)]
drm/i915: Merge sandybridge_pcode_(read|write)
These routines are identical except in the nature of the value parameter.
For writes it is a pure in-param, but for a read, we need an out-param.
Since they differ in a single line, merge the two routines into one.
Chris Wilson [Fri, 26 Apr 2019 08:17:23 +0000 (09:17 +0100)]
drm/i915: Merge sbi read/write into a single accessor
Since intel_sideband_read and intel_sideband_write differ by only a
couple of lines (depending on whether we feed the value in or out),
merge the two into a single common accessor.
v2: Restore vlv_flisdsi_read() lost during rebasing.
Chris Wilson [Fri, 26 Apr 2019 08:17:21 +0000 (09:17 +0100)]
drm/i915: Replace pcu_lock with sb_lock
We now have two locks for sideband access. The general one covering
sideband access across all generation, sb_lock, and a specific one
covering sideband access via the punit on vlv/chv. After lifting the
sb_lock around the punit into the callers, the pcu_lock is now redudant
and can be separated from its other use to regulate RPS (essentially
giving RPS a lock all of its own).
Chris Wilson [Fri, 26 Apr 2019 08:17:20 +0000 (09:17 +0100)]
drm/i915: Lift sideband locking for vlv_punit_(read|write)
Lift the sideband acquisition for vlv_punit_read and vlv_punit_write
into their callers, so that we can lock the sideband once for a sequence
of operations, rather than perform the heavyweight acquisition on each
request.
Chris Wilson [Fri, 26 Apr 2019 08:17:19 +0000 (09:17 +0100)]
drm/i915: Lift acquiring the vlv punit magic to a common sb-get
As we now employ a very heavy pm_qos around the punit access, we want to
minimise the number of synchronous requests by performing one for the
whole punit sequence rather than around individual accesses. The
sideband lock is used for this, so push the pm_qos into the sideband
lock acquisition and release, moving it from the lowlevel punit rw
routine to the callers. In the first step, we move the punit magic into
the common sideband lock so that we can acquire a bunch of ports
simultaneously, and if need be extend the workaround protection later.
Chris Wilson [Fri, 26 Apr 2019 08:17:18 +0000 (09:17 +0100)]
drm/i915: Disable preemption and sleeping while using the punit sideband
While we talk to the punit over its sideband, we need to prevent the cpu
from sleeping in order to prevent a potential machine hang.
Note that by itself, it appears that pm_qos_update_request (via
intel_idle) doesn't provide a sufficient barrier to ensure that all core
are indeed awake (out of Cstate) and that the package is awake. To do so,
we need to supplement the pm_qos with a manual ping on_each_cpu.
v2: Restrict the heavy-weight wakeup to just the ISOF_PORT_PUNIT, there
is insufficient evidence to implicate a wider problem atm. Similarly,
restrict the w/a to Valleyview, as Cherryview doesn't have an angry cadre
of users.
The working theory, courtesy of Ville and Hans, is the issue lies within
the power delivery and so is likely to be unit and board specific and
occurs when both the unit/fw require extra power at the same time as the
cpu package is changing its own power state.
References: https://bugzilla.kernel.org/show_bug.cgi?id=109051
References: https://bugs.freedesktop.org/show_bug.cgi?id=102657
References: https://bugzilla.kernel.org/show_bug.cgi?id=195255 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190426081725.31217-1-chris@chris-wilson.co.uk
Dave Airlie [Fri, 26 Apr 2019 01:35:40 +0000 (11:35 +1000)]
Merge tag 'drm-misc-next-fixes-2019-04-24' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
- fb_helper: Fix NULL deref in legacy drivers (Noralf)
- leases: Ensure lessees can't connect to objects outside their perview (Daniel)
- leases: Enforce that lessees hold the lease for implicitly set planes (Daniel)
- leases: A few non-functional cleanups (Daniel)
Chris Wilson [Thu, 25 Apr 2019 05:43:33 +0000 (06:43 +0100)]
drm/i915: Allow multiple user handles to the same VM
It was noted that we made the same mistake for VM_ID as for object
handles, whereby we ensured that we only allocated a single handle for
one ppgtt. This has the unfortunate consequence for userspace that they
need to reference count the handles to avoid destroying an active ID. If
we allow multiple handles to the same ppgtt, userspace can freely
unreference any handle they own without fear of destroying the same
handle in use elsewhere.
Chris Wilson [Thu, 25 Apr 2019 05:01:43 +0000 (06:01 +0100)]
drm/i915: Explicitly pin the logical context for execbuf
In order to separate the reservation phase of building a request from
its emission phase, we need to pull some of the request alloc activities
from deep inside i915_request to the surface, GEM_EXECBUFFER.
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
Daniel Vetter [Thu, 28 Feb 2019 14:49:10 +0000 (15:49 +0100)]
drm/atomic: -EACCESS for lease-denied crtc lookup
With the previous patch drm_crtc_find will return NULL when the crtc
isn't in our lease, which will then disable the plane/connector. No
longer an issue since the lessor can't escape their lease terms
anymore, but not quite great semantics yet either.
Catch this and return -EACCES, so that at least evil test cases have a
better chance of making sure the kernel works correctly.
Daniel Vetter [Thu, 28 Feb 2019 14:49:09 +0000 (15:49 +0100)]
drm/atomic: Wire file_priv through for property changes
We need this to make sure lessees can only connect their
plane/connectors to crtc objects they own. And note that this is
irrespective of whether the lessor is atomic or not, lessor cannot
prevent lessees from enabling atomic.
Daniel Vetter [Thu, 28 Feb 2019 14:49:08 +0000 (15:49 +0100)]
drm/lease: Make sure implicit planes are leased
If userspace doesn't enable universal planes, then we automatically
add the primary and cursor planes. But for universal userspace there's
no such check (and maybe we only want to give the lessee one plane,
maybe not even the primary one), hence we need to check for the
implied plane.
Daniel Vetter [Thu, 28 Feb 2019 14:49:04 +0000 (15:49 +0100)]
drm/leases: Drop object_id validation for negative ids
Not exactly sure what's the aim here, but the canonical nil object has
id == 0, we don't use negative object ids for anything. Plus all
object_id are valided by the object_idr, there's nothing we need to do
on top of that ENOENT check a bit further down.
Spotted while typing exhaustive igt coverage for all these
corner-cases.
Fix the order of lane, port parameters passed to the register macro.
Note that this was already partly fixed by commit 37fc7845df7b6 ("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: 58106b7d816e1 ("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
(cherry picked from commit 9c11b12184bb01d8ba2c48e655509b184f02c769) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
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
Dave Airlie [Wed, 24 Apr 2019 03:09:50 +0000 (13:09 +1000)]
Merge tag 'exynos-drm-next-for-v5.2' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next
Log cleanups
- Correct the use of log macro in error case.
- Drop unnecessary messages.
- Replace DRM_ERROR/DEBUG with DRM_DEV_ERROR/DEBUG.
- Print out debug messages with correct device name in vidi and ipp drivers.
One trivial cleanup
- Just fix checkpatch error, "foo* bar" to "foo *bar" in g2d driver.
Dave Airlie [Thu, 18 Apr 2019 07:10:40 +0000 (17:10 +1000)]
drm: allow removal of legacy codepaths (v4.1)
If you don't want the legacy drivers, then lets get rid of all the
legacy codepaths from the core module.
This drop the size of drm.ko for me by about 10%.
380515 7422 4192 392129 5fbc1 ../../drm-next-build/drivers/gpu/drm/drm.ko
351736 7298 4192 363226 58ada ../../drm-next-build/drivers/gpu/drm/drm.ko
v2: drop drm_lock as well, fix some DMA->DRM typos
v3: avoid ifdefs in mainline code
v4: rework ioctl defs
v4.1: fix nouveau Kconfig
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Thu, 18 Apr 2019 06:45:15 +0000 (16:45 +1000)]
drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3)
There was a nouveau DDX that relied on legacy context ioctls to work,
but we fixed it years ago, give distros that have a modern DDX the
option to break the uAPI and close the mess of holes that legacy
context support is.
The context functions are not used by the i915 driver and should not
be used by modeset drivers. These driver functions contain several bugs
and security holes. This change makes these functions optional can be
turned on by a setting, they are turned off by default for modeset
driver with the exception of the nouvea driver that may require them with
an old version of libdrm.
Revert "drm: mark context support as a legacy subsystem"
v2: remove returns from void function, and formatting (Daniel Vetter)
v3:
- s/Nova/nouveau/ in the commit message, and add references to the
previous attempts
- drop the part touching the drm hw lock, that should be a separate
patch.
Signed-off-by: Peter Antoine <peter.antoine@intel.com> (v2) Cc: Peter Antoine <peter.antoine@intel.com> (v2) Reviewed-by: Peter Antoine <peter.antoine@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: move DRM_VM dependency into legacy config.
v3: fix missing dep (kbuild robot)
Cc: stable@vger.kernel.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
Print out debug messages with correct device name.
As for this, this patch adds device pointer to exynos_drm_ipp structure,
and in case of exynos_drm_ipp_task structure, replace drm_device pointer
with device one. This will make each ipp driver to print out debug
messages with correct device name.
drm/vidi: replace platform_device pointer with device one
Add device pointer to vidi_context and remove platform_device pointer.
It doesn't need for vidi_context to contain platform_device object.
Instead, this patch makes this driver more simply by replacing platform_device
pointer with device one.
Dave Airlie [Wed, 24 Apr 2019 01:54:26 +0000 (11:54 +1000)]
Merge tag 'drm-msm-next-2019-04-21' of https://gitlab.freedesktop.org/drm/msm into drm-next
This time around it is a bunch of cleanup and fixes, expanding gpu
"zap" shader support (so we can take the GPU out of secure mode on
boot) to a6xx, and small UABI extension to support robustness (see
mesa MR 673).
Dave Airlie [Wed, 24 Apr 2019 01:24:22 +0000 (11:24 +1000)]
Merge branch 'drm-next-5.2' of git://people.freedesktop.org/~agd5f/linux into drm-next
- Add the amdgpu specific bits for timeline support
- Add internal interfaces for xgmi pstate support
- DC Z ordering fixes for planes
- Add support for NV12 planes in DC
- Add colorspace properties for planes in DC
- eDP optimizations if the GOP driver already initialized eDP
- DC bandwidth validation tracing support
Dave Airlie [Wed, 24 Apr 2019 00:30:41 +0000 (10:30 +1000)]
Merge tag 'drm/tegra/for-5.2-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Changes for v5.2-rc1
This contains a fix for the usage of shared resets that previously
generated a WARN on boot. In addition, there's a fix for CPU cache
maintenance of GEM buffers allocated using get_pages().
(airlied: contains a merge from a shared tegra tree)
Dave Airlie [Wed, 24 Apr 2019 00:12:34 +0000 (10:12 +1000)]
Merge tag 'drm-misc-next-2019-04-18' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for v5.2:
UAPI Changes:
- Document which feature flags belong to which command in virtio_gpu.h
- Make the FB_DAMAGE_CLIPS available for atomic userspace only, it's useless for legacy.
Cross-subsystem Changes:
- Add device tree bindings for lg,acx467akm-7 panel and ST-Ericsson Multi Channel Display Engine MCDE
- Add parameters to the device tree bindings for tfp410
- iommu/io-pgtable: Add ARM Mali midgard MMU page table format
- dma-buf: Only do a 64-bits seqno compare when driver explicitly asks for it, else wraparound.
- Use the 64-bits compare for dma-fence-chains
Core Changes:
- Make the fb conversion functions use __iomem dst.
- Rename drm_client_add to drm_client_register
- Move intel_fb_initial_config to core.
- Add a drm_gem_objects_lookup helper
- Add drm_gem_fence_array helpers, and use it in lima.
- Add drm_format_helper.c to kerneldoc.
Driver Changes:
- Add panfrost driver for mali midgard/bitfrost.
- Converts bochs to use the simple display type.
- Small fixes to sun4i, tinydrm, ti-fp410.
- Fid aspeed's Kconfig options.
- Make some symbols/functions static in lima, sun4i and meson.
- Add a driver for the lg,acx467akm-7 panel.
Dave Airlie [Wed, 24 Apr 2019 00:02:20 +0000 (10:02 +1000)]
Merge tag 'drm-intel-next-2019-04-17' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
UAPI Changes:
- uAPI "Fixes:" patch for the upcoming kernel 5.1, included here too
We have an Ack from the media folks (only current user) for this
late tweak
Cross-subsystem Changes:
- ALSA: hda: Fix racy display power access (Takashi, Chris)
Driver Changes:
- DDI and MIPI-DSI clocks fixes for Icelake (Vandita)
- Fix Icelake frequency change/locking (RPS) (Mika)
- Temporarily disable ppGTT read-only bit on Icelake (Mika)
- Add missing Icelake W/As (Mika)
- Enable 12 deep CSB status FIFO on Icelake (Mika)
- Inherit more Icelake code for Elkhartlake (Bob, Jani)
- Handle catastrophic error on engine reset (Mika)
- Shortcut readiness to reset check (Mika)
- Regression fix for GEM_BUSY causing us to report a mixed uabi-class request as not busy (Chris)
- Revert back to max link rate and lane count on eDP (Jani)
- Fix pipe BPP readout for BXT/GLK DSI (Ville)
- Set DP min_bpp to 8*3 for non-RGB output formats (Ville)
- Enable coarse preemption boundaries for Gen8 (Chris)
- Do not enable FEC without DSC (Ville)
- Restore correct BXT DDI latency optim setting calculation (Ville)
- Always reset context's RING registers to avoid running workload twice during reset (Chris)
- Set GPU wedged on driver unload (Janusz)
- Consolidate two similar barries from timeline into one (Chris)
- Only reset the pinned kernel contexts on resume (Chris)
- Wakeref tracking improvements (Chris, Imre)
- Lockdep fixes for shrinker interactions (Chris)
- Bump ready tasks ahead of busywaits in prep of semaphore use (Chris)
- Huge step in splitting display code into fine grained files (Jani)
- Refactor the IRQ init/reset macros for code saving (Paulo)
- Convert IRQ initialization code to uncore MMIO access (Paulo)
- Convert workarounds code to use uncore MMIO access (Chris)
- Nuke drm_crtc_state and use intel_atomic_state instead (Manasi)
- Update SKL clock-gating WA (Radhakrishna, Ville)
- Isolate GuC reset code flow (Chris)
- Expose force_dsc_enable through debugfs (Manasi)
- Header standalone compile testing framework (Jani)
- Code cleanups to reduce driver footprint (Chris)
- PSR code fixes and cleanups (Jose)
- Sparse and kerneldoc updates (Chris)
- Suppress spurious combo PHY B warning (Vile)
projects / mirror_ubuntu-kernels.git / log