Re: [PATCH 05/14] drm/msm/dp: fold dp_power into dp_ctrl module

On 29.12.2023 23:56, Dmitry Baryshkov wrote: > The dp_power submodule is limited to handling the clocks only following > previous cleanups. Fold it into the dp_ctrl submodule, removing one > unnecessary level of indirection. > > Signed-off-by: Dmitry Baryshkov > --- [...] > > - /* set

Re: [PATCH 04/14] drm/msm/dp: inline dp_power_(de)init

On 29.12.2023 23:56, Dmitry Baryshkov wrote: > In preparation to cleanup of the dp_power module, inline dp_power_init() > and dp_power_deinit() functions, which are now just turning the clocks > on and off. > > Signed-off-by: Dmitry Baryshkov > --- Oh wow, talk about sugar (salt?) syntax :P

Re: [PATCH 03/14] drm/msm/dp: parse DT from dp_parser_get

On 29.12.2023 23:56, Dmitry Baryshkov wrote: > It makes little sense to split the submodule get and actual DT parsing. > Call dp_parser_parse() directly from dp_parser_get(), so that the parser > data is fully initialised once it is returned to the caller. > > Signed-off-by: Dmitry Baryshkov >

Re: [PATCH 02/14] drm/msm/dp: drop unused fields from dp_power_private

On 29.12.2023 23:56, Dmitry Baryshkov wrote: > Drop unused and obsolete fields from struct dp_power_private. > > Signed-off-by: Dmitry Baryshkov > --- Reviewed-by: Konrad Dybcio Konrad

Re: (subset) [PATCH v4 00/29] Add HDMI support for RK3128

On Fri, 22 Dec 2023 18:41:51 +0100, Alex Bee wrote: > This is version 4 of my series that aims to add support for the display > controller (VOP) and the HDMI controller block of RK3128 (which is very > similar to the one found in RK3036). The original intention of this series > was to add support

Re: (subset) [PATCH v4 00/29] Add HDMI support for RK3128

On Fri, 22 Dec 2023 18:41:51 +0100, Alex Bee wrote: > This is version 4 of my series that aims to add support for the display > controller (VOP) and the HDMI controller block of RK3128 (which is very > similar to the one found in RK3036). The original intention of this series > was to add support

Re: [PATCH v4 01/29] dt-bindings: display: rockchip, inno-hdmi: Document RK3128 compatible

Am Freitag, 22. Dezember 2023, 18:41:52 CET schrieb Alex Bee: > The integration for this SoC is different from the currently existing: It > needs it's PHY's reference clock rate to calculate the DDC bus frequency > correctly. The controller is also part of a powerdomain, so this gets added > as an

[PATCH 11/14] drm/msm/dp: move all IO handling to dp_catalog

Rather than parsing the I/O addresses from dp_parser and then passing them via a struct pointer to dp_catalog, handle I/O region parsing in dp_catalog and drop it from dp_parser. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/dp/dp_catalog.c | 125 +++-

[PATCH 12/14] drm/msm/dp: move link property handling to dp_panel

Instead of passing link properties through the separate struct, parse them directly in the dp_panel. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/dp/dp_display.c | 8 drivers/gpu/drm/msm/dp/dp_display.h | 1 - drivers/gpu/drm/msm/dp/dp_panel.c | 63

[PATCH 14/14] drm/msm/dp: drop dp_parser

Finally drop separate "parsing" submodule. There is no need in it anymore. All submodules handle DT properties directly rather than passing them via the separate structure pointer. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/Makefile| 1 - drivers/gpu/drm/msm/dp/dp_aux.h

[PATCH 13/14] drm/msm/dp: move next_bridge handling to dp_display

Remove two levels of indirection and fetch next bridge directly in dp_display_probe_tail(). Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/dp/dp_display.c | 42 + drivers/gpu/drm/msm/dp/dp_parser.c | 14 -- drivers/gpu/drm/msm/dp/dp_parser.h | 14

[PATCH 08/14] drm/msm/dp: move phy_configure_opts to dp_ctrl

There is little point in sharing phy configuration structure between several modules. Move it to dp_ctrl, which becomes the only submodule re-configuring the PHY. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/dp/dp_catalog.c | 19 - drivers/gpu/drm/msm/dp/dp_catalog.h | 2

[PATCH 10/14] drm/msm/dp: handle PHY directly in dp_ctrl

There is little point in going trough dp_parser->io indirection each time the driver needs to access the PHY. Store the pointer directly in dp_ctrl_private. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/dp/dp_ctrl.c| 37 ++---

[PATCH 03/14] drm/msm/dp: parse DT from dp_parser_get

It makes little sense to split the submodule get and actual DT parsing. Call dp_parser_parse() directly from dp_parser_get(), so that the parser data is fully initialised once it is returned to the caller. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/dp/dp_display.c | 6 --

[PATCH 05/14] drm/msm/dp: fold dp_power into dp_ctrl module

The dp_power submodule is limited to handling the clocks only following previous cleanups. Fold it into the dp_ctrl submodule, removing one unnecessary level of indirection. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/Makefile| 1 - drivers/gpu/drm/msm/dp/dp_ctrl.c|

[PATCH 04/14] drm/msm/dp: inline dp_power_(de)init

In preparation to cleanup of the dp_power module, inline dp_power_init() and dp_power_deinit() functions, which are now just turning the clocks on and off. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/dp/dp_display.c | 4 ++-- drivers/gpu/drm/msm/dp/dp_power.c | 10 --

[PATCH 09/14] drm/msm/dp: remove PHY handling from dp_catalog.c

Inline dp_catalog_aux_update_cfg() and call phy_calibrate() from dp_aux functions directly. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/dp/dp_aux.c | 9 +++-- drivers/gpu/drm/msm/dp/dp_aux.h | 1 + drivers/gpu/drm/msm/dp/dp_catalog.c | 12

[PATCH 06/14] drm/msm/dp: simplify stream clocks handling

There is only a single DP_STREAM_PM clock, stream_pixel. Instead of using a separate dss_module_power instance for this single clock, handle this clock directly. This allows us to drop several wrapping functions. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/dp/dp_ctrl.c | 91

[PATCH 07/14] drm/msm/dp: stop parsing clock names from DT

All supported platforms use the same clocks configuration. Instead of parsing names from DT in a pretty complex manner, use the static configuration. If at some point newer (or older) platforms have different clock configuration, this clock config can be moved to the device data. Signed-off-by:

[PATCH 02/14] drm/msm/dp: drop unused fields from dp_power_private

Drop unused and obsolete fields from struct dp_power_private. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/dp/dp_power.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/msm/dp/dp_power.c b/drivers/gpu/drm/msm/dp/dp_power.c index c4843dd69f47..b095a5b47c8b

[PATCH 01/14] drm/msm/dp: drop unused parser definitions

Drop several unused and obsolete definitions from the dp_parser module. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/dp/dp_parser.h | 46 -- 1 file changed, 46 deletions(-) diff --git a/drivers/gpu/drm/msm/dp/dp_parser.h

[PATCH 00/14] drm/msm/dp: clear power and parser submodules away

Reshuffle code in the DP driver, cleaning up clocks and DT parsing and dropping the dp_power and dp_parser submodules. Initially I started by looking onto stream_pixel clock handling only to find several wrapping layers around a single clocks. After inlining and/or dropping them (and thus

[PATCH v9 2/2] drm/i915/guc: Close deregister-context race against CT-loss

If we are at the end of suspend or very early in resume its possible an async fence signal (via rcu_call) is triggered to free_engines which could lead us to the execution of the context destruction worker (after a prior worker flush). Thus, when suspending, insert rcu_barriers at the start of

[PATCH] drm/panel: enable prepare_prev_first for BOE tv101wum

After commit 9e15123eca79 ("drm/msm/dsi: Stop unconditionally powering up DSI hosts at modeset"), the host DSI bridge can no longer be assumed to be available. Enable prepare_prev_first for the panel to ensure the DSI bridge is ready before panel init. Fixes display on the IdeaPad Duet 3

Re: Implement per-key keyboard backlight as auxdisplay?

Hi Hans & the others, [snip] I also stumbled across a new Problem: We have an upcoming device that has a per-key keyboard backlight, but does the control completely via a wmi/acpi interface. So no usable hidraw here for a potential userspace driver implementation ... So a quick summary for

Re: [PATCH 8/8] drm/panel: nt35510: support FRIDA FRD400B25025-A-CTK

Hi Dario, On Fri, Dec 29, 2023 at 2:52 PM Dario Binacchi wrote: > The initialization commands are taken from the STMicroelectronics driver > found at > https://github.com/STMicroelectronics/STM32CubeF7/blob/master/Drivers/BSP/Components/nt35510/ > > Signed-off-by: Dario Binacchi NAK. Please

Re: [PATCH 7/8] drm/panel: nt35510: refactor panel initialization

On Fri, Dec 29, 2023 at 2:52 PM Dario Binacchi wrote: > The previous implementation did not make it easy to support new > NT35510-based panels with different initialization sequences. > This patch, preparatory for future developmentes, simplifies the > addition of new NT35510-based displays and

Re: [PATCH 5/8] dt-bindings: nt35510: add compatible for FRIDA FRD400B25025-A-CTK

Hi Dario, thanks for your patch! On Fri, Dec 29, 2023 at 2:52 PM Dario Binacchi wrote: > The patch adds the FRIDA FRD400B25025-A-CTK panel, which belongs to the > Novatek NT35510-based panel family. > > Signed-off-by: Dario Binacchi (...) > +oneOf: > + items: > +- const:

[RFC PATCH] drm/amd/display: fix bandwidth validation failure on DCN 2.1

IGT `amdgpu/amd_color/crtc-lut-accuracy` fails right at the beginning of the test execution, during atomic check, because DC rejects the bandwidth state for a fb sizing 64x64. The test was previously working with the deprecated dc_commit_state(). Now using dc_validate_with_context() approach, the

Re: [PATCH 5/8] dt-bindings: nt35510: add compatible for FRIDA FRD400B25025-A-CTK

On Fri, 29 Dec 2023 14:51:20 +0100, Dario Binacchi wrote: > The patch adds the FRIDA FRD400B25025-A-CTK panel, which belongs to the > Novatek NT35510-based panel family. > > Signed-off-by: Dario Binacchi > --- > > .../display/panel/novatek,nt35510.yaml| 20 +++ > 1

[PATCH 7/8] drm/panel: nt35510: refactor panel initialization

The previous implementation did not make it easy to support new NT35510-based panels with different initialization sequences. This patch, preparatory for future developmentes, simplifies the addition of new NT35510-based displays and also avoids the risk of creating regressions on already managed

[PATCH 8/8] drm/panel: nt35510: support FRIDA FRD400B25025-A-CTK

The initialization commands are taken from the STMicroelectronics driver found at https://github.com/STMicroelectronics/STM32CubeF7/blob/master/Drivers/BSP/Components/nt35510/ Signed-off-by: Dario Binacchi --- drivers/gpu/drm/panel/panel-novatek-nt35510.c | 75 +++ 1 file

[PATCH 5/8] dt-bindings: nt35510: add compatible for FRIDA FRD400B25025-A-CTK

The patch adds the FRIDA FRD400B25025-A-CTK panel, which belongs to the Novatek NT35510-based panel family. Signed-off-by: Dario Binacchi --- .../display/panel/novatek,nt35510.yaml| 20 +++ 1 file changed, 12 insertions(+), 8 deletions(-) diff --git

[PATCH 0/8] Add display support for stm32f769-disco board

The series adds display support for the stm32f769-disco board. It has been tested on hardware revisions MB1225-B03 and MB1166-A09. This required modifications to the nt35510 driver. As I do not have the Hydis HVA40WV1 display, it would be better if someone tested the driver in that configuration.

Re: [PATCH v2.1 2/4] drm/i915/gt: reconcile Excess struct member kernel-doc warnings

Hi Randy, On Thu, Dec 28, 2023 at 03:49:46PM -0800, Randy Dunlap wrote: > Document nested struct members with full names as described in > Documentation/doc-guide/kernel-doc.rst. > > intel_gsc.h:34: warning: Excess struct member 'gem_obj' description in > 'intel_gsc' > > Also add missing field

[PATCH v5 3/4] dt-bindings: display: Add SSD133x OLED controllers

Add a Device Tree binding schema for the OLED panels based on the Solomon SSD133x family of controllers. Signed-off-by: Javier Martinez Canillas Reviewed-by: Rob Herring --- Changes in v5: - Drop I2C example in DT binding schema due that bus not being supported. Changes in v3: - Move

[PATCH v5 0/4] drm/solomon: Add support for the SSD133x controller family

Hello, This patch-set adds support for the family of SSD133x Solomon controllers, such as the SSD1331. These are used for RGB Dot Matrix OLED/PLED panels. This is a v5 that is basically the same than the previous v4 but dropping support for I2C since the ssd133x family does not support that

[PATCH v5 4/4] drm/ssd130x: Add support for the SSD133x OLED controller family

The Solomon SSD133x controllers (such as the SSD1331) are used by RGB dot matrix OLED panels, add a modesetting pipeline to support the chip family. The SSD133x controllers support 256 (8-bit) and 65k (16-bit) color depths but only the 256-color mode (DRM_FORMAT_RGB332) is implemented for now.

[PATCH v5 1/4] dt-bindings: display: ssd1307fb: Add vendor prefix to width and height

The commit 591825fba8a2 ("dt-bindings: display: ssd1307fb: Remove default width and height values") used the wrong properties for width and height, instead of the correct "solomon,width" and "solomon,height" properties. Fix this by adding the vendor prefix to the width and height properties.

[PATCH v5 2/4] dt-bindings: display: ssd132x: Add vendor prefix to width and height

Commit 2d23e7d6bacb ("dt-bindings: display: Add SSD132x OLED controllers") used the wrong properties for width and height, instead of the correct "solomon,width" and "solomon,height" properties. Fix this by adding the vendor prefix to the width and height properties. Fixes: 2d23e7d6bacb

[PATCH v4 4/4] drm/i915/guc: Use the ce_to_guc() wrapper whenever possible

Get the guc reference from the ce using the ce_to_guc() helper. Just a leftover from previous cleanups. Signed-off-by: Andi Shyti Reviewed-by: Nirmoy Das --- drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v4 3/4] drm/i915: Use the new gt_to_guc() wrapper

Get the guc reference from the gt using the gt_to_guc() helper. Signed-off-by: Andi Shyti Reviewed-by: Nirmoy Das --- drivers/gpu/drm/i915/i915_debugfs_params.c | 2 +- drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c | 4 ++-- 2 files changed, 3 insertions(+), 3

[PATCH v4 2/4] drm/i915/guc: Use the new gt_to_guc() wrapper

Get the guc reference from the gt using the gt_to_guc() helper. Signed-off-by: Andi Shyti Reviewed-by: Nirmoy Das --- drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 4 +-- drivers/gpu/drm/i915/gt/uc/intel_gsc_proxy.c | 3 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 2 +-

[PATCH v4 1/4] drm/i915/gt: Create the gt_to_guc() wrapper

We already have guc_to_gt() and getting to guc from the GT it requires some mental effort. Add the gt_to_guc(). Given the reference to the "gt", the gt_to_guc() will return the pinter to the "guc". Update all the files under the gt/ directory. Signed-off-by: Andi Shyti Reviewed-by: Nirmoy Das

[PATCH v4 0/4] Add gt_to_guc() helper

Hi, respinning this series as there was a rebase conflict in its latest version. Andi Changelog: == v3 -> v4: - Rebase on top of the latest drm-tip v2 -> v3: - Remove patch 1 that contained guc_to_i915() v1 -> v2: - add the gt_to_guc() helper and change files in: - i915/gt/ -

[PATCH] drivers/accel/habanalabs: Remove unnecessary braces from if statement

The coding style in the Linux kernel prefers not to use braces for single-statement if conditions. This patch removes the unnecessary braces from an if statement in the file drivers/accel/habanalabs/common/command_submission.c, which also resolves a coding style warning. Signed-off-by: