summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/display
AgeCommit message (Collapse)AuthorFilesLines
2024-10-01Merge tag 'drm-misc-fixes-2024-09-26' of ↵Dave Airlie2-5/+9
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Short summary of fixes pull: atomic: - Use correct type when reading damage rectangles display: - Fix kernel docs dp-mst: - Fix DSC decompression detection hdmi: - Fix infoframe size panthor: - Fix locking sched: - Update maintainers - Fix race condition whne queueing up jobs sysfb: - Disable sysfb if framebuffer parent device is unknown vbox: - Fix VLA handling Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240926121045.GA561653@localhost.localdomain
2024-09-24drm/connector: hdmi: Fix writing Dynamic Range Mastering infoframesDerek Foreman1-3/+1
The largest infoframe we create is the DRM (Dynamic Range Mastering) infoframe which is 26 bytes + a 4 byte header, for a total of 30 bytes. With HDMI_MAX_INFOFRAME_SIZE set to 29 bytes, as it is now, we allocate too little space to pack a DRM infoframe in write_device_infoframe(), leading to an ENOSPC return from hdmi_infoframe_pack(), and never calling the connector's write_infoframe() vfunc. Instead of having HDMI_MAX_INFOFRAME_SIZE defined in two places, replace HDMI_MAX_INFOFRAME_SIZE with HDMI_INFOFRAME_SIZE(MAX) and make MAX 27 bytes - which is defined by the HDMI specification to be the largest infoframe payload. Fixes: f378b77227bc ("drm/connector: hdmi: Add Infoframes generation") Fixes: c602e4959a0c ("drm/connector: hdmi: Create Infoframe DebugFS entries") Signed-off-by: Derek Foreman <derek.foreman@collabora.com> Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240827163918.48160-1-derek.foreman@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-09-12drm/dp_mst: Fix DSC decompression detection in Synaptics branch devicesImre Deak1-2/+8
Atm it's assumed that all Synaptics MST branch devices support DSC, which is not exposed via a DP-to-DP peer device, rather a control flag in the branch device's UFP DPCD applying to all the streams going through it. This isn't true for all adapters with this branch device though (for instance the Cakitte USBC->2xHDMI adapter reported in the Closes link below doesn't support DSC). Fix the above by advertising the DSC decompression support only if the capability flag for this in the UFP DPCD is actually set. Cc: Lyude Paul <lyude@redhat.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12047 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240909144650.2931258-1-imre.deak@intel.com
2024-09-11Merge v6.11-rc7 into drm-nextSimona Vetter3-10/+505
Thomas needs 5a498d4d06d6 ("drm/fbdev-dma: Only install deferred I/O if necessary") in drm-misc, so start the backmerge cascade. Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch>
2024-09-03drm/bridge-connector: reset the HDMI connector stateDmitry Baryshkov2-1/+13
On HDMI connectors which use drm_bridge_connector and DRM_BRIDGE_OP_HDMI IGT chokes on the max_bpc property in several kms_properties tests due to the drm_bridge_connector failing to reset HDMI-related properties. Call __drm_atomic_helper_connector_hdmi_reset() if the drm_bridge_connector has bridge_hdmi. It is impossible to call this function from HDMI bridges, none of the bridge callbacks correspond to the drm_connector_funcs::reset(). Fixes: 6b4468b0c6ba ("drm/bridge-connector: implement glue code for HDMI connector") Reviewed-by: Maxime Ripard <mripard@kernel.org> Acked-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240903-drm-bridge-connector-fix-hdmi-reset-v5-3-daebde6d9857@linaro.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-09-03drm/bridge-connector: move to DRM_DISPLAY_HELPER moduleDmitry Baryshkov3-0/+485
drm_bridge_connector is a "leaf" driver, belonging to the display helper, rather than the "CRTC" drm_kms_helper module. Move the driver to the drm/display and add necessary Kconfig selection clauses. Suggested-by: Maxime Ripard <mripard@kernel.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240903-drm-bridge-connector-fix-hdmi-reset-v5-2-daebde6d9857@linaro.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-09-03drm/display: stop depending on DRM_DISPLAY_HELPERDmitry Baryshkov1-10/+8
Kconfig symbols should not declare dependency on DRM_DISPLAY_HELPER. Move all parts of DRM_DISPLAY_HELPER to an if DRM_DISPLAY_HELPER block. It is not possible to make those symbols select DRM_DISPLAY_HELPER because of the link issues when a part of the helper is selected to be built-in, while other part is selected to be as module. In such a case the modular part doesn't get built at all, leading to undefined symbols. The only viable alternative is to split drm_display_helper.ko into several small modules, each of them having their own dependencies. Suggested-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240903-drm-bridge-connector-fix-hdmi-reset-v5-1-daebde6d9857@linaro.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-08-30Merge tag 'drm-misc-next-2024-08-29' of ↵Dave Airlie1-37/+34
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v6.12: UAPI Changes: devfs: - support device numbers up to MINORBITS limit Core Changes: ci: - increase job timeout devfs: - use XArray for minor ids displayport: - mst: GUID improvements docs: - add fixes and cleanups panic: - optionally display QR code Driver Changes: amdgpu: - faster vblank disabling - GUID improvements gm12u320 - convert to struct drm_edid host1x: - fix syncpoint IRQ during resume - use iommu_paging_domain_alloc() imx: - ipuv3: convert to struct drm_edid omapdrm: - improve error handling panel: - add support for BOE TV101WUM-LL2 plus DT bindings - novatek-nt35950: improve error handling - nv3051d: improve error handling - panel-edp: add support for BOE NE140WUM-N6G; revert support for SDC ATNA45AF01 - visionox-vtdr6130: improve error handling; use devm_regulator_bulk_get_const() renesas: - rz-du: add support for RZ/G2UL plus DT bindings sti: - convert to struct drm_edid tegra: - gr3d: improve PM domain handling - convert to struct drm_edid Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240829144654.GA145538@linux.fritz.box
2024-08-29drm/mst: switch to guid_gen() to generate valid GUIDsJani Nikula1-9/+1
Instead of just smashing jiffies into a GUID, use guid_gen() to generate RFC 4122 compliant GUIDs. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240812122312.1567046-2-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-08-29drm/mst: switch to guid_t type for GUIDJani Nikula1-29/+38
The kernel has a guid_t type for GUIDs. Switch to using it, but avoid any functional changes here. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240812122312.1567046-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-08-26drm: Fix kerneldoc for "Returns" sectionrenjun wang1-4/+0
The blank line between title "Returns:" and detail description is not allowed, otherwise the title will goes under the description block in generated .html file after running `make htmldocs`. There are a few examples for current kerneldoc at [1][2][3]. v2: - use Link tag with stable URLs Signed-off-by: renjun wang <renjunw0@foxmail.com> Link: https://www.kernel.org/doc/html/v6.10/gpu/drm-kms.html#c.drm_crtc_commit_wait # 1 Link: https://www.kernel.org/doc/html/v6.10/gpu/drm-kms.html#c.drm_atomic_get_crtc_state # 2 Link: https://www.kernel.org/doc/html/v6.10/gpu/i915.html#c.i915_vma_pin_fence # 3 Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/tencent_37A873672B5CD20DECAF99DEDAC5E45C3106@qq.com
2024-08-16Merge tag 'drm-intel-next-2024-08-13' of ↵Dave Airlie1-13/+42
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next - Type-C programming fix for MTL+ (Gustavo) - Fix display clock workaround (Mitul) - Fix DP LTTPR detection (Imre) - Calculate vblank delay more accurately (Ville) - Make vrr_{enabling,disabling}() usable outside intel_display.c (Ville) - FBC clean-up (Ville) - DP link-training fixes and clean-up (Imre) - Make I2C terminology more inclusive (Easwar) - Make read-only array bw_gbps static const (Colin) - HDCP fixes and improvements (Suraj) - DP VSC SDP fixes and clean-ups (Suraj, Mitul) - Fix opregion leak in Xe code (Lucas) - Fix possible int overflow in skl_ddi_calculate_wrpll (Nikita)] - General display clean-ups and conversion towards intel_display (Jani) - On DP MST, Enable LT fallback for UHBR<->non-UHBR rates (Imre) - Add VRR condition for DPKGC Enablement (Suraj) - Use backlight power constants (Zimmermann) - Correct dual pps handling for MTL_PCH+ (Dnyaneshwar) - Dump DSC HW state (Imre) - Replace double blank with single blank after comma (Andi) - Read display register timeout on BMG (Mitul) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ZruWsyTv3nzdArDk@intel.com
2024-08-08Merge tag 'drm-misc-next-2024-08-01' of ↵Daniel Vetter2-11/+57
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v6.12: UAPI Changes: virtio: - Define DRM capset Cross-subsystem Changes: dma-buf: - heaps: Clean up documentation printk: - Pass description to kmsg_dump() Core Changes: CI: - Update IGT tests - Point upstream repo to GitLab instance modesetting: - Introduce Power Saving Policy property for connectors - Add might_fault() to drm_modeset_lock priming - Add dynamic per-crtc vblank configuration support panic: - Avoid build-time interference with framebuffer console docs: - Document Colorspace property scheduler: - Remove full_recover from drm_sched_start TTM: - Make LRU walk restartable after dropping locks - Allow direct reclaim to allocate local memory Driver Changes: amdgpu: - Support Power Saving Policy connector property ast: - astdp: Support AST2600 with VGA; Clean up HPD bridge: - Silence error message on -EPROBE_DEFER - analogix: Clean aup - bridge-connector: Fix double free - lt6505: Disable interrupt when powered off - tc358767: Make default DP port preemphasis configurable gma500: - Update i2c terminology ivpu: - Add MODULE_FIRMWARE() lcdif: - Fix pixel clock loongson: - Use GEM refcount over TTM's mgag200: - Improve BMC handling - Support VBLANK intterupts nouveau: - Refactor and clean up internals - Use GEM refcount over TTM's panel: - Shutdown fixes plus documentation - Refactor several drivers for better code sharing - boe-th101mb31ig002: Support for starry-er88577 MIPI-DSI panel plus DT; Fix porch parameter - edp: Support AOU B116XTN02.3, AUO B116XAN06.1, AOU B116XAT04.1, BOE NV140WUM-N41, BOE NV133WUM-N63, BOE NV116WHM-A4D, CMN N116BCA-EA2, CMN N116BCP-EA2, CSW MNB601LS1-4 - himax-hx8394: Support Microchip AC40T08A MIPI Display panel plus DT - ilitek-ili9806e: Support Densitron DMT028VGHMCMI-1D TFT plus DT - jd9365da: Support Melfas lmfbx101117480 MIPI-DSI panel plus DT; Refactor for code sharing sti: - Fix module owner stm: - Avoid UAF wih managed plane and CRTC helpers - Fix module owner - Fix error handling in probe - Depend on COMMON_CLK - ltdc: Fix transparency after disabling plane; Remove unused interrupt tegra: - Call drm_atomic_helper_shutdown() v3d: - Clean up perfmon vkms: - Clean up Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240801121406.GA102996@linux.fritz.box
2024-08-01Merge drm/drm-next into drm-intel-nextJani Nikula8-5/+930
Sync with v6.11-rc1 in general, and specifically get the new BACKLIGHT_POWER_ constants for power states. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-07-31drm/dp_mst: Simplify the condition when to enumerate path resourcesImre Deak1-11/+8
In the if (old_ddps != port->ddps || !created) if (port->ddps && !port->input) ret = drm_dp_send_enum_path_resources(); sequence the first if's condition is true if the port exists already (!created) or the port was created anew (hence old_ddps==0) and it was in the plugged state (port->ddps==1). The second if's condition is true for output ports in the plugged state. So the function is called for an output port in the plugged state, regardless if it already existed or not and regardless of the old plugged state. In all other cases port->full_pbn can be zeroed as the port is either an input for which full_pbn is never set, or an output in the unplugged state for which full_pbn was already zeroed previously or the port was just created (with port->full_pbn==0). Simplify the condition, making it clear that the path resources are always enumerated for an output port in the plugged state. Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240722165503.2084999-4-imre.deak@intel.com
2024-07-31drm/dp_mst: Add a helper to queue a topology probeImre Deak1-0/+27
A follow up i915 patch will need to reprobe the MST topology after the initial probing, add a helper for this. Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240722165503.2084999-3-imre.deak@intel.com
2024-07-31drm/dp_mst: Factor out function to queue a topology probe workImre Deak1-2/+7
Factor out a function to queue a work for probing the topology, also used by the next patch. Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240722165503.2084999-2-imre.deak@intel.com
2024-07-25Merge tag 'driver-core-6.11-rc1' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core updates from Greg KH: "Here is the big set of driver core changes for 6.11-rc1. Lots of stuff in here, with not a huge diffstat, but apis are evolving which required lots of files to be touched. Highlights of the changes in here are: - platform remove callback api final fixups (Uwe took many releases to get here, finally!) - Rust bindings for basic firmware apis and initial driver-core interactions. It's not all that useful for a "write a whole driver in rust" type of thing, but the firmware bindings do help out the phy rust drivers, and the driver core bindings give a solid base on which others can start their work. There is still a long way to go here before we have a multitude of rust drivers being added, but it's a great first step. - driver core const api changes. This reached across all bus types, and there are some fix-ups for some not-common bus types that linux-next and 0-day testing shook out. This work is being done to help make the rust bindings more safe, as well as the C code, moving toward the end-goal of allowing us to put driver structures into read-only memory. We aren't there yet, but are getting closer. - minor devres cleanups and fixes found by code inspection - arch_topology minor changes - other minor driver core cleanups All of these have been in linux-next for a very long time with no reported problems" * tag 'driver-core-6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (55 commits) ARM: sa1100: make match function take a const pointer sysfs/cpu: Make crash_hotplug attribute world-readable dio: Have dio_bus_match() callback take a const * zorro: make match function take a const pointer driver core: module: make module_[add|remove]_driver take a const * driver core: make driver_find_device() take a const * driver core: make driver_[create|remove]_file take a const * firmware_loader: fix soundness issue in `request_internal` firmware_loader: annotate doctests as `no_run` devres: Correct code style for functions that return a pointer type devres: Initialize an uninitialized struct member devres: Fix memory leakage caused by driver API devm_free_percpu() devres: Fix devm_krealloc() wasting memory driver core: platform: Switch to use kmemdup_array() driver core: have match() callback in struct bus_type take a const * MAINTAINERS: add Rust device abstractions to DRIVER CORE device: rust: improve safety comments MAINTAINERS: add Danilo as FIRMWARE LOADER maintainer MAINTAINERS: add Rust FW abstractions to FIRMWARE LOADER firmware: rust: improve safety comments ...
2024-07-23drm/dp_mst: Simplify character output in drm_dp_mst_dump_topology()Markus Elfring1-1/+1
Single characters should be put into a sequence. Thus use the corresponding function “seq_putc” for one selected call. This issue was transformed by using the Coccinelle software. Suggested-by: Christophe Jaillet <christophe.jaillet@wanadoo.fr> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/af602b2e-4d92-4c54-9884-7db84700aa93@web.de
2024-07-11drm/dp: Add helper to dump an LTTPR PHY descriptorImre Deak1-10/+56
Add a helper to dump the DPCD descriptor for an LTTPR PHY. This is based on [1] and [2] moving the helper to DRM core as suggested by Ville. [1] https://lore.kernel.org/all/20240703155937.1674856-5-imre.deak@intel.com [2] https://lore.kernel.org/all/20240703155937.1674856-6-imre.deak@intel.com Cc: dri-devel@lists.freedesktop.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240708190029.271247-6-imre.deak@intel.com
2024-07-03drm/display/dsc: Add a helper to dump the DSC configurationImre Deak1-0/+91
Add a helper to dump the Display Stream Compression configuration, taken into use in the i915 driver by a later patch. v2: - Rebase on the s/DRM_X16/FXP_Q4 change. - s/DSC configration/DSC configuration in the function documentation. Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240628164451.1177612-3-imre.deak@intel.com
2024-07-03drm: Add helpers for q4 fixed point valuesImre Deak1-2/+3
Add helpers to convert between q4 fixed point and integer/fraction values. Also add the format/argument macros required to printk q4 fixed point variables. The q4 notation is based on the short variant described by https://en.wikipedia.org/wiki/Q_(number_format) where only the number of fraction bits in the fixed point value are defined, while the full size is deducted from the container type, that is the size of int for these helpers. Using the fxp_ prefix, which makes moving these helpers outside of drm to a more generic place easier, if they prove to be useful. These are needed by later patches dumping the Display Stream Compression configuration in DRM core and in the i915 driver to replace the corresponding bpp_x16 helpers defined locally in the driver. v2: Use the more generic/descriptive fxp_q4 prefix instead of drm_x16. (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240628164451.1177612-2-imre.deak@intel.com
2024-07-03drm/dp_mst: Skip CSN if topology probing is not done yetWayne Lin1-0/+11
[Why] During resume, observe that we receive CSN event before we start topology probing. Handling CSN at this moment based on uncertain topology is unnecessary. [How] Add checking condition in drm_dp_mst_handle_up_req() to skip handling CSN if the topology is yet to be probed. Cc: Lyude Paul <lyude@redhat.com> Cc: Harry Wentland <hwentlan@amd.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240626084825.878565-3-Wayne.Lin@amd.com
2024-07-03drm/dp_mst: Fix all mstb marked as not probed after suspend/resumeWayne Lin1-2/+2
[Why] After supend/resume, with topology unchanged, observe that link_address_sent of all mstb are marked as false even the topology probing is done without any error. It is caused by wrongly also include "ret == 0" case as a probing failure case. [How] Remove inappropriate checking conditions. Cc: Lyude Paul <lyude@redhat.com> Cc: Harry Wentland <hwentlan@amd.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: stable@vger.kernel.org Fixes: 37dfdc55ffeb ("drm/dp_mst: Cleanup drm_dp_send_link_address() a bit") Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240626084825.878565-2-Wayne.Lin@amd.com
2024-07-03driver core: have match() callback in struct bus_type take a const *Greg Kroah-Hartman1-1/+1
In the match() callback, the struct device_driver * should not be changed, so change the function callback to be a const *. This is one step of many towards making the driver core safe to have struct device_driver in read-only memory. Because the match() callback is in all busses, all busses are modified to handle this properly. This does entail switching some container_of() calls to container_of_const() to properly handle the constant *. For some busses, like PCI and USB and HV, the const * is cast away in the match callback as those busses do want to modify those structures at this point in time (they have a local lock in the driver structure.) That will have to be changed in the future if they wish to have their struct device * in read-only-memory. Cc: Rafael J. Wysocki <rafael@kernel.org> Reviewed-by: Alex Elder <elder@kernel.org> Acked-by: Sumit Garg <sumit.garg@linaro.org> Link: https://lore.kernel.org/r/2024070136-wrongdoer-busily-01e8@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-06-25drm/connector: hdmi: shorten too long function nameDmitry Baryshkov1-3/+3
If CONFIG_MODVERSIONS is enabled, then using the HDMI Connector framework can result in build failures. Rename the function to make it fit into the name requirements. ERROR: modpost: too long symbol "drm_atomic_helper_connector_hdmi_disable_audio_infoframe" [drivers/gpu/drm/msm/msm.ko] Reported-by: Mark Brown <broonie@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240624-hdmi-connector-shorten-name-v1-1-5bd3410138db@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-06-12drm/connector: hdmi: allow disabling Audio InfoframeDmitry Baryshkov1-0/+36
Add drm_atomic_helper_connector_hdmi_disable_audio_infoframe(), an API to allow the driver disable sending the Audio Infoframe. This is to be used by the drivers if setup of the infoframes is not tightly coupled with the audio functionality and just disabling the audio playback doesn't stop the HDMI hardware from sending the Infoframe. Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240607-bridge-hdmi-connector-v5-1-ab384e6021af@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-05-29drm/display: Fix HDMI state helper dependencyMaxime Ripard1-1/+1
During the life of the series that introduced the DRM_DISPLAY_HDMI_STATE_HELPER option, we reworked the Kconfig option dependency setup to rely on depends on with commit f6d2dc03fa85 ("drm: Switch DRM_DISPLAY_HDMI_HELPER to depends on") which got reverted later on because it was creating too many issues by commit d7c128cb775e ("Revert "drm: Switch DRM_DISPLAY_HDMI_HELPER to depends on""). However, since the series was out of tree at that time, DRM_DISPLAY_HDMI_STATE_HELPER wasn't properly updated to take the revert into account and is now creating build issues. Let's switch the depends on to a select to fix this. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202405290332.Sqtt0ix0-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202405290438.TOYhXMIn-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202405290803.c3178DYT-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202405291109.PQdqc46g-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202405291221.a0NStxHE-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202405291636.8GgBtK8u-lkp@intel.com/ Fixes: 54cb39e2293b ("drm/connector: hdmi: Create an HDMI sub-state") Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240529080013.2325748-1-mripard@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-05-28drm/connector: hdmi: Add Infoframes generationMaxime Ripard1-0/+336
Infoframes in KMS is usually handled by a bunch of low-level helpers that require quite some boilerplate for drivers. This leads to discrepancies with how drivers generate them, and which are actually sent. Now that we have everything needed to generate them in the HDMI connector state, we can generate them in our common logic so that drivers can simply reuse what we precomputed. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-22-c5af16c3aae2@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-05-28drm/connector: hdmi: Add RGB Quantization Range to the connector stateMaxime Ripard1-0/+29
HDMI controller drivers will need to figure out the RGB range they need to configure based on a mode and property values. Let's expose that in the HDMI connector state so drivers can just use that value. Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-20-c5af16c3aae2@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-05-28drm/connector: hdmi: Add Broadcast RGB propertyMaxime Ripard1-1/+3
The i915 driver has a property to force the RGB range of an HDMI output. The vc4 driver then implemented the same property with the same semantics. KWin has support for it, and a PR for mutter is also there to support it. Both drivers implementing the same property with the same semantics, plus the userspace having support for it, is proof enough that it's pretty much a de-facto standard now and we can provide helpers for it. Let's plumb it into the newly created HDMI connector. Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Sebastian Wick <sebastian.wick@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-18-c5af16c3aae2@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-05-28drm/connector: hdmi: Compute bpc and format automaticallyMaxime Ripard1-3/+214
Now that we have all the infrastructure needed, we can add some code that will, for a given connector state and mode, compute the best output format and bpc. The algorithm is equivalent to the one already found in i915 and vc4. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-15-c5af16c3aae2@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-05-28drm/connector: hdmi: Add custom hook to filter TMDS character rateMaxime Ripard1-0/+9
Most of the HDMI controllers have an upper TMDS character rate limit they can't exceed. On "embedded"-grade display controllers, it will typically be lower than what high-grade monitors can provide these days, so drivers will filter the TMDS character rate based on the controller capabilities. To make that easier to handle for drivers, let's provide an optional hook to be implemented by drivers so they can tell the HDMI controller helpers if a given TMDS character rate is reachable for them or not. This will then be useful to figure out the best format and bpc count for a given mode. Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-13-c5af16c3aae2@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-05-28drm/connector: hdmi: Calculate TMDS character rateMaxime Ripard1-0/+67
Most HDMI drivers have some code to calculate the TMDS character rate, usually to adjust an internal clock to match what the mode requires. Since the TMDS character rates mostly depends on the resolution, whether we need to repeat pixels or not, the bpc count and the format, we can now derive it from the HDMI connector state that stores all those infos and remove the duplication from drivers. Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-11-c5af16c3aae2@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-05-28drm/display: hdmi: Add HDMI compute clock helperMaxime Ripard1-0/+61
A lot of HDMI drivers have some variation of the formula to calculate the TMDS character rate from a mode, but few of them actually take all parameters into account. Let's create a helper to provide that rate taking all parameters into account. Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-9-c5af16c3aae2@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-05-28drm/connector: hdmi: Add support for output formatMaxime Ripard1-1/+2
Just like BPC, we'll add support for automatic selection of the output format for HDMI connectors. Let's add the needed defaults and fields for now. Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-7-c5af16c3aae2@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-05-28drm/connector: hdmi: Add output BPC to the connector stateMaxime Ripard1-0/+20
We'll add automatic selection of the output BPC in a following patch, but let's add it to the HDMI connector state already. Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-4-c5af16c3aae2@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-05-28drm/connector: hdmi: Create an HDMI sub-stateMaxime Ripard3-0/+50
The next features we will need to share across drivers will need to store some parameters for drivers to use, such as the selected output format. Let's create a new connector sub-state dedicated to HDMI controllers, that will eventually store everything we need. Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-3-c5af16c3aae2@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-05-21drm/mst: Fix NULL pointer dereference at drm_dp_add_payload_part2Wayne Lin1-3/+1
[Why] Commit: - commit 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload allocation/removement") accidently overwrite the commit - commit 54d217406afe ("drm: use mgr->dev in drm_dbg_kms in drm_dp_add_payload_part2") which cause regression. [How] Recover the original NULL fix and remove the unnecessary input parameter 'state' for drm_dp_add_payload_part2(). Fixes: 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload allocation/removement") Reported-by: Leon Weiß <leon.weiss@ruhr-uni-bochum.de> Link: https://lore.kernel.org/r/38c253ea42072cc825dc969ac4e6b9b600371cc8.camel@ruhr-uni-bochum.de/ Cc: lyude@redhat.com Cc: imre.deak@intel.com Cc: stable@vger.kernel.org Cc: regressions@lists.linux.dev Reviewed-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240307062957.2323620-1-Wayne.Lin@amd.com (cherry picked from commit 4545614c1d8da603e57b60dd66224d81b6ffc305)
2024-05-02Revert "drm/display: Make all helpers visible and switch to depends on"Geert Uytterhoeven1-14/+12
This reverts commit d674858ff979550a0e97b4ac766f2640f0d9d7e7, as helper code should always be selected by the driver that needs it, for the convenience of the final user configuring a kernel. The user who configures a kernel should not need to know which helpers are needed for the driver he is interested in. Making a driver depend on helper code means that the user needs to know which helpers to enable first, which is very user-unfriendly. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patchwork.freedesktop.org/patch/msgid/3db958e3f4002e26cd963596d810c37feb315fb3.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-05-02Revert "drm: Switch DRM_DISPLAY_HELPER to depends on"Geert Uytterhoeven1-1/+0
This reverts commit e075e496f516bf92bc0cbaf94d64e8d4a6b58321, as helper code should always be selected by the driver that needs it, for the convenience of the final user configuring a kernel. The user who configures a kernel should not need to know which helpers are needed for the driver he is interested in. Making a driver depend on helper code means that the user needs to know which helpers to enable first, which is very user-unfriendly. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patchwork.freedesktop.org/patch/msgid/1ba76cc4d96a8afefff5d1bc42fb1e1329c5da68.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-05-02Revert "drm: Switch DRM_DISPLAY_DP_AUX_BUS to depends on"Geert Uytterhoeven1-1/+0
This reverts commit 4d15125d7fe637f401e64e33c99513adf6586fdd, as helper code should always be selected by the driver that needs it, for the convenience of the final user configuring a kernel. The user who configures a kernel should not need to know which helpers are needed for the driver he is interested in. Making a driver depend on helper code means that the user needs to know which helpers to enable first, which is very user-unfriendly. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patchwork.freedesktop.org/patch/msgid/79824fec01eb9ab0673b9409f9b39cc8b5cc338d.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-05-02Revert "drm: Switch DRM_DISPLAY_DP_HELPER to depends on"Geert Uytterhoeven1-1/+0
This reverts commit 0323287de87d7e6e9c22c57d7440aa353a2298d0, as helper code should always be selected by the driver that needs it, for the convenience of the final user configuring a kernel. The user who configures a kernel should not need to know which helpers are needed for the driver he is interested in. Making a driver depend on helper code means that the user needs to know which helpers to enable first, which is very user-unfriendly. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patchwork.freedesktop.org/patch/msgid/89ac456805746b6d0c888f10c5120b11aacd3319.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-05-02Revert "drm: Switch DRM_DISPLAY_HDCP_HELPER to depends on"Geert Uytterhoeven1-1/+0
This reverts commit 3166e7e6d935caaef07605a5c90773fbf9ffeaf4, as helper code should always be selected by the driver that needs it, for the convenience of the final user configuring a kernel. The user who configures a kernel should not need to know which helpers are needed for the driver he is interested in. Making a driver depend on helper code means that the user needs to know which helpers to enable first, which is very user-unfriendly. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patchwork.freedesktop.org/patch/msgid/a40e70a0abd3d841c23c107d452a43fdd70ef37a.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-05-02Revert "drm: Switch DRM_DISPLAY_HDMI_HELPER to depends on"Geert Uytterhoeven1-1/+0
This reverts commit f6d2dc03fa8546b284dd8c1af027d9fac5725921, as helper code should always be selected by the driver that needs it, for the convenience of the final user configuring a kernel. The user who configures a kernel should not need to know which helpers are needed for the driver he is interested in. Making a driver depend on helper code means that the user needs to know which helpers to enable first, which is very user-unfriendly. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patchwork.freedesktop.org/patch/msgid/bd288a5943dab8609f2d1f2bf413595a61df727a.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-05-02Revert "drm/display: Select DRM_KMS_HELPER for DP helpers"Geert Uytterhoeven1-1/+0
This reverts commit 7fa678cc0a5648b5ea28629a2d21b9d4b6ac8f56, as the commit it fixes will be reverted, too. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://patchwork.freedesktop.org/patch/msgid/17b6a2c5f3250a7d02ee1b517182ca6fd9baa45a.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-04-26Merge tag 'drm-intel-next-2024-04-24' of ↵Dave Airlie2-3/+21
https://anongit.freedesktop.org/git/drm/drm-intel into drm-next Core Changes: - Some DP/DP_MST DRM helpers (Imre) Driver Changes (i915 Display): - PLL refactoring (Ville) - Limit eDP MSO pipe only for display version 20 (Luca) - More display refactor towards independence from i915 dev_priv (Jani) - QGV/SAGV related refactor (Stanislav) - Few MTL/DSC and a UHBR monitor fix (Imre) - BXT/GLK per-lane vswing and PHY reg cleanup (Ville) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/Zik0LKEtN1PwXXGb@intel.com
2024-04-22Backmerge tag 'v6.9-rc5' into drm-nextDave Airlie1-2/+2
Linux 6.9-rc5 I've had a persistent msm failure on clang, and the fix is in fixes so just pull it back to fix that. Signed-off-by: Dave Airlie <airlied@redhat.com>
2024-04-19drm/i915/dp_mst: Enable HBLANK expansion quirk for UHBR ratesImre Deak1-0/+2
Enabling the 5k@60Hz uncompressed mode on the MediaTek/Dell U3224KBA monitor results in a blank screen, at least on MTL platforms on UHBR link rates with some (<30) uncompressed bpp values. Enabling compression fixes the problem, so do that for now. Windows enables DSC always if the sink supports it and forcing it to enable the mode without compression leads to the same problem above (which suggests a panel issue with uncompressed mode). The same 5k mode on non-UHBR link rates is not affected and lower resolution modes are not affected either. The problem is similar to the one fixed by the HBLANK expansion quirk on Synaptics hubs, with the difference that the problematic mode has a longer HBLANK duration. Also the monitor doesn't report supporting HBLANK expansion; either its internal MST hub does the expansion internally - similarly to the Synaptics hub - or the issue has another root cause, but still related to the mode's short HBLANK duration. Enable the quirk for the monitor adjusting the detection for the abo