Ville Syrjälä [Fri, 1 Oct 2021 13:01:07 +0000 (16:01 +0300)]
drm/i915: Allow per-lane drive settings with LTTPRs
LTTPRs should support per-lane drive settings I think, and even if
they don't they should implement their own fallback logic to determine
suitable common drive settings to use for all the lanes.
Ville Syrjälä [Fri, 1 Oct 2021 13:01:06 +0000 (16:01 +0300)]
drm/i915: Prepare link training for per-lane drive settings
Adjust the link training code to accommodate per-lane drive settings,
if supported by the platform. Actually enabling this will involve
some changes to each platform's .set_signal_level() implementation,
so for the moment all supported platforms will keep using the current
codepath that just uses the same drive settings for all the lanes.
v2: Fix min() vs. max() fumble
v3: Compact the debug print to a single line
Ville Syrjälä [Fri, 1 Oct 2021 13:01:05 +0000 (16:01 +0300)]
drm/i915: Pass the lane to intel_ddi_level()
In order to have per-lane drive settings we need intel_ddi_level()
to accept the lane as a parameter. That is, the eventual goal is to
call intel_ddi_level() once for each lane. For now we just pass in
a hardcoded 0 and use the same settings for every lane. Ie. no
change in behaviour yet.
Ville Syrjälä [Fri, 1 Oct 2021 13:01:04 +0000 (16:01 +0300)]
drm/i915: Nuke intel_ddi_hdmi_num_entries()
Since intel_ddi_level() now looks at the buf_trans table there's
no point in having intel_ddi_hdmi_num_entries() around. Just
roll the necessary bits of locic into
intel_ddi_hdmi_level()/intel_ddi_level().
Ville Syrjälä [Fri, 1 Oct 2021 13:01:03 +0000 (16:01 +0300)]
drm/i915: Hoover the level>=n_entries WARN into intel_ddi_level()
All callers of intel_ddi_level() duplicate the check+WARN
to make sure the returned level is actually present in the
appropriate buf_trans table. Let's push that stuff into
intel_ddi_level() so the callers don't have to worry about it.
Now that .set_signal_levels() is used for HDMI as well, we can
remove the extra level of indirection and just plug the correct
stuff straight into .set_signal_levels().
Ville Syrjälä [Fri, 1 Oct 2021 13:01:00 +0000 (16:01 +0300)]
drm/i915: Generalize .set_signal_levels()
Currently .set_signal_levels() is only used by encoders in DP mode.
For most modern platforms there is no essential difference between
DP and HDMI, and both codepaths just end up calling the same function
under the hood. Let's get remove the need for that extra indirection
by moving .set_signal_levels() into the encoder from intel_dp.
Since we already plumb the crtc_state/etc. into .set_signal_levels()
the code will do the right thing for both DP and HDMI.
HSW/BDW/SKL are the only platforms that need a bit of care on
account of having to preload the hardware buf_trans register
with the full set of values. So we must still remember to call
hsw_prepare_{dp,hdmi}_ddi_buffers() to do said preloading, and
.set_signal_levels() will just end up selecting the correct entry
for DP, and also setting up the iboost magic for both DP and HDMI.
Note that previously on HSW/BDW/SKL we did write to DDI_BUF_CTL to
select the correct entry until link training started, now that we
call .set_signal_levels() already from hsw_ddi_pre_enable_dp() that
is no longer the case. But it's all safe now that the
intel_ddi_init_dp_buf_reg() call was hoisted up and it no longer
sets up the DDI_BUF_CTL_ENABLE bit (that is still deferred until
link training).
v2: Rebase due to has_{iboost,buf_trans_select}()
Add some notes about the DDI_BUF_CTL situation on HSW/BDW/SKL (Imre)
Ville Syrjälä [Fri, 1 Oct 2021 13:00:59 +0000 (16:00 +0300)]
drm/i915: Introduce has_buf_trans_select()
Add a small helper to determine if DDI_BUF_CTL uses the
DDI_BUF_TRANS_SELECT field, and whether we have the
accompanying DDI_BUF_TRANS table in the hardware.
The DP spec says:
"If the receiver keeps the same value in the ADJUST_REQUEST_LANEx_y
register(s) while the LANEx_CR_DONE bits remain unset, the transmitter
must loop four times with the same voltage swing. On the fifth time,
the transmitter must down-shift to the lower bit rate and must repeat
the CR-lock training sequence as described below."
Lets fix the code to follow that instead of terminating after five
times of transmitting the same signal levels. The text in spec feels
a little bit ambiguous still, but this is my best guess at its meaning.
As a bonus this also gets rid of the train_set[0] stuff which
would not work for per-lane drive settings anyway.
Ville Syrjälä [Tue, 28 Sep 2021 18:51:05 +0000 (21:51 +0300)]
drm/i915: Stop force enabling pipe bottom color gammma/csc
While sanitizing the hardware state we're currently forcing
the pipe bottom color legacy csc/gamma bits on. That is not a
good idea as BIOSen are likely to leave gabage in the LUTs and
so doing this causes ugly visual glitches if and when the
planes covering the background get disabled. This was exactly
the case on this Dell Precision 5560 tgl laptop.
On icl+ we don't normally even use these legacy bits
anymore and instead use their GAMMA_MODE counterparts.
On earlier platforms the bits are used, but we still
shouldn't force them on without knowing what's in the LUT.
So two options, get rid of the whole thing, or do what
intel_color_commit() does to make sure the bottom color state
matches whatever out hardware readout produced. I chose the
latter since it'll match what happens on older platforms when
the primary plane gets turned off. In fact let's just call
intel_color_commit(). It'll also do some CSC programming but
since we don't have readout for that it'll actually just set
to all zeros. So in the unlikely case of CSC actually being
enabld by the BIOS we'll end up with all black until the first
atomic commit happens.
Still not totally sure what we should do about color management
features here in general. Probably the safest thing would be to
force everything off exactly at the same time when we disable
the primary plane as there is no guarantees that whatever the
LUTs/CSCs contain make any sense whatsoever without the
specific pixel data in the BIOS fb. And if we preserve the
primary plane then we should disable the color management
features exactly when the primary plane fb contents first
changes since the new content assumes more or less no
transformations. But of course synchronizing front buffer
rendering with anything else is a bit hard...
"CRTC fixup failed" is probably leftovers from pre-atomic days
when there was an actual fixup() function. Let's unify the debug
messages between encoder vs. crtc compute_config() calls.
Jani Nikula [Thu, 30 Sep 2021 11:24:32 +0000 (14:24 +0300)]
drm/i915/dsi: fuse dsi_send_pkt_payld() and add_payld_to_queue()
Having two functions for this seems like excess duplication and
parameter juggling. Merge them together.
While at it, drop the extra error message, as wait_for_payload_credits()
already prints an error, and switch from incidental -EPERM (i.e. -1) to
actual error codes.
Jani Nikula [Thu, 30 Sep 2021 09:22:59 +0000 (12:22 +0300)]
drm/i915/pps: move pps (panel) modeset asserts to intel_pps.c
Move assert_panel_unlocked() to intel_pps.c and rename
assert_pps_unlocked(). Keep the functionality and the assert code
together.
There's still a bit of a split between the eDP PPS usage in intel_pps.c
and all the other PPS usage, and assert_pps_unlocked() is arguably more
related to the latter. However, intel_pps.c is the best fit for anything
touching the PPS registers.
With all the recent fixes PSR2 is properly working in Alderlake-P but
due to some issues that don't have software workarounds it will not be
supported in display steppings older than B0.
Even with this patch PSR2 will no be enabled by default in ADL-P, it
still requires enable_psr2_sel_fetch to be set to true, what some
of our tests does.
drm/i915/display/adlp: Optimize PSR2 power-savings in corner cases
The Wa_14014971508 is required to fix scanout when a feature that i915
do not support is enabled and this feature is not planned to be enabled
for adlp.
Keeping this workaround enabled can badly hurt power-savings when
a full frame fetch is required(see psr2_sel_fetch_plane_state_supported()
and psr2_sel_fetch_pipe_state_supported()).
Here a example that could badly hurt power-savings, userspace does
a page flip to a rotated plane, so CONTINUOS_FULL_FRAME set.
But then for a whole 30 seconds nothing in the screen requires updates
but because CONTINUOS_FULL_FRAME is set, it will not go into DC5/DC6.
Reverting Wa_14014971508 fixes that, as only a single frame will be
sent and then display can go to DC5/DC6 for those 30 seconds of
idleness.
drm/i915/display: Fix glitches when moving cursor with PSR2 selective fetch enabled
Legacy cursor APIs are handled by intel_legacy_cursor_update(), that
calls drm_atomic_helper_update_plane() when going through the
slow/atomic path to update cursor, what was the case for PSR2
selective fetch.
drm_atomic_helper_update_plane() sets
drm_atomic_state->legacy_cursor_update to true when updating the
cursor plane, to allow several cursor updates to happen within the
same frame, as userspace does that.
If drivers waited for a vblank increment at the end of every cursor
movement that would cause a visible lag in the cursor.
But this optimization do not properly work with PSR2 selective fetch
dirt area calculation, for example if within a single frame the cursor
had 3 moves the final dirt area programmed to PSR2_MAN_TRK_CTL would
be based in the second movement as old state and third movement as new
state, not updating the area where cursor was in the first state.
So here switching back to the fast path approach in
intel_legacy_cursor_update() and handling cursor movements as
frontbuffer rendering(psr_force_hw_tracking_exit()), that is not the
most optimal for power-savings but is the solution that we have until
mailbox style updates is implemented.
Also removing the cursor workaround as not it is properly undestand
the issue and is know that it will never cover all the cases.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210930001409.254817-5-jose.souza@intel.com
drm/i915/display: Handle frontbuffer rendering when PSR2 selective fetch is enabled
When PSR2 selective fetch is enabled writes to CURSURFLIVE alone do
not causes the panel to be updated when doing frontbuffer rendering.
From what I was able to figure from experiments the writes to
CURSURFLIVE takes PSR2 from deep sleep but panel is not updated
because PSR2_MAN_TRK_CTL has no start and end region set.
As we don't have the dirt area from current flush and invalidate API
and even if we did userspace could do several draws to frontbuffer and
we would need a way to append all the damaged areas of all the draws
that need to be part of next frame.
So here only programing PSR2_MAN_TRK_CTL to do a single full frame
fetch.
It is a safe approach as if scanout is in the visible area
the single full frame will only be visible for hardware in the next
frame because of the double buffering, and if scanout is in vblank
area it will be draw in the current frame.
No need to disable PSR and wait a few miliseconds to enable it again.
drm/i915/display: Drop unnecessary frontbuffer flushes
This unnecessary flushes are hurting power-savings are it causes
features like PSR, FBC and DRRS to disable it self to handle
frontbuffer rendering, below some explanation of why each removed
call is not necessary.
The flush in intel_prepare_plane_fb() is not required as framebuffer
will be flipped and power-saving features do the proper flip handling
in hardware.
intel_find_initial_plane_obj() flush is not required because it is
only executed during driver load and at this point the power-saving
features are not even enabled.
And the last one intelfb_create(), is also not required as at this
point the fbdev was just allocated, userspace will draw on
it what will trigger frontbuffer invalidates and flushes later on.
Gwan-gyeong Mun [Thu, 30 Sep 2021 00:14:02 +0000 (17:14 -0700)]
drm/i915/display/psr: Do full fetch when handling multi-planar formats
We are still missing the PSR2 selective fetch handling of multi-planar
formats but until proper handle is added we can workaround it by
doing full frames fetch when state has such formats.
drm/i915/display/psr: Handle plane and pipe restrictions at every page flip
PSR2 selective is not supported over rotated and scaled planes.
We had the rotation check in intel_psr2_sel_fetch_config_valid()
but that code path is only execute when a modeset is needed and
those plane parameters can change without a modeset.
Pipe selective fetch restrictions are also needed, it could be added
in intel_psr_compute_config() but pippe scaling is computed after
it is executed, so leaving as is for now.
There is no much loss in this approach as it would cause selective
fetch to not enabled as for alderlake-P and newer will cause it to
switch to PSR1 that will have the same power-savings as do full pipe
fetch.
Also need to check those restricions in the second
for_each_oldnew_intel_plane_in_state() loop because the state could
only have a plane that is not affected by those restricitons but
the damaged area intersect with planes that has those restrictions,
so a full pipe fetch is required.
Ville Syrjälä [Thu, 30 Sep 2021 13:43:10 +0000 (16:43 +0300)]
drm/i915: Nuke local copies/pointers of intel_dp->DP
Get rid of the local copies and pointers of intel_dp->DP and
instead just poke at it directly. Makes it much easier to see
where it actually gets used/modified.
Ville Syrjälä [Thu, 30 Sep 2021 13:43:09 +0000 (16:43 +0300)]
drm/i915: Remove DP_PORT_EN stuff from link training code
Setting DP_PORT_EN in intel_dp->DP is already handled by
intel_dp_enable_port() so there is no point in setting it also
from the link training code.
For DDI platforms a bit with that name doesn't even exist. The
counterpart is DDI_BUF_CTL_ENABLE, which is already set up by
intel_ddi_prepare_link_retrain(). Fortunately it is the same bit
so there was no harm in doing this from the platform independent
code as well. But it's just confusing when platform independent
code sets platform specific bits in intel_dp->DP. Just get rid
of it.
I want intel_dp->DP to be fully populated by the time the
initial vswing programming happens. To that end move the
intel_ddi_init_dp_buf_reg() call to an earlier spot.
Additionally we don't want intel_ddi_init_dp_buf_reg() to
set DDI_BUF_CTL_ENABLE since the port should only get enabled
at the start of link training (see intel_ddi_prepare_link_retrain()).
So any earlier write to the register should not set the enable bit.
Ville Syrjälä [Thu, 30 Sep 2021 13:43:07 +0000 (16:43 +0300)]
drm/i915: Clear leftover DP vswing/preemphasis values before modeset
Currently we clear the leftover vswing/preemphasis values only
at the start of link training. That means the initial vswing
programming performed during modeset is going to use stale values
left over from the previous link training sequence, and then at
the start of link training we're going to reset the levels back
to 0. Seems much better to make sure we start with level 0 from
the get go.
Additionally if LTTPRs are present the leftover vswing/preemphasis
values are those of the last link in the chain, so not the values
that our PHY is even using after a successful link training sequence.
So let's make sure everything is cleared up before we start
programming anything.
With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+"
the size of bdb_lfp_backlight_data structure has been increased,
causing if-statement in the parse_lfp_backlight function
that comapres this structure size to the one retrieved from BDB,
always to fail for older revisions.
This patch calculates expected size of the structure for a given
BDB version and compares it with the value gathered from BDB.
Tested on Chromebook Pixelbook (Nocturne) (reports bdb->version = 221)
Fixes: d381baad29b4 ("drm/i915/vbt: Fix backlight parsing for VBT 234+") Tested-by: Lukasz Majczak <lma@semihalf.com> Signed-off-by: Lukasz Majczak <lma@semihalf.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/20210930134606.227234-1-lma@semihalf.com
Ville Syrjälä [Mon, 13 Sep 2021 14:44:34 +0000 (17:44 +0300)]
drm/i915: Configure TRANSCONF just the once with bigjoiner
Let's not configure the single transcoder's TRANSCONF multiple
times with bigjoiner. No real harm I suppose but since we already
have the bigjoiner if statement directly above might as well suck
this in there and skip the redundant programming.
Ville Syrjälä [Mon, 13 Sep 2021 14:44:33 +0000 (17:44 +0300)]
drm/i915: Pimp HSW+ transcoder state readout
Adjust the HSW+ transcoder state readout to just read through
all the possible transcoders for the pipe, and stuff the results
in a bitmask.
We can conveniently cross check the bitmask for invalid
combinations of enabled transcoders, and later we can easily
extend the bitmask readout to handle the bigjoiner case.
One slight change in behaviour is that we no longer read out
the AONOFF->force_pfit.pfit bit for all the enabled "panel
transcoders". But having more than one enabled would anyway
be illegal so no big loss. Also the AONOFF selection should
only ever be used on HSW, which only has the EDP transcoder
an no DSI transcoders.
Ville Syrjälä [Fri, 24 Sep 2021 14:13:30 +0000 (17:13 +0300)]
drm/i915/fbc: Allow FBC with Yf tiling
FBC+Yf tiling seems to work just fine, and unlike with linear
the hardware does appear to correctly calculate the CFB stride
with using the override stride on both cfl and glk. So no need
for any additional tweaks.
Ville Syrjälä [Wed, 29 Sep 2021 16:24:04 +0000 (19:24 +0300)]
drm/i915: Enable TPS3/4 on all platforms that support them
Stop using HBR2/3 support as a proxy for TPS3/4 support.
The two are no longer 1:1 in the hardware, arguably they
never were due to HSW ULX which does support TPS3 while
being limited to HBR1.
In more recent times GLK gained support for TPS4 while
being limited to HBR2. And on CNL+ some ports support
HBR3 while others are limited to HBR2, but all ports
support TPS4.
Ville Syrjälä [Wed, 29 Sep 2021 18:45:36 +0000 (21:45 +0300)]
drm/i915: Reject user modes that don't match fixed mode's refresh rate
When using a panel with a fixed mode we don't change the refresh
rate of the display. Reject any user requested mode which doesn't
match that fixed refresh rate.
Unfortunately when Xorg sees the scaling_mode property on the
connecor it likes to automagically cook up modes whose refresh
rate is a fair bit off from the fixed refresh rate we use. So
we have to give it some extra latitude so that we don't start to
reject all of it.
v2: sDVO now uses intel_panel_compute_config() too
v3: Add a debug message to inform the user what happened
Ville Syrjälä [Mon, 27 Sep 2021 18:52:07 +0000 (21:52 +0300)]
drm/i915: Introduce intel_panel_compute_config()
Let's introduce a compute_config() helper for fixed mode panels.
For now all it does is the fixed_mode->adjusted_mode copy.
Note that with sDVO we have to ask the external encoder chip
to spit out our actual display timings for us, so the fixed_mode
to adjusted_mode copy done by intel_panel_compute_config() is
redundant, but we still want to use it to do other checks for us
later. We'll be fine so long as we only call it before
intel_sdvo_get_preferred_input_mode() overwrites adjusted_mode
with the timings from the encoder.
Ville Syrjälä [Thu, 23 Sep 2021 20:01:06 +0000 (23:01 +0300)]
drm/i915: Reject modes that don't match fixed_mode vrefresh
When using a fixed mode we won't change the refresh rate ever.
So filter out all modes that don't match the fixed_mode's refresh
rate.
I'm going to declare the "rounded to nearest Hz refresh
rates must match" approach good enough for now.
Note that we could start supporting multiple refresh rates
with panels that can do it, but that would mean replacing
the single fixed mode concept with a list of fixed modes.
Then we could look for the closest match to the user's
requested refresh rate and use that. But all of that would
be a fair bit of work so we'll leave it for later.
Ville Syrjälä [Thu, 23 Sep 2021 20:01:05 +0000 (23:01 +0300)]
drm/i915: Use intel_panel_mode_valid() for DSI/LVDS/(s)DVO
All fixed mode panels should behave the same way when it comes to mode
filtering. Reuse the intel_panel_mode_valid() for all of them.
This changes the behaviour to match what we do for eDP, ie.
reject anything that doesn't exactly match the fixed mode
dimensions. Users can still manually provide different
sized modes which will be handled by the panel fitter just
as before. The difference is that we can no longer report
funny modes in the connector's mode list.
Imre Deak [Wed, 29 Sep 2021 13:28:33 +0000 (16:28 +0300)]
drm/i915/tc: Fix system hang on ADL-P during TypeC PHY disconnect
The PHY ownership release->AUX PW disable steps during a modeset
disable->PHY disconnect sequence can hang the system if the PHY
disconnect happens after disabling the PHY's PLL. The spec doesn't
require a specific order for these two steps, so this issue is still
being root caused by HW/FW teams. Until that is found, let's make
sure the disconnect happens before the PLL is disabled, and do this on
all platforms for consistency.
v2: Add a TODO comment to remove the w/a once the issue is root
caused/fixed. (Jose)
Imre Deak [Tue, 21 Sep 2021 00:23:12 +0000 (03:23 +0300)]
drm/i915/tc: Drop extra TC cold blocking from intel_tc_port_connected()
After the previous patch the driver holds a power domain blocking
TC-cold whenever the port is locked, so we can remove the extra blocking
around the lock/unlock sequence.
Imre Deak [Wed, 29 Sep 2021 13:28:32 +0000 (16:28 +0300)]
drm/i915/tc: Fix TypeC PHY connect/disconnect logic on ADL-P
So far TC-cold was blocked only for the duration of TypeC mode resets.
The DP-alt and legacy modes require TC-cold to be blocked also whenever
the port is in use (AUX transfers, enable modeset), and this was ensured
by the held PHY ownership flag. On ADL-P this doesn't work, since the
PHY ownership flag is in a register backed by the PW#2 power well.
Whenever this power well is disabled the ownership flag is cleared by
the HW under the driver.
The only way to cleanly release and re-acquire the PHY ownership flag
and also allow for power saving (by disabling the display power wells
and reaching DC5/6 states) is to hold the TC-cold blocking power domains
while the PHY is connected and disconnect/reconnect the PHY on-demand
around AUX transfers and modeset enable/disables. Let's do that,
disconnecting a PHY with a 1 sec delay after it becomes idle. For
consistency do this on all platforms and TypeC modes.
v2: Add tc_mode!=disconnected and phy_is_owned asserts to
__intel_tc_port_lock().
Imre Deak [Tue, 21 Sep 2021 00:23:10 +0000 (03:23 +0300)]
drm/i915/icl/tc: Remove the ICL special casing during TC-cold blocking
While a TypeC port mode is locked a DISPLAY_CORE power domain reference
is held, which implies a runtime PM ref. By removing the ICL !legacy
port special casing, a TC_COLD_OFF power domain reference will be taken
for such ports, which also translates to a runtime PM ref on that
platform. A follow-up change will stop holding the DISPLAY_CORE power
domain while the port is locked.
Imre Deak [Wed, 29 Sep 2021 13:28:31 +0000 (16:28 +0300)]
drm/i915/tc: Avoid using legacy AUX PW in TBT mode
For the ADL-P TBT mode the spec doesn't require blocking TC-cold by
using the legacy AUX power domain. To avoid the timeouts that this would
cause during PHY disconnect/reconnect sequences (which will be more
frequent after a follow-up change) use the TC_COLD_OFF power domain in
TBT mode on all platforms. On TGL this power domain blocks TC-cold via a
PUNIT command, while on other platforms the domain just takes a runtime
PM reference.
If the HPD live status indicates that the port mode needs to be reset
- for instance after switching from TBT to a DP-alt sink - still take
the AUX domain, since the IOM firmware handshake requires this.
Imre Deak [Wed, 29 Sep 2021 13:28:29 +0000 (16:28 +0300)]
drm/i915/tc: Add a mode for the TypeC PHY's disconnected state
A follow-up change will start to disconnect/re-connect PHYs around AUX
transfers and modeset enable/disables. To prepare for that add a new
TypeC PHY disconnected mode, to help tracking the TC-cold blocking power
domain status (no power domain in disconnected state, mode dependent
power domain in connected state).
v2: Move the !disconnected mode and phy-owned asserts in
__intel_tc_port_lock() later in the patchset, when the asserts will
hold. (Jose)
Imre Deak [Tue, 21 Sep 2021 00:23:06 +0000 (03:23 +0300)]
drm/i915/tc: Don't keep legacy TypeC ports in connected state w/o a sink
A follow-up patch will disconnect/reconnect PHYs around AUX transfers
and modeset enable/disables. To prepare for that and make things
consistent for all TypeC modes stop connecting the PHY in legacy mode
without a sink being connected. This was done before since in legacy
mode the PHY is dedicated to display usage, so there was no point in
disconnecting it. However after the follow-up changes the TC-cold
blocking power domains will be held as long as the PHY is in the
connected state, so we'll need to disconnect/re-connect the PHY in all
TypeC modes to allow for power saving.
Imre Deak [Wed, 29 Sep 2021 13:28:28 +0000 (16:28 +0300)]
drm/i915/tc: Check for DP-alt, legacy sinks before taking PHY ownership
On ADL-P the PHY ready/complete flag is always set even in TBT-alt mode.
To avoid taking the PHY ownership and the following spurious "PHY sudden
disconnect" messages on this platform when connecting the PHY in TBT
mode, check if there is any DP-alt or legacy sink connected before
taking the ownership.
v2: (Jose)
- Fix debug message clarifying that a TBT sink can be connected.
- Add comments describing the PHY complete HW flag semantic differences
between adl-p and other platforms.
Imre Deak [Tue, 21 Sep 2021 00:23:03 +0000 (03:23 +0300)]
drm/i915/tc: Remove waiting for PHY complete during releasing ownership
Waiting for the PHY complete flag to clear when releasing the PHY
ownership was add in
commit ddec362724f9 ("drm/i915: Wait for TypeC PHY complete flag to clear in safe mode")
This isn't required by the spec, the vague idea was to make the
handshake with the firmware more robust, without actual evidence for
when it would be needed. Checking this again, the flag doesn't clear on
ICL until after the PHY's PLL is disabled and the flag is permanently
set on ADL-P. To avoid the spurious timeout messages in dmesg, just
remove this wait.
Imre Deak [Tue, 21 Sep 2021 00:23:02 +0000 (03:23 +0300)]
drm/i915/adlp/tc: Fix PHY connected check for Thunderbolt mode
On ADL-P the PHY ready (aka status complete on other platforms) flag is
always set, besides when a DP-alt, legacy sink is connected also when a
TBT sink is connected or nothing is connected. So assume the PHY to be
connected when both the TBT live status and PHY ready flags are set.
Imre Deak [Wed, 29 Sep 2021 13:28:27 +0000 (16:28 +0300)]
drm/i915/tc: Fix TypeC port init/resume time sanitization
Atm during driver loading and system resume TypeC ports are accessed
before their HW/SW state is synced. Move the TypeC port sanitization to
the encoder's sync_state hook to fix this.
v2: Handle the encoder disabled case in gen11_dsi_sync_state() as well
(Jose, Jani)
Fixes: f9e76a6e68d3 ("drm/i915: Add an encoder hook to sanitize its state during init/resume") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210929132833.2253961-1-imre.deak@intel.com
drm/i915/gen11: Disable cursor clock gating in HDR mode
Display underrun in HDR mode when cursor is enabled.
RTL fix will be implemented CLKGATE_DIS_PSL_A bit 28-46520h.
As per W/A 1604331009, Disable cursor clock gating in HDR mode.
Bspec : 33451
Changes since V6:
- Address checkpatch warnings
- Bit ordering
Changes since V5:
- replace intel_de_read with intel_de_rmw - Jani
Changes since V4:
- Added WA needed check - Ville
- Replace BIT with REG_BIT - Ville
- Add WA enable/disable support back which was
added in V1 - Ville
Changes since V3:
- Disable WA when not in HDR mode or cursor plane
not active - Ville
- Extract required args from crtc_state - Ville
- Create HDR mode API using bdw_set_pipemisc ref - Ville
- Tested with HDR video as well full setmode, WA
applies and disables
Changes since V2:
- Made it general gen11 WA
- Removed WA needed check
- Added cursor plane active check
- Once WA enable, software will not disable
Changes since V1:
- Modified way CLKGATE_DIS_PSL bit 28 was modified
Dave Airlie [Tue, 28 Sep 2021 22:57:46 +0000 (01:57 +0300)]
drm/i915/pm: drop get_fifo_size vfunc.
The i845_update_wm code was always calling the i845 variant,
and the i9xx_update_wm had only a choice between i830 and i9xx
paths, hardly worth the vfunc overhead.
drm/i915/display: Fix the dsc check while selecting min_cdclk
The right parameter that selects second dsc engine is dsc_split.
Hence use dsc_split instead of slice_count while selecting the
cdclk in order to accommodate 1ppc limitaion of vdsc.
Fixes: fe01883fdcef ("drm/i915: Get proper min cdclk if vDSC enabled") Suggested-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210915054338.29869-1-vandita.kulkarni@intel.com
Ville Syrjälä [Tue, 21 Sep 2021 15:25:17 +0000 (18:25 +0300)]
drm/i915/fbc: Allow higher compression limits on FBC1
On FBC1 we can specify an arbitrary cfb stride. The hw will
simply throw away any compressed line that would exceed the
specified limit and keep using the uncompressed data instead.
Thus we can allow arbitrary compression limits.
The one thing we have to keep in mind though is that the cfb
stride is specified in units of 32B (gen2) or 64B (gen3+).
Fortunately X-tile is already 128B (gen2) or 512B (gen3+) wide
so as long as we limit outselves to the same 4x compression
limit that FBC2 has we are guaranteed to have a sufficiently
aligned cfb stride.
Ville Syrjälä [Tue, 21 Sep 2021 15:25:15 +0000 (18:25 +0300)]
drm/i915/fbc: Align FBC segments to 512B on glk+
Apply the same 512 byte FBC segment alignment to glk+ as we use
on skl+. The only real difference is that we now have a dedicated
register for the FBC override stride. Not 100% sure which
platforms really need the 512B alignment, but it's easiest
to just do it on everything.
Also the hardware no longer seems to misclaculate the CFB stride
for linear, so we can omit the use of the override stride for
linear unless the stride is misaligned.
projects / mirror_ubuntu-kernels.git / log