Define the contents of VBT block 10 (Mode Removal Table).
There seem to be two variants:
- 8 byte entries for desktop systems
- 10 byte entries for mobile systems, with the extra
panel_flags being a bitmask of LFPs
It seems starting from HSW only the mobile variant is
used anymore.
Define the contents for VBT blocks:
- Block 6 (Extended MMIO Register Table)
- Block 7 (IO Software Flag Table)
- Block 8 (MMIO SWF Register Table)
All of these use the same basic layout, with two known variants:
- data_access_size==0xce -> offset,value tuples are u8,u8
- data_access_size==0x02 -> offset,value tuples are u32,u32
Define the contents of VBT block 5 (Generic Mode Table).
Details were mostly gleaned from some VBIOS sources.
There are apparently two variants of the block: ALM only
vs. MGM, defined here as bdb_generic_mode_table_alm
and bdb_generic_mode_table_mgm. And those are the only two
platforms where I've seen this block.
Ville Syrjälä [Fri, 3 May 2024 12:24:24 +0000 (15:24 +0300)]
drm/i915/bios: Define VBT block 4 (Mode Support List) contents
Define the contents of VBT block 4 (Mode Support List).
Slightly crazy layout with a variable length list at the start,
followed by the length of said list.
No real idea what these "Intel mode numbers" really are. What
I see in real world VBTs seems to be always the same list of
26 numbers, ranging between 0x30 and 0x84.
Ville Syrjälä [Fri, 3 May 2024 12:24:20 +0000 (15:24 +0300)]
drm/i915/bios: Define "TV" child device handle
Child device 0x2 used to be "TV" until redefined to mean
EFP5 in version 215. Add a define for the old meaning as well.
Technically it was probably deprecated a lot before version
215 since native TV encoders were last seen on CTG, and SDVO
was fully gone by HSW. So something like "???-164" might also
be a reasonable way to document this, but no real harm in
saying "???-214" since nothing else presumably occupied that
bit in the meantime.
Ville Syrjälä [Fri, 3 May 2024 12:24:16 +0000 (15:24 +0300)]
drm/i915/bios: Remove version number comment from DEVICE_HANDLE_EFP4
DEVICE_HANDLE_EFP4 has actually been in use since the very beginning,
or at least something has been occupying that bit because old
VBTs actually use it, and it definitely looks to be about external
displays given how its used. So let's ignore what the current spec
claims and remove the misleading version number comment.
Karthikeyan Ramasubramanian [Thu, 22 Feb 2024 01:06:24 +0000 (18:06 -0700)]
drm/i915/bios: Fix parsing backlight BDB data
Starting BDB version 239, hdr_dpcd_refresh_timeout is introduced to
backlight BDB data. Commit 700034566d68 ("drm/i915/bios: Define more BDB
contents") updated the backlight BDB data accordingly. This broke the
parsing of backlight BDB data in VBT for versions 236 - 238 (both
inclusive) and hence the backlight controls are not responding on units
with the concerned BDB version.
backlight_control information has been present in backlight BDB data
from at least BDB version 191 onwards, if not before. Hence this patch
extracts the backlight_control information for BDB version 191 or newer.
Tested on Chromebooks using Jasperlake SoC (reports bdb->version = 236).
Tested on Chromebooks using Raptorlake SoC (reports bdb->version = 251).
v2: removed checking the block size of the backlight BDB data
[vsyrjala: this is completely safe thanks to commit e163cfb4c96d
("drm/i915/bios: Make copies of VBT data blocks")]
Fixes: 700034566d68 ("drm/i915/bios: Define more BDB contents") Cc: stable@vger.kernel.org Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Karthikeyan Ramasubramanian <kramasub@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240221180622.v2.1.I0690aa3e96a83a43b3fc33f50395d334b2981826@changeid Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Matthew Auld [Tue, 30 Apr 2024 17:28:49 +0000 (10:28 -0700)]
drm/i915/display: perform transient flush
Perform manual transient cache flush prior to flip and at the end of
frontbuffer_flush. This is needed to ensure display engine doesn't see
garbage if the surface is L3:XD dirty.
Testcase: igt@xe-pat@display-vs-wb-transient Signed-off-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430172850.1881525-19-radhakrishna.sripada@intel.com
Nirmoy Das [Tue, 30 Apr 2024 17:28:48 +0000 (10:28 -0700)]
drm/xe/device: implement transient flush
Display surfaces can be tagged as transient by mapping it using one of
the various L3:XD PAT index modes on Xe2. The expectation is that KMD
needs to request transient data flush at the start of flip sequence to
ensure all transient data in L3 cache is flushed to memory. Add a
routine for this which we can then call from the display code.
v2: rebase(RK)
Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Co-developed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430172850.1881525-18-radhakrishna.sripada@intel.com
Revert "drm/i915/dgfx: DGFX uses direct VBT pin mapping"
This reverts commit 562f33836f519a235e5c5e71bcc723ab1faccd2f.
For BMG it seems that the VBT to DDI mapping does not follow DG1, and
DG2, but follows ADLP mapping given in Bspec:20124.
Matt Roper [Tue, 30 Apr 2024 17:28:42 +0000 (10:28 -0700)]
drm/i915/xe2hpd: Add max memory bandwidth algorithm
Unlike DG2, Xe2_HPD does support multiple GV points with different
maximum memory bandwidths, but uses a much simpler algorithm than igpu
platforms use.
drm/i915/xe2hpd: Add support for eDP PLL configuration
Tables for eDP PHY PLL configuration for different link rates added for
Xe2_HPD. Previous platforms were using C10 PHY for eDP port whereas
Xe2_HPD has C20 PHY.
Xe2_HPD has different offsets for C20 PHY SRAM configuration context
location. Use the display version to select the right address.
Note that Xe2_LPD uses the same C20 SRAM offsets used by Xe_LPDP (i.e.
MTL's display). According to the BSpec, currently, only Xe2_HPD has
different offsets, so make sure it is the only display using them in the
driver.
v2:
* Redesigned how the right offsets are selected for different display
IP versions.
v3: Fix white space error(RK)
Bspec: 67610 Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430172850.1881525-7-radhakrishna.sripada@intel.com
Discrete cards use the Port numbers TC1-4 for the offsets. The regular
flow for type-c subsystem port initialization can be skipped. This check
is present in DG2. Extend this to future discrete products.
Display code uses IS_BATTLEMAGE macro but the platform support doesn't
exist in i915. So fake IS_BATTLEMAGE macro defined to enable building
i915 code. We should make sure the macro parameter is used in the
always-false expression so that we don't run into "unused variable"
warnings from i915 builds if the IS_BATTLEMAGE() check is the only place
the i915 pointer gets used in a function.
While we're at it, also update the IS_LUNARLAKE macro to include the
parameter in the false expression for consistency.
Mika Kahola [Thu, 2 May 2024 13:17:16 +0000 (16:17 +0300)]
drm/i915/display: Calculate crtc clock rate based on PLL parameters
With HDMI monitors we bumped up a case where the crtc clock rate
caused a mismatch on state verification. This was due to
assumption that the SW clock rate from PLL structure would match
the calculated counterpart from HW. This is not necessarily always
the case and therefore we would actually need to recalculate the
clock rate from SW PLL parameters. Then these SW and HW crtc clock
rates can be compared with each other.
The patch recalculates the crtc clock rate for SW state based on
SW PLL parameters and compares the crtc clock rate calculated
from the parameters found from the HW.
Rename need_async_flip_disable_wa to need_async_flip_toggle_wa to
better reflect the fact that we need to deal with the bad
PLANE_CTL_ASYNC_FLIP double buffering behaviour going both
ways.
Ville Syrjälä [Tue, 30 Apr 2024 09:56:38 +0000 (12:56 +0300)]
drm/i915: Eliminate extra frame from skl-glk sync->async flip change
On bdw-glk the sync->async flip change takes an extra frame due to
the double buffering behaviour of the async flip plane control bit.
Since on skl+ we are now explicitly converting the first async flip
to a sync flip (in order to allow changing the modifier and/or
ddb/watermarks) we are now taking two extra frames until async flips
are actually active. We can drop that back down to one frame by
setting the async flip bit already during the sync flip.
Note that on bdw we don't currently do the extra sync flip (see
intel_plane_do_async_flip()) so technically we wouldn't have
to deal with this in i9xx_plane_update_arm(). But I added the
relevant snippet of code there as well, just in case we ever
decide to go for the extra sync flip on pre-skl platforms as
well (we might, for example, want to change the fb stride).
Ville Syrjälä [Tue, 30 Apr 2024 09:56:37 +0000 (12:56 +0300)]
drm/i915: Allow the initial async flip to change modifier
With Xorg+modesetting on skl+ we see the following behaviour:
1. root pixmap is X-tiled
2. client submitted buffers can be Y-tiled (w/ 'Option "dmabuf_capable"')
3. we try to switch from the X-tiled buffer to the Y-tiled buffer
using an async flip (when vsync is disabled).
4. the async flip will be rejected by i915 due to the modifier change
Relax the rules a bit by turning the first async flip into a sync
flip so that we can change the modifier if necessary. Note that
we already convert the first async flip into a sync flip on adl+
in order to reprogram the watermarks.
Ville Syrjälä [Tue, 30 Apr 2024 09:56:36 +0000 (12:56 +0300)]
drm/i915: Reject async flips if we need to change DDB/watermarks
DDB/watermarks are always double buffered on the vblank, so we
can't safely change them during async flips. Currently this never
happens, but we'll be making changing between sync and async
flips a bit more flexible, in which case we can actually end up
here.
Ville Syrjälä [Tue, 30 Apr 2024 09:56:35 +0000 (12:56 +0300)]
drm/i915: Align PLANE_SURF to 16k on ADL for async flips
On ADL async flips apparently generate DMAR and GGTT faults
(with accompanying visual glitches) unless PLANE_SURF is
aligned to at least 16k. Bump up the alignment to 16k.
TODO: analyze things better to figure out what is really
going on here
drm/i915/audio: Fix audio time stamp programming for DP
Intel hardware is capable of programming the Maud/Naud SDPs on its
own based on real-time clocks. While doing so, it takes care
of any deviations from the theoretical values. Programming the registers
explicitly with static values can interfere with this logic. Therefore,
let the HW decide the Maud and Naud SDPs on it's own.
Cc: stable@vger.kernel.org # v5.17 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8097 Co-developed-by: Kai Vehmanen <kai.vehmanen@intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen@intel.com> Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430091825.733499-1-chaitanya.kumar.borah@intel.com
In order to detect duplicate implementations for the same workaround,
early in the implementation of RTP it was decided to error out even if
the values set are exactly the same. With the introduction of 18034896535
in commit 74671d23ca18 ("drm/xe/xe2: Add workaround 18034896535"), LNL
stepping with graphics stepping A1 now gives the following error on
module load:
Matthew Auld [Tue, 23 Apr 2024 07:47:23 +0000 (08:47 +0100)]
drm/xe/vm: prevent UAF in rebind_work_func()
We flush the rebind worker during the vm close phase, however in places
like preempt_fence_work_func() we seem to queue the rebind worker
without first checking if the vm has already been closed. The concern
here is the vm being closed with the worker flushed, but then being
rearmed later, which looks like potential uaf, since there is no actual
refcounting to track the queued worker. We can't take the vm->lock here
in preempt_rebind_work_func() to first check if the vm is closed since
that will deadlock, so instead flush the worker again when the vm
refcount reaches zero.
v2:
- Grabbing vm->lock in the preempt worker creates a deadlock, so
checking the closed state is tricky. Instead flush the worker when
the refcount reaches zero. It should be impossible to queue the
preempt worker without already holding vm ref.
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1676 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1591 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1364 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1304 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1249 Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240423074721.119633-4-matthew.auld@intel.com
(cherry picked from commit 3d44d67c441a9fe6f81a1d705f7de009a32a5b35) Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Thomas Hellström [Tue, 23 Apr 2024 12:11:14 +0000 (14:11 +0200)]
drm/xe: Fix unexpected backmerge results
The recent backmerge from drm-next to drm-xe-next brought with it
some silent unexpected results. One code snippet was added twice
and a partial revert had merge errors. Fix that up to
reinstate the affected code as it was before the backmerge.
Display i915:
- More initial work to make display code more independent from i915 (Jani)
- Convert i915/xe fbdev to DRM client (Thomas Zimmermann)
- VLV/CHV DPIO register cleanup (Ville)
Ville Syrjälä [Mon, 22 Apr 2024 08:34:56 +0000 (11:34 +0300)]
drm/i915/dpio: Clean up the vlv/chv PHY register bits
Use REG_BIT() & co. for the vlv/chv DPIO PHY registers.
Note that DPIO_BIAS_CURRENT_CTL_SHIFT was incorrectly defined
to be 21 wheres 20 is the correct value. It is not used in the
code though so didn't bother splitting to a separate patch.
Ville Syrjälä [Mon, 22 Apr 2024 08:34:54 +0000 (11:34 +0300)]
drm/i915/dpio: Rename a few CHV DPIO PHY registers
Drop the leading underscore from the CHV PHY common lane
register definitions. We use these directly from actual
code so the underscore here is misleading as usually it indicates
an intermediate define that shouldn't be used directly.
Ville Syrjälä [Mon, 22 Apr 2024 08:34:53 +0000 (11:34 +0300)]
drm/i915/dpio: Give VLV DPIO group register a clearer name
Include _GRP in VLV DPIO PHY group access register define
names. Makes it more obvious where the accesses will land.
Also matches the naming used by BXT already.
Ville Syrjälä [Mon, 22 Apr 2024 08:34:52 +0000 (11:34 +0300)]
drm/i915/dpio: Derive the phy from the port rather than pipe in encoder hooks
In the encoder hooks we are dealing primarily with the encoder,
so derive the DPIO PHY from the encoder rather than the pipe.
Technically this doesn't matter as we can't cross connect
pipes<->port across PHY boundaries, but it does conveny the
intention more accurately.
Ville Syrjälä [Mon, 22 Apr 2024 08:34:51 +0000 (11:34 +0300)]
drm/i915/dpio: s/pipe/ch/
Stop using 'pipe' directly as the DPIO PHY channel. This
does happen to work on VLV since it just has the one PHY
with CH0==pipe A and CH1==pipe B. But explicitly converting
the thing to the right enum makes the whole thing less
confusing.
VLV_PLL_DW9_BCAST is actually VLV_PCS_DW17_BCAST. The address
does kinda look like it goes to the PLL block on a first glance,
but broadcast is special and doesn't even exist for the PLL
(only PCS and TX have it).
The fact that we use a broadcast write here is a bit sketchy
IMO since we're now blasting the register to all PCS splines
across the whole PHY. So the PCS registers in the other channel
(ie. other pipe/port) will also be written. But I guess the
fact that we always write the same value should make this a nop
even if the other channel is already enabled (assuming the VBIOS/GOP
didn't screw up and use some other value...).
Dave Airlie [Tue, 30 Apr 2024 04:20:31 +0000 (14:20 +1000)]
Merge tag 'drm-intel-gt-next-2024-04-26' of https://anongit.freedesktop.org/git/drm/drm-intel into drm-next
UAPI Changes:
- drm/i915/guc: Use context hints for GT frequency
Allow user to provide a low latency context hint. When set, KMD
sends a hint to GuC which results in special handling for this
context. SLPC will ramp the GT frequency aggressively every time
it switches to this context. The down freq threshold will also be
lower so GuC will ramp down the GT freq for this context more slowly.
We also disable waitboost for this context as that will interfere with
the strategy.
We need to enable the use of SLPC Compute strategy during init, but
it will apply only to contexts that set this bit during context
creation.
Userland can check whether this feature is supported using a new param-
I915_PARAM_HAS_CONTEXT_FREQ_HINT. This flag is true for all guc submission
enabled platforms as they use SLPC for frequency management.
The Mesa usage model for this flag is here -
https://gitlab.freedesktop.org/sushmave/mesa/-/commits/compute_hint
- drm/i915/gt: Enable only one CCS for compute workload
Enable only one CCS engine by default with all the compute sices
allocated to it.
While generating the list of UABI engines to be exposed to the
user, exclude any additional CCS engines beyond the first
instance
***
NOTE: This W/A will make all DG2 SKUs appear like single CCS SKUs by
default to mitigate a hardware bug. All the EUs will still remain
usable, and all the userspace drivers have been confirmed to be able
to dynamically detect the change in number of CCS engines and adjust.
For the smaller percent of applications that get perf benefit from
letting the userspace driver dispatch across all 4 CCS engines we will
be introducing a sysfs control as a later patch to choose 4 CCS each
with 25% EUs (or 50% if 2 CCS).
- Add new and fix to existing workarounds: Wa_14018575942 (MTL),
Wa_16019325821 (Gen12.70), Wa_14019159160 (MTL), Wa_16015675438,
Wa_14020495402 (Gen12.70) (Tejas, John, Lucas)
- Fix UAF on destroy against retire race and remove two earlier
partial fixes (Janusz)
- Limit the reserved VM space to only the platforms that need it (Andi)
- Reset queue_priority_hint on parking for execlist platforms (Chris)
- Fix gt reset with GuC submission is disabled (Nirmoy)
- Correct capture of EIR register on hang (John)
- Remove usage of the deprecated ida_simple_xx() API
- Refactor confusing __intel_gt_reset() (Nirmoy)
- Fix the fix for GuC reset lock confusion (John)
- Simplify/extend platform check for Wa_14018913170 (John)
- Replace dev_priv with i915 (Andi)
- Add and use gt_to_guc() wrapper (Andi)
- Remove bogus null check (Rodrigo, Dan)
Merge tag 'sched-urgent-2024-04-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull scheduler fixes from Ingo Molnar:
- Fix EEVDF corner cases
- Fix two nohz_full= related bugs that can cause boot crashes
and warnings
* tag 'sched-urgent-2024-04-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/isolation: Fix boot crash when maxcpus < first housekeeping CPU
sched/isolation: Prevent boot crash when the boot CPU is nohz_full
sched/eevdf: Prevent vlag from going out of bounds in reweight_eevdf()
sched/eevdf: Fix miscalculation in reweight_entity() when se is not curr
sched/eevdf: Always update V if se->on_rq when reweighting
Merge tag 'x86-urgent-2024-04-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Ingo Molnar:
- Make the CPU_MITIGATIONS=n interaction with conflicting
mitigation-enabling boot parameters a bit saner.
- Re-enable CPU mitigations by default on non-x86
- Fix TDX shared bit propagation on mprotect()
- Fix potential show_regs() system hang when PKE initialization
is not fully finished yet.
- Add the 0x10-0x1f model IDs to the Zen5 range
- Harden #VC instruction emulation some more
* tag 'x86-urgent-2024-04-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
cpu: Ignore "mitigations" kernel parameter if CPU_MITIGATIONS=n
cpu: Re-enable CPU mitigations by default for !X86 architectures
x86/tdx: Preserve shared bit on mprotect()
x86/cpu: Fix check for RDPKRU in __show_regs()
x86/CPU/AMD: Add models 0x10-0x1f to the Zen5 range
x86/sev: Check for MWAITX and MONITORX opcodes in the #VC handler
projects / users / jedix / linux-maple.git / log