Jani Nikula [Wed, 20 Nov 2024 12:43:09 +0000 (14:43 +0200)]
drm/i915/mst: pass intel_dp around in mst stream helpers
All of the functions in question operate on the primary encoder, and
more specifically the primary intel_dp, so pass it around instead of the
encoder for less ambiguity.
Ankit Nautiyal [Wed, 13 Nov 2024 11:55:31 +0000 (17:25 +0530)]
drm/i915/display/xe3lpd: Avoid setting YUV420_MODE in PIPE_MISC
For Xe3_LPD the PIPE_MISC YUV420 Enable (bit 27), already implies enabling
full blend YUV420 mode and YUV420 Mode (bit 26) is removed.
Therefore, avoid setting YUV420 Mode for Xe3_LPD+ while programming
PIPE_MISC for YCbCr420 output format.
Animesh Manna [Tue, 5 Nov 2024 10:39:16 +0000 (16:09 +0530)]
drm/i915/psr: Disable psr1 if setup_time > vblank
Issue is seen when PSR enabled with setup frames and when try to disable
PSR at SRDONACK State (0x1). PSR FSM is stuck at SRDONACK(0x1) for more
than 5 seconds. Issue not seen with Setup frames disabled. Currently
disable psr1 if setuptime > vblank to workaround the above issue.
Imre Deak [Mon, 18 Nov 2024 13:10:44 +0000 (15:10 +0200)]
drm/i915/dp_mst: Fix connector initialization in intel_dp_add_mst_connector()
The connector initialization in intel_dp_add_mst_connector() depends on
the device pointer in connector to be valid, at least by connector
debug printing. The device pointer is initialized by drm_connector_init(),
however that function also exposes the connector to in-kernel users,
which can't be done before the connector is fully initialized. For now
make sure the device pointer is valid before it's used, until a
follow-up change moving this to DRM core.
This issue was revealed by the commit in the Fixes: line below, before
which the above debug printing checked and handled a NULL device pointer
gracefully in DRM core.
Cc: Jani Nikula <jani.nikula@intel.com> Fixes: 529798bd786a ("drm/i915/mst: convert to struct intel_display") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12799 Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241118131044.1278028-1-imre.deak@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
drm/i915/dp: Include the time taken by AUX Tx for timeout
As per DP spec the timeout for LANE_CHANNEL_EQ_DONE is 400ms. But this
timeout value is exclusively for the Aux RD Interval and excludes the
time consumed for the AUX Tx (i.e reading/writing FFE presets). Add
another 50ms for these AUX Tx to the 400ms timeout.
Ref: "Figure 3-52: 128b132b DP DPTC LANEx_CHANNEL_EQ_DONE Sequence" of
DP2.1a spec.
Co-developed-by: Srikanth V NagaVenkata <nagavenkata.srikanth.v@intel.com> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240925034432.1777029-4-arun.r.murthy@intel.com
Arun R Murthy [Fri, 11 Oct 2024 04:58:25 +0000 (10:28 +0530)]
drm/i915/dp: read Aux RD interval just before setting the FFE preset
Figure 3-52: 128b132b DP DPTC LANEx_CHANNEL_EQ_DONE Sequence of
DP2.1a spec.
After reading LANEx_CHANNEL_EQ_DONE, read the FFE presets.
AUX_RD_INTERVAL and then write the new FFE presets.
v4: Read AUX_RD_INTERVAL before get/set TX FFE preset (Jani)
drm/i915/dp: use fsleep instead of usleep_range for LT
Sleeping for < 10us use udelay, for 10us to 20ms use usleep_range() and
for > 10ms use msleep. flseep() will call the particular API based on
the above condition. (Documentation/timers/timers-howto.rst)
Aux RD Interval value depends on the value read from the dpcd register
which is updated from the sink device, hence use flseep.
Rodrigo Vivi [Wed, 13 Nov 2024 22:50:16 +0000 (17:50 -0500)]
drm/{i915, xe}: Move power_domains suspend/resume to display_power
Move intel_power_domains_{suspend,resume} to inside
intel_display_power_{suspend_late, resume_early}.
With this also change the VLV suspend failure to call
the intel_display_power_resume_early. In the end, the only
function executed there for VLV is the intel_power_domains_resume.
Besides make the code more consistency give the call that was
immediately before: intel_display_power_suspend_late.
Rodrigo Vivi [Wed, 13 Nov 2024 22:50:11 +0000 (17:50 -0500)]
drm/i915/display: Convert i915_suspend into i9xx_display_sr
These save & restore functions inside i915_suspend are old display
functions to save and restore a bunch of display related registers.
Move it under display and rename accordantly. Just don't move it
entirely towards intel_display struct yet because it depends
on drm_i915_private for the IS_MOBILE.
While doing this conversion also update the MIT header using
the new SPDX ones.
v2: Fix Makefile and include (Jani)
Removed vga and gmbus (Jani, Ville)
Ankit Nautiyal [Wed, 30 Oct 2024 08:41:00 +0000 (14:11 +0530)]
drm/i915/dp: Limit max compressed bpp to 18 when forcing DSC
While forcing DSC when it is not actually required, the max compressed
bpp from the source gets picked for compression for some pipe bpps.
Apparently, when DSC is not required, forcing DSC to the maximum compressed
bpp seems to cause underruns.
To avoid this, limit the max compressed bpp to 18 while forcing DSC. This
value works across platforms with different pipe bpps and prevents
underruns.
Jani Nikula [Tue, 12 Nov 2024 11:10:44 +0000 (13:10 +0200)]
drm/i915/dp: add comments about hooks called from MST stream encoders
It would be best to have self-explanatory code, but lacking that, add
some comments about the way the DDI encoder hooks get called from DP MST
stream encoders.
Jani Nikula [Tue, 12 Nov 2024 11:10:43 +0000 (13:10 +0200)]
drm/i915/mst: change naming from fake encoders to MST stream encoders
The fake encoders pretty much match individual MST streams. The encoders
remain as fake as ever, but change the naming to MST stream
encoders. Rename all the encoder hooks and related functions called from
them to mst_stream_* to clarify what type of encoders the hooks are
called on.
Jani Nikula [Tue, 12 Nov 2024 11:10:42 +0000 (13:10 +0200)]
drm/i915/mst: convert to struct intel_display
struct intel_display will replace struct drm_i915_private as the main
display device data structure. Convert the DP MST code to struct
intel_display as much as possible.
Jani Nikula [Tue, 12 Nov 2024 11:10:41 +0000 (13:10 +0200)]
drm/i915/display: make CHICKEN_TRANS() display version aware
Making register macros platform or display version aware is not exactly
something I want to promote widely, but in this case it's the lesser of
two evils. hsw_chicken_trans_reg() is not pretty, and it doesn't have a
suitable home.
Jani Nikula [Tue, 12 Nov 2024 11:10:39 +0000 (13:10 +0200)]
drm/i915/mst: introduce to_primary_encoder() and to_primary_dp()
Add helpers to_primary_encoder() and to_primary_dp() to convert fake MST
encoder pointers to primary encoder and DP pointers, respectively, and
use them.
The main point is to highlight the primary encoder and DP usage. Very
few places actually need the struct intel_dp_mst_encoder pointer, or the
primary struct intel_digital_port, so ditch them where possible for
clarity.
Jani Nikula [Tue, 12 Nov 2024 11:10:37 +0000 (13:10 +0200)]
drm/i915/mst: pass primary encoder to primary encoder hooks
Pass the primary encoder to the primary encoder hooks. This is
pedantically correct, but intel_ddi_post_pll_disable() also works with
the fake encoder by coincidence.
Jani Nikula [Mon, 11 Nov 2024 10:34:04 +0000 (12:34 +0200)]
drm/i915/display: add mobile platform group
Identify mobile platforms separately in display, using the platform
group mechanism. This enables dropping the dependency on i915_drv.h
IS_MOBILE() from display code.
Jani Nikula [Mon, 11 Nov 2024 10:34:03 +0000 (12:34 +0200)]
drm/i915/display: pass struct pci_dev * to intel_display_device_probe()
Convert intel_display_device_probe() to accept struct pci_dev * instead
of struct drm_i915_private *. Return struct intel_display * in
preparation of allocating the memory of it later.
Jani Nikula [Mon, 11 Nov 2024 10:34:02 +0000 (12:34 +0200)]
drm/i915/display: convert display device identification to struct intel_display
Convert intel_display_device.[ch] to struct intel_display, including
callers, but excluding intel_display_device_probe() which will be
handled in follow-up.
Jani Nikula [Mon, 11 Nov 2024 10:33:50 +0000 (12:33 +0200)]
drm/i915/display: identify discrete graphics
Identify discrete graphics separately in display, using the platform
group mechanism. This enables dropping the dependency on i915_drv.h
IS_DGFX() from display code.
Start grouping platform groups separately in INTEL_DISPLAY_PLATFORMS()
in anticipation of more groups to come.
Suraj Kandpal [Mon, 4 Nov 2024 03:59:51 +0000 (09:29 +0530)]
drm/i915/hdcp: Fix when the first read and write are retried
Make sure that the first read/write in hdcp2_authentication_key_exchange
are only retried when we have either DP/DPMST encoder connected,
since we do this to give docks and dp encoders some extra time to
get their HDCP DPCD registers ready only for DP/DPMST encoders as
this issue is only observed here no need to burden other encoders
with extra retries as this causes the HDMI connector to have some
other timing issue and fails HDCP authentication.
--v2
-Add intent of patch [Chaitanya]
-Add reasoning for loop [Jani]
-Make sure we forfiet the 50ms wait for non DP/DPMST encoders.
--v3
-Remove the is_dp_encoder check [Jani/Chaitanya]
-Make the commit message more clearer [Jani]
Ville Syrjälä [Thu, 7 Nov 2024 12:26:55 +0000 (14:26 +0200)]
drm/i915/scaler: Convert the scaler code to intel_display
struct intel_display will replace struct drm_i915_private as
the main thing for display code. Convert the scaler code to
use it (as much as possible at this stage).
Ville Syrjälä [Thu, 7 Nov 2024 12:26:54 +0000 (14:26 +0200)]
drm/i915/scaler: Clean up intel_atomic_setup_scalers() a bit
intel_atomic_setup_scalers() is currently messing around with
the internals of the atomic states. Stop doing that and instead
use the regular interfaces so that we don't need to know any ugly
implementation details.
Ville Syrjälä [Thu, 7 Nov 2024 12:26:53 +0000 (14:26 +0200)]
drm/i915/scaler: Pass the whole atomic state into intel_atomic_setup_scalers()
intel_atomic_setup_scalers() currently digs out the full atomic
state from the crtc state. Flip that on its head so that we instead
pass in the full atomic state and dig out the crtc state (and whatever
else we need). This is generallte the better approach as it works
in all phases of the atomic commit, whereas the other apporoach only
really works during .atomic_check().
Ville Syrjälä [Thu, 7 Nov 2024 16:11:18 +0000 (18:11 +0200)]
drm/i915/crt: Clean up ADPA_HOTPLUG_BITS definitions
ADPA_HOTPLUG_BITS is defined in terms of the individual
register bits and is defined in intel_crt.c, whereas the
counterpart mask (ADPA_CRT_HOTPLUG_MASK) is just defined
as a raw hex constant and lives in i915_reg.h. Just define
both the same way (with unified name to boot) and move both
to intel_crt.c since they are more an implementation detail
rather than anything to do with the actual register definitions.
Ville Syrjälä [Thu, 7 Nov 2024 16:11:14 +0000 (18:11 +0200)]
drm/i915: Grab intel_display from the encoder to avoid potential oopsies
Grab the intel_display from 'encoder' rather than 'state'
in the encoder hooks to avoid the massive footgun that is
intel_sanitize_encoder(), which passes NULL as the 'state'
argument to encoder .disable() and .post_disable().
TODO: figure out how to actually fix intel_sanitize_encoder()...
Jani Nikula [Tue, 29 Oct 2024 11:32:48 +0000 (13:32 +0200)]
drm/i915/psr: add LATENCY_REPORTING_REMOVED() register bit helper
Drop the wa_16013835468_bit_get() function in favour of the register
macro. It doesn't have to be so complicated, and we don't have to use
the workaround name in everything that's related to it.
Jani Nikula [Wed, 6 Nov 2024 16:23:25 +0000 (18:23 +0200)]
drm/i915/dp: demote source OUI read/write failure logging to debug
Commit 1f12d63a14d7 ("drm/i915/dp: Write the source OUI for non-eDP
sinks as well") started writing source OUI for non-eDP sinks as well,
increasing the possibilities of hitting read/write failures either due
to the sink behaviour or hotplug or whatever.
Even before that, commit 3fb0501f0c07 ("drm/i915/display/dp: Reduce log
level for SOURCE OUI write failures") already reduced write failures to
info level when source OUI was just for eDP.
Further reduce the log level to just debug. Switch to struct
intel_display while at it.
Gustavo Sousa [Fri, 8 Nov 2024 12:57:20 +0000 (09:57 -0300)]
drm/i915/xe3lpd: Use DMC wakelock by default
Although Bspec doesn't explicitly mentions that, as of Xe3_LPD, using
DMC wakelock is the officially recommended way of accessing registers
that would be off during DC5/DC6 and the legacy method (where the DMC
intercepts MMIO to wake up the hardware) is to be avoided.
As such, update the driver to use the DMC wakelock by default starting
with Xe3_LPD. Since the feature is somewhat new to the driver, also
allow disabling it via a module parameter for debugging purposes.
For that, make the existing parameter allow values -1 (per-chip
default), 0 (disabled) and 1 (enabled), similarly to what is done for
other parameters.
v2:
- Describe -1 in the same area where 0 and 1 are described. (Luca)
Gustavo Sousa [Fri, 8 Nov 2024 12:57:18 +0000 (09:57 -0300)]
drm/i915/dmc_wl: Add and use HAS_DMC_WAKELOCK()
A HAS_DMC_WAKELOCK() macro gives more semantic than openly checking the
display version. Define it and use it where appropriate.
v2:
- Make this patch contain only the non-functional refactor. Functional
changes related to including HAS_DMC() in the macro are done in
upcoming changes. (Jani)
Gustavo Sousa [Fri, 8 Nov 2024 12:57:17 +0000 (09:57 -0300)]
drm/i915/dmc_wl: Couple enable/disable with dynamic DC states
Enabling and disabling the DMC wakelock should be done as part of
enabling and disabling of dynamic DC states, respectively. We should not
enable or disable DMC wakelock independently of DC states, otherwise we
would risk ending up with an inconsistent state where dynamic DC states
are enabled and the DMC wakelock is disabled, going against current
recommendations and making MMIO transactions potentially slower. In
future display IPs that could have a worse outcome if DMC trap
implementation is completely removed.
So, let's make things safer by tying stuff together, removing the
independent calls, and also put warnings in place to detect inconsistent
calls.
Gustavo Sousa [Fri, 8 Nov 2024 12:57:16 +0000 (09:57 -0300)]
drm/i915/dmc_wl: Deal with existing references when disabling
It is possible that there are active wakelock references at the time we
are disabling the DMC wakelock mechanism. We need to deal with that in
two ways:
(A) Implement the missing step from Bspec:
The Bspec instructs us to clear any existing wakelock request bit
after disabling the mechanism. That gives a clue that it is okay to
disable while there are locks held and we do not need to wait for
them. However, since the spec is not explicit about it, we need
still to get confirmation with the hardware team. Let's thus
implement the spec and add a TODO note.
(B) Ensure a consistent driver state:
The enable/disable logic would be problematic if the following
sequence of events would happen:
1. Function A calls intel_dmc_wl_get();
2. Some function calls intel_dmc_wl_disable();
3. Some function calls intel_dmc_wl_enable();
4. Function A is done and calls intel_dmc_wl_put().
At (2), the refcount becomes zero and then (4) causes an invalid
decrement to the refcount. That would cause some issues:
- At the time between (3) and (4), function A would think that
the hardware lock is held but it could not be really held
until intel_dmc_wl_get() is called by something else.
- The call made to (4) could cause the refcount to become zero
and consequently the hardware lock to be released while there
could be innocent paths trusting they still have the lock.
To fix that, we need to keep the refcount correctly in sync with
intel_dmc_wl_{get,put}() calls and retake the hardware lock when
enabling the DMC wakelock with a non-zero refcount.
One missing piece left to be handled here is the following scenario:
1. Function A calls intel_dmc_wl_get();
2. Some function calls intel_dmc_wl_disable();
3. Some function calls intel_dmc_wl_enable();
4. Concurrently with (3), function A performs the MMIO in between
setting DMC_WAKELOCK_CFG_ENABLE and asserting the lock with
__intel_dmc_wl_take().
I'm mostly sure this would cause issues future display IPs if DMC
trap implementation was completely removed. We need to check with
the hardware team whether it would be safe to assert the hardware
lock before setting DMC_WAKELOCK_CFG_ENABLE to avoid this scenario.
If not, then we would have to deal with that via software
synchronization.
Gustavo Sousa [Fri, 8 Nov 2024 12:57:15 +0000 (09:57 -0300)]
drm/i915/dmc_wl: Allow simpler syntax for single reg in range tables
Allow simpler syntax for defining entries for single registers in range
tables. That makes them easier to type as well as to read, allowing one
to quickly tell whether a range actually refers to a single register or
a "true range".
Gustavo Sousa [Fri, 8 Nov 2024 12:57:14 +0000 (09:57 -0300)]
drm/i915/dmc_wl: Track registers touched by the DMC
There are extra registers that require the DMC wakelock when specific
dynamic DC states are in place. Those are registers that are touched by
the DMC and require DC exit for proper access. Add the range tables for
them and use the correct one depending on the enabled DC state.
v2:
- Do not look into power domains guts (i.e.
display->power.domains.dc_state). (Jani)
- Come up with better names for variables containing register ranges.
(Luca)
- Keep a copy of dc_state in struct intel_dmc_wl.
- Update commit message for a clearer explanation for the need of
these new tables.
Gustavo Sousa [Fri, 8 Nov 2024 12:57:13 +0000 (09:57 -0300)]
drm/i915/dmc_wl: Rename lnl_wl_range to powered_off_ranges
In an upcoming change, we will add extra range tables for registers that
are touched by the DMC during DC states. The range table that we are
currently using is meant for registers that are powered off during DC
states. As such, let's rename the table to powered_off_ranges and also
add a comment regarding its purpose in the function that uses it.
We will be using more than one range table in
intel_dmc_wl_check_range(). As such, move the logic to a new function
and name it intel_dmc_wl_reg_in_range().
Gustavo Sousa [Fri, 8 Nov 2024 12:57:11 +0000 (09:57 -0300)]
drm/i915/dmc_wl: Use sentinel item for range tables
We are currently using ARRAY_SIZE() to iterate address ranges in
intel_dmc_wl_check_range(). In upcoming changes, we will be using more
than a single table and will extract the range checking logic into a
dedicated function that takes a range table as argument. As we will not
able to use ARRAY_SIZE() then, let's make range tables contain a
sentinel item at the end and use that instead of having to pass the size
as parameter in this future function.
Gustavo Sousa [Fri, 8 Nov 2024 12:57:09 +0000 (09:57 -0300)]
drm/i915/dmc_wl: Check for non-zero refcount in release work
When the DMC wakelock refcount reaches zero, we know that there are no
users and that we can do the actual release operation on the hardware,
which is queued with a delayed work. The idea of the delayed work is to
avoid performing the release if a new lock user appears (i.e. refcount
gets incremented) in a very short period of time.
Based on the above, the release work should bail out if refcount is
non-zero (meaning new lock users appeared in the meantime), but our
current code actually does the opposite: it bails when refcount is zero.
That means that the wakelock is not released when it should be; and
that, when the work is not canceled in time, it ends up being releasing
when it should not.
Gustavo Sousa [Fri, 8 Nov 2024 12:57:08 +0000 (09:57 -0300)]
drm/i915/dmc_wl: Use non-sleeping variant of MMIO wait
Some display MMIO transactions for offsets in the range that requires
the DMC wakelock happen in atomic context (this has been confirmed
during tests on PTL). That means that we need to use a non-sleeping
variant of MMIO waiting function.
Implement __intel_de_wait_for_register_atomic_nowl() and use it when
waiting for acknowledgment of acquire/release.
v2:
- No __intel_de_wait_for_register_atomic_nowl() wrapper to convert
i915 to display. (Jani)
- Add a quick explanation why DMC_WAKELOCK_CTL_TIMEOUT_US is defined
in microseconds. (Luca)
Gustavo Sousa [Fri, 8 Nov 2024 12:57:07 +0000 (09:57 -0300)]
drm/xe: Mimic i915 behavior for non-sleeping MMIO wait
In upcoming display changes, we will modify the DMC wakelock MMIO
waiting code to choose a non-sleeping variant implementation, because
the wakelock is also taking in atomic context.
While xe provides an explicit parameter (namely "atomic") to prevent
xe_mmio_wait32() from sleeping, i915 does not and implements that
behavior when slow_timeout_ms is zero.
So, for now, let's mimic what i915 does to allow for display to use
non-sleeping MMIO wait. In the future, we should come up with a better
and explicit interface for this behavior in i915, at least while display
code is not an independent entity with proper interfaces between xe and
i915.
v2:
- Make the tone in comment the comment added in
__intel_wait_for_register() more explanatory than a FIXME-like text.
(Luca)
Suraj Kandpal [Thu, 7 Nov 2024 02:28:08 +0000 (07:58 +0530)]
drm/i915/hdcp: Handle HDCP Line Rekeying for HDCP 1.4
TRANS_DDI_FUNC_CTL asks us to disable hdcp line rekeying when not in
hdcp 2.2 and we are not using an hdmi transcoder and it need to be
enabled when we are using an HDMI transcoder to enable HDCP 1.4.
We use intel_de_rmw cycles to update TRANS_DDI_FUNC_CTL register so
we cannot depend on the value being 0 by default everytime which calls
for seprate handling of HDCP 1.4 case.
--v2
-Use the exising function and modify it based on a bool rather than
have a different function [Matt]
--v3
-No need for kzalloc [Jani]
--v4
-i915_reg_t should not be pointer [Jani]
-use rekey_bit to ensure when writing to reg everything is initialized
Ville Syrjälä [Tue, 29 Oct 2024 21:52:17 +0000 (23:52 +0200)]
drm/i915/cdclk: Unify cdclk max() parameter order
In some places we do
min_cdclk = max(min_cdclk, other_min_cdclk)
and in other places we have the arguments swapped as
min_cdclk = max(other_min_cdclk, min_cdclk)
Unify everyone to use the first order of arguments, because
it looks cleaner, especially within intel_crtc_compute_min_cdclk()
which is doing a lot of these back-to-back.
Ville Syrjälä [Tue, 29 Oct 2024 21:52:10 +0000 (23:52 +0200)]
drm/i915/cdclk: Extract intel_audio_min_cdclk()
Pull the audio min cdclk calculation into a helper and hide
it inside intel_audio.c in order to keep most audio related
details in one place.
The one audio related thing that remains in intel_cdclk.c
is commit 451eaa1a614c ("drm/i915: Bump GLK CDCLK frequency when
driving multiple pipes") but given that's implemented in terms
of the cdclk_state I think it should stay put.
Ville Syrjälä [Tue, 29 Oct 2024 21:52:09 +0000 (23:52 +0200)]
drm/i915/cdclk: Extract hsw_ips_min_cdclk()
Pull the whole BDW IPS min CDCLK stuff into the IPS code
so that all the details around IPS are contained in once
place.
Note that while
- min_cdclk = DIV_ROUND_UP(min_cdclk * 100, 95);
vs.
+ min_cdclk = max(DIV_ROUND_UP(crtc_state->pixel_rate * 100, 95), min_cdclk)
may look different, they are in fact the same because
min_cdclk==crtc_state->pixel_rate at this point in
intel_crtc_compute_min_cdclk() on BDW.
Ville Syrjälä [Tue, 29 Oct 2024 21:52:08 +0000 (23:52 +0200)]
drm/i915/cdclk: Extract intel_cdclk_guardband() and intel_cdclk_ppc()
We are duplicating the CDCLK guardband and "pixels per clock"
figures in two places. Pull those out into small helpers that
can be used by both places.
Ville Syrjälä [Wed, 6 Nov 2024 22:09:04 +0000 (00:09 +0200)]
drm/i915/dsi: Stop using pixel_format_from_register_bits() to parse VBT
Introduce a proper VBT->enum mipi_dsi_pixel_format converter
instead of abusing pixel_format_from_register_bits() (whose
job is to parse the pixel format from some pre-ICL DSI
hardware register).
Imre Deak [Wed, 30 Oct 2024 19:23:12 +0000 (21:23 +0200)]
drm/i915/adlp+/dp_mst: Align slave transcoder sequences with spec wrt. DP2 config
On ADLP+ during modeset enabling and disabling, enable and disable the DP2
configuration for MST slave transcoders as required by the specification.
Update the documentation of intel_ddi_config_transcoder_func() /
intel_ddi_disable_transcoder_func() based on the above. While at it also
clarify the programming steps of these functions specific to transcoder
types.
v2:
- Enable/disable the DP2 config from
intel_ddi_config_transcoder_func()/intel_ddi_disable_transcoder_func().
(Jani)
- Handle all ADLP+ platforms in one patch, instead of doing that
separately wrt. PTL.
Imre Deak [Wed, 30 Oct 2024 19:23:10 +0000 (21:23 +0200)]
drm/i915/adlp+/dp_mst: Align slave transcoder enabling with spec wrt. DDI function
On ADLP+ during modeset enabling configure the DDI function without
enabling it for MST slave transcoders before programming the data and
link M/N values. The DDI function gets enabled separately later in the
transcoder enabling sequence.
Align the code with the spec based on the above.
v2: Move this patch earlier in the series, addressing the DP2
config fixes for all ADLP+ platforms later.
Imre Deak [Wed, 30 Oct 2024 19:23:09 +0000 (21:23 +0200)]
drm/i915/ptl/dp_mst: Fix slave transcoder enabling wrt. DDI function
On PTL during modeset enabling configure the DDI function without
enabling it for MST slave transcoders before programming the data and
link M/N values. The DDI function gets enabled separately later in the
transcoder enabling sequence.
This fixes a slave transcoder getting stuck during enabling, leading
to page flip timeout errors on the corresponding pipe.
The spec requires the same programming step for ADLP+ platforms, that
will be addressed separately (on those platforms the above transcoder
getting stuck issue was not observed).
Ville Syrjälä [Thu, 31 Oct 2024 15:56:45 +0000 (17:56 +0200)]
drm/i915: Sanitize MBUS joining
If the system boots with MBUS joining enabled but we disable
the relevant pipe during sanitation we later get into trouble
as the rest of the code doesn't expect MBUS joining to be
enabled unless the set of active pipes is in agreement.
We could relax some of the MBUS joining related checks during
normal atomic commits to let this slide, but that might also
let some real bugs through. So let's sanitize the MBUS joining
instead. And in order to keep things more or less in sync we'll
do the related credit, cdclk/mdclk ratio, etc. updates as well.
We'll stick to sturct drm_i915_private for now (instead of
struct intel_display) since the rest of the skl wm code does the
same, and we might need to bakport this.
Ville Syrjälä [Thu, 31 Oct 2024 15:56:44 +0000 (17:56 +0200)]
drm/i915: Extract mbus_ctl_join_update()
We'll be wanting to reprogram the MBUS_CTL register during an
upcoming MBUS sanitation stage. Extract the reprogramming
into a helper that doesn't depend on the full atomic state
so that it can be reused.
We'll stick to sturct drm_i915_private for now (instead of
struct intel_display) since the rest of the skl wm code does the
same, and we might need to bakport this.
Ville Syrjälä [Thu, 31 Oct 2024 15:56:43 +0000 (17:56 +0200)]
drm/i915: Extract pipe_mbus_dbox_ctl_update()
We'll be wanting to reprogram the PIPE_MBUS_DBOX_CTL registers
during an upcoming MBUS sanitation stage. Extract the reprogramming
loop into a helper that doesn't depend on the full atomic state
so that it can be reused.
We'll stick to sturct drm_i915_private for now (instead of
struct intel_display) since the rest of the skl wm code does the
same, and we might need to bakport this.
Ville Syrjälä [Thu, 31 Oct 2024 15:56:42 +0000 (17:56 +0200)]
drm/i915: Extract pipe_mbus_dbox_ctl()
We'll be wanting to reprogram the PIPE_MBUS_DBOX_CTL registers
during an upcoming MBUS sanitation stage. To make that easier
extract a helper that computes the full register value for us.
Ville Syrjälä [Thu, 31 Oct 2024 15:56:41 +0000 (17:56 +0200)]
drm/i915: Relocate the SKL wm sanitation code
In order to add more MBUS sanitation into the code we'll want
to reuse a bunch of the code that performs the MBUS/related
hardware programming. Currently that code comes after the
main skl_wm_get_hw_state_and_sanitize() entrypoint. In order
to avoid annoying forward declarations relocate the
skl_wm_get_hw_state_and_sanitize() and related stuff nearer to
the end of the file.
projects / thirdparty / kernel / linux.git / log
