Register read functions usually return the value instead of passing via
pointer parameters. Return the multiple register verification results
via a pointer parameter, which can also be NULL to skip the extra
checks.
Make the name conform to existing style better while at it.
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/4d08c0f63c4975cc8cd01b0f82845c989bf13dd0.1693933849.git.jani.nikula@intel.com
Register read functions usually return the value instead of passing via
pointer parameters. The calling code becomes easier to read.
Make the name conform to existing style better while at it.
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/89b7d70bb19114ab3ff0e150a4b862d8032f136d.1693933849.git.jani.nikula@intel.com
Make it clear what's the number of vdsc per pipe, and what's the number
of registers to grab. Have intel_dsc_get_pps_reg() return the registers
it knows even if the requested amount is bigger.
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e2551b52ac0dd2b4ffe18d5e7733fafdc191d68a.1693933849.git.jani.nikula@intel.com
Apparently Acer Chromebook C740 (BDW-ULT) doesn't have the
eDP HPD line properly connected, and thus fails the new
HPD check during eDP probe. The result is that we lose the
eDP output.
I suspect all such machines would be Chromebooks or other
Linux exclusive systems as the Windows driver likely wouldn't
work either. I did check a few other BDW machines here and
those do have eDP HPD connected, one of them even is a
different Chromebook (Samus).
To account for these funky machines let's skip the HPD check when
it looks like the eDP port is the only one using that specific AUX
channel. In case of multiple ports sharing the same AUX CH (eg. on
Asrock B250M-HDV) we still do the check and thus should correctly
ignore the eDP port in favor of the other DP port (usually a DP->VGA
converter).
v2: Don't oops during list iteration
Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9264
Fixes: cfe5bdfb27 ("drm/i915: Check HPD live state during eDP probe")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230908052527.685-1-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Rather than applying display workarounds as part of
intel_clock_gating_init() (which in turn is confusingly called from
i915_gem_init during device probe), handle them at the point we're
actually initializing the display hardware. This will also ensure that
these workarounds are properly applied during display initialization on
the Xe driver, which re-uses i915's display code, but does not call
i915's gem init.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230906234732.3728630-10-matthew.d.roper@intel.com
Several of the register updates that are currently done in the clock
gating init functions are actually display workarounds that should move
into the display-specific part of the code. Furthermore, some of the
registers being programmed don't even have anything to do with clock
gating at all.
Extract the display workarounds for gen11 and later platforms to a
dedicated display/intel_display_wa.c file to keep these separate from
the SOC / sgunit clock gating that we need on some platforms. The gen11
cutoff here is selected somewhat arbitrarily; this is the point where
workarounds were first assigned dedicated lineage numbers that can be
easily looked up and confirmed in the modern workaround database. It
also avoids any confusion on older platforms where the exact boundaries
between display/GT/other IP blocks wasn't as well-defined as it is
today.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230907001009.3732474-2-matthew.d.roper@intel.com
The only programming that happens in gen12lp_init_clock_gating is for
display workarounds that are specific to display version 12 and are not
relevant to ADL-P's display version 13.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230906234732.3728630-8-matthew.d.roper@intel.com
In the early days of i915, pretty much every platform needed to
initialize _something_ in the clock gating init functions. In some
cases the items initialized were inside the GT (and really should have
been initialized through the GT workaround infrastructure instead).
In other cases they were display programming (sometimes not even related
to "clock gating" at all!) which probably needs to move inside the
display-specific code. The number of initialization tasks that are
truly "clock gating" and don't fall within the GT or display domains is
relatively limited. Let's stop forcing future platforms to always
define a clock gating init hook.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230906234732.3728630-7-matthew.d.roper@intel.com
i915_gem_object_create_internal() does not hand out zeroed
memory. Thus we may confuse whatever stale garbage is in
there as a previous register write and mistakenly handle the
first actual register write as an indexed write. This can
end up corrupting the instruction sufficiently well to lose
the entire register write.
Make sure we've actually emitted a previous instruction before
attemting indexed register write merging.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230606191504.18099-7-ville.syrjala@linux.intel.com
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
We have experienced timeout issues when going through the sequence to
access C20 SRAM registers. Experimentation showed that bumping the
message bus timer threshold helped on getting display Type-C connection
on the C20 PHY to work.
While the timeout is still under investigation with the HW team, having
logic to allow forward progress (with the proper warnings) seems useful.
Thus, let's bump the threshold when a timeout is detected.
The bumped value of 0x200 pclk cycles was somewhat arbitrary - 2x the
default value. That value was successfully tested on real hardware that
was displaying timeouts otherwise.
v2:
- Reword commit message to indicate that access to C20 SRAM registers
is not direct. (Radhakrishna)
- Prefer not to use REG_FIELD_PREP() in intel_cx0_phy.c.
(Radhakrishna)
- Simplify intel_cx0_bus_check_and_bump_timer() to use a fixed bumped
value instead of progressively increasing the threshold. (Mika)
BSpec: 65156
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230830121524.15101-1-gustavo.sousa@intel.com
By at least strong convention, a print-buffer's trailing newline says
"message complete, send it". The exception (no TNL, followed by a call
to pr_cont) proves the general rule.
Most DRM.debug calls already comport with this: 207 DRM_DEV_DEBUG,
1288 drm_dbg. Clean up the remainders, in maintainer sized chunks.
No functional changes.
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
[Rodrigo changed subject while pushing]
Link: https://patchwork.freedesktop.org/patch/msgid/20230903184607.272198-4-jim.cromie@gmail.com
Normally PSR errors detected by the panel are triggering HPD interrupt and
seen as error in dmesg. Some panels are not triggering the interrupt even
it is requested and they are detecting error. Due to this it would be good
to have possibility to check panel detected errors. Add PSR error status
into PSR sink status debugfs interface.
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230828083107.1520501-1-jouni.hogander@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 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
With the dsc config being readout and filled in crtc_state add
macros and use them to compare current and previous PPS param in
DSC.
--v2
-Remove version check [Jani]
-Remove dupe macro for dsc pipe compare and use the existing ones
[Jani]
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-9-suraj.kandpal@intel.com
We have setup both the read and write functions so we can
move ahead and fill in all the readout state from PPS register
into the crtc_state so we can send it for comparision.
--v2
-Shorten comment to just PPSX rather than having the whole
"Readout PPSX register" [Jani]
-Remove pps_temp reinitialization as its being initialized in
the read function [Jani]
-Use REG_FIELD_GET to readout certain fields of dsc registers
[Jani]
--v9
-Place the masks at a more appropriate place [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-8-suraj.kandpal@intel.com
Now that we have macros that can fetch dsc register values based
on pipe and pps parameters we can go ahead and remove all the
unused register.
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-7-suraj.kandpal@intel.com
Now that we have a function that reads any PPS register based
on intel_dsc_pps enum provided lets create a function that can
write on any PPS.
--v2
-Changes need as PPS enum was dropped
-Remove duplicated code in intel_dsc_write_pps_reg [Jani]
--v3
-Use dsc_split instead of num_vdsc_instances [Ankit]
--v5
-Changes to implement the new dsc_reg array variable passing
[Ankit]
--v7
-Pass no of vdsc instances to get_pps_reg [Ankit]
--v8
-No need for dsc_reg dynamic allocation [Jani]
-Change function to void as no return needs to be sent back
--v9
-Send ARRAY_SIZE(dsc_reg) instead of vdsc_per_pipe [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-6-suraj.kandpal@intel.com
Add function to read any PPS register based on the
intel_dsc_pps enum provided. Add a function which will call the
new pps read function and place it in crtc state. Only PPS0 and
PPS1 are readout the rest of the registers will be read in upcoming
patches.
--v2
-Changes in read function as PPS enum is removed
-Initialize pps_val as 0 in pps_read func itself [Jani]
-Create a function that gets the required register and call that
in the common read function [Jani]
-Move the drm_WARN_ON one abstraction layer above [Jani]
--v3
-Send both reg values regardless of dsc engine no [Jani]
-Don't use num_vdsc_instances stick to dsc_split field [Ankit]
--v4
-Manipulate the reg values instead of creating MACRO to change
name of pps [Ankit]
--v5
-Read dsc reg values using array rather than individual variables
[Ankit]
-Loop the verification of all dsc engine reads to future proof it
[Ankit]
-Keep the fix me comment in this patch and remove it in later one
where we add other readouts [Ankit]
-Add switch statement that fills in the required registers based on
no of vdsc engines per pipe.
--v7
-Pass no of vdsc instances from read_reg function [Ankit]
-Fix issue where arrays do not get freed on return for read_and_verify
func [Ankit]
--v8
-Simplify reading and verifying of register and remove dynamically
allocated arrays [Jani]
-Remove no_ from no_vdsc_per_pipe and wherever else it applies [Ankit]
--v9
-change variable name to dsc_reg_size rather than vdsc_per_pipe [Ankit]
--v10
-remove switch case as we never enter case1 [Ankit]
--v11
-Add _ prefix for register that are not supposed to be used directly
[Jani]
-Remove REG suffix from register macros [Jani]
-Do not duplicate register read [Jani]
--v12
-Use vdsc_per_pipe rather than array size of dsc_reg [Jani]
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-5-suraj.kandpal@intel.com
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
