Hi Jani,
On Tue, Apr 29, 2025 at 12:22:00PM +0300, Jani Nikula wrote:
> On Tue, 29 Apr 2025, Maxime Ripard wrote:
> > Hi Jani,
> >
> > On Mon, Apr 28, 2025 at 07:31:50PM +0300, Jani Nikula wrote:
> >> On Mon, 31 Mar 2025, Anusha Srivatsa wrote:
> >> > Allocate panel via reference counting. Add _
On 03/05/2025 00:52, Dmitry Baryshkov wrote:
> On Wed, Apr 30, 2025 at 03:00:49PM +0200, Krzysztof Kozlowski wrote:
>> Add support for DSI on Qualcomm SM8750 SoC with notable difference:
>>
>> DSI PHY PLLs, the parents of pixel and byte clocks, cannot be used as
>> parents before DSI PHY is configu
On Mon, Apr 28, 2025 at 05:25:16PM +0200, Luca Ceresoli wrote:
> Hi Maxime,
>
> On Mon, 28 Apr 2025 13:39:23 +0200
> Maxime Ripard wrote:
>
> > On Thu, Apr 24, 2025 at 10:05:49PM +0200, Luca Ceresoli wrote:
> > > This is the new API for allocating DRM bridges.
> > >
> > > The devm lifetime mana
On 03/05/2025 00:44, Dmitry Baryshkov wrote:
> On Wed, Apr 30, 2025 at 03:00:45PM +0200, Krzysztof Kozlowski wrote:
>> Add bitfields for PHY_CMN_CTRL_0 registers to avoid hard-coding bit
>> masks and shifts and make the code a bit more readable.
>>
>> Signed-off-by: Krzysztof Kozlowski
>>
>> ---
>
On 03/05/2025 00:42, Dmitry Baryshkov wrote:
> On Wed, Apr 30, 2025 at 03:00:36PM +0200, Krzysztof Kozlowski wrote:
>> On SM8750 the setting rate of pixel and byte clocks, while the parent
>> DSI PHY PLL, fails with:
>>
>> disp_cc_mdss_byte0_clk_src: rcg didn't update its configuration.
>>
>> DSI
On 30/04/25 4:06 pm, Luca Ceresoli wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> Hello Manikandan,
>
> On Wed, 30 Apr 2025 09:42:16 +
> wrote:
>
> [...]
>
>>> diff --git a/drivers/gpu/drm/bridge/microchip-lvds.c
>>> b/drivers/gp
On Sat, May 03, 2025 at 12:07:58AM -0400, Joel Fernandes wrote:
> +Conceptual diagram (not exact) of the Falcon and its memory subsystem is as
> follows:
> +
> + External Memory (Framebuffer / System DRAM)
> +▲ │
> +│ │
> +
On Sat, May 03, 2025 at 12:07:57AM -0400, Joel Fernandes wrote:
> +.. SPDX-License-Identifier: GPL-2.0
> +==
> +Device Initialization (devinit)
> +==
Separate SPDX line from title heading.
> +These low-level GPU firmware components a
On Sat, May 03, 2025 at 12:07:56AM -0400, Joel Fernandes wrote:
> +.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +=
> +FWSEC (Firmware Security)
> +=
Separate SPDX line from title heading.
> +Here is a block diagram of the FWSEC memory layout::
A
On 5/5/25 10:00, Bagas Sanjaya wrote:
On Sat, May 03, 2025 at 12:07:55AM -0400, Joel Fernandes wrote:
+Here is a block diagram of the VBIOS layout::
+
+ ┌┐
+ │ VBIOS (Starting at ROM_OFFSET: 0x30)
On Sat, May 03, 2025 at 12:07:55AM -0400, Joel Fernandes wrote:
> +.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +==
> +VBIOS
> +==
Separate SPDX line and title heading.
> +- PciAt Image (Type 0x00) - This is the standard PCI BIOS image who's naming
> likely
> +comes from t
From: Dmitry Baryshkov
The HDMI driver already has msm_hdmi_hpd_enable() and
msm_hdmi_hpd_disable() functions. Wire them into the
msm_hdmi_bridge_funcs, so that HPD can be enabled and disabled
dynamically rather than always having HPD events generation enabled.
Reviewed-by: Jessica Zhang
Signe
From: Dmitry Baryshkov
Expand the HDMI_CFG() macro in HDMI config description. It has no added
value other than hiding some boilerplate declarations.
Reviewed-by: Jessica Zhang
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 16
drivers/gpu/drm/msm/hdmi/
From: Dmitry Baryshkov
The HDMI block needs to be enabled to properly generate HPD events. Make
sure it is not turned off in the disable paths if HPD delivery is enabled.
Reviewed-by: Jessica Zhang
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c| 1 +
drivers/gpu/d
From: Dmitry Baryshkov
We must be sure that the HDMI controller is powered on, while performing
the DDC transfer. Add corresponding runtime PM calls to
msm_hdmi_i2c_xfer().
Reviewed-by: Jessica Zhang
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_i2c.c | 14 --
From: Dmitry Baryshkov
As these clocks are now used in the runtime PM callbacks, they have no
connection to 'HPD'. Rename corresponding fields to follow clocks
purpose, to power up the HDMI controller.
Reviewed-by: Jessica Zhang
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdm
From: Dmitry Baryshkov
It is completely not obvious, but the so-called 'hpd' clocks and
regulators are required for the HDMI host to function properly. Merge
pwr and hpd regulators. Use regulators, clocks and pinctrl to implement
proper runtime PM callbacks.
Reviewed-by: Jessica Zhang
Signed-of
From: Dmitry Baryshkov
The last platform using legacy clock names for HDMI block (APQ8064)
switched to new clock names in 5.16. It's time to stop caring about old
DT, drop hand-coded helpers and switch to clk_bulk_* API.
Reviewed-by: Jessica Zhang
Signed-off-by: Dmitry Baryshkov
---
drivers/g
From: Dmitry Baryshkov
The pm_runtime_get_sync() function is a bad choise for runtime power
management. Switch HDMI driver to pm_runtime_resume_and_get() and add
proper error handling, while we are at it.
Reviewed-by: Jessica Zhang
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/
From: Dmitry Baryshkov
The only clock which has frequency being set through hpd_freqs is the
"core" aka MDSS_HDMI_CLK clock. It always has the specified frequency,
so we can drop corresponding clk_set_rate() call together with the
hpd_freq infrastructure.
Reviewed-by: Jessica Zhang
Signed-off-b
From: Dmitry Baryshkov
With the extp being the only "power" clock left, remove the surrounding
loops and handle the extp clock directly.
Reviewed-by: Jessica Zhang
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c| 24
drivers/gpu/drm/msm/hdm
From: Dmitry Baryshkov
According to the vendor kernel [1] , the alt_iface clock should be
enabled together with the rest of HPD clocks, to make HPD to work
properly.
[1]
https://git.codelinaro.org/clo/la/kernel/msm-3.18/-/commit/e07a5487e521e57f76083c0a6e2f995414ac6d03
Reviewed-by: Jessica Zha
From: Dmitry Baryshkov
As a preparation to the next patches convert 'static const char *'
arrays to 'static const char * const', as required by the checkpatch.pl
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Jessica Zhang
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 10 +-
drivers/gpu/drm/msm
From: Dmitry Baryshkov
The commit 68e674b13b17 ("drm/msm/hdmi: drop unused GPIO support")
dropped support for obsolete qcom,hdmi-tx-mux-* gpios. They were not
used by any of the upstream platforms. Drop them from the bindings too.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Krzysztof Kozlowski
The MSM HDMI driver is plagued with the long-standing bug. If HDMI cable
is disconnected, in most of the cases cable reconnection will not be
detected properly. We have been carrying the patch from [1] in our
integration tree for ages. The time has come to fix the long-standing
bug and implement pr
I think Android is probably the only remaining user of the dmabuf sysfs
files. The BPF infrastructure added earlier in this series will allow us
to get the same information much more cheaply.
This patch is a RFC because I'd like to keep this for at least one more
longterm stable release (6.18?) be
The dmabuf iterator traverses the list of all DMA buffers.
DMA buffers are refcounted through their associated struct file. A
reference is taken on each buffer as the list is iterated to ensure each
buffer persists for the duration of the bpf program execution without
holding the list mutex.
Sign
Use the same test buffers as the traditional iterator and a new BPF map
to verify the test buffers can be found with the open coded dmabuf
iterator.
Signed-off-by: T.J. Mercier
---
.../testing/selftests/bpf/bpf_experimental.h | 5 ++
.../selftests/bpf/prog_tests/dmabuf_iter.c| 52 +
This test creates a udmabuf, and a dmabuf from the system dmabuf heap,
and uses a BPF program that prints dmabuf metadata with the new
dmabuf_iter to verify they can be found.
Signed-off-by: T.J. Mercier
---
tools/testing/selftests/bpf/config| 3 +
.../selftests/bpf/prog_tests/dmab
This open coded iterator allows for more flexibility when creating BPF
programs. It can support output in formats other than text. With an open
coded iterator, a single BPF program can traverse multiple kernel data
structures (now including dmabufs), allowing for more efficient analysis
of kernel d
Expose the debugfs list and mutex so they are usable for the creation of
a BPF iterator for dmabufs without the need for CONFIG_DEBUG_FS. Rename
the symbols so it's clear debugfs is not required, and that the list
contains dmabufs and not some other type.
Signed-off-by: T.J. Mercier
---
v2: Make
Until CONFIG_DMABUF_SYSFS_STATS was added [1] it was only possible to
perform per-buffer accounting with debugfs which is not suitable for
production environments. Eventually we discovered the overhead with
per-buffer sysfs file creation/removal was significantly impacting
allocation and free times
On Sun, 4 May 2025 at 05:02, Abhinav Kumar wrote:
>
> Hi Alex
>
> Thanks for the response.
>
> My updates below. I also had one question for Abel below.
>
> Thanks
>
> Abhinav
>
> On 5/1/2025 8:56 AM, Aleksandrs Vinarskis wrote:
> > On Thu, 1 May 2025 at 04:11, Abhinav Kumar
> > wrote:
> >>
> >>
On Tue, Apr 22, 2025 at 9:23 AM Neil Armstrong
wrote:
>
> On 22/04/2025 09:04, neil.armstr...@linaro.org wrote:
> > On 19/04/2025 23:32, Martin Blumenstingl wrote:
> >> Hi Martijn, Hi Neil,
> >>
> >> On Thu, Apr 10, 2025 at 8:46 PM wrote:
> >>>
> >>> Hi Martin,
> >>>
> >>> Thank you for the patch
On Tue, Apr 29, 2025 at 11:00 PM Christophe JAILLET
wrote:
>
> Le 29/04/2025 à 21:07, I Hsin Cheng a écrit :
> > Coverity scan reported the usage of "mode->clock * 1000" may lead to
> > integer overflow. Cast the type of "mode->clock" to "unsigned long long"
> > when utilizing it to avoid potentia
8", "08/28/2018",
- "12/07/2018", NULL },
+ "12/07/2018", "04/17/2020", NULL },
.orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
};
---
base-commit: 593bde4ca9b1991e81ccf98b0baf8499cab6cab9
change-id: 20250504-gpd_pocket2_biosver-662fe240755f
Best regards,
--
Mark Dietzer
On Sat, May 03, 2025 at 04:42:04PM +0200, Heiko Stübner wrote:
> Am Dienstag, 22. April 2025, 09:04:39 Mitteleuropäische Sommerzeit schrieb
> Andy Yan:
> > From: Andy Yan
> >
> > When preparing to convert the current inno hdmi driver into a
> > bridge driver, I found that there are several issue
On Thu, 24 Apr 2025 11:54:20 +0530, Ayushi Makhija wrote:
> This series enables the support for DSI to DP bridge ports
> (labled as DSI0 and DSI1) of the Qualcomm's SA8775P Ride platform.
>
> SA8775P SoC has DSI controller v2.5.1 and DSI PHY v4.2.
> The Ride platform is having ANX7625 DSI to DP
On Thu, 10 Apr 2025 10:52:21 +0800, Chen Ni wrote:
> Replace comma between expressions with semicolons.
>
> Using a ',' in place of a ';' can have unintended side effects.
> Although that is not the case here, it is seems best to use ';'
> unless ',' is intended.
>
> Found by inspection.
> No f
On Fri, 07 Mar 2025 08:24:48 +0200, Dmitry Baryshkov wrote:
> Since version 5.0 the DPU got an improved way of handling multi-output
> configurations. It is now possible to program all pending changes
> through a single CTL and flush everything at the same time.
>
> Implement corresponding chang
On Sun, 20 Apr 2025 17:12:42 +0200, Luca Weiss wrote:
> Since the interconnect driver for msm8953 is already upstream, let's add
> the nodes which are required for it to enable interconnect on MSM8953.
>
>
Applied, thanks!
[1/2] dt-bindings: msm: qcom,mdss: Document interconnect paths
h
On Fri, 25 Apr 2025 12:51:50 +0300, Dmitry Baryshkov wrote:
> The LCDC controller uses pixel clock provided by the multimedia clock
> controller (mmcc) instead of using LVDS PHY clock directly. Link LVDS
> clocks properly, taking MMCC into account.
>
> MDP4 uses custom code to handle LVDS panel.
On Thu, 06 Mar 2025 19:11:12 +0100, Konrad Dybcio wrote:
> A set of not quite related bindings warnings fixes.
>
>
Applied, thanks!
[02/11] dt-bindings: display: msm: sm8350-mdss: Describe the CPU-CFG icc path
https://gitlab.freedesktop.org/lumag/msm/-/commit/60b8d3a2365a
Best regard
On Sat, 26 Apr 2025 07:51:17 +0300, Dmitry Baryshkov wrote:
> Since SmartDMA planes provide two rectangles, it is possible to use them
> to drive two different DRM planes, first plane getting the rect_0,
> another one using rect_1 of the same SSPP. The sharing algorithm is
> pretty simple, it req
On Sat, 01 Mar 2025 11:24:53 +0200, Dmitry Baryshkov wrote:
> During one of the chats Abhinav pointed out that in the 1.x generation
> most of the DPU/MDP5 instances didn't have DSC support. Also SDM630
> didn't provide DSC support. Disable DSC on those platforms.
>
>
Applied, thanks!
[1/5] d
On Wed, 23 Apr 2025 20:52:45 +0300, Dmitry Baryshkov wrote:
> The MSM DisplayPort driver implements several HDMI codec functions
> in the driver, e.g. it manually manages HDMI codec device registration,
> returning ELD and plugged_cb support. In order to reduce code
> duplication reuse drm_hdmi_a
On Fri, 18 Apr 2025 10:49:55 +0300, Dmitry Baryshkov wrote:
> Add support for the Mobile Display SubSystem (MDSS) device present on
> the Qualcomm SAR2130P platform. The MDSS device is similar to SM8550, it
> features two MIPI DSI controllers, two MIPI DSI PHYs and one DisplayPort
> controller.
>
On Fri, 25 Apr 2025 22:49:07 +0300, Dmitry Baryshkov wrote:
> It is easy to skip or ignore the fact that the default SSPP feature
> masks for SDM845+ don't include the SmartDMA bit (both during
> development and during the review stage).
>
> Enable SmartDMA on SC8180X, SC8280XP, SM8150 and SM855
On Tue, 08 Apr 2025 16:54:24 +0300, Dmitry Baryshkov wrote:
> HDMI standards define a recommended set of values to be used for Audio
> Clock Regeneration. Nevertheless, each HDMI driver dealing with audio
> implements its own way to determine those values. Implement a common
> helper and use it f
On Wed, Apr 23, 2025 at 8:28 PM Haoxiang Li wrote:
>
> The memory allocated by msm_fence_alloc() actually is the
> container of msm_fence_alloc()'s return value. Thus, just
> free its return value is not enough.
> Add a helper 'msm_fence_free()' in msm_fence.h/msm_fence.c
> to do the complete job.
Hi Prabhakar,
Thanks for the patch.
> -Original Message-
> From: Prabhakar
> Sent: 30 April 2025 21:41
> Subject: [PATCH v4 12/15] drm: renesas: rz-du: mipi_dsi: Add dphy_late_init()
> callback for RZ/V2H(P)
>
> From: Lad Prabhakar
>
> Introduce the `dphy_late_init` callback in `rzg2
Hi Prabhakar,
Thanks for the patch.
> -Original Message-
> From: Prabhakar
> Sent: 30 April 2025 21:41
> Subject: [PATCH v4 14/15] drm: renesas: rz-du: mipi_dsi: Add support for
> LPCLK handling
>
> From: Lad Prabhakar
>
> Introduce the `RZ_MIPI_DSI_FEATURE_LPCLK` feature flag in
>
Hi Prabhakar,
Thanks for the patch.
> -Original Message-
> From: Prabhakar
> Sent: 30 April 2025 21:41
> Subject: [PATCH v4 13/15] drm: renesas: rz-du: mipi_dsi: Add function
> pointers for configuring VCLK
> and mode validation
>
> From: Lad Prabhakar
>
> Introduce `dphy_conf_clks`
Hi Prabhakar,
Thanks for the patch.
> -Original Message-
> From: Prabhakar
> Sent: 30 April 2025 21:41
> Subject: [PATCH v4 11/15] drm: renesas: rz-du: mipi_dsi: Add feature flag for
> 16BPP support
>
> From: Lad Prabhakar
>
> Introduce the `RZ_MIPI_DSI_FEATURE_16BPP` flag in `rzg2l_
Hi Prabhakar,
Thanks for the patch.
> -Original Message-
> From: Prabhakar
> Sent: 30 April 2025 21:41
> Subject: [PATCH v4 10/15] drm: renesas: rz-du: mipi_dsi: Use mHz for D-PHY
> frequency calculations
>
> From: Lad Prabhakar
>
> Pass the HSFREQ in milli-Hz to the `dphy_init()` ca
Hi Prabhakar,
> -Original Message-
> From: Prabhakar
> Sent: 30 April 2025 21:41
> Subject: [PATCH v4 09/15] drm: renesas: rz-du: mipi_dsi: Add OF data support
>
> From: Lad Prabhakar
>
> In preparation for adding support for the Renesas RZ/V2H(P) SoC, this patch
> introduces a mechan
Hi Prabhakar,
> -Original Message-
> From: Prabhakar
> Sent: 30 April 2025 21:41
> Subject: [PATCH v4 08/15] drm: renesas: rz-du: mipi_dsi: Use VCLK for HSFREQ
> calculation
>
> From: Lad Prabhakar
>
> Update the RZ/G2L MIPI DSI driver to calculate HSFREQ using the actual VCLK
> rate
On Tue, 22 Apr 2025 15:04:39 +0800, Andy Yan wrote:
> When preparing to convert the current inno hdmi driver into a
> bridge driver, I found that there are several issues currently
> existing with it:
>
> 1. When the system starts up, the first time it reads the EDID, it
>will fail. This is
On Mon, 28 Apr 2025 18:23:07 +0800, Andy Yan wrote:
> Convert it to drm bridge driver, it will be convenient for us to
> migrate the connector part to the display driver later.
>
> Note: I don't have the hardware to test this driver, so for now
> I can only do the compilation test.
>
>
> [...]
The major of dcn and dce irqs share a copy-pasted collection
of copy-pasted function, which is: hpd_ack.
This patch removes the multiple copy-pasted by moving them to
the irq_service.c and make the irq_service's
calls the functions implemented by the irq_service.c
instead.
The hpd_ack function is
60 matches
Mail list logo
