RE: [PATCH v3 04/11] drm/dp_mst: Register connectors via drm_connector_dynamic_register()

[Public] Hi Imre, Thanks for the patch set! Patch 1~4 & patch 6 & patch 8 are: Acked-by: Wayne Lin > -Original Message- > From: Imre Deak > Sent: Monday, December 16, 2024 8:24 PM > To: Wentland, Harry ; Li, Sun peng (Leo) > ; Lin, Wayne ; Deucher, > Alexander > Cc: intel-...@lists.fr

Re: [PATCH v20 5/9] drm: bridge: Cadence: Add MHDP8501 DP/HDMI driver

Hi, On Tue, Dec 17, 2024 at 02:51:47PM +0800, Sandor Yu wrote: > +static ssize_t firmware_version_show(struct device *dev, > + struct device_attribute *attr, char *buf); > +static struct device_attribute firmware_version = > __ATTR_RO(firmware_version); > + > +ssi

Re: [PATCH v5 3/7] dt-bindings: display: renesas, du: Add missing constraints

Hi Tomi, On Tue, Dec 17, 2024 at 6:32 AM Tomi Valkeinen wrote: > From: Tomi Valkeinen > > The binding is missing maxItems for all renesas,cmms and renesas,vsps > properties. As the amount of cmms or vsps is always a fixed amount, set > the maxItems to match the minItems. > > Also add the minItem

Re: a bochs-drm (?) oops on head

