Add the necessary structures and functions to handle reading and
unpacking Adaptive Sync Secondary Data Packets. Also add support
to write and pack AS SDP.
--v2:
- Correct use of REG_BIT and REG_GENMASK. [Jani]
- Use as_sdp instead of async. [Jani]
- Remove unrelated comments and changes. [Jani]
- Correct code indent. [Jani]
--v3:
- Update definition names for AS SDP which are starting from
HSW, as these defines are applicable for ADLP+.(Ankit)
--v4:
- Remove as_sdp_mode from crtc_state.
- Drop metadata keyword.
- For consistency, update ADL_ prefix or post fix as required.
--v5:
- Check if AS_SDP bit is set in crtc_state->infoframes.enable. If not
return.
- Check for HAS_AS_SDP() before setting VIDEO_DIP_ENABLE_AS_ADL mask.
--v6:
- Rename intel_read_dp_infoframe_as_sdp to intel_read_dp_as_sdp.
--v7:
- Add read back for length and vtotal correction.
--v8:
- Use as_sdp->target_rr & 0xFF.
- Shift by 8 instead of 32, and drop casting to u64.
- Remove changes which are does not belong to this patch.
Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240322031157.3823909-5-mitulkumar.ajitkumar.golani@intel.com
After an HPD IRQ storm on a connector intel_hpd_irq_storm_detect() will
set the connector's HPD pin state to HPD_MARK_DISABLED and the IRQ gets
disabled. Subsequently intel_hpd_irq_storm_switch_to_polling() will
enable polling for these connectors, setting the pin state to
HPD_DISABLED, but only if the connector's base.polled field is set to
DRM_CONNECTOR_POLL_HPD. intel_hpd_irq_storm_reenable_work() will
reenable the IRQ - after 2 minutes - if the pin state is HPD_DISABLED.
The connectors will be created with their base.polled field set to 0,
which gets initialized only later in i915_hpd_poll_init_work() (using
intel_connector::polled). If a storm is detected on a connector after
it's created and IRQs are enabled on it - by intel_hpd_init() - and
before its bease.polled field is initialized in the above work, the
connector's HPD pin will stay in the HPD_MARK_DISABLED state - leaving
the IRQ disabled indefinitely - and polling will not get enabled on it as
intended.
I can't see a reason for initializing base.polled in a delayed manner,
so do this already when creating the connector, to prevent the above
race condition.
Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-2-imre.deak@intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Update intel_hdcp_shim funcs specifically read_2_2_message,
write_2_2_message and config_stream_type to use intel_connector
argument instead of intel_digital_port as this will help in getting
correct aux later for dp mst scenarios also already hdcp funcs
derive digital_port from connector and then many funcs again get back
the connector from dig_port which doesn't seem right.
Connector specific hdcp functions can derive dig_port on need basis.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230828063401.600414-2-suraj.kandpal@intel.com
The issue fixed in
commit a8ddac7c9f ("drm/i915: Avoid HPD poll detect triggering a new detect cycle")
on VLV, CHV is still present on platforms where the display hotplug
detection functionality is available whenever the device is in D0 state
(hence these platforms switch to HPD polling only when the device is
runtime suspended).
The above commit avoids an endless i915_hpd_poll_init_work() ->
connector detect loop by making sure that by the end of
i915_hpd_poll_init_work() all display power references acquired by the
connector detect functions which can trigger a new cycle (display core
power domain) are dropped. However on platforms where HPD polling is
enabled/disabled only from the runtime suspend/resume handlers, this is
not ensured: for instance eDP VDD, TypeC port PHYs and the runtime
autosuspend delay may still keep the device runtime resumed (via a power
reference acquired during connector detection and hence result in an
endless loop like the above).
Solve the problem described in the above commit on all platforms, by
making sure that a i915_hpd_poll_init_work() -> connector detect
sequence can't take any power reference in the first place which would
trigger a new cycle, instead of relying on these power references to be
dropped by the end of the sequence.
With the default runtime autosuspend delay (10 sec) this issue didn't
happen in practice, since the device remained runtime resumed for the
whole duration of the above sequence. CI/IGT tests however set the
autosuspend delay to 0, which makes the problem visible, see References:
below.
Tested on GLK, CHV.
v2: Don't warn about a requeued work, to account for disabling
polling directly during driver loading, reset and system resume.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/7940#note_1997403
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230809104307.1218058-1-imre.deak@intel.com
Stop with the VBT DDC pin sanitation, and instead just check
that the appropriate DDC pin is still available when initializing
a HDMI connector.
The reason being that we want to start initializing ports in
VBT order to deal with VBTs that declare child devices with
seemingly conflicting ports. As the encoder initialization can
fail for other reasons (at least for eDP+AUX) we can't know
upfront which way the conflicts should be resolved.
Note that the old way of sanitizing gave priority to the last
port declared in the VBT, but now we sort of do the opposite by
favoring the first encoder to successfully initialize. So far
we're not aware of HDMI/DDC use cases where this would matter
but for AUX CH (will be subject to a similar change) there are
known cases where it matters.
Also note that the old code fell back to the platform default DDC
pin if the VBT pin was populated but invalid. That doesn't seem like
such a great idea because the VBT might have later declared another
port using that platform default pin, and so we might just be
creating more DDC pin conflicts here. So lets not second guess the
VBT and simply reject the entire HDMI encoder if the VBT DDC pin is
invalid.
v2: Pimp the commit message (Jani)
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230630155846.29931-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
On g4x the hardware has only one audio/video DIP block. Thus
only one HDMI port can transmit audio/infoframes at a time.
Currently we pretend that multiple ports can do it at the same
time, but that doesn't actually work for two reasons:
- the state of the single hw block will get clobbered by
the multiple ports, leading to state checker failures
- the hardware will automagically disable audio/infoframe
transmission when enabled on multiple ports
To fix this let's allow only one of the ports to transmit
audio/infoframes at a time. We'll just go over all the HDMI
ports and pick the first one that is otherwise capable of
audio/infoframes. Further HDMI ports will be treated as if
they had a DVI sink connected.
In order to compute this consistently we'll also need to
always add all HDMI ports to the atomic state.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221107194604.15227-6-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
The decision to use DFP output format conversion capabilities should be
during compute_config phase.
This patch adds new member to crtc_state to represent the final
output_format to the sink. In case of a DFP this can be different than
the output_format, as per the format conversion done via the PCON.
This will help to store only the format conversion capabilities of the
DP device in intel_dp->dfp, and use crtc_state to compute and store the
configuration for color/format conversion for a given mode.
v2: modified the new member to crtc_state to represent the final
output_format that eaches the sink, after possible conversion by
PCON kind of devices. (Ville)
v3: Addressed comments from Ville:
-Added comments to clarify difference between sink_format and
output_format.
-Corrected the order of setting sink_format and output_format.
-Added readout for sink_format in get_pipe_config hooks.
v4: Set sink_format for intel_sdvo too. (Ville)
v5: Rebased.
v6: Fixed condition to go for YCbCr420 format for dp and hdmi. (Ville)
v7: Fix the condition to set sink_format for HDMI.
Set hdmi output_format simply as sink_format. (Ville)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v3)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230427125605.487769-2-ankit.k.nautiyal@intel.com
Like DG2, we still don't have a proper algorithm that can be used
for calculating PHY settings, but we do have tables of register
values for a handful of the more common link rates. Some support is
better than none, so let's go ahead and add/use these tables when we
can, and also add some logic to hdmi_port_clock_valid() to filter the
modelist to just the modes we can actually support with these link
rates.
Hopefully we'll have a proper / non-encumbered algorithm to calculate
these registers by the time we upstream and we'll be able to replace
this patch with something more general purpose.
Bspec: 64568
v2: Rebasing with Clint's HDMI C10 PLL tables (Mika)
v3: Remove the extra hdmi clock check pruning.
Cc: Imre Deak <imre.deak@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230413212443.1504245-8-radhakrishna.sripada@intel.com
