Driver had discrepancy in how cdclk squash and crawl support
were checked. Like crawl, add squash as a 1 bit feature flag
to the display section of DG2.
Not all Dekel PHY registers have a lane instance, so having to specify
this when using them is awkward. It makes more sense to define each PHY
register with its full internal PHY offset where bits 15:12 is the lane
for lane-instanced PHY registers and just a register bank index for other
PHY registers. This way lane-instanced registers can be referred to with
the (tc_port, lane) parameters, while other registers just with a tc_port
parameter.
An additional benefit of this change is to prevent passing a Dekel
register to a generic MMIO access function or vice versa.
v2:
- Fix parameter reuse in the DKL_REG_MMIO definition.
v3:
- Rebase on latest patchset version.
Imre Deak [Tue, 25 Oct 2022 10:26:42 +0000 (13:26 +0300)]
drm/i915: Rename intel_tc_phy_regs.h to intel_mg_phy_regs.h
An upcoming patch moves the DKL PHY register definitions to
intel_dkl_phy_regs.h, so for consistency rename intel_tc_phy_regs.h
containing only MG PHY register definitions to intel_mg_phy_regs.h.
Imre Deak [Tue, 25 Oct 2022 11:44:55 +0000 (14:44 +0300)]
drm/i915/tgl+: Add locking around DKL PHY register accesses
Accessing the TypeC DKL PHY registers during modeset-commit,
-verification, DP link-retraining and AUX power well toggling is racy
due to these code paths being concurrent and the PHY register bank
selection register (HIP_INDEX_REG) being shared between PHY instances
(aka TC ports) and the bank selection being not atomic wrt. the actual
PHY register access.
Add the required locking around each PHY register bank selection->
register access sequence.
Kudos to Ville for noticing the race conditions.
v2:
- Add the DKL PHY register accessors to intel_dkl_phy.[ch]. (Jani)
- Make the DKL_REG_TC_PORT macro independent of PHY internals.
- Move initing the DKL PHY lock to a more logical place.
v3:
- Fix parameter reuse in the DKL_REG_TC_PORT definition.
- Document the usage of phy_lock.
v4:
- Fix adding TC_PORT_1 offset in the DKL_REG_TC_PORT definition.
Ville Syrjälä [Mon, 24 Oct 2022 16:15:14 +0000 (19:15 +0300)]
drm/i915: Stop loading linear degamma LUT on glk needlessly
Make glk_load_luts() a bit lighter for the common case
where neither the degamma LUT nor pipe CSC are enabled
by not loading the linear degamma LUT. Making .load_luts()
as lightweight as possible is a good idea since it may need
to execute from a vblank worker under tight deadlines.
My earlier reasoning for always loading the linear degamma LUT
was to avoid an extra LUT load when just enabling/disabling the
pipe CSC, but that is nonsense since we load the LUTs on every
flagged color management change/modeset anyway (either of which
is needed for a pipe CSC toggle).
We can also get rid of the glk_can_preload_luts() special
case since the presence of the degamma LUT will now always
match csc_enable.
Ville Syrjälä [Mon, 24 Oct 2022 16:15:13 +0000 (19:15 +0300)]
drm/i915: Get rid of glk_load_degamma_lut_linear()
Since we now have a place (pre_csc_lut) to stuff a purely
internal LUT we can replace glk_load_degamma_lut_linear()
with such a thing and just rely on the normal
glk_load_degamma_lut() to load it as well.
drm_mode_config_cleanup() will clean this up for us.
v2: Pass on the error pointer
Drop a hint about this into the state dump
Ville Syrjälä [Mon, 24 Oct 2022 16:15:12 +0000 (19:15 +0300)]
drm/i915: Assert {pre,post}_csc_lut were assigned sensibly
Since we now have the extra step from hw.(de)gamma_lut into
{pre,post}_csc_lut let's make sure we didn't forget to assign
them appropriately. Ie. basically making sure intel_color_check()
was called when necessary (and that it did its job suitable well).
Add an extra remapping step between the logical state of the LUTs
(hw.(de)gamma_lut) as specified via uapi/bigjoiner copy vs.
the actual state of the LUTs programmed into the hardware.
With this we should be finally able finish the (de)gamma
readout/state checker support for the remaining platforms
(ilk-skl) where the same hardware LUT can be positioned
either before or after the pipe CSC unit. Where we position
it depends on factors such as presence of the logical degamma
LUT, RGB vs. YCbCr output, full vs. limited RGB quantization
range.
Without the extra remapping step the state readout doesn't
really know whether the LUT read from the hardware is the
degamma or gamma LUT, and so we is unable to accurately store
it into our crtc state. With the remapping step we know
exactly where to put it given the order of the LUT vs. CSC
in the hardware state.
Only the initial hw->uapi state readout done during driver
load/resume still has the problem of not really knowing
what to do with the LUT(s). But we can just assume 1:1
mapping there and let subsequent commits fix things up.
Another benefit is that we now have a place for purely
internal LUTs, without complicating the bigjoiner uapi->hw
copy logic. This should prove useful for streamlining
glk degamma LUT handling.
Ville Syrjälä [Mon, 24 Oct 2022 16:15:10 +0000 (19:15 +0300)]
drm/i915: Make ilk_load_luts() deal with degamma
Make ilk_load_luts() ready for a degamma lut. Currently we never
have one, but soon we may get one from readout, and I think we
may want to change the state computation such that we may end up
with one even when userspace has simply supplied a gamma lut.
At least the code now follows the path laid out by the ivb/bdw
counterpars.
Ville Syrjälä [Fri, 21 Oct 2022 16:24:41 +0000 (19:24 +0300)]
drm/i915: Don't flag both full modeset and fastset at the same time
Be consistent in whether we flag a full modeset or a
fastset for the pipe. intel_modeset_all_pipes() would
seem to be the only codepath not getting this right.
The other case is when we flag the fastset initially,
currently we just clear the mode_changed flag and set
the update_pipe flag. But we could still have
connectors_changed==true or active_changed==true forcing
a full modeset anyway. So check for that after clearing
the mode_changed flag.
And let's add a WARN to make sure we did get it right.
Ville Syrjälä [Fri, 21 Oct 2022 16:24:39 +0000 (19:24 +0300)]
drm/i915: Introduce intel_crtc_needs_fastset()
Replace the somewhat obscure crtc_state.update_pipe checks
with a more descriptive thing. Also nicely matches the
intel_crtc_needs_modeset() counterpart for full modesets.
Ville Syrjälä [Thu, 20 Oct 2022 12:07:06 +0000 (15:07 +0300)]
drm/i915: Activate DRRS after state readout
On BDW+ we have just the one set of DP M/N registers. The
values we write into said registers depends on whether we
want DRRS to be in high or low gear. This causes issues
for the state checker which currently has to assume either
set of M/N (high or low refresh rate) values may appear there.
That sort of works for M/N itself, but all other values
derived from the M/N (dotclock, pixel rate) are not handled
correctly, leading to potential for state checker mismatches.
Let's avoid all those problems by simply keeping DRRS in
high gear until the state checker has done its hardware
state readout.
Note that hitting this issue presumable became very hard
after commit 1b333c679a0f ("drm/i915: Do DRRS disable/enable
during pre/post_plane_update()") since the state check would
have to laze about for one full second (delay used by
intel_drrs_schedule_work()) to see the low refresh rate.
But it is still theoretically possible.
Ville Syrjälä [Thu, 20 Oct 2022 09:39:38 +0000 (12:39 +0300)]
drm/i915: Allow panel fixed modes to have differing sync polarities
Apparently some panels declare multiple modes with random
sync polarities. Seems a bit weird, but looks like Windows/GOP
doesn't care, so let follow suit and accept alternate fixed
modes regardless of their sync polarities.
v2: Don't pollute the DRM_ namespace with a define (Jani)
Ankit Nautiyal [Tue, 11 Oct 2022 06:34:40 +0000 (12:04 +0530)]
drm/i915/dp: Reset frl trained flag before restarting FRL training
For cases where DP has HDMI2.1 sink and FRL Link issues are detected,
reset the flag to state FRL trained status before restarting FRL
training.
Fixes: 9488a030ac91 ("drm/i915: Add support for enabling link status and recovery") Cc: Swati Sharma <swati2.sharma@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> (v2) Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221011063447.904649-2-ankit.k.nautiyal@intel.com
Anshuman Gupta [Fri, 14 Oct 2022 11:32:58 +0000 (17:02 +0530)]
drm/i915/dgfx: Keep PCI autosuspend control 'on' by default on all dGPU
DGFX platforms has lmem and cpu can access the lmem objects
via mmap and i915 internal i915_gem_object_pin_map() for
i915 own usages. Both of these methods has pre-requisite
requirement to keep GFX PCI endpoint in D0 for a supported
iomem transaction over PCI link. (Refer PCIe specs 5.3.1.4.1)
Both DG1/DG2 have a known hardware bug that violates the PCIe specs
and support the iomem read write transaction over PCIe bus despite
endpoint is D3 state.
Due to above H/W bug, we had never observed any issue with i915 runtime
PM versus lmem access.
But this issue becomes visible when PCIe gfx endpoint's upstream
bridge enters to D3, at this point any lmem read/write access will be
returned as unsupported request. But again this issue is not observed
on every platform because it has been observed on few host machines
DG1/DG2 endpoint's upstream bridge does not bind with pcieport driver.
which really disables the PCIe power savings and leaves the bridge
at D0 state.
We need a unique interface to read/write from lmem with runtime PM
wakeref protection something similar to intel_uncore_{read, write},
keep autosuspend control to 'on' on all discrete platforms,
until we have a unique interface to read/write from lmem.
This just change the default autosuspend setting of i915 on dGPU,
user can still change it to 'auto'.
v2:
- Modified the commit message and subject with more information.
- Changed the Fixes tag to LMEM support commit. [Joonas]
- Changed !HAS_LMEM() Cond to !IS_DGFX(). [Rodrigo]
Andrzej Hajda [Mon, 17 Oct 2022 08:55:25 +0000 (10:55 +0200)]
drm/i915: fix clear mask in GEN7_MISCCPCTL update
GEN7_DOP_CLOCK_GATE_ENABLE bit should be cleared, not inverse.
The bug was introduced during conversion to intel_uncore_rmw helper.
Suggested-by: Matt Roper <matthew.d.roper@intel.com> Fixes: 8cee664d3eb6f8 ("drm/i915: use proper helper for register updates") Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221017085525.3898649-1-andrzej.hajda@intel.com
Radhakrishna Sripada [Tue, 11 Oct 2022 15:38:51 +0000 (08:38 -0700)]
drm/i915: Use graphics ver, rel info for media on old platforms
Platforms prior to MTL do not have a separate media and graphics version.
On platforms where GMD id is not supported, reuse the graphics ip version,
release info for media.
The rest of the IP graphics, display versions would be copied during driver
creation.
While at it warn if GMD is not used for platforms greater than gen12.
v2:
- Use simple assignment to copy contents of the structure(JaniN)
Fixes: c2c7075225ef ("drm/i915: Read graphics/media/display arch version from hw") Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221011153851.3781507-2-radhakrishna.sripada@intel.com
The GPU reset involves a display suspend/resume sequence, but this is
done without suspending/resuming the encoders. The encoder HW readout
code during resume however assumes that the encoders were
suspended/resumed, at least on TypeC platforms where the TC PHYs must be
left in a disconnected state during encoder-suspend, and the PHY's TypeC
mode must be initialized already during encoder-resume.
Since the above issue occurs only in case the display recovery during
GPU reset is simulated in CI tests (on new platforms w/o the GPU reset
clobbering the display), this patch fixes the issue by simply restoring
the saved display state in this case w/o doing a display HW state
readout / sanitization first. This also fixes the WARN below introduced
by
commit a82796a2e332 ("drm/i915: Fix TypeC mode initialization during system resume")
Anusha Srivatsa [Mon, 10 Oct 2022 20:21:35 +0000 (13:21 -0700)]
drm/i915/display: Add DC5 counter and DMC debugfs entries for MTL
MTL and dgfx use the same DC5 counter.
While at it, this patch also adds the corresponding
debugfs entries. Some cleanup wrt dc3co register
which makes the code more readable.
Driver loads all firmware that it finds in the firmware
binary but platform doesn't *need* all of them. Cleaning the
previous debugs entries to reflect which firmware is needed
and if the needed firmware is loaded or not.
MTL needs both Pipe A and Pipe B DMC to be loaded
along with Main DMC.
Andrzej Hajda [Thu, 6 Oct 2022 16:31:59 +0000 (18:31 +0200)]
drm/i915: make intel_uncore_rmw() write unconditionally
Two small changes in intel_uncore_rmw will allow to use it more broadly:
- write register unconditionally, for use with latch registers,
- return old value of the register, IRQ cleanup and similar.
If we really want to keep write-only-if-changed feature maybe other
helper will be more suitable for it, intel_uncore_rmw name suggests
unconditional write.
Ville Syrjälä [Fri, 7 Oct 2022 21:11:08 +0000 (00:11 +0300)]
drm/i915: Enable atomic by default on ctg/elk
The watermark code for ctg/elk has been atomic ready for a long time
so let's just flip the switch now that some of the last CxSR issues
have been sorted out (which granted was a problem for vlv/chv as well
despite them already having atomic enabled by default).
Ville Syrjälä [Fri, 7 Oct 2022 21:11:07 +0000 (00:11 +0300)]
drm/i915: Do the DRIVER_ATOMIC feature disable later
Currently we do the DRIVER_ATOMIC disable as almost the
first thing during pci probe. That involves the use of
DISPLAY_VER() which is perhaps a bit sketchy now that we
may need to read that out from the hardware itself.
Looks like we do populate a default value for it anyway
so the current does at least still work.
But let's make this safer anyway and move the code
into intel_device_info_runtime_init() where we also
handle the same thing for the !HAS_DISPLAY case.
Ville Syrjälä [Wed, 22 Jun 2022 15:54:51 +0000 (18:54 +0300)]
drm/i915: Write watermarks for disabled pipes on gmch platforms
We've excluded gmch platforms from writing the final watermarks
for any disabled pipe. IIRC the reason was perhaps some lingering
issue with the watermark merging across the pipes. But I can't
really see any reason for this anymore, so let's unify this behaviour.
The main benefit being more consistency in register dumps when
we don't have stale watermarks hanging around in the registers.
Functionally there should be no difference as the hardware just
ignore all of it when the pipe is disabled.
Ville Syrjälä [Wed, 22 Jun 2022 15:54:50 +0000 (18:54 +0300)]
drm/i915: Fix pipe gamma enable/disable vs. CxSR on gmch platforms
Like most other plane control register bits, the pipe gamma
enable bit is also blocked by CxSR. So make sure we kick the
machine out of CxSR before trying to change that bit.
Ville Syrjälä [Wed, 22 Jun 2022 15:54:49 +0000 (18:54 +0300)]
drm/i915: Fix g4x/vlv/chv CxSR vs. format/tiling/rotation changes
On g4x/vlv/chv the hardware seems incapable of changing the pixel
format, rotation, or YUV->RGB CSC matrix while in CxSR.
Additionally on VLV/CHV the sprites seem incapable of tiling
changes while in CxSR. On g4x CxSR is not even possible with
the sprite enabled. Curiously the primary plane seems perfectly
happy when changing tiling during CxSR.
Pimp up the code to account for these when determining whether
CxSR needs to be disabled. Since it looks like most of the plane
control register bits are affected let's just compare that.
But in the name of efficiency we'll make an exception for the
primary plane tiling changes (avoids some extra vblank waits).
v2: Just use the pre-computed plane control register values
Ville Syrjälä [Tue, 4 Oct 2022 15:09:29 +0000 (18:09 +0300)]
drm/i915: Clean up some namespacing
Rename a few functions from intel_crtc_foo_init() to
intel_foo_crtc_init() so that the namespaec clearly
indicates what feature/file we're talking about.
I left out intel_crtc_crc_init() because the whole crc
stuff uses intel_crtc_ as its namespace currently.
Radhakrishna Sripada [Wed, 5 Oct 2022 00:20:13 +0000 (17:20 -0700)]
drm/i915/mtl: Add MTP ddc pin configuration
Meteorlake PCH reuses Alderlake vbt, DE pin mapping. Extend
ADL-P pin mapping for Meteorlake.
Bspec: 20124 does not have the mapping for MTP. Based on Bspec:49306, 64051,
it is concluded that MTP and ADL-P PCH have the same vbt -> DE pin pair mapping.
José Roberto de Souza [Wed, 7 Sep 2022 08:15:43 +0000 (11:15 +0300)]
drm/i915/mtl: Extend PSR support
Meteorlake and display 14 platform don't have any PSR differences
when comparing to Alderlake-P display, so it was only necessary to
extend some checks to properly program hardware.
BSpec: 55229, 49196
Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220907081543.92268-1-mika.kahola@intel.com
Ville Syrjälä [Mon, 3 Oct 2022 11:32:49 +0000 (14:32 +0300)]
drm/i915: Setup final panel drrs_type already during init
Now that we track the VBT drrs type per-panel we can move the
has_drrs_modes() check to the panel init rather than doing it
for every intel_panel_drrs_type() call.
Ville Syrjälä [Mon, 3 Oct 2022 11:32:46 +0000 (14:32 +0300)]
drm/i915: Make DRRS debugfs per-crtc/connector
Since I already broke anything that relied on the old contents
of the DRRS debugfs files might as well finish the breakage
and convert the files to be per-crtc/connector so we don't need
to have annoying code in igt to parse these.
Ville Syrjälä [Mon, 3 Oct 2022 11:32:45 +0000 (14:32 +0300)]
drm/i915: Make the DRRS debugfs contents more consistent
The stuff in the DRRS debugs is currently a hodgepode mix
of camelcase, lowercase, spaces, undescores, you name it.
Convert over to a reasonably common style.
Also move the busy bits thing to be the last sine it's
generally the least interesting thing in there.
Ville Syrjälä [Tue, 27 Sep 2022 18:24:55 +0000 (21:24 +0300)]
drm/i915: Reject excessive dotclocks early
Make sure modes with crazy big dotclocks are rejected early,
so as to not cause problems for subsequent code via integer
overflows and whatnot.
These would eventually be rejected in intel_crtc_compute_pipe_mode()
but that is now too late as we do the clock computations a bit
earlier than that. And we don't want to just reorder the two since
we still want to check the final computed dotclock against the
hardware limit to make sure we didn't end up above the limit due
to rounding/etc.
Ville Syrjälä [Mon, 3 Oct 2022 11:15:43 +0000 (14:15 +0300)]
drm/i915: Fix watermark calculations for DG2 CCS+CC modifier
Take the DG2 CCS+CC modifier into account when calculating the
watermarks. Othwerwise we'll calculate the watermarks thinking this
tile-4 modifier is linear.
The rc_surface part is actually a nop since that is not used
for any glk+ platform.
Ville Syrjälä [Mon, 3 Oct 2022 11:15:42 +0000 (14:15 +0300)]
drm/i915: Fix watermark calculations for DG2 CCS modifiers
Take the DG2 CCS modifiers into account when calculating the
watermarks. Othwerwise we'll calculate the watermarks thinking these
tile-4 modifiers are linear.
The rc_surface part is actually a nop since that is not used
for any glk+ platform.
Ville Syrjälä [Mon, 3 Oct 2022 11:15:41 +0000 (14:15 +0300)]
drm/i915: Fix watermark calculations for gen12+ CCS+CC modifier
Take the gen12+ CCS+CC modifier into account when calculating the
watermarks. Othwerwise we'll calculate the watermarks thinking this
Y-tiled modifier is linear.
The rc_surface part is actually a nop since that is not used
for any glk+ platform.
Ville Syrjälä [Mon, 3 Oct 2022 11:15:40 +0000 (14:15 +0300)]
drm/i915: Fix watermark calculations for gen12+ MC CCS modifier
Take the gen12+ MC CCS modifier into account when calculating the
watermarks. Othwerwise we'll calculate the watermarks thinking this
Y-tiled modifier is linear.
The rc_surface part is actually a nop since that is not used
for any glk+ platform.
Ville Syrjälä [Mon, 3 Oct 2022 11:15:39 +0000 (14:15 +0300)]
drm/i915: Fix watermark calculations for gen12+ RC CCS modifier
Take the gen12+ RC CCS modifier into account when calculating the
watermarks. Othwerwise we'll calculate the watermarks thinking this
Y-tiled modifier is linear.
The rc_surface part is actually a nop since that is not used
for any glk+ platform.
Jouni Högander [Mon, 3 Oct 2022 07:20:11 +0000 (10:20 +0300)]
drm/i915/psr: Fix PSR_IMR/IIR field handling
Current PSR code is supposed to use TRANSCODER_EDP to force 0 shift for
bits in PSR_IMR/IIR registers:
/*
* gen12+ has registers relative to transcoder and one per transcoder
* using the same bit definition: handle it as TRANSCODER_EDP to force
* 0 shift in bit definition
*/
At the time of writing the code assumption "TRANSCODER_EDP == 0" was made.
This is not the case and all fields in PSR_IMR and PSR_IIR are shifted
incorrectly if DISPLAY_VER >= 12.
Fix this by adding separate register field defines for >=12 and add bit
getter functions to keep code readability.
v4:
- Remove EDP from TGL definitions (José)
- Use REG_BIT and REG_GENMASK (José)
v3:
- Add separate register field defines (José)
- Add bit getter functions (José)
v2:
- Improve commit message (José)
Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Fixes: 8241cfbe67f4 ("drm/i915/tgl: Access the right register when handling PSR interruptions") Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221003072011.72408-1-jouni.hogander@intel.com
Ville Syrjälä [Thu, 29 Sep 2022 07:15:12 +0000 (10:15 +0300)]
drm/i915: Remove PLL asserts from .load_luts()
.load_luts() potentially runs from the vblank worker, and is
under a deadline to complete within the vblank. Thus we can't
do expesive stuff like talk to the Punit, etc.
To that end get rid of the assert_dsi_pll_enabled() call for
vlv/chv. We'll just have to trust that the PLL is already enabled
here.
And I don't think the normal assert_pll_enabled() really buys us
anything useful on gmch platforms either, so nuke that one too.
We don't have corresponding asserts in the ilk+ codepaths anyway
despite the hardware (IIRC) still requiring the clock to be
enabled when we access the LUT.
Ville Syrjälä [Tue, 27 Sep 2022 18:06:15 +0000 (21:06 +0300)]
drm/i915: Allow alternate fixed modes always for LVDS
As with eDP let's stop considering the VBTs DRRS knobs and
just always accept all otherwise suitable EDID modes. This
appears to be how Windows does it.
Ville Syrjälä [Tue, 27 Sep 2022 18:06:14 +0000 (21:06 +0300)]
drm/i915: Allow alternate fixed modes always for eDP
Stop considering VBT's static DRRS support when deciding whether
to use alternate fixed modes or not. It looks like Windows more
or less just uses that to decide whether to automagically switch
refresh rates on AC<->battery changes, or perhaps whether to
even expose a control for that in some UI thing. Either way it
seems happy to always use all EDID modes, and I guess the
DRRS/VRR stuff more or less adjusts how said modes get
actually used.
Let's do the same and just accept all the suitable looking
modes from EDID, whether we have DRRS or VRR.
Since commit a5810f551d0a ("drm/i915: Allow more varied alternate
fixed modes for panels") intel_panel_add_edid_alt_fixed_modes()
no longer considers vrr vs. drrs separately. So no reason to
pass them as separate parameters either.
Ville Syrjälä [Mon, 26 Sep 2022 19:30:21 +0000 (22:30 +0300)]
drm/i915: Round to closest in g4x+ HDMI clock readout
On pre-ddi platforms we have slightly different code being
used for HDMI TMDS clock to dotclock conversion between the
state computation and state readout. Both of these need to
round the same way in order to not get a mismatch between
the computed and read out states. Fix up the rounding
direction in the readout path to match what is used during
state computation.
Another option would to just use intel_crtc_dotclock()
in the readout path as well, but I don't really want to
do that as the current code more accurately represents
how the hardware really works; The HDMI port register
defines whether we're actually outputting 8bpc or 12bpc
over HDMI, and the PIPECONF bpc setting just defines what
goes over FDI between the CPU and PCH. The fact that we
try to cram all that into a single pipe_bpp during state
computation is perhaps not entirely great...
Imre Deak [Thu, 22 Sep 2022 17:21:48 +0000 (20:21 +0300)]
drm/i915: Fix TypeC mode initialization during system resume
During system resume DP MST requires AUX to be working already before
the HW state readout of the given encoder. Since AUX requires the
encoder/PHY TypeC mode to be initialized, which atm only happens during
HW state readout, these AUX transfers can change the TypeC mode
incorrectly (disconnecting the PHY for an enabled encoder) and trigger
the state check WARNs in intel_tc_port_sanitize().
Fix this by initializing the TypeC mode earlier both during driver
loading and system resume and making sure that the mode can't change
until the encoder's state is read out. While at it add the missing
DocBook comments and rename
intel_tc_port_sanitize()->intel_tc_port_sanitize_mode() for consistency.
Ville Syrjälä [Thu, 22 Sep 2022 19:13:14 +0000 (22:13 +0300)]
drm/i915: Don't bail early from intel_dp_initial_fastset_check()
Do all the checks in intel_dp_initial_fastset_check() instead
of bailing out on the first condition that triggers.
This makes for better debug logs since we see all the reasons
why the full modeset computation is forced.
Also avoid the risk of someone accidentally adding a check
later in the function that would require connectors_changed=true
(ie. no fastset at all), but an earlier check may have already
bailed out with just mode_changed=true (ie. fastset is still
possible).
Pimp the debugs with the encoder id+name while at it.
v2: Call the return variable 'fastset' to convey its meaning
Ville Syrjälä [Thu, 22 Sep 2022 19:12:36 +0000 (22:12 +0300)]
drm/i915: Force DPLL calculation for TC ports after readout
We always allocate two DPLLs (TC and TBT) for TC ports. This
is because we can't know ahead of time wherher we need to put
the PHY into DP-Alt or TBT mode.
However during readout we can obviously only read out the state
of the DPLL that the port is actually using. Thus the state after
readout will not have both DPLLs populated.
We run into problems if during readout the TC port is in DP-Alt
mode, but we then perform a modeset on the port without going
through the full .compute_config() machinery, and during said
modeset the port cannot be switched back into DP-Alt mode and
we need to take the TBT fallback path. Such a modeset can
happen eg. due to cdclk reprogramming.
This wasn't a problem earlier because we did all the DPLL
calculations much later in the modeset. So even if flagged
a modeset very late we'd still have gone through the DPLL
calculations. But now all the DPLL calculations happen much
earlier and so we need to deal with it, or else we'll attempt
a modeset without a DPLL.
To guarantee that we always have both DPLLs fully cal/ulated
for TC ports force a full modeset computation during the
initial commit.
v2: Avoid bitwise operation on bool (Jani)
Call the return variable 'fastset' to convey its meaning
Jani Nikula [Fri, 16 Sep 2022 08:26:42 +0000 (11:26 +0300)]
drm/i915: fix device info for devices without display
Commit 00c6cbfd4e8a ("drm/i915: move pipe_mask and cpu_transcoder_mask
to runtime info") moved the pipe_mask member from struct
intel_device_info to intel_runtime_info, but overlooked some of our
platforms initializing device info .display = {}. This is significant,
as pipe_mask is the single point of truth for a device having a display
or not; the platforms in question left pipe_mask to whatever was set for
the platforms they "inherit" from in the complex macro scheme we have.
Add new NO_DISPLAY macro initializing .__runtime.pipe_mask = 0, which
will cause the device info .display sub-struct to be zeroed in
intel_device_info_runtime_init(). A better solution (or simply audit of
proper use of HAS_DISPLAY() checks) is required before moving forward
with [1].
Also clear all the display related members in runtime info if there's no
display. The latter is a bit tedious, but it's for completeness at this
time, to ensure similar functionality as before.
Fixes: 00c6cbfd4e8a ("drm/i915: move pipe_mask and cpu_transcoder_mask to runtime info") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Maarten Lankhort <maarten.lankhorst@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220916082642.3451961-1-jani.nikula@intel.com
Ville Syrjälä [Wed, 22 Jun 2022 15:54:47 +0000 (18:54 +0300)]
drm/i915: Simplify up vlv watermark sanitation
We can simplify the vlv watermark sanitation by reusing the
second half of vlv_compute_pipe_wm() to convert the sanitized
raw watermarks into the proper form to be used as the
optimal/intermediate watermarks.
Also to be consistent with normal watermark computation the sanitized
watermarks should be all 0 for any disabled plane. Previously we
zeroed out the watermarks only up to the level (ie. PM2/5/DVDFS)
that was enabled.
Ville Syrjälä [Wed, 22 Jun 2022 15:54:46 +0000 (18:54 +0300)]
drm/i915: Simplify up g4x watermark sanitation
We can simplify the g4x watermark sanitation by reusing the
second half of g4x_compute_pipe_wm() to convert the sanitized
raw watermarks into the proper form to be used as the
optimal/intermediate watermarks.
Ville Syrjälä [Wed, 22 Jun 2022 15:54:45 +0000 (18:54 +0300)]
drm/i915: Split vlv_compute_pipe_wm() into two
Split vlv_compute_pipe_wm() into two halves. The first half computes
the new raw watermarks, and the second half munges those up into real
watermarks for the particular pipe.
We can reuse the second half for watermark sanitation as well.
Ville Syrjälä [Wed, 22 Jun 2022 15:54:44 +0000 (18:54 +0300)]
drm/i915: Split g4x_compute_pipe_wm() into two
Split g4x_compute_pipe_wm() into two halves. The first half computes
the new raw watermarks, and the second half munges those up into real
watermarks for the particular pipe.
We can reuse the second half for watermark sanitation as well.
Ville Syrjälä [Mon, 12 Sep 2022 11:18:12 +0000 (14:18 +0300)]
drm/i915: Don't init eDP if we can't find a fixed mode
In the unlikely case of not finding a fixed mode don't register
the eDP connector. I think there are some places where we'd oops
if we didn't have a fixed mode for eDP so presumable this doesn't
typically happen. But better safe than sorry.
Also pimp the debugs with the encoder id+name. I think dumping
the encoder rather than the connector provides more information
here (eg. to match against the port information in the VBT).
We can also drop the extra check from intel_edp_add_properties().
Ville Syrjälä [Mon, 12 Sep 2022 11:18:11 +0000 (14:18 +0300)]
drm/i915: Clean up connector->*_allowed setup
All the connectors are zero initialized so no need to clear
the *_allowed flags we don't support. Only leave the ones we want
to set. And while at it switch to booleans instead of ints.
Consolidate the scaling_mode property setup into a single
place.
The one slight complicateion here is that GMCH platforms can't
do the CENTER mode except on the LVDS port. But we can deal with
that by just checking the connector type.
Ville Syrjälä [Mon, 12 Sep 2022 11:18:01 +0000 (14:18 +0300)]
drm/i915: Clean up transcoder_to_stream_enc_status()
Drop the pointless middle man variable and just return the
correct thing directly. And while at it change the return
type to u32 since this is a register value we're returning.
drm/i915: Move hotplug inversion logic into separate helper
Use *_hpd_invert() helpers whenever possible to isolate logic specific
to hotplug inversion from common HPD setup logic to improve readability
and maintainability of the source code.
While we only define dg1_hpd_invert() here, future platforms are likely
to have different hotplug inversion needs, thus it makes sense grouping
different implementations under a common suffix.
v2: Fix coding style and prefer to use small *_hdp_invert() helpers
instead of a generic one.
José Roberto de Souza [Fri, 16 Sep 2022 01:46:47 +0000 (18:46 -0700)]
drm/i915: Parse and set stepping for platforms with GMD
Expand the current stepping convention to accommodate the GMD
stepping info. Typically GMD step maps to letter stepping
by "A + step %4" and number to "A + step /4" i.e, GMD step
0 maps to STEP_A0, 1 to _A1, 2 to _A2, 3 to _A3, 4 to STEP_B0...
Future platforms might break this formulae and may require a table
mapping to decode GMD step compatible with the convention.
v2:
- Pass the updated ip version structure
v3:
- Skip using GMD to step table(MattR)
Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220916014648.1310346-3-radhakrishna.sripada@intel.com
Matt Roper [Fri, 16 Sep 2022 01:46:46 +0000 (18:46 -0700)]
drm/i915: Read graphics/media/display arch version from hw
Going forward, the hardware teams no longer consider new platforms to
have a "generation" in the way we've defined it for past platforms.
Instead, each IP block (graphics, media, display) will have their own
architecture major.minor versions and stepping ID's which should be read
directly from a register in the MMIO space.
Bspec: 63361, 64111
v2:
- Move the IP version readout to intel_device_info.c
- Convert the macro into a function
v3:
- Move subplatform init to runtime early init
- Cache runtime ver, release info to compare with hardware values.
- Use IP_VER for snaity check(MattR)
v4:
- Minor doccumentation changes.
- Normalize HAS_GMD_ID macro value.(JaniN)
Ville Syrjälä [Fri, 16 Sep 2022 16:52:05 +0000 (19:52 +0300)]
drm/i915/fbc: Remove stale FIXME
Remove the old tales about 90/270 degree rotation
effectively preventing FBC. That hasn't been true since
we stopped demanding the fence is present in
commit 691f7ba58d52 ("drm/i915/display/fbc: Make fences
a nice-to-have for GEN9+")
Also fix up the multiline comment formatting while at it.
Ville Syrjälä [Fri, 16 Sep 2022 16:52:04 +0000 (19:52 +0300)]
drm/i915: Nuke stale plane cdclk ratio FIXMEs
The plane ratio stuff got implemented in
commit bb6ae9e653dc ("drm/i915: Allow planes to
declare their minimum acceptable cdclk") so these
FIXMEs have no business being here.
Ville Syrjälä [Mon, 20 Jun 2022 18:29:17 +0000 (21:29 +0300)]
drm/i915/fbc: Use lockdep_assert_held()
Replace the mutex_is_locked() stuff with lockdep_assert_held() since
that's what it's there for.
Also sprinkle these around so that we have more or less
mirrored coverage for the enable vs. disable instead of the
current situation where the asserts seem to be more or less
randomly thrown around.
Ville Syrjälä [Mon, 20 Jun 2022 18:29:16 +0000 (21:29 +0300)]
drm/i915/fbc: Move flip_pending assignmnt
Move the flip_pending assignment into __intel_fbc_post_update()
from intel_fbc_post_update(). Now mirrors the pre_update() side.
The only reason the assignment was in the higher level function
is that we used to call __intel_fbc_post_update() from elsewhere
as well. That got cleaned up in commit b39d2c620242 ("drm/i915/fbc:
Call intel_fbc_activate() directly from frontbuffer flush")
projects / users / dwmw2 / linux.git / log