IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Enabling the 5k@60Hz uncompressed mode on the MediaTek/Dell U3224KBA
monitor results in a blank screen, at least on MTL platforms on UHBR
link rates with some (<30) uncompressed bpp values. Enabling compression
fixes the problem, so do that for now. Windows enables DSC always if the
sink supports it and forcing it to enable the mode without compression
leads to the same problem above (which suggests a panel issue with
uncompressed mode).
The same 5k mode on non-UHBR link rates is not affected and lower
resolution modes are not affected either. The problem is similar to the
one fixed by the HBLANK expansion quirk on Synaptics hubs, with the
difference that the problematic mode has a longer HBLANK duration. Also
the monitor doesn't report supporting HBLANK expansion; either its
internal MST hub does the expansion internally - similarly to the
Synaptics hub - or the issue has another root cause, but still related
to the mode's short HBLANK duration. Enable the quirk for the monitor
adjusting the detection for the above differences.
v2: Rebase on drm_dp_128132b_supported() change.
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240417142217.457902-1-imre.deak@intel.com
The DPCD OUI of the logical port on a Dell UHBR monitor - on which the
AUX device is used to enable DSC - is all 0. To detect if the HBLANK
expansion quirk is required for this monitor use the OUI of the port's
parent instead.
Since in the above case the DPCD of both the logical port and the parent
port reports being a sink device (vs. branch device) type, read the
proper sink/branch OUI based on the DPCD device type.
This is required by a follow-up patch enabling the quirk for the above
Dell monitor.
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/20240416221010.376865-11-imre.deak@intel.com
Add a function to get the AUX device of the parent of an MST port, used
by a follow-up i915 patch in the patchset.
v2: Move drm_dp_mst_aux_for_parent() forward declaration to this patch
(Ankit)
Cc: Lyude Paul <lyude@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-10-imre.deak@intel.com
Factor out a function to check if an MST port is logical, used by a
follow-up i915 patch in the patchset.
v2: Move drm_dp_mst_aux_for_parent() forward declaration to the next
patch. (Ankit)
Cc: Lyude Paul <lyude@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-9-imre.deak@intel.com
Factor out a function to check for 128b/132b channel coding support used
by a follow-up patch in the patchset.
v2: s/drm_dp_uhbr_channel_coding_supported()/drm_dp128b132b_supported()
(Jani)
Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240417141936.457796-1-imre.deak@intel.com
Instead of checking each compressed bpp value against the maximum
DSC/DPT bpp, simplify things by calculating the maximum bpp upfront and
limiting the range of bpps looped over using this maximum.
While at it add a comment about the origin of the DSC/DPT bpp limit.
Bspec: 49259, 68912
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/20240416221010.376865-7-imre.deak@intel.com
The DSC DPT interface BW limit check should take into account the link
clock's (aka DDI clock in bspec) channel coding efficiency overhead.
Bspec suggests that the FEC overhead needs to be applied, however HW
people claim this isn't the case, nor is any overhead applicable.
However based on testing various 5k/6k modes both on the DELL U3224KBA
monitor and the Unigraf UCD-500 CTS test device, both the channel coding
efficiency (which includes the FEC overhead) and an additional 3%
overhead must be accounted for to get these modes working.
Bspec: 49259
v2:
- Apply an additional 3% overhead, add a commit log and code comment
about these overheads and the relation to the Bspec BW limit formula.
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/20240416221010.376865-5-imre.deak@intel.com
The expected link symbol clock unit when calculating the DSC DPT bpp
limit is kSymbols/sec, aligning with the dotclock's kPixels/sec unit
based on the crtc clock. As opposed to this port_clock is used - which
has a 10 kbits/sec unit - with the resulting symbol clock in 10
kSymbols/sec units (disregarding the rounding error for the 13.5Gbps
rate). Fix the calculation using the expected 10x factor.
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/20240416221010.376865-3-imre.deak@intel.com
Fix the calculation of the DSC line buffer depth. This is limited both
by the source's and sink's maximum line buffer depth, but the former one
was not taken into account. On all Intel platform's the source's maximum
buffer depth is 13, so the overall limit is simply the minimum of the
source/sink's limit, regardless of the DSC version.
This leaves the DSI DSC line buffer depth calculation as-is, trusting
VBT.
On DSC version 1.2 for sinks reporting a maximum line buffer depth of 16
the line buffer depth was incorrectly programmed as 0, leading to a
corruption in color gradients / lines on the decompressed screen image.
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240416221010.376865-2-imre.deak@intel.com
The current intel_bw_atomic_check do not check the possbility
of a sagv configuration change after the hw state readout.
Hence cannot update the sagv configuration until some other
relevant changes like data rates, number of planes etc. happen.
Introduce a flag to force qgv check in such cases.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240405113533.338553-7-vinod.govindapillai@intel.com
There could be multiple qgv and psf gv points with similar values.
Apparently pcode's handling of psf and qgv points are different. For
qgv case, pcode sets whatever is asked by the driver. But in case
of psf gv points, it compares the bw from points before setting the
mask. This can cause problems in scenarios where we have to disable
sagv by setting the highest bw point and there could be multiple
points with highest bw. So to set the maximum psf gv point, find
out all the points with the highest bw and set all together.
v1: - use the same treatment to qgv points as well (Vinod)
v2: - pcode confirms that for qgv points, it sets whatever the
driver sets (Vinod)
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240405113533.338553-6-vinod.govindapillai@intel.com
Problem is that on some platforms, we do get QGV point mask in wrong
state on boot. However driver assumes it is set to 0
(i.e all points allowed), however in reality we might get them all
restricted, causing issues.
Lets disable SAGV initially to force proper QGV point state.
If more QGV points are available, driver will recalculate and update
those then after next commit.
v2: - Added trace to see which QGV/PSF GV point is used when SAGV is
disabled.
v3: - Move force disable function to intel_bw_init in order to initialize
bw state as well, so that hw/sw are immediately in sync after init.
v4: - Don't try sending PCode request, seems like it is not possible at
intel_bw_init, however assigning bw->state to be restricted as if
SAGV is off, still forces driveer to send PCode request anyway on
next modeset, so the solution still works.
However we still need to address the case, when no display is
connected, which anyway requires much more changes.
v5: - Put PCode request back and apply temporary hack to make the
request succeed(in case if there 2 PSF GV points with same BW, PCode
accepts only if both points are restricted/unrestricted same time)
- Fix argument sequence for adl_qgv_bw(Ville Syrjälä)
v6: - Fix wrong platform checks, not to break everything else.
v7: - Split the handling of quplicate QGV/PSF GV points (Vinod)
Restrict force disable to display version below 14 (Vinod)
v8: - Simplify icl_force_disable_sagv (Vinod)
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240405113533.338553-5-vinod.govindapillai@intel.com
We need that in order to force disable SAGV in next patch.
Also it is beneficial to separate that code, as in majority cases,
when SAGV is enabled, we don't even need those calculations.
Also we probably need to determine max PSF GV point as well, however
currently we don't do that when we disable SAGV, which might be
actually causing some issues in that case.
v2: - Introduce helper adl_qgv_bw(counterpart to adl_psf_bw)
(Ville Syrjälä)
- Don't restrict psf gv points for SAGV disable case
(Ville Syrjälä)
v3: - Update icl_max_bw_qgv_point_mask to return max qgv point
mask (Vinod)
v4: - Minor changes in icl_find_qgv_points (Vinod)
v5: - use max_bw_point instead of max_bw_point_mask (stan)
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240405113533.338553-3-vinod.govindapillai@intel.com
For debug purposes we need those - error path won't flood the log,
however there has been already numerous cases, when due to lack
of debugs, we couldn't immediately tell what was the problem on
customer machine, which slowed down the investigation, requiring
to get access to target device and adding those traces manually.
v2: - Make the debug more generic and move it to intel_dram_detect
(Gustavo Sousa)
v3: - Use %u for unsigned variable in debug prints (Gustavo)
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240405113533.338553-2-vinod.govindapillai@intel.com
It would be too much noise to convert the intel_de_* functions from
using struct drm_i915_private to struct intel_display all at once. Add
generic wrappers using __to_intel_display() to accept both.
v2: Take the intel_dmc_wl_* changes into account
Cc: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1b0e8e7c732535e18c8498a2e18fe1e4c123e2f5.1713358679.git.jani.nikula@intel.com
Add generic __to_intel_display() macro that accepts either struct
drm_i915_private * or struct intel_display *. This is to be used for
transitional stuff that eventually needs to be converted to use struct
intel_display *, and therefore is not part of to_intel_display().
Add new intel_display_conversion.h to host the helper to avoid
duplication between xe and i915 drivers.
v2: put it in the new header (Rodrigo)
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a999ff8183659a4df68d439ebd31c19b5c56852a.1713358679.git.jani.nikula@intel.com
Convert various pointers to struct intel_display * using _Generic().
Add some macro magic to make adding new conversions easier, and somewhat
abstract the need to cast each generic association. The cast is required
because all associations needs to compile, regardless of the type and
the generic selection.
The use of *p in the generic selection assignment expression removes the
need to add separate associations for const pointers.
Note: This intentionally does *not* cover struct drm_i915_private or
struct xe_device. They are not to be used in the long run, so avoid
using this macro for them.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/02cf407961200db4379370856c779ea62b3eaa90.1713358679.git.jani.nikula@intel.com
The pipes that can be used for eDP MSO are limited to pipe A (and
sometimes also pipe B) only for display version 20 and below.
Modify the function that returns the pipe mask for eDP MSO so that
these limitations only apply to version 20 and below, enabling all
pipes otherwise.
Bspec: 68923
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: James Ausmus <james.ausmus@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240404091646.165309-1-luciano.coelho@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
For some reason the snps/cx0 PLL states were added into
a union alongside dpll_hw_state. Just suck them into
dpll_hw_state so that we don't have so many levels of
unions/etc.
TODO: Get rid of 'clock' from the snps/cx0 PLL states
as it is not a register values and thus doesn't
belong there
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-19-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
intel_dpll_hw_state contains space for all possible PLL
register values across all platforms. That is rather wasteful
as each machine only needs to store the registers values
that are appropriate for the platform.
Turn intel_dpll_hw_state into a union so that we don't
waste memory for the register values of other platforms.
And let's use an anonymous union so that we don't have
to do tons of s/struct/union/ all over the place.
pahole:
struct intel_dpll_hw_state {
- struct i9xx_dpll_hw_state i9xx; /* 0 16 */
- struct hsw_dpll_hw_state hsw; /* 16 8 */
- struct skl_dpll_hw_state skl; /* 24 12 */
- struct bxt_dpll_hw_state bxt; /* 36 44 */
- /* --- cacheline 1 boundary (64 bytes) was 16 bytes ago --- */
- struct icl_dpll_hw_state icl; /* 80 60 */
+ union {
+ struct i9xx_dpll_hw_state i9xx; /* 0 16 */
+ struct hsw_dpll_hw_state hsw; /* 0 8 */
+ struct skl_dpll_hw_state skl; /* 0 12 */
+ struct bxt_dpll_hw_state bxt; /* 0 44 */
+ struct icl_dpll_hw_state icl; /* 0 60 */
+ }; /* 0 60 */
- /* size: 140, cachelines: 3, members: 5 */
- /* last cacheline: 12 bytes */
+ /* size: 60, cachelines: 1, members: 1 */
+ /* last cacheline: 60 bytes */
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-18-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
struct intel_dpll_hw_state has a spot for all possible
PLL registers across all platforms (well, apart from
cx0/snps). This makes it rather confusing when trying to
figure out which members belong to which platform(s).
Split the struct up into five different platform specific
sub-structures. For now this will actually increase the size
a little bit as we have to duplicate a few members from
skl to icl, but that will be remedied soon when we turn
the thing into a union.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-17-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
The *_compute_dpll() functions generally contain
two things:
- huge pile of inline code to calculate the DPLL
register value
- a few calls to helpers to calculate the
DPLL_MD and FP register values
Pull the DPLL register value calculations into a helpers
as well, so that *_compute_dpll() can focus on higher
level tasks.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-11-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Stop rummaging around inside pll->state directly in the low
level pll->enable() functions, and instead let the higher level
code figure out where the correct state is stored and pass it in.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-9-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Spinkle local PLL hw_state variables into various low
level PLL functions. Will make subsequent changes cleaner
when we don't have to touch so many places when renaming
struct members and whatnot.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
We have zero consistency in out PLL state naming scheme. Try
to unify things a bit by using 'dpll_hw_state' for high level
stuff and just 'hw_state' for low level stuff. Currently both
are the same, but I want to unionize intel_dpll_hw_state at
which point using different names can make it more clear whether
we're talking about the whole union or just the embedded platform
specific struct.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412182703.19916-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
We only need DMC wakelocks when we allow DC5 and DC6 states. Add the
calls to enable and disable DMC wakelock accordingly.
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412094148.808179-5-luciano.coelho@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This feature should be disabled by default until properly tested and
mature. Add a module parameter to enable the feature for testing,
while keeping it disabled by default for now.
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412094148.808179-4-luciano.coelho@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Only allow running DMC wakelock code if the display version is 20 or
greater. Also check if DMC is loaded before enabling.
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412094148.808179-3-luciano.coelho@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
In order to reduce the DC5->DC2 restore time, wakelocks have been
introduced in DMC so the driver can tell it when registers and other
memory areas are going to be accessed and keep their respective blocks
awake.
Implement this in the driver by adding the concept of DMC wakelocks.
When the driver needs to access memory which lies inside pre-defined
ranges, it will tell DMC to set the wakelock, access the memory, then
wait for a while and clear the wakelock.
The wakelock state is protected in the driver with spinlocks to
prevent concurrency issues.
BSpec: 71583
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412094148.808179-2-luciano.coelho@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
