We have a function that gets us the total of the vdsc engines being
used but not the no. of vdsc instances being used by each pipe.
--v6
-Change function to static
--v7
-Shorten name to intel_dsc_get_vdsc_per_pipe
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230828054300.560559-4-suraj.kandpal@intel.com
In intel_vdsc_get_config we only read the primary dsc engine register
and not take into account if the other dsc engine is in use and if
both registers have the same value or not this patche fixes that by
adding a check.
--v3
-Remove superfluos new line [Jani]
-Fix register naming [Jani]
--v5
-pps_temp0/pps_temp1 can be assigned where they are used [Ankit]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230828054300.560559-3-suraj.kandpal@intel.com
This patch refactors dsc register related macros that prepares
the values to be written in the register. The current bit shifting
looks bad and going forward will not serve our purpose to readout
dsc register field values the change was suggested by Jani Nikula.
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230828054300.560559-2-suraj.kandpal@intel.com
Take into account dma fences in dirtyfb callback. If there is no
unsignaled dma fences perform flush immediately. If there are
unsignaled dma fences perform invalidate and add callback which will
queue flush when the fence gets signaled.
v4:
- Move invalidate before callback is added
v3:
- Check frontbuffer bits before adding any fence fb
- Flush only when adding fence cb succeeds
v2: Use dma_resv_get_singleton
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230901093500.3463046-5-jouni.hogander@intel.com
We want to wait dma fences in dirtyfb ioctl. As we don't want to make
dirtyfb ioctl as blocking call we need to use
dma_fence_add_callback. Callback used for dma_fence_add_callback is
called from atomic context. Due to this we need to add a new
frontbuffer tracking interface to queue flush.
v3:
- Check schedule work success rather than work being pending
- Init flush work when frontbuffer struct is initialized
v2: Check if flush work is already pending
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230901093500.3463046-4-jouni.hogander@intel.com
We are planning to move flush performed from work queue. This
means it is possible to have invalidate -> flip -> flush sequence.
Handle this by clearing possible busy bits on flip.
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230901093500.3463046-3-jouni.hogander@intel.com
We are planning to move flush performed from work queue. This
means it is possible to have invalidate -> flip -> flush sequence.
Handle this by clearing possible busy bits on flip.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230901093500.3463046-2-jouni.hogander@intel.com
In the drm subsystem, the source physical address is, in most cases,
available without having to parse the EDID again. Add notes about
preferring to use the pre-parsed address instead.
Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Cc: linux-media@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Link: https://patchwork.freedesktop.org/patch/msgid/20230831105144.25923-1-jani.nikula@intel.com
Connectors have source physical address available in display
info. There's no need to parse the EDID again for this. Add
drm_dp_cec_attach() to do this.
Seems like the set_edid/unset_edid naming is a bit specific now that
there's no need to pass the EDID at all, so aim for attach/detach going
forward.
v2: Fix the embarrashing build failures
Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Cc: linux-media@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230825130120.1250089-1-jani.nikula@intel.com
Send the correct aux rather than the one derived
from intel_digital_port so that the HDCP version of both monitors
are fetched rather than just the primary one's
Signed-off-by: Suraj Kandpal <suraj.kandpal@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/20230830073437.666263-3-suraj.kandpal@intel.com
Use intel_connector as argument instead of intel_digital_port in
hdcp_2_2_capable function and dig_port can be later derived from
connector. This will help with getting the correct hdcp version of
particular monitor in a MST setup.
Signed-off-by: Suraj Kandpal <suraj.kandpal@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/20230830073437.666263-2-suraj.kandpal@intel.com
Split out frontbuffer related declarations and static inlines from
gem/i915_gem_object.h into new gem/i915_gem_object_frontbuffer.h.
The main goal is to reduce header interdependencies. With
gem/i915_gem_object.h including display/intel_frontbuffer.h,
modification of the latter causes a whopping 300+ objects to be rebuilt,
while many of the source files actually needing it aren't explicitly
including it at all.
After the change, only 21 objects depend on display/intel_frontbuffer.h,
directly or indirectly.
Cc: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230830085127.2416842-1-jani.nikula@intel.com
intel_dp_force() takes the AUX power reference as required by the DP AUX
transactions in intel_dp_set_edid(). However the low level AUX handler
takes this reference already so the get/put in intel_dp_force() can be
dropped. This also fixes a problem where the TC port mode changed while
the AUX power well was enabled.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8779
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230830140421.2031111-1-imre.deak@intel.com
The bspec has been updated with a new revision 0x1 that
translates to A1 GT stepping and C0 display stepping.
Bspec: 44477
Signed-off-by: Swati Sharma <swati2.sharma@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230829135945.1201574-1-swati2.sharma@intel.com
As per DP v1.4, a DP DSC Sink device shall support 8bpc in DPCD 6Ah.
Apparently some panels that do support DSC, are not setting the bit for
8bpc.
So always assume 8bpc support by DSC decoder, when DSC is claimed to be
supported.
v2: Use helper to get check dsc support. (Ankit)
v3: Fix styling and other typos. (Jani)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230824125121.840298-2-ankit.k.nautiyal@intel.com
Each SDVO device can have up to three sets of DDC pins.
Currently we just register a single i2c_adapter for the
entire SDVO device and semi-randomly pick the "correct"
set of DDC pins during intel_sdvo_tmds_sink_detect().
This doesn't make any real sense especially if we have
multiple outputs each with their own dedicated DDC bus.
Let's clean up this mess and register a dedicated
i2c_adapter for each of the possible pin pairs. Each
output (ie. connector) can then pick the correct i2c_adapter
to use for its DDC bus. And we can just switch over to
drm_connector_init_with_ddc() to take care of the
connector->ddc association, which also populates the
"ddc" sysfs symlink as a bonus.
And now that things are based on the actual connector we can
also nuke the sketchy sdvo->controller_output thing.
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/20230825134431.24391-6-ville.syrjala@linux.intel.com
We should switch over to the standard "ddc" per-connector
symlink instead of rolling our own thing. The i2c specific
symlink is also in the way of reworking the SDVO DDC handling
(which is a mess atm) so get rid of it.
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/20230825134431.24391-5-ville.syrjala@linux.intel.com
Instead of operating on the output the user specified (via the
connector) the current code tends to operate on whichever outputs
it has detected as attached. That is not how the kms uapi is supposed
to work. So simply get rid of attached_outputs and instead directly
operate on the output the user has specified.
Acked-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/20230825134431.24391-2-ville.syrjala@linux.intel.com
For dpmst hdcp scenario increase the message timeout based
on the number of ports connected as each port needs to be
validated and each will take the prescribed amount of time
for the respective msg_id and total timeout will be
original_timeout * num_ports.
--v2
-Add justification for Adjusting the timeout [Arun]
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-5-suraj.kandpal@intel.com
Up until now we were sending the base aux stored in dig_port which
is not correct as this causes an issue when monitor is connected via
a DPMST hub causing it to be remote hence we end up seeing AUX
failures so let's send the remote aux in case of DPMST.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Arun R Murthy <arun.r.mruthy@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230828063401.600414-4-suraj.kandpal@intel.com
We were propagating dig_port info to dp hdcp2 specific functions.
Let us clean that up and send intel_connector in the following
functions: intel_dp_hdcp2_wait_for_msg, get_receiver_id_list_rx_info,
intel_dp_hdcp2_read_rx_status.
This optimises mst scenarios where aux ends up being remote and not
stored in dig_port and dig_port can always be derived from
intel_connector if needed.
--v2
-Fix Typo [Arun]
-Dont pass drm_dp core structures [Arun]
-Fix commit message styling [Arun]
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/20230828063850.604048-1-suraj.kandpal@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
Update pci device ids as per bspec for
RPL P/U.
v2:
- Append new id's instead of replacing the existing in device
id list define
v3:
- Fixed the commit messege with revision details.
Bpsec: 55376
Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230824062840.2372872-1-dnyaneshwar.bhadane@intel.com
port_clock is what the encoder/dpll code is supposed to calculate,
it is not the input clock. Use the dotclock as the target we're
trying to achieve instead.
TODO: the SDVO TV clocking is a mess atm and needs further work
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230705202122.17915-7-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Call *_calc_dpll_params() even in cases where the encoder has
computed the DPLL params for us.
The SDVO TV output code doesn't populate crtc_state->dpll.dot
leading to the dotclock getting calculated as zero, and that
leads to all kinds of real problems. The g4x DP code also
doesn't populate the derived dividers nor .vco, which could
also create some confusion.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230705202122.17915-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Allow *_calc_dpll_params() to be called even if the N/P dividers
are zero without warning. We'll want to call these to make sure the
derived values are fully computed, but not all users (VLV DSI in
particular) even enable the DPLL and thus the dividers will
be left at zero.
It could also be possible that the BIOS has misprogrammed the DPLL
(IIRC happened with some SNB machines with 4k+ displays) and thus
we'll currently generate a lot of dmesg spew. Better be silent and
just let the normal state checker/etc. deal with any driver bugs.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230705202122.17915-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
The SDVO inputs are reported a simple number, not a bitmask.
Adjust the code to match reality.
Note that we don't actually support dual input SDVO devices,
and we just always use the first input.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230705202122.17915-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
I have at least one SDVO device (some Lenovo DVI-I ADD2 card,
based on Conexant CX25904) where GetAttachedDisplays returns
success but fails to report any attached displays unless we
precede the command with a SetTargetOutput. Make it so.
I wasn't able to spot anything in the SDVO spec stating that
this should be necessary, but real world wins over spec.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230705202122.17915-2-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
