| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Prefer generic poll helpers over i915 custom helpers.
The functional change is losing the exponentially growing sleep of
wait_for(), which used to be 10, 20, 40, ..., 640, and 1280 us.
Use an arbitrary constant 200 us sleep for the 5 ms timeout, and 1000 us
sleep for the 500 ms timeout. The timeouts remain the same.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/50cd06b61210f541d5bb52a36af2d8bf059dd3a1.1756383233.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
There is a possibility that intel_encoder_to_tc() function
returns negative i.e. TC_PORT_NONE (-1) value which may cause
tc_port_power_domain() function to overflow. To fix this,
let's add additional check that returns invalid power domain
i.e. POWER_DOMAIN_INVALID in case tc port equals TC_PORT_NONE.
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20250829101226.4085757-1-mika.kahola@intel.com
|
|
Debug print the TypeC pin assignment and max lane count value during HW
readout and after resetting the TypeC mode.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-20-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
Cache the pin assignment value. This is more consistent with the way the
max lane count value is tracked and a bit more efficient than reading
out the same value from HW each time it's queried.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-19-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
The pin assignment is only relevant in case the PHY is owned by the
display, that is in legacy and DP-alt mode. In TBT-alt mode the PHY is
owned by the TBT FW/driver and so the pin assignment/configuration is
managed by those components. A follow-up change will cache the pin
assignment value in all the TypeC modes - querying this by calling
get_pin_assignment() - prepare for that here, by reporting pin
assignment NONE in the TBT-alt mode.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-18-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
Pass the intel_tc_port pointer instead of intel_digital_port to all lane
mask and count query helpers internal to intel_tc.c, to avoid the
redundant intel_digital_port -> intel_tc_port conversions.
While at it shorten the function names, keeping the intel_tc_port_
prefix only for exported functions and use the mtl_, icl_ prefixes
making it clear which platforms a given query function is specific for.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-17-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
For consistency, handle the case where
intel_tc_port_get_pin_assignment() is called for a non-TypeC encoder,
returning the default NONE pin assignment value, similarly to how this
is done in intel_tc_port_max_lane_count().
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-16-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
Unify the way to get the max lane count value on all MTL+ platforms,
reducing the code duplication.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-15-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
Unify the way to get the pin assignment on all platforms. This removes
the duplication in the helper functions in this and a follow-up change.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-14-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
Validate the pin assignment on ICL-TGL, similarly to how this is done on
MTL+. ICL supports all the pin assignments, while TGL+ supports only the
NONE, C, D, E pin assignments.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-13-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
For consistency, handle pin assignment NONE on all platforms similarly
to LNL+. On earlier platforms the driver doesn't actually see this pin
assignment - as it's not valid on a connected DP-alt PHY - however it's
a valid HW setting even on those platforms, for instance in legacy mode.
Handle this pin assignment on earlier platforms as well, so that the way
to query the pin assignment can be unified by a follow-up change.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-12-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
Pass around the pin assignment value via the corresponding enum instead
of a plain integer.
While at it rename intel_tc_port_get_pin_assignment_mask() to
intel_tc_port_get_pin_assignment(), since the value returned is not a
mask.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-11-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
Add an enum for the TypeC pin assignment, which is a better way to pass
its value around than a plain integer. While at it add a description for
each pin assignment, based on the DP and DP Alt mode Standards, opting
for more details to ease any future debugging related to a given pin
assignment and the cables / sink types used.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
[Imre: s/deined/defined in pin assignment enum documentation.]
Link: https://lore.kernel.org/r/20250805073700.642107-10-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
Move asserting the expected TC cold power state and the read out
register value right after reading the TCSS_DDI_STATUS register,
similarly to how this is done with the other PORT_TX_DFLEXDPSP and
PORT_TX_DFLEXPA1 PHY registers.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-9-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
Move getting the required display power domain right before reading the
PORT_TX_DFLEXDPSP and PORT_TX_DFLEXPA1 registers, similarly to how this
is done while reading the other TCSS_DDI_STATUS PHY register.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-8-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
Use the PHY's cached max lane count value on all platforms similarly to
LNL+. On LNL+ using the cached value is mandatory - since the
corresponding HW register field can get cleared by the time the value is
queried - on earlier platforms there isn't a problem with using the HW
register instead. Having a uniform way to query the value still makes
sense and it's also a bit more efficient, so do that.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250805073700.642107-7-imre.deak@intel.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
The BIOS can leave the AUX power well enabled on an output, even if this
isn't required (on platforms where the AUX power is only needed for an
AUX access). This was observed at least on PTL. To avoid the WARN which
would be triggered by this during the HW readout, convert the WARN to a
debug message.
Cc: stable@vger.kernel.org # v6.8+
Reported-by: Charlton Lin <charlton.lin@intel.com>
Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250811080152.906216-6-imre.deak@intel.com
|
|
Use the cached max lane count value on LNL+, to account for scenarios
where this value is queried after the HW cleared the corresponding pin
assignment value in the TCSS_DDI_STATUS register after the sink got
disconnected.
For consistency, follow-up changes will use the cached max lane count
value on other platforms as well and will also cache the pin assignment
value in a similar way.
Cc: stable@vger.kernel.org # v6.8+
Reported-by: Charlton Lin <charlton.lin@intel.com>
Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250811080152.906216-5-imre.deak@intel.com
|
|
On LNL+ for a disconnected sink the pin assignment value gets cleared by
the HW/FW as soon as the sink gets disconnected, even if the PHY
ownership got acquired already by the BIOS/driver (and hence the PHY
itself is still connected and used by the display). During HW readout
this can result in detecting the PHY's max lane count as 0 - matching
the above cleared aka NONE pin assignment HW state. For a connected PHY
the driver in general (outside of intel_tc.c) expects the max lane count
value to be valid for the video mode enabled on the corresponding output
(1, 2 or 4). Ensure this by setting the max lane count to 4 in this
case. Note, that it doesn't matter if this lane count happened to be
more than the max lane count with which the PHY got connected and
enabled, since the only thing the driver can do with such an output -
where the DP-alt sink is disconnected - is to disable the output.
v2: Rebased on change reading out the pin configuration only if the PHY
is connected.
Cc: stable@vger.kernel.org # v6.8+
Reported-by: Charlton Lin <charlton.lin@intel.com>
Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250811080152.906216-4-imre.deak@intel.com
|
|
The PHY's pin assignment value in the TCSS_DDI_STATUS register - as set
by the HW/FW based on the connected DP-alt sink's TypeC/PD pin
assignment negotiation - gets cleared by the HW/FW on LNL+ as soon as
the sink gets disconnected, even if the PHY ownership got acquired
already by the driver (and hence the PHY itself is still connected and
used by the display). This is similar to how the PHY Ready flag gets
cleared on LNL+ in the same register.
To be able to query the max lane count value on LNL+ - which is based on
the above pin assignment - at all times even after the sink gets
disconnected, the max lane count must be determined and cached during
the PHY's HW readout and connect sequences. Do that here, leaving the
actual use of the cached value to a follow-up change.
v2: Don't read out the pin configuration if the PHY is disconnected.
Cc: stable@vger.kernel.org # v6.8+
Reported-by: Charlton Lin <charlton.lin@intel.com>
Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250811080152.906216-3-imre.deak@intel.com
|
|
The TypeC PHY HW readout during driver loading and system resume
determines which TypeC mode the PHY is in (legacy/DP-alt/TBT-alt) and
whether the PHY is connected, based on the PHY's Owned and Ready flags.
For the PHY to be in DP-alt or legacy mode and for the PHY to be in the
connected state in these modes, both the Owned (set by the BIOS/driver)
and the Ready (set by the HW) flags should be set.
On ICL-MTL the HW kept the PHY's Ready flag set after the driver
connected the PHY by acquiring the PHY ownership (by setting the Owned
flag), until the driver disconnected the PHY by releasing the PHY
ownership (by clearing the Owned flag). On LNL+ this has changed, in
that the HW clears the Ready flag as soon as the sink gets disconnected,
even if the PHY ownership was acquired already and hence the PHY is
being used by the display.
When inheriting the HW state from BIOS for a PHY connected in DP-alt
mode on which the sink got disconnected - i.e. in a case where the sink
was connected while BIOS/GOP was running and so the sink got enabled
connecting the PHY, but the user disconnected the sink by the time the
driver loaded - the PHY Owned but not Ready state must be accounted for
on LNL+ according to the above. Do that by assuming on LNL+ that the PHY
is connected in DP-alt mode whenever the PHY Owned flag is set,
regardless of the PHY Ready flag.
This fixes a problem on LNL+, where the PHY TypeC mode / connected state
was detected incorrectly for a DP-alt sink, which got connected and then
disconnected by the user in the above way.
v2: Rename tc_phy_in_legacy_or_dp_alt_mode() to tc_phy_owned_by_display().
(Luca, Jani)
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org # v6.8+
Reported-by: Charlton Lin <charlton.lin@intel.com>
Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
[Imre: Add one-liner function documentation for tc_phy_owned_by_display()]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250811080152.906216-2-imre.deak@intel.com
|
|
This is a scripted split of the display related register macros from
i915_reg.h to display/intel_display_regs.h. As a starting point, move
all the macros that are only used in display code (or GVT). If there are
users in core i915 code or soc/, or no users anywhere, keep the macros
in i915_reg.h. This is done in groups of macros separated by blank
lines, moving the comments along with the groups.
Some manually picked macro groups are kept/moved regardless of the
heuristics above.
This is obviously a very crude approach. It's not perfect. But there are
4.2k lines in i915_reg.h, and its refactoring has ground to a halt. This
is the big hammer that splits the file to two, and enables further
cleanup.
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> # v2
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20250606102256.2080073-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
intel_dp_mst_active_streams()
It's not clear which encoder intel_dp_mst_encoder_active_links() refers
to (primary/stream), but there is also no reason to call the queried
property an encoder property; remove encoder from the name. Also it's
the number of MST streams being queried, vs. the number of MST links
(there is one MST link carrying one or more MST streams), so rename link
to stream as well.
While at it pass intel_dp to the function, which is more logical and
makes it easier to re-use the function later (without the need to get
the digital port pointer).
Also move the function earlier, next to the related ones.
Suggested-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250404150310.1156696-5-imre.deak@intel.com
|
|
Forward declare struct drm_printer instead of including drm/drm_print.h,
as we only need the pointer. Turns out quite a few places depend on this
include implicitly. Make them explicit.
Some of the includes are just stale and unnecessary. Group the forward
declarations together while at it.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/20250326115452.2090275-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Going forward, struct intel_display is the main display device data
pointer. Convert intel_tc.c to struct intel_display.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/bbff21269f348ac72eb749b6cf3f692234bed9f2.1742554320.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Convert the remaining intel_display_power.h interfaces to
take struct intel_display instead of struct drm_i915_private.
intel_display_power.c still has some internal uses due to
i915->runtime_pm.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250211000135.6096-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
Pass intel_display to the display power stuff. These are spread
all over the place so tend to hinder clean conversions of whole
files.
TODO: The gt part/unpark power domain shenanigans need some
kind of more abstract interface...
v2: Deal with cmtg
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250206185533.32306-7-ville.syrjala@linux.intel.com
|
|
Backmerge to get the DRM DP payload and ACT helpers to drm-intel-next.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Let's start using struct intel_display instead of struct drm_i915_private
when introducing new code. No functional changes.
v2: Drop tc_to_intel_display() helper function (Jani)
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241127073200.124907-3-mika.kahola@intel.com
|
|
There is a HW issue that arises when there are race conditions
between TCSS entering/exiting TC7 or TC10 states while the
driver is asserting/deasserting TCSS power request. As a
workaround, Display driver will implement a mailbox sequence
to ensure that the TCSS is in TC0 when TCSS power request is
asserted/deasserted.
The sequence is the following
1. Read mailbox command status and wait until run/busy bit is
clear
2. Write mailbox data value '1' for power request asserting
and '0' for power request deasserting
3. Write mailbox command run/busy bit and command value with 0x1
4. Read mailbox command and wait until run/busy bit is clear
before continuing power request.
v2: Rename WA function (Gustavo)
Limit WA only for PTL platform with a TODO note (Gustavo)
Add TCSS_DISP_MAILBOX_IN_CMD_RUN_BUSY for clarity when writing
register data (Gustavo)
Move register defs from i915_reg.h to intel_cx0_phy_regs.h (Gustavo)
v3: Use "struct intel_display" instead of "struct drm_i915_private" (Jani)
Move defs above C10 definitions in the
intel_cx0_phy_regs.h file (Gustavo)
Move drm_WARN_ON() inside WA function (Gustavo)
Rename workaround function as wa_14020908590() (Gustvo)
Use boolean enable instead of if-else structure (Raag)
v4: Drop drm_WARN_ON() (Raag)
Fix function definition to fit into a single line (Raag)
v5: Drop TCSS_DISP_MAILBOX_IN_CMD_RUN_BUSY from TCSS_DISP_MAILBOX_IN_CMD_DATA(val)
macro (Jani)
Rename WA function with some meaningful name and add comment
on WA number (Jani)
Use struct intel_display on WA calling function (Jani)
Reviewed-by: Raag Jadav <raag.jadav@intel.com> (v4)
Acked-by: Jani Nikula <jani.nikula@intel.com> (v5)
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241127073200.124907-2-mika.kahola@intel.com
|
|
dig_port->saved_port_bits is used to permanently store two DDI_BUF_CTL
bits, DDI_BUF_PORT_REVERSAL and DDI_A_4_LANES. Store them separately as
bools to make their use more logical and less about storing state as
register bits.
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241129102503.452272-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Replace the last few remaining instances of string enable(d)/disable(d)
choices with the linux string choice helpers to avoid further
cocci warnings.
Signed-off-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241023054655.4017489-1-sai.teja.pottumuttu@intel.com
|
|
Starting with Xe_LPD+, although FIA is still used to readout Type-C pin
assignment, part of Type-C support is moved to PICA and programming
PORT_TX_DFLEXDPMLE1(*) registers is not applicable anymore like it was
for previous display IPs (e.g. see BSpec 49190).
v2:
- Mention Bspec 49190 as a reference of instructions for previous
IPs. (Shekhar Chauhan)
- s/Xe_LPDP/Xe_LPD+/ in the commit message. (Matt Roper)
- Update commit message to be more accurate to the changes in the IP.
(Imre Deak)
Bspec: 65750, 65448
Reviewed-by: Shekhar Chauhan <shekhar.chauhan@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240625202652.315936-1-gustavo.sousa@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
Wherever possible, replace the port/phy based functions with the encoder
based functions:
intel_is_c10phy() -> intel_encoder_is_c10phy()
intel_phy_is_combo() -> intel_encoder_is_combo()
intel_phy_is_tc() -> intel_encoder_is_tc()
intel_port_to_phy() -> intel_encoder_to_phy()
intel_port_to_tc() -> intel_encoder_to_tc()
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ce8d116fcdd7662fa0a0817200a8e6fda313e496.1710949619.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Some registers for DDI A/B moved to PICA and now follow the same format
as the ones for the PORT_TC ports. The wrapper here deals with 2 issues:
- Share the implementation between xe2lpd and previous
platforms: there are minor layout changes, it's mostly the
register location that changed
- Handle offsets after TC ports
v2:
- Explain better the trick to use just the second range (Matt Roper)
- Add missing conversions after rebase (Matt Roper)
- Use macro instead of inline function, avoiding includes in the
header (Jani)
- Prefix old macros with underscore so they don't get used by mistake,
and name the new ones using the previous names
v3: Use the same logic for the recently-introduced XELPDP_PORT_MSGBUS_TIMER
(Gustavo)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240126224638.4132016-3-lucas.demarchi@intel.com
|
|
Glitches deasserting the connector HPD line can lead to incorrectly
detecting a disconnect event (a glitch asserting the line will only
cause a redundant connect->disconnect transition). The source of such a
glitch can be noise on the line or a 0.5ms-1ms MST IRQ_HPD pulse. TypeC
ports in the DP-alt or TBT-alt mode filter out these glitches inernally,
but for others the driver has to do this. Make it so by polling the HPD
line on these connectors for 4 ms.
Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-12-imre.deak@intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
Add hooks to intel_digital_port to lock and unlock the port and add a
helper to check the connector's detect status while the port is locked
already. This simplifies checking the connector detect status in
intel_dp_aux_xfer() and intel_digital_port_connected() in the next two
patches aborting AUX transfers on all DP connectors (except eDP) and
filtering HPD glitches.
Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-11-imre.deak@intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
|
|
When going through the disconnection flow we don't need to wait for PHY
readiness and hence we can skip the wait part. For disabling the function
returns false as an indicator that the power is not enabled. After all,
we are not even using the return value when Type-C is disconnecting.
v2: Cleanup for increased readibility (Imre)
BSpec: 65380
For VLK-53734
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231212115130.485911-1-mika.kahola@intel.com
|
|
Fix below compiler warning:
intel_tc.c:1879:11: error: ‘%d’ directive output may be truncated
writing between 1 and 11 bytes into a region of size 3
[-Werror=format-truncation=]
"%c/TC#%d", port_name(port), tc_port + 1);
^~
intel_tc.c:1878:2: note: ‘snprintf’ output between 7 and 17 bytes
into a destination of size 8
snprintf(tc->port_name, sizeof(tc->port_name),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%c/TC#%d", port_name(port), tc_port + 1);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
v2: use kasprintf(Imre)
v3: use const for port_name, and fix tc mem leak(Imre)
Fixes: 3eafcddf766b ("drm/i915/tc: Move TC port fields to a new intel_tc_port struct")
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231026125636.5080-1-nirmoy.das@intel.com
|
|
Starting from display version 20, we need to read the pin assignment
from the IOM TCSS_DDI_STATUS register instead of reading it from the
FIA.
We use the pin assignment to decide the maximum lane count. So, to
support this change, add a new lnl_tc_port_get_max_lane_count() function
that reads from the TCSS_DDI_STATUS register and decides the maximum
lane count based on that.
BSpec: 69594
Cc: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-14-lucas.demarchi@intel.com
|
|
It is irrelevant for the caller that the max lane count is being
derived from a FIA register, so having "fia" in the function name is
irrelevant. Rename the function accordingly.
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230825081638.275795-5-luciano.coelho@intel.com
|
|
This makes the code a bit more symmetric and readable, especially when
we start adding more display version-specific alternatives.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230825081638.275795-4-luciano.coelho@intel.com
|
|
This function is only used locally, so make it static and remove the
definition from the header file.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230825081638.275795-3-luciano.coelho@intel.com
|
|
This function doesn't really return the pin assignment mask, but the
max lane count derived from that. So rename the function to
mtl_tc_port_get_max_lane_count() to better reflect what it really does.
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230825081638.275795-2-luciano.coelho@intel.com
|
|
disconnects
If the output on a DP-alt link with its sink disconnected is kept
enabled for too long (about 20 sec), then some IOM/TCSS firmware timeout
will cause havoc on the PCI bus, at least for other GFX devices on it
which will stop powering up. Since user space is not guaranteed to do a
disabling modeset in time, switch such disconnected but active links to
TBT mode - which is without such shortcomings - with a 2 second delay.
If the above condition is detected already during the driver load/system
resume sanitization step disable the output instead, as at that point no
user space or kernel client depends on a consistent output state yet and
because subsequent atomic modeset on such connectors - without the
actual sink capabilities available - can fail.
An active/disconnected port as above will also block the HPD status of
other active/disconnected ports to get updated (stuck in the connected
state), until the former port is disabled, its PHY is disconnected and
a ~10 ms delay has elapsed. This means the link state for all TypeC
ports/CRTCs must be rechecked after a CRTC is disabled due to the above
reason. For this disconnect the PHY synchronously after the CRTC/port is
disabled and recheck all CRTCs for the above condition whenever such a
port is disabled.
To account for a race condition during driver loading where the sink is
disconnected after the above sanitization step and before the HPD
interrupts get enabled, do an explicit check/link reset if needed from
the encoder's late_register hook, which is called after the HPD
interrupts are enabled already.
v2:
- Handle an active/disconnected port blocking the HPD state update of
another active/disconnected port.
- Cancel the delayed work resetting the link also from the encoder
enable/suspend/shutdown hooks.
- Rebase on the earlier intel_modeset_lock_ctx_retry() addition,
fixing here the missed atomic state reset in case of a retry.
- Fix handling of an error return from intel_atomic_get_crtc_state().
- Recheck if the port needs to be reset after all the atomic state
is locked and async commits are waited on.
v3:
- Add intel_crtc_needs_link_reset(), instead of open-coding it,
keep intel_crtc_has_encoders(). (Ville)
- Fix state dumping and use a bitmask to track disabled CRTCs in
intel_sanitize_all_crtcs(). (Ville)
- Set internal in intel_atomic_state right after allocating it.
(Ville)
- Recheck all CRTCs (not yet force-disabled) after a CRTC is
force-disabled for any reason (not only due to a link state)
in intel_sanitize_all_crtcs().
- Reduce delay after CRTC disabling to 20ms, and use the simpler
msleep().
- Clarify code comment about HPD behaviour in
intel_sanitize_all_crtcs().
- Move all the TC link reset logic to intel_tc.c .
- Cancel the link reset work synchronously during system suspend,
driver unload and shutdown.
v4:
- Rebased on previous patch, which allows calling the TC port
suspend/cleanup handlers without modeset locks held; remove the
display driver suspended assert from the link reset work
accordingly.
v5: (Ville)
- Remove reset work canceling from intel_ddi_pre_pll_enable().
- Track a crtc vs. pipe mask in intel_sanitize_all_crtcs().
- Add reset_link_commit() to clarify the
intel_modeset_lock_ctx_retry loop.
Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5860
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230512195513.2699-2-imre.deak@intel.com
|
|
Unlike previous platforms that used PORT_TX_DFLEXDPSP
for max_lane calculation, MTL uses only PORT_TX_DFLEXPA1
from which the max_lanes has to be calculated.
Bspec: 50235, 65380
Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Jose Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-13-mika.kahola@intel.com
|
|
The HPD live status for MTL has to be read from different set of
registers. MTL deserves a new function for this purpose
and cannot reuse the existing HPD live status detection
Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-12-mika.kahola@intel.com
|
|
Add register writes to enable powering up Type-C subsystem i.e. TCSS.
For MeteorLake we need to request TCSS to power up and check the TCSS
power state after 500 us.
In addition, for PICA we need to set/clear the Type-C PHY ownnership
bit when Type-C device is connected/disconnected.
Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-11-mika.kahola@intel.com
|
|
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: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230405104142.766598-1-jani.nikula@intel.com
|
|
After the previous patch the workaround for a TC PHY hang issue is not
required any more, remove it.
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-29-imre.deak@intel.com
|
