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
Lucas De Marchi [Mon, 8 Jul 2019 17:28:14 +0000 (10:28 -0700)]
drm/i915: move intel_ddi_set_fia_lane_count to intel_tc.c
PORT_TX_DFLEXDPMLE1 is a FIA register so move it to intel_tc.c where we
access other FIA registers. In Tiger Lake we have multiple/modular FIAs
so it makes sense to start moving all access to their registers to a
common place.
While at it, make it clear that we will only ever call this function
for ports with TC phy. Previously we were relying on tc_mode being
TC_PORT_TBT_ALT for combo phy ports. However it's confusing since in
this same function we have checks for is_tc_port. Also, if we manage to
make each phy access only their own field, we may in future add them as
a union inside intel_digital_port.
drm/i915/perf: add missing delay for OA muxes configuration
This was dropped from the original patch series, we weren't sure
whether it was needed at the time. More recent tests show it's
definitely needed to have acurate performance data.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 19f81df2859eb1 ("drm/i915/perf: Add OA unit support for Gen 8+") Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
[ickle: combine duplicate code and comments] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190710105524.23017-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 10 Jul 2019 06:44:41 +0000 (07:44 +0100)]
drm/i915/execlists: Record preemption for selftests
Put back the preemption counters lost in commit 22b7a426bbe1
("drm/i915/execlists: Preempt-to-busy") so that our selftests that
assert no preemption took place continue to function.
v2: But a timeslice is only a "soft" preemption!
Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190710064454.682-1-chris@chris-wilson.co.uk
drm/i915: add infrastructure to hold off preemption on a request
We want to set this flag in the next commit on requests containing
perf queries so that the result of the perf query can just be a delta
of global counters, rather than doing post processing of the OA
buffer.
drm/i915/perf: ensure we keep a reference on the driver
The i915 perf stream has its own file descriptor and is tied to
reference of the driver. We haven't taken care of keep the driver
alive.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Fixes: eec688e1420da5 ("drm/i915: Add i915 perf infrastructure") Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190709123351.5645-2-lionel.g.landwerlin@intel.com
Chris Wilson [Tue, 9 Jul 2019 08:17:18 +0000 (09:17 +0100)]
drm/i915/userptr: Don't mark readonly objects as dirty
If we map an object as readonly into the GTT, we know that the GPU
cannot have written to it and so the object is not dirty and we don't
need to flush the writes back to the system.
Imre Deak [Mon, 8 Jul 2019 14:07:35 +0000 (17:07 +0300)]
drm/i915/icl: Clear the shared port PLLs from the new crtc state
For consistency clear the icl_port_dplls from the new crtc state, when
releasing the DPLLs from the old crtc state. Leaving them set could
result in releasing the same PLLs multiple times from the same CRTC
state incorrectly (if the same CRTC was first used for a TypeC port then
for a combo PHY port).
Leaving the stale pointers behind happens not to cause a problem atm
(since the incorrect releasing will be a NOP), but we need to fix that
for consistency.
Ville Syrjälä [Wed, 19 Jun 2019 18:03:08 +0000 (21:03 +0300)]
drm/i915/sdvo: Use named initializers for the SDVO command names
Use named initializers to make it easier to associate the SDVO debug
prints with the SDVO command defines. Also switch to using ARRAY_SIZE()
instead of assuming that SDVO_CMD_STATUS_SCALING_NOT_SUPP is the last
command type.
Chris Wilson [Mon, 8 Jul 2019 14:03:27 +0000 (15:03 +0100)]
drm/i915/userptr: Acquire the page lock around set_page_dirty()
set_page_dirty says:
For pages with a mapping this should be done under the page lock
for the benefit of asynchronous memory errors who prefer a
consistent dirty state. This rule can be broken in some special
cases, but should be better not to.
Under those rules, it is only safe for us to use the plain set_page_dirty
calls for shmemfs/anonymous memory. Userptr may be used with real
mappings and so needs to use the locked version (set_page_dirty_lock).
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203317 Fixes: 5cc9ed4b9a7a ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl")
References: 6dcc693bc57f ("ext4: warn when page is dirtied without buffers") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190708140327.26825-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 8 Jul 2019 15:23:21 +0000 (16:23 +0100)]
drm/i915/selftests: Reorder error cleanup for whitelist checking
Reorder the error paths so that we unwind all the locals from any error
path and so avoid setting off divers alarum in case we find an error in
case we find an error.
Chris Wilson [Sun, 7 Jul 2019 15:11:35 +0000 (16:11 +0100)]
drm/i915: Pull assert_forcewake_active() underneath the lock
Make no assumption that something in the background is not acquiring the
fw_domain -- but we still do not track owner so assume that any active
domain is intended by the caller.
Mika Kuoppala [Fri, 5 Jul 2019 21:52:03 +0000 (22:52 +0100)]
drm/i915/gtt: Setup phys pages for 3lvl pdps
If we setup backing phys page for 3lvl pdps, as they
are not used, we will lose 5 pages per ppgtt.
Trading this memory on bsw, we gain more common code paths for all
gen8+ directory manipulation. And those paths are now void of checks
for page directory type, making the hot paths faster.
Mika Kuoppala [Fri, 5 Jul 2019 21:52:02 +0000 (22:52 +0100)]
drm/i915/gtt: Tear down setup and cleanup macros for page dma
We don't use common codepaths to setup and cleanup page
directories vs page tables. So their setup and cleanup macros
are of no use and can be removed.
Mika Kuoppala [Fri, 5 Jul 2019 21:52:01 +0000 (22:52 +0100)]
drm/i915/gtt: pde entry encoding is identical
For all page directory entries, the pde encoding is
identical. Don't complicate call sites with different
versions of doing the same thing, so we always check the
existence of physical page before writing the entry into
it. This further generalizes the pd so that manipulation in
callsites will be identical, removing the need to handle
pdps differently for gen8.
drm/i915: Remove set but not used variable 'intel_dig_port'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/i915/display/intel_ddi.c: In function 'intel_ddi_get_config':
drivers/gpu/drm/i915/display/intel_ddi.c:3774:29: warning:
variable 'intel_dig_port' set but not used [-Wunused-but-set-variable]
struct intel_digital_port *intel_dig_port;
drm/i915: Remove set but not used variable 'encoder'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/i915/display/intel_dp.c: In function 'intel_dp_set_drrs_state':
drivers/gpu/drm/i915/display/intel_dp.c:6623:24: warning:
variable 'encoder' set but not used [-Wunused-but-set-variable]
It's never used, so can be removed.Also remove related
variable 'dig_port'
Chris Wilson [Fri, 5 Jul 2019 07:45:57 +0000 (08:45 +0100)]
drm/i915: Order assert forcewake test
Read the current value before computing the expected to ensure that if
the timer does complete early (against our will), it should not cause a
false positive.
v2: The local irq disable did not prevent the timer from running.
This patch adds support for DPLL4 on EHL that include the
following restrictions:
- DPLL4 cannot be used with DDIA (combo port A internal eDP usage).
DPLL4 can be used with other DDIs, including DDID
(combo port A external usage).
- DPLL4 cannot be enabled when DC5 or DC6 are enabled.
- The DPLL4 enable, lock, power enabled, and power state are connected
to the MGPLL1_ENABLE register.
v2: (suggestions from Bob Paauwe)
- Rework ehl_get_dpll() function to call intel_find_shared_dpll() and
iterate twice: once for Combo plls and once for MG plls.
- Use MG pll funcs for DPLL4 instead of creating new ones and modify
mg_pll_enable to include the restrictions for EHL.
v3: Fix compilation error
v4: (suggestions from Lucas and Ville)
- Treat DPLL4 as a combo phy PLL and not as MG PLL
- Disable DC states when this DPLL is being enabled
- Reuse icl_get_dpll instead of creating a separate one for EHL
v5: (suggestion from Ville)
- Refcount the DC OFF power domains during the enabling and disabling
of this DPLL.
v6: rebase
v7: (suggestion from Imre)
- Add a new power domain instead of iterating over the domains
assoicated with DC OFF power well.
v8: (Ville and Imre)
- Rename POWER_DOMAIN_DPLL4 TO POWER_DOMAIN_DPLL_DC_OFF
- Grab a reference in intel_modeset_setup_hw_state() if this
DPLL was already enabled perhaps by BIOS.
- Check for the port type instead of the encoder
v9: (Ville)
- Move the block of code that grabs a reference to the power domain
POWER_DOMAIN_DPLL_DC_OFF to intel_modeset_readout_hw_state() to ensure
that there is a reference present before this DPLL might get disabled.
v10: rebase
Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.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> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190703230353.24059-1-vivek.kasireddy@intel.com
Ville Syrjälä [Wed, 3 Jul 2019 20:08:24 +0000 (23:08 +0300)]
drm/i915: Clean up skl vs. icl plane formats
Split the format lists for different planes on skl/icl more cleanly.
On skl+ we have just two types of planes: those can do planar and
those that can't.
On icl we have three types of planes: hdr planes, sdr planes that
can do planar, and sdr planes that can't do planar. Those latter two
are the same set of planes we must when choose from when picking the
UV vs. Y plane for planar scanout. So we shall just designate
them sdr uv planes and sdr y planes.
Ville Syrjälä [Wed, 3 Jul 2019 20:08:22 +0000 (23:08 +0300)]
drm/i915: Deal with cpp==8 for g4x watermarks
Docs tell us that on g4x we have to compute the SR watermarks
using 4 bytes per pixel. I'm going to assume that only applies
to 1 and 2 byte per pixel formats, and not 8 byte per pixel
formats. That seems like a recipe for an insufficient watermark
which could lead to underruns. Use the maximum of the two numbers
instead.
Ville Syrjälä [Wed, 3 Jul 2019 20:08:21 +0000 (23:08 +0300)]
drm/i915: Program plane gamma ramps
All sprite planes have a progammable gamma ramp. Set it up with
a linear ramp on all platforms. This actually matches the reset
value but soon we'll want to reprogram this ramp on some machines,
so let's just set it up across the board.
Note that on pre-IVB the hardware bypasses the gamma unit
unless a YCbCr pixel format is used.
v2: Add parens around << in ilk_linear_gamma()
Skip gamma programming for RGB on pre-IVB
s/DVSGAMC/DVSGAMC_G4X/
Ville Syrjälä [Wed, 3 Jul 2019 20:08:19 +0000 (23:08 +0300)]
drm/i915: Add windowing for primary planes on gen2/3 and chv
Plane B and C (note that we don't actually expose plane C currently)
on gen2/3 have a window generator, as does the primary plane on CHV
pipe B. So let's allow positioning of these planes freely within the
pipe source area.
Plane A on gen2/3 seems to have some kind of partial window generator
which would allow you to cut the plane off midway through the scanout,
but it would still have to start at the top-left corner of the pipe,
and it would have to be full width. That's doesn't sound all that
useful, so for simplicity let's just keep to the idea that plane A
has to be fullscreen.
Gen4 removed the plane A/B windowing support entirely, and it wasn't
reintroduced until SKL (apart from the CHV pipe B special case).
v2: s/plane/i9xx_plane/ etc. (James)
v3: Make it less confusing
v4: Deal with IS_GEN()
drm/i915: Rework some interrupt handling functions to take intel_gt
Some interrupt handling functions already have gt in their names
suggesting them as obvious candidates to make them take struct intel_gt
instead of i915.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Co-developed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190704121756.27824-1-tvrtko.ursulin@linux.intel.com
Chris Wilson [Thu, 4 Jul 2019 20:04:55 +0000 (21:04 +0100)]
drm/i915: Show instdone for each engine in debugfs
Although polling each engine quickly is preferable as it should give us
a sample of each engine at roughly the same time, keep it simple and
just sample the engine as print out the debug state.
Chris Wilson [Thu, 4 Jul 2019 21:23:43 +0000 (22:23 +0100)]
drm/i915/selftests: Be engine agnostic
When using MI operations, we do not care which engine we use, so use
them all where possible, and where inconvenient double check we have the
engine we selected at random.
v2: Drop the local copy of engine->sseu to avoid an unchecked deref
Chris Wilson [Thu, 4 Jul 2019 20:04:53 +0000 (21:04 +0100)]
drm/i915/overlay: Stash the kernel context on initialisation
Simplify runtime request creation by storing the context we need to use
during initialisation. This allows us to remove one more hardcoded
engine lookup.
drm/i915/hangcheck: Look at instdone for all engines
It seems intel_engine_get_instdone is able to get instdone for all engines
but intel_hangcheck.c/subunits_stuck decides to ignore it for non render.
We can just drop the check in subunits_stuck since the checks on
unavailable fields will always return stuck, which when bitwise and with
the potential unstuck instdone is harmless.
Chris Wilson [Thu, 4 Jul 2019 16:53:17 +0000 (17:53 +0100)]
drm/i915/selftests: Drain the freedlists between exec passes
During the context execution tests, we issue a lot of work and discard a
lot of objects without releasing the lock and allowing the background
reaper to free those objects. Insert a small break between each pass to
flush the worker.
Fixes: 1d1b5490b91c ("drm/i915/gtt: Replace struct_mutex serialisation for allocation") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190704201656.15775-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 3 Jul 2019 13:58:05 +0000 (14:58 +0100)]
drm/i915/gt: Pull engine w/a initialisation into common
We need to setup the workarounds on all engines, with the knowledge
about which platforms each workaround applies to kept together in the
workaround list. As such, we can pull the w/a initialisation into the
common setup and try to avoid duplicating knowledge about when to setup
the workarounds.
Chris Wilson [Thu, 4 Jul 2019 10:43:45 +0000 (11:43 +0100)]
drm/i915/gtt: Handle double alloc failures
Matthew pointed out that we could face a double failure with concurrent
allocations/frees, and so the assumption that the local var alloc was
NULL was fraught with danger. Rather than complicate the error paths too
much to add a second local for a second free, just do the second free
earlier on the unwind path.
Chris Wilson [Wed, 3 Jul 2019 18:06:01 +0000 (19:06 +0100)]
drm/i915/gem: Defer obj->base.resv fini until RCU callback
Since reservation_object_fini() does an immediate free, rather than
kfree_rcu as normal, we have to delay the release until after the RCU
grace period has elapsed (i.e. from the rcu cleanup callback) so that we
can rely on the RCU protected access to the fences while the object is a
zombie.
i915_gem_busy_ioctl relies on having an RCU barrier to protect the
reservation in order to avoid having to take a reference and strong
memory barriers.
v2: Order is important; only release after putting the pages!
Chris Wilson [Wed, 3 Jul 2019 15:52:25 +0000 (16:52 +0100)]
drm/i915/gt: Ignore forcewake acquisition for posting_reads
We don't care about the result of the read, so it may be garbage, we
only care that the mmio is flushed. As such, we can forgo using an
individual forcewake and lock around any posting-read for an engine.
Chris Wilson [Wed, 3 Jul 2019 15:52:24 +0000 (16:52 +0100)]
drm/i915/gt: Assume we hold forcewake for execlists resume
We can assume the caller is holding a blanket forcewake for the
register writes during resume, and so we can skip taking individual
locks around each write inside execlists resume.