On Tue, May 13, 2025 at 12:18:44PM +0200, Gerd Hoffmann wrote:
> > > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
> > > b/drivers/gpu/drm/virtio/virtgpu_drv.c
> > > index e32e680c7197..71c6ccad4b99 100644
> > > --- a/drivers/gpu/drm/virtio/virtgpu_drv.c
> > > +++ b/drivers/gpu/drm/virtio/virt
On Mon, May 12, 2025 at 05:34:35PM -0300, André Almeida wrote:
> When a device get wedged, it might be caused by a guilty application.
> For userspace, knowing which app was the cause can be useful for some
> situations, like for implementing a policy, logs or for giving a chance
> for the composit
On Fri, May 16, 2025 at 6:52 PM Ryan Walklin wrote:
>
> From: Jernej Skrabec
>
> The H616 (and related SoC packages sharing the same die) carry the new
> DE33 display engine.
>
> Add the mixer configuration and a compatible string for the H616 to the
> mixer.
>
> Signed-off-by: Jernej Skrabec
>
On Fri, May 16, 2025 at 6:51 PM Ryan Walklin wrote:
>
> From: Jernej Skrabec
>
> Now that the DE variant can be selected by enum, take the oppportunity
> to factor out some common initialisation code to a separate function.
>
> Signed-off-by: Jernej Skrabec
> Signed-off-by: Ryan Walklin
> Revie
gt; - Add top/disp regmaps to mixer for DE33
> - Remove YUV-specific code
> - Remove use of global double buffer
> - Remove unneeded if/then parentheses and fix an alignment issue as suggested
> by checkpatch.pl
>
> Changelog v9..v10:
> - Use names from vendor BSP kernel for register
On Fri, May 16, 2025 at 6:52 PM Ryan Walklin wrote:
>
> From: Jernej Skrabec
>
> The vi_scaler appears to be used in preference to the ui_scaler module
> for hardware video scaling in the DE33.
>
> Enable support for this scaler.
>
> Signed-off-by: Jernej Skrabec
> Signed-off-by: Ryan Walklin
>
On Fri, May 16, 2025 at 6:52 PM Ryan Walklin wrote:
>
> From: Jernej Skrabec
>
> The DE33 is a newer version of the Allwinner Display Engine IP block,
> found in the H616, H618, H700 and T507 SoCs. DE2 and DE3 are already
> supported by the mainline driver.
>
> Notable features (from the H616 dat
On Fri, May 16, 2025 at 6:52 PM Ryan Walklin wrote:
>
> From: Jernej Skrabec
>
> Use the new blender register lookup function where required in the layer
> commit and update code.
>
> Signed-off-by: Jernej Skrabec
> Signed-off-by: Ryan Walklin
> Acked-by: Maxime Ripard
Reviewed-by: Chen-Yu Ts
dding a function to look the blender reference up,
> with a subsequent patch to add a conditional based on the DE type.
>
> Signed-off-by: Jernej Skrabec
> Signed-off-by: Ryan Walklin
> Acked-by: Maxime Ripard
Reviewed-by: Chen-Yu Tsai
On Fri, May 16, 2025 at 6:51 PM Ryan Walklin wrote:
>
> From: Jernej Skrabec
>
> The Allwinner DE2 and DE3 display engine mixers are currently identified
> by a simple boolean flag. This will not scale to support additional DE
> variants.
>
> Convert the boolean flag to an enum.
>
> Signed-off-by
On Sat, May 17, 2025 at 07:32:44PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> It's only necessary for some lower end parts.
> Also rename it to min_acc_len_64b to denote that if set, the minimum
> access length is 64 bits, 32b otherwise.
>
> Signed-off-by: Konrad Dybcio
> ---
> driv
From: Dmitry Baryshkov
Move several misnamed functions accessing AUX bus to dp_aux.c, further
cleaning up dp_catalog submodule.
Reviewed-by: Stephen Boyd
Tested-by: Stephen Boyd # sc7180-trogdor
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_aux.c | 94
From: Dmitry Baryshkov
Move all register-level functions to dp_aux.c, inlining one line
wrappers during this process.
Reviewed-by: Stephen Boyd
Tested-by: Stephen Boyd # sc7180-trogdor
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_aux.c | 96 ++
From: Dmitry Baryshkov
Move CTRL-related functions to dp_ctrl.c, inlining one line wrappers
during this process. The enable/disable functions have been split to the
enable/disable or enter/exit pairs. The IRQ and HPD related functions
are left in dp_catalog.c, pending later cleanup.
Reviewed-by:
From: Dmitry Baryshkov
Having I/O regions inside a msm_dp_catalog_private() results in extra
layers of one-line wrappers for accessing the data. Move I/O region base
and size to the globally visible struct msm_dp_catalog.
Reviewed-by: Stephen Boyd
Tested-by: Stephen Boyd # sc7180-trogdor
Signe
From: Dmitry Baryshkov
Now as the msm_dp_catalog module became nearly empty, drop it, accessing
registers directly from the corresponding submodules.
Reviewed-by: Stephen Boyd
Tested-by: Stephen Boyd # sc7180-trogdor
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Dmitry Baryshkov
---
driver
From: Dmitry Baryshkov
There is little point in rereading DP controller revision over and over
again. Read it once, after the first software reset.
Reviewed-by: Stephen Boyd
Tested-by: Stephen Boyd # sc7180-trogdor
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 29
From: Dmitry Baryshkov
It makes it easier to keep all interrupts-related code in dp_ctrl
submodule. Move all functions to dp_ctrl.c.
Reviewed-by: Stephen Boyd
Tested-by: Stephen Boyd # sc7180-trogdor
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_aux.c | 9 +--
drivers/g
From: Dmitry Baryshkov
It's the dp_panel's duty to clear the MMSS_DP_DSC_DTO register. Once DP
driver gets DSC support, it will handle that register in other places
too. Split a call to write 0x0 to that register to a separate function.
Reviewed-by: Stephen Boyd
Tested-by: Stephen Boyd # sc718
-audio-fixup-v5-0-370f09492...@linaro.org
Changes in v5:
- Dropped applied patches.
- Removed MMSS_DP_DSC_DTO programming from msm_dp_catalog_ctrl_config_msa()
(Abhinav)
- Pulled the hw_revision patch closer to the top of the series (Abhinav)
- Link to v4:
https://lore.kernel.org/r/20241216-fd-dp
From: Dmitry Baryshkov
Move audio-related functions to dp_audio.c, following up the cleanup
done by the rest of the submodules. Inline functions with simple
register access patterns.
Reviewed-by: Stephen Boyd
Tested-by: Stephen Boyd # sc7180-trogdor
Signed-off-by: Dmitry Baryshkov
---
driver
From: Dmitry Baryshkov
Move panel-related functions to dp_panel.c, following up the cleanup
done by the rest of the submodules.
Reviewed-by: Stephen Boyd
Tested-by: Stephen Boyd # sc7180-trogdor
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 195 ---
From: Dmitry Baryshkov
Move msm_dp_read()/msm_write_foo() functions to the dp_catalog.h,
allowing other modules to access the data directly.
Reviewed-by: Stephen Boyd
Tested-by: Stephen Boyd # sc7180-trogdor
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 65 ---
Both perf and hangrd make sense only for GPU devices. Bail out if we are
registering a KMS-only device.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_debugfs.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_debugfs.c
b/drivers/gpu/drm/msm/msm_debu
On Sat, May 17, 2025 at 12:54:32PM +0530, Ekansh Gupta wrote:
> During rpmsg_probe, fastrpc device nodes are created first, then
> channel specific resources are initialized, followed by
> of_platform_populate, which triggers context bank probing. This
> sequence can cause issues as applications mi
Currently the msm driver creates an extra interim platform device for
Imageon GPUs. This is not ideal, as the device doesn't have
corresponding OF node. If the headless mode is used for newer GPUs, then
the msm_use_mmu() function can not detect corresponding IOMMU devices.
Also the DRM device (alth
Currently the KMS and GPU parts of the msm driver are pretty much
intertwined. It is impossible to register a KMS-only device and
registering a GPU-only DRM device requires modifying the DT. Not to
mention that binding the GPU-only device creates an interim platform
devices, which complicates IOMM
On Wed, May 07, 2025 at 09:45:26AM -0700, Rob Clark wrote:
> On Sat, May 3, 2025 at 12:17 AM Dmitry Baryshkov
> wrote:
> >
> > Some of the platforms don't have onboard GPU or don't provide support
> > for the GPU in the drm/msm driver. Make it possible to disable the GPU
> > part of the driver and
Some of the platforms don't have onboard GPU or don't provide support
for the GPU in the drm/msm driver. Make it possible to disable the GPU
part of the driver and build the KMS-only part.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Kconfig | 25 +--
drivers/gpu/drm/ms
There are cases when we want to have separate DRM devices for GPU and
display pipelines.
One example is development, when it is beneficial to be able to bind the
GPU driver separately, without the display pipeline (and without the
hacks adding "amd,imageon" to the compatible string).
Another exampl
Move symbol selection to be more fine grained: select DP helpers only if
DP driver is also enabled, move KMS and display helpers to the newly
introduced DRM_MSM_KMS.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Kconfig | 20 ++--
1 file changed, 10 insertions(+), 10 de
Extract two more KMS-related codepieces to msm_kms.c, removing last
pieces of KMS code from msm_drv.c.
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_drv.c | 9 +++--
drivers/gpu/drm/msm/msm_kms.c | 20
drivers/gpu/drm/msm/msm_km
If the Adreno device is used in a headless mode, there is no need to
build all KMS components. Build corresponding parts conditionally, only
selecting them if modeset support is actually required.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Kconfig | 14 +
drivers/gp
There is no reason to store CRTC id, it's a part of the drm_crtc. Drop
this member and use drm_crtc.name for the warning message.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 7 ++-
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 2 +-
drivers/gpu/drm/msm/disp/
Data for HDMI, DSI and DP blocks only makes sense for the KMS parts of
the driver. Move corresponding data pointers from struct msm_drm_private
to struct msm_kms.
Suggested-by: Abhinav Kumar
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 11
dri
Drop superfluous msm_drm_private::num_crtcs in favour of using
drm_mode_config::num_crtc or MAX_CRCS as appropriate.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +--
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 3 ---
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c |
The global workqueue is only used for vblanks inside KMS code. Move
allocation / flushing / deallcation of it to msm_kms.c
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 2 +-
drivers/gpu/drm/msm/disp/mdp5/m
On Sat, May 17, 2025 at 07:32:48PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> Now that Adreno specifics are out of the way, use the common config
> (but leave the HBB hardcoding in place until that is wired up on the
> other side).
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gp
On Sat, May 17, 2025 at 07:32:47PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> The UBWC 1.0 case is easy - it must be all 3 enabled.
> UBWC2.0 and 3.x require that level1 is removed, follow suit.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/soc/qcom/ubwc_config.c | 18 +++
On Sat, May 17, 2025 at 07:32:46PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> Make the values a bit more meaningful.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/soc/qcom/ubwc_config.c | 37 +
> include/linux/soc/qcom/ubwc.h | 8
>
On Sat, May 17, 2025 at 07:32:45PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> The value of 7 (a.k.a. GENMASK(2, 0), a.k.a. disabling levels 1-3 of
> swizzling) is what we want on this platform (and others with a UBWC
> 1.0 encoder).
>
> Fix it to make mesa happy (the hardware doesn't
On Sat, May 17, 2025 at 07:32:43PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> It's supposed to be on when the UBWC encoder version is >= 4.0.
> Drop the per-GPU assignments.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 7 ++-
> 1 file changed,
On Sat, May 17, 2025 at 07:32:42PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> ubwc_swizzle is a bitmask. Check for a bit to make it more obvious.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
On Sat, May 17, 2025 at 07:32:41PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> This bit is set iff the UBWC version is 1.0. That notably does not
> include QCM2290's "no UBWC".
>
> This commit is intentionally cross-subsystem to ease review, as the
> patchset is intended to be merged t
On Sat, May 17, 2025 at 07:32:40PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> Instead of setting it on a gpu-per-gpu basis, converge it to the
> intended "is A650 family or A7xx".
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 15 ++-
>
On Sat, May 17, 2025 at 07:32:39PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> The bit must be set to 1 if the UBWC encoder version is >= 3.0, drop it
> as a separate field.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 12 +++-
> 1 file cha
On Sat, May 17, 2025 at 07:32:38PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> Start the great despaghettification by getting a pointer to the common
> UBWC configuration, which houses e.g. UBWC versions that we need to
> make decisions.
>
> Signed-off-by: Konrad Dybcio
> ---
> drive
On Sat, May 17, 2025 at 07:32:37PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> As discussed a lot in the past, the UBWC config must be coherent across
> a number of IP blocks (currently display and GPU, but it also may/will
> concern camera/video as the drivers evolve).
>
> So far, we'
er: GPL-2.0-only */
> +/*
> + * Copyright (c) 2018, The Linux Foundation
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#ifndef __QCOM_UBWC_H__
> +#define __QCOM_UBWC_H__
> +
> +#include
> +#include
> +
> +struct qcom_u
On Sat, May 17, 2025 at 07:32:36PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> The Adreno part of the driver exposes this value to userspace, and the
> SMEM data source also presents a x+13 value. Keep things coherent and
> make the value uniform across them.
>
> Signed-off-by: Konrad
: edef457004774e598fc4c1b7d1d4f0bcd9d0bb30
patch link:
https://lore.kernel.org/r/20250517-topic-ubwc_central-v3-4-3c8465565f86%40oss.qualcomm.com
patch subject: [PATCH RFT v3 04/14] drm/msm/a6xx: Get a handle to the common
UBWC config
config: arm64-randconfig-004-20250518
(https://download.01.org/0day-ci/archive/20250518
> We can always make the property mutable on drivers that support it in
> the future, much like the zpos property. I think we should keep it
> immutable for now.
Sure, but I don't see any reason for immutability with an enum
property - it can just limit the possible values to what it supports,
and
On 5/17/25 2:22 AM, Xaver Hugl wrote:
Am Do., 27. März 2025 um 00:58 Uhr schrieb Alex Hung :
It is to be used to enable HDR by allowing userpace to create and pass
3D LUTs to kernel and hardware.
new drm_colorop_type: DRM_COLOROP_3D_LUT.
Signed-off-by: Alex Hung
---
v8:
- Fix typo in subj
Do not create a custom directory in debugfs-root, but use the
debugfs_init callback to create a custom directory at the given place
for the bridge.
Signed-off-by: Wolfram Sang
Reviewed-by: Dmitry Baryshkov
---
Changes since v2:
* added tag from Dmitry (thanks!)
No code changes, but the thread
From: Konrad Dybcio
The bit must be set to 1 if the UBWC encoder version is >= 3.0, drop it
as a separate field.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6
From: Konrad Dybcio
As discussed a lot in the past, the UBWC config must be coherent across
a number of IP blocks (currently display and GPU, but it also may/will
concern camera/video as the drivers evolve).
So far, we've been trying to keep the values reasonable in each of the
two drivers separ
From: Konrad Dybcio
Now that Adreno specifics are out of the way, use the common config
(but leave the HBB hardcoding in place until that is wired up on the
other side).
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 20 -
drivers/gpu/drm/msm/adreno/a6xx_gpu
From: Konrad Dybcio
Make the values a bit more meaningful.
Signed-off-by: Konrad Dybcio
---
drivers/soc/qcom/ubwc_config.c | 37 +
include/linux/soc/qcom/ubwc.h | 8
2 files changed, 29 insertions(+), 16 deletions(-)
diff --git a/drivers/soc/qcom
From: Konrad Dybcio
The UBWC 1.0 case is easy - it must be all 3 enabled.
UBWC2.0 and 3.x require that level1 is removed, follow suit.
Signed-off-by: Konrad Dybcio
---
drivers/soc/qcom/ubwc_config.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/soc/qcom/ubwc_c
From: Konrad Dybcio
ubwc_swizzle is a bitmask. Check for a bit to make it more obvious.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno
From: Konrad Dybcio
It's only necessary for some lower end parts.
Also rename it to min_acc_len_64b to denote that if set, the minimum
access length is 64 bits, 32b otherwise.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 18 +-
1 file changed, 9 inse
From: Konrad Dybcio
The value of 7 (a.k.a. GENMASK(2, 0), a.k.a. disabling levels 1-3 of
swizzling) is what we want on this platform (and others with a UBWC
1.0 encoder).
Fix it to make mesa happy (the hardware doesn't care about the 2 higher
bits, as they weren't consumed on this platform).
Si
From: Konrad Dybcio
Start the great despaghettification by getting a pointer to the common
UBWC configuration, which houses e.g. UBWC versions that we need to
make decisions.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 16 ++--
drivers/gpu/drm/msm/adr
From: Konrad Dybcio
It's supposed to be on when the UBWC encoder version is >= 4.0.
Drop the per-GPU assignments.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gp
From: Konrad Dybcio
This bit is set iff the UBWC version is 1.0. That notably does not
include QCM2290's "no UBWC".
This commit is intentionally cross-subsystem to ease review, as the
patchset is intended to be merged together, with a maintainer
consensus.
Signed-off-by: Konrad Dybcio
---
dri
From: Konrad Dybcio
The Adreno part of the driver exposes this value to userspace, and the
SMEM data source also presents a x+13 value. Keep things coherent and
make the value uniform across them.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/msm_mdss.c | 50 +---
From: Konrad Dybcio
Add a file that will serve as a single source of truth for UBWC
configuration data for various multimedia blocks.
Signed-off-by: Konrad Dybcio
---
drivers/soc/qcom/Kconfig | 8 ++
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/ubwc_config.c | 236 +
From: Konrad Dybcio
Instead of setting it on a gpu-per-gpu basis, converge it to the
intended "is A650 family or A7xx".
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm
break userspace abi (hbb value)
- Don't keep mdss_reg_bus_bw in ubwc_config
- Add the last patch warning if there are inconsistencies (I don't
insist on it getting merged, but I think it's a good idea for the
time being)
- Link to v1:
https://lore.kernel.org/r/20250508-topic-ubwc
Good morning Alex,
I just resend the patch with the name I`ve been suggesting, please let me
know if you have any recommendation.
And thanks again for your reply 😄
Leonardo Gomes
Em sex., 16 de mai. de 2025 às 13:56, Alex Deucher
escreveu:
> On Thu, May 15, 2025 at 9:23 PM Leonardo Go
Adjust get_value function in hw_hpd.c file to have
prefix to help in ftrace, the name change from
'get_value' to 'dal_hw_hpd_get_value'
Signed-off-by: Leonardo da Silva Gomes
Co-developed-by: Derick Frias
Signed-off-by: Derick Frias
---
drivers/gpu/drm/amd/display/dc/gpio/hw_hpd.c | 4 ++--
1
Adjust set_value function in hw_hpd.c file to have
prefix to help in ftrace, the name change from
'set_value' to 'dal_hw_hpd_set_value'
Signed-off-by: Leonardo da Silva Gomes
Co-developed-by: Derick Frias
Signed-off-by: Derick Frias
---
drivers/gpu/drm/amd/display/dc/gpio/hw_hpd.c | 4 ++--
1
crate::gpu::Chipset;
>> +use crate::regs;
>> +
>> +fn align_down(value: u64, align: u64) -> u64 {
>> +value & !(align - 1)
>> +}
>
> Can this go in the previous patch, i.e. "rust: num: Add an upward alignment
> helper for usize"?
Yes, let me tr
Several style and robustness fixes suggested in the mailing list.
> - Added patches from Nicolas Frattaroli that add support to the NPU for
> the Rock 5B board.
> - Link to v2:
> https://lore.kernel.org/r/20250225-6-10-rocket-v2-0-d4dbcfafc...@tomeuvizoso.net
>
> Changes in v2
On Saturday, May 17th, 2025 at 03:23, Xaver Hugl wrote:
> Do we ever expect this to be something with multiple options that
> userspace could select? I think it would be good to keep our options
> open and make this property not immutable (properties that are
> sometimes but not always immutable
Am Do., 15. Mai 2025 um 22:00 Uhr schrieb Leandro Ribeiro
:
>
>
>
> On 5/15/25 15:39, Daniel Stone wrote:
> > Hi,
> >
> > On Thu, 15 May 2025 at 19:02, Harry Wentland wrote:
> >> On 2025-05-15 13:19, Daniel Stone wrote:
> >>> Yeah, the Weston patches are marching on. We've still been doing a
> >>>
"ENABLE" is currently misspelled in SYS_INFO_GPUCAPS__ENABEL_DFS_BYPASS
PS: checkpatch.pl is complaining about the presence of a space at the
start of drivers/gpu/drm/amd/include/atomfirmware.h line: 1716
This is propably because this file uses (two) spaces and not tabs.
Signed-off-by: Jihed Cha
Jihed Chaibi , 17 May 2025 Cmt, 06:06
tarihinde şunu yazdı:
>
> "ENABLE" is currently misspelled in SYS_INFO_GPUCAPS__ENABEL_DFS_BYPASS
>
> PS: checkpatch.pl is complaining about the presence of a space at the
> start of drivers/gpu/drm/amd/include/atomfirmware.h line: 1716
> This is propably becau
"ENABLE" is currently misspelled in SYS_INFO_GPUCAPS__ENABEL_DFS_BYPASS
Signed-off-by: Jihed Chaibi
---
drivers/gpu/drm/radeon/atombios.h | 2 +-
drivers/gpu/drm/radeon/kv_dpm.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios.h
b/drivers/
Jihed Chaibi , 17 May 2025 Cmt, 06:09
tarihinde şunu yazdı:
>
> "ENABLE" is currently misspelled in SYS_INFO_GPUCAPS__ENABEL_DFS_BYPASS
>
i didnt see this and yes *grph_object_ctrl_defs.h* is exactly what i'm
talking about, please ignore my previous email.
Regards
Ozgur
> Signed-off-by: Jihed C
Fix double 'u' in 'frequuency'
Signed-off-by: Daniil Ryabov
---
drivers/gpu/drm/amd/display/dc/basics/dce_calcs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/basics/dce_calcs.c
b/drivers/gpu/drm/amd/display/dc/basics/dce_calcs.c
index 6
On Fri, May 16, 2025 at 01:09:19PM -0400, Lyude Paul wrote:
> Drive-by fix, it doesn't seem like anything actually uses this constant
> anymore.
>
> Signed-off-by: Lyude Paul
Reviewed-by: Danilo Krummrich
On Fri, May 16, 2025 at 01:09:18PM -0400, Lyude Paul wrote:
> Just to reduce the clutter with the File<…> types in gem.rs.
>
> Signed-off-by: Lyude Paul
> ---
> rust/kernel/drm/gem/mod.rs | 26 ++
> 1 file changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/rust/
On Fri, May 16, 2025 at 01:09:17PM -0400, Lyude Paul wrote:
> Now that we've cleaned up the generics for gem objects a bit, we're still
> left with a bit of generic soup around referring to the Object
> implementation for a given driver. Let's clean this up a bit by re-using
> the DriverObject iden
On Fri, May 16, 2025 at 01:09:15PM -0400, Lyude Paul wrote:
> Look mom, no generic soup!
>
> Anyway - this is just the last of the cleanup stuff I ended up while
> working on cleaning up the gem shmem patch series. It simplifies the use
> of generics and also adds a type alias for
: 96c85e428ebaeacd2c640eba075479ab92072ccd
patch link:
https://lore.kernel.org/r/7005fb2eba3abbb2ee95282d117f70c8a7c8555f.1747148172.git.lukas.zapolskas%40arm.com
patch subject: [PATCH v4 5/7] drm/panthor: Implement the counter sampler and
sample handling
config: i386-buildonly-randconfig-002-20250517
(https://download
: 96c85e428ebaeacd2c640eba075479ab92072ccd
patch link:
https://lore.kernel.org/r/0319137f966f2dbffc54e51f7a2a3cbac837507b.1747148172.git.lukas.zapolskas%40arm.com
patch subject: [PATCH v4 4/7] drm/panthor: Introduce sampling sessions to
handle userspace clients
config: i386-buildonly-randconfig-002-20250517
(https
During rpmsg_probe, fastrpc device nodes are created first, then
channel specific resources are initialized, followed by
of_platform_populate, which triggers context bank probing. This
sequence can cause issues as applications might open the device
node before channel resources are initialized or t
d wbinvd_on_cpu(int cpu);
+void wbinvd_on_cpumask(struct cpumask *cpus);
void wbinvd_on_all_cpus(void);
And the wb*invd_all_cpus() methods should probably be inlined wrappers
with -1 as the cpumask, or so - not two separate functions?
In fact it would be nice to have the DRM preparatory p
* Sean Christopherson wrote:
> Drop wbinvd_on_all_cpus()'s return value; both the "real" version and the
> stub always return '0', and none of the callers check the return.
>
> Signed-off-by: Sean Christopherson
> ---
> arch/x86/include/asm/smp.h | 5 ++---
> arch/x86/lib/cache-smp.c | 3 +
* Sean Christopherson wrote:
> From: Kevin Loughlin
>
> In line with WBINVD usage, add WBONINVD helper functions. Fall back to
> WBINVD (via alternative()) if WBNOINVD isn't supported, as WBINVD provides
> a superset of functionality, just more slowly.
>
> Note, alternative() ensures compat
Rewrite the ADV7511 driver to use implementation provided by the DRM
HDMI connector framework, including the Audio and CEC bits. Drop the
in-bridge connector support and use drm_bridge_connector if the host
requires the connector to be provided by the bridge.
Note: currently only AVI InfoFrames ar
On Fri, May 16, 2025 at 09:49:53AM -0300, Jason Gunthorpe wrote:
> On Fri, May 16, 2025 at 02:19:45PM +0800, Xu Yilun wrote:
> > > I don't know why you'd disable a viommu while the VM is running,
> > > doesn't make sense.
> >
> > Here it means remove the CC setup for viommu, shared setup is still
Switch VC4 driver to using CEC helpers code, simplifying hotplug and
registration / cleanup. The existing vc4_hdmi_cec_release() is kept for
now.
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/vc4/Kconfig| 1 +
drivers/gpu/drm/vc4/vc4_hdmi.c | 137
As a preparation to adding HDMI CEC helper code, add CEC-related fields
to the struct drm_connector. The callbacks abstract CEC infrastructure
in order to support CEC adapters and CEC notifiers in a universal way.
CEC data is a void pointer as it allows us to make CEC data
helper-specific. For exa
THe Kconfig symbol DRM_DISPLAY_DP_AUX_CEC is a boolean which simply
toggles whether DP_AUX_CEC support should be built into the
drm_display_helper (which can be eithera module or built-in into the
kernel). If DRM_DISPLAY_DP_AUX_CEC is selected, then CEC_CORE is
selected to be built-in into the kern
mentation for @hdmi_audio_i2s_formats to describe default
behaviour.
- Split drm_connector_cleanup() patch from the patch adding CEC-related
data structures (Maxime).
- Documented that CEC mutex protects all data fields in struct
drm_connector_cec (Maxime).
- Improved drm_connector_cec_funcs.unregis
WHen adding HDMI fields I didn't notice the private: declaration for HPD
fields. Move private fields to the end of the struct drm_bride to have
clear distinction between private and public fields.
Reviewed-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Dmitry Baryshkov
---
in
Allow HDMI DRM bridges to create CEC notifier. Physical address is
handled automatically by drm_atomic_helper_connector_hdmi_hotplug()
being called from .detect() path.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_br
Implement necessary glue code to let DRM bridge drivers to implement CEC
adapters support.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/Kconfig| 1 +
drivers/gpu/drm/display/drm_bridge_connector.c | 83 +
1 - 100 of 64581 matches
Mail list logo
