Re: [PATCH v17 0/9] Enable Adaptive Sync SDP Support for DP

On 4/19/2024 6:05 PM, Jani Nikula wrote: On Thu, 04 Apr 2024, "Nautiyal, Ankit K" wrote: On 3/19/2024 3:16 PM, Maxime Ripard wrote: On Mon, Mar 18, 2024 at 04:37:58PM +0200, Jani Nikula wrote: On Mon, 11 Mar 2024, Mitul Golani wrote: An Adaptive-Sync-capable DP protocol converter

Re: [PATCH 0/4] drm/amd/display: Update Display Core unit tests

Em sáb., 20 de abr. de 2024 às 15:50, Joao Paulo Pereira da Silva escreveu: > > Hey, I'm interested in contributing for display tests from this patch-set. > I've noticed potential updates related to both refactoring and optimization. > This patch-set applies these suggestions. > Hi, It's great

[PATCH v8 3/4] MAINTAINERS: add SAM9X7 SoC's LVDS controller

Add the newly added LVDS controller for the SAM9X7 SoC to the existing MAINTAINERS entry. Signed-off-by: Dharma Balasubiramani Reviewed-by: Neil Armstrong Acked-by: Nicolas Ferre --- Changelog v7 -> v8 v6 -> v7 - No changes. v5 -> v6 - Correct the file name sam9x7-lvds.yaml ->

[PATCH v8 4/4] ARM: configs: at91: Enable LVDS serializer support

Enable LVDS serializer support for display pipeline. Signed-off-by: Dharma Balasubiramani Acked-by: Hari Prasath Gujulan Elango Acked-by: Nicolas Ferre --- Changelog v7 -> v8 v6 -> v7 v5 -> v6 v4 -> v5 v3 -> v4 v2 -> v3 - No Changes. --- arch/arm/configs/at91_dt_defconfig | 1 + 1 file

[PATCH v8 2/4] drm/bridge: add lvds controller support for sam9x7

Add a new LVDS controller driver for sam9x7 which does the following: - Prepares and enables the LVDS Peripheral clock - Defines its connector type as DRM_MODE_CONNECTOR_LVDS and adds itself to the global bridge list. - Identifies its output endpoint as panel and adds it to the encoder display

[PATCH v8 1/4] dt-bindings: display: bridge: add sam9x75-lvds binding

Add the 'sam9x75-lvds' compatible binding, which describes the Low Voltage Differential Signaling (LVDS) Controller found on some Microchip's sam9x7 series System-on-Chip (SoC) devices. This binding will be used to define the properties and configuration for the LVDS Controller in DT.

[PATCH v8 0/4] LVDS Controller Support for SAM9X75 SoC

This patch series introduces LVDS controller support for the SAM9X75 SoC. The LVDS controller is designed to work with Microchip's sam9x7 series System-on-Chip (SoC) devices, providing Low Voltage Differential Signaling capabilities. Patch series Changelog: - Include configs: at91: Enable LVDS

[RFC][PATCH] drm: bridge: dw-mipi-dsi: Call modeset in modeset callback

Doing modeset in .atomic_pre_enable callback instead of dedicated .mode_set callback does not seem right. Undo this change, which was added as part of commit 05aa61334592 ("drm: bridge: dw-mipi-dsi: Fix enable/disable of DSI controller") as it breaks STM32MP15xx LTDC scanout (DSI)->TC358762

Re: [PATCH 3/3] drm/msm/mdp4: correct LCDC regulator name

On 4/19/2024 7:33 PM, Dmitry Baryshkov wrote: Correct c error from the conversion of LCDC regulators to the bulk API. Fixes: 54f1fbcb47d4 ("drm/msm/mdp4: use bulk regulators API for LCDC encoder") Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c | 2 +-

Re: [PATCH 1/3] drm/msm: don't clean up priv->kms prematurely

On 4/19/2024 7:33 PM, Dmitry Baryshkov wrote: MSM display drivers provide kms structure allocated during probe(). Don't clean up priv->kms field in case of an error. Otherwise probe functions might fail after KMS probe deferral. So just to understand this more, this will happen when master

Re: [PATCH v2 8/9] drm/msm: merge dpu format database to MDP formats

On 4/19/2024 9:01 PM, Dmitry Baryshkov wrote: Finally remove duplication between DPU and generic MDP code by merging DPU format lists to the MDP format database. Signed-off-by: Dmitry Baryshkov --- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 4 +-

Re: [PATCH v2 4/9] drm/msm/dpu: pull format flag definitions to mdp_format.h

On 4/19/2024 9:01 PM, Dmitry Baryshkov wrote: In preparation to merger of formats databases, pull format flag definitions to mdp_format.h header, so that they are visibile to both dpu and mdp drivers. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 98

[PATCH v3 4/5] drm/v3d: Decouple stats calculation from printing

Create a function to decouple the stats calculation from the printing. This will be useful in the next step when we add a seqcount to protect the stats. Signed-off-by: Maíra Canal --- drivers/gpu/drm/v3d/v3d_drv.c | 18 ++ drivers/gpu/drm/v3d/v3d_drv.h | 4

[PATCH v3 5/5] drm/v3d: Fix race-condition between sysfs/fdinfo and interrupt handler

In V3D, the conclusion of a job is indicated by a IRQ. When a job finishes, then we update the local and the global GPU stats of that queue. But, while the GPU stats are being updated, a user might be reading the stats from sysfs or fdinfo. For example, on `gpu_stats_show()`, we could think about

[PATCH v3 3/5] drm/v3d: Create function to update a set of GPU stats

