summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-04-08drm/i915: Disable live M/N updates when using bigjoinerVille Syrjälä
All joined pipes share the same transcoder/timing generator. Currently we just do the commits per-pipe, which doesn't really work if we need to change the timings at the same time. For now just disable live M/N updates when bigjoiner is needed. Cc: stable@vger.kernel.org Tested-by: Vidya Srinivas <vidya.srinivas@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240404213441.17637-5-ville.syrjala@linux.intel.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2024-04-08drm/i915: Disable port sync when bigjoiner is usedVille Syrjälä
The current modeset sequence can't handle port sync and bigjoiner at the same time. Refuse port sync when bigjoiner is needed, at least until we fix the modeset sequence. v2: Add a FIXME (Vandite) Cc: stable@vger.kernel.org Tested-by: Vidya Srinivas <vidya.srinivas@intel.com> Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240404213441.17637-4-ville.syrjala@linux.intel.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2024-04-08drm/i915/psr: Disable PSR when bigjoiner is usedVille Syrjälä
Bigjoiner seem to be causing all kinds of grief to the PSR code currently. I don't believe there is any hardware issue but the code simply not handling this correctly. For now just disable PSR when bigjoiner is needed. Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20240404213441.17637-3-ville.syrjala@linux.intel.com Reviewed-by: Arun R Murthy <arun.r.mruthy@intel.com> Acked-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2024-04-08dt-bindings: display: bridge: it6505: Add #sound-dai-cellsChen-Yu Tsai
The ITE IT6505 display bridge can take one I2S input and transmit it over the DisplayPort link. Add #sound-dai-cells (= 0) to the binding for it. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240327085250.3427496-1-wenst@chromium.org
2024-04-08drm/xe/display: clean up compat i915_vgpu.hJani Nikula
There's a bunch of unnecessary stuff not needed by display code. Remove. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e583679c00aae8fec78f988fa857cfc724a9fa2d.1712345787.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-04-08drm/xe/display: remove compat i915_gem.hJani Nikula
It's only there for GEM_BUG_ON(), but the display code no longer uses it. Good riddance. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/8de7815d9c80125b86e0b85a1af80d4f8686eef6.1712345787.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-04-08drm/xe/display: clean up a lot of cruft from compat i915_drv.hJani Nikula
There's a bunch of unused cruft. Just throw away. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/d773f26cced0b376a30a6cb1e38c9581b469d8cf.1712345787.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-04-08drm/i915: move i915_fixed.h to display/intel_fixed.hJani Nikula
All the users are in display, move the fixed point header under display. We could also consider making these more general purpose things, but that takes a bunch more effort. This allows the immediate cleanup of xe compat i915_fixed.h. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/320c451e116c7807e544a50c67ba79b087a4f218.1712345787.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-04-08drm/i915/dmc: define firmware URL locallyJani Nikula
Avoid the dependency on intel_uc_fw.h, and allow removal of xe compat intel_uc_fw.h. If there needs to be duplication of the URL, at least have the duplication in a sensible way. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/15935837a0c15f861bb2a688cc53514f47153ef3.1712345787.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-04-08drm/i915: use IS_JASPERLAKE()/IS_ELKHARTLAKE() instead of IS_PLATFORM()Jani Nikula
Avoid direct IS_PLATFORM() usage when we have the platform helpers. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/7ca5fabac6a6f5ac8e102b84d1e28502e79296f0.1712345787.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-04-08drm/i915/psr: Panel replay has to be enabled before link trainingJouni Högander
Panel replay has to be enabled on sink side before link training. Take this into account in fastset check and in initial fastset check. 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/20240405113602.992714-9-jouni.hogander@intel.com
2024-04-08drm/i915/psr: Unify panel replay enable/disable sinkJouni Högander
Unify enabling and disabling of psr/panel replay for a sink. Modify intel_psr_enable_sink accordingly and use it for both cases. v3: - move psr2_su_region_et_valid to be check for PSR2 only v2: - enable panel replay for sink before link training - write ALPM_CONFIG only for PSR - add DP_PSR_CRC_VERIFICATION only for PSR - take care of disable sink as well 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/20240405113602.992714-8-jouni.hogander@intel.com
2024-04-08drm/i915/psr: Do not write registers/bits not applicable for panel replayJouni Högander
Bspec is saying this mask register: Only PSR_MASK[Mask FBC modify] and PSR_MASK[Mask Hotplug] are used in panel replay mode. Status register: Only SRD_STATUS[SRD state] field is used in panel replay mode. Due to this stop writing and reading registers and bits not used by panel replay if panel replay is used. Bspec: 53370, 68920 v2: - use intel_dp_is_edp with PSR_MASK register - handle LunarLake as well - hanle ALPM configuration as well 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/20240405113602.992714-7-jouni.hogander@intel.com
2024-04-08drm/i915/psr: Check possible errors for panel replay as wellJouni Högander
On HPD interrupt we want to check if the reason for HPD was some panel replay error detected by monitor/panel. This is already done for PSR. We want to do this for panel replay as well. Modify intel_psr_short_pulse to support panel replay as well. 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/20240405113602.992714-6-jouni.hogander@intel.com
2024-04-08drm/i915/psr: Do not update phy power state in case of non-eDP panel replayJouni Högander
Currently panel replay is supporting only main link on mode -> Do not update phy power state for non-eDP panel replay. Bspec: 53370 v2: use intel_dp_is_edp to differentiate 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/20240405113602.992714-5-jouni.hogander@intel.com
2024-04-08drm/i915/psr: Intel_psr_pause/resume needs to support panel replayJouni Högander
Currently intel_psr_pause and intel_psr_resume do nothing in case of panel replay. Change them to perform pause and return also in case of panel replay. 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/20240405113602.992714-4-jouni.hogander@intel.com
2024-04-08drm/i915/psr: Set intel_crtc_state->has_psr on panel replay as wellJouni Högander
Current code is setting only intel_crtc_state->has_panel_replay in panel replay case. There are lots of stuff behind intel_crtc_state->has_psr that is needed for panel replay as well. Instead of converting each check to has_psr || has_panel_replay set has_psr in case of panel replay as well. Code can then differentiate between psr and panel replay by using intel_crtc_state->has_panel_replay. 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/20240405113602.992714-3-jouni.hogander@intel.com
2024-04-08drm/i915/psr: Add some documentation of variables used in psr codeJouni Högander
We are adding more boolean variable into intel_psr and intel_crtc_state structs. Add some documentation about these for sake of clarity. v2: Modify has_psr + has_panel_replay to mean panel replay 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/20240405113602.992714-2-jouni.hogander@intel.com
2024-04-07drm-panel: If drm_panel_dp_aux_backlight() fails, don't fail panel probeDouglas Anderson
If we're using the AUX channel for eDP backlight and it fails to probe for some reason, let's _not_ fail the panel probe. At least one case where we could fail to init the backlight is because of a dead or physically missing panel. As talked about in detail in the earlier patch in this series, ("drm/panel-edp: If we fail to powerup/get EDID, use conservative timings"), this can cause the entire system's display pipeline to fail to come up and that's non-ideal. If we fail to init the backlight for some transitory reason, we should dig in and see if there's a way to fix this (perhaps retries?). Even in that case, though, having a panel whose backlight is stuck at 100% (the default, at least in the panel Samsung ATNA33XC20 I tested) is better than having no panel at all. Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240325145626.3.I552e8af0ddb1691cc0fe5d27ea3d8020e36f7006@changeid
2024-04-07drm/panel-edp: If we fail to powerup/get EDID, use conservative timingsDouglas Anderson
If at boot we fail to power up the eDP panel (most often happens if the eDP panel never asserts HPD to us) or if we are unable to read the EDID at bootup to figure out the panel's ID then let's use the conservative eDP panel powerup/powerdown timings but _not_ fail the probe. It might seem strange to _not_ fail the probe in this case since we were unable to powerup the panel and confirm it's there. However, there is a reason to do this. Specifically, if we fail to probe the panel then it really throws the whole display pipeline for loop. Most DRM subsystems are written so that they wait until all components (including the panel) have probed before they set everything up. When the panel doesn't come up then this never happens. As a side effect of not setting everything up then other display adapters don't get initialized. As a practical example, I can see that if I open up a sc7180-trogdor based Chromebook that's using the generic "edp-panel" and unplug the eDP panel that it causes the _external_ DP monitor not to function. This is obviously bad because it means that a device with a dead eDP panel becomes e-waste when it could instead still be given useful life with an external display. NOTES: - When we fail to probe like this, boot is a bit slow because we try several times to power the panel up. This doesn't feel horrible because it'll eventually work and the retries are known to help bring some panels up. - In the case where we hit the condition of failing to power up, the display will likely _never_ have a chance to work again until reboot. Once the panel-edp pm_runtime resume function fails it doesn't ever seem to retry. This is probably for the best given that we don't have any real timing/modes. eDP isn't expected to be "hotplugged" so this makes some sense. - It turns out that this makes panel-edp behave more similarly for users of the generic "edp-panel" compatible string and the old fixed panel compatible string. With the old fixed panel compatible string we don't talk to the panel during probe so we'd actually behave much the same way that we'll now behave for the generic "edp-panel". Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240325145626.2.Ia7a55a9657b0b6aa4644fd497a0bc595a771258c@changeid
2024-04-07drm/panel-edp: Abstract out function to set conservative timingsDouglas Anderson
If we're using the generic "edp-panel" compatible string and we fail to detect an eDP panel then we fall back to conservative timings for powering up and powering down the panel. Abstract out the function for setting these timings so it can be used in future patches. No functional change expected--just code movement. Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240325145626.1.I659b2517d9f619d09e804e071591ecab76335dfb@changeid
2024-04-08Merge tag 'drm-misc-next-2024-04-05' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v6.10: Core Changes: - Fix DRM_DISPLAY_DP_HELPER dependencies. Driver Changes: - i2c and polling fixes to ast. - Small fixes to panthor. - Allow IRQ to share GPIO pins in bridge/adv7511. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/2ad89d5a-4096-4cc5-badb-4ad61ff1df7d@linux.intel.com
2024-04-06drm/i915: Fix i915_display_info output when connectors are not activeVille Syrjälä
Currently intel_connector_info(), which prints the per-connector output for i915_display_info, just bails out early if the connector doesn't have a current encoder. That leads to very confusing output where some of your connected (and properly detected) outputs appear to have no enumerated modes. Get rid of the encoder stuff and just rely on the connector itself so that the output is always consistent. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240329012331.29281-1-ville.syrjala@linux.intel.com Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
2024-04-05accel/qaic: Add fifo queued debugfsJeffrey Hugo
When debugging functional issues with workload input processing, it is useful to know if requests are backing up in the fifo, or perhaps getting stuck elsewhere. To answer the question of how many requests are in the fifo, implement a "queued" debugfs entry per-dbc that returns the number of pending requests when read. Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Carl Vanderlip <quic_carlv@quicinc.com> Reviewed-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240322175730.3855440-4-quic_jhugo@quicinc.com
2024-04-05accel/qaic: Add fifo size debugfsJeffrey Hugo
Each DMA Bridge Channel (dbc) has a unique configured fifo size which is specified by the userspace client of that dbc. Since the fifo is circular, it is useful to know the configured size when debugging issues. Add a per-dbc subdirectory in debugfs and in each subdirectory add a fifo_size entry that will display the size of that dbc's fifo when read. Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Carl Vanderlip <quic_carlv@quicinc.com> Reviewed-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240322175730.3855440-3-quic_jhugo@quicinc.com
2024-04-05accel/qaic: Add bootlog debugfsJeffrey Hugo
During the boot process of AIC100, the bootloaders (PBL and SBL) log messages to device RAM. During SBL, if the host opens the QAIC_LOGGING channel, SBL will offload the contents of the log buffer to the host, and stream any new messages that SBL logs. This log of the boot process can be very useful for an initial triage of any boot related issues. For example, if SBL rejects one of the runtime firmware images for a validation failure, SBL will log a reason why. Add the ability of the driver to open the logging channel, receive the messages, and store them. Also define a debugfs entry called "bootlog" by hooking into the DRM debugfs framework. When the bootlog debugfs entry is read, the current contents of the log that the host is caching is displayed to the user. The driver will retain the cache until it detects that the device has rebooted. At that point, the cache will be freed, and the driver will wait for a new log. With this scheme, the driver will only have a cache of the log from the current device boot. Note that if the driver initializes a device and it is already in the runtime state (QSM), no bootlog will be available through this mechanism because the driver and SBL have not communicated. Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Carl Vanderlip <quic_carlv@quicinc.com> Reviewed-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240322175730.3855440-2-quic_jhugo@quicinc.com
2024-04-05drm/bridge: dw-hdmi: Make DRM_DW_HDMI selectableMaxime Ripard
Commit c0e0f139354c ("drm: Make drivers depends on DRM_DW_HDMI") turned select dependencies into depends on ones. However, DRM_DW_HDMI was not manually selectable which resulted in no way to enable the drivers that were now depending on it. Fixes: 4fc8cb47fcfd ("drm/display: Move HDMI helpers into display-helper module") Reported-by: Mark Brown <broonie@kernel.org> Reported-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240403-fix-dw-hdmi-kconfig-v1-2-afbc4a835c38@kernel.org
2024-04-05drm/display: Select DRM_KMS_HELPER for DP helpersMaxime Ripard
The DisplayPort helpers rely on some (__drm_atomic_helper_private_obj_duplicate_state, drm_kms_helper_hotplug_event) helpers found in files compiled by DRM_KMS_HELPER. Prior to commit d674858ff979 ("drm/display: Make all helpers visible and switch to depends on"), DRM_DISPLAY_DP_HELPER was only selectable so it wasn't really a big deal. However, since that commit, it's now something that can be enabled as is, and since there's no expressed dependency with DRM_KMS_HELPER, it can break too. Since DRM_KMS_HELPER is a selectable option for now, let's select it for DRM_DISPLAY_DP_HELPER. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202404021556.0JVcNC13-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202404021700.LbyYZGFd-lkp@intel.com/ Fixes: d674858ff979 ("drm/display: Make all helpers visible and switch to depends on") Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240403-fix-dw-hdmi-kconfig-v1-1-afbc4a835c38@kernel.org
2024-04-05drm/i915/hdcp: Fix get remote hdcp capability functionSuraj Kandpal
HDCP 1.x capability needs to be checked even if setup is not HDCP 2.x capable. --v2 -Assign hdcp_capable and hdcp2_capable to false [Chaitanya] --v3 -Fix variable assignment [Chaitanya] Fixes: 813cca96e4ac ("drm/i915/hdcp: Add new remote capability check shim 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/20240401055652.276785-2-suraj.kandpal@intel.com
2024-04-05drm/i915/display: Initialize capability variablesSuraj Kandpal
Initialize HDCP capability variables to false to avoid UBSAN warning in boolean value as some functions invoking this could return without filling the two capability values. --v2 -Fix Typo [Chaitanya] 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/20240401030106.274787-2-suraj.kandpal@intel.com
2024-04-05Merge tag 'drm-misc-next-2024-03-28' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next Two misc-next in one. drm-misc-next for v6.10-rc1: The deal of a lifetime! You get ALL of the previous drm-misc-next-2024-03-21-1 tag!! But WAIT, there's MORE! Cross-subsystem Changes: - Assorted DT binding updates. Core Changes: - Clarify how optional wait_hpd_asserted is. - Shuffle Kconfig names around. Driver Changes: - Assorted build fixes for panthor, imagination, - Add AUO B120XAN01.0 panels. - Assorted small fixes to panthor, panfrost. drm-misc-next for v6.10: UAPI Changes: - Move some nouveau magic constants to uapi. Cross-subsystem Changes: - Move drm-misc to gitlab and freedesktop hosting. - Add entries for panfrost. Core Changes: - Improve placement for TTM bo's in idle/busy handling. - Improve drm/bridge init ordering. - Add CONFIG_DRM_WERROR, and use W=1 for drm. - Assorted documentation updates. - Make more (drm and driver) headers self-contained and add header guards. - Grab reservation lock in pin/unpin callbacks. - Fix reservation lock handling for vmap. - Add edp and edid panel matching, use it to fix a nearly identical panel. Driver Changes: - Add drm/panthor driver and assorted fixes. - Assorted small fixes to xlnx, panel-edp, tidss, ci, nouveau, panel and bridge drivers. - Add Samsung s6e3fa7, BOE NT116WHM-N44, CMN N116BCA-EA1, CrystalClear CMT430B19N00, Startek KD050HDFIA020-C020A, powertip PH128800T006-ZHC01 panels. - Fix console for omapdrm. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/bea310a6-6ff6-477e-9363-f9f053cfd12a@linux.intel.com
2024-04-04drm: fix DRM_DISPLAY_DP_HELPER dependenciesArnd Bergmann
Both the exynos and rockchip drivers ran into link failures after a Kconfig cleanup: aarch64-linux-ld: drivers/gpu/drm/exynos/exynos_dp.o: in function `exynos_dp_resume': exynos_dp.c:(.text+0xc0): undefined reference to `analogix_dp_resume' aarch64-linux-ld: drivers/gpu/drm/exynos/exynos_dp.o: in function `exynos_dp_suspend': exynos_dp.c:(.text+0xf4): undefined reference to `analogix_dp_suspend' x86_64-linux-ld: drivers/gpu/drm/rockchip/cdn-dp-core.o: in function `cdn_dp_connector_mode_valid': cdn-dp-core.c:(.text+0x13a): undefined reference to `drm_dp_bw_code_to_link_rate' x86_64-linux-ld: cdn-dp-core.c:(.text+0x148): undefined reference to `drm_dp_bw_code_to_link_rate' x86_64-linux-ld: drivers/gpu/drm/rockchip/cdn-dp-core.o: in function `cdn_dp_check_link_status': cdn-dp-core.c:(.text+0x1396): undefined reference to `drm_dp_channel_eq_ok' In both cases, the problem is that ROCKCHIP_CDN_DP and DRM_EXYNOS_DP are 'bool' symbols that depend on the the 'tristate' DRM_DISPLAY_HELPER symbol, but end up not working when the SoC specific part is built-in but the helper is in a loadable module. Use the same trick that DRM_ROCKCHIP already uses for the EXTCON dependency and disallow DP support when it would not work. Fixes: 0323287de87d ("drm: Switch DRM_DISPLAY_DP_HELPER to depends on") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240404124101.2988099-1-arnd@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-04-04drm/i915: Optimize out redundant dbuf slice updatesVille Syrjälä
if the new dbuf slices are a superset of the old dbuf slices then we don't have to do anything in intel_dbuf_post_plane_update(). Restructure the code to skip such redundant dbuf slice updates. The main benefit is slightly less confusing logs. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240402155016.13733-15-ville.syrjala@linux.intel.com
2024-04-04drm/i915: Use a plain old int for the cdclk/mdclk ratioVille Syrjälä
No point in throwing around u8 when we're dealing with just an integer. Use a plain old boring 'int'. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240402155016.13733-14-ville.syrjala@linux.intel.com
2024-04-04drm/i915: Implement vblank synchronized MBUS join changesStanislav Lisovskiy
Currently we can't change MBUS join status without doing a modeset, because we are lacking mechanism to synchronize those with vblank. However then this means that we can't do a fastset, if there is a need to change MBUS join state. Fix that by implementing such change. We already call correspondent check and update at pre_plane dbuf update, so the only thing left is to have a non-modeset version of that. If active pipes stay the same then fastset is possible and only MBUS join state/ddb allocation updates would be committed. The full mbus/cdclk sequence will look as follows: 1. disable pipes 2. increase cdclk if necessary 2.1 reprogram cdclk 2.2 update dbuf tracker value 3. enable mbus joining if necessary 3.1 update mbus_ctl 3.2 update dbuf tracker value 4. reallocate dbuf for planes on active pipes 5. disable mbus joining if necessary 5.1 update dbuf tracker value 5.2 update mbus_ctl 6. enable pipes 7. decrease cdclk if necessary 7.1 update dbuf tracker value 7.2 reprogram cdclk And in order to keep things in sync we need: Step 2: - mbus_join == old - mdclk/cdclk ratio == new Step 3: - mbus_join == new - mdclk/cdclk ratio == old when cdclk is changing in step 7 - mdclk/cdclk ratio == new when cdclk is changing in step 2 Step 5: - mbus_join == new - mdclk/cdclk ratio == old when cdclk is changing in step 7 - mdclk/cdclk ratio == new when cdclk is changing in step 2 Step 7: - mbus_join == new - mdclk/cdclk ratio == new v2: - Removed redundant parentheses(Ville Syrjälä) - Constified new_crtc_state in intel_mbus_joined_pipe(Ville Syrjälä) - Removed pipe_select variable(Ville Syrjälä) [v3: vsyrjala: Correctly sequence vs. cdclk updates, properly describe the full sequence, shuffle code around to make the diff more legible, streamline a few things] [v4: vsyrjala: Move the intel_cdclk_is_decreasing_later() stuff to a separate patch] Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> #v3 Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Co-developed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240402155016.13733-13-ville.syrjala@linux.intel.com
2024-04-04drm/i915: Use the correct mdclk/cdclk ratio in MBUS updatesVille Syrjälä
The current cdclk/mbus programming sequence is as follows: 1. intel_set_cdclk_pre_plane_update() 2. update_mbus_pre_enable() 3. intel_set_cdclk_post_plane_update() when the actual mdclk/cdclk programming is postponed to intel_set_cdclk_post_plane_update() we must keep using the old mdclk/cdclk ratio during update_mbus_pre_enable(). This guarantees the programmed ratio matches the rest of the hardware state (mdlk/cdclk/mbus joining). v2: Extracted from the vblank synchronized mbus programming patch Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> #v1 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240402155016.13733-12-ville.syrjala@linux.intel.com
2024-04-04drm/i915: Use old mbus_join value when increasing CDCLKStanislav Lisovskiy
In order to make sure we are not breaking the proper sequence let's do updates step by step and don't change MBUS join value during MDCLK/CDCLK programming stage. MBUS join programming would be taken care by pre/post ddb hooks. v2: - Reworded comment about using old mbus_join value in intel_set_cdclk(Ville Syrjälä) Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> [v3: vsyrjala: rebase on top of cdclk changes, reword a bit more] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240402155016.13733-11-ville.syrjala@linux.intel.com
2024-04-04drm/i915: Add debugs for mbus joining and dbuf ratio programmingVille Syrjälä
Add some debugs so that we can actually observe what is actually happening during the mbus/dbuf programming steps. We can just shove them into fairly low level functions as none of them are called during any critical sections/etc. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240402155016.13733-10-ville.syrjala@linux.intel.com
2024-04-04drm/i915: Extract intel_dbuf_mdclk_min_tracker_update()Ville Syrjälä
Extract the stuff that writes the dbuf/mbus ratio stuff into its own function. Will help with correctly sequencing the operations done during mbus programming. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240402155016.13733-9-ville.syrjala@linux.intel.com
2024-04-04drm/i915: Extract intel_dbuf_mbus_join_update()Ville Syrjälä
Extact the stuff that writes the joining bits in MBUS_CTL into its own function. Will help with correctly sequencing the operations done during mbus programming. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240402155016.13733-8-ville.syrjala@linux.intel.com
2024-04-04drm/i915: Relocate intel_mbus_dbox_update()Ville Syrjälä
intel_mbus_dbox_update() will become static soon. Relocate it into a place that avoids having to add a forward declaration for it. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240402155016.13733-7-ville.syrjala@linux.intel.com
2024-04-04drm/i915: Loop over all active pipes in intel_mbus_dbox_updateStanislav Lisovskiy
We need to loop through all active pipes, not just the ones, that are in current state, because disabling and enabling even a particular pipe affects credits in another one. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240402155016.13733-6-ville.syrjala@linux.intel.com
2024-04-04drm/i915/cdclk: Indicate whether CDCLK change happens during pre or post ↵Ville Syrjälä
plane update Currently we just get a plain "Changing CDCLK to ..." in the logs. It would actually be interesting to see whether we're doing the programming during the pre or post plane phase of the commit. Include that information in the debug message. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240402155016.13733-5-ville.syrjala@linux.intel.com
2024-04-04drm/i915/cdclk: Drop tgl/dg2 cdclk bump hacksVille Syrjälä
No one ever figured out why bumping the cdclk helped with whatever issue we were having at the time. Remove the hacks and start from scratch so that we can actually see if any problems still remain. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240402155016.13733-4-ville.syrjala@linux.intel.com
2024-04-04drm/i915/cdclk: Fix voltage_level programming edge caseVille Syrjälä
Currently we only consider the relationship of the old and new CDCLK frequencies when determining whether to do the repgramming from intel_set_cdclk_pre_plane_update() or intel_set_cdclk_post_plane_update(). It is technically possible to have a situation where the CDCLK frequency is decreasing, but the voltage_level is increasing due a DDI port. In this case we should bump the voltage level already in intel_set_cdclk_pre_plane_update() (so that the voltage_level will have been increased by the time the port gets enabled), while leaving the CDCLK frequency unchanged (as active planes/etc. may still depend on it). We can then reduce the CDCLK frequency to its final value from intel_set_cdclk_post_plane_update(). In order to handle that correctly we shall construct a suitable amalgam of the old and new cdclk states in intel_set_cdclk_pre_plane_update(). And we can simply call intel_set_cdclk() unconditionally in both places as it will not do anything if nothing actually changes vs. the current hw state. v2: Handle cdclk_state->disable_pipes v3: Only synchronize the cd2x update against the pipe's vblank when the cdclk frequency is changing during the current commit phase (Gustavo) Cc: stable@vger.kernel.org Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240402155016.13733-3-ville.syrjala@linux.intel.com
2024-04-04drm/i915/cdclk: Fix CDCLK programming order when pipes are activeVille Syrjälä
Currently we always reprogram CDCLK from the intel_set_cdclk_pre_plane_update() when using squash/crawl. The code only works correctly for the cd2x update or full modeset cases, and it was simply never updated to deal with squash/crawl. If the CDCLK frequency is increasing we must reprogram it before we do anything else that might depend on the new higher frequency, and conversely we must not decrease the frequency until everything that might still depend on the old higher frequency has been dealt with. Since cdclk_state->pipe is only relevant when doing a cd2x update we can't use it to determine the correct sequence during squash/crawl. To that end introduce cdclk_state->disable_pipes which simply indicates that we must perform the update while the pipes are disable (ie. during intel_set_cdclk_pre_plane_update()). Otherwise we use the same old vs. new CDCLK frequency comparsiong as for cd2x updates. The only remaining problem case is when the voltage_level needs to increase due to a DDI port, but the CDCLK frequency is decreasing (and not all pipes are being disabled). The current approach will not bump the voltage level up until after the port has already been enabled, which is too late. But we'll take care of that case separately. v2: Don't break the "must disable pipes case" v3: Keep the on stack 'pipe' for future use Cc: stable@vger.kernel.org Fixes: d62686ba3b54 ("drm/i915/adl_p: CDCLK crawl support for ADL") Reviewed-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240402155016.13733-2-ville.syrjala@linux.intel.com
2024-04-04drm/bridge: adv7511: Allow IRQ to share GPIO pinsAdam Ford
The IRQ registration currently assumes that the GPIO is dedicated to it, but that may not necessarily be the case. If the board has another device sharing the GPIO, it won't be registered and the hot-plug detect fails to function. Currently, the handler reads two registers and blindly assumes one of them caused the interrupt and returns IRQ_HANDLED unless there is an error. In order to properly do this, the IRQ handler needs to check if it needs to handle the IRQ and return IRQ_NONE if there is nothing to handle. With the check added and the return code properly indicating whether or not it there was an IRQ, the IRQF_SHARED can be set to share a GPIO IRQ. V2: Add check to see if there is IRQ data to handle Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240305004859.201085-1-aford173@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-04-04drm/i915/display: Read/Write Adaptive Sync SDPMitul Golani
Add read/write calls for Adaptive Sync SDP. 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-10-mitulkumar.ajitkumar.golani@intel.com
2024-04-04drm/i915/display: Compute vrr_vsync paramsMitul Golani
Compute vrr_vsync_start/end, which sets the position for hardware to send the Vsync at a fixed position relative to the end of the Vblank. --v2: - Updated VSYNC_START/END macros to VRR_VSYNC_START/END. (Ankit) - Updated bit fields of VRR_VSYNC_START/END. (Ankit) --v3: - Add PIPE_CONF_CHECK_I(vrr.vsync_start/end). - Read/write vrr_vsync params only when we intend to send adaptive_sync sdp. --v4: - Use VRR_SYNC_START/END macros correctly. --v5: - Send AS SDP only when VRR is enabled. --v6: - Add TRANS_VRR_VSYNC before enabling VRR as per bspec. (Ankit) Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@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-9-mitulkumar.ajitkumar.golani@intel.com
2024-04-04drm/i915/display: Add state checker for Adaptive Sync SDPMitul Golani
Enable infoframe and add state checker for Adaptive Sync SDP enablement. --v1: - crtc_state->infoframes.enable, to add on correct place holder. 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-8-mitulkumar.ajitkumar.golani@intel.com
generated by cgit (git 2.34.1) at 2025-09-11 22:59:49 +0000