drm/i915: Remove set but not used variable 'src_y'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/i915/display/intel_sprite.c: In function 'g4x_sprite_check_scaling':
drivers/gpu/drm/i915/display/intel_sprite.c:1494:13: warning:
variable 'src_y' set but not used [-Wunused-but-set-variable]
Chris Wilson [Tue, 16 Jul 2019 12:49:30 +0000 (13:49 +0100)]
drm/i915/execlists: Cancel breadcrumb on preempting the virtual engine
As we unwind the requests for a preemption event, we return a virtual
request back to its original virtual engine (so that it is available for
execution on any of its siblings). In the process, this means that its
breadcrumb should no longer be associated with the original physical
engine, and so we are forced to decouple it. Previously, as the request
could not complete without our awareness, we would move it to the next
real engine without any danger. However, preempt-to-busy allowed for
requests to continue on the HW and complete in the background as we
unwound, which meant that we could end up retiring the request before
fixing up the breadcrumb link.
A single 32-bit PSR2 training pattern field follows the sixteen element
array of PSR table entries in the VBT spec. But, we incorrectly define
this PSR2 field for each of the PSR table entries. As a result, the PSR1
training pattern duration for any panel_type != 0 will be parsed
incorrectly. Secondly, PSR2 training pattern durations for VBTs with bdb
version >= 226 will also be wrong.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: stable@vger.kernel.org Cc: stable@vger.kernel.org #v5.2 Fixes: 88a0d9606aff ("drm/i915/vbt: Parse and use the new field with PSR2 TP2/3 wakeup time")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183 Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: François Guerraz <kubrick@fgv6.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190717223451.2595-1-dhinakaran.pandiyan@intel.com
Chris Wilson [Thu, 18 Jul 2019 14:54:05 +0000 (15:54 +0100)]
drm/i915: Use maximum write flush for pwrite_gtt
As recently disovered by forcing big-core (!llc) machines to use the GTT
paths, we need our full GTT write flush before manipulating the GTT PTE
or else the writes may be directed to the wrong page.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190718145407.21352-2-chris@chris-wilson.co.uk
Ville Syrjälä [Wed, 17 Jul 2019 11:45:36 +0000 (14:45 +0300)]
drm/i915: Make sure cdclk is high enough for DP audio on VLV/CHV
On VLV/CHV there is some kind of linkage between the cdclk frequency
and the DP link frequency. The spec says:
"For DP audio configuration, cdclk frequency shall be set to
meet the following requirements:
DP Link Frequency(MHz) | Cdclk frequency(MHz)
270 | 320 or higher
162 | 200 or higher"
I suspect that would more accurately be expressed as
"cdclk >= DP link clock", and in any case we can express it like
that in the code because of the limited set of cdclk (200, 266,
320, 400 MHz) and link frequencies (162 and 270 MHz) we support.
Without this we can end up in a situation where the cdclk
is too low and enabling DP audio will kill the pipe. Happens
eg. with 2560x1440 modes where the 266MHz cdclk is sufficient
to pump the pixels (241.5 MHz dotclock) but is too low for
the DP audio due to the link frequency being 270 MHz.
v2: Spell out the cdclk and link frequencies we actually support
drm/i915/ehl: Use an id of 4 while accessing DPLL4's CR0 and CR1
Although, DPLL4 enable and disable is associated with MGPLL1_ENABLE
register, we can use ICL_DPLL_CFGCR0/CR1 macros to access this dpll's
CR0 and CR1 registers by passing an id of 4 to these macros.
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190717021316.18610-1-vivek.kasireddy@intel.com
Chris Wilson [Tue, 16 Jul 2019 12:49:28 +0000 (13:49 +0100)]
drm/i915/gt: Push engine stopping into reset-prepare
Push the engine stop into the back reset_prepare (where it already was!)
This allows us to avoid dangerously setting the RING registers to 0 for
logical contexts. If we clear the register on a live context, those
invalid register values are recorded in the logical context state and
replayed (with hilarious results).
Chris Wilson [Tue, 16 Jul 2019 12:49:29 +0000 (13:49 +0100)]
drm/i915/execlists: Process interrupted context on reset
By stopping the rings, we may trigger an arbitration point resulting in
a premature context-switch (i.e. a completion event before the request
is actually complete). This clears the active context before the reset,
but we must remember to rewind the incomplete context for replay upon
resume.
Chris Wilson [Tue, 16 Jul 2019 21:34:43 +0000 (22:34 +0100)]
drm/i915/oa: Reconfigure contexts on the fly
Avoid a global idle barrier by reconfiguring each context by rewriting
them with MI_STORE_DWORD from the kernel context.
v2: We only need to determine the desired register values once, they are
the same for all contexts.
v3: Don't remove the kernel context from the list of known GEM contexts;
the world is not ready for that yet.
Chris Wilson [Mon, 15 Jul 2019 08:09:28 +0000 (09:09 +0100)]
drm/i915: Lock the engine while dumping the active request
We cannot let the request be retired and freed while we are trying to
dump it during error capture. It is not sufficient just to grab a
reference to the request, as during retirement we may free the ring
which we are also dumping. So take the engine lock to prevent retiring
and freeing of the request.
Reported-by: Alex Shumsky <alexthreed@gmail.com> Fixes: 83c317832eb1 ("drm/i915: Dump the ringbuffer of the active request for debugging") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Alex Shumsky <alexthreed@gmail.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190715080946.15593-6-chris@chris-wilson.co.uk
Right now we are aware of two cases that needs another hotplug retry:
- Unpowered type-c dongles
- HDMI slow unplug
Both have a complete explanation in the code to schedule another run
of the hotplug handler.
It could have more checks to just trigger the retry in those two
specific cases but why would sink signal a long pulse if there is
no change? Also the drawback of running the hotplug handler again
is really low and that could fix another cases that we are not
aware.
Also retrying for old DP ports(non-DDI) to make it consistent and not
cause CI failures if those systems are connected to chamelium boards
that will be used to simulate the issues reported in here.
v2: Also retrying for old DP ports(non-DDI)(Imre)
v4: Renamed INTEL_HOTPLUG_NOCHANGE to INTEL_HOTPLUG_UNCHANGED to keep
it consistent(Rodrigo)
Tested-by: Timo Aaltonen <tjaalton@ubuntu.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190712005343.24571-2-jose.souza@intel.com
Imre Deak [Fri, 12 Jul 2019 00:53:42 +0000 (17:53 -0700)]
drm/i915: Add support for retrying hotplug
There is some scenarios that we are aware that sink probe can fail,
so lets add the infrastructure to let hotplug() hook to request
another probe after some time.
v2: Handle shared HPD pins (Imre)
v3: Rebased
v4: Renamed INTEL_HOTPLUG_NOCHANGE to INTEL_HOTPLUG_UNCHANGED to keep
it consistent(Rodrigo)
v5: Making the working queue used explicit through all the callers to
hotplug_work (Ville)
Tested-by: Timo Aaltonen <tjaalton@ubuntu.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190712005343.24571-1-jose.souza@intel.com
Chris Wilson [Fri, 12 Jul 2019 08:25:49 +0000 (09:25 +0100)]
drm/i915/selftests: Ignore self-preemption suppression under gvt
GVT forces single port submission of individual requests. We do not
enjoy the context amalgamation that the test depends upon for setting up
the test (where port 0 has a large number of requests with a priority
change somewhere in the middle). Under single request submission of gvt
it is quite able for the preemption event to occur while another context
is active and so there be a real need to act upon that preemption.
Get rid of them to avoid more users being added while the guc code
transitions to use gt more than i915.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Acked-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190713100016.8026-11-chris@chris-wilson.co.uk Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
drm/i915/guc: prefer intel_gt in guc interrupt functions
We can get rid of a few more guc_to_i915 and start compartmentalizing
interrupt management a bit more. We should be able to move more code in
the future once the gt_pm code is also moved across to gt.
drm/i915/uc: prefer intel_gt over i915 in GuC/HuC paths
With our HW interface logic moving from i915 to gt and with GuC and HuC
being part of the gt HW, it makes sense to use the intel_gt structure
instead of i915 as our reference object in GuC/HuC paths.
All the intel_uc_* can now be moved to work on the intel_uc structure
for better encapsulation of uc-related actions.
Note: I've introduced uc_to_gt instead of uc_to_i915 because the aim is
to move everything to be gt-focused in the medium term, so we would've
had to replace it soon anyway.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Acked-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190713100016.8026-8-chris@chris-wilson.co.uk Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
drm/i915/uc: move GuC/HuC inside intel_gt under a new intel_uc
Being part of the GT HW, it make sense to keep the guc/huc structures
inside the GT structure. To help with the encapsulation work done by the
following patches, both structures are placed inside a new intel_uc
container. Although this results in code with ugly nested dereferences
(i915->gt.uc.guc...), it saves us the extra work required in moving
the structures twice (i915 -> gt -> uc). The following patches will
reduce the number of places where we try to access the guc/huc
structures directly from i915 and reduce the ugliness.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190713100016.8026-7-chris@chris-wilson.co.uk Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Both microcontrollers are part of the GT HW and are closely related to
GT operations. To keep all the files cleanly together, they've been
placed in their own subdir inside the gt/ folder
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190713100016.8026-6-chris@chris-wilson.co.uk Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The 16-bit guc irq vector is unchanged across gens, the only thing that
moved is its position (from the upper 16 bits of the PM regs to its own
register). Instead of duplicating all defines and functions to handle
the 2 different positions, we can work on the vector and shift it as
appropriate. While at it, update the handler to work on intel_guc.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190713100016.8026-5-chris@chris-wilson.co.uk Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Instead of always checking in the device config is GuC and HuC are
supported or not, we can save the state in the uc_fw structure and
avoid going through i915 every time from the low-level uc management
code. while at it FIRMWARE_NONE has been renamed to better indicate that
we haven't started the fetch/load yet, but we might have already selected
a blob.
The "misc" terminology doesn't clearly explain what we intend to cover
in this phase. The only thing we used ot do in there apart from FW fetch
was initializing the log workqueue, with the latter being required only in
the very rare case where we enable the log relay. As we no longer create
our own workqueue, piggybacking on the system_highpri_wq instead, we can
rename the function to clarify that they only fetch/release the blobs.
v2: only create log wq when needed (Michal), reword commit msg
accordingly
v3: after rebase the wq is gone, reword commit msg accordingly
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190713100016.8026-2-chris@chris-wilson.co.uk Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson [Sat, 13 Jul 2019 10:00:06 +0000 (11:00 +0100)]
drm/i915/guc: Use system workqueue for log capture
We only employ a single task for log capture, and created a workqueue
for the purpose of ensuring we had a high priority queue for low
latency. We can simply use the system_highpri_wq and avoid the
complication with creating our own admist the maze of mutexes.
(Currently we create the wq early before we even know we need it in
order to avoid trying to create it on demand while we hold the logging
mutex.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190713100016.8026-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 12 Jul 2019 19:29:53 +0000 (20:29 +0100)]
drm/i915/gt: Use intel_gt as the primary object for handling resets
Having taken the first step in encapsulating the functionality by moving
the related files under gt/, the next step is to start encapsulating by
passing around the relevant structs rather than the global
drm_i915_private. In this step, we pass intel_gt to intel_reset.c
Some platforms may have Modular FIA. If Modular FIA is used in the SOC,
then Display Driver will access the additional instances of
FIA based on pre-assigned offset in GTTMADDR space.
Each Modular FIA instance has its own IOSF Sideband Port ID
and it houses only 2 Type-C Port. In SOC that has more than
two Type-C Ports, there are multiple instances of Modular FIA.
Gunit will need to use different destination ID when it access
different pair of Type-C Port.
The DFLEXDPSP register has Modular FIA bit starting on Tiger Lake. If
Modular FIA is used in the SOC, this register bit exists in all the
instances of Modular FIA. IOM FW is required to program only the MF bit
in first FIA instance that houses the Type-C Port 0 and Port 1, for
Display Driver to read from.
v2 (Lucas):
- Move all accesses to FIA to be contained in intel_tc.c, along with
display_fia that is now called tc_phy_fia
- Save the fia instance number on intel_digital_port, so we don't have
to query if modular FIA is used on every access
v3 (Lucas): Make function static
v4 (Lucas): Move enum phy_fia to the header and use it in
intel_digital_port (suggested by Ville)
v5 (Lucas): Add comment about the mapping between FIA and TC port
(suggested by Stuart)
Chris Wilson [Fri, 12 Jul 2019 11:27:23 +0000 (12:27 +0100)]
drm/i915/gtt: Recursive ppgtt clear for gen8
With an explicit level, we can refactor the separate clear functions
as a simple recursive function. The additional knowledge of the level
allows us to spot when we can free an entire subtree at once.
Chris Wilson [Fri, 12 Jul 2019 11:27:22 +0000 (12:27 +0100)]
drm/i915/gtt: Recursive cleanup for gen8
With an explicit level, we can refactor the separate cleanup functions
as a simple recursive function. We take the opportunity to pass down the
size of each level so that we can deal with the different sizes of
top-level and avoid over allocating for 32/36-bit vm.
Chris Wilson [Fri, 12 Jul 2019 13:42:34 +0000 (14:42 +0100)]
drm/i915/display: Drop kerneldoc for 'intel_atomic_commit'
intel_atomic_commit() is not for use internally, but only as an entry
point from the core drm atomic helper (drm_atomic_commit).
Squelches the warning for:
drivers/gpu/drm/i915/display/intel_display.c:14148: warning: Function parameter or member '_state' not described in 'intel_atomic_commit'
drivers/gpu/drm/i915/display/intel_display.c:14148: warning: Excess function parameter 'state' description in 'intel_atomic_commit'
Ville Syrjälä [Tue, 28 May 2019 14:06:50 +0000 (17:06 +0300)]
drm/i915: Skip SINK_COUNT read on CH7511
CH7511 doesn't update SINK_COUNT properly so in order to detect
the device as connected we have to ignore SINK_COUNT.
In order to have access to the quirk list early enough we
must move the drm_dp_read_desc() call to happen earlier.
We can also skip re-reading this on eDP since we know it
won't change.
Cc: David S. <david@majinbuu.com> Cc: Peteris Rudzusiks <peteris.rudzusiks@gmail.com> Tested-by: Peteris Rudzusiks <peteris.rudzusiks@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105406 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190528140650.19230-2-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com> #irc
Michal Wajdeczko [Fri, 12 Jul 2019 11:14:45 +0000 (11:14 +0000)]
drm/i915/guc: Turn on GuC/HuC auto mode
Using "enable_guc" modparam auto mode (-1) will let driver
decide on which platforms and in which configuration we want
to use GuC/HuC firmwares.
Today driver will enable HuC firmware authentication by GuC
only on Gen11+ platforms as HuC firmware is required to unlock
advanced video codecs in media driver.
Legacy platforms with GuC/HuC are not affected by this change
as for them driver still defaults to disabled(0) in auto mode.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190712111445.21040-3-michal.wajdeczko@intel.com
Michal Wajdeczko [Fri, 12 Jul 2019 11:14:44 +0000 (11:14 +0000)]
drm/i915/guc: Don't enable GuC/HuC in auto mode on pre-Gen11
We are about to change default setting of "enable_guc" modparam
from 0(disabled) to -1(auto). As we only want to turn on
GuC/HuC on Gen11+, keep it off for older gens.
Note that it would be still possible to enable GuC/HuC on these
old platforms using explicit "enable_guc=2" modparam.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190712111445.21040-2-michal.wajdeczko@intel.com
drm/i915: Propagate "_probe" function name suffix down
Similar to the "_release" and "_remove" cases, consequently replace
"_init" components of names of functions called from
i915_driver_probe() with "_probe" suffixes for better code readability.
drm/i915: Propagate "_remove" function name suffix down
Similar to the "_release" case, consistently replace mixed
"_cleanup"/"_fini"/"_fini_hw" components found in names of functions
called from i915_driver_remove() with "_remove" or "_driver_remove"
suffixes for better code readability.
drm/i915: Propagate "_release" function name suffix down
Replace mixed "_fini"/"_cleanup"/"_cleanup_hw" suffixes found in names
of functions called from i915_driver_release() with "_release" suffix
consistently. This provides better code readability, especially
helpful when trying to work out which phase the code is in.
Functions names starting with "i915_driver_", i.e., those defined in
drivers/gpu/dri/i915/i915_drv.c, just have their "cleanup" or "fini"
parts of their names replaced with the "_release" suffix, while names
of functions coming from other source files have been suffixed with
"_driver_release" to avoid ambiguity with other possible .release entry
points.
v2: early_probe pairs better with late_release (Chris)
v3: fix typo in commit message (Joonas)
drm/i915: Replace "_load" with "_probe" consequently
Use the "_probe" nomenclature not only in i915_driver_probe() helper
name but also in other related function / variable names for
consistency. Only the userspace exposed name of a related module
parameter is left untouched.
drm/i915: Rename "_load"/"_unload" to match PCI entry points
Current names of i915_driver_load/unload() functions originate in
legacy DRM stubs. Reduce nomenclature ambiguity by renaming them to
match their current use as helpers called from PCI entry points.
Chris Wilson [Fri, 12 Jul 2019 09:43:26 +0000 (10:43 +0100)]
drm/i915/gtt: Convert vm->scratch into an array
Each level has its own scratch. Make the levels more obvious by forgoing
the fancy similarly names and replace them with a number. 0 is the bottom
most level, the physical page used for actual data; 1+ are the page
directories.
John Harrison [Fri, 12 Jul 2019 07:07:45 +0000 (00:07 -0700)]
drm/i915: Add engine name to workaround debug print
There is a debug message in the workaround initialisation path that
reports how many entries were added of each type. However, whitelist
workarounds exist for multiple engines but the type name is just
'whitelist'. Tvrtko suggested adding the engine name to make the
message more useful.
v2: Updated the similar message in the workaround reset selftest.
John Harrison [Fri, 12 Jul 2019 07:07:44 +0000 (00:07 -0700)]
drm/i915: Implement read-only support in whitelist selftest
Newer hardware supports extra feature in the whitelist registers. This
patch updates the selftest to test that entries marked as read only
are actually read only.
v2: Removed all use of 'rsvd' for read-only registers to avoid
ambiguous code or error messages.
Lucas De Marchi [Thu, 11 Jul 2019 17:31:12 +0000 (10:31 -0700)]
drm/i915/tgl: port to ddc pin mapping
Make the icl function generic so it is based on phy type and can be
applied to tgl as well.
I checked if this could not apply to EHL as well, but unfortunately
there the HPD and DDC/GMBUS pins for DDI C are mapped to TypeC Port 1
even though it doesn't have TC phy.
v2: don't add a separate function for TGL, but rather reuse the ICL one
(suggested by Rodrigo)
v3: rebase after the introduction of enum phy and use it for the
conversions
Add default GPIO pin mapping for all ports. Tiger Lake has 3 combophy
ports and 6 TC ports, gpio pin1-3 are mapped to combophy & pin9-14 are
mapped to TC ports.
Previously, the recommended B credit for all platforms was 24 / number
of pipes, which would give 6 for newer platforms with 4 pipes. However 6
is not enough and we need 12 on these cases.
We also need a different BW credit for these platforms.
There are 2 new additional typeC ports in Tiger Lake and PORT-C is now a
combophy port. This results in 6 typeC ports and 3 combophy ports.
These 6 TC ports can be DP alternate mode, DP over thunderbolt, native
DP on legacy DP connector or native HDMI on legacy connector.
v2: Rebase on new modular FIA code (Lucas)
v3: Also add new port in port_identifier(), even though it can't
possibly be used there (requested by José)
v4: Add conversion port->tc_port in helper function after introction of
phy namespace (Lucas)
Add 2 new PLLs for additional TC ports. The names for the PLLs on TGL
changed, but most registers remained the same, like MGPLL5_ENABLE,
MGPLL6_ENABLE. So continue to use the name from ICL.
Imre Deak [Thu, 11 Jul 2019 17:31:02 +0000 (10:31 -0700)]
drm/i915/tgl: Add power well support
The patch adds the new power wells introduced by TGL (GEN 12) and
maps these to existing/new power domains. The changes for GEN 12 wrt
to GEN 11 are the following:
- Transcoder#EDP removed from power well#1 (Transcoder#A used in
low-power mode instead)
- Transcoder#A is now backed by power well#1 instead of power well#3
- The DDI#B/C combo PHY ports are now backed by power well#1 instead of
power well#3
- New power well#5 added for pipe#D functionality (TODO)
- 2 additional TC ports (TC#5-6) backed by power well#3, 2 port
specific IO power wells (only for the non-TBT modes) and 4 port
specific AUX power wells (2-2 for TBT vs. non-TBT modes)
- Power well#2 backs now VDSC/joining for pipe#A instead of VDSC for
eDP and MIPI DSI (TODO)
On TGL Port DDI#C changed to be a combo PHY (native DP/HDMI) and
BSpec has renamed ports DDI#D-F to TC#4-6 respectively. Thus on ICL we
have the following naming for ports:
Starting from GEN 12 we have the following naming for ports:
- Combo PHYs (native DP/HDMI):
DDI#A-C
- TBT/non-TBT (TC altmode, native DP/HDMI) PHYs:
DDI TC#1-6
To save some space in the power domain enum the power domain naming in
the driver reflects the above change, that is power domains TC#1-3 are
added as aliases for DDI#D-F and new power domains are reserved for
TC#4-6.
v2 (Lucas):
- Separate out the bits and definitions for TGL from the ICL ones.
Fix use of TRANSCODER_EDP_VDSC, that is now the correct define since
we don't define TRANSCODER_A_VDSC power domain to spare a one bit in
the bitmask (suggested by Ville)
v3 (Lucas):
- Fix missing squashes on v2
- Rebase on renamed TRANSCODER_EDP_VDSC
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190711173115.28296-9-lucas.demarchi@intel.com
drm/i915/tgl: rename TRANSCODER_EDP_VDSC to use on transcoder A
On TGL the special EDP transcoder is gone and it should be handled by
transcoder A.
v2 (Lucas):
- Reuse POWER_DOMAIN_TRANSCODER_EDP_VDSC (suggested by Ville)
- Use crtc->dev since new_crtc_state->state may be NULL on atomic
commit (suggested by Maarten)
v3 (Lucas):
- Rename power domain so it's clear it can also be used for transcoder
A in TGL (requested by José and Manasi)
drm/i915: Copy name string into ring buffer for intel_update/disable_plane tracepoints
Currently the intel_update_plane and intel_disable_plane tracepoints record
the address of plane->name in the ring buffer, and then when reading the
ring buffer uses %s to get the name. The issue with this, is that those two
events can be minutes, hours or even days apart. It is very dangerous to
dereference a string pointer without knowing if it still exists or not.
The proper way to handle this is to use the __string() macro in the
tracepoint which will save the string into the ring buffer at the time of
recording. Then there's no worries if the original string still exists in
memory when the ring buffer is read.
Ville Syrjälä [Wed, 10 Jul 2019 13:49:37 +0000 (16:49 +0300)]
drm/i915: Don't pass stack garbage to pcode in the second data register
Zero initialize val2 so that we don't pass stack garbage to
the pcode qgv read command. I suspect in this case pcode
just ignores the initial value in that registers, but better
safe than sorry.
Ville Syrjälä [Mon, 1 Jul 2019 16:05:47 +0000 (19:05 +0300)]
drm/i915: Polish intel_shared_dpll_swap_state()
Use swap() instead of hand rolling it in intel_shared_dpll_swap_state(),
and pass in the intel_atomic_state instead of drm_atomic_state. Makes
the code less convoluted.
Ville Syrjälä [Mon, 1 Jul 2019 16:15:34 +0000 (19:15 +0300)]
drm/i915: Use the "display core" power domain in vlv/chv set_cdclk()
The PFI credit programming performed during cdclk change on vlv/chv
requires access to a register in the disp2d power well. So far
we've abused pipe-A power domain for this, but now we have the
more appropriate "display core" domain so let's make use of it.
Chris Wilson [Thu, 11 Jul 2019 06:51:59 +0000 (07:51 +0100)]
drm/i915/selftests: Hold the vma manager lock while modifying mmap_offset
Right idea, wrong lock. We already drop struct_mutex before we free the
mmap_offset when freeing the object, so we need to take the vma manager
lock when manipulating the mmap_offset address space for our selftests.
We originally added support, in some cases partial, for different modes
of operations via guc clients:
- proxy vs direct submission;
- variable engine mask per-client.
We only ever used one flow (all submissions via a single proxy), so the
other code paths haven't been exercised and are most likely
non-functional. The guc firmware interface is also in the process of
being updated to better fit the i915 flow and our client abstraction
will need to change accordingly (or possibly go away entirely), so these
old unused paths can be considered dead and removed.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Acked-by: Matthew Brost <Matthew Brost <matthew.brost@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190710005437.3496-3-daniele.ceraolospurio@intel.com
Chris Wilson [Wed, 10 Jul 2019 00:54:26 +0000 (17:54 -0700)]
drm/i915/guc: Remove preemption support for current fw
Preemption via GuC submission is not being supported with its current
legacy incarnation. The current FW does support a similar pre-emption
flow via H2G, but it is class-based instead of being instance-based,
which doesn't fit well with the i915 tracking. To fix this, the
firmware is being updated to better support our needs with a new flow,
so we can safely remove the old code.
v2 (Daniele): resurrect & rebase, reword commit message, remove
preempt_context as well
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Acked-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190710005437.3496-2-daniele.ceraolospurio@intel.com
Matt Roper [Tue, 9 Jul 2019 18:39:32 +0000 (11:39 -0700)]
drm/i915/gen11: Convert combo PHY logic to use new 'enum phy' namespace
Convert the code that operates directly on gen11 combo PHY's to use the
new namespace. Combo PHY registers are those named "ICL_PORT_*" plus
ICL_DPHY_CHKN.
Note that a lot of the PHY programming happens in the MIPI DSI code.
For clarity I've added a for_each_dsi_phy() to loop over the phys used
by DSI. Since DSI always uses A & B on gen11, port=phy in all cases so
it doesn't actually matter which form we use in the DSI code. I've used
the phy iterator in code that's explicitly working with the combo PHY,
but left the rest of the DSI code using the port iterator and namespace
to minimize patch deltas. We can switch the rest of the DSI code over
to use phy terminology later if this winds up being too confusing.
v6: Drop an include of drm/i915_drm.h; that was previously included just
for the definition of 'enum port' which this patch removes the need
for. (Jose)
Matt Roper [Tue, 9 Jul 2019 18:39:31 +0000 (11:39 -0700)]
drm/i915/gen11: Program ICL_DPCLKA_CFGCR0 according to PHY
Although the register name implies that it operates on DDI's,
DPCLKA_CFGCR0_ICL actually needs to be programmed according to the PHY
that's in use. I.e., when using EHL's DDI-D on combo PHY A, the bits
described as "port A" in the bspec are what we need to set. The bspec
clarifies:
"[For EHL] DDID clock tied to DDIA clock, so DPCLKA_CFGCR0 DDIA
Clock Select chooses the PLL for both DDIA and DDID and drives
port A in all cases."
Also, since the CNL DPCLKA_CFGCR0 bit defines are still port-based, we
create separate ICL-specific defines that accept the PHY rather than
trying to share the same bit definitions between CNL and ICL.
v5: Make icl_dpclka_cfgcr0_clk_off() take phy rather than port. When
splitting the original patch the hunk to handle this wound up too
late in the series. (Sparse)
v6: Since we're already changing this code,
s/DPCLKA_CFGCR0_ICL/ICL_DPCLKA_CFGCR0/ for consistency. (Jose)
Matt Roper [Tue, 9 Jul 2019 18:39:30 +0000 (11:39 -0700)]
drm/i915/gen11: Start distinguishing 'phy' from 'port'
Our past DDI-based Intel platforms have had a fixed DDI<->PHY mapping.
Because of this, both the bspec documentation and our i915 code has used
the term "port" when talking about either DDI's or PHY's; it was always
easy to tell what terms like "Port A" were referring to from the
context.
Unfortunately this is starting to break down now that EHL allows PHY-A
to be driven by either DDI-A or DDI-D. Is a setup with DDI-D driving
PHY-A considered "Port A" or "Port D?" The answer depends on which
register we're working with, and even the bspec doesn't do a great job
of clarifying this.
Let's try to be more explicit about whether we're talking about the DDI
or the PHY on gen11+ by using 'port' to refer to the DDI and creating a
new 'enum phy' namespace to refer to the PHY in use.
This patch just adds the new PHY namespace, new phy-based versions of
intel_port_is_*(), and a helper to convert a port to a PHY.
Transitioning various areas of the code over to using the PHY namespace
will be done in subsequent patches to make review easier. We'll remove
the intel_port_is_*() functions at the end of the series when we
transition all callers over to using the PHY-based versions.
v2:
- Convert a few more 'port' uses to 'phy.' (Sparse)
v3:
- Switch DDI_CLK_SEL() back to 'port.' (Jose)
- Add a code comment clarifying why DPCLKA_CFGCR0_ICL needs to use PHY
for its bit definitions, even though the register description is
given in terms of DDI.
- To avoid confusion, switch CNL's DPCLKA_CFGCR0 defines back to using
port and create separate ICL+ definitions that work in terms of PHY.
v4:
- Rebase and resolve conflicts with Imre's TC series.
- This patch now just adds the namespace and a few convenience
functions; the important changes are now split out into separate
patches to make review easier.
Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190709183934.445-2-matthew.d.roper@intel.com
projects / kernel.git / log