Age | Commit message (Collapse) | Author |
|
FBC is no longer limited by pipe: add the defines for pipes B and C that
will be used by platforms supporting FBC on such pipes.
Bspec: 68881, 68904
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-3-lucas.demarchi@intel.com
|
|
Add Lunar Lake platform definitions for i915 display. The support for
LNL will be added to the xe driver, with i915 only driving the display
side. Xe2 display is derived from the Xe_LPD+ IP; additional feature
deltas will be introduced in subsequent patches, so here it's just
adding a separate xe2_lpd_display struct.
v2: Use a LPDP_FEATURES macro (Matt Roper)
Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-2-lucas.demarchi@intel.com
|
|
Add a FEATURES macro for XE_LPD+ as this is expected to be the baseline
for Xe2_LPD and will allow to see the delta more easily.
v2: Move everything from xe_lpdp_display to the new macro and remove
the version setting: it's not needed with GMD_ID.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-1-lucas.demarchi@intel.com
|
|
This reverts commit 959fb1a686528df1b8fb0cc7bec8ff851b1594a5.
Looks like the core MST code might not call i2c_adapter() for us
in time, and thus creating the ddc symlink will fail. This will
in fact fail the entire connector registration, but the MST code
doesn't really seem to care about that and blindly plows ahead.
All we may get in the logs is a nearly back to back
register+unregister debug messages:
[drm:drm_dp_mst_connector_late_register [drm_display_helper]] registering DPMST remote bus for card0-DP-7
[drm:intel_dp_hpd_pulse [i915]] DPRX ESI: 42 00 00 02
[drm:drm_dp_mst_connector_early_unregister [drm_display_helper]] unregistering DPMST remote bus for card0-DP-7
Untangling the initialization order may take some real work,
so let's just revert the ddc symlink addition for now...
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9357
Fixes: 959fb1a68652 ("drm/i915/mst: Populate connector->ddc")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919095659.10742-1-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Karthik B S <karthik.b.s@intel.com>
|
|
Add a note that fec_enable actually means FEC is to be enabled
explicitly. 128b/132b always has FEC enabled, the driver doesn't need to
enable it separately, and fec_enable will be false.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230920112901.3315876-1-jani.nikula@intel.com
|
|
Implement low refresh rate (LRR) where we change the vblank
length by hand as requested, but otherwise keep the timing
generator running in non-VRR mode (ie. fixed refresh rate).
The panel itself must support VRR for this to work, and
only TGL+ has the double buffred TRANS_VTOTAL.VTOTAL that
we need to make the switch properly. The double buffer
latching happens at the start of transcoders undelayed
vblank. The other thing that we change is
TRANS_VBLANK.VBLANK_END but the hardware entirely ignores
that in DP mode. But I decided to keep writing it anyway
just to avoid more special cases in readout/state check.
v2: Document that TRANS_VBLANK.VBLANK_END is ignored by
the hardware
v3: Reconcile with VRR fastset
Adjust update_lrr flag behaviour
Make sure timings stay within VRR range
v4: Fix up update_m_n vs. update_lrr rebase fail (Manasi)
Drop DOUBLE_BUFFER_VACTIVE define as it's not needed (Manasi)
TODO: Hook LRR into the automatic DRRS downclocking stuff?
Cc: Manasi Navare <navaremanasi@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230915103800.14218-1-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
|
|
Whenever we change the actual transcoder timings (clock via
seamless M/N, full modeset, (or soon) vtotal via LRR) we
want the timing generator to be in non-VRR during the commit.
Warn if we forgot to turn VRR off prior to vblank evasion.
Cc: Manasi Navare <navaremanasi@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-12-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
|
|
We should be able to change any of the VRR parameters
during fastsets as long as we toggle VRR off at the start
and then back on at the end. The transcoder will be running
in non-VRR mode during the transition.
Co-developed-by: Manasi Navare <navaremanasi@chromium.org>
Signed-off-by: Manasi Navare <navaremanasi@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-11-ville.syrjala@linux.intel.com
Reviewed-by: Sean Paul <seanpaul@chromium.org>
|
|
Make life less confusing by making sure VRR is disabled whenever
we do any drastic changes to the display timings, such as seamless
M/N changes.
Cc: Manasi Navare <navaremanasi@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-10-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
|
|
Let's assume there are some crazy displays where the high
end of the VRR range ends up being lower than the refresh
rate as determined by the actual timings. In that case
when we toggle VRR on/off we would step outside the VRR
range when toggling VRR on/off. Let's just make sure that
never happens by not using VRR in such cases. If the user
really wants VRR they should then select the timings to
land within the VRR range.
Cc: Manasi Navare <navaremanasi@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-9-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
|
|
Move is_in_vrr_range() into intel_vrr.c in anticipation of
more users, and rename it accordingly.
Cc: Manasi Navare <navaremanasi@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-8-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
|
|
Don't perform a seamless M/N update if the values aren't actually
changing. This avoids doing extra shenanigans during vblank evasion
needlessly.
Cc: Manasi Navare <navaremanasi@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-7-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
|
|
Make the seamless_m_n flag more like the update_pipe fastset
flag, ie. the flag will only be set if we need to do the seamless
M/N update, and in all other cases the flag is cleared. Also
rename the flag to update_m_n to make it more clear it's similar
to update_pipe.
I believe special casing seamless_m_n like this makes sense
as it also affects eg. vblank evasion. We can potentially avoid
some vblank evasion tricks, simplify some checks, and hopefully
will help with the VRR vs. M/N mess.
Cc: Manasi Navare <navaremanasi@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-6-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
|
|
In order to reconcile seamless M/N updates with VRR we'll
need to defer the fastset VRR enable to happen after the
seamless M/N update (which happens during the vblank evade
critical section). So just push the VRR enable to be the last
thing during the update.
This will also affect the vblank evasion as the transcoder
will now still be running with the old VRR state during
the vblank evasion. So just grab the timings always from the
old crtc state during any non-modeset commit, and also grab
the current state of VRR from the active timings (as we disable
VRR before vblank evasion during fastsets).
This also fixes vblank evasion for seamless M/N updates as
we now properly account for the fact that the M/N update
happens after vblank evasion.
Cc: Manasi Navare <navaremanasi@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-5-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
|
|
Pull the vblank evasion scanline calculations into their own helper
to declutter intel_pipe_update_start() a bit.
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-4-ville.syrjala@linux.intel.com
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
|
|
We'll need to also look at the old crtc state in
intel_pipe_update_start() so change the calling convention to
just plumb in the full atomic state instead.
Cc: Manasi Navare <navaremanasi@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-3-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
|
|
Do the PSR unlock after the vblank evade critcal section is
fully over, not before.
Cc: Manasi Navare <navaremanasi@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230901130440.2085-2-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <navaremanasi@chromium.org>
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
|
|
This change is to adjust TCLK-POST timing so DSI signaling can
meet CTS specification.
For clock lane, the TCLK-POST timing may be changed from
133.44 ns to 178.72 ns, which is greater than (60 ns+52*UI)
and is conformed to the CTS standard.
The computed UI is around 1.47 ns.
v2: remove the change of HS-TRAIL.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Cc: Lee Shawn C <shawn.c.lee@intel.com>
Signed-off-by: William Tseng <william.tseng@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230914095137.4132029-1-william.tseng@intel.com
|
|
There was a recent update in the BSpec adding an extra step to the PLL
enable sequence, which is for programming the msgbus timer. Since we
also touch PHY registers during hw readout, let's do the programming
when starting a transaction rather than only when doing the PLL enable
sequence.
This might be the missing step that was causing the timeouts
that we have recently seen during C20 SRAM register programming
sequences. With this in place, we shouldn't need the logic to bump the
timer thresholds, since now we have a documented value that should be
set peform programming the registers. As such, let's also remove
intel_cx0_bus_check_and_bump_timer(), but keep the part that checks if
hardware really detected a timeout, which might be useful debugging
information.
v2:
- Use debug level instead of warning for the message notifying that
the hardware did not detect the timeout. (Mika)
- Got a new BSpec update clarifying that we need to program the msgbus
timer of both PHY lanes. Update the changes to reflect that.
(Gustavo)
BSpec: 64568
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/20230912155923.39494-1-gustavo.sousa@intel.com
|
|
If a sink is removed in the middle of payload addition
drm_dp_add_payload_part1() will fail as expected, either not finding the
payload's MST port or failing the payload-add AUX transaction.
Based on the above tune the error message down to a debug messge.
Cc: Lyude Paul <lyude@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230913223218.540365-4-imre.deak@intel.com
|
|
It's not necessary to carry separate suspended status information in
intel_runtime_pm struct as this information is already in underlying device
structure. Remove it and use pm_runtime_suspended() to obtain suspended
status information when needed.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230913100430.3433969-1-jouni.hogander@intel.com
|
|
Don't hide display probe in device info code.
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230912120537.2158209-3-jani.nikula@intel.com
|
|
Move gmdid selection one abstraction level higher.
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230912120537.2158209-2-jani.nikula@intel.com
|
|
Initializing i915->display.info.__device_info and DISPLAY_RUNTIME_INFO()
really belongs in display code. Move them there.
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230912120537.2158209-1-jani.nikula@intel.com
|
|
Avoid using GEM_BUG_ON() in display code.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/17e70eaf967bdfe99111cdbb3bcf6aa2f0b0e837.1694684044.git.jani.nikula@intel.com
|
|
Avoid using GEM_WARN_ON() in display code.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/593285450602c259b6985972d68511190c754bf5.1694684044.git.jani.nikula@intel.com
|
|
Avoid using GEM_BUG_ON() in display code.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a7d53a403822b43c7d78689a10480b47ccc0534d.1694684044.git.jani.nikula@intel.com
|
|
We aren't intending to mutate the SDVO device mapping structs,
so make them const.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230829113920.13713-13-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
Remove the i915 specific i2c-N symlink from HDMI connectors.
This was added to sort of mirror the DP connectors that alreayd
had their aux ch based i2c adapter sitting beneath them in the
sysfs hierarchy. But now that we have the standard "ddc" symlink
approach provided by the core let's switch to that fully.
I don't think anything beyond igt depends on this.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230829113920.13713-12-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
Remove the mostly redundant hdmi->ddc_bus. The only thing that needs
it anymore is get_encoder_by_ddc_bus(), but that can be replaced with
a slight detour through attached_connector+intel_gmbus_get_adapter().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230829113920.13713-11-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
We already populate connector->ddc for HDMI ports, but
so far we've not taken full advantage of it. Do that by
eliminating a bunch of intel_gmbus_get_adapter() lookups.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230829113920.13713-10-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
Populate connector->ddc, and thus create the "ddc" symlink
in sysfs for DP MST connectors.
TODO: test that this actually works
References: https://gitlab.freedesktop.org/drm/intel/-/issues/3605
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230829113920.13713-9-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
Populate connector->ddc, and thus create the "ddc" symlink
in sysfs for analog DP SST connectors.
Let's also reorder intel_dp_aux_init() vs. drm_connector_init_with_ddc()
a bit to make sure the i2c aux ch is at least somewhat populated
before we pass it on, though drm_connector_init_with_ddc() does
not actually do anything with it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230829113920.13713-8-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
Populate connector->ddc, and thus create the "ddc" symlink
in sysfs for DVO connectors.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230829113920.13713-7-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
Populate connector->ddc, and thus create the "ddc" symlink
in sysfs for analog VGA connectors.
As a bonus we can replace a bunch of intel_gmbus_get_adapter()
lookups with just the connector->ddc pointer. Sadly one extra
lookup still remains due to the g4x DVI-I shenanigans. We could
perhaps consider borrowing the ddc proxy idea from SDVO to deal
with that in a perhaps nicer way, but can't really be bothered
right now at least. Also not sure exposing such a dual ddc bus
to userspace would be quite wise.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230829113920.13713-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
Populate connector->ddc, and thus create the "ddc" symlink
in sysfs for the LVDS port.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230829113920.13713-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
Rename the various names we've used for the DDC bus
i2c adapter ("i2c", "adapter", etc.) to just "ddc".
This differentiates it from the various other i2c
busses we might have (DSI panel stuff, DVO control bus, etc.).
v2: Don't add a bogus drm_get_edid() call (Jani)
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/20230831104300.29688-1-ville.syrjala@linux.intel.com
|
|
Currently drm_sysfs_connector_add() attempts to register
the "ddc" symlink (based one connector->ddc) before the
driver's .early_register() hook has been called. That is
too early for i915 which only fully registers the aux ch
and associated i2c bus from said hook (to prevent half
initialized stuff getting exposed to userspace). This
causes my attempt at using drm_connector_init_with_ddc()
to fail, and the entire connector disappears from sysfs
on account of sysfs_create_link() failing.
To fix that split the sysfs symlink stuff into separate
functions (drm_sysfs_connector_add_late() and
drm_sysfs_connector_remove_early()) which are called
on the opposite side of the .later_register() and
.early_unregister() hooks.
Cc: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Emil Velikov <emil.velikov@collabora.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230829113920.13713-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de> #irc
|
|
Use the standard onion peeling approach and call
drm_debugfs_connector_remove() and
drm_sysfs_connector_remove() in the reverse order in
drm_connector_unregister() than what we called their
add counterpartse in drm_connector_register().
The error unwiding in drm_connector_register() is
already doing this the correct way around.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230829113920.13713-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de> #irc
|
|
Sync to v6.6-rc1.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
pic_width when written into the PPS register is divided by the no.
of vdsc instances first but the actual variable that we compare it
to does not change i.e vdsc_cfg->pic_width hence when reading the
register back for pic_width it needs to be multiplied by
num_vdsc_instances rather than being divided.
Fixes: 8b70b5691704 ("drm/i915/vdsc: Fill the intel_dsc_get_pps_config function")
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230911193742.836063-1-suraj.kandpal@intel.com
|
|
Track DP enhanced framing properly in the crtc state instead
of relying just on the cached DPCD everywhere, and hook it
up into the state check and dump.
v2: Actually set enhanced_framing in .compute_config()
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230503113659.16305-1-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
|
|
We always check whether combo PHYs need to be re-initialized
after disabling DC states, which leads to log spam. Switch things
around so that we only log something when we actually have to
re-initialized a PHY.
The log spam was exacerbated by commit 41b4c7fe72b6 ("drm/i915:
Disable DC states for all commits") since we now disable DC
states far more often.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230502143906.2401-12-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
|
|
encoder->get_config() is not the place where the state
should be dumped. Get rid of the spam.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230502143906.2401-10-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Split some overly long lines in hsw_fdi_link_train().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230502143906.2401-8-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Stop dumping state while reading it out. We have a proper
place for that stuff.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230502143906.2401-7-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
|
|
On pre-TGL FEC is a port level feature, not a transcoder
level feature, and it's DDI A which doesn't have it, not
trancoder A. Check for the correct thing when determining
whether FEC is supported or not.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230502143906.2401-5-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
|
|
The MST codepath is missing FEC readout. Add it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230502143906.2401-4-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
|
|
intel_gtt.h is indirectly included absolutely everywhere in the
driver. DBG() is too short a name. Rename it GTT_TRACE() after
GEM_TRACE().
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230911123305.1682554-1-jani.nikula@intel.com
|
|
Use the register helper macros for PPS0 and PPS1 register contents.
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/0dfebe37a391a5ceb8bfae8e16383f1e5aef815d.1693933849.git.jani.nikula@intel.com
|