- Jan 07, 2025
-
-
Dmitry Baryshkov authored
Nouveau driver is the only user of the drm_encoder_slave API. Rework necessary bits of drm_encoder_slave into the nouveau_i2c_encoder API and drop drm_encoder_slave.c from the DRM KMS helper. Suggested-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
Danilo Krummrich <dakr@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250106-nouveau-encoder-slave-v3-2-1d37d2f2c67f@linaro.org
-
Dmitry Baryshkov authored
Chrontel CH7006 and Silicon Image sil164 drivers use drm_encoder_slave interface which is being used only by the nouveau driver. It doesn't make sense to keep this interface inside the DRM subsystem. In preparation to moving this set of helpers to the nouveau driver, move the only two I2C driver that use that interface to the nouveau driver too. Suggested-by:
-
Dmitry Baryshkov authored
The mode_valid() callbacks of drm_encoder, drm_crtc and drm_bridge take a const struct drm_display_mode argument. Change the mode_valid callback of drm_connector to also take a const argument. Acked-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Liviu Dudau <liviu.dudau@arm.com> Reviewed-by:
Raphael Gallais-Pou <rgallaispou@gmail.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Lyude Paul <lyude@redhat.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241214-drm-connector-mode-valid-const-v2-5-4f9498a4c822@linaro.org Signed-off-by:
-
Dmitry Baryshkov authored
The mode_valid() callbacks of drm_encoder, drm_crtc and drm_bridge take a const struct drm_display_mode argument. Change the mode_valid_ctx callback of drm_connector to also take a const argument. Acked-by:
-
Dmitry Baryshkov authored
Make hda_get_mode_idx() take a const struct drm_display_mode pointer instead of just raw struct drm_display_mode. This is a preparation to converting the mode_valid() callback of drm_connector to take a const struct drm_display_mode argument. Acked-by:
-
Dmitry Baryshkov authored
Make amdgpu_dm_connector_mode_valid() duplicate the mode during the test rather than modifying the passed mode. This is a preparation to converting the mode_valid() callback of drm_connector to take a const struct drm_display_mode argument. Reviewed-by:
-
Dmitry Baryshkov authored
The mode_valid() callbacks of drm_encoder, drm_crtc and drm_bridge accept const struct drm_display_mode argument. Change the mode_valid callback of drm_encoder_slave to also accept const argument. Reviewed-by:
Lyude Paul <lyude@redhat.com>
Reviewed-by:
-
- Jan 06, 2025
-
-
Uprev IGT to the latest version and update expectation files. Signed-off-by:
Vignesh Raman <vignesh.raman@collabora.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # msm Signed-off-by:
Helen Koike <helen.koike@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241217160655.2371138-1-vignesh.raman@collabora.com
-
The HDMI on RK3576 shares the same IP block (PHY and Controller) with rk3588. However, there are some control bits scattered in different GRF. Signed-off-by:
Andy Yan <andy.yan@rock-chips.com> Tested-by:
Detlev Casanova <detlev.casanova@collabora.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20241231094425.253398-4-andyshrk@163.com
-
RK3576 HDMI TX Controller is very similar to that of RK3588, but with some control bits for IO and interrupts status scattered across different GRF. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
There are some control bits for IO and interrupts status scattered across different GRF on differt SOC. Add platform callback for this IO setting and interrupts status handling. Signed-off-by:
-
Tomi Valkeinen authoredFix two kernel doc warnings introduced by the recent DP audio patch: - Add a doc line for the new "audio" field - Remove a reference to zynqmp_dpsub.c from zynqmp.rst, as the .c file no longer has structured comments Fixes: 3ec5c157 ("drm: xlnx: zynqmp_dpsub: Add DP audio support") Closes: https://lore.kernel.org/all/20241220154208.720d990b@canb.auug.org.au/ Reviewed-by:
Vishal Sagar <vishal.sagar@amd.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241220-xilinx-dp-audio-doc-fix-v1-1-cc488996e463@ideasonboard.com
-
- Jan 05, 2025
-
-
This is the only afbc format supported by the upcoming VOP for rk3576. Add support for it. Signed-off-by:
-
- Jan 04, 2025
-
-
Dmitry Baryshkov authored
Use the helper function to update the connector's information. This makes sure that HDMI-related events are handled in a generic way. Currently it is limited to the HDMI state reporting to the sound system. Acked-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241224-drm-bridge-hdmi-connector-v10-10-dc89577cd438@linaro.org Signed-off-by:
-
Dmitry Baryshkov authored
The vc4_hdmi_connector_detect_ctx() via vc4_hdmi_handle_hotplug() already reads EDID and propagates it to the drm_connector. Stop rereading EDID as a part of the .get_modes() callback and just update the list of modes. This matches the behaviour of the i915 driver. Acked-by:
-
Dmitry Baryshkov authored
Drop driver-specific implementation and use the generic HDMI Codec framework in order to implement the HDMI audio support. Acked-by:
-
Dmitry Baryshkov authored
Extend drm_bridge_connector code to read the EDID and use it to update connector status if the bridge chain implements HDMI bridge. Performing it from the generic location minimizes individual bridge's code and enforces standard behaviour from all corresponding drivers. Reviewed-by:
-
Dmitry Baryshkov authored
The HDMI Connectors need to perform a variety of tasks when the HDMI connector state changes. Such tasks include setting or invalidating CEC address, notifying HDMI codec driver, updating scrambler data, etc. Implementing such tasks in a driver-specific callbacks is error prone. Start implementing the generic helper function (currently handling only the HDMI Codec framework) to be used by drivers utilizing HDMI Connector framework. Reviewed-by:
-
Dmitry Baryshkov authored
Make the Lontium LT9611 DSI-to-HDMI bridge driver use the DRM HDMI Codec framework. This enables programming of Audio InfoFrames using the HDMI Connector interface and also enables support for the missing features, including the ELD retrieval and better hotplug support. Reviewed-by:
-
Dmitry Baryshkov authored
Add necessary glue code to be able to use new HDMI codec framework from the DRM bridge drivers. The drm_bridge implements a limited set of the hdmi_codec_ops interface, with the functions accepting both drm_connector and drm_bridge instead of just a generic void pointer. This framework is integrated with the DRM HDMI Connector framework, but can also be used for DisplayPort connectors. Reviewed-by:
-
Dmitry Baryshkov authored
Several DRM drivers implement HDMI codec support (despite its name it applies to both HDMI and DisplayPort drivers). Implement generic framework to be used by these drivers. This removes a requirement to implement get_eld() callback and provides default implementation for codec's plug handling. Acked-by:
-
Dmitry Baryshkov authored
The no_capture_mute flag might differ from platform to platform, especially in the case of the wrapping implementations, like the upcoming DRM HDMI Codec framework. Move the flag next to all other flags in struct hdmi_codec_pdata. Acked-by:
Mark Brown <broonie@kernel.org> Tested-by:
-
Dmitry Baryshkov authored
The upcoming DRM connector HDMI codec implementation is going to use codec-specific data in the .get_dai_id to get drm_connector. Pass data to the callback, as it is done with other hdmi_codec_ops callbacks. Acked-by:
-
Fix sparse warning: symbol 'npu6_dev_priv' was not declared. Should it be static? Fixes: 273b5176 ("accel/amdxdna: Add RyzenAI-npu6 support") Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202412311819.9mz11Uak-lkp@intel.com/ Signed-off-by:
Lizhi Hou <lizhi.hou@amd.com> Reviewed-by:
Mario Limonciello <mario.limonciello@amd.com> Signed-off-by:
-
The second parameter of aie2_query_status() is a userspace pointer. Declaring it as 'char __user *' to fix sparse warning. Fixes: 850d71f6 ("accel/amdxdna: Add query functions") Reported-by:
-
Fix sparse warning: symbol 'force_cmdlist' was not declared. Should it be static? Fixes: aac24309 ("accel/amdxdna: Add command execution") Reported-by:
-
Use rcu_access_pointer for pid in struct drm_file. This fixes sparse warning. Fixes: be462c97 ("accel/amdxdna: Add hardware context") Reported-by:
-
Fix the sparse warning: symbol 'aie2_max_col' was not declared. Should it be static? Fixes: c88d3325 ("accel/amdxdna: Add hardware resource solver") Reported-by:
-
Declare mailbox ringbuf_base and mbox_base as 'void __iomem *' to fix sparse warnings: cast removes address space '__iomem' of expression incorrect type in argument 2 (different address spaces) Fixes: b87f920b ("accel/amdxdna: Support hardware mailbox") Reported-by:
-
Declare the variables as static to fix the sparse warnings: symbol 'npu5_dev_priv' was not declared. Should it be static? symbol 'npu1_dev_priv' was not declared. Should it be static? symbol 'npu4_dev_priv' was not declared. Should it be static? symbol 'npu2_dev_priv' was not declared. Should it be static? Fixes: 8c9ff1b1 ("accel/amdxdna: Add a new driver for AMD AI Engine") Reported-by:
-
- Jan 03, 2025
-
-
DisplayPort AUX protocol supports I2C transport which is capable of reading EDID or supports MCCS. In drm_dp_helper, drm_dp_i2c_xfer() packs I2C requests into a sequence of AUX requests. it6505_aux_i2c_operation() is implemented to match drm_dp_i2c_xfer() operactions. it6505_aux_i2c_transfer() adds I2C functionality for it6505_aux_transfer(). Reviewed-by:
Hermes Wu <hermes.wu@ite.com.tw> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
-
HDCP must disabled encryption and restart authentication after waiting KSV for 5s. The original method uses a counter in a waitting loop that may wait much longer than it is supposed to. Use time_after() for KSV wait timeout. Signed-off-by:
-
When HDCP negotiation with a repeater device. Checking SHA V' matching must retry 3 times before restarting HDCP. Signed-off-by:
-
When running the HDCP CTS test with UNIGRAF DPR-100. KSV list must be read from DP_AUX_HDCP_KSV_FIFO in an AUX request, and can not separate with multiple read requests. The AUX operation command "CMD_AUX_GET_KSV_LIST" reads the KSV list with AUX FIFO and is able to read DP_AUX_HDCP_KSV_FIFO in an AUX request. Add it6505_get_ksvlist() which uses CMD_AUX_GET_KSV_LIST operation to read the KSV list. Reviewed-by:
-
When starting HDCP authentication, HDCP encryption should be enabled when R0'is checked. Change encryption enables time at R0' ready. The hardware HDCP engine trigger is changed and the repeater KSV fails will restart HDCP. Signed-off-by:
-
When HDCP is activated, a DisplayPort source receiving CP_IRQ from the sink shall check Bstatus from DPCD and process the corresponding value Reviewed-by:
-
A HDCP source device shall support max downstream to 127 devices. Change definition MAX_HDCP_DOWN_STREAM_COUNT to 127 KSVs shall save for DRM blocked devices check. This results in struct it6505 growth by ~0.5 KiB. Reviewed-by:
-
HDCP KSV list readback can choose to use AUX FIFO or general data register. For some DisplayPort devices, the KSV list must be read in 5 byte boundaries. The original AUX read command does not support these devices. The AUX command operation control register "REG_AUX_CMD_REQ" uses b[3:0] as AUX operacion control, and b[7:4] are status bits and read only. To change KSV read operation uses "CMD_AUX_NATIVE_READ" from using the data registers to using AUX FIFO. The extended command "CMD_AUX_GET_KSV_LIST" is added as "CMD_AUX_NATIVE_READ" with the 0x10 flag which selects AUX FIFO mode. Reviewed-by:
-
The original AUX operation using data registers is limited to 4 bytes. The AUX operation command CMD_AUX_I2C_EDID_READ uses AUX FIFO and is capable of reading 16 bytes. This improves the speed of EDID read. Reviewed-by:
-
The hardware AUX FIFO is 16 bytes Change definition of AUX_FIFO_MAX_SIZE to 16 Fixes: b5c84a9e ("drm/bridge: add it6505 driver") Reviewed-by:
-
