Ville Syrjälä [Wed, 26 Oct 2022 10:11:28 +0000 (13:11 +0300)]
drm/i915/sdvo: Setup DDC fully before output init
Call intel_sdvo_select_ddc_bus() before initializing any
of the outputs. And before that is functional (assuming no VBT)
we have to set up the controlled_outputs thing. Otherwise DDC
won't be functional during the output init but LVDS really
needs it for the fixed mode setup.
Note that the whole multi output support still looks very
bogus, and more work will be needed to make it correct.
But for now this should at least fix the LVDS EDID fixed mode
setup.
Ville Syrjälä [Wed, 26 Oct 2022 10:11:27 +0000 (13:11 +0300)]
drm/i915/sdvo: Filter out invalid outputs more sensibly
We try to filter out the corresponding xxx1 output
if the xxx0 output is not present. But the way that is
being done is pretty awkward. Make it less so.
Ville Syrjälä [Wed, 26 Oct 2022 17:01:50 +0000 (20:01 +0300)]
drm/i915/sdvo: Extract intel_sdvo_has_audio()
Pull the SDVO audio state computation into a helper.
This is almost identical to intel_hdmi_has_audio(),
except the sink capabilities are stored under intel_sdvo
rather than intel_hdmi. Might be nice to get rid of
this duplication eventually...
Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026170150.2654-16-ville.syrjala@linux.intel.com
Ville Syrjälä [Wed, 26 Oct 2022 17:01:49 +0000 (20:01 +0300)]
drm/i915/audio: Do the vblank waits
The spec tells us to do a bunch of vblank waits in the audio
enable/disable sequences. Make it so.
The FIXMEs are nonsense since we do the audio disable very
early and enable very late, so vblank interrupts are in fact
enabled when we do this.
TODO not sure we actually want these since we don't even rely
on the hw ELD buffer, and these might be there just to give
the audio side a bit of time to respond to the unsol events.
OTOH they might be really needed for some other reason.
Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026170150.2654-15-ville.syrjala@linux.intel.com
Ville Syrjälä [Wed, 26 Oct 2022 17:01:48 +0000 (20:01 +0300)]
drm/i915/audio: Split "ELD valid" vs. audio PD on hsw+
On the older platforms the audio presence detect bit is in
the port register, so it gets written outside audio codec hooks
and is this separate from the ELD valid toggling. Split the
operations into two steps on hsw+ to be more consistent with
both the other platforms and the spec. Also according to the
spec we might need some vblank waits between the two which
definitely needs them done separately.
Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026170150.2654-14-ville.syrjala@linux.intel.com
Ville Syrjälä [Wed, 26 Oct 2022 17:01:47 +0000 (20:01 +0300)]
drm/i915/audio: Use intel_de_rmw() for most audio registers
The audio code does a lot of RMW accesses. Utilize
intel_de_rmw() to make that a bit less tedious.
There are still some hand rolled RMW left, but those have
a lot of code in between the read and write to calculate
the new value, so would need some refactoring first.
v2: Add parens around the ?: to satisfy the robot
Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026170150.2654-13-ville.syrjala@linux.intel.com
Ville Syrjälä [Wed, 26 Oct 2022 17:01:45 +0000 (20:01 +0300)]
drm/i915/audio: Make sure we write the whole ELD buffer
Currently we only write as many dwords into the hardware
ELD buffers as drm_eld_size() tells us. That could mean the
remainder of the hardware buffer is left with whatever
stale garbage it had before, which doesn't seem entirely
great. Let's zero out the remainder of the buffer in case
the provided ELD doesn't fill it fully.
We can also sanity check out idea of the hardware ELD buffer's
size by making sure the address wrapped back to zero once
we wrote the entire buffer.
Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026170150.2654-11-ville.syrjala@linux.intel.com
Ville Syrjälä [Wed, 26 Oct 2022 17:01:44 +0000 (20:01 +0300)]
drm/i915/audio: Read ELD buffer size from hardware
We currently read the ELD buffer size from hardware on g4x,
but on ilk+ we just hardcode it to 84 bytes. Let's unify
this and just do the hardware readout on all platforms,
in case the size changes in the future or something.
TODO: should perhaps do the readout during driver init and
stash the results somewhere so that we could check that the
connector's ELD actually fits and not even try to enable audio
in that case...
v2: Document the size is in dwords (Jani)
Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026170150.2654-10-ville.syrjala@linux.intel.com
Ville Syrjälä [Wed, 26 Oct 2022 17:01:42 +0000 (20:01 +0300)]
drm/i915/audio: Protect singleton register with a lock
On the "ilk" platforms AUD_CNTL_ST2 is a singleton. Protect
it with the audio mutex in case we ever want to do parallel
RMW access to it.
Currently that should not happen since we only do audio
enable/disable from full modesets, and those are fully
serialized. But we probably want to think about toggling
audio on/off from fastsets too.
The hsw codepaths already have the same locking.
g4x should not need it since it can only do audio to a
single port at a time, which means it's actually broken
in more ways than this atm.
Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026170150.2654-8-ville.syrjala@linux.intel.com
Ville Syrjälä [Wed, 26 Oct 2022 17:01:39 +0000 (20:01 +0300)]
drm/i915/audio: Extract struct ilk_audio_regs
The "ilk" audio codec codepaths have some duplicated code
to figure out the correct registers to use on each platform.
Extrat that into a single place.
Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026170150.2654-5-ville.syrjala@linux.intel.com
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.
projects / users / dwmw2 / linux.git / log