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
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: 4c2fae652a4a73 ("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 c7e4d40378c6
("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: c7e4d40378c6 ("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: 41b38c4f4ec517 ("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: 1944115857b2 ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl")
References: af4685341733 ("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.
projects / kernel.git / log