- 11 Apr, 2023 1 commit
-
-
Ville Syrjälä authored
Our current limited range matrix is a bit off. I think it was originally calculated with rounding, as if we wanted the normal pixel replication type of behaviour. That is, since the 8bpc max value is 0xeb we assumed the 16bpc max value should be 0xebeb, but what the HDMI spec actually says it should be is 0xeb00. So to get what we want we make the formula out = in * (235-16) << (12-8) / in_max + 16 << (12-8), with 12 being precision of the csc, 8 being the precision of the constants we used. The hardware takes its coefficients as floating point values, but the (235−16)/255 = ~.86, so exponent 0 is what we want anyway, so it works out perfectly without having to hardcode it in hex or start playing with floats. In terms of raw numbers we are feeding the hardware the post offset changes from 0x101 to 0x100, and the coefficient changes from 0xdc0 to 0xdb0 (~.860->~.855). So this should make everything come out just a tad darker. I already used better constants in lut_limited_range() earlier so the output of the two paths should be closer now. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230329135002.3096-2-ville.syrjala@linux.intel.comReviewed-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com>
-
- 06 Apr, 2023 2 commits
-
-
Jani Nikula authored
Fix the warning: drivers/gpu/drm/i915/intel_wakeref.h:118: warning: expecting prototype for intel_wakeref_get_if_in_use(). Prototype was for intel_wakeref_get_if_active() instead Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230405104142.766598-2-jani.nikula@intel.com
-
Jani Nikula authored
There's not much point in a static work function having a kernel-doc comment. Just clean it up and make it a regular comment. This fixes the kernel-doc warnings: drivers/gpu/drm/i915/display/intel_tc.c:1370: warning: Function parameter or member 'work' not described in 'intel_tc_port_disconnect_phy_work' drivers/gpu/drm/i915/display/intel_tc.c:1370: warning: Excess function parameter 'dig_port' description in 'intel_tc_port_disconnect_phy_work' Signed-off-by:
-
- 05 Apr, 2023 5 commits
-
-
Jani Nikula authored
Follow the contemporary naming style. Include some indentation fixes while at it on the affected statements. One function needs to keep using dev_priv due to implicit dev_priv usage in a macro. Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Jani Nikula authored
Observe that intel_pm.[ch] is now purely about clock gating, so rename them to intel_clock_gating.[ch]. Rename the functions to intel_clock_gating_*() to follow coding conventions. Reviewed-by:
-
Alan Previn authored
MESA driver is creating protected context on every driver handle creation to query caps bits for app. So when running CI tests, they are observing hundreds of drm_errors when enabling PXP in .config but using SOC fusing or BIOS configuration that cannot support PXP sessions. The fixes tag referenced below was to resolve a related issue where we wanted to silence error messages, but that case was due to outdated IFWI (firmware) that definitely needed an upgrade and was, at that point, considered a one-off case as opposed to today's realization that default CI was enabling PXP in kernel config for all testing. So with this patch, let's strike a balance between issues that is critical but are root-caused from HW/platform gaps (louder drm-warn but just ONCE) vs other cases where it could also come from session state machine (which cannot be a WARN_ONCE since it can be triggered due to runtime operation events). Let's use helpers for these so as more functions are added in future features / HW (or as FW designers continue to bless upstreaming of the error codes and meanings), we only need to update the helpers. NOTE: Don't completely remove FW errors (via drm_debug) or else cusomer apps that really needs to know that content protection failed won't be aware of it. v2: - Add fixes tag (Trvtko) v3: - Break multi-line drm_dbg strings into separate drm_dbg (Daniele) - Fix couple of typecasting nits (Daniele) v4: - Unsuccessful PXP FW cmd due to platform configuration shouldn't use drm_WARN_once (Tvrtko), Switched to use drm_info_once. v5: - Added "reported-and-tested" by Eero. Reported-and-tested-by:Eero Tamminen <eero.t.tamminen@intel.com> Fixes: b762787b ("drm/i915/pxp: Use drm_dbg if arb session failed due to fw version") Signed-off-by:
Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Jani Nikula authored
Enabling kernel-doc warnings in commit aaee4bbe ("drm/i915: enable kernel-doc warnings for CONFIG_DRM_I915_WERROR=y") actually only covers the .c files. And it's good for avoiding warnings in W= builds. However, we need something more to check for kernel-doc issues in headers. Add it as part of the existing HDRTEST. We have tons of issues, and this unleashes warnings galore on CONFIG_DRM_I915_WERROR=y. It doesn't fail the build because (at least for now) we don't pass -Werror to kernel-doc. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230404090528.173075-1-jani.nikula@intel.com
-
Stanislav Lisovskiy authored
According to spec, we should check if output_bpp * pixel_rate is less than DDI clock * 72, if UHBR is used. v2: - s/pipe_config/crtc_state/ (Jani Nikula) - Merged previous patch into that one, to remove empty function(Jani Nikula) v3: - Make that constraint check to be DSC-related only - Limit this to only DISPLAY_VER <= 13 v4: - Move constraint check to the top(Vinod Govindapillai) HSDES: 1406899791 BSPEC: 49259 Signed-off-by:Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by:
-
- 04 Apr, 2023 3 commits
-
-
Jani Nikula authored
Increase awareness of kernel-doc issues by enabling doc check locally when CONFIG_DRM_I915_WERROR=y is enabled. Once the warnings have been fixed, we can pass -Werror to kernel-doc locally, and fail the build when there are kernel-doc warnings in i915. v2: Don't check for KBUILD_EXTRA_WARN (Masahiro) Cc: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
-
Jani Nikula authored
Clean up i915_reg.h by splitting out PSR regs to display/intel_psr_regs.h. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Clean up i915_reg.h by splitting out SKL+ watermark regs to display/skl_watermark_regs.h. v2: Rebased Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> # v1 Signed-off-by:
-
- 03 Apr, 2023 29 commits
-
-
Ville Syrjälä authored
Replace the hardcoded final numbers in the AUX SYNC/precharge setup, and derive those from numbers from the (e)DP specs. The new functions can serve as the single point of truth for the number of SYNC pulses we use. Cc: Jouni Högander <jouni.hogander@intel.com> Signed-off-by:
Jouni Högander <jouni.hogander@intel.com>
-
Ville Syrjälä authored
Fast wake should use 8 SYNC pulses for the preamble and 10-16 SYNC pulses for the precharge. Reduce our fast wake SYNC count to match the maximum value. We also use the maximum precharge length for normal AUX transactions. Cc: Jouni Högander <jouni.hogander@intel.com> Signed-off-by:
-
Ashutosh Dixit authored
On ATSM the PL1 limit is disabled at power up. The previous uapi assumed that the PL1 limit is always enabled and therefore did not have a notion of a disabled PL1 limit. This results in erroneous PL1 limit values when the PL1 limit is disabled. For example at power up, the disabled ATSM PL1 limit was previously shown as 0 which means a low PL1 limit whereas the limit being disabled actually implies a high effective PL1 limit value. To get round this problem, the PL1 limit uapi is expanded to include a special value 0 to designate a disabled PL1 limit. A read value of 0 means that the PL1 power limit is disabled, writing 0 disables the limit. The link between this patch and the bugs mentioned below is as follows: * Because on ATSM the PL1 power limit is disabled on power up and there were no means to enable it, we previously implemented the means to enable the limit when the PL1 hwmon entry (power1_max) was written to. * Now there is a IGT igt@i915_hwmon@hwmon_write which (a) reads orig value from all hwmon sysfs (b) does a bunch of random writes and finally (c) restores the orig value read. On ATSM since the orig value is 0, when the IGT restores the 0 value, the PL1 limit is now enabled with a value of 0. * PL1 limit of 0 implies a low PL1 limit which causes GPU freq to fall to 100 MHz. This causes GuC FW load and several IGT's to start timing out and gives rise to these Intel CI bugs. After this patch, writing 0 would disable the PL1 limit instead of enabling it, avoiding the freq drop issue. v2: Add explanation for bugs mentioned below (Rodrigo) v3: Eliminate race during PL1 disable and verify (Tvrtko) Change return to -ENODEV if verify fails (Tvrtko) Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8062 Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8060Signed-off-by:Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/i915/display/intel_wm.c:46: warning: Function parameter or member 'i915' not described in 'intel_update_watermarks' drivers/gpu/drm/i915/display/intel_wm.c:46: warning: Excess function parameter 'dev_priv' description in 'intel_update_watermarks' Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Lee Jones <lee@kernel.org> Signed-off-by:
-
Lee Jones authored
drm/i915/display/intel_display_power: Fix incorrectly documented function __intel_display_power_put_async() Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/i915/display/intel_display_power.c:712: warning: expecting prototype for intel_display_power_put_async(). Prototype was for __intel_display_power_put_async() instead Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Imre Deak <imre.deak@intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Lee Jones authored
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/i915/display/intel_display_debugfs.c:1668: warning: Function parameter or member 'intel_connector' not described in 'intel_connector_debugfs_add' drivers/gpu/drm/i915/display/intel_display_debugfs.c:1668: warning: Excess function parameter 'connector' description in 'intel_connector_debugfs_add' Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Imre Deak authored
The encoder update_prepare()/complete() hooks were added to hold a TC port link reference for all outputs in the atomic state around the whole modeset enable sequence - thus locking the ports' TC mode - and set the TBT/DP-alt PLL type corresponding to the current TC mode. Since nothing depends on the PLL selection before/after then encoder's pre_pll_enable/post_pll_disable hooks are called, the above steps can be moved to these hooks, so do that and remove the update_prepare()/complete() hooks. Reviewed-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230323142035.1432621-30-imre.deak@intel.com
-
Imre Deak authored
After the previous patch the workaround for a TC PHY hang issue is not required any more, remove it. Reviewed-by:
-
Imre Deak authored
Bspec requires disabling the DPLLs on TC ports before disconnecting the port's PHY. Add a post_pll_disable encoder hook and move the call to disconnect the port's PHY from the post_disable hook to the new hook. Reviewed-by:
-
Imre Deak authored
The spec requires disabling the PLL on TC ports before disconnecting the port's PHY. Prepare for that by moving the PLL disabling to the CRTC disable hook, while disconnecting the PHY will be moved to the post_pll_disable() encoder hook in the next patch. v2: Move the call from intel_crtc_disable_noatomic() as well. Reviewed-by: Mika Kahola <mika.kahola@intel.com> # v1 Signed-off-by:
-
Imre Deak authored
Bspec has updated the TC connect/disconnect sequences, add the required platform hooks for these. The difference wrt. the old sequence is the order of taking the PHY ownership - while holding a port power reference this requires - and blocking the TC-cold power state. Bspec: 49294 Reviewed-by:
-
Imre Deak authored
Connecting the PHY for connector probing - also blocking TC-cold - isn't required and has some overhead. Taking only the mutex is sufficient, so do that. Reviewed-by:
-
Imre Deak authored
Enable the power required for the HPD live status register access instead of depending on the caller blocking the TC-cold power state (during HW readout and connector probing). A follow up patch will remove connecting/disconnecting the PHY around connector probing, so querying the HPD status can happen in this case without TC-cold being blocked. Reviewed-by:
-
Imre Deak authored
The spec says to use the CPU ISR registers for DP-alt/TBT HPD detection on ADLP, so do that instead of using the related IOM/TCSS registers. Bspec: 55480, 55482, 49212, 49305 Reviewed-by:
-
Imre Deak authored
Add a hook for platform specific PHY initialization. Move the detection of modular FIAs to the TGL handler, skipping this on ADLP+ where the FIAs are always modular, not requiring a detection. Reviewed-by:
-
Imre Deak authored
Add an assert to each TC PHY hook that their required power domain is enabled. While at it add a comment describing the domains used on each platform and TC mode. v2: Fix non kernel-doc multiline comments. (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Imre Deak authored
Instead of the corresponding if ladder, add a TC PHY hook to get the platform and TC mode specific power domain used for blocking the TC-cold power state. Reviewed-by:
-
Imre Deak authored
Simplify tc_cold_block()/unblock() by dropping their power domain parameter. The power domain depends on the current TC mode, which - after the previous patch - can't change while the PHY is connected, holding a TC-cold-off power domain reference. Based on this the domain can be deducted from the current TC mode instead of having to pass this as a parameter. Blocking TC-cold for the PHY HW readout happens before the current TC mode is determined, so here the initial power domain must be still manually passed. For debugging still keep track of the domain used for tc_cold_block() and verify that it remained the same until tc_cold_unblock(). While at it rename tc_cold_get_power_domain() to tc_phy_cold_off_domain(), reflecting the name of platform specific hook added in the next patch. Reviewed-by:
-
Imre Deak authored
After the previous patch unblock_tc_cold() will not be called in a disconnected mode, so the wakeref passed to it will be always non-zero. Remove the redundant check. Reviewed-by:
-
Imre Deak authored
Move blocking/unblocking the TC-cold power state to the platform specific PHY connect / disconnect hooks. This allows for adjusting the connect/disconnect sequence as required for each platform. Reviewed-by:
-
Imre Deak authored
After the previous patch the TC mode in the connect/disconnect functions is always in sync with the VBT legacy port flag, so for consistency with the rest of the function check the TC mode instead of the VBT flag. Reviewed-by:
-
Imre Deak authored
A follow-up patch simplifies the tc_cold_block()/unblock() functions, dropping the power domain parameter. For this it must be ensured that the power domain - which depends on the actual TC mode and so the VBT legacy port flag - can't change while the PHY is in a connected state and accordingly TC-cold is blocked. Make this so, by fixing up the VBT legacy flag only in the disconnected TC mode, instead of whenever the HPD state is retrieved. Reviewed-by:
-
Imre Deak authored
Add TC PHY hooks to connect/disconnect the PHY. A follow-up patch will add the ADLP specific hooks for these. Reviewed-by:
-
Imre Deak authored
Factor out a function verifying the PHY connected state in legacy or DP-alt mode. This is common to all platforms, which can be reused in platform specific connect hooks added in follow-up patches. No functional changes. Reviewed-by:
-
Imre Deak authored
Add generic handlers to connect/disconnect a PHY. Setting the TC mode to the target mode deducted from the HPD state and - if connecting to this mode fails - falling back to connecting to the default (TBT) mode are common to all platforms; move the logic for this from the ICL specific connect / disconnect handlers to the generic ones. Reviewed-by:
-
Imre Deak authored
Add a TC PHY hook to read out the PHY HW state on each platform, move the common parts to the generic helper. Reviewed-by:
-
Imre Deak authored
Add TC PHY hooks to get the PHY ready/owned state on each platform, replacing the corresponding if ladder. Reviewed-by:
-
Imre Deak authored
Add a table of TC PHY hooks which can be used to call platform specific TC PHY handlers, replacing the corresponding if ladders. Add the hook to retrieve the PHY's HPD live status. Move the common part fixing up the VBT legacy port flag to the generic helper. Reviewed-by:
-
Imre Deak authored
Move the intel_tc_port struct to intel_tc.c for better isolation. This requires allocating the struct dynamically. Reviewed-by:
-
