Imre Deak [Fri, 28 Jun 2019 14:36:23 +0000 (17:36 +0300)]
drm/i915: Handle the TCCOLD power-down event
Based on a recent BSpec update (Index/21750) we must handle the TCCOLD
event associated with the DP-alt mode. We can detect this event by
reading an invalid all-1s value from FIA registers.
After detecting TCCOLD we will:
- fall back to TBT-alt mode when attempting to switch to DP-alt mode
- conclude that nothing is connected during live status detection
- WARN when already in unsafe mode, since then TCCOLD is unexpected
v2:
- Use DRM_DEBUG_KMS instead of DRM_DEBUG_DRIVER. (José)
v3:
- Use 0xffffffff instead of -1 as invalid FIA reg value.
(José, Ville)
- Check for TCCOLD in icl_tc_phy_status_complete() too. (Ville)
Imre Deak [Fri, 28 Jun 2019 14:36:22 +0000 (17:36 +0300)]
drm/i915: Wait for TypeC PHY complete flag to clear in safe mode
The PHY status complete flag normally clears when disconnecting the PHY
in DP-alt mode (achieved by switching to safe mode), so wait for the
flag to clear.
v2:
- Use DRM_DEBUG_KMS instead of DRM_DEBUG_DRIVER. (José)
Imre Deak [Fri, 28 Jun 2019 14:36:21 +0000 (17:36 +0300)]
drm/i915: Factor out common parts from TypeC port handling functions
Factor out helpers reading/parsing the TypeC specific registers, making
current users of them clearer and letting us use them later.
While at it also:
- Simplify icl_tc_phy_connect() with an early return in legacy mode.
- Simplify the live status check using one bitmask for all HPD bits.
- Remove a micro-optimisation of the repeated safe-mode clearing.
- Make sure we fix the legacy port flag in all cases.
Except for the last two, no functional changes.
v2:
- Don't do reg reads at variable declarations. (Jani)
- Prevent constant truncated compiler warning when assigning the
valid_hpd_mask. (Nick)
- s/intel_tc_port_get_lane_info/intel_tc_port_get_lane_mask/ (Ville)
v3:
- Make valid_hpd_mask init clear. (Ville)
Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-10-imre.deak@intel.com
Imre Deak [Fri, 28 Jun 2019 14:36:18 +0000 (17:36 +0300)]
drm/i915: Fix the TBT AUX power well enabling
Fix the mapping from a TBT AUX power well index to the DP_AUX_CH_CTL
register.
Fixes: a1803ea91263 ("drm/i915: Configure AUX_CH_CTL when enabling the AUX power domain") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-7-imre.deak@intel.com
Imre Deak [Fri, 28 Jun 2019 14:36:17 +0000 (17:36 +0300)]
drm/i915: Don't enable the DDI-IO power in the TypeC TBT-alt mode
According to the spec we should not enable the DDI-IO power domain if
the TypeC port is in the TBT-alt mode, so do that only in the other
TypeC modes or for non-TypeC ports. See the internal BSpec Index/22243.
v2:
- Add the internal BSpec reference to the log message. (José)
Imre Deak [Fri, 28 Jun 2019 14:36:16 +0000 (17:36 +0300)]
drm/i915: Sanitize the terminology used for TypeC port modes
The TypeC port mode can switch dynamically, to reflect that better call
the port's mode as 'mode' rather than 'type'.
While at it:
- s/TC_PORT_TBT/TC_PORT_TBT_ALT/ and s/TC_PORT_TYPEC/TC_PORT_DP_ALT/.
'TYPEC' is ambiguous, TBT_ALT and DP_ALT better match the reality.
- Remove the 'unknown' TypeC port mode. The mode is always known, it's
the TBT-alt/safe mode after HW reset and after disconnecting the PHY.
Simplify the tc_port/tc_type checks accordingly.
- Don't WARN if the port mode changes, that can happen normally.
No functional changes.
Cc: Animesh Manna <animesh.manna@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@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/20190628143635.22066-5-imre.deak@intel.com
Imre Deak [Fri, 28 Jun 2019 14:36:15 +0000 (17:36 +0300)]
drm/i915: Move the TypeC port handling code to a separate file
Move the TypeC port handling functions to a new file for clarity.
While at it:
- s/icl_tc_port_connected()/intel_tc_port_connected()/
icl_tc_phy_disconnect(), will be unexported later.
- s/intel_dp_get_fia_supported_lane_count()/
intel_tc_port_fia_max_lane_count()/
It's used for HDMI legacy mode too.
- Simplify function interfaces by passing only dig_port to them.
No functional changes.
v2:
- Fix checkpatch issues: +1/-1 empty lines in intel_tc.c and add
missing SPDX to intel_tc.h. (Jani)
Cc: Animesh Manna <animesh.manna@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-4-imre.deak@intel.com
Imre Deak [Fri, 28 Jun 2019 14:36:14 +0000 (17:36 +0300)]
drm/i915: Tune down WARNs about TBT AUX power well enabling
The HW completion flag for the TBT AUX power well enabling/disabling
gets stuck if the firmware tears down the TBT DP tunnel before the
completion.
We shouldn't complain about the timeout, since it's expected to happen
and doesn't cause further issues. We suppress the disabling timeout
already, do the same for enabling.
drm/i915: Use intel state as much as possible in wm code
Instead of directly referencing drm_crtc_state, convert to
intel_ctc_state and use the base struct. This is useful when we're
making the split between uapi and hw state, and also makes the
code slightly more readable.
A lot of places also use cstate, instead of the more common crtc_state.
Clean those up to use crtc_state. Same for pstate vs plane_state. (Ville)
drm/i915: Pass intel state to plane functions as well
Pass along the correct state as much as possible, instead of relying
on the drm state internally. This is required to rely on hw state
internally soon.
While at it, clean up intel_plane_atomic_check slightly, by using a
helper function to get the intel_crtc. (Ville)
drm/i915: Convert most of atomic commit to take more intel state
Instead of passing along drm_crtc_state and drm_atomic_state, pass
along more intel_atomic_state and intel_crtc_state. This will
make the code more readable by not casting between drm state
and intel state all the time.
While at it, rename old_state to state, with the get_new/old helpers
there is no point in distinguishing between state before and after
swapping state any more. (Ville)
drm/i915: Pass intel_crtc_state to needs_modeset()
In i915 we should use intel_crtc_state as much as possible, pass
intel_crtc_state to needs_modeset, before we clean up all other uses
of drm_crtc_state.
Lucas De Marchi [Tue, 25 Jun 2019 17:54:11 +0000 (10:54 -0700)]
drm/i915: rework reading pipe disable fuses
This prepares to have possibly more than 3 pipes. I didn't want to
continue the previous approach since the check for "are the disabled
pipes the last ones" poses a combinatory explosion. We need that check
because in several places of the code we have that assumption. If that
ever becomes false in a new HW, other parts of the code would have to
change.
Now we start by considering we have info->num_pipes enabled and disable
each pipe that is marked as disabled. Then it's a simple matter of
checking if we have at least one pipe and that all the enabled ones are
the first pipes, i.e. there are no holes in the bitmask.
Chris Wilson [Wed, 26 Jun 2019 22:42:12 +0000 (23:42 +0100)]
drm/i915: Make i945gm_vblank_work_func static
drivers/gpu/drm/i915/i915_irq.c:3382:6: warning: symbol 'i945gm_vblank_work_func' was not declared. Should it be static?
CC [M] drivers/gpu/drm/i915/i915_irq.o
drivers/gpu/drm/i915/i915_irq.c:3382:6: error: no previous prototype for ‘i945gm_vblank_work_func’ [-Werror=missing-prototypes]
void i945gm_vblank_work_func(struct work_struct *work)
Jani wrote the idential patch, so for posterity:
The static keyword was apparently accidentally removed in commit 337ce80bc209 ("drm/i915: Switch to per-crtc vblank vfuncs"), leading to
sparse warning:
drivers/gpu/drm/i915/i915_irq.c:3382:6: warning: symbol
'i945gm_vblank_work_func' was not declared. Should it be static?
Make the function static again.
Meanwhile, the 0-day kbuilder also spotted the mistake.
Jani Nikula [Wed, 26 Jun 2019 14:36:18 +0000 (17:36 +0300)]
drm/i915: add header search path to subdir Makefiles
With the subdirectories we lost the ability to build individual files on
the command line, for example:
$ make drivers/gpu/drm/i915/display/intel_display.o
This was due to the top level directory missing from header search
path. Add the header search paths to subdir Makefiles.
Note that none of the other options in the top level i915 Makefile are
taken into account when building individual files. Usually this is not a
concern.
Michal Wajdeczko [Wed, 26 Jun 2019 12:38:26 +0000 (12:38 +0000)]
drm/i915: Move OA files to separate folder
OA files look to be auto-generated so we can keep them all in
dedicated subdirectory.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190626123826.39760-1-michal.wajdeczko@intel.com
EHL has it own voltage level requirement depending on cd clock.
BSpec: 21809 Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190626014053.30541-3-jose.souza@intel.com
v2:
- Limiting maximum CD clock by max_cdclk_freq instead of remove it
from icl_calc_cdclk()(Ville and Jani)
BSpec: 20598 Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190626014053.30541-2-jose.souza@intel.com
180 and 172.8 MHz CD clocks will only be used when audio is not
enabled as state by BSpec and implemented in
intel_crtc_compute_min_cdclk(), CD clock must be at least twice of
Azalia BCLK and BCLK by default is 96 MHz, it could be set to 48 MHz
but we are not reading it.
Chris Wilson [Wed, 26 Jun 2019 15:45:49 +0000 (16:45 +0100)]
drm/i915: Lift intel_engines_resume() to callers
Since the reset path wants to recover the engines itself, it only wants
to reinitialise the hardware using i915_gem_init_hw(). Pull the call to
intel_engines_resume() to the module init/resume path so we can avoid it
during reset.
Chris Wilson [Wed, 26 Jun 2019 15:45:48 +0000 (16:45 +0100)]
drm/i915: Only recover active engines
If we issue a reset to a currently idle engine, leave it idle
afterwards. This is useful to excise a linkage between reset and the
shrinker. When waking the engine, we need to pin the default context
image which we use for overwriting a guilty context -- if the engine is
idle we do not need this pinned image! However, this pinning means that
waking the engine acquires the FS_RECLAIM, and so may trigger the
shrinker. The shrinker itself may need to wait upon the GPU to unbind
and object and so may require services of reset; ergo we should avoid
the engine wake up path.
The danger in skipping the recovery for idle engines is that we leave the
engine with no context defined, which may interfere with the operation of
the power context on some older platforms. In practice, we should only
be resetting an active GPU but it something to look out for on Ironlake
(if memory serves).
Chris Wilson [Wed, 26 Jun 2019 15:45:47 +0000 (16:45 +0100)]
drm/i915: Add a wakeref getter for iff the wakeref is already active
For use in the next patch, we want to acquire a wakeref without having
to wake the device up -- i.e. only acquire the engine wakeref if the
engine is already active.
Ville Syrjälä [Wed, 19 Jun 2019 17:08:42 +0000 (20:08 +0300)]
drm/i915: Initialize drm_driver vblank funcs at compile time
Move the .get_vblank_timestamp() and .get_scanout_position()
initialization to happen at compile time. No point in delaying
it since we always assign the same functions.
Ville Syrjälä [Thu, 20 Jun 2019 10:33:34 +0000 (13:33 +0300)]
drm/i915: Nuke drm_driver irq vfuncs
Stop using the irq vfuncs under drm_driver. That's not going to fly
in a mixed gen environment since the structure is shared between all
the devices.
v2: Allow intel_irq_uninstall() to be called twice due to
intel_modeset_cleanup() calling it as well. Toss in a
FIXME to remind us that this is not great.
Ville Syrjälä [Wed, 19 Jun 2019 17:08:39 +0000 (20:08 +0300)]
drm/i915: Fix various tracepoints for gen2
Gen2 doesn't have a frame counter and apparently we no longer provide
a fake .get_vblank_counter() hook for it. That means all tracepoints
calling that hook will oops. Update the tracepoints to use
intel_crtc_get_vblank_counter() which will gracefully fall back to
using the software counter. This is actually a better approach since
we now get (hopefully accurate) frame numbers in the traces.
This also gets rid of the raw driver->get_vblank_counter() calls, which
we need to do in order to switch to the per-crtc vblank vfuncs.
v2: Deal with new tracepoints
v3: Use a distinct variable name for the internal crtc iterator (Chris)
Chris Wilson [Wed, 26 Jun 2019 13:44:33 +0000 (14:44 +0100)]
drm/i915/selftests: Fixup atomic reset checking
We require that the intel_gpu_reset() was atomic, not the whole of
i915_reset() which is guarded by a mutex. However, we do require that
i915_reset_engine() is atomic for use from within the submission tasklet.
Chris Wilson [Wed, 26 Jun 2019 13:44:32 +0000 (14:44 +0100)]
drm/i915/selftests: Drop manual request wakerefs around hangcheck
We no longer need to manually acquire a wakeref for request emission, so
drop the redundant wakerefs, letting us test our wakeref handling more
precisely.
Chris Wilson [Wed, 26 Jun 2019 13:44:31 +0000 (14:44 +0100)]
drm/i915/selftests: Serialise nop reset with retirement
In order for the reset count to be accurate across our selftest, we need
to prevent the background retire worker from modifying our expected
state. To preserve the intent of symmetry, we apply this to both
i915_reset and i915_reset_engine, even though it strictly only affects
i915_reset_engine currently.
Lee Shawn C [Thu, 20 Jun 2019 15:44:16 +0000 (08:44 -0700)]
drm/i915: Check backlight type while doing eDP backlight initializaiton
If LFP backlight type setting from VBT was "VESA eDP AUX Interface".
Driver should check panel capability and try to initialize aux backlight.
No matter i915_modparams.enable_dpcd_backlight was enabled or not.
v2: access dev_priv->vbt.backlight.type directly and remove unused function.
v3: 1. Modify i915.enable_dpcd_backlight type from bool to int and give default
value as 0 (disable).
2. Add a judgement to check LFP backlight type was aux interface or not.
Chris Wilson [Tue, 25 Jun 2019 23:33:48 +0000 (00:33 +0100)]
drm/i915/gt: Drop stale commentary for timeline density
We no longer allocate a contiguous set of timeline ids for all engines
upon creation, so we no longer should assume that the timelines are
densely allocated within a context. Hopefully, the set of fences used
within a workload are still dense enough for us to take advantage of
the compressed radix tree used for the syncmap.
Chris Wilson [Tue, 25 Jun 2019 13:01:14 +0000 (14:01 +0100)]
drm/i915: Rename intel_wakeref_[is]_active
Our general rule is to use is/has as the verb for boolean functions,
rename intel_wakeref_active to intel_wakeref_is_active so the question
being asked is clear.
Robert M. Fosha [Tue, 25 Jun 2019 16:41:07 +0000 (09:41 -0700)]
drm/i915/guc: Add debug capture of GuC exception
Detect GuC firmware load failure due to an exception during execution
in GuC firmware. Output the GuC EIP where exception occurred to dmesg
for GuC debug information.
v2: correct typos, change debug message and error code returned for
GuC exception (Michal)
Signed-off-by: Robert M. Fosha <robert.m.fosha@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> 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/20190625164107.21512-1-robert.m.fosha@intel.com
Chris Wilson [Tue, 25 Jun 2019 13:01:09 +0000 (14:01 +0100)]
drm/i915/execlists: Convert recursive defer_request() into iterative
As this engine owns the lock around rq->sched.link (for those waiters
submitted to this engine), we can use that link as an element in a local
list. We can thus replace the recursive algorithm with an iterative walk
over the ordered list of waiters.
EHL can have up to one VECS(video enhancement) engine, so add it to
the device_info.
BSpec: 29152 Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190614213749.15870-1-jose.souza@intel.com
We got the wrong offsets (could they have changed?). New values were
computed off an error state by looking up the register offset in the
context image as written by the HW.
Kenneth Graunke [Tue, 25 Jun 2019 09:06:55 +0000 (10:06 +0100)]
drm/i915: Disable SAMPLER_STATE prefetching on all Gen11 steppings.
The Demand Prefetch workaround (binding table prefetching) only applies
to Icelake A0/B0. But the Sampler Prefetch workaround needs to be
applied to all Gen11 steppings, according to a programming note in the
SARCHKMD documentation.
Using the Intel Gallium driver, I have seen intermittent failures in
the dEQP-GLES31.functional.copy_image.non_compressed.* tests. After
applying this workaround, the tests reliably pass.
Chris Wilson [Mon, 24 Jun 2019 09:20:09 +0000 (10:20 +0100)]
drm/i915/execlists: Always clear ring_pause if we do not submit
In the unlikely case (thank you CI!), we may find ourselves wanting to
issue a preemption but having no runnable requests left. In this case,
we set the semaphore before computing the preemption and so must unset
it before forgetting (or else we leave the machine busywaiting until the
next request comes along and so likely hang).
v2: Replace readback with only a wmb after asserting the semaphore
Chris Wilson [Fri, 21 Jun 2019 21:57:33 +0000 (22:57 +0100)]
drm/i915/blt: Remove recursive vma->lock
As we have already plugged the w->dma into the reservation_object, and
have set ourselves up to automatically signal the request and w->dma on
completion, we do not need to export the rq->fence directly and just use
the w->dma fence.
This avoids having to take the reservation_lock inside the worker which
cross-release lockdep would complain about. :)
Chris Wilson [Fri, 21 Jun 2019 18:38:00 +0000 (19:38 +0100)]
drm/i915: Provide an i915_active.acquire callback
If we introduce a callback for i915_active that is only called the first
time we use the i915_active and is symmetrically paired with the
i915_active.retire callback, we can replace the open-coded and
non-atomic implementations -- which will be very fragile (i.e. broken)
upon removing the struct_mutex serialisation.
Chris Wilson [Fri, 21 Jun 2019 18:37:59 +0000 (19:37 +0100)]
drm/i915: Throw away the active object retirement complexity
Remove the accumulated optimisations that we have for i915_vma_retire
and reduce it to the bare essential of tracking the active object
reference. This allows us to only use atomic operations, and so will be
able to avoid the struct_mutex requirement.
The principal loss here is the shrinker MRU bumping, so now if we have
to shrink, we will do so in much more random order and more likely to
try and shrink recently used objects. That is a nuisance, but shrinking
active objects is a second step we try to avoid and will always be a
system-wide performance issue.
The other loss is here is in the automatic pruning of the
reservation_object when idling. This is not as large an issue as upon
reservation_object introduction as now adding new fences into the object
replaces already signaled fences, keeping the array compact. But we do
lose the auto-expiration of stale fences and unused arrays. That may be
a noticeable problem for which we need to re-implement autopruning.
Chris Wilson [Fri, 21 Jun 2019 18:37:58 +0000 (19:37 +0100)]
drm/i915: Track i915_active using debugobjects
Provide runtime asserts and tracking of i915_active via debugobjects.
For example, this should allow us to check that the i915_active is only
active when we expect it to be and is never freed too early.
One consequence is that, for simplicity, we no longer allow i915_active
to be on-stack which only affected the selftests.
Chris Wilson [Fri, 21 Jun 2019 18:37:57 +0000 (19:37 +0100)]
drm/i915: Remove waiting & retiring from shrinker paths
i915_gem_wait_for_idle() and i915_retire_requests() introduce a
dependency on the timeline->mutex. This is problematic as we want to
later perform allocations underneath i915_active.mutex, forming a link
between the shrinker, the timeline and active mutexes. Nip this cycle in
the bud by removing the acquisition of the timeline mutex (i.e.
retiring) from inside the shrinker.
drm/i915/guc: handle GuC messages received with CTB disabled
There is a very small chance of triggering a log flush event when
enabling or disabling CT buffers. Events triggered while CT buffers
are disabled are logged in the SCRATCH_15 register using the same bits
used in the CT message payload. Since our communication channel with
GuC is turned off, we can save the message and handle it after we turn
it back on.
GuC should be idle and not generate more events in the meantime because
we're not talking to it.
v2: clear the mmio register on stop_communication as well (Chris)
drm/i915/guc: reorder enable/disable communication steps
Make sure we always have CT buffers enabled when the interrupts are
enabled, so we can always handle interrupts from GuC. Also move the
setting of the guc->send and guc->handler functions to the GuC
communication control functions for consistency.
The reorder also fixes the onion unwinding of intel_uc_init_hw, because
guc_enable_communication would've left interrupts enabled when failing
to enable CTB.
v2: always retunr the result of ctch_enable() in
intel_guc_ct_enable() (Michal)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110943 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> Reviewed-by: Matthew Brost <matthew.brost@intel.com> 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/20190621182123.31368-1-daniele.ceraolospurio@intel.com
Chris Wilson [Fri, 21 Jun 2019 13:16:40 +0000 (14:16 +0100)]
drm/i915/gt: Fixup kerneldoc parameters
drivers/gpu/drm/i915/gt/intel_mocs.c:513: warning: Function parameter or member 'gt' not described in 'intel_mocs_init_l3cc_table'
drivers/gpu/drm/i915/gt/intel_mocs.c:513: warning: Excess function parameter 'dev_priv' description in 'intel_mocs_init_l3cc_table'
intel_vgt_balloon/deballoon, i915_ggtt_probe_hw intel_wopcm_init_hw need
similar treatment
Chris Wilson [Fri, 21 Jun 2019 13:16:39 +0000 (14:16 +0100)]
drm/i915/gt: Rename i915_gt_timelines
Since the anonymous i915_gt became struct intel_gt and encloses
struct i915_gt_timelines, rename i915_gt_timelines to intel_gt_timelines
to match its parentage.
Tvrtko Ursulin [Fri, 21 Jun 2019 07:08:11 +0000 (08:08 +0100)]
drm/i915: Eliminate dual personality of i915_scratch_offset
Scratch vma lives under gt but the API used to work on i915. Make this
consistent by renaming the function to intel_gt_scratch_offset and make
it take struct intel_gt.
Tvrtko Ursulin [Fri, 21 Jun 2019 07:08:05 +0000 (08:08 +0100)]
drm/i915: Compartmentalize i915_gem_init_ggtt
Continuing on the theme of better logical organization of our code, make
the first step towards making the ggtt code better isolated from wider
struct drm_i915_private.
v2:
* Bring the ickle onion unwind back. (Chris)
* Rename to i915_init_ggtt. (Chris)
Tvrtko Ursulin [Fri, 21 Jun 2019 07:08:04 +0000 (08:08 +0100)]
drm/i915: Compartmentalize i915_ggtt_cleanup_hw
Continuing on the theme of better logical organization of our code, make
the first step towards making the ggtt code better isolated from wider
struct drm_i915_private.
v2:
* Cleanup of mm.wc_stash does not need struct_mutex. (Chris)
Continuing on the theme of better logical organization of our code, make
the first step towards making the timeline code better isolated from wider
struct drm_i915_private.
Tvrtko Ursulin [Fri, 21 Jun 2019 07:08:01 +0000 (08:08 +0100)]
drm/i915: Convert i915_gem_flush_ggtt_writes to intel_gt
Having introduced struct intel_gt (named the anonymous structure in i915)
we can start using it to compartmentalize our code better. It makes more
sense logically to have the code internally like this and it will also
help with future split between gt and display in i915.
v2:
* Keep ggtt flush before fb obj flush. (Chris)
Having made start to better code compartmentalization by introducing
struct intel_gt, continue the theme elsewhere in code by making functions
take parameters take what logically makes most sense for them instead of
the global struct drm_i915_private.
Tvrtko Ursulin [Fri, 21 Jun 2019 07:07:57 +0000 (08:07 +0100)]
drm/i915: Compartmentalize i915_ggtt_init_hw
Having made start to better code compartmentalization by introducing
struct intel_gt, continue the theme elsewhere in code by making functions
take parameters take what logically makes most sense for them instead of
the global struct drm_i915_private.
Tvrtko Ursulin [Fri, 21 Jun 2019 07:07:56 +0000 (08:07 +0100)]
drm/i915: Compartmentalize i915_ggtt_probe_hw
Having made start to better code compartmentalization by introducing
struct intel_gt, continue the theme elsewhere in code by making functions
take parameters take what logically makes most sense for them instead of
the global struct drm_i915_private.
Tvrtko Ursulin [Fri, 21 Jun 2019 07:07:53 +0000 (08:07 +0100)]
drm/i915: Convert i915_gem_init_hw to intel_gt
More removal of implicit dev_priv from using old mmio accessors.
Actually the top level function remains but is split into a part which
writes to i915 and part which operates on intel_gt in order to initialize
the hardware.
GuC and engines are the only odd ones out remaining.
Tvrtko Ursulin [Fri, 21 Jun 2019 07:07:45 +0000 (08:07 +0100)]
drm/i915: Convert i915_gem_init_swizzling to intel_gt
Start using the newly introduced struct intel_gt to fuse together correct
logical init flow with uncore for more removal of implicit dev_priv in
mmio access.
projects / kernel.git / log