Hi Lukas,
kernel test robot noticed the following build errors:
[auto build test ERROR on 96c85e428ebaeacd2c640eba075479ab92072ccd]
url:
https://github.com/intel-lab-lkp/linux/commits/Lukas-Zapolskas/drm-panthor-Add-performance-counter-uAPI/20250517-000257
base
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
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
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 +---
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 separately, but it really m
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
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
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
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
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
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
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
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
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
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
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
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
On Wed May 14, 2025 at 1:41 AM JST, Danilo Krummrich wrote:
>> diff --git a/drivers/gpu/nova-core/gsp/fb.rs
>> b/drivers/gpu/nova-core/gsp/fb.rs
>> new file mode 100644
>> index
>> ..f28ded59469d52daf39e5d19c09efd7bf08fee92
>> --- /dev/null
>> +++ b/driver
On Fri, 16 May 2025 18:53:14 +0200, Tomeu Vizoso wrote:
> This series adds a new driver for the NPU that Rockchip includes in its
> newer SoCs, developed by them on the NVDLA base.
>
> In its current form, it supports the specific NPU in the RK3588 SoC.
>
> The userspace driver is part of Mesa
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
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
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 Gomes
> wr
* Sean Christopherson wrote:
> From: Zheyun Shen
>
> Extract KVM's open-coded calls to do writeback caches on multiple CPUs to
> common library helpers for both WBINVD and WBNOINVD (KVM will use both).
> Put the onus on the caller to check for a non-empty mask to simplify the
> SMP=n implemen
Hi Lukas,
kernel test robot noticed the following build errors:
[auto build test ERROR on 96c85e428ebaeacd2c640eba075479ab92072ccd]
url:
https://github.com/intel-lab-lkp/linux/commits/Lukas-Zapolskas/drm-panthor-Add-performance-counter-uAPI/20250517-000257
base
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 some very long t
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: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: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
"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
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
"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
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
Hello all,
The Board of Directors election concluded at 23:59 UTC on 14 May 2025.
For this election, we had 77 members who could cast a vote. 72 did, so
the turnout was 92.5%. This is the 3rd highest turnout in the last 10
elections, with only 2021 (93.8%) and 2016 (98.8%) being higher. It is
also
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
> >>>
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
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
> 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
: 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
40 matches
Mail list logo
