Jani Nikula [Mon, 3 Apr 2023 12:24:27 +0000 (15:24 +0300)]
drm/i915: rename intel_pm.[ch] to intel_clock_gating.[ch]
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.
Alan Previn [Thu, 23 Mar 2023 18:41:56 +0000 (11:41 -0700)]
drm/i915/pxp: limit drm-errors or warning on firmware API failures
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: b762787bf767 ("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: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230323184156.4140659-1-alan.previn.teres.alexis@intel.com
Jani Nikula [Tue, 4 Apr 2023 09:05:28 +0000 (12:05 +0300)]
drm/i915: run kernel-doc on headers as part of HDRTEST
Enabling kernel-doc warnings in commit aaee4bbe8a1a ("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.
Ville Syrjälä [Wed, 29 Mar 2023 17:24:33 +0000 (20:24 +0300)]
drm/i915: Fix fast wake AUX sync len
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.
Ashutosh Dixit [Sat, 1 Apr 2023 02:41:46 +0000 (19:41 -0700)]
drm/i915/hwmon: Use 0 to designate disabled PL1 power limit
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)
Lee Jones [Fri, 31 Mar 2023 09:26:07 +0000 (10:26 +0100)]
drm/i915/display/intel_wm: Fix a little doc-rot in intel_update_watermarks()
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: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230331092607.700644-20-lee@kernel.org
Lee Jones [Fri, 31 Mar 2023 09:26:05 +0000 (10:26 +0100)]
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 <lee@kernel.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230331092607.700644-18-lee@kernel.org
Lee Jones [Fri, 31 Mar 2023 09:25:52 +0000 (10:25 +0100)]
drm/i915/display/intel_display_debugfs: Fix incorrect param naming for 'intel_connector'
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: Lee Jones <lee@kernel.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230331092607.700644-5-lee@kernel.org
Imre Deak [Thu, 23 Mar 2023 14:20:35 +0000 (16:20 +0200)]
drm/i915: Remove the encoder update_prepare()/complete() hooks
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.
Imre Deak [Thu, 23 Mar 2023 14:20:33 +0000 (16:20 +0200)]
drm/i915: Disable DPLLs before disconnecting the TC PHY
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.
Imre Deak [Thu, 23 Mar 2023 14:20:32 +0000 (16:20 +0200)]
drm/i915: Move shared DPLL disabling into CRTC disable hook
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.
Imre Deak [Thu, 23 Mar 2023 14:20:31 +0000 (16:20 +0200)]
drm/i915/adlp/tc: Align the connect/disconnect PHY sequence with bspec
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.
Imre Deak [Thu, 23 Mar 2023 14:20:30 +0000 (16:20 +0200)]
drm/i915/tc: Don't connect the PHY in intel_tc_port_connected()
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.
Imre Deak [Thu, 23 Mar 2023 14:20:29 +0000 (16:20 +0200)]
drm/i915/tc: Get power ref for reading the HPD live status register
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.
Imre Deak [Thu, 23 Mar 2023 14:20:27 +0000 (16:20 +0200)]
drm/i915/tc: Add TC PHY hook to init the PHY
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.
Imre Deak [Thu, 23 Mar 2023 14:20:25 +0000 (16:20 +0200)]
drm/i915/tc: Add TC PHY hook to get the TC-cold blocking power domain
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.
Imre Deak [Thu, 23 Mar 2023 14:20:24 +0000 (16:20 +0200)]
drm/i915/tc: Drop tc_cold_block()/unblock()'s power domain parameter
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.
Imre Deak [Thu, 23 Mar 2023 14:20:23 +0000 (16:20 +0200)]
drm/i915/tc: Remove redundant wakeref=0 check from unblock_tc_cold()
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.
Imre Deak [Thu, 23 Mar 2023 14:20:22 +0000 (16:20 +0200)]
drm/i915/tc: Block/unblock TC-cold in the PHY connect/disconnect hooks
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.
Imre Deak [Thu, 23 Mar 2023 14:20:21 +0000 (16:20 +0200)]
drm/i915/tc: Check TC mode instead of the VBT legacy flag
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.
Imre Deak [Thu, 23 Mar 2023 14:20:20 +0000 (16:20 +0200)]
drm/i915/tc: Fix up the legacy VBT flag only in disconnected mode
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.
Imre Deak [Thu, 23 Mar 2023 14:20:18 +0000 (16:20 +0200)]
drm/i915/tc: Factor out tc_phy_verify_legacy_or_dp_alt_mode()
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.
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.
Imre Deak [Thu, 23 Mar 2023 14:20:12 +0000 (16:20 +0200)]
drm/i915/tc: Check for TC PHY explicitly in intel_tc_port_fia_max_lane_count()
Check explicitly if the port passed to
intel_tc_port_fia_max_lane_count() has a TC PHY, instead of relying on
the default TC mode value set for non-TC PHY ports.
Imre Deak [Thu, 23 Mar 2023 14:20:11 +0000 (16:20 +0200)]
drm/i915/tc: Move TC port fields to a new intel_tc_port struct
Move the TC port specific fields from intel_digital_port to a new
intel_tc_port struct. Pass an intel_tc_port pointer to all static
functions in intel_tc.c keeping dig_port accessible for these via a
pointer stored in the new struct.
The next patch will allocate the intel_tc_port dynamically, allowing
moving the struct definition to intel_tc.c.
Imre Deak [Thu, 23 Mar 2023 14:20:07 +0000 (16:20 +0200)]
drm/i915/tc: Group the TC PHY setup/query functions per platform
Arrange the TC PHY HW state setup/query functions into platform
specific and generic groups. This prepares for upcoming patches adding
generic TC PHY handlers and platform specific hooks for these,
replacing the corresponding if ladders.
Swati Sharma [Thu, 9 Mar 2023 06:28:55 +0000 (11:58 +0530)]
drm/i915/dsc: Add debugfs entry to validate DSC output formats
DSC_Output_Format_Sink_Support entry is added to i915_dsc_fec_support_show
to depict if sink supports DSC output formats (RGB/YCbCr420/YCbCr444).
Also, new debugfs entry is created to enforce output format. This is
required because of our driver policy. For ex. if a mode is supported
in both RGB and YCbCr420 output formats by the sink, our policy is to
try RGB first and fall back to YCbCr420, if mode cannot be shown
using RGB. So, to test other output formats like YCbCr420 or YCbCr444,
we need a debugfs entry (force_dsc_output_format) to force this
output format.
v2: -Func name changed to intel_output_format_name() (Jani N)
-Return forced o/p format from intel_dp_output_format() (Jani N)
v3: -output_format_str[] to remain static (Jani N)
Suraj Kandpal [Thu, 9 Mar 2023 06:28:53 +0000 (11:58 +0530)]
drm/i915/dsc: Fill in native_420 field
Now that we have laid the groundwork for YUV420 Enablement
we fill up native_420 field in vdsc_cfg and add appropriate
checks wherever required.
---v2
-adding native_422 field as 0 [Vandita]
-filling in second_line_bpg_offset, second_line_offset_adj
and nsl_bpg_offset in vds_cfg when native_420 is true
---v3
-adding display version check to solve igt issue
--v7
-remove is_pipe_dsc check as its always true for D14 [Jani]
--v10
-keep sink capability check [Jani]
-move from !(x == y || w == z) to x !=y && w != z [Jani]
--v11
-avoid native_420 computation if not gen14 [Uma]
Suraj Kandpal [Thu, 9 Mar 2023 06:28:52 +0000 (11:58 +0530)]
drm/i915/dsc: Enable YCbCr420 for VDSC
Implementation of VDSC for YCbCr420.
Add QP tables for 8,10,12 BPC from rc_tables.h in intel_qp_tables.c
(Derived from C-Model, which is given along with DSC1.2a Spec from Vesa)
intel_lookup_range_min/max_qp functons need to take into account the
output format. Based on that appropriate qp table need to be chosen.
Other rc_parameters need to be set where currently values for 444 format
is hardcoded in calculate_rc_parameters( ).
vdsc_cfg struct needs to be filled with output format information, where
these are hardcoded for 444 format.
Bspec: 49259
Jouni Högander [Wed, 29 Mar 2023 15:07:00 +0000 (18:07 +0300)]
drm/i915/psr: Implement Wa_14015648006
PSR WM optimization should be disabled based on any wm level being
disabled. Also same WA should be applied for ICL as well.
Bspec: 71580
v5:
- Set in pre plane hook and clear in post plane hook
v4:
- Handle mode change in psr enable/disable
- Handle wm_level_disable changes separately in pre plane hook
v3:
- Split patch
v2:
- set/clear chicken bit in post_plane_update
- apply for ICL as well
Jouni Högander [Wed, 29 Mar 2023 15:06:59 +0000 (18:06 +0300)]
drm/i915/psr: Modify/Fix Wa_16013835468 and prepare for Wa_14015648006
Wa_16013835468 is a separate from Wa_14015648006 and needs to be
applied for display version 12. Fix this by removing all the
references to Wa_14015648006 and apply Wa_16013835468 according to
Bspec.
Also move workaround into separate function as a preparation for
Wa_14015648006 implementation.
Bspec: 55378
v3:
- apply for display version 12 only
v2:
- keep applying the wa in intel_psr_enable_source
The PTEs expect the offset from the base of the fake LMEM region (i.e.
the base of stolen) and not from the base of the DSM. Quoting the specs:
"Driver will set the Device Memory bit = 1 in the PTE when pointing to a
page in DSM and program the PTE with offset from LMEM_BAR. Device Memory
Offset from LMEM_BAR is same as offset from BGSM."
DSM starts 8MBs from BGSM, so we set dsm_base = 8MB.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Cc: Fei Yang <fei.yang@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230328012430.2524330-1-daniele.ceraolospurio@intel.com
drm/i915: Use compressed bpp when calculating m/n value for DP MST DSC
For obvious reasons, we use compressed bpp instead of pipe bpp for
DSC DP SST case. Lets be consistent and use compressed bpp instead of
pipe bpp, also in DP MST DSC case.
Jani Nikula [Mon, 27 Mar 2023 10:53:30 +0000 (13:53 +0300)]
drm/i915: remove unused config DRM_I915_UNSTABLE
Essentially this is a revert of commit d9d54a530a70 ("drm/i915: Put
future HW and their uAPIs under STAGING & BROKEN").
We currently have no users for this config option. The last one was
removed in commit 8c26491f5853 ("drm/i915: Kill the fake lmem
support"). Drop it altogether; it's easy enough to resurrect if need
arises.
Similar to FBC let's expose an debugfs file to control
IPS false color. Enabling this provides an immediate visual
feedback on whether IPS is working or not.
Laurent Pinchart [Wed, 22 Feb 2023 03:49:39 +0000 (05:49 +0200)]
drm: rcar-du: Write correct values in DORCR reserved fields
The DORCR register controls the routing of clocks and data between DU
channels within a group. For groups that contain a single channel,
there's no routing option to control, and some fields of the register
are then reserved. On Gen2 those reserved fields are documented as
required to be set to 0, while on Gen3 and newer the PG1T, DK1S and PG1D
reserved fields must be set to 1.
The DU driver initializes the DORCR register in rcar_du_group_setup(),
where it ignores the PG1T, DK1S and PG1D, and then configures those
fields to the correct value in rcar_du_group_set_routing(). This hasn't
been shown to cause any issue, but prevents certifying that the driver
complies with the documentation in safety-critical use cases.
As there is no reasonable change that the documentation will be updated
to clarify that those reserved fields can be written to 0 temporarily
before starting the hardware, make sure that the registers are always
set to valid values.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Laurent Pinchart [Wed, 22 Feb 2023 22:08:14 +0000 (00:08 +0200)]
drm: rcar-du: Rename DORCR fields to make them 0-based
The DORCR fields were documented in the R-Car H1 datasheet with 1-based
named, and then got renamed to 0-based in Gen2. The 0-based names are
used for Gen3 and Gen4, making H1 an outlier. Rename the field macros to
make them 0-based, in order to increase readability of the code when
comparing it with the documentation.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Laurent Pinchart [Wed, 22 Feb 2023 03:54:03 +0000 (05:54 +0200)]
drm: rcar-du: Disable alpha blending for DU planes used with VSP
When the input to a DU channel comes from a VSP, the DU doesn't perform
any blending operation. Select XRGB8888 instead of ARGB8888 to ensure
that the corresponding registers don't get written with invalid values.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Laurent Pinchart [Wed, 22 Feb 2023 03:49:39 +0000 (05:49 +0200)]
drm: rcar-du: Don't write unimplemented ESCR and OTAR registers on Gen3
The ESCR and OTAR registers are not present in all DU channels on Gen3
SoCs. ESCR only exists in channels that can be routed to an LVDS or
DPAD, and OTAR in channels that can be routed to a DPAD. Skip writing
those registers for other channels. This replaces the DU gen check, as
Gen4 doesn't have LVDS or DPAD outputs.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Laurent Pinchart [Mon, 13 Feb 2023 13:25:15 +0000 (15:25 +0200)]
drm: rcar-du: lvds: Fix LVDS PLL disable on D3/E3
On R-Car D3 and E3, the LVDS encoder provides the dot (pixel) clock to
the DU, regardless of whether the LVDS output is used or not. When using
the DPAD (RGB) output, the DU driver thus enables and disables the LVDS
PLL manually, while when using the LVDS output, it lets the LVDS bridge
driver handle the PLL configuration internally as part of the atomic
enable and disable operations.
This causes an issue when using the LVDS output. As bridges are disabled
before CRTCs, the current implementation violates the enable/disable
sequences documented in the hardware datasheet, which requires the dot
clock to be enabled before the CRTC is started and disabled after it
gets stopped.
Fix the problem by enabling/disabling the LVDS PLL manually from the DU
regardless of which output is used, and skipping the PLL handling in the
LVDS bridge atomic enable and disable operations.
This is however not enough. Disabling the LVDS encoder while leaving the
PLL on still results in a vertical blanking wait timeout when disabling
the DU. Investigation showed that the culprit is the LVEN bit. For an
unclear reason, clearing the bit when disabling the LVDS encoder blocks
vertical blanking interrupts. We thus have to delay disabling the whole
LVDS encoder, not just disabling the PLL, until the DU is disabled.
We could split the LVDS disable sequence by clearing the LVRES bit in
the LVDS bridge atomic disable handler, and delaying the rest of the
operations, in order to disable the LVDS output at bridge atomic disable
time, before stopping the CRTC. This would make the code more complex,
without a clear benefit, so keep the implementation simple(r).
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Laurent Pinchart [Mon, 13 Feb 2023 23:19:17 +0000 (01:19 +0200)]
drm: rcar-du: lvds: Move LVDS enable code to separate code section
To prepare for a rework of the LVDS disable code, which will need to be
called from rcar_lvds_pclk_disable(), move the LVDS enable code,
currently stored in the __rcar_lvds_atomic_enable() function, to a
separate code section separate from bridge operations. It will be then
extended with the LVDS disable code.
As part of this rework the __rcar_lvds_atomic_enable() function is
renamed to rcar_lvds_enable() to more clearly indicate its purpose.
Laurent Pinchart [Mon, 13 Feb 2023 23:07:18 +0000 (01:07 +0200)]
drm: rcar-du: lvds: Call function directly instead of through pointer
When disabling the companion bridge in rcar_lvds_atomic_disable(),
there's no need to go through the bridge's operations to call
.atomic_disable(). Call rcar_lvds_atomic_disable() on the companion
directly.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Ville Syrjälä [Wed, 22 Mar 2023 18:12:19 +0000 (20:12 +0200)]
drm/i915: Add i915.enable_sagv modparam
Currently we have no sane way to forcibly disable SAGV, which
makes debugging things a PITA. Manually poking at the pcode
mailbox with it's various SAGV/QGV/PSF formats is no fun,
and likely to be clobbered by the driver anyway.
Ville Syrjälä [Mon, 20 Mar 2023 09:05:22 +0000 (11:05 +0200)]
drm/i915: Move PLANE_BUG_CFG bit definitions to the correct place
All other skl+ universal plane register bit definitions are next
to the pipe A register definition. Move the PLANE_BUF_CFG bit
definitions there as well.
Driver Changes:
- Meteor Lake enabling and fixes (RK, Jose, Madhumitha)
- Lock the fbdev obj before vma pin (Tejas)
- DSC fixes (Stanislav)
- Fixes and clean-up on opregion code (Imre)
- More wm/vblank stuff (Ville)
- More general display code organization (Jani)
- DP Fixes (Stanislav, Ville)
- Introduce flags to ignore long HPD and link training issues \
for handling spurious issues on CI (Vinod)
- Plane cleanups and extra registers (Ville)
- Update audio keepalive clock values (Clint)
- Rename find_section to bdb_find_section (Maarten)
- DP SDP CRC16 for 128b132b link layer (Arun)
- Fix various issues with noarm register writes (Ville)
- Fix a few TypeC / MST issues (Imre)
- Create GSC submission targeting HDCP and PXP usages on MTL+ (Suraj)
- Enable HDCP2.x via GSC CS (Suraj)
Daniel Vetter [Fri, 24 Mar 2023 18:35:37 +0000 (19:35 +0100)]
Merge tag 'drm-misc-next-2023-03-23' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for v6.4-rc1:
Core Changes:
- Add unit test for xrgb8888 to mono.
- Assorted small fixes to format helper selftests.
- Assorted documentation updates.
- Drop drm_dev_set_unique.
- Always use shadow buffer in generic fbdev emulation helpers, and
improve error handling.
Driver Changes:
- Assorted small fixes to malidp, hdlcd, gma500, lima, bridge, rockchip.
- Move fbdev in gma500 to use drm_client.
- Convert bridge platform callbacks to void return.
- Drop leftover from vgem to shmem helper conversion.
Ville Syrjälä [Mon, 20 Mar 2023 09:05:18 +0000 (11:05 +0200)]
drm/i915/dpt: Only do the POT stride remap when using DPT
If we want to test with DPT disabled on ADL the POT stride remap
stuff needs to be disabled. Make it depend on actual DPT usage
instead of just assuming it based on the modifier.
Ville Syrjälä [Mon, 20 Mar 2023 09:05:17 +0000 (11:05 +0200)]
drm/i915/dpt: Treat the DPT BO as a framebuffer
Currently i915_gem_object_is_framebuffer() doesn't treat the
BO containing the framebuffer's DPT as a framebuffer itself.
This means eg. that the shrinker can evict the DPT BO while
leaving the actual FB BO bound, when the DPT is allocated
from regular shmem.
That causes an immediate oops during hibernate as we
try to rewrite the PTEs inside the already evicted
DPT obj.
TODO: presumably this might also be the reason for the
DPT related display faults under heavy memory pressure,
but I'm still not sure how that would happen as the object
should be pinned by intel_dpt_pin() while in active use by
the display engine...
Cc: stable@vger.kernel.org Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Imre Deak <imre.deak@intel.com> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation for dpt") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230320090522.9909-2-ville.syrjala@linux.intel.com Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Suraj Kandpal [Thu, 16 Mar 2023 09:29:27 +0000 (14:59 +0530)]
drm/i915/mtl: Add HDCP GSC interface
MTL uses GSC command streamer i.e gsc cs to send HDCP/PXP commands
to GSC f/w. It requires to keep hdcp display driver
agnostic to content protection f/w (ME/GSC fw) in the form of
i915_hdcp_fw_ops generic ops.
Adding HDCP GSC CS interface by leveraging the i915_hdcp_fw_ops generic
ops instead of I915_HDCP_COMPONENT as integral part of i915.
Adding checks to see if GSC is loaded and proxy is setup
--v6
-dont change the license date in same patch series [Jani]
-fix the license year {Jani]
--v8
-remove stale comment [Ankit]
-get headers in alphabetical order [Ankit]
-fix hdcp2_supported check [Ankit]
--v9
-remove return statement from hdcp_gsc_fini [Ankit]
Cc: Tomas Winkler <tomas.winkler@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316092927.668980-7-suraj.kandpal@intel.com
Suraj Kandpal [Thu, 16 Mar 2023 09:29:26 +0000 (14:59 +0530)]
drm/i915/mtl: Add function to send command to GSC CS
Add function that takes care of sending command to gsc cs. We start
of with allocation of memory for our command intel_hdcp_gsc_message that
contains gsc cs memory header as directed in specs followed by the
actual payload hdcp message that we want to send.
Spec states that we need to poll pending bit of response header around
20 times each try being 50ms apart hence adding that to current
gsc_msg_send function
Also we use the same function to take care of both sending and receiving
hence no separate function to get the response.
--v4
-Create common function to fill in gsc_mtl_header [Alan]
-define host session bitmask [Alan]
--v5
-use i915 directly instead of gt->i915 [Alan]
-No need to make fields NULL as we are already
using kzalloc [Alan]
--v8
-change mechanism to reuse the same memory for one hdcp session[Alan]
-fix header ordering
-add comments to explain flags and host session mask [Alan]
--v9
-remove gem obj from hdcp message as we can use
i915_vma_unpin_and_release [Alan]
-move hdcp message allocation and deallocation from hdcp2_enable and
hdcp2_disable to init and teardown of HDCP [Alan]
--v10
-remove unnecessary i915_vma_unpin [Alan]
--v11
-fix comment style [Uma]
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Pervin Teres <alan.previn.teres.alexis@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316092927.668980-6-suraj.kandpal@intel.com
Suraj Kandpal [Thu, 16 Mar 2023 09:29:25 +0000 (14:59 +0530)]
drm/i915/hdcp: Refactor HDCP API structures
It requires to move intel specific HDCP API structures to
i915_hdcp_interface.h from driver/misc/mei/hdcp/mei_hdcp.h
so that any content protection fw interfaces can use these
structures.
Cc: Tomas Winkler <tomas.winkler@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316092927.668980-5-suraj.kandpal@intel.com
Anshuman Gupta [Thu, 16 Mar 2023 09:29:23 +0000 (14:59 +0530)]
drm/i915/hdcp: Use generic names for HDCP helpers and structs
pre MTL we interact with mei interface to talk to
firmware and enable CP but going forward we will talk to gsc cs
because of which we are making all names for HDCP helpers and
structures generic as either mei or gsc cs maybe used.
Change the include/drm/i915_mei_hdcp_interface.h to
include/drm/i915_hdcp_interface.h
Change the i915_hdcp_interface.h header naming convention to
suit generic f/w type.
%s/MEI_/HDCP_
%s/mei_dev/hdcp_dev
Change structure name Accordingly.
%s/i915_hdcp_comp_master/i915_hdcp_master
%s/i915_hdcp_component_ops/i915_hdcp_ops
--v6
-make each patch build individually [Jani]
--v8
-change ME FW to ME/GSC FW [Ankit]
-fix formatting issue [Ankit]
--v9
-fix commit message and header [Uma]
--v10
-rename comp variable [Uma]
Cc: Tomas Winkler <tomas.winkler@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Acked-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316092927.668980-3-suraj.kandpal@intel.com
HDCP and PXP will require a common function to allow it to
submit commands to the gsc cs. Also adding the gsc mtl header
that needs to be added on to the existing payloads of HDCP
and PXP.
--v4
-Seprate gsc load and heci cmd submission into different
functions in different files for better scalability [Alan]
-Rename gsc address field [Alan]
--v5
-remove extra line is intel_gsc_fw.h [Uma]
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Signed-off-by: Suraj Kandpal<suraj.kandpal@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230316092927.668980-2-suraj.kandpal@intel.com
Toby Chen [Fri, 17 Mar 2023 00:51:26 +0000 (17:51 -0700)]
drm/rockchip: dw_hdmi: cleanup drm encoder during unbind
This fixes a use-after-free crash during rmmod.
The DRM encoder is embedded inside the larger rockchip_hdmi,
which is allocated with the component. The component memory
gets freed before the main drm device is destroyed. Fix it
by running encoder cleanup before tearing down its container.
clang reportes this error
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2322:8: error:
variable 'possible_crtcs' is used uninitialized whenever 'if'
condition is false [-Werror,-Wsometimes-uninitialized]
if (vp) {
^~
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2336:36: note:
uninitialized use occurs here
ret = vop2_plane_init(vop2, win, possible_crtcs);
^~~~~~~~~~~~~~
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2322:4:
note: remove the 'if' if its condition is always true
if (vp) {
^~~~~~~~
The else-statement changes the win->type to OVERLAY without setting the
possible_crtcs variable. Rework the block, initialize possible_crtcs to
0 to remove the else-statement. Split the else-if-statement out to its
own if-statement so the OVERLAY check will catch when the win-type has
been changed.
Imre Deak [Tue, 21 Mar 2023 22:01:01 +0000 (00:01 +0200)]
drm/i915/tc: Check the PLL type used by an enabled TC port
The current way to determine during HW state sanitization if a PHY is
connected in the expected way doesn't work in all cases. The check for
this considers only the PHY ready/owned state and the initial TC mode
which was determined earlier by the TC port HW readout - using the
sink's HPD and the same PHY ready/owned states.
For instance for an enabled DP-alt/TBT port without the PHY ready/owned
flags set the initial mode will be TBT, and this will be regarded as a
valid PHY state. However it's possible that the port is actually enabled
in DP-alt mode, but for some reason the PHY ownership was not acquired.
Make sure the driver can detect invalid PHY states as in the above
example by checking the PHY ready/owned state wrt. the PLL type used.
This should be the TBT PLL if the PHY is not owned and the MG (non-TBT)
PLL if the PHY is owned.
v2: Rebased on change passing crtc_state in the previous patch.
projects / mirror_ubuntu-kernels.git / log