Given a set of GPU stats, that is, a `struct v3d_stats` related to a queue in a given context, create a function that can update this set of GPU stats. Signed-off-by: Maíra Canal Reviewed-by: Tvrtko Ursulin Reviewed-by: Jose Maria Casanova Crespo --- drivers/gpu/drm/v3d/v3d_sched.c | 17

[PATCH v3 1/5] drm/v3d: Create two functions to update all GPU stats variables

Currently, we manually perform all operations to update the GPU stats variables. Apart from the code repetition, this is very prone to errors, as we can see on commit 35f4f8c9fc97 ("drm/v3d: Don't increment `enabled_ns` twice"). Therefore, create two functions to manage updating all GPU stats

[PATCH v3 0/5] drm/v3d: Fix GPU stats inconsistencies and race-condition

The first version of this series had the intention to fix two major issues with the GPU stats: 1. We were incrementing `enabled_ns` twice by the end of each job. 2. There is a race-condition between the IRQ handler and the users The first of the issues was already addressed and the fix was

[PATCH v3 2/5] drm/v3d: Create a struct to store the GPU stats

This will make it easier to instantiate the GPU stats variables and it will create a structure where we can store all the variables that refer to GPU stats. Note that, when we created the struct `v3d_stats`, we renamed `jobs_sent` to `jobs_completed`. This better express the semantics of the

Re: [PATCH v7 2/4] drm/bridge: add lvds controller support for sam9x7

Hi Dharma, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-misc/drm-misc-next] [also build test WARNING on linus/master v6.9-rc4 next-20240419] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to

[PATCH 4/4] Documentation/gpu: Update AMD Display Core Unit Test documentation

Display Core unit tests documentation is a bit outdated, therefore update it to follow current configuration. Signed-off-by: Joao Paulo Pereira da Silva --- .../gpu/amdgpu/display/display-test.rst | 20 +-- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git

[PATCH 3/4] drm/amd/display/test: Optimize kunit test suite dml_dcn20_fpu_dcn21_update_bw_bounding_box_test

The KUnit init function of the suite dml_dcn20_fpu_dcn21_update_bw_bounding_box_test does not need to be executed before every test, but only once before the test suite, since it's just used to store backup copies of DCN global structures. So, turn it into a suite_init. Signed-off-by: Joao Paulo

[PATCH 2/4] drm/amd/display/test: Fix kunit test that is not running

The KUnit test file test/kunit/dc/dml/calcs/bw_fixed_test.c does not have the correct path relative to the file being tested, dc/basics/bw_fixed.c. Also, it is neither compiling nor running. Therefore, change the test file path and import it conditionally in the file dc/basics/bw_fixed.c to make

[PATCH 1/4] drm/amd/display: Refactor AMD display KUnit tests configs

Configs in AMD display KUnit tests can be clarified. Remove unnecessary configs, rename configs to follow a pattern, and update config Help blocks. Signed-off-by: Joao Paulo Pereira da Silva --- drivers/gpu/drm/amd/display/Kconfig | 31 ++-

[PATCH 0/4] drm/amd/display: Update Display Core unit tests

Hey, I'm interested in contributing for display tests from this patch-set. I've noticed potential updates related to both refactoring and optimization. This patch-set applies these suggestions. [WHY] 1. The single test suite in the file test/kunit/dc/dml/calcs/bw_fixed_test.c,

[PATCH] Revert "drm/etnaviv: Expose a few more chipspecs to userspace"

From: Christian Gmeiner This reverts commit 1dccdba084897443d116508a8ed71e0ac8a031a4. In userspace a different approach was choosen - hwdb. As a result, there is no need for these values. Signed-off-by: Christian Gmeiner --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 20 ---

[PATCH] drm/bridge: imx: Fix unmet depenency for PHY_FSL_SAMSUNG_HDMI_PHY

When enabling i.MX8MP DWC HDMI driver, it automatically selects PHY_FSL_SAMSUNG_HDMI_PHY, since it wont' work without the phy. This may cause some Kconfig warnings during various build tests. Fix this by implying the phy instead of selecting the phy. Fixes: 1f36d634670d ("drm/bridge: imx: add

Re: [PATCH v2 1/4] drm: add devm release action

On 19/04/24 14:41, Maxime Ripard wrote: > On Fri, Apr 19, 2024 at 02:28:23PM +0530, Aravind Iddamsetty wrote: >> In scenarios where drm_dev_put is directly called by driver we want to >> release devm_drm_dev_init_release action associated with struct >> drm_device. >> >> v2: Directly expose the

Re: [PATCH][next] drivers: video: Simplify device_node cleanup using __free

20 Apr 2024 1:13:42 am Dmitry Baryshkov : > On Sat, Apr 20, 2024 at 12:22:41AM +0530, Shresth Prasad wrote: >> >>> Please fix the subject line to be "backlight: : ...". I came >>> very close to deleting this patch without reading it ;-) . >> >> Really sorry about that, I'll fix it. >> >>> Do

Re: [PATCH v3 2/2] misc: sram: Add DMA-BUF Heap exporting of SRAM areas

On Fri, Apr 19, 2024 at 06:57:47PM +0200, Christian Gmeiner wrote: > Am Di., 9. Apr. 2024 um 14:14 Uhr schrieb Greg Kroah-Hartman > : > > > > On Tue, Apr 09, 2024 at 02:06:05PM +0200, Pascal FONTAIN wrote: > > > From: Andrew Davis > > > > > > This new export type exposes to userspace the SRAM