(cc'ing Hans, who implemented deferred console takeover) Hi Am 16.12.24 um 18:35 schrieb Dr. David Alan Gilbert: * Thomas Zimmermann (tzimmerm...@suse.de) wrote: Hi Am 16.12.24 um 14:46 schrieb Dr. David Alan Gilbert: [...] The attached patch fixes the problem for me. Could you please test

Re: [PATCH v5 3/7] dt-bindings: display: renesas,du: Add missing constraints

On Tue, Dec 17, 2024 at 11:59:53AM +0200, Tomi Valkeinen wrote: > Hi, > > On 17/12/2024 10:14, Geert Uytterhoeven wrote: > > Hi Tomi, > > > > On Tue, Dec 17, 2024 at 6:32 AM Tomi Valkeinen > > wrote: > >> From: Tomi Valkeinen > >> > >> The binding is missing maxItems for all renesas,cmms and re

Re: [PATCH v5 3/7] dt-bindings: display: renesas,du: Add missing constraints

On Tue, Dec 17, 2024 at 07:31:37AM +0200, Tomi Valkeinen wrote: > From: Tomi Valkeinen > > The binding is missing maxItems for all renesas,cmms and renesas,vsps > properties. As the amount of cmms or vsps is always a fixed amount, set > the maxItems to match the minItems. > > Also add the minIte

Re: [PATCH v2 1/4] drm/vc4: Use DRM Execution Contexts

On 12/17, Christian König wrote: > Am 16.12.24 um 20:08 schrieb Melissa Wen: > > On 12/12, Maíra Canal wrote: > > > VC4 has internal copies of `drm_gem_lock_reservations()` and > > > `drm_gem_unlock_reservations()` inside the driver and ideally, we should > > > move those hard-coded functions to th

Re: [PATCH 4/5] clk: Add flag to prevent frequency changes when walking subtrees

On Thu, Nov 21, 2024 at 06:41:14PM +0100, Miquel Raynal wrote: > There are mainly two ways to change a clock frequency. There's much more than that :) Off the top of my head, setting/clearing a min/max rate and changing the parent might also result in a rate change. And then, the firmware might

Re: [PATCH 0/4] cover-letter: Allow MMIO regions to be exported through dmabuf

Am 17.12.24 um 12:06 schrieb Wei Lin Guay: [SNIP] Please send that out once more with me on explicit CC. I will resend the patch series. I was experiencing issues with my email client, which inadvertently split the series into two separate emails. Alternatively I can also copy the code from

Re: [PATCH 0/5] clk: Fix simple video pipelines on i.MX8

On Fri, Nov 22, 2024 at 10:54:55AM +0100, Miquel Raynal wrote: > Hello Liu, > > Thanks for the feedback! > > On 22/11/2024 at 14:01:49 +08, Liu Ying wrote: > > > Hi Miquel, > > > > On 11/22/2024, Miquel Raynal wrote: > >> Recent changes in the clock tree have set CLK_SET_RATE_PARENT to the two

Re: [PATCH] drm/connector: Allow clearing HDMI infoframes

On Mon, 02 Dec 2024 12:19:39 -0600, Derek Foreman wrote: > Our infoframe setting code currently lacks the ability to clear > infoframes. For some of the infoframes, we only need to replace them, > so if an error occurred when generating a new infoframe we would leave > a stale frame instead of clea

Re: [PATCH v3 2/2] drm/connector: hdmi: Validate supported_formats matches ycbcr_420_allowed

On Tue, Dec 17, 2024 at 12:54:08AM +0200, Cristian Ciocaltea wrote: > Ensure HDMI connector initialization fails when the presence of > HDMI_COLORSPACE_YUV420 in the given supported_formats bitmask doesn't > match the value of drm_connector->ycbcr_420_allowed. > > Suggested-by: Dmitry Baryshkov >

[PATCH v4 1/6] tee: add restricted memory allocation

Add restricted memory allocation to the TEE subsystem. Restricted memory refers to memory buffers behind a hardware enforced firewall. It is not accessible to the kernel during normal circumstances but rather only accessible to certain hardware IPs or CPUs executing in higher privileged mode than

Re: [PATCH v2 1/4] drm/vc4: Use DRM Execution Contexts

Am 17.12.24 um 12:09 schrieb Maíra Canal: Hi Christian, On 17/12/24 07:30, Christian König wrote: Am 16.12.24 um 20:08 schrieb Melissa Wen: On 12/12, Maíra Canal wrote: VC4 has internal copies of `drm_gem_lock_reservations()` and `drm_gem_unlock_reservations()` inside the driver and ideally,

Re: [PATCH] drm/i915/cx0_phy: Fix C10 pll programming sequence

On 12/16/2024 11:45 PM, Suraj Kandpal wrote: According to spec VDR_CUSTOM_WIDTH register gets programmed after pll specific VDR registers and TX Lane programming registers are done. Moreover we only program into C10_VDR_CONTROL1 to update config and setup master lane once all VDR registers are

[PATCH v3 12/33] drm/mediatek: hdmi: Use regmap instead of iomem for main registers

From: Guillaume Ranquet In preparation for the addition of a new version of the HDMI IP which will need to share its iospace between multiple subdrivers, and in preparation for moving out the common bits between the two, migrate this driver to fully use regmap. Signed-off-by: Guillaume Ranquet

[PATCH v3 11/33] drm/mediatek: mtk_hdmi: Unregister audio platform device on failure

The probe function of this driver may fail after registering the audio platform device: in that case, the state is not getting cleaned up, leaving this device registered. Adding up to the mix, should the probe function of this driver return a probe deferral for N times, we're registering up to N a

[PATCH v3 08/33] drm/mediatek: mtk_cec: Switch to register as module_platform_driver

In preparation for splitting out the common bits from the HDMI driver, change the mtk_cec driver from being registered from the HDMI driver itself to be a module_platform_driver of its own. Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/mediatek/mtk_cec.c | 5 - drivers/gpu/

[PATCH v3 10/33] drm/mediatek: mtk_hdmi: Convert to module_platform_driver macro

Now that all of the mtk_hdmi subdrivers are a platform driver on their own it is possible to remove the custom init/exit functions in this driver and just use the module_platform_driver() macro. While at it, also compress struct of_device_id entries and remove stray commas in mtk_hdmi_driver assig

[PATCH v3 05/33] drm/mediatek: mtk_dpi: Add checks for reg_h_fre_con existence

In preparation for adding support for newer DPI instances which do support direct-pin but do not have any H_FRE_CON register, like the one found in MT8195 and MT8188, add a branch to check if the reg_h_fre_con variable was declared in the mtk_dpi_conf structure for the probed SoC DPI version. As a

[PATCH v3 07/33] dt-bindings: display: mediatek: Add binding for MT8195 HDMI-TX v2

Add a binding for the HDMI TX v2 Encoder found in MediaTek MT8195 and MT8188 SoCs. This fully supports the HDMI Specification 2.0b, hence it provides support for 3D-HDMI, Polarity inversion, up to 16 bits Deep Color, color spaces including RGB444, YCBCR420/422/444 (ITU601/ITU709) and xvYCC, with o

[PATCH v3 04/33] drm/mediatek: mtk_dpi: Move pixel clock setting flow to function

In preparation for adding support for the DPI IP found in MT8195 and in MT8188 used for HDMI, move the code flow for calculation and setting of the DPI pixel clock to a separate function called mtk_dpi_set_pixel_clk(). This was done because, on those platforms, the DPI instance that is used for HD

[PATCH v3 00/33] Add support for MT8195/88 DPI, HDMIv2 and DDCv2

Changes in v3: - Added hpd_enable() and hpd_disable() callbacks as suggested by Dmitry B - Removed audio mute call in bridge_enable() as suggested by CK - Reworked commonization commits for mtk_hdmi/mtk_hdmi_common and split out debugfs/abist implementation as suggested by CK - Removed .mode

[PATCH v3 03/33] drm/mediatek: mtk_dpi: Use an array for pixclk factor calculation

Setting the TVD PLL clock requires to multiply the target pixel clock by a specific constant factor to achieve the target PLL frequency, and this is done to reduce jitter to acceptable levels. On all MediaTek SoCs, the factor is not retrieved by any real kind of calculation but rather by checking

[PATCH v3 01/33] dt-bindings: display: mediatek: dpi: Add MT8195 and MT8188 compat

Add compatibles for the Digital Parallel Interface (DPI) block found in the MT8195 and MT8188 SoCs: inside of the chip, this one is directly connected to the HDMI block. Acked-by: Krzysztof Kozlowski Reviewed-by: CK Hu Signed-off-by: AngeloGioacchino Del Regno --- .../devicetree/bindings/disp

[PATCH v3 31/33] drm/mediatek: Introduce HDMI/DDC v2 for MT8195/MT8188

Add support for the newer HDMI-TX (Encoder) v2 and DDC v2 IPs found in MediaTek's MT8195, MT8188 SoC and their variants, and including support for display modes up to 4k60 and for HDMI Audio, as per the HDMI 2.0 spec. HDCP and CEC functionalities are also supported by this hardware, but are not in

[PATCH v3 28/33] drm/mediatek: mtk_hdmi: Split driver and add common probe function

In preparation for adding a new driver for the HDMI TX v2 IP, split out the functions that will be common between the already present mtk_hdmi (v1) driver and the new one. Since the probe flow for both drivers is 90% similar, add a common probe function that will be called from each driver's .prob

[PATCH v3 15/33] drm/mediatek: mtk_hdmi: Disgregate function mtk_hdmi_audio_set_param()

As a cleanup, and in preparation for splitting common bits of this driver, disgregate the code in function mtk_hdmi_audio_set_param() between mtk_hdmi_audio_params() and mtk_hdmi_audio_hw_params(). The generic hdmi_audio_param copy now gets performed in the former, and the IP specific mtk_hdmi_aud

[PATCH v3 27/33] drm/mediatek: mtk_hdmi: Improve mtk_hdmi_get_all_clk() flexibility

In preparation for splitting common bits of this driver and for introducing a new version of the MediaTek HDMI Encoder IP, improve the flexibility of function mtk_hdmi_get_all_clk() by adding a pointer to the clock names array and size of it to its parameters. Also change the array of struct clock

[PATCH v3 25/33] drm/mediatek: mtk_hdmi: Remove goto in mtk_hdmi_clk_enable_audio()

If the clk_prepare_enable() call for the SPDIF clock fails, just disable and unprepare the clock in the error check branch and return immediately instead of jumping to the end with a goto, slightly reducing code size. This commit brings no functional changes. Signed-off-by: AngeloGioacchino Del R

[PATCH v3 18/33] drm/mediatek: mtk_hdmi: Move vendor/product strings to drm_bridge

Move the vendor and product strings to the appropriate entries of struct drm_bridge and use that in mtk_hdmi_setup_spd_infoframe instead of having the same as function parameters. While at it, also beautify the strings, setting them to read "MediaTek On-Chip HDMI". Signed-off-by: AngeloGioacchino

[PATCH v3 13/33] drm/mediatek: mtk_hdmi: Fix typo for aud_sampe_size member

Rename member aud_sampe_size of struct hdmi_audio_param to aud_sample_size to fix a typo and enhance readability. This commit brings no functional changes. Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support") Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/mediatek/mtk_hdmi.c |

[PATCH v3 17/33] drm/mediatek: mtk_hdmi: Move N/CTS setting to new function

In preparation for splitting common bits of this driver, moving the hdmi_rec_n_table struct array, and the hdmi_recommended_n(), hdmi_mode_clock_to_hz(), hdmi_expected_cts() functions, add one function called mtk_hdmi_get_ncts() that sets both N and CTS in a single call. Signed-off-by: AngeloGioac

[PATCH v3 29/33] drm/mediatek: mtk_hdmi_common: Assign DDC adapter pointer to bridge

In preparation for adding the new HDMI TX v2 IP driver, assign the pointer to the DDC adapter to struct drm_bridge during probe. This commit brings no functional changes. Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/mediatek/mtk_hdmi_common.c | 1 + 1 file changed, 1 insertion

[PATCH v3 21/33] drm/mediatek: mtk_hdmi: Remove unused members of struct mtk_hdmi

The hdmi_colorspace csp member of struct mtk_hdmi is initialized once but then it's never used at all. Remove said member and the only assignment to it as a cleanup. Also remove the ibias, ibias_up, min_clock, max_clock, min_hdisplay and max_vdisplay members, as those were really completely unused

[PATCH v3 30/33] drm/mediatek: mtk_hdmi_common: Add OP_HDMI if helper funcs assigned

In preparation for adding the HDMI TX v2 driver, and to allow a future modernization of the HDMI v1 one, perform changes that enable the usage of the HDMI Helpers provided by DRM. Check if the HDMI driver provides the function pointers to hdmi_{clear,write}_infoframe used by the HDMI Helper API an

[PATCH v3 09/33] drm/mediatek: mtk_hdmi_ddc: Switch to register as module_platform_driver

In preparation for splitting out the common bits from the HDMI driver, change the mtk_cec driver from being registered from the HDMI driver itself to be a module_platform_driver of its own. With this change, there are no more users of the mtk_hdmi.h header so, while at it, also remove it. Signed-

[PATCH v3 20/33] drm/mediatek: mtk_hdmi: Move CEC device parsing in new function

Move the CEC device parsing logic to a new function called mtk_hdmi_get_cec_dev(), and move the parsing action to the end of mtk_hdmi_dt_parse_pdata(), allowing to remove gotos in this function, reducing code size and improving readability. Signed-off-by: AngeloGioacchino Del Regno --- drivers/

[PATCH v3 16/33] drm/mediatek: mtk_hdmi: Move plugged_cb/codec_dev setting to new function

In preparation for splitting common bits of this driver, move the mutex-protected cable plugged callback and codec device setting to a new function called mtk_hdmi_audio_set_plugged_cb(). Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/mediatek/mtk_hdmi.c | 13 + 1 fil

[PATCH v3 19/33] drm/mediatek: mtk_hdmi: Use dev_err_probe() in mtk_hdmi_dt_parse_pdata()

Change error prints to use dev_err_probe() instead of dev_err() where possible in function mtk_hdmi_dt_parse_pdata(), used only during device probe. While at it, also beautify some prints. Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/mediatek/mtk_hdmi.c | 34 ++-

[PATCH v3 26/33] drm/mediatek: mtk_hdmi: Cleanup function mtk_hdmi_resume()

Remove the error print in case of mtk_hdmi_clk_enable_audio() failures: since the APIs will already print on their own, having one in there is redundant. Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/mediatek/mtk_hdmi.c | 9 + 1 file changed, 1 insertion(+), 8 deletions(

[PATCH v3 33/33] drm/mediatek: mtk_hdmi_v2: Add debugfs ops and implement ABIST

Implement the Automated Built-In Self-Test ABIST functionality provided by the HDMIv2 IP and expose it through the "hdmi_abist" debugfs file. Write "1" to this file to activate ABIST, or "0" to deactivate. Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/mediatek/mtk_hdmi_v2.c | 1

[PATCH v3 23/33] drm/mediatek: mtk_hdmi: Use devm managed version of drm_bridge_add

Simplify the probe/remove functions by using devm_drm_bridge_add() as now there is no more need to manually remove the bridge. Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/mediatek/mtk_hdmi.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers

[PATCH v3 24/33] drm/mediatek: mtk_hdmi: Remove ifdef for CONFIG_PM_SLEEP

Since the SIMPLE_DEV_PM_OPS macro and the pm pointer are anyway defined when CONFIG_PM_SLEEP is not set, remove the ifdef for it and indicate that the mtk_hdmi_{remove,suspend} functions may be unused (as they are, in case PM support is not built-in). While at it, to improve readability, also comp

[PATCH v3 14/33] drm/mediatek: mtk_hdmi: Move audio params selection to new function

In preparation for splitting common bits of this driver, move the audio params (codec, sample rate/size, input type, i2s format, etc) selection to a new function called mtk_hdmi_audio_params(). Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/mediatek/mtk_hdmi.c | 46 ++

[PATCH v3 02/33] drm/mediatek: mtk_dpi: Add support for Pattern Generator in debugfs

This IP includes a Pattern Generator which is useful for debugging and testing purposes: add the relevant register and bits to the mtk_dpi_regs.h header, and implement support for it in mtk_dpi. Adding this required to introduce a .debugfs_init() callback for the DPI bridge, which creates a "dpi_t

Re: [PATCH v2 15/15] drm/mediatek: Introduce HDMI/DDC v2 for MT8195/MT8188

[PATCH] drm/panthor: Fix a race between the reset and suspend path

If a reset is scheduled when the suspend happens, we drop the reset-pending info on the floor assuming the resume will fix things, but the resume logic might try a fast reset. If we're lucky, the fast reset fails and we fallback to a slow reset, but if the FW was corrupted in a way that makes it pa

Re: [PATCH 0/4] cover-letter: Allow MMIO regions to be exported through dmabuf

Am 16.12.24 um 17:54 schrieb Keith Busch: On Mon, Dec 16, 2024 at 11:21:39AM +0100, Christian König wrote: Am 16.12.24 um 10:54 schrieb Wei Lin Guay: From: Wei Lin Guay However, as a general mechanism, it can support many other scenarios with VFIO. I imagine this dmabuf approach to be usable b

[PATCH v4 2/6] optee: account for direction while converting parameters

The OP-TEE backend driver has two internal function pointers to convert between the subsystem type struct tee_param and the OP-TEE type struct optee_msg_param. The conversion is done from one of the types to the other, which is then involved in some operation and finally converted back to the orig

[PATCH v4 3/6] optee: sync secure world ABI headers

Update the header files describing the secure world ABI, both with and without FF-A. The ABI is extended to deal with restricted memory, but as usual backward compatible. Signed-off-by: Jens Wiklander --- drivers/tee/optee/optee_ffa.h | 27 ++--- drivers/tee/optee/optee_msg.h | 65 ++

[PATCH v4 4/6] optee: support restricted memory allocation

Add support in the OP-TEE backend driver for restricted memory allocation. The support is limited to only the SMC ABI and for secure video buffers. OP-TEE is probed for the range of restricted physical memory and a memory pool allocator is initialized if OP-TEE have support for such memory. Signe

[PATCH v4 6/6] optee: smc abi: dynamic restricted memory allocation

Add support in the OP-TEE backend driver for dynamic restricted memory allocation using the SMC ABI. Signed-off-by: Jens Wiklander --- drivers/tee/optee/smc_abi.c | 74 +++-- 1 file changed, 71 insertions(+), 3 deletions(-) diff --git a/drivers/tee/optee/smc_abi.

[PATCH v4 5/6] optee: FF-A: dynamic restricted memory allocation

Add support in the OP-TEE backend driver dynamic restricted memory allocation with FF-A. The restricted memory pools for dynamically allocated restrict memory are instantiated when requested by user-space. This instantiation can fail if OP-TEE doesn't support the requested use-case of restricted m

Re: [PATCH 06/15] net: hbl_cn: debugfs support

Revisiting the comments regarding our use of debugfs as an interface for device configurations - A big part of the non-statistics debugfs parameters are HW related debug-only capabilities, and not configurations required by the user. Should these sort of parameters be part of devlink as well? Is

[PATCH v4 0/6] TEE subsystem for restricted dma-buf allocations

Hi, This patch set allocates the restricted DMA-bufs via the TEE subsystem. The TEE subsystem handles the DMA-buf allocations since it is the TEE (OP-TEE, AMD-TEE, TS-TEE, or perhaps a future QCOMTEE) which sets up the restrictions for the memory used for the DMA-bufs. I've added a new IOCTL, TE

Re:[PATCH v1 2/2] drm/panel: add Raydium RM67200 panel driver

Hi Sebastian, At 2024-12-11 00:41:31, "Sebastian Reichel" wrote: >The Rockchip W552793DBA-V10 display/touchscreen board contains a >Wanchanglong W552793BAA panel, which in turn is using a Raydium >RM67200 MIPI-DSI controller. Add a DSI panel driver for it. > >The W552793BAA panel init sequence

Fwd: [PATCH] drm/amdgpu: Make the submission path memory reclaim safe

Sending it out to the mailing lists once more because AMD mail servers tried to convert it to HTML :( Am 17.12.24 um 01:26 schrieb Matthew Brost: On Fri, Nov 22, 2024 at 02:36:59PM +, Tvrtko Ursulin wrote: [SNIP] Do we have system wide workqueues for that? It seems a bit overkill that amd

Re: [PATCH v4 5/9] drm/msm/dpu: Add SM6150 support

On 2024/12/17 18:54, Dmitry Baryshkov wrote: On Tue, Dec 10, 2024 at 02:53:56PM +0800, Fange Zhang wrote: From: Li Liu Add definitions for the display hardware used on the Qualcomm SM6150 platform. Reviewed-by: Dmitry Baryshkov Signed-off-by: Li Liu Signed-off-by: Fange Zhang --- .../

Re: [PATCH] drm/fourcc: add LINEAR modifiers with an exact pitch alignment

On Tue, Dec 17, 2024 at 11:13:05AM +, Michel Dänzer wrote: > On 2024-12-17 10:14, Brian Starkey wrote: > > On Sun, Dec 15, 2024 at 03:53:14PM +, Marek Olšák wrote: > >> The comment explains the problem with DRM_FORMAT_MOD_LINEAR. > >> > >> Signed-off-by: Marek Olšák > >> > >> diff --git a/

Re: [PATCH v20 1/9] soc: cadence: Create helper functions for Cadence MHDP

On Tue, Dec 17, 2024 at 02:51:43PM +0800, Sandor Yu wrote: > Cadence MHDP IP includes a firmware. Driver and firmware communicate > through a mailbox. The basic mailbox access functions in this patch > are derived from the DRM bridge MHDP8546 driver. > New mailbox access functions have been created

Re: [PATCH] drm/panthor: Fix a race between the reset and suspend path

On Tue, 17 Dec 2024 10:56:14 + Liviu Dudau wrote: > On Tue, Dec 17, 2024 at 10:24:57AM +0100, Boris Brezillon wrote: > > If a reset is scheduled when the suspend happens, we drop the > > reset-pending info on the floor assuming the resume will fix things, > > but the resume logic might try a

Re: [PATCH v3 10/10] arm64: dts: renesas: gray-hawk-single: Add DisplayPort support

CC Saravana On Tue, Dec 17, 2024 at 2:29 PM Geert Uytterhoeven wrote: > On Mon, Dec 16, 2024 at 2:33 PM Geert Uytterhoeven > wrote: > > On Fri, Dec 6, 2024 at 10:33 AM Tomi Valkeinen > > wrote: > > > From: Tomi Valkeinen > > > > > > Add support for the mini DP output on the Gray Hawk board. >

[PATCH v4 0/2] leds: TI LP8864/LP8866 support

From: Alexander Sverdlin The series adds support for a family of Texas Instruments' automotive high-efficiency LED drivers with boost controller. The four or six high-precision current sinks support phase shifting that is automatically adjusted based on the number of channels in use. LED brightne

[PATCH v4 1/2] dt-bindings: backlight: add TI LP8864/LP8866 LED-backlight drivers

From: Alexander Sverdlin Add bindings for Texas Instruments' LP8864/LP8866 LED-backlight drivers. Note that multiple channels in these models are used for load-balancing and brightness is controlled gobally, so from a user perspective it's only one LED. Reviewed-by: Rob Herring (Arm) Signed-off

Re: [PATCH v2 1/4] drm/vc4: Use DRM Execution Contexts

On 12/17, Christian König wrote: > Am 17.12.24 um 12:09 schrieb Maíra Canal: > > Hi Christian, > > > > On 17/12/24 07:30, Christian König wrote: > > > Am 16.12.24 um 20:08 schrieb Melissa Wen: > > > > On 12/12, Maíra Canal wrote: > > > > > VC4 has internal copies of `drm_gem_lock_reservations()` a

[PATCH v4 2/2] leds: lp8864: New driver

From: Alexander Sverdlin Add driver for TI LP8864, LP8864S, LP8866 4/6 channel LED-backlight drivers with I2C interface. Link: https://www.ti.com/lit/gpn/lp8864-q1 Link: https://www.ti.com/lit/gpn/lp8864s-q1 Link: https://www.ti.com/lit/gpn/lp8866-q1 Link: https://www.ti.com/lit/gpn/lp8866s-q1 S

[PATCH] drm/tegra: dsi: fix the reference leak of the ganged mode device

tegra_dsi_driver leaks a device reference, which is obtained by of_find_device_by_node() in tegra_dsi_ganged_probe(). Add a function tegra_dsi_ganged_put() and call it in the error path of .probe() and in .remove(). This bug was found by an experimental verification tool that I am developing. Fix

Re: [PATCH v10 2/4] drm/doc: Document device wedged event

On Thu, Dec 12, 2024 at 03:50:29PM -0300, André Almeida wrote: > Em 28/11/2024 12:37, Raag Jadav escreveu: > > Add documentation for device wedged event in a new 'Device wedging' > > chapter. The describes basic definitions, prerequisites and consumer > > expectations along with an example. > > >

Re: [PATCH 7/8] drm/msm/dpu: link DSPP_2/_3 blocks on X1E80100

On Mon, Dec 16, 2024 at 10:27:28AM +0200, Dmitry Baryshkov wrote: > Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks. Please say something about why you're doing this and what the expected outcome of doing so is. There is currently no way for a third party (e.g. stable or distro mainta

[PATCH] drm/bochs: Do not put DRM device in PCI remove callback

Removing the bochs PCI device should mark the DRM device as unplugged without removing it. Hence clear the respective call to drm_dev_put() from bochs_pci_remove(). Fixes a double unref in devm_drm_dev_init_release(). An example error message is shown below: [ 32.958338] BUG: KASAN: use-after-f

Re: [PATCH v2 1/4] drm/vc4: Use DRM Execution Contexts

Hi Christian, On 17/12/24 07:30, Christian König wrote: Am 16.12.24 um 20:08 schrieb Melissa Wen: On 12/12, Maíra Canal wrote: VC4 has internal copies of `drm_gem_lock_reservations()` and `drm_gem_unlock_reservations()` inside the driver and ideally, we should move those hard-coded functions t

Re: [PATCH 06/15] net: hbl_cn: debugfs support

On Tue, Dec 17, 2024 at 12:00:39PM +0200, Avri Kehat wrote: > Revisiting the comments regarding our use of debugfs as an interface for > device configurations - > A big part of the non-statistics debugfs parameters are HW related debug-only > capabilities, and not configurations required by the u

Re: [PATCH v20 2/9] drm: bridge: cadence: Update mhdp8546 mailbox access functions

On Tue, Dec 17, 2024 at 02:51:44PM +0800, Sandor Yu wrote: > Basic mailbox access functions are removed, they are replaced by > mailbox helper functions: > - cdns_mhdp_mailbox_send() > - cdns_mhdp_mailbox_send_recv() > - cdns_mhdp_mailbox_send_recv_multi() > - cdns_mhdp_secure_mailbox_send() > - cd

Re: [PATCH] drm/panthor: Fix a race between the reset and suspend path

On Tue, Dec 17, 2024 at 12:06:59PM +0100, Boris Brezillon wrote: > On Tue, 17 Dec 2024 10:56:14 + > Liviu Dudau wrote: > > > On Tue, Dec 17, 2024 at 10:24:57AM +0100, Boris Brezillon wrote: > > > If a reset is scheduled when the suspend happens, we drop the > > > reset-pending info on the flo

[PATCH v2 2/3] drm/atomic-helpers: Introduce drm_atomic_helper_disable_connector()

drm_atomic_helper_disable_connector() disables a connector taking care of disabling the CRTC as well if the disabled connector was the only one connector connected to the CRTC. Signed-off-by: Herve Codina --- drivers/gpu/drm/drm_atomic_helper.c | 67 + include/drm/drm

[PATCH v2 3/3] drm: bridge: ti-sn65dsi83: Add error recovery mechanism

In some cases observed during ESD tests, the TI SN65DSI83 cannot recover from errors by itself. A full restart of the bridge is needed in those cases to have the bridge output LVDS signals again. Also, during tests, cases were observed where reading the status of the bridge was not even possible.

[PATCH v2 0/3] Add support for errors recovery in the TI SN65DSI83 bridge driver

Hi, Usually the TI SN65DSI83 recovers from error by itself but during ESD tests, we have some cases where the TI SN65DSI83 didn't recover. In order to handle those cases, this series adds support for a recovery mechanism. Compare to the previous iteration, this v2 series mainly: - Rebase patch

[PATCH v2 1/3] dt-bindings: display: bridge: sn65dsi83: Add interrupt

Both the TI SN65DSI83 and SN65DSI84 bridges have an IRQ pin to signal errors using interrupt. This interrupt is not documented in the binding. Add the missing interrupts property. Signed-off-by: Herve Codina Reviewed-by: Laurent Pinchart Acked-by: Conor Dooley --- .../devicetree/bindings/dis

Re: [PATCH v3 0/7] drm/connector: Expose only a properly inited connector

On Thu, Dec 12, 2024 at 01:03:17AM +0200, Imre Deak wrote: The patchset at [2] is pushed now to drm-misc-next, thanks for the reviews, acks and ideas. While merging, I fixed the typos in patch 3, 5-7 and removed references to 'patches', 'patchsets' in the commit logs of patch 2, 4, 9. I had to r

Re: [PATCH v9 0/6] drm/log: Introduce a new boot logger to draw the kmsg on the screen

On 17/12/2024 15:19, Geert Uytterhoeven wrote: Hi Jocelyn, On Wed, Dec 4, 2024 at 6:41 PM Jocelyn Falempe wrote: drm_log is a simple logger that uses the drm_client API to print the kmsg boot log on the screen. This is not a full replacement to fbcon, as it will only print the kmsg. It will n

Re: [PATCH v2 15/15] drm/mediatek: Introduce HDMI/DDC v2 for MT8195/MT8188

Il 17/12/24 10:21, CK Hu (胡俊光) ha scritto: Hi, Angelo: On Thu, 2024-12-05 at 12:45 +0100, AngeloGioacchino Del Regno wrote: External email : Please do not click links or open attachments until you have verified the sender or the content. Add support for the newer HDMI-TX (Encoder) v2 and DDC

[PATCH v6 0/7] drm/msm: adreno: add support for DDR bandwidth scaling via GMU

The Adreno GPU Management Unit (GMU) can also vote for DDR Bandwidth along the Frequency and Power Domain level, but by default we leave the OPP core scale the interconnect ddr path. While scaling the interconnect path was sufficient, newer GPUs like the A750 requires specific vote parameters and

[PATCH v6 1/7] drm/msm: adreno: add defines for gpu & gmu frequency table sizes

Even if the code uses ARRAY_SIZE() to fill those tables, it's still a best practice to not use magic values for tables in structs. Suggested-by: Dmitry Baryshkov Reviewed-by: Dmitry Baryshkov Reviewed-by: Akhil P Oommen Signed-off-by: Neil Armstrong --- drivers/gpu/drm/msm/adreno/a6xx_gmu.h |

[PATCH v6 4/7] drm/msm: adreno: find bandwidth index of OPP and set it along freq index

The Adreno GPU Management Unit (GMU) can also scale the DDR Bandwidth along the Frequency and Power Domain level, until now we left the OPP core scale the OPP bandwidth via the interconnect path. In order to enable bandwidth voting via the GPU Management Unit (GMU), when an opp is set by devfreq w

[PATCH v6 2/7] drm/msm: adreno: add plumbing to generate bandwidth vote table for GMU

The Adreno GPU Management Unit (GMU) can also scale DDR Bandwidth along the Frequency and Power Domain level, but by default we leave the OPP core scale the interconnect ddr path. While scaling via the interconnect path was sufficient, newer GPUs like the A750 requires specific vote paremeters and

[PATCH v6 3/7] drm/msm: adreno: dynamically generate GMU bw table

The Adreno GPU Management Unit (GMU) can also scale the ddr bandwidth along the frequency and power domain level, but for now we statically fill the bw_table with values from the downstream driver. Only the first entry is used, which is a disable vote, so we currently rely on scaling via the linux

[PATCH v6 5/7] drm/msm: adreno: enable GMU bandwidth for A740 and A750

Now all the DDR bandwidth voting via the GPU Management Unit (GMU) is in place, declare the Bus Control Modules (BCMs) and the corresponding parameters in the GPU info struct. Reviewed-by: Dmitry Baryshkov Reviewed-by: Akhil P Oommen Signed-off-by: Neil Armstrong --- drivers/gpu/drm/msm/adreno

[PATCH v6 7/7] arm64: qcom: dts: sm8650: add interconnect and opp-peak-kBps for GPU

Each GPU OPP requires a specific peak DDR bandwidth, let's add those to each OPP and also the related interconnect path. Signed-off-by: Neil Armstrong --- arch/arm64/boot/dts/qcom/sm8650.dtsi | 15 +++ 1 file changed, 15 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/sm8650.dts

[PATCH v6 6/7] arm64: qcom: dts: sm8550: add interconnect and opp-peak-kBps for GPU

Each GPU OPP requires a specific peak DDR bandwidth, let's add those to each OPP and also the related interconnect path. Reviewed-by: Akhil P Oommen Signed-off-by: Neil Armstrong --- arch/arm64/boot/dts/qcom/sm8550.dtsi | 13 + 1 file changed, 13 insertions(+) diff --git a/arch/arm

Re: [PATCH v9 0/6] drm/log: Introduce a new boot logger to draw the kmsg on the screen

Hi Jocelyn. On Tue, Dec 17, 2024 at 3:46 PM Jocelyn Falempe wrote: > On 17/12/2024 15:19, Geert Uytterhoeven wrote: > > On Wed, Dec 4, 2024 at 6:41 PM Jocelyn Falempe wrote: > >> drm_log is a simple logger that uses the drm_client API to print the kmsg > >> boot log on the screen. > >> This is

Re: [PATCH] drm/fourcc: add LINEAR modifiers with an exact pitch alignment

On 2024-12-16 22:54, Marek Olšák wrote: > On Mon, Dec 16, 2024 at 5:46 AM Lucas Stach > wrote: > > Am Montag, dem 16.12.2024 um 10:27 +0100 schrieb Michel Dänzer: > > On 2024-12-15 21:53, Marek Olšák wrote: > > > The comment explains the problem with DRM

Re: [PATCH v5 3/7] dt-bindings: display: renesas,du: Add missing constraints

Hi, On 17/12/2024 10:14, Geert Uytterhoeven wrote: Hi Tomi, On Tue, Dec 17, 2024 at 6:32 AM Tomi Valkeinen wrote: From: Tomi Valkeinen The binding is missing maxItems for all renesas,cmms and renesas,vsps properties. As the amount of cmms or vsps is always a fixed amount, set the maxItems t

[PATCH v2] media: cec: include linux/debugfs.h and linux/seq_file.h where needed

Having cec.h include linux/debugfs.h leads to all users of all cec headers include and depend on debugfs.h and its dependencies for no reason. Drop the include from cec.h, and include debugfs.h and seq_file.h where needed. Sort all the modified include lists while at it. Cc: Hans Verkuil Cc: lin

Re: [PATCH 7/8] drm/msm/dpu: link DSPP_2/_3 blocks on X1E80100

On Tue, Dec 17, 2024 at 09:41:44AM +0100, Johan Hovold wrote: > On Mon, Dec 16, 2024 at 10:27:28AM +0200, Dmitry Baryshkov wrote: > > Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks. > > Please say something about why you're doing this and what the expected > outcome of doing so is. >

Re: [PATCH] drm/amdgpu: Make the submission path memory reclaim safe

[+cc Krzysztof, who I think witnessed a possibly related Kernel crash in the wild] P. On Wed, 2024-11-13 at 13:48 +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > As commit 746ae46c1113 ("drm/sched: Mark scheduler work queues with > WQ_MEM_RECLAIM") > points out, ever since > a6149f03936

Re: [PATCH v4 5/9] drm/msm/dpu: Add SM6150 support

On Tue, 17 Dec 2024 at 13:02, fange zhang wrote: > > > > On 2024/12/17 18:54, Dmitry Baryshkov wrote: > > On Tue, Dec 10, 2024 at 02:53:56PM +0800, Fange Zhang wrote: > >> From: Li Liu > >> > >> Add definitions for the display hardware used on the Qualcomm SM6150 > >> platform. > >> > >> Reviewed

Re: Re: [PATCH v6 08/16] drm/rockchip: vop2: Support 32x8 superblock afbc

Hi Andy, On Tue, 17 Dec 2024 at 00:41, Andy Yan wrote: > At 2024-12-16 21:06:07, "Daniel Stone" wrote: > >On Sat, 14 Dec 2024 at 08:18, Andy Yan wrote: > >> This is the only afbc format supported by the upcoming > >> VOP for rk3576. > >> > >> Add support for it. > > > >Out of interest, how was

Re: [PATCH v4 04/25] drm/tests: Add test for drm_atomic_helper_check_modeset()

On Mon, 16 Dec 2024 16:43:15 -0800, Jessica Zhang wrote: > Add a test for drm_atomic_check_modeset() specifically to validate > drm_atomic_check_valid_clones() helper > > Signed-off-by: Jessica Zhang Reviewed-by: Maxime Ripard Thanks! Maxime

Re: [PATCH v9 0/6] drm/log: Introduce a new boot logger to draw the kmsg on the screen

Hi Jocelyn, On Wed, Dec 4, 2024 at 6:41 PM Jocelyn Falempe wrote: > drm_log is a simple logger that uses the drm_client API to print the kmsg > boot log on the screen. > This is not a full replacement to fbcon, as it will only print the kmsg. > It will never handle user input, or a terminal beca

  1   2   3   >