drm/i915: Fix possible int overflow in skl_ddi_calculate_wrpll()
On the off chance that clock value ends up being too high (by means
of skl_ddi_calculate_wrpll() having been called with big enough
value of crtc_state->port_clock * 1000), one possible consequence
may be that the result will not be able to fit into signed int.
Fix this issue by moving conversion of clock parameter from kHz to Hz
into the body of skl_ddi_calculate_wrpll(), as well as casting the
same parameter to u64 type while calculating the value for AFE clock.
This both mitigates the overflow problem and avoids possible erroneous
integer promotion mishaps.
Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.
drm/i915/display/dp: Compute AS SDP when vrr is also enabled
AS SDP should be computed when VRR timing generator is also enabled.
Correct the compute condition to compute params of Adaptive sync SDP
when VRR timing genrator is enabled along with sink support indication.
--v2:
Modify if condition (Jani).
Fixes: b2013783c445 ("drm/i915/display: Cache adpative sync caps to use it later") Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Cc: Arun R Murthy <arun.r.murthy@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: intel-xe@lists.freedesktop.org Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
(added prefix drm in subject) Link: https://patchwork.freedesktop.org/patch/msgid/20240730040941.396862-1-mitulkumar.ajitkumar.golani@intel.com
Lucas De Marchi [Wed, 24 Jul 2024 21:53:09 +0000 (14:53 -0700)]
drm/xe: Fix opregion leak
Being part o the display, ideally the setup and cleanup would be done by
display itself. However this is a bigger refactor that needs to be done
on both i915 and xe. For now, just fix the leak:
drm/i915/dp: Clear VSC SDP during post ddi disable routine
Clear VSC SDP if intel_dp_set_infoframes is called from post ddi disable
routine i.e with the variable of enable as false. This is to avoid
an infoframes.enable mismatch issue which is caused when pipe is
connected to eDp which has psr then connected to DPMST. In this case
eDp's post ddi disable routine does not clear infoframes.enable VSC
for the given pipe and DPMST does not recompute VSC SDP and write
infoframes.enable which causes a mismatch.
drm/i915/hdcp: Add encoder check in intel_hdcp_get_capability
Sometimes during hotplug scenario or suspend/resume scenario encoder is
not always initialized when intel_hdcp_get_capability add
a check to avoid kernel null pointer dereference.
I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced "master/slave"
with more appropriate terms. Inspired by Wolfram's series to fix drivers/i2c/,
fix the terminology for users of I2C_ALGOBIT bitbanging interface, now that
the approved verbiage exists in the specification.
Imre Deak [Fri, 12 Jul 2024 13:57:24 +0000 (16:57 +0300)]
drm/i915/dp: Don't WARN on failed link-retrain modeset
After a bad link state is detected, the sink capabilities with which the
link was originally trained could have changed: for instance another
sink got connected or the retraining was forced after the rate/lane count
got decreased (as a fallback). In these cases the retraining modeset
fails as expected also printing a debug message, so don't WARN on it.
Imre Deak [Fri, 12 Jul 2024 13:57:23 +0000 (16:57 +0300)]
drm/i915/dp: Require a valid atomic state for SST link training
After the previous patch link training happens always with a valid
atomic state, so remove the NOTE comments and asserts which required a
valid state only for DP-MST and allowed for a NULL state for DP-SST.
Imre Deak [Fri, 12 Jul 2024 13:57:22 +0000 (16:57 +0300)]
drm/i915/dp: Retrain SST links via a modeset commit
Instead of direct calls of the link training functions, use a modeset
commit to retrain a DP link in SST mode, similarly to how this is done
in DP-MST mode. Originally the current way was chosen presumedly,
because there wasn't a well-established way in place for the driver to
do an internal (vs. userspace/kernel client) commit. Since then such
internal commits became a common place (initial-, HDMI/TC link reset
commit), so there is no reason to handle the DP-SST link-retraining case
differently.
At the end of the current sequence the HW reported a FIFO underrun -
without other issues visible to users - because during retraining the
link's encoder/port was disabled/re-enabled without also
disabling/re-enabling the corresponding pipe/transcoder (as required by
the spec); the corresponding underrun error message was suppressed as a
known issue. Based on Ankit's test on DG2 the underrun error was still
reported as it got detected with some (vblank) delay wrt. other
platforms. Switching to a modeset commit resolves these underrun related
issues.
Ville Syrjälä [Fri, 5 Jul 2024 14:52:45 +0000 (17:52 +0300)]
drm/i915/fbc: Extract intel_fbc_max_cfb_height()
Pull the code to determine the maximum CFB height
into a separate function.
To make this work we need to declare an explicit max height
for all older platforms as well. But that is actually just
the max plane height as pre-HSW hardware supposedly doesn't
have the trick of leaving the extra lines uncompressed.
Ville Syrjälä [Fri, 5 Jul 2024 14:52:41 +0000 (17:52 +0300)]
drm/i915/fbc: Adjust g4x+ platform checks
Do the "is this ilk+ or g4x" checks in the customary order instead
of the reverse order. Easier for the poor brain to parse this
when it's always done the same way.
Rename intel_fbc_hw_tracking_covers_screen() to intel_fbc_surface_size_ok()
so that the naming scheme is the same for the surface size vs. plane
size checks. "surface size" is what bspec talks about.
Ville Syrjälä [Fri, 5 Jul 2024 14:52:38 +0000 (17:52 +0300)]
drm/i915/fbc: Extract intel_fbc_max_plane_size()
Extract intel_fbc_max_plane_size() from intel_fbc_plane_size_valid().
We'll have another use for this soon in determining how much stolen
memory we'd like to keep reserved for FBC.
_intel_fbc_cfb_stride() calculates the CFB stride the hardware would
automagically generate from the plane's stride. Rename the function
to intel_fbc_plane_cfb_stride() to better reflect its purpose.
Ville Syrjälä [Fri, 5 Jul 2024 14:52:36 +0000 (17:52 +0300)]
drm/i915/fbc: Convert to intel_display, mostly
Switch the FBC code over to intel_display from i915, as
much as possible. This is the future direction so that
the display code can be shared between i915 and xe more
cleanly.
Some of the platform checks and the stolen mem facing stiff
still need i915 around though.
Ville Syrjälä [Fri, 5 Jul 2024 14:52:35 +0000 (17:52 +0300)]
drm/i915/fbc: Extract intel_fbc_has_fences()
Pull the "do we have fences?" check into a single helper in the FBC
code. Avoids having to call to outside the display code in multiple
places for this.
Ville Syrjälä [Mon, 24 Jun 2024 19:10:20 +0000 (22:10 +0300)]
drm/i915: Make vrr_{enabling,disabling}() usable outside intel_display.c
Give vrr_enabling() and vrr_disabling() slightly fancier names, and
pass in the whole atomic state so that they'll be easier to use.
We'll need to call at least the disabling part from the DSB code
soon enough (so that we can do vblank evasions/etc. correctly on
the DSB).
Ville Syrjälä [Mon, 24 Jun 2024 19:10:19 +0000 (22:10 +0300)]
drm/i915: Calculate vblank delay more accurately
Calculate the vblank delay in the vblank evasion code correctly
for interlaced modes.
The current code assumes that we won't be using an interlaced mode.
That assumption is actually valid since we've defeatured interlaced
scanout in commit f71c9b7bc35f ("drm/i915/display: Prune Interlace
modes for Display >=12") for DSB capable platforms. However the
feature is still present in the hardware, and if we ever find the
need to re-enable it seems better to calculate the vblank delay
correctly.
Imre Deak [Mon, 8 Jul 2024 19:00:26 +0000 (22:00 +0300)]
drm/i915/dp: Reset cached LTTPR count if number of LTTPRs is unsupported
After detection the cached LTTPR count can be checked to determine if
LTTPRs in non-transparent mode were detected. Reset the cached LTTPR
count if the reported number of LTTPRs is invalid to ensure the above
checks work as expected.
Imre Deak [Mon, 8 Jul 2024 19:00:25 +0000 (22:00 +0300)]
drm/i915/dp: Don't switch the LTTPR mode on an active link
Switching to transparent mode leads to a loss of link synchronization,
so prevent doing this on an active link. This happened at least on an
Intel N100 system / DELL UD22 dock, the LTTPR residing either on the
host or the dock. To fix the issue, keep the current mode on an active
link, adjusting the LTTPR count accordingly (resetting it to 0 in
transparent mode).
v2: Adjust code comment during link training about reiniting the LTTPRs.
(Ville)
Fixes: 7b2a4ab8b0ef ("drm/i915: Switch to LTTPR transparent mode link training") Reported-and-tested-by: Gareth Yu <gareth.yu@intel.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10902 Cc: <stable@vger.kernel.org> # v5.15+ Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240708190029.271247-3-imre.deak@intel.com
Imre Deak [Mon, 8 Jul 2024 19:00:24 +0000 (22:00 +0300)]
drm/i915/dp: Reset intel_dp->link_trained before retraining the link
Regularly retraining a link during an atomic commit happens with the
given pipe/link already disabled and hence intel_dp->link_trained being
false. Ensure this also for retraining a DP SST link via direct calls to
the link training functions (vs. an actual commit as for DP MST). So far
nothing depended on this, however the next patch will depend on
link_trained==false for changing the LTTPR mode to non-transparent.
drm/i915/display: WA for Re-initialize dispcnlunitt1 xosc clock
The dispcnlunit1_cp_xosc_clk should be de-asserted in display off
and only asserted in display on. As part of this workaround, Display
driver shall execute set-reset sequence at the end of the initialize
sequence to ensure clk does not remain active in display OFF.
--v2:
- Rebase.
--v3:
- Correct HSD number in commit message.
--v4:
- Reformat commit message.
- Use intel_de_rmw instead of intel_de_write
--v5:
- Build Fixes.
drm/i915/display: Cache adpative sync caps to use it later
Add new member to struct intel_dp to cache support of Adaptive Sync
SDP capabilities and use it whenever required to avoid HW access
to read capability during each atomic commit.
Gustavo Sousa [Tue, 25 Jun 2024 20:26:52 +0000 (17:26 -0300)]
drm/i915: Skip programming FIA link enable bits for MTL+
Starting with Xe_LPD+, although FIA is still used to readout Type-C pin
assignment, part of Type-C support is moved to PICA and programming
PORT_TX_DFLEXDPMLE1(*) registers is not applicable anymore like it was
for previous display IPs (e.g. see BSpec 49190).
v2:
- Mention Bspec 49190 as a reference of instructions for previous
IPs. (Shekhar Chauhan)
- s/Xe_LPDP/Xe_LPD+/ in the commit message. (Matt Roper)
- Update commit message to be more accurate to the changes in the IP.
(Imre Deak)
Imre Deak [Wed, 26 Jun 2024 17:08:13 +0000 (20:08 +0300)]
drm/i915/mtl: Skip PLL state verification in TBT mode
In TBT-alt mode the driver doesn't program the PHY's PLL, which is
handled instead by Thunderbolt driver/FW components, hence the PLL's HW
vs. SW state verification should be skipped. During HW readout set a flag
in the PLL state if the port was at the moment in TBT-alt mode and skip
the verification of PLL parameters in this case.
Fixes: 45fe957ae769 ("drm/i915/display: Add compare config for MTL+ platforms") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11258 Cc: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240626170813.806470-1-imre.deak@intel.com
Ville Syrjälä [Tue, 11 Jun 2024 13:33:44 +0000 (16:33 +0300)]
drm/i915/dsb: Try to document that DSB_STATUS bit 16 is level triggered
DSB_STATUS bit 16 is supposed to be a sticky bit informing us whether
the DSB was idle or not when the pipe's delayed vblank (when double
buffered registers latch) occurred. Unfortunately it turns out this
is a level triggred signal, ie. the bit will be set whenever the
DSB is busy during the scanline window between start of delayed
vblank and vtotal. Try to document that fact by renaming the bit.
Sadly this also thwarts my plan to use this bit to sanity check
that the (to be introduced) DSB based vblank evasion did its job
correctly. That would require an edge triggered signal instead.
So looks like we'll have to rely mostly on luck instead :(
Jouni Högander [Wed, 19 Jun 2024 06:21:29 +0000 (09:21 +0300)]
drm/i915/psr: Perform scanline indication check for Panel Replay as well
Scanline indication needs to be checked and configure for both PSR2 and
Panel Replay Selective Update. Move this check to
intel_sel_update_config_valid.
Jouni Högander [Wed, 19 Jun 2024 06:21:28 +0000 (09:21 +0300)]
drm/i915/psr: Perform psr2 checks related to ALPM for Panel Replay
eDP1.5 support ALPM with Panel Replay as well. We need to check ALPM
related things for Panel Replay as well.
Bspec: 68920
v5:
- instead of using crtc_state->has_panel_replay provide aux_less flag
v4:
- do not move _compute_psr2_sdp_prior_scanline_indication
- move ALPM related checks to separate function
v3: move vblank check as well
v2: do not move Vblank >= PSR2_CTL Block Count Number maximum line count
check
Jouni Högander [Wed, 19 Jun 2024 06:21:23 +0000 (09:21 +0300)]
drm/i915/psr: enable sink for eDP1.5 Panel Replay
eDP1.5 allows Panel Replay on eDP as well. Take this into account when
enabling sink PSR/Panel Replay. Write also PANEL_REPLAY_CONFIG2 register
accordingly.
v3:
- set DP_PANEL_REPLAY_CRC_VERIFICATION in PANEL_REPLAY_CONFIG2
- PANEL_REPLAY_CONFIG2 is available in DP2.1 as well
v2: do not configure ALPM for DP2.0 Panel Replay
Maarten Lankhorst [Wed, 22 May 2024 05:33:41 +0000 (07:33 +0200)]
drm/i915: Use the same vblank worker for atomic unpin
In case of legacy cursor update, the cursor VMA needs to be unpinned
only after vblank. This exceeds the lifetime of the whole atomic commit.
Any trick I attempted to keep the atomic commit alive didn't work, as
drm_atomic_helper_setup_commit() force throttles on any old commit that
wasn't cleaned up.
The only option remaining is to remove the plane from the atomic commit,
and use the same path as the legacy cursor update to clean the state
after vblank.
Changes since previous version:
- Call the memset for plane state immediately when scheduling vblank,
this prevents a use-after-free in cursor cleanup.
Ville Syrjälä [Wed, 22 May 2024 05:33:40 +0000 (07:33 +0200)]
drm/i915: Use vblank worker to unpin old legacy cursor fb safely
The cursor hardware only does sync updates, and thus the hardware
will be scanning out from the old fb until the next start of vblank.
So in order to make the legacy cursor fastpath actually safe we
should not unpin the old fb until we're sure the hardware has
ceased accessing it. The simplest approach is to just use a vblank
work here to do the delayed unpin.
Not 100% sure it's a good idea to put this onto the same high
priority vblank worker as eg. our timing critical gamma updates.
But let's keep it simple for now, and it we later discover that
this is causing problems we can think about adding a lower
priority worker for such things.
Ville Syrjälä [Wed, 12 Jun 2024 20:47:12 +0000 (23:47 +0300)]
drm/i915: Nuke the TGL+ chroma plane tile row alignment stuff
I don't think the display hardware really has such chroma
plane tile row alignment requirements as outlined in
commit d156135e6a54 ("drm/i915/tgl: Make sure a semiplanar
UV plane is tile row size aligned")
Bspec had the same exact thing to say about earlier hardware
as well, but we never cared and things work just fine.
The one thing mentioned in that commit that is definitely
true however is the fence alignment issue. But we don't
deal with that on earlier hardware either. We do have code
to deal with that issue for the first color plane, but not
the chroma planes. So I think if we did want to check this
more extensively we should do it in the same places where
we already check the first color plane (namely
convert_plane_offset_to_xy() and intel_fb_bo_framebuffer_init()).
Ville Syrjälä [Wed, 12 Jun 2024 20:47:11 +0000 (23:47 +0300)]
drm/i915: Update plane alignment requirements for TGL+
Currently we still use the SKL+ PLANE_SURF alignment even
for TGL+ even though the hardware no longer needs it.
Introduce a separate tgl_plane_min_alignment() and update
it to more accurately reflect the hardware requirements.
Ville Syrjälä [Wed, 12 Jun 2024 20:47:10 +0000 (23:47 +0300)]
drm/i915: Move intel_surf_alignment() into skl_univerals_plane.c
Now that all pre-skl platforms have their own .min_alignment()
functions the remainder of intel_surf_alignment() can be hoisted
into skl_univerals_plane.c (and renamed appropriately).
Ville Syrjälä [Wed, 12 Jun 2024 20:47:07 +0000 (23:47 +0300)]
drm/i915: Introduce fb->min_alignment
Different planes could have different alignment requirements
even for the same format/modifier. Collect the alignment
requirements across all planes capable of scanning out the
fb such that the alignment is satisfactory to all those
planes.
So far this was sort of handled by making sure intel_surf_alignment()
declares the superset of all planes' alignment requirements,
but maintaining that manually is annoying. So we're going to move
towards each plane declaring only its own requirements, and thus
we need code to generate the superset.
v2: Drop the borked per-plane vma optimization (Imre)
Assert that the plane's declared alignment is POT (Imre)
Ville Syrjälä [Wed, 12 Jun 2024 20:47:06 +0000 (23:47 +0300)]
drm/i915: Introduce the plane->min_alignment() vfunc
Different hardware generations have different scanout alignment
requirements. Introduce a new vfunc that will allow us to
make that distinction without horrible if-ladders.
For now we directly plug in the existing intel_surf_alignment()
and intel_cursor_alignment() functions.
For fbdev we (temporarily) introduce intel_fbdev_min_alignment()
that simply queries the alignment from the primary plane of
the first crtc.
TODO: someone will need to fix xe's alignment handling
Ville Syrjälä [Wed, 19 Jun 2024 11:31:44 +0000 (14:31 +0300)]
drm: Export drm_plane_has_format()
Export drm_plane_has_format() so that drivers can use it.
v2: add kerneldoc
Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240619113144.1616-1-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Daniel Stone <daniels@collabora.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Jouni Högander [Thu, 20 Jun 2024 10:33:12 +0000 (13:33 +0300)]
drm/i915/psr: Set DP_PSR_SU_REGION_SCANLINE_CAPTURE bit when needed
Setting DP_PSR_SU_REGION_SCANLINE_CAPTURE (Selective Update Region Scan
Line Capture Indication in spec) bit was dropped when psr_enable_sink was
split to _psr_enable_sink and _panel_replay_enable_sink. Add setting it
back.
Imre Deak [Tue, 18 Jun 2024 12:52:55 +0000 (15:52 +0300)]
drm/xe: Use the encoder suspend helper also used by the i915 driver
Use the suspend encoders helper which is also used by the i915 driver.
This fixes an issue in the xe driver where the encoder
suspend_complete() hook is not called and was an overlook when this hook
was added in commit b61fad5f7e5d ("drm/i915/tc: Call TypeC port
flush_work/cleanup without modeset locks held") for i915, but not added
to the xe driver (which was still in a separate source tree at the above
point).
Ville Syrjälä [Tue, 11 Jun 2024 13:33:43 +0000 (16:33 +0300)]
drm/i915/dsb: Document that the ATS fault bits are for mtl+
The ATS faults have something to do with some new iommu stuff
on mtl+. Document that the relevant DSB interrupt bits aren't
valid for earlier platforms.
As we extend the use of DSB for critical pipe/plane register
programming, it'll be nice to have an escape valve at hand,
in case things go very poorly. To that end, add a i915.enable_dsb
modparam by which we can force the driver to take the pure mmio
path instead.
v2: Use 0400 permissions for the actual modparam (Jani)
Ville Syrjälä [Tue, 11 Jun 2024 13:33:37 +0000 (16:33 +0300)]
drm/i915: Introduce intel_mode_vdisplay()
The DSB code will need to know the hardware's idea of vertical
active, as that is also what defines the start of undelayed
vblank. Introduce a helper that gives us that information,
in line with the other intel_mode_v*() functions.
Ville Syrjälä [Wed, 5 Jun 2024 11:18:30 +0000 (14:18 +0300)]
drm/i915: Nuke the intermediate pipe fault bitmasks
GEN8_DE_PIPE_IRQ_FAULT_ERRORS & co. don't really achieve anything.
Get rid of them and just declare all the bits directly in
gen8_de_pipe_fault_mask().
Ville Syrjälä [Wed, 5 Jun 2024 11:18:29 +0000 (14:18 +0300)]
drm/i915: Extend GEN9_PIPE_PLANE_FLIP_DONE() to cover all universal planes
GEN9_PIPE_PLANE_FLIP_DONE() only works for planes 1-4. Extend
it handle planes 5-7 as well. Somewhat annoyingly the bits are
spread around into two distinct clumps.
Currently this doesn't achieve anything, but if we ever extend
async flip support to more than just the first plane then we'll
need this.
Ville Syrjälä [Wed, 5 Jun 2024 11:18:28 +0000 (14:18 +0300)]
drm/i915: Sort bdw+ pipe interrupt bits
It's really hard to figure out which bdw+ pipe interrupt bits
we've defined and which we have not. Sort the defines to make
that a bit easier (still not super easy since the bits have
been shuffled a bit over the years).
We want to notice possible issues faced with PSR2 Region Early Transport as
early as possible -> let's revert patch disabling Region Early Transport by
default. Also eDP 1.5 Panel Replay requires Early Transport.
Jouni Högander [Tue, 18 Jun 2024 05:30:22 +0000 (08:30 +0300)]
drm/i915/psr: Disable PSR2 SU Region ET if enable_psr module parameter is set
Currently PSR2 SU Region Early Transport is enabled by default on Lunarlake
if panel supports it despite enable_psr module parameter value. This patch
makes it possible for user to limit used PSR mode and prevent SU Region
Early Transport by setting enable_psr as 2. With default (-1) PSR2 SU
Region Early Transport is allowed.
Jouni Högander [Tue, 18 Jun 2024 05:30:21 +0000 (08:30 +0300)]
drm/i915/psr: Disable Panel Replay if PSR mode is set via module parameter
If user is specifically limiting PSR mode to PSR1 or PSR2: disable Panel
Replay. With default value -1 all modes are allowed including Panel
Replay. Disabling PSR using value 0 disables Panel Replay as well.
Also own compute config helper is added for Panel Replay. This makes sense
because number of Panel Replay specific checks are increasing.
Vinod Govindapillai [Tue, 28 May 2024 11:48:26 +0000 (14:48 +0300)]
drm/i915/display: update handling of FBC when VT-d active workaround
Move the handling of the disabling FBC when VT-d is active wa
as part of the intel_fbc_check_plane(). As the hw is still there,
intel_fbc_sanitize should be able to handle the state properly.
v2: update the patch description (Jani Nikula)
v3: fix the return value in wa handling (Jani Nikula)
Jani Nikula [Fri, 14 Jun 2024 09:22:37 +0000 (12:22 +0300)]
drm/i915: use i9xx_fsb_freq() for GT clock frequency
Reuse i9xx_fsb_freq() for GT clock frequency initialization instead of
depending on rawclk_freq.
Note: If the init order was changed, we could use i915->fsb_freq
directly. However, GT clock initialization is done in
i915_driver_mmio_probe(), but intel_dram_detect() later in
i915_driver_hw_probe(), with a dependency on intel_pcode_init().
Jani Nikula [Fri, 14 Jun 2024 09:22:35 +0000 (12:22 +0300)]
drm/i915: convert fsb_freq and mem_freq to kHz
We'll want to use fsb frequency for deriving GT clock and rawclk
frequencies in the future. Increase the accuracy by converting to
kHz. Do the same for mem freq to be aligned.
Round the frequencies ending in 666 to 667.
v2: Also handle mem_freq in gen5_rps_init() (Ville)
projects / nvme.git / log