Re: [PATCH] drm/amdgpu: Fix recursive locking warning
Am 04.02.22 um 04:11 schrieb Rajneesh Bhardwaj:
Noticed the below warning while running a pytorch workload on vega10
GPUs. Change to trylock to avoid conflicts with already held reservation
locks.
[ +0.03] WARNING: possible recursive locking detected
[ +0.03] 5.13.0-kfd-rajneesh #1030 Not tainted
[ +0.04]
[ +0.02] python/4822 is trying to acquire lock:
[ +0.04] 932cd9a259f8 (reservation_ww_class_mutex){+.+.}-{3:3},
at: amdgpu_bo_release_notify+0xc4/0x160 [amdgpu]
[ +0.000203]
but task is already holding lock:
[ +0.03] 932cbb7181f8 (reservation_ww_class_mutex){+.+.}-{3:3},
at: ttm_eu_reserve_buffers+0x270/0x470 [ttm]
[ +0.17]
other info that might help us debug this:
[ +0.02] Possible unsafe locking scenario:
[ +0.03]CPU0
[ +0.02]
[ +0.02] lock(reservation_ww_class_mutex);
[ +0.04] lock(reservation_ww_class_mutex);
[ +0.03]
*** DEADLOCK ***
[ +0.02] May be due to missing lock nesting notation
[ +0.03] 7 locks held by python/4822:
[ +0.03] #0: 932c4ac028d0 (>mutex){+.+.}-{3:3}, at:
kfd_ioctl_map_memory_to_gpu+0x10b/0x320 [amdgpu]
[ +0.000232] #1: 932c55e830a8 (>lock#2){+.+.}-{3:3}, at:
amdgpu_amdkfd_gpuvm_map_memory_to_gpu+0x64/0xf60 [amdgpu]
[ +0.000241] #2: 932cc45b5e68 (&(*mem)->lock){+.+.}-{3:3}, at:
amdgpu_amdkfd_gpuvm_map_memory_to_gpu+0xdf/0xf60 [amdgpu]
[ +0.000236] #3: b2b35606fd28
(reservation_ww_class_acquire){+.+.}-{0:0}, at:
amdgpu_amdkfd_gpuvm_map_memory_to_gpu+0x232/0xf60 [amdgpu]
[ +0.000235] #4: 932cbb7181f8
(reservation_ww_class_mutex){+.+.}-{3:3}, at:
ttm_eu_reserve_buffers+0x270/0x470 [ttm]
[ +0.15] #5: c045f700 (*(sspp++)){}-{0:0}, at:
drm_dev_enter+0x5/0xa0 [drm]
[ +0.38] #6: 932c52da7078 (>eviction_lock){+.+.}-{3:3},
at: amdgpu_vm_bo_update_mapping+0xd5/0x4f0 [amdgpu]
[ +0.000195]
stack backtrace:
[ +0.03] CPU: 11 PID: 4822 Comm: python Not tainted
5.13.0-kfd-rajneesh #1030
[ +0.05] Hardware name: GIGABYTE MZ01-CE0-00/MZ01-CE0-00, BIOS F02
08/29/2018
[ +0.03] Call Trace:
[ +0.03] dump_stack+0x6d/0x89
[ +0.10] __lock_acquire+0xb93/0x1a90
[ +0.09] lock_acquire+0x25d/0x2d0
[ +0.05] ? amdgpu_bo_release_notify+0xc4/0x160 [amdgpu]
[ +0.000184] ? lock_is_held_type+0xa2/0x110
[ +0.06] ? amdgpu_bo_release_notify+0xc4/0x160 [amdgpu]
[ +0.000184] __ww_mutex_lock.constprop.17+0xca/0x1060
[ +0.07] ? amdgpu_bo_release_notify+0xc4/0x160 [amdgpu]
[ +0.000183] ? lock_release+0x13f/0x270
[ +0.05] ? lock_is_held_type+0xa2/0x110
[ +0.06] ? amdgpu_bo_release_notify+0xc4/0x160 [amdgpu]
[ +0.000183] amdgpu_bo_release_notify+0xc4/0x160 [amdgpu]
[ +0.000185] ttm_bo_release+0x4c6/0x580 [ttm]
[ +0.10] amdgpu_bo_unref+0x1a/0x30 [amdgpu]
[ +0.000183] amdgpu_vm_free_table+0x76/0xa0 [amdgpu]
[ +0.000189] amdgpu_vm_free_pts+0xb8/0xf0 [amdgpu]
[ +0.000189] amdgpu_vm_update_ptes+0x411/0x770 [amdgpu]
[ +0.000191] amdgpu_vm_bo_update_mapping+0x324/0x4f0 [amdgpu]
[ +0.000191] amdgpu_vm_bo_update+0x251/0x610 [amdgpu]
[ +0.000191] update_gpuvm_pte+0xcc/0x290 [amdgpu]
[ +0.000229] ? amdgpu_vm_bo_map+0xd7/0x130 [amdgpu]
[ +0.000190] amdgpu_amdkfd_gpuvm_map_memory_to_gpu+0x912/0xf60
[amdgpu]
[ +0.000234] kfd_ioctl_map_memory_to_gpu+0x182/0x320 [amdgpu]
[ +0.000218] kfd_ioctl+0x2b9/0x600 [amdgpu]
[ +0.000216] ? kfd_ioctl_unmap_memory_from_gpu+0x270/0x270 [amdgpu]
[ +0.000216] ? lock_release+0x13f/0x270
[ +0.06] ? __fget_files+0x107/0x1e0
[ +0.07] __x64_sys_ioctl+0x8b/0xd0
[ +0.07] do_syscall_64+0x36/0x70
[ +0.04] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ +0.07] RIP: 0033:0x7fbff90a7317
[ +0.04] Code: b3 66 90 48 8b 05 71 4b 2d 00 64 c7 00 26 00 00 00
48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f
05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 41 4b 2d 00 f7 d8 64 89 01 48
[ +0.05] RSP: 002b:7fbe301fe648 EFLAGS: 0246 ORIG_RAX:
0010
[ +0.06] RAX: ffda RBX: 7fbcc402d820 RCX:
7fbff90a7317
[ +0.03] RDX: 7fbe301fe690 RSI: c0184b18 RDI:
0004
[ +0.03] RBP: 7fbe301fe690 R08: R09:
7fbcc402d880
[ +0.03] R10: 02001000 R11: 0246 R12:
c0184b18
[ +0.03] R13: 0004 R14: 7fbf689593a0 R15:
7fbcc402d820
Cc: Christian König
Cc: Felix Kuehling
Cc: Alex Deucher
Fixes: 627b92ef9d7c ("drm/amdgpu: Wipe all VRAM on free when RAS is
enabled")
Signed-off-by: Rajneesh Bhardwaj
The fixes tag is not necessarily correct, I would remove that.
But apart from that the patch is Reviewed-by: Christian König
.
Thanks,
Christian.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
[git pull] drm fixes for 5.17-rc3
Hi Linus, Regular fixes for the week. Daniel has agreed to bring back the fbcon hw acceleration under a CONFIG option for the non-drm fbdev users, we don't advise turning this on unless you are in the niche that is old fbdev drivers, Since it's essentially a revert and shouldn't be high impact seemed like a good time to do it now. Otherwise, i915 and amdgpu fixes are most of it, along with some minor fixes elsewhere. Dave. drm-fixes-2022-02-04: drm fixes for 5.17-rc3 fbdev: - readd fbcon acceleration i915: - fix DP monitor via type-c dock - fix for engine busyness and read timeout with GuC - use ALLOW_FAIL for error capture buffer allocs - don't use interruptible lock on error paths - smatch fix to reject zero sized overlays. amdgpu: - mGPU fan boost fix for beige goby - S0ix fixes - Cyan skillfish hang fix - DCN fixes for DCN 3.1 - DCN fixes for DCN 3.01 - Apple retina panel fix - ttm logic inversion fix dma-buf: - heaps: fix potential spectre v1 gadget kmb: - fix potential oob access mxsfb: - fix NULL ptr deref nouveau: - fix potential oob access during BIOS decode The following changes since commit 26291c54e111ff6ba87a164d85d4a4e134b7315c: Linux 5.17-rc2 (2022-01-30 15:37:07 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-02-04 for you to fetch changes up to 9ca3d3cd0857523c95ab8cdbb6cfe47b8f90e309: Merge tag 'drm-intel-fixes-2022-02-03' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2022-02-04 15:48:27 +1000) drm fixes for 5.17-rc3 fbdev: - readd fbcon acceleration i915: - fix DP monitor via type-c dock - fix for engine busyness and read timeout with GuC - use ALLOW_FAIL for error capture buffer allocs - don't use interruptible lock on error paths - smatch fix to reject zero sized overlays. amdgpu: - mGPU fan boost fix for beige goby - S0ix fixes - Cyan skillfish hang fix - DCN fixes for DCN 3.1 - DCN fixes for DCN 3.01 - Apple retina panel fix - ttm logic inversion fix dma-buf: - heaps: fix potential spectre v1 gadget kmb: - fix potential oob access mxsfb: - fix NULL ptr deref nouveau: - fix potential oob access during BIOS decode Agustin Gutierrez (1): drm/amd/display: Update watermark values for DCN301 Alexander Stein (1): drm: mxsfb: Fix NULL pointer dereference Anitha Chrisanthus (1): drm/kmb: Fix for build errors with Warray-bounds Aun-Ali Zaidi (1): drm/amd/display: Force link_rate as LINK_RATE_RBR2 for 2018 15" Apple Retina panels Christian König (1): drm/amdgpu: fix logic inversion in check Dan Carpenter (1): drm/i915/overlay: Prevent divide by zero bugs in scaling Dave Airlie (3): Merge tag 'amd-drm-fixes-5.17-2022-02-02' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Merge tag 'drm-misc-fixes-2022-02-03' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge tag 'drm-intel-fixes-2022-02-03' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Evan Quan (1): drm/amd/pm: correct the MGpuFanBoost support for Beige Goby Helge Deller (3): Revert "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)" Revert "fbcon: Disable accelerated scrolling" fbcon: Add option to enable legacy hardware acceleration Imre Deak (1): drm/i915/adlp: Fix TypeC PHY-ready status readout Jordy Zomer (1): dma-buf: heaps: Fix potential spectre v1 gadget Lang Yu (1): drm/amdgpu: fix a potential GPU hang on cyan skillfish Mario Limonciello (4): drm/amd: Warn users about potential s0ix problems drm/amd: add support to check whether the system is set to s3 drm/amd: Only run s3 or s0ix if system is configured properly drm/amd: avoid suspend on dGPUs w/ s2idle support when runtime PM enabled Matthew Brost (2): drm/i915: Allocate intel_engine_coredump_alloc with ALLOW_FAIL drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline Nick Lopez (1): drm/nouveau: fix off by one in BIOS boundary checking Paul Hsieh (1): drm/amd/display: watermark latencies is not enough on DCN31 Umesh Nerlige Ramappa (2): drm/i915/pmu: Use PM timestamp instead of RING TIMESTAMP for reference drm/i915/pmu: Fix KMD and GuC race on accessing busyness Zhan Liu (1): drm/amd/display: revert "Reset fifo after enable otg" Documentation/gpu/todo.rst | 24 - drivers/dma-buf/dma-heap.c | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu.h| 10 +- drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 37 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 11 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 2 +- drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 3 +
Re: Kconfig CONFIG_FB dependency regression
On 2/3/22 19:21, Thinh Nguyen wrote:
> Arnd Bergmann wrote:
>> On Thu, Feb 3, 2022 at 12:55 AM Thinh Nguyen
>> wrote:
>>> Arnd Bergmann wrote:
On Wed, Feb 2, 2022 at 1:14 AM Thinh Nguyen
wrote:
> Fabio Estevam wrote:
CONFIG_FB should not normally be needed for booting, so unless
you have a graphical application in your initramfs that requires the
/dev/fb0
device to work, it is not supposed to make a difference.
>>>
>>> I'm not sure, but it seems like the setup we have isn't the only one
>>> that needed it. Fabio also noted that the imx_v6_v7_defconfig also needs
>>> to have CONFIG_FB set.
>>
>> No, that one is different: the change for imx_v6_v7_defconfig was
>> done because they actually use a framebuffer console on some devices,
>> so the patch just adds the symbol to enable the drivers they are using.
>>
>> This is expected with my original patch that doesn't implicitly enable
>> the framebuffer layer any more. What is not expected is for the kernel
>> to hang during boot as you reported for your unidentified platform.
>>
Are there any other differences in your .config before and after the patch?
It's possible that you use some other driver that in turn depends on
CONFIG_FB. Does your machine have any graphical output device?
If yes, which driver do you use?
>>>
>>> I don't have the answer to those questions yet. Need more investigation.
>>> I'm new to this particular test setup.
>>
>> Do you mean you don't know if there is a screen attached to the system?
>>
>
> It does have a graphical output device, but I didn't check what it is or
> what driver is driving it. I just notice that after the reported commit,
> something stopped working.
>
You may also want to make sure that you have 9d6366e743f3 ("drm:
fb_helper: improve CONFIG_FB dependency") in your kernel, which
fixes a minor problem with my original patch.
>>>
>>> The issue also occurs in mainline, which has your minor fix commit
>>> above. The revert isn't clean for the latest kernel version. I also have
>>> to revert some of the changes along with CONFIG_FB. The revert looks
>>> more like this for the latest kernel:
>>>
>>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>>> index b1f22e457fd0..7cbc733a8569 100644
>>> --- a/drivers/gpu/drm/Kconfig
>>> +++ b/drivers/gpu/drm/Kconfig
>>> @@ -118,8 +118,9 @@ config DRM_DEBUG_MODESET_LOCK
>>>
>>> config DRM_FBDEV_EMULATION
>>> bool "Enable legacy fbdev support for your modesetting driver"
>>> - depends on DRM_KMS_HELPER
>>> - depends on FB=y || FB=DRM_KMS_HELPER
>>> + depends on DRM
>>> + select DRM_KMS_HELPER
>>> + select FB
>>> select FB_CFB_FILLRECT
>>> select FB_CFB_COPYAREA
>>> select FB_CFB_IMAGEBLIT
>>>
>>>
>>>
>>> I attached the configs for kernel v5.17-rc1. The "bad" config is without
>>> any revert, the "good" config is with the change above.
>>
>> Looking at the config, I see that this is for an x86 machine,
>> and you have the FB_EFI driver and EFI_EARLYCON enabled.
>>
>> What I suspec is going on is that you are looking at a screen rather
>> than a serial console, and the kernel doesn't actually hang but you
>> just don't see any more messages after the DRM driver takes
>> over from EFI_EARLYCON because there is no console driver.
>>
>> In this case, what you see is the intended behavior, not a bug.
>> If you want a graphical console in your system, you need to
>> enable the support for this in your config.
>>
>
> It sounds like that's the case. Unfortunately I'm not familiar with this
> subsystem to say that's what happening. If there's nothing actually
> broken from review, we can ignore this email thread.
Hi,
I don't know of anything that is broken...
I am curious how CONFIG_FB_EFI came to be set when going from bad.config to
good.config. Can you explain that?
thanks.
--
~Randy
RE: [Patch v5 00/24] CHECKPOINT RESTORE WITH ROCm
[AMD Official Use Only] Thank you Felix for the review and your guidance. -Original Message- From: Kuehling, Felix Sent: Thursday, February 3, 2022 10:22 PM To: Bhardwaj, Rajneesh ; amd-...@lists.freedesktop.org Cc: Yat Sin, David ; Deucher, Alexander ; dri-devel@lists.freedesktop.org Subject: Re: [Patch v5 00/24] CHECKPOINT RESTORE WITH ROCm The series is Reviewed-by: Felix Kuehling Am 2022-02-03 um 04:08 schrieb Rajneesh Bhardwaj: > V5: Proposed IOCTL APIs for CRIU with consolidated feedback > > CRIU is a user space tool which is very popular for container live > migration in datacentres. It can checkpoint a running application, > save its complete state, memory contents and all system resources to > images on disk which can be migrated to another m achine and restored later. > More information on CRIU can be found at https://criu.org/Main_Page > > CRIU currently does not support Checkpoint / Restore with applications > that have devices files open so it cannot perform checkpoint and > restore on GPU devices which are very complex and have their own VRAM > managed privately. CRIU, however can support external devices by using > a plugin architecture. We feel that we are getting close to finalizing > our IOCTL APIs which were again changed since V3 for an improved modular > design. > > Our changes to CRIU user space are can be obtained from here: > https://github.com/RadeonOpenCompute/criu/tree/amdgpu_rfc-211222 > > We have tested the following scenarios: > - Checkpoint / Restore of a Pytorch (BERT) workload > - kfdtests with queues and events > - Gfx9 and Gfx10 based multi GPU test systems > - On baremetal and inside a docker container > - Restoring on a different system > > V1: Initial > V2: Addressed review comments > V3: Rebased on latest amd-staging-drm-next (5.15 based) > v4: New API design and basic support for SVM, however there is an > outstanding issue with SVM restore which is currently under debug and > hopefully that won't impact the ioctl APIs as SVMs are treated as > private data hidden from user space like queues and events with the > new approch. > V5: Fix the SVM related issues and finalize the APIs. > > David Yat Sin (9): >drm/amdkfd: CRIU Implement KFD unpause operation >drm/amdkfd: CRIU add queues support >drm/amdkfd: CRIU restore queue ids >drm/amdkfd: CRIU restore sdma id for queues >drm/amdkfd: CRIU restore queue doorbell id >drm/amdkfd: CRIU checkpoint and restore queue mqds >drm/amdkfd: CRIU checkpoint and restore queue control stack >drm/amdkfd: CRIU checkpoint and restore events >drm/amdkfd: CRIU implement gpu_id remapping > > Rajneesh Bhardwaj (15): >x86/configs: CRIU update debug rock defconfig >drm/amdkfd: CRIU Introduce Checkpoint-Restore APIs >drm/amdkfd: CRIU Implement KFD process_info ioctl >drm/amdkfd: CRIU Implement KFD checkpoint ioctl >drm/amdkfd: CRIU Implement KFD restore ioctl >drm/amdkfd: CRIU Implement KFD resume ioctl >drm/amdkfd: CRIU export BOs as prime dmabuf objects >drm/amdkfd: CRIU checkpoint and restore xnack mode >drm/amdkfd: CRIU allow external mm for svm ranges >drm/amdkfd: use user_gpu_id for svm ranges >drm/amdkfd: CRIU Discover svm ranges >drm/amdkfd: CRIU Save Shared Virtual Memory ranges >drm/amdkfd: CRIU prepare for svm resume >drm/amdkfd: CRIU resume shared virtual memory ranges >drm/amdkfd: Bump up KFD API version for CRIU > > arch/x86/configs/rock-dbg_defconfig | 53 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h|7 +- > .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 64 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 20 + > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h |2 + > drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 1471 ++--- > drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c |2 +- > .../drm/amd/amdkfd/kfd_device_queue_manager.c | 185 ++- > .../drm/amd/amdkfd/kfd_device_queue_manager.h | 16 +- > drivers/gpu/drm/amd/amdkfd/kfd_events.c | 313 +++- > drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.h | 14 + > .../gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c | 75 + > .../gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c | 77 + > .../gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c | 92 ++ > .../gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c | 84 + > drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 160 +- > drivers/gpu/drm/amd/amdkfd/kfd_process.c | 72 +- > .../amd/amdkfd/kfd_process_queue_manager.c| 372 - > drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 331 +++- > drivers/gpu/drm/amd/amdkfd/kfd_svm.h | 39 + > include/uapi/linux/kfd_ioctl.h| 84 +- > 21 files changed, 3193 insertions(+), 340 deletions(-) >
Re: [Patch v5 00/24] CHECKPOINT RESTORE WITH ROCm
The series is Reviewed-by: Felix Kuehling Am 2022-02-03 um 04:08 schrieb Rajneesh Bhardwaj: V5: Proposed IOCTL APIs for CRIU with consolidated feedback CRIU is a user space tool which is very popular for container live migration in datacentres. It can checkpoint a running application, save its complete state, memory contents and all system resources to images on disk which can be migrated to another m achine and restored later. More information on CRIU can be found at https://criu.org/Main_Page CRIU currently does not support Checkpoint / Restore with applications that have devices files open so it cannot perform checkpoint and restore on GPU devices which are very complex and have their own VRAM managed privately. CRIU, however can support external devices by using a plugin architecture. We feel that we are getting close to finalizing our IOCTL APIs which were again changed since V3 for an improved modular design. Our changes to CRIU user space are can be obtained from here: https://github.com/RadeonOpenCompute/criu/tree/amdgpu_rfc-211222 We have tested the following scenarios: - Checkpoint / Restore of a Pytorch (BERT) workload - kfdtests with queues and events - Gfx9 and Gfx10 based multi GPU test systems - On baremetal and inside a docker container - Restoring on a different system V1: Initial V2: Addressed review comments V3: Rebased on latest amd-staging-drm-next (5.15 based) v4: New API design and basic support for SVM, however there is an outstanding issue with SVM restore which is currently under debug and hopefully that won't impact the ioctl APIs as SVMs are treated as private data hidden from user space like queues and events with the new approch. V5: Fix the SVM related issues and finalize the APIs. David Yat Sin (9): drm/amdkfd: CRIU Implement KFD unpause operation drm/amdkfd: CRIU add queues support drm/amdkfd: CRIU restore queue ids drm/amdkfd: CRIU restore sdma id for queues drm/amdkfd: CRIU restore queue doorbell id drm/amdkfd: CRIU checkpoint and restore queue mqds drm/amdkfd: CRIU checkpoint and restore queue control stack drm/amdkfd: CRIU checkpoint and restore events drm/amdkfd: CRIU implement gpu_id remapping Rajneesh Bhardwaj (15): x86/configs: CRIU update debug rock defconfig drm/amdkfd: CRIU Introduce Checkpoint-Restore APIs drm/amdkfd: CRIU Implement KFD process_info ioctl drm/amdkfd: CRIU Implement KFD checkpoint ioctl drm/amdkfd: CRIU Implement KFD restore ioctl drm/amdkfd: CRIU Implement KFD resume ioctl drm/amdkfd: CRIU export BOs as prime dmabuf objects drm/amdkfd: CRIU checkpoint and restore xnack mode drm/amdkfd: CRIU allow external mm for svm ranges drm/amdkfd: use user_gpu_id for svm ranges drm/amdkfd: CRIU Discover svm ranges drm/amdkfd: CRIU Save Shared Virtual Memory ranges drm/amdkfd: CRIU prepare for svm resume drm/amdkfd: CRIU resume shared virtual memory ranges drm/amdkfd: Bump up KFD API version for CRIU arch/x86/configs/rock-dbg_defconfig | 53 +- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h|7 +- .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 64 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 20 + drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h |2 + drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 1471 ++--- drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c |2 +- .../drm/amd/amdkfd/kfd_device_queue_manager.c | 185 ++- .../drm/amd/amdkfd/kfd_device_queue_manager.h | 16 +- drivers/gpu/drm/amd/amdkfd/kfd_events.c | 313 +++- drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.h | 14 + .../gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c | 75 + .../gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c | 77 + .../gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c | 92 ++ .../gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c | 84 + drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 160 +- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 72 +- .../amd/amdkfd/kfd_process_queue_manager.c| 372 - drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 331 +++- drivers/gpu/drm/amd/amdkfd/kfd_svm.h | 39 + include/uapi/linux/kfd_ioctl.h| 84 +- 21 files changed, 3193 insertions(+), 340 deletions(-)
[PATCH] drm/amdgpu: Fix recursive locking warning
Noticed the below warning while running a pytorch workload on vega10
GPUs. Change to trylock to avoid conflicts with already held reservation
locks.
[ +0.03] WARNING: possible recursive locking detected
[ +0.03] 5.13.0-kfd-rajneesh #1030 Not tainted
[ +0.04]
[ +0.02] python/4822 is trying to acquire lock:
[ +0.04] 932cd9a259f8 (reservation_ww_class_mutex){+.+.}-{3:3},
at: amdgpu_bo_release_notify+0xc4/0x160 [amdgpu]
[ +0.000203]
but task is already holding lock:
[ +0.03] 932cbb7181f8 (reservation_ww_class_mutex){+.+.}-{3:3},
at: ttm_eu_reserve_buffers+0x270/0x470 [ttm]
[ +0.17]
other info that might help us debug this:
[ +0.02] Possible unsafe locking scenario:
[ +0.03]CPU0
[ +0.02]
[ +0.02] lock(reservation_ww_class_mutex);
[ +0.04] lock(reservation_ww_class_mutex);
[ +0.03]
*** DEADLOCK ***
[ +0.02] May be due to missing lock nesting notation
[ +0.03] 7 locks held by python/4822:
[ +0.03] #0: 932c4ac028d0 (>mutex){+.+.}-{3:3}, at:
kfd_ioctl_map_memory_to_gpu+0x10b/0x320 [amdgpu]
[ +0.000232] #1: 932c55e830a8 (>lock#2){+.+.}-{3:3}, at:
amdgpu_amdkfd_gpuvm_map_memory_to_gpu+0x64/0xf60 [amdgpu]
[ +0.000241] #2: 932cc45b5e68 (&(*mem)->lock){+.+.}-{3:3}, at:
amdgpu_amdkfd_gpuvm_map_memory_to_gpu+0xdf/0xf60 [amdgpu]
[ +0.000236] #3: b2b35606fd28
(reservation_ww_class_acquire){+.+.}-{0:0}, at:
amdgpu_amdkfd_gpuvm_map_memory_to_gpu+0x232/0xf60 [amdgpu]
[ +0.000235] #4: 932cbb7181f8
(reservation_ww_class_mutex){+.+.}-{3:3}, at:
ttm_eu_reserve_buffers+0x270/0x470 [ttm]
[ +0.15] #5: c045f700 (*(sspp++)){}-{0:0}, at:
drm_dev_enter+0x5/0xa0 [drm]
[ +0.38] #6: 932c52da7078 (>eviction_lock){+.+.}-{3:3},
at: amdgpu_vm_bo_update_mapping+0xd5/0x4f0 [amdgpu]
[ +0.000195]
stack backtrace:
[ +0.03] CPU: 11 PID: 4822 Comm: python Not tainted
5.13.0-kfd-rajneesh #1030
[ +0.05] Hardware name: GIGABYTE MZ01-CE0-00/MZ01-CE0-00, BIOS F02
08/29/2018
[ +0.03] Call Trace:
[ +0.03] dump_stack+0x6d/0x89
[ +0.10] __lock_acquire+0xb93/0x1a90
[ +0.09] lock_acquire+0x25d/0x2d0
[ +0.05] ? amdgpu_bo_release_notify+0xc4/0x160 [amdgpu]
[ +0.000184] ? lock_is_held_type+0xa2/0x110
[ +0.06] ? amdgpu_bo_release_notify+0xc4/0x160 [amdgpu]
[ +0.000184] __ww_mutex_lock.constprop.17+0xca/0x1060
[ +0.07] ? amdgpu_bo_release_notify+0xc4/0x160 [amdgpu]
[ +0.000183] ? lock_release+0x13f/0x270
[ +0.05] ? lock_is_held_type+0xa2/0x110
[ +0.06] ? amdgpu_bo_release_notify+0xc4/0x160 [amdgpu]
[ +0.000183] amdgpu_bo_release_notify+0xc4/0x160 [amdgpu]
[ +0.000185] ttm_bo_release+0x4c6/0x580 [ttm]
[ +0.10] amdgpu_bo_unref+0x1a/0x30 [amdgpu]
[ +0.000183] amdgpu_vm_free_table+0x76/0xa0 [amdgpu]
[ +0.000189] amdgpu_vm_free_pts+0xb8/0xf0 [amdgpu]
[ +0.000189] amdgpu_vm_update_ptes+0x411/0x770 [amdgpu]
[ +0.000191] amdgpu_vm_bo_update_mapping+0x324/0x4f0 [amdgpu]
[ +0.000191] amdgpu_vm_bo_update+0x251/0x610 [amdgpu]
[ +0.000191] update_gpuvm_pte+0xcc/0x290 [amdgpu]
[ +0.000229] ? amdgpu_vm_bo_map+0xd7/0x130 [amdgpu]
[ +0.000190] amdgpu_amdkfd_gpuvm_map_memory_to_gpu+0x912/0xf60
[amdgpu]
[ +0.000234] kfd_ioctl_map_memory_to_gpu+0x182/0x320 [amdgpu]
[ +0.000218] kfd_ioctl+0x2b9/0x600 [amdgpu]
[ +0.000216] ? kfd_ioctl_unmap_memory_from_gpu+0x270/0x270 [amdgpu]
[ +0.000216] ? lock_release+0x13f/0x270
[ +0.06] ? __fget_files+0x107/0x1e0
[ +0.07] __x64_sys_ioctl+0x8b/0xd0
[ +0.07] do_syscall_64+0x36/0x70
[ +0.04] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ +0.07] RIP: 0033:0x7fbff90a7317
[ +0.04] Code: b3 66 90 48 8b 05 71 4b 2d 00 64 c7 00 26 00 00 00
48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f
05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 41 4b 2d 00 f7 d8 64 89 01 48
[ +0.05] RSP: 002b:7fbe301fe648 EFLAGS: 0246 ORIG_RAX:
0010
[ +0.06] RAX: ffda RBX: 7fbcc402d820 RCX:
7fbff90a7317
[ +0.03] RDX: 7fbe301fe690 RSI: c0184b18 RDI:
0004
[ +0.03] RBP: 7fbe301fe690 R08: R09:
7fbcc402d880
[ +0.03] R10: 02001000 R11: 0246 R12:
c0184b18
[ +0.03] R13: 0004 R14: 7fbf689593a0 R15:
7fbcc402d820
Cc: Christian König
Cc: Felix Kuehling
Cc: Alex Deucher
Fixes: 627b92ef9d7c ("drm/amdgpu: Wipe all VRAM on free when RAS is
enabled")
Signed-off-by: Rajneesh Bhardwaj
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 36bb41b027ec..6ccd2be685f5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++
[PATCH] drm/sprd: remove allow_fb_modifiers setting
Remove allow_fb_modifiers setting in this driver. The allow_fb_modifiers
flag was removed.
Signed-off-by: Tomohito Esaki
Fixes: 3d082157a242 ("drm: remove allow_fb_modifiers")
Reported-by: kernel test robot
---
drivers/gpu/drm/sprd/sprd_drm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/sprd/sprd_drm.c b/drivers/gpu/drm/sprd/sprd_drm.c
index a077e2d4d721..54c851bccf5b 100644
--- a/drivers/gpu/drm/sprd/sprd_drm.c
+++ b/drivers/gpu/drm/sprd/sprd_drm.c
@@ -43,7 +43,6 @@ static void sprd_drm_mode_config_init(struct drm_device *drm)
drm->mode_config.min_height = 0;
drm->mode_config.max_width = 8192;
drm->mode_config.max_height = 8192;
- drm->mode_config.allow_fb_modifiers = true;
drm->mode_config.funcs = _drm_mode_config_funcs;
drm->mode_config.helper_private = _drm_mode_config_helper;
--
2.17.1
[PATCH 1/2] drm/mm: Add an iterator to optimally walk over holes for an allocation (v2)
This iterator relies on drm_mm_first_hole() and drm_mm_next_hole()
functions to identify suitable holes for an allocation of a given
size by efficiently traversing the rbtree associated with the given
allocator.
It replaces the for loop in drm_mm_insert_node_in_range() and can
also be used by drm drivers to quickly identify holes of a certain
size within a given range.
v2: (Tvrtko)
- Prepend a double underscore for the newly exported first/next_hole
- s/each_best_hole/each_suitable_hole/g
- Mask out DRM_MM_INSERT_ONCE from the mode before calling
first/next_hole and elsewhere.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/drm_mm.c | 38 ++
include/drm/drm_mm.h | 36
2 files changed, 54 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 8257f9d4f619..b6da1dffcfcb 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -352,10 +352,10 @@ static struct drm_mm_node *find_hole_addr(struct drm_mm
*mm, u64 addr, u64 size)
return node;
}
-static struct drm_mm_node *
-first_hole(struct drm_mm *mm,
- u64 start, u64 end, u64 size,
- enum drm_mm_insert_mode mode)
+struct drm_mm_node *
+__drm_mm_first_hole(struct drm_mm *mm,
+ u64 start, u64 end, u64 size,
+ enum drm_mm_insert_mode mode)
{
switch (mode) {
default:
@@ -374,6 +374,7 @@ first_hole(struct drm_mm *mm,
hole_stack);
}
}
+EXPORT_SYMBOL(__drm_mm_first_hole);
/**
* DECLARE_NEXT_HOLE_ADDR - macro to declare next hole functions
@@ -410,11 +411,11 @@ static struct drm_mm_node *name(struct drm_mm_node
*entry, u64 size) \
DECLARE_NEXT_HOLE_ADDR(next_hole_high_addr, rb_left, rb_right)
DECLARE_NEXT_HOLE_ADDR(next_hole_low_addr, rb_right, rb_left)
-static struct drm_mm_node *
-next_hole(struct drm_mm *mm,
- struct drm_mm_node *node,
- u64 size,
- enum drm_mm_insert_mode mode)
+struct drm_mm_node *
+__drm_mm_next_hole(struct drm_mm *mm,
+ struct drm_mm_node *node,
+ u64 size,
+ enum drm_mm_insert_mode mode)
{
switch (mode) {
default:
@@ -432,6 +433,7 @@ next_hole(struct drm_mm *mm,
return >hole_stack == >hole_stack ? NULL : node;
}
}
+EXPORT_SYMBOL(__drm_mm_next_hole);
/**
* drm_mm_reserve_node - insert an pre-initialized node
@@ -520,7 +522,6 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm,
{
struct drm_mm_node *hole;
u64 remainder_mask;
- bool once;
DRM_MM_BUG_ON(range_start > range_end);
@@ -533,22 +534,19 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm,
if (alignment <= 1)
alignment = 0;
- once = mode & DRM_MM_INSERT_ONCE;
- mode &= ~DRM_MM_INSERT_ONCE;
-
remainder_mask = is_power_of_2(alignment) ? alignment - 1 : 0;
- for (hole = first_hole(mm, range_start, range_end, size, mode);
-hole;
-hole = once ? NULL : next_hole(mm, hole, size, mode)) {
+ drm_mm_for_each_suitable_hole(hole, mm, range_start, range_end,
+ size, mode) {
u64 hole_start = __drm_mm_hole_node_start(hole);
u64 hole_end = hole_start + hole->hole_size;
u64 adj_start, adj_end;
u64 col_start, col_end;
+ enum drm_mm_insert_mode placement = mode & ~DRM_MM_INSERT_ONCE;
- if (mode == DRM_MM_INSERT_LOW && hole_start >= range_end)
+ if (placement == DRM_MM_INSERT_LOW && hole_start >= range_end)
break;
- if (mode == DRM_MM_INSERT_HIGH && hole_end <= range_start)
+ if (placement == DRM_MM_INSERT_HIGH && hole_end <= range_start)
break;
col_start = hole_start;
@@ -562,7 +560,7 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm,
if (adj_end <= adj_start || adj_end - adj_start < size)
continue;
- if (mode == DRM_MM_INSERT_HIGH)
+ if (placement == DRM_MM_INSERT_HIGH)
adj_start = adj_end - size;
if (alignment) {
@@ -574,7 +572,7 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm,
div64_u64_rem(adj_start, alignment, );
if (rem) {
adj_start -= rem;
- if (mode != DRM_MM_INSERT_HIGH)
+ if (placement != DRM_MM_INSERT_HIGH)
adj_start += alignment;
if (adj_start < max(col_start, range_start) ||
diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
Re: [Intel-gfx] [PATCH] drm/i915: Add fallback inside memcpy_from_wc functions
Hi Balasubramani,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip drm-exynos/exynos-drm-next
drm/drm-next tegra-drm/drm/tegra/for-next v5.17-rc2 next-20220203]
[cannot apply to airlied/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Balasubramani-Vivekanandan/drm-i915-Add-fallback-inside-memcpy_from_wc-functions/20220204-002704
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-s001
(https://download.01.org/0day-ci/archive/20220204/202202040609.osw2rfil-...@intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.4-dirty
#
https://github.com/0day-ci/linux/commit/66de634b392157effc065df388510df67de59f2b
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Balasubramani-Vivekanandan/drm-i915-Add-fallback-inside-memcpy_from_wc-functions/20220204-002704
git checkout 66de634b392157effc065df388510df67de59f2b
# save the config file to linux build tree
mkdir build_dir
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir
ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/i915/ net/ipv6/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/i915/i915_memcpy.c:189:42: sparse: sparse: incorrect type in
>> argument 2 (different address spaces) @@ expected void const *src @@
>> got void const [noderef] __iomem *src @@
drivers/gpu/drm/i915/i915_memcpy.c:189:42: sparse: expected void const
*src
drivers/gpu/drm/i915/i915_memcpy.c:189:42: sparse: got void const
[noderef] __iomem *src
>> drivers/gpu/drm/i915/i915_memcpy.c:191:45: sparse: sparse: incorrect type in
>> argument 2 (different address spaces) @@ expected void const *[assigned]
>> src @@ got void const [noderef] __iomem *src @@
drivers/gpu/drm/i915/i915_memcpy.c:191:45: sparse: expected void const
*[assigned] src
drivers/gpu/drm/i915/i915_memcpy.c:191:45: sparse: got void const
[noderef] __iomem *src
drivers/gpu/drm/i915/i915_memcpy.c:187:6: sparse: sparse: symbol
'i915_io_memcpy_from_wc' redeclared with different type (incompatible argument
2 (different address spaces)):
>> drivers/gpu/drm/i915/i915_memcpy.c:187:6: sparse:void extern
>> [addressable] [toplevel] i915_io_memcpy_from_wc( ... )
drivers/gpu/drm/i915/i915_memcpy.c: note: in included file:
drivers/gpu/drm/i915/i915_memcpy.h:17:6: sparse: note: previously declared
as:
>> drivers/gpu/drm/i915/i915_memcpy.h:17:6: sparse:void extern
>> [addressable] [toplevel] i915_io_memcpy_from_wc( ... )
--
>> drivers/gpu/drm/i915/gem/i915_gem_object.c:449:37: sparse: sparse: incorrect
>> type in argument 2 (different address spaces) @@ expected void const
>> *src @@ got void [noderef] __iomem *[assigned] src_ptr @@
drivers/gpu/drm/i915/gem/i915_gem_object.c:449:37: sparse: expected void
const *src
drivers/gpu/drm/i915/gem/i915_gem_object.c:449:37: sparse: got void
[noderef] __iomem *[assigned] src_ptr
vim +189 drivers/gpu/drm/i915/i915_memcpy.c
175
176 /**
177 * i915_io_memcpy_from_wc: perform an accelerated *aligned* read from WC
178 * @dst: destination pointer
179 * @src: source pointer
180 * @len: how many bytes to copy
181 *
182 * To be used when the when copying from io memory.
183 *
184 * memcpy_fromio() is used as fallback otherewise no difference to
185 * i915_memcpy_from_wc()
186 */
> 187 void i915_io_memcpy_from_wc(void *dst, const void __iomem *src,
> unsigned long len)
188 {
> 189 if (i915_can_memcpy_from_wc(dst, src, len)) {
190 if (likely(len))
> 191 __memcpy_ntdqa(dst, src, len >> 4);
192 return;
193 }
194
195 /* Fallback */
196 memcpy_fromio(dst, src, len);
197 }
198
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH 16/19] drm/i915/guc: Use a single pass to calculate regset
On Tue, Feb 01, 2022 at 02:42:20PM -0800, Daniele Ceraolo Spurio wrote:
On 1/26/2022 12:36 PM, Lucas De Marchi wrote:
The ADS initialitazion was using 2 passes to calculate the regset sent
to GuC to initialize each engine: the first pass to just have the final
object size and the second to set each register in place in the final
gem object.
However in order to maintain an ordered set of registers to pass to guc,
each register needs to be added and moved in the final array. The second
phase may actually happen in IO memory rather than system memory and
accessing IO memory by simply dereferencing the pointer doesn't work on
all architectures. Other places of the ADS initializaition were
converted to use the dma_buf_map API, but here there may be a lot more
accesses to IO memory. So, instead of following that same approach,
convert the regset initialization to calculate the final array in 1
pass and in the second pass that array is just copied to its final
location, updating the pointers for each engine written to the ADS blob.
One important thing is that struct temp_regset now have
different semantics: `registers` continues to track the registers of a
single engine, however the other fields are updated together, according
to the newly added `storage`, which tracks the memory allocated for
all the registers. So rename some of these fields and add a
__mmio_reg_add(): this function (possibly) allocates memory and operates
on the storage pointer while guc_mmio_reg_add() continues to manage the
registers pointer.
On a Tiger Lake system using enable_guc=3, the following log message is
now seen:
[ 187.334310] i915 :00:02.0: [drm:intel_guc_ads_create [i915]]
Used 4 KB for temporary ADS regset
This change has also been tested on an ARM64 host with DG2 and other
discrete graphics cards.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 7 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 117 +
2 files changed, 79 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index e2e0df1c3d91..4c852eee3ad8 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -152,6 +152,13 @@ struct intel_guc {
struct dma_buf_map ads_map;
/** @ads_regset_size: size of the save/restore regsets in the ADS */
u32 ads_regset_size;
+ /**
+* @ads_regset_count: number of save/restore registers in the ADS for
+* each engine
+*/
+ u32 ads_regset_count[I915_NUM_ENGINES];
+ /** @ads_regset: save/restore regsets in the ADS */
+ struct guc_mmio_reg *ads_regset;
/** @ads_golden_ctxt_size: size of the golden contexts in the ADS */
u32 ads_golden_ctxt_size;
/** @ads_engine_usage_size: size of engine usage in the ADS */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 73ca34de44f7..390101ee3661 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -226,14 +226,13 @@ static void guc_mapping_table_init(struct intel_gt *gt,
/*
* The save/restore register list must be pre-calculated to a temporary
- * buffer of driver defined size before it can be generated in place
- * inside the ADS.
+ * buffer before it can be copied inside the ADS.
*/
-#define MAX_MMIO_REGS 128 /* Arbitrary size, increase as needed */
struct temp_regset {
struct guc_mmio_reg *registers;
- u32 used;
- u32 size;
+ struct guc_mmio_reg *storage;
I think this could use a comment to distinguish between registers and
storage. Something like.:
/* ptr to the base of the allocated storage for all engines */
struct guc_mmio_reg *storage;
/* ptr to the section of the storage for the engine currently being
worked on */
struct guc_mmio_reg *registers;
agreed, I will add that
+ u32 storage_used;
+ u32 storage_max;
};
static int guc_mmio_reg_cmp(const void *a, const void *b)
@@ -244,18 +243,44 @@ static int guc_mmio_reg_cmp(const void *a, const void *b)
return (int)ra->offset - (int)rb->offset;
}
+static struct guc_mmio_reg * __must_check
+__mmio_reg_add(struct temp_regset *regset, struct guc_mmio_reg *reg)
+{
+ u32 pos = regset->storage_used;
+ struct guc_mmio_reg *slot;
+
+ if (pos >= regset->storage_max) {
+ size_t size = ALIGN((pos + 1) * sizeof(*slot), PAGE_SIZE);
+ struct guc_mmio_reg *r = krealloc(regset->storage,
+ size, GFP_KERNEL);
+ if (!r) {
+ WARN_ONCE(1, "Incomplete regset list: can't add register
(%d)\n",
+ -ENOMEM);
+
Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/uapi: Add query for hwconfig table
Jordan Justen writes:
> John, Rodrigo,
>
> It is now clear to me just how dependent i915 is going to be on the
> closed source guc software, and that's just a fact of life for our
> graphics stack going forward.
>
> In that context, it seems kind of pointless for me to make a big deal
> out of this peripheral "query item" commit message. I still think
> something as simple and to the point as:
>
> "In this interface i915 is returning a blob of data which it receives
> from the guc software. This blob provides some useful data about the
> hardware for drivers. The format of this blob will be documented in the
> Programmer Reference Manuals when released."
As I said on the internal email thread, *if you use my commit message
suggestion*, then, begrudgingly, you can add my:
Acked-by: Jordan Justen
to the patch.
Regardless of the commit message, I think you can add:
Tested-by: Jordan Justen
In truth, I've only tested this via the "prelim" i915 Linux uapi fork on
an internal kernel tree, but I think that probably is close enough.
In case you find it helpful, maybe:
Ref: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14511
-Jordan
>
> ... would be better, but obviously this is really just down in the noise
> in terms of concerns about the greater issue. So, feel free (to
> continue) to ignore my suggestion.
>
> Sorry for having wasted your time,
>
> -Jordan
>
> john.c.harri...@intel.com writes:
>
>> From: Rodrigo Vivi
>>
>> GuC contains a consolidated table with a bunch of information about the
>> current device.
>>
>> Previously, this information was spread and hardcoded to all the components
>> including GuC, i915 and various UMDs. The goal here is to consolidate
>> the data into GuC in a way that all interested components can grab the
>> very latest and synchronized information using a simple query.
>>
>> As per most of the other queries, this one can be called twice.
>> Once with item.length=0 to determine the exact buffer size, then
>> allocate the user memory and call it again for to retrieve the
>> table data. For example:
>> struct drm_i915_query_item item = {
>> .query_id = DRM_I915_QUERY_HWCONCFIG_TABLE;
>> };
>> query.items_ptr = (int64_t)
>> query.num_items = 1;
>>
>> ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>
>> if (item.length <= 0)
>> return -ENOENT;
>>
>> data = malloc(item.length);
>> item.data_ptr = (int64_t)
>> ioctl(fd, DRM_IOCTL_I915_QUERY, query, sizeof(query));
>>
>> // Parse the data as appropriate...
>>
>> The returned array is a simple and flexible KLV (Key/Length/Value)
>> formatted table. For example, it could be just:
>> enum device_attr {
>> ATTR_SOME_VALUE = 0,
>> ATTR_SOME_MASK = 1,
>> };
>>
>> static const u32 hwconfig[] = {
>> ATTR_SOME_VALUE,
>> 1, // Value Length in DWords
>> 8, // Value
>>
>> ATTR_SOME_MASK,
>> 3,
>> 0x00, 0x, 0xFF00,
>> };
>>
>> The attribute ids are defined in a hardware spec.
>>
>> Cc: Tvrtko Ursulin
>> Cc: Kenneth Graunke
>> Cc: Michal Wajdeczko
>> Cc: Slawomir Milczarek
>> Signed-off-by: Rodrigo Vivi
>> Signed-off-by: John Harrison
>> Reviewed-by: Matthew Brost
>> ---
>> drivers/gpu/drm/i915/i915_query.c | 23 +++
>> include/uapi/drm/i915_drm.h | 1 +
>> 2 files changed, 24 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_query.c
>> b/drivers/gpu/drm/i915/i915_query.c
>> index 2dfbc22857a3..609e64d5f395 100644
>> --- a/drivers/gpu/drm/i915/i915_query.c
>> +++ b/drivers/gpu/drm/i915/i915_query.c
>> @@ -479,12 +479,35 @@ static int query_memregion_info(struct
>> drm_i915_private *i915,
>> return total_length;
>> }
>>
>> +static int query_hwconfig_table(struct drm_i915_private *i915,
>> +struct drm_i915_query_item *query_item)
>> +{
>> +struct intel_gt *gt = to_gt(i915);
>> +struct intel_guc_hwconfig *hwconfig = >uc.guc.hwconfig;
>> +
>> +if (!hwconfig->size || !hwconfig->ptr)
>> +return -ENODEV;
>> +
>> +if (query_item->length == 0)
>> +return hwconfig->size;
>> +
>> +if (query_item->length < hwconfig->size)
>> +return -EINVAL;
>> +
>> +if (copy_to_user(u64_to_user_ptr(query_item->data_ptr),
>> + hwconfig->ptr, hwconfig->size))
>> +return -EFAULT;
>> +
>> +return hwconfig->size;
>> +}
>> +
>> static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
>> struct drm_i915_query_item *query_item)
>> = {
>> query_topology_info,
>> query_engine_info,
>> query_perf_config,
>> query_memregion_info,
>> +query_hwconfig_table,
>> };
>>
>> int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file
>> *file)
>> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
>> index 914ebd9290e5..132515199f27 100644
>> ---
Re: [PATCH 11/21] fbcon: Extract fbcon_open/release helpers
Hi Daniel, > > > + kfree(ops->cursor_state.mask); > > + kfree(ops->cursor_data); > > + kfree(ops->cursor_src); > > + kfree(ops->fontbuffer); > > + kfree(oldinfo->fbcon_par); > > + oldinfo->fbcon_par = NULL; > These all look like candidates to stuff into fbcon_release() > That would drop the nice symmetry but make it more consistent. > > I think we miss freeing ops->cursor_data in fbcon_exit(), > but I did not follow all the code. We agree as I can see this was done in a later patch. Sam
Re: [PATCH 10/21] fb: Delete fb_info->queue
On Mon, Jan 31, 2022 at 10:05:41PM +0100, Daniel Vetter wrote:
> It was only used by fbcon, and that now switched to its own,
> private work.
>
> Signed-off-by: Daniel Vetter
> Cc: Helge Deller
> Cc: linux-fb...@vger.kernel.org
I would merge this with the patch that drops the usage
> ---
> include/linux/fb.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 02f362c661c8..a8a00d2ba1f3 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -449,7 +449,6 @@ struct fb_info {
> struct fb_var_screeninfo var; /* Current var */
> struct fb_fix_screeninfo fix; /* Current fix */
> struct fb_monspecs monspecs;/* Current Monitor specs */
> - struct work_struct queue; /* Framebuffer event queue */
> struct fb_pixmap pixmap;/* Image hardware mapper */
> struct fb_pixmap sprite;/* Cursor hardware mapper */
> struct fb_cmap cmap;/* Current cmap */
> --
> 2.33.0
Re: [PATCH 09/21] fbcon: Replace FBCON_FLAGS_INIT with a boolean
On Mon, Jan 31, 2022 at 10:05:40PM +0100, Daniel Vetter wrote: > It's only one flag and slightly tidier code. > > Signed-off-by: Daniel Vetter > Cc: Daniel Vetter > Cc: Tetsuo Handa > Cc: Greg Kroah-Hartman > Cc: Du Cheng > Cc: Thomas Zimmermann > Cc: Claudio Suarez Acked-by: Sam Ravnborg Next step is to convert some of the int flags to bool - so it is obvious this is bool and not an int. I do not like bitfields for bools when there is no big win in memory usage - so not fan of that suggestion. Sam
Re: [PATCH 07/21] fbdev/sysfs: Fix locking
On Mon, Jan 31, 2022 at 10:05:38PM +0100, Daniel Vetter wrote: > fb_set_var requires we hold the fb_info lock. Or at least this now > matches what the ioctl does ... > > Note that ps3fb and sh_mobile_lcdcfb are busted in different ways here, > but I will not fix them up. > > Also in practice this isn't a big deal, because really variable fbdev > state is actually protected by console_lock (because fbcon just > doesn't bother with lock_fb_info() at all), and lock_fb_info > protecting anything is really just a neat lie. But that's a much > bigger fish to fry. > > Signed-off-by: Daniel Vetter > Cc: Helge Deller > Cc: Daniel Vetter > Cc: Qing Wang > Cc: Sam Ravnborg Acked-by: Sam Ravnborg
Re: [PATCH 05/21] fbcon: Introduce wrapper for console->fb_info lookup
On Mon, Jan 31, 2022 at 10:05:36PM +0100, Daniel Vetter wrote: > Half of it is protected by console_lock, but the other half is a lot > more awkward: Registration/deregistration of fbdev are serialized, but > we don't really clear out anything in con2fb_map and so there's > potential for use-after free mixups. > > First step is to encapsulate the lookup. > > Signed-off-by: Daniel Vetter > Cc: Helge Deller > Cc: Daniel Vetter > Cc: Greg Kroah-Hartman > Cc: Tetsuo Handa > Cc: Du Cheng > Cc: Claudio Suarez > Cc: Thomas Zimmermann Acked-by: Sam Ravnborg
Re: [PATCH 12/21] fbcon: Ditch error handling for con2fb_release_oldinfo
On Mon, Jan 31, 2022 at 10:05:43PM +0100, Daniel Vetter wrote: > It doesn't ever fail anymore. > > Signed-off-by: Daniel Vetter > Cc: Daniel Vetter > Cc: Thomas Zimmermann > Cc: Greg Kroah-Hartman > Cc: Claudio Suarez > Cc: Du Cheng > Cc: Tetsuo Handa Acked-by: Sam Ravnborg
Re: [PATCH 11/21] fbcon: Extract fbcon_open/release helpers
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:42PM +0100, Daniel Vetter wrote:
> There's two minor behaviour changes in here:
> - in error paths we now consistently call fb_ops->fb_release
> - fb_release really can't fail (fbmem.c ignores it too) and there's no
> reasonable cleanup we can do anyway.
>
> Signed-off-by: Daniel Vetter
> Cc: Daniel Vetter
> Cc: Claudio Suarez
> Cc: Greg Kroah-Hartman
> Cc: Tetsuo Handa
> Cc: Du Cheng
> ---
> drivers/video/fbdev/core/fbcon.c | 107 +++
> 1 file changed, 53 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index fa30e1909164..eea2ee14b64c 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -680,19 +680,37 @@ static int fbcon_invalid_charcount(struct fb_info
> *info, unsigned charcount)
>
> #endif /* CONFIG_MISC_TILEBLITTING */
>
> +static int fbcon_open(struct fb_info *info)
> +{
> + if (!try_module_get(info->fbops->owner))
> + return -ENODEV;
> +
> + if (info->fbops->fb_open &&
> + info->fbops->fb_open(info, 0)) {
> + module_put(info->fbops->owner);
> + return -ENODEV;
> + }
> +
> + return 0;
> +}
> +
> +static void fbcon_release(struct fb_info *info)
> +{
> + if (info->fbops->fb_release)
> + info->fbops->fb_release(info, 0);
> +
> + module_put(info->fbops->owner);
> +}
>
> static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> int unit, int oldidx)
> {
> struct fbcon_ops *ops = NULL;
> - int err = 0;
> -
> - if (!try_module_get(info->fbops->owner))
> - err = -ENODEV;
> + int err;
>
> - if (!err && info->fbops->fb_open &&
> - info->fbops->fb_open(info, 0))
> - err = -ENODEV;
> + err = fbcon_open(info);
> + if (err)
> + return err;
>
> if (!err) {
> ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> @@ -713,7 +731,7 @@ static int con2fb_acquire_newinfo(struct vc_data *vc,
> struct fb_info *info,
>
> if (err) {
> con2fb_map[unit] = oldidx;
> - module_put(info->fbops->owner);
> + fbcon_release(info);
> }
>
> return err;
> @@ -724,45 +742,34 @@ static int con2fb_release_oldinfo(struct vc_data *vc,
> struct fb_info *oldinfo,
> int oldidx, int found)
> {
> struct fbcon_ops *ops = oldinfo->fbcon_par;
> - int err = 0, ret;
> + int ret;
>
> - if (oldinfo->fbops->fb_release &&
> - oldinfo->fbops->fb_release(oldinfo, 0)) {
> - con2fb_map[unit] = oldidx;
The old code assigns con2fb_map[unit] before is calls
newinfo->fbops->fb_release).
I wonder if there can be any callback to fbcon where the value
of con2fb_map[unit] matters?
> - if (!found && newinfo->fbops->fb_release)
> - newinfo->fbops->fb_release(newinfo, 0);
> - if (!found)
> - module_put(newinfo->fbops->owner);
> - err = -ENODEV;
> - }
> + fbcon_release(oldinfo);
>
> - if (!err) {
> - fbcon_del_cursor_work(oldinfo);
> - kfree(ops->cursor_state.mask);
> - kfree(ops->cursor_data);
> - kfree(ops->cursor_src);
> - kfree(ops->fontbuffer);
> - kfree(oldinfo->fbcon_par);
> - oldinfo->fbcon_par = NULL;
> - module_put(oldinfo->fbops->owner);
> - /*
> - If oldinfo and newinfo are driving the same hardware,
> - the fb_release() method of oldinfo may attempt to
> - restore the hardware state. This will leave the
> - newinfo in an undefined state. Thus, a call to
> - fb_set_par() may be needed for the newinfo.
> - */
> - if (newinfo && newinfo->fbops->fb_set_par) {
> - ret = newinfo->fbops->fb_set_par(newinfo);
> + fbcon_del_cursor_work(oldinfo);
> + kfree(ops->cursor_state.mask);
> + kfree(ops->cursor_data);
> + kfree(ops->cursor_src);
> + kfree(ops->fontbuffer);
> + kfree(oldinfo->fbcon_par);
> + oldinfo->fbcon_par = NULL;
These all look like candidates to stuff into fbcon_release()
That would drop the nice symmetry but make it more consistent.
I think we miss freeing ops->cursor_data in fbcon_exit(),
but I did not follow all the code.
With my ramblings considered the patch is
Acked-by: Sam Ravnborg
Sam
> + /*
> + If oldinfo and newinfo are driving the same hardware,
> + the fb_release() method of oldinfo may attempt to
> + restore the hardware state. This will leave the
> + newinfo in an undefined state. Thus, a call to
> + fb_set_par() may be needed for the newinfo.
> + */
> + if (newinfo &&
Re: [PATCH v2] drm/msm/dp: add connector type to enhance debug messages
Quoting Dmitry Baryshkov (2022-01-31 18:34:47)
> On 27/01/2022 02:46, Kuogee Hsieh wrote:
> > DP driver is a generic driver which supports both eDP and DP.
> > For debugging purpose it is required to have capabilities to
> > differentiate message are generated from eDP or DP.
> > This patch do:
> > 1) add connector type into debug messages within dp_display.c
> > 2) revise debug messages related to DP phy within dp_ctrl.c
> > 3) replace DRM_DEBUG_DP marco with drm_dbg_dp
>
> You list three items here. This patch should be split into respective
> three parts.
>
> >
> > Changes in V2:
> > -- replace DRM_DEBUG_DP marco with drm_dbg_dp
>
> I suppose that Stephen's idea was to pass proper drm_device to this
> function rather than always passing NULL.
>
The idea was to pass 'struct something' and then have a 'dev' named
member inside that's a struct device.
struct something {
struct device *dev;
...
};
Then the macro will extract the device out of it and use it to print
messages. It may be an abuse of the macro though because initially I
thought it needed to be a drm device but that doesn't seem to be the
case?
Re: [PATCH] drm/panel: Select DRM_DP_HELPER for DRM_PANEL_EDP
Reviewed-by: Lyude Paul
On Thu, 2022-02-03 at 10:13 +0100, Thomas Zimmermann wrote:
> As reported in [1], DRM_PANEL_EDP depends on DRM_DP_HELPER. Select
> the option to fix the build failure. The issue has been reported
> before, when DisplayPort helpers where hidden behind the option
> CONFIG_DRM_KMS_HELPER. [2]
>
> Signed-off-by: Thomas Zimmermann
> Fixes: adb9d5a2cc77 ("drm/dp: Move DisplayPort helpers into separate helper
> module")
> Fixes: 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of panel-simple")
> Reported-by: Naresh Kamboju
> Cc: Thomas Zimmermann
> Cc: Lyude Paul
> Cc: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: dri-devel@lists.freedesktop.org
> ---
> drivers/gpu/drm/panel/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 434c2861bb40..0aec5a10b064 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -106,6 +106,7 @@ config DRM_PANEL_EDP
> depends on PM
> select VIDEOMODE_HELPERS
> select DRM_DP_AUX_BUS
> + select DRM_DP_HELPER
> help
> DRM panel driver for dumb eDP panels that need at most a regulator
> and
> a GPIO to be powered up. Optionally a backlight can be attached so
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
[Important!] 2022 X.Org Foundation Membership deadline for voting in the election
The 2022 X.Org Foundation elections are rapidly approaching. We will be forwarding instructions on the nomination process to membership in the near future. Please note that only current members can vote in the upcoming election, and that the deadline for new memberships or renewals to vote in the upcoming election is March 17th 2022 at 23:59 UTC. If you are interested in joining the X.Org Foundation or in renewing your membership, please visit the membership system site at: https://members.x.org/ You can find the current election schedule here: https://www.x.org/wiki/BoardOfDirectors/Elections/2022/ Lyude Paul, On behalf of the X.Org elections committee -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
Re: [PATCH 06/21] fbcon: delete delayed loading code
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:37PM +0100, Daniel Vetter wrote:
> Before
>
> commit 6104c37094e729f3d4ce65797002112735d49cd1
> Author: Daniel Vetter
> Date: Tue Aug 1 17:32:07 2017 +0200
>
> fbcon: Make fbcon a built-time depency for fbdev
>
> it was possible to load fbcon and fbdev drivers in any order, which
> means that fbcon init had to handle the case where fbdev drivers where
> already registered.
>
> This is no longer possible, hence delete that code.
>
> Note that the exit case is a bit more complex and will be done in a
> separate patch.
>
> Signed-off-by: Daniel Vetter
> Cc: Helge Deller
> Cc: Daniel Vetter
> Cc: Claudio Suarez
> Cc: Greg Kroah-Hartman
> Cc: Tetsuo Handa
> Cc: Du Cheng
> ---
> drivers/video/fbdev/core/fbcon.c | 13 +
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index 8f971de35885..814b648e8f09 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -942,7 +942,7 @@ static const char *fbcon_startup(void)
> return display_desc;
> /*
>* Instead of blindly using registered_fb[0], we use info_idx, set by
> - * fb_console_init();
> + * fbcon_fb_registered();
>*/
This comment change looks like it does not belong in this patch.
Also, the comment is wrong as info_idx is set in several places.
Like set_con2fb_map(), fbcon_remap_all(), and more.
Though it is not set by fb_console_init - so partly OK.
With the comment adjustment dropped.
Acked-by: Sam Ravnborg
at least the code deletion looked OK, I failed to follow all the logic.
So would be good if someone else could ack it too.
Sam
> info = registered_fb[info_idx];
> if (!info)
> @@ -3316,17 +3316,6 @@ static void fbcon_start(void)
> return;
> }
> #endif
> -
> - if (num_registered_fb) {
> - int i;
> -
> - for_each_registered_fb(i) {
> - info_idx = i;
> - break;
> - }
> -
> - do_fbcon_takeover(0);
> - }
> }
>
> static void fbcon_exit(void)
> --
> 2.33.0
[PATCH AUTOSEL 5.4 07/15] drm: panel-orientation-quirks: Add quirk for the 1Netbook OneXPlayer
From: Raymond Jay Golo
[ Upstream commit d3cbc6e323c9299d10c8d2e4127c77c7d05d07b1 ]
The 1Netbook OneXPlayer uses a panel which has been mounted
90 degrees rotated. Add a quirk for this.
Signed-off-by: Raymond Jay Golo
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20220113000619.90988-1-rjg...@gmail.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 9d1bd8f491ad7..448c2f2d803a6 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -115,6 +115,12 @@ static const struct drm_dmi_panel_orientation_data
lcd1280x1920_rightside_up = {
.orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
};
+static const struct drm_dmi_panel_orientation_data lcd1600x2560_leftside_up = {
+ .width = 1600,
+ .height = 2560,
+ .orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP,
+};
+
static const struct dmi_system_id orientation_data[] = {
{ /* Acer One 10 (S1003) */
.matches = {
@@ -261,6 +267,12 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Default string"),
},
.driver_data = (void *)_pro,
+ }, {/* OneXPlayer */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ONE-NETBOOK TECHNOLOGY CO.,
LTD."),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "ONE XPLAYER"),
+ },
+ .driver_data = (void *)_leftside_up,
}, {/* Samsung GalaxyBook 10.6 */
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO.,
LTD."),
--
2.34.1
[PATCH AUTOSEL 5.10 10/25] drm: panel-orientation-quirks: Add quirk for the 1Netbook OneXPlayer
From: Raymond Jay Golo
[ Upstream commit d3cbc6e323c9299d10c8d2e4127c77c7d05d07b1 ]
The 1Netbook OneXPlayer uses a panel which has been mounted
90 degrees rotated. Add a quirk for this.
Signed-off-by: Raymond Jay Golo
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20220113000619.90988-1-rjg...@gmail.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 9d1bd8f491ad7..448c2f2d803a6 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -115,6 +115,12 @@ static const struct drm_dmi_panel_orientation_data
lcd1280x1920_rightside_up = {
.orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
};
+static const struct drm_dmi_panel_orientation_data lcd1600x2560_leftside_up = {
+ .width = 1600,
+ .height = 2560,
+ .orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP,
+};
+
static const struct dmi_system_id orientation_data[] = {
{ /* Acer One 10 (S1003) */
.matches = {
@@ -261,6 +267,12 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Default string"),
},
.driver_data = (void *)_pro,
+ }, {/* OneXPlayer */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ONE-NETBOOK TECHNOLOGY CO.,
LTD."),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "ONE XPLAYER"),
+ },
+ .driver_data = (void *)_leftside_up,
}, {/* Samsung GalaxyBook 10.6 */
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO.,
LTD."),
--
2.34.1
[PATCH AUTOSEL 5.15 35/41] drm/amd/display: Correct MPC split policy for DCN301
From: Zhan Liu
[ Upstream commit ac46d93235074a6c5d280d35771c23fd8620e7d9 ]
[Why]
DCN301 has seamless boot enabled. With MPC split enabled
at the same time, system will hang.
[How]
Revert MPC split policy back to "MPC_SPLIT_AVOID". Since we have
ODM combine enabled on DCN301, pipe split is not necessary here.
Signed-off-by: Zhan Liu
Reviewed-by: Charlene Liu
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c
index 9e2f18a0c9483..26ebe00a55f67 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c
@@ -863,7 +863,7 @@ static const struct dc_debug_options debug_defaults_drv = {
.disable_clock_gate = true,
.disable_pplib_clock_request = true,
.disable_pplib_wm_range = true,
- .pipe_split_policy = MPC_SPLIT_DYNAMIC,
+ .pipe_split_policy = MPC_SPLIT_AVOID,
.force_single_disp_pipe_split = false,
.disable_dcc = DCC_ENABLE,
.vsr_support = true,
--
2.34.1
[PATCH AUTOSEL 5.15 19/41] drm/vc4: Fix deadlock on DSI device attach error
From: Padmanabha Srinivasaiah
[ Upstream commit 0a3d12ab5097b1d045e693412e6b366b7e82031b ]
DSI device attach to DSI host will be done with host device's lock
held.
Un-registering host in "device attach" error path (ex: probe retry)
will result in deadlock with below call trace and non operational
DSI display.
Startup Call trace:
[ 35.043036] rt_mutex_slowlock.constprop.21+0x184/0x1b8
[ 35.043048] mutex_lock_nested+0x7c/0xc8
[ 35.043060] device_del+0x4c/0x3e8
[ 35.043075] device_unregister+0x20/0x40
[ 35.043082] mipi_dsi_remove_device_fn+0x18/0x28
[ 35.043093] device_for_each_child+0x68/0xb0
[ 35.043105] mipi_dsi_host_unregister+0x40/0x90
[ 35.043115] vc4_dsi_host_attach+0xf0/0x120 [vc4]
[ 35.043199] mipi_dsi_attach+0x30/0x48
[ 35.043209] tc358762_probe+0x128/0x164 [tc358762]
[ 35.043225] mipi_dsi_drv_probe+0x28/0x38
[ 35.043234] really_probe+0xc0/0x318
[ 35.043244] __driver_probe_device+0x80/0xe8
[ 35.043254] driver_probe_device+0xb8/0x118
[ 35.043263] __device_attach_driver+0x98/0xe8
[ 35.043273] bus_for_each_drv+0x84/0xd8
[ 35.043281] __device_attach+0xf0/0x150
[ 35.043290] device_initial_probe+0x1c/0x28
[ 35.043300] bus_probe_device+0xa4/0xb0
[ 35.043308] deferred_probe_work_func+0xa0/0xe0
[ 35.043318] process_one_work+0x254/0x700
[ 35.043330] worker_thread+0x4c/0x448
[ 35.043339] kthread+0x19c/0x1a8
[ 35.043348] ret_from_fork+0x10/0x20
Shutdown Call trace:
[ 365.565417] Call trace:
[ 365.565423] __switch_to+0x148/0x200
[ 365.565452] __schedule+0x340/0x9c8
[ 365.565467] schedule+0x48/0x110
[ 365.565479] schedule_timeout+0x3b0/0x448
[ 365.565496] wait_for_completion+0xac/0x138
[ 365.565509] __flush_work+0x218/0x4e0
[ 365.565523] flush_work+0x1c/0x28
[ 365.565536] wait_for_device_probe+0x68/0x158
[ 365.565550] device_shutdown+0x24/0x348
[ 365.565561] kernel_restart_prepare+0x40/0x50
[ 365.565578] kernel_restart+0x20/0x70
[ 365.565591] __do_sys_reboot+0x10c/0x220
[ 365.565605] __arm64_sys_reboot+0x2c/0x38
[ 365.565619] invoke_syscall+0x4c/0x110
[ 365.565634] el0_svc_common.constprop.3+0xfc/0x120
[ 365.565648] do_el0_svc+0x2c/0x90
[ 365.565661] el0_svc+0x4c/0xf0
[ 365.565671] el0t_64_sync_handler+0x90/0xb8
[ 365.565682] el0t_64_sync+0x180/0x184
Signed-off-by: Padmanabha Srinivasaiah
Signed-off-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/20220118005127.29015-1-treasure4pa...@gmail.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/vc4/vc4_dsi.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index a185027911ce5..d09c1ea60c04e 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -1262,7 +1262,6 @@ static int vc4_dsi_host_attach(struct mipi_dsi_host *host,
struct mipi_dsi_device *device)
{
struct vc4_dsi *dsi = host_to_dsi(host);
- int ret;
dsi->lanes = device->lanes;
dsi->channel = device->channel;
@@ -1297,18 +1296,15 @@ static int vc4_dsi_host_attach(struct mipi_dsi_host
*host,
return 0;
}
- ret = component_add(>pdev->dev, _dsi_ops);
- if (ret) {
- mipi_dsi_host_unregister(>dsi_host);
- return ret;
- }
-
- return 0;
+ return component_add(>pdev->dev, _dsi_ops);
}
static int vc4_dsi_host_detach(struct mipi_dsi_host *host,
struct mipi_dsi_device *device)
{
+ struct vc4_dsi *dsi = host_to_dsi(host);
+
+ component_del(>pdev->dev, _dsi_ops);
return 0;
}
@@ -1706,9 +1702,7 @@ static int vc4_dsi_dev_remove(struct platform_device
*pdev)
struct device *dev = >dev;
struct vc4_dsi *dsi = dev_get_drvdata(dev);
- component_del(>dev, _dsi_ops);
mipi_dsi_host_unregister(>dsi_host);
-
return 0;
}
--
2.34.1
[PATCH AUTOSEL 5.15 20/41] drm: panel-orientation-quirks: Add quirk for the 1Netbook OneXPlayer
From: Raymond Jay Golo
[ Upstream commit d3cbc6e323c9299d10c8d2e4127c77c7d05d07b1 ]
The 1Netbook OneXPlayer uses a panel which has been mounted
90 degrees rotated. Add a quirk for this.
Signed-off-by: Raymond Jay Golo
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20220113000619.90988-1-rjg...@gmail.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 9d1bd8f491ad7..448c2f2d803a6 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -115,6 +115,12 @@ static const struct drm_dmi_panel_orientation_data
lcd1280x1920_rightside_up = {
.orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
};
+static const struct drm_dmi_panel_orientation_data lcd1600x2560_leftside_up = {
+ .width = 1600,
+ .height = 2560,
+ .orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP,
+};
+
static const struct dmi_system_id orientation_data[] = {
{ /* Acer One 10 (S1003) */
.matches = {
@@ -261,6 +267,12 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Default string"),
},
.driver_data = (void *)_pro,
+ }, {/* OneXPlayer */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ONE-NETBOOK TECHNOLOGY CO.,
LTD."),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "ONE XPLAYER"),
+ },
+ .driver_data = (void *)_leftside_up,
}, {/* Samsung GalaxyBook 10.6 */
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO.,
LTD."),
--
2.34.1
[PATCH AUTOSEL 5.16 40/52] drm/amdgpu/display: use msleep rather than udelay for long delays
From: Alex Deucher
[ Upstream commit 98fdcacb45f7cd2092151d6af2e60152811eb79c ]
Some architectures (e.g., ARM) throw an compilation error if the
udelay is too long. In general udelays of longer than 2000us are
not recommended on any architecture. Switch to msleep in these
cases.
Reviewed-by: Harry Wentland
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index 01ac1a64c78b9..d1b47c0d7791a 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -6038,7 +6038,7 @@ bool dpcd_write_128b_132b_sst_payload_allocation_table(
}
}
retries++;
- udelay(5000);
+ msleep(5);
}
if (!result && retries == max_retries) {
@@ -6090,7 +6090,7 @@ bool dpcd_poll_for_allocation_change_trigger(struct
dc_link *link)
break;
}
- udelay(5000);
+ msleep(5);
}
if (result == ACT_FAILED) {
--
2.34.1
[PATCH AUTOSEL 5.16 39/52] drm/amdgpu/display: adjust msleep limit in dp_wait_for_training_aux_rd_interval
From: Alex Deucher
[ Upstream commit dc919d670c6fd1ac81ebf31625cd19579f7b3d4c ]
Some architectures (e.g., ARM) have relatively low udelay limits.
On most architectures, anything longer than 2000us is not recommended.
Change the check to align with other similar checks in DC.
Reviewed-by: Harry Wentland
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index 13bc69d6b6791..01ac1a64c78b9 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -201,7 +201,7 @@ void dp_wait_for_training_aux_rd_interval(
uint32_t wait_in_micro_secs)
{
#if defined(CONFIG_DRM_AMD_DC_DCN)
- if (wait_in_micro_secs > 16000)
+ if (wait_in_micro_secs > 1000)
msleep(wait_in_micro_secs/1000);
else
udelay(wait_in_micro_secs);
--
2.34.1
[PATCH AUTOSEL 5.16 38/52] drm/amd/display: Correct MPC split policy for DCN301
From: Zhan Liu
[ Upstream commit ac46d93235074a6c5d280d35771c23fd8620e7d9 ]
[Why]
DCN301 has seamless boot enabled. With MPC split enabled
at the same time, system will hang.
[How]
Revert MPC split policy back to "MPC_SPLIT_AVOID". Since we have
ODM combine enabled on DCN301, pipe split is not necessary here.
Signed-off-by: Zhan Liu
Reviewed-by: Charlene Liu
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c
index e472b729d8690..8af80bc05b364 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c
@@ -686,7 +686,7 @@ static const struct dc_debug_options debug_defaults_drv = {
.disable_clock_gate = true,
.disable_pplib_clock_request = true,
.disable_pplib_wm_range = true,
- .pipe_split_policy = MPC_SPLIT_DYNAMIC,
+ .pipe_split_policy = MPC_SPLIT_AVOID,
.force_single_disp_pipe_split = false,
.disable_dcc = DCC_ENABLE,
.vsr_support = true,
--
2.34.1
[PATCH AUTOSEL 5.16 20/52] drm: panel-orientation-quirks: Add quirk for the 1Netbook OneXPlayer
From: Raymond Jay Golo
[ Upstream commit d3cbc6e323c9299d10c8d2e4127c77c7d05d07b1 ]
The 1Netbook OneXPlayer uses a panel which has been mounted
90 degrees rotated. Add a quirk for this.
Signed-off-by: Raymond Jay Golo
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20220113000619.90988-1-rjg...@gmail.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 042bb80383c93..b910978d3e480 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -115,6 +115,12 @@ static const struct drm_dmi_panel_orientation_data
lcd1280x1920_rightside_up = {
.orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
};
+static const struct drm_dmi_panel_orientation_data lcd1600x2560_leftside_up = {
+ .width = 1600,
+ .height = 2560,
+ .orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP,
+};
+
static const struct dmi_system_id orientation_data[] = {
{ /* Acer One 10 (S1003) */
.matches = {
@@ -275,6 +281,12 @@ static const struct dmi_system_id orientation_data[] = {
DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Default string"),
},
.driver_data = (void *)_pro,
+ }, {/* OneXPlayer */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ONE-NETBOOK TECHNOLOGY CO.,
LTD."),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "ONE XPLAYER"),
+ },
+ .driver_data = (void *)_leftside_up,
}, {/* Samsung GalaxyBook 10.6 */
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO.,
LTD."),
--
2.34.1
Re: [PATCH 04/21] fbcon: delete a few unneeded forward decl
On Mon, Jan 31, 2022 at 10:05:35PM +0100, Daniel Vetter wrote: > I didn't bother with any code movement to fix the others, these just > got a bit in the way. > > Signed-off-by: Daniel Vetter > Cc: Helge Deller > Cc: Daniel Vetter > Cc: Thomas Zimmermann > Cc: Du Cheng > Cc: Tetsuo Handa > Cc: Claudio Suarez > Cc: Greg Kroah-Hartman Acked-by: Sam Ravnborg
[PATCH AUTOSEL 5.16 19/52] drm/vc4: Fix deadlock on DSI device attach error
From: Padmanabha Srinivasaiah
[ Upstream commit 0a3d12ab5097b1d045e693412e6b366b7e82031b ]
DSI device attach to DSI host will be done with host device's lock
held.
Un-registering host in "device attach" error path (ex: probe retry)
will result in deadlock with below call trace and non operational
DSI display.
Startup Call trace:
[ 35.043036] rt_mutex_slowlock.constprop.21+0x184/0x1b8
[ 35.043048] mutex_lock_nested+0x7c/0xc8
[ 35.043060] device_del+0x4c/0x3e8
[ 35.043075] device_unregister+0x20/0x40
[ 35.043082] mipi_dsi_remove_device_fn+0x18/0x28
[ 35.043093] device_for_each_child+0x68/0xb0
[ 35.043105] mipi_dsi_host_unregister+0x40/0x90
[ 35.043115] vc4_dsi_host_attach+0xf0/0x120 [vc4]
[ 35.043199] mipi_dsi_attach+0x30/0x48
[ 35.043209] tc358762_probe+0x128/0x164 [tc358762]
[ 35.043225] mipi_dsi_drv_probe+0x28/0x38
[ 35.043234] really_probe+0xc0/0x318
[ 35.043244] __driver_probe_device+0x80/0xe8
[ 35.043254] driver_probe_device+0xb8/0x118
[ 35.043263] __device_attach_driver+0x98/0xe8
[ 35.043273] bus_for_each_drv+0x84/0xd8
[ 35.043281] __device_attach+0xf0/0x150
[ 35.043290] device_initial_probe+0x1c/0x28
[ 35.043300] bus_probe_device+0xa4/0xb0
[ 35.043308] deferred_probe_work_func+0xa0/0xe0
[ 35.043318] process_one_work+0x254/0x700
[ 35.043330] worker_thread+0x4c/0x448
[ 35.043339] kthread+0x19c/0x1a8
[ 35.043348] ret_from_fork+0x10/0x20
Shutdown Call trace:
[ 365.565417] Call trace:
[ 365.565423] __switch_to+0x148/0x200
[ 365.565452] __schedule+0x340/0x9c8
[ 365.565467] schedule+0x48/0x110
[ 365.565479] schedule_timeout+0x3b0/0x448
[ 365.565496] wait_for_completion+0xac/0x138
[ 365.565509] __flush_work+0x218/0x4e0
[ 365.565523] flush_work+0x1c/0x28
[ 365.565536] wait_for_device_probe+0x68/0x158
[ 365.565550] device_shutdown+0x24/0x348
[ 365.565561] kernel_restart_prepare+0x40/0x50
[ 365.565578] kernel_restart+0x20/0x70
[ 365.565591] __do_sys_reboot+0x10c/0x220
[ 365.565605] __arm64_sys_reboot+0x2c/0x38
[ 365.565619] invoke_syscall+0x4c/0x110
[ 365.565634] el0_svc_common.constprop.3+0xfc/0x120
[ 365.565648] do_el0_svc+0x2c/0x90
[ 365.565661] el0_svc+0x4c/0xf0
[ 365.565671] el0t_64_sync_handler+0x90/0xb8
[ 365.565682] el0t_64_sync+0x180/0x184
Signed-off-by: Padmanabha Srinivasaiah
Signed-off-by: Maxime Ripard
Link:
https://patchwork.freedesktop.org/patch/msgid/20220118005127.29015-1-treasure4pa...@gmail.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/vc4/vc4_dsi.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index a229da58962a2..9300d3354c512 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -1262,7 +1262,6 @@ static int vc4_dsi_host_attach(struct mipi_dsi_host *host,
struct mipi_dsi_device *device)
{
struct vc4_dsi *dsi = host_to_dsi(host);
- int ret;
dsi->lanes = device->lanes;
dsi->channel = device->channel;
@@ -1297,18 +1296,15 @@ static int vc4_dsi_host_attach(struct mipi_dsi_host
*host,
return 0;
}
- ret = component_add(>pdev->dev, _dsi_ops);
- if (ret) {
- mipi_dsi_host_unregister(>dsi_host);
- return ret;
- }
-
- return 0;
+ return component_add(>pdev->dev, _dsi_ops);
}
static int vc4_dsi_host_detach(struct mipi_dsi_host *host,
struct mipi_dsi_device *device)
{
+ struct vc4_dsi *dsi = host_to_dsi(host);
+
+ component_del(>pdev->dev, _dsi_ops);
return 0;
}
@@ -1686,9 +1682,7 @@ static int vc4_dsi_dev_remove(struct platform_device
*pdev)
struct device *dev = >dev;
struct vc4_dsi *dsi = dev_get_drvdata(dev);
- component_del(>dev, _dsi_ops);
mipi_dsi_host_unregister(>dsi_host);
-
return 0;
}
--
2.34.1
Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
Hi Daniel, On Mon, Jan 31, 2022 at 10:05:32PM +0100, Daniel Vetter wrote: > Ever since Tomi extracted the core code in 2014 it's been defacto me > maintaining this, with help from others from dri-devel and sometimes > Linus (but those are mostly merge conflicts): > > $ git shortlog -ns drivers/video/fbdev/core/ | head -n5 > 35 Daniel Vetter > 23 Linus Torvalds > 10 Hans de Goede > 9 Dave Airlie > 6 Peter Rosin > > I think ideally we'd also record that the various firmware fb drivers > (efifb, vesafb, ...) are also maintained in drm-misc because for the > past few years the patches have either been to fix handover issues > with drm drivers, or caused handover issues with drm drivers. So any > other tree just doesn't make sense. But also, there's plenty of > outdated MAINTAINER entries for these with people and git trees that > haven't been active in years, so maybe let's just leave them alone. > And furthermore distros are now adopting simpledrm as the firmware fb > driver, so hopefully the need to care about the fbdev firmware drivers > will go down going forward. > > Note that drm-misc is group maintained, I expect that to continue like > we've done before, so no new expectations that patches all go through > my hands. That would be silly. This also means I'm happy to put any > other volunteer's name in the M: line, but otherwise git log says I'm > the one who's stuck with this. > > Cc: Dave Airlie > Cc: Jani Nikula > Cc: Linus Torvalds > Cc: Linux Fbdev development list > Cc: Pavel Machek > Cc: Sam Ravnborg > Cc: Greg Kroah-Hartman > Cc: Javier Martinez Canillas > Cc: DRI Development > Cc: Linux Kernel Mailing List > Cc: Claudio Suarez > Cc: Tomi Valkeinen > Cc: Geert Uytterhoeven > Cc: Thomas Zimmermann > Cc: Daniel Vetter > Cc: Sven Schnelle > Cc: Gerd Hoffmann > Signed-off-by: Daniel Vetter > --- > MAINTAINERS | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index ea3e6c914384..49809eaa3096 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -7573,6 +7573,12 @@ S: Maintained > W: http://floatingpoint.sourceforge.net/emulator/index.html > F: arch/x86/math-emu/ > > +FRAMEBUFFER CORE > +M: Daniel Vetter > +F: drivers/video/fbdev/core/ Maybe add: include/linux/fb.h include/uapi/linux/fb.h Both edited within some months - so they see a little changes. With or without this: Acked-by: Sam Ravnborg
Re: [PATCH v2] drm/panel: Select DRM_DP_HELPER for DRM_PANEL_EDP
On Thu, Feb 03, 2022 at 10:39:22AM +0100, Thomas Zimmermann wrote:
> As reported in [1], DRM_PANEL_EDP depends on DRM_DP_HELPER. Select
> the option to fix the build failure. The error message is shown
> below.
>
> arm-linux-gnueabihf-ld: drivers/gpu/drm/panel/panel-edp.o: in function
> `panel_edp_probe': panel-edp.c:(.text+0xb74): undefined reference to
> `drm_panel_dp_aux_backlight'
> make[1]: *** [/builds/linux/Makefile:1222: vmlinux] Error 1
>
> The issue has been reported before, when DisplayPort helpers were
> hidden behind the option CONFIG_DRM_KMS_HELPER. [2]
>
> v2:
> * fix and expand commit description (Arnd)
>
> Signed-off-by: Thomas Zimmermann
> Fixes: adb9d5a2cc77 ("drm/dp: Move DisplayPort helpers into separate helper
> module")
> Fixes: 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of panel-simple")
> Reported-by: Naresh Kamboju
> Reported-by: Linux Kernel Functional Testing
> Link:
> https://lore.kernel.org/dri-devel/CA+G9fYvN0NyaVkRQmA1O6rX7H8PPaZrUAD7=rdy33qy9ruu...@mail.gmail.com/
> # [1]
> Link:
> https://lore.kernel.org/all/2027062704.14671-1-rdun...@infradead.org/ #
> [2]
> Cc: Thomas Zimmermann
> Cc: Lyude Paul
> Cc: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: dri-devel@lists.freedesktop.org
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/panel/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 434c2861bb40..0aec5a10b064 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -106,6 +106,7 @@ config DRM_PANEL_EDP
> depends on PM
> select VIDEOMODE_HELPERS
> select DRM_DP_AUX_BUS
> + select DRM_DP_HELPER
> help
> DRM panel driver for dumb eDP panels that need at most a regulator and
> a GPIO to be powered up. Optionally a backlight can be attached so
> --
> 2.34.1
Re: [PATCH v5 6/6] drm/vc4: hdmi: Support HDMI YUV output
On Thu, Jan 27, 2022 at 03:10:21PM +0100, Maxime Ripard wrote:
> +/*
> + * Conversion between Full Range RGB and Full Range YUV444 using the
> + * BT.709 Colorspace
> + *
> + * [ -0.117208 -0.394207 0.511416 128 ]
> + * [ 0.511416 -0.464524 -0.046891 128 ]
> + * [ 0.212639 0.715169 0.072192 0 ]
> + *
> + * Matrix is signed 2p13 fixed point, with signed 9p6 offsets
> + */
> +static const u16 vc5_hdmi_csc_full_rgb_to_full_yuv444_bt709[3][4] = {
I think YCbCr output is supposed to be limited range. Or at least
that was the case with DP. For HDMI/CTA IIRC the spec is super
unclear/confusing when it talks about the YCC quantizaton range
stuff.
Currently i915 will only do limited range BT.709 YCbCr output.
> + { 0xfc41, 0xf364, 0x105e, 0x2000 },
> + { 0x105e, 0xf124, 0xfe81, 0x2000 },
> + { 0x06ce, 0x16e3, 0x024f, 0x },
> +};
> +
> static void vc5_hdmi_set_csc_coeffs(struct vc4_hdmi *vc4_hdmi,
> const u16 coeffs[3][4])
> {
> @@ -1323,11 +1534,56 @@ vc4_hdmi_encoder_compute_clock(const struct vc4_hdmi
> *vc4_hdmi,
> return 0;
> }
>
> +static int
> +vc4_hdmi_encoder_compute_format(const struct vc4_hdmi *vc4_hdmi,
> + struct vc4_hdmi_connector_state *vc4_state,
> + const struct drm_display_mode *mode,
> + unsigned int bpc)
> +{
> + struct drm_device *dev = vc4_hdmi->connector.dev;
> + const struct drm_connector *connector = _hdmi->connector;
> + const struct drm_display_info *info = >display_info;
> + unsigned int format;
> +
> + drm_dbg(dev, "Trying with an RGB output\n");
> +
> + format = VC4_HDMI_OUTPUT_RGB;
> + if (vc4_hdmi_sink_supports_format_bpc(vc4_hdmi, info, mode, format,
> bpc)) {
> + int ret;
> +
> + ret = vc4_hdmi_encoder_compute_clock(vc4_hdmi, vc4_state,
> + mode, bpc, format);
> + if (!ret) {
> + vc4_state->output_format = format;
> + return 0;
> + }
> + }
You seem to have the bpc vs. format selection in the opposite order to
i915. We try to exhaust all RGB color depths first, and only then fall
back to YCbCr 4:2:0. The automagic YCbCr 4:2:0 fallback is only
really there because without it you may not be able to light up the
display at all (at least if you want the higher resolutions).
With the current i915 logic 4:2:2 doesn't make any sense since it has
the same requirements as 8bpc RGB. Hence we don't even implement
YCbCr 4:2:2 (also hw didn't have it until recently). There has
occasionally been some talk about introducing a new property
to give the user explicit control over this stuff. If/when that
happens I guess we might want to revisit the 4:2:2 situation for
i915.
> +
> + drm_dbg(dev, "Failed, Trying with an YUV422 output\n");
> +
> + format = VC4_HDMI_OUTPUT_YUV422;
> + if (vc4_hdmi_sink_supports_format_bpc(vc4_hdmi, info, mode, format,
> bpc)) {
> + int ret;
> +
> + ret = vc4_hdmi_encoder_compute_clock(vc4_hdmi, vc4_state,
> + mode, bpc, format);
> + if (!ret) {
> + vc4_state->output_format = format;
> + return 0;
> + }
> + }
> +
> + drm_dbg(dev, "Failed. No Format Supported for that bpc count.\n");
> +
> + return -EINVAL;
> +}
> +
--
Ville Syrjälä
Intel
[PATCH v4 2/4] drm/i915/gt: Drop invalidate_csb_entries
Drop invalidate_csb_entries and directly call drm_clflush_virt_range.
This allows for one less function call, and prevent complier errors when
building for non-x86 architectures.
v2(Michael Cheng): Drop invalidate_csb_entries function and directly
invoke drm_clflush_virt_range. Thanks to Tvrtko for the
sugguestion.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 9bb7c863172f..7500c06562da 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -1646,12 +1646,6 @@ cancel_port_requests(struct intel_engine_execlists *
const execlists,
return inactive;
}
-static void invalidate_csb_entries(const u64 *first, const u64 *last)
-{
- clflush((void *)first);
- clflush((void *)last);
-}
-
/*
* Starting with Gen12, the status has a new format:
*
@@ -1999,7 +1993,7 @@ process_csb(struct intel_engine_cs *engine, struct
i915_request **inactive)
* the wash as hardware, working or not, will need to do the
* invalidation before.
*/
- invalidate_csb_entries([0], [num_entries - 1]);
+ drm_clflush_virt_range([0], num_entries * sizeof(buf[0]));
/*
* We assume that any event reflects a change in context flow
@@ -2783,8 +2777,8 @@ static void reset_csb_pointers(struct intel_engine_cs
*engine)
/* Check that the GPU does indeed update the CSB entries! */
memset(execlists->csb_status, -1, (reset_value + 1) * sizeof(u64));
- invalidate_csb_entries(>csb_status[0],
- >csb_status[reset_value]);
+ drm_clflush_virt_range(>csb_status[0],
+ sizeof(>csb_status[reset_value]));
/* Once more for luck and our trusty paranoia */
ENGINE_WRITE(engine, RING_CONTEXT_STATUS_PTR,
--
2.25.1
[PATCH v4 4/4] drm/i915/: Re-work clflush_write32
Use drm_clflush_virt_range instead of clflushopt and remove the memory
barrier, since drm_clflush_virt_range takes care of that.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 498b458fd784..0854276ff7ba 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1332,10 +1332,8 @@ static void *reloc_vaddr(struct i915_vma *vma,
static void clflush_write32(u32 *addr, u32 value, unsigned int flushes)
{
if (unlikely(flushes & (CLFLUSH_BEFORE | CLFLUSH_AFTER))) {
- if (flushes & CLFLUSH_BEFORE) {
- clflushopt(addr);
- mb();
- }
+ if (flushes & CLFLUSH_BEFORE)
+ drm_clflush_virt_range(addr, sizeof(addr));
*addr = value;
@@ -1347,7 +1345,7 @@ static void clflush_write32(u32 *addr, u32 value,
unsigned int flushes)
* to ensure ordering of clflush wrt to the system.
*/
if (flushes & CLFLUSH_AFTER)
- clflushopt(addr);
+ drm_clflush_virt_range(addr, sizeof(addr));
} else
*addr = value;
}
--
2.25.1
[PATCH v4 3/4] drm/i915/gt: Re-work reset_csb
Use drm_clflush_virt_range instead of directly invoking clflush. This
will prevent compiler errors when building for non-x86 architectures.
v2(Michael Cheng): Remove extra clflush
v3(Michael Cheng): Remove memory barrier since drm_clflush_virt_range
takes care of it.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 7500c06562da..22505aa428d9 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -2944,9 +2944,8 @@ reset_csb(struct intel_engine_cs *engine, struct
i915_request **inactive)
{
struct intel_engine_execlists * const execlists = >execlists;
- mb(); /* paranoia: read the CSB pointers from after the reset */
- clflush(execlists->csb_write);
- mb();
+ drm_clflush_virt_range(execlists->csb_write,
+ sizeof(execlists->csb_write));
inactive = process_csb(engine, inactive); /* drain preemption events */
--
2.25.1
[PATCH v4 0/4] Use drm_clflush* instead of clflush
This patch series re-work a few i915 functions to use drm_clflush_virt_range instead of calling clflush or clflushopt directly. This will prevent errors when building for non-x86 architectures. v2: s/PAGE_SIZE/sizeof(value) for Re-work intel_write_status_page and added more patches to convert additional clflush/clflushopt to use drm_clflush*. (Michael Cheng) v3: Drop invalidate_csb_entries and directly invoke drm_clflush_virt_ran v4: Remove extra memory barriers Michael Cheng (4): drm/i915/gt: Re-work intel_write_status_page drm/i915/gt: Drop invalidate_csb_entries drm/i915/gt: Re-work reset_csb drm/i915/: Re-work clflush_write32 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 +++- drivers/gpu/drm/i915/gt/intel_engine.h | 13 - .../drm/i915/gt/intel_execlists_submission.c| 17 + 3 files changed, 12 insertions(+), 26 deletions(-) -- 2.25.1
[PATCH v4 1/4] drm/i915/gt: Re-work intel_write_status_page
Re-work intel_write_status_page to use drm_clflush_virt_range. This
will prevent compiler errors when building for non-x86 architectures.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gt/intel_engine.h | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 0e353d8c2bc8..986777c2430d 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -4,6 +4,7 @@
#include
#include
+#include
#include
#include
@@ -143,15 +144,9 @@ intel_write_status_page(struct intel_engine_cs *engine,
int reg, u32 value)
* of extra paranoia to try and ensure that the HWS takes the value
* we give and that it doesn't end up trapped inside the CPU!
*/
- if (static_cpu_has(X86_FEATURE_CLFLUSH)) {
- mb();
- clflush(>status_page.addr[reg]);
- engine->status_page.addr[reg] = value;
- clflush(>status_page.addr[reg]);
- mb();
- } else {
- WRITE_ONCE(engine->status_page.addr[reg], value);
- }
+ drm_clflush_virt_range(>status_page.addr[reg], sizeof(value));
+ WRITE_ONCE(engine->status_page.addr[reg], value);
+ drm_clflush_virt_range(>status_page.addr[reg], sizeof(value));
}
/*
--
2.25.1
Re: [PATCH v5 2/6] drm/vc4: hdmi: Move clock calculation into its own function
On Thu, Jan 27, 2022 at 03:10:17PM +0100, Maxime Ripard wrote:
> The code to compute our clock rate for a given setup will be called in
> multiple places in the next patches, so let's create a separate function
> for it.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 49 +++---
> 1 file changed, 34 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 105911644b02..a1fa37ad350d 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -1274,6 +1274,35 @@ vc4_hdmi_encoder_clock_valid(const struct vc4_hdmi
> *vc4_hdmi,
> return MODE_OK;
> }
>
> +static unsigned long long
> +vc4_hdmi_encoder_compute_mode_clock(const struct drm_display_mode *mode,
> + unsigned int bpc)
> +{
> + unsigned long long clock = mode->clock * 1000;
> +
> + if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> + clock = clock * 2;
> +
> + return clock * bpc / 8;
div_u64()/etc.?
> +}
> +
> +static int
> +vc4_hdmi_encoder_compute_clock(const struct vc4_hdmi *vc4_hdmi,
> +struct vc4_hdmi_connector_state *vc4_state,
> +const struct drm_display_mode *mode,
> +unsigned int bpc)
> +{
> + unsigned long long clock;
> +
> + clock = vc4_hdmi_encoder_compute_mode_clock(mode, bpc);
> + if (vc4_hdmi_encoder_clock_valid(vc4_hdmi, clock) != MODE_OK)
> + return -EINVAL;
> +
> + vc4_state->pixel_rate = clock;
This thing seems a bit confused between pixels vs. TMDS characters.
Either that or some/all of the pixel_clock/rate things are just
misnamed?
> +
> + return 0;
> +}
> +
> #define WIFI_2_4GHz_CH1_MIN_FREQ 24ULL
> #define WIFI_2_4GHz_CH1_MAX_FREQ 242200ULL
>
> @@ -1286,6 +1315,7 @@ static int vc4_hdmi_encoder_atomic_check(struct
> drm_encoder *encoder,
> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> unsigned long long pixel_rate = mode->clock * 1000;
> unsigned long long tmds_rate;
> + int ret;
>
> if (vc4_hdmi->variant->unsupported_odd_h_timings &&
> ((mode->hdisplay % 2) || (mode->hsync_start % 2) ||
> @@ -1306,21 +1336,10 @@ static int vc4_hdmi_encoder_atomic_check(struct
> drm_encoder *encoder,
> pixel_rate = mode->clock * 1000;
> }
>
> - if (conn_state->max_bpc == 12) {
> - pixel_rate = pixel_rate * 150;
> - do_div(pixel_rate, 100);
> - } else if (conn_state->max_bpc == 10) {
> - pixel_rate = pixel_rate * 125;
> - do_div(pixel_rate, 100);
> - }
> -
> - if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> - pixel_rate = pixel_rate * 2;
> -
> - if (vc4_hdmi_encoder_clock_valid(vc4_hdmi, pixel_rate) != MODE_OK)
> - return -EINVAL;
> -
> - vc4_state->pixel_rate = pixel_rate;
> + ret = vc4_hdmi_encoder_compute_clock(vc4_hdmi, vc4_state, mode,
> + conn_state->max_bpc);
> + if (ret)
> + return ret;
>
> return 0;
> }
> --
> 2.34.1
--
Ville Syrjälä
Intel
Re: Linux 5.16.3 breaks headless Raspberry Pi 3 boot, again
Hi Maxime, maxime at cerno.tech (Maxime Ripard) writes: > I'm not entirely sure what you expect by insisting on things getting > broken *again*, but we got it, thanks. I wanted to remind of the previous issue, which had the same symptoms, and hence might be related and helpful in debugging. Upon further reading, I realize it came across as annoyed and accusatory, and for that I apologize. Sorry. It was not my intention. While we’re on the subject, though, I do wonder whether anything could be improved to catch issues like this one before the kernel is released in the future? Are you not testing this driver on the Raspberry Pi 3? I don’t know what the testing process for this driver, or Linux more broadly, looks like in detail, so I’m curious to learn more. > For some reason, in the stable commit, pm_runtime_put ended up in > vc4_hdmi_cec_init while it should have been at the end of > vc4_hdmi_cec_adap_enable. > > I'll send a patch to fix it. Thanks for identifying and getting this addressed so quickly! -- Best regards, Michael
Re: [PATCH 8/8] drm/ast: Move SIL164-based connector code into separate helpers
On 1/11/22 13:00, Thomas Zimmermann wrote:
> Add helpers for initializing SIL164-based connectors. These used to be
> handled by the VGA connector code. But SIL164 provides output via DVI-I,
> so set the encoder and connector types accordingly.
>
> If a SIL164 chip has been detected, ast will now create a DVI-I
> connector instead of a VGA connector.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/ast/ast_drv.h | 15 ++
> drivers/gpu/drm/ast/ast_mode.c | 99 +-
> 2 files changed, 112 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
> index 420d19d8459e..c3a582372649 100644
> --- a/drivers/gpu/drm/ast/ast_drv.h
> +++ b/drivers/gpu/drm/ast/ast_drv.h
> @@ -140,6 +140,17 @@ to_ast_vga_connector(struct drm_connector *connector)
> return container_of(connector, struct ast_vga_connector, base);
> }
>
[snip]
> +static int ast_sil164_connector_init(struct drm_device *dev,
> + struct ast_sil164_connector
> *ast_sil164_connector)
> +{
> + struct drm_connector *connector = _sil164_connector->base;
> + int ret;
> +
> + ast_sil164_connector->i2c = ast_i2c_create(dev);
> + if (!ast_sil164_connector->i2c)
> + drm_err(dev, "failed to add ddc bus for connector\n");
> +
> + if (ast_sil164_connector->i2c)
> + ret = drm_connector_init_with_ddc(dev, connector,
> _sil164_connector_funcs,
> + DRM_MODE_CONNECTOR_DVII,
> +
> _sil164_connector->i2c->adapter);
> + else
> + ret = drm_connector_init(dev, connector,
> _sil164_connector_funcs,
> + DRM_MODE_CONNECTOR_DVII);
> + if (ret)
I think you want a kfree(i2c) here before returning.
And where is the struct ast_i2c_chan freed if the function succeeds ?
With that,
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
Re: [PATCH v16 33/40] soc/tegra: pmc: Enable core domain support for Tegra20 and Tegra30
On Wed, Dec 01, 2021 at 02:23:40AM +0300, Dmitry Osipenko wrote: > All device drivers got runtime PM and OPP support. Flip the core domain > support status for Tegra20 and Tegra30 SoCs. > > Reviewed-by: Ulf Hansson > Signed-off-by: Dmitry Osipenko > --- > drivers/soc/tegra/pmc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Applied now. I'll give it a few days in linux-next and will then send a PR with this for ARM SoC. Thierry signature.asc Description: PGP signature
Re: [PATCH 7/8] drm/ast: Move DP501-based connector code into separate helpers
On 1/11/22 13:00, Thomas Zimmermann wrote: > Add helpers for DP501-based connectors. DP501 provides output via > DisplayPort. This used to be handled by the VGA connector code. > > If a DP501 chip has been detected, ast will now create a DisplayPort > connector instead of a VGA connector. > > Remove the DP501 code from ast_vga_connector_helper_get_modes(). Also > remove the call to drm_connector_update_edid_property(), which is > performed by drm_get_edid(). > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH] drm/i915: Flip guc_id allocation partition
On Wed, Feb 02, 2022 at 11:15:00PM +0100, Michal Wajdeczko wrote: > > > On 13.01.2022 17:27, Matthew Brost wrote: > > Move the multi-lrc guc_id from the lower allocation partition (0 to > > number of multi-lrc guc_ids) to upper allocation partition (number of > > single-lrc to max guc_ids). > > > > This will help when a native driver transitions to a PF after driver > > load time. If the perma-pin guc_ids (kernel contexts) are in a low range > > it is easy reduce total number of guc_ids as the allocated slrc are in a > > valid range the mlrc range moves to an unused range. Assuming no mlrc > > are allocated and few slrc are used the native to PF transition is > > seamless for the guc_id resource. > > > > v2: > > (Michal / Tvrtko) > > - Add an explaination to commit message of why this patch is needed > > (Michal / Piotr) > > - Replace marcos with functions > > (Michal) > > - Rework logic flow in new_mlrc_guc_id > > - Unconditionally call bitmap_free > > v3: > > (Michal) > > - Move allocation of mlrc bitmap back submission init > > (CI) > > - Resend for CI > > > > Signed-off-by: Matthew Brost > > --- > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 77 ++- > > 1 file changed, 56 insertions(+), 21 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c > > index 23a40f10d376d..fce58365b3ff8 100644 > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c > > @@ -138,17 +138,6 @@ guc_create_parallel(struct intel_engine_cs **engines, > > > > #define GUC_REQUEST_SIZE 64 /* bytes */ > > > > -/* > > - * We reserve 1/16 of the guc_ids for multi-lrc as these need to be > > contiguous > > - * per the GuC submission interface. A different allocation algorithm is > > used > > - * (bitmap vs. ida) between multi-lrc and single-lrc hence the reason to > > - * partition the guc_id space. We believe the number of multi-lrc contexts > > in > > - * use should be low and 1/16 should be sufficient. Minimum of 32 guc_ids > > for > > - * multi-lrc. > > - */ > > -#define NUMBER_MULTI_LRC_GUC_ID(guc) \ > > - ((guc)->submission_state.num_guc_ids / 16) > > - > > /* > > * Below is a set of functions which control the GuC scheduling state which > > * require a lock. > > @@ -1746,6 +1735,7 @@ void intel_guc_submission_reset_finish(struct > > intel_guc *guc) > > } > > > > static void destroyed_worker_func(struct work_struct *w); > > +static int number_mlrc_guc_id(struct intel_guc *guc); > > > > /* > > * Set up the memory resources to be shared with the GuC (via the GGTT) > > @@ -1778,7 +1768,7 @@ int intel_guc_submission_init(struct intel_guc *guc) > > destroyed_worker_func); > > > > guc->submission_state.guc_ids_bitmap = > > - bitmap_zalloc(NUMBER_MULTI_LRC_GUC_ID(guc), GFP_KERNEL); > > + bitmap_zalloc(number_mlrc_guc_id(guc), GFP_KERNEL); > > to fully benefit from the id partition flip we likely will have to > allocate bitmap 'just-in-time' when first mlrc id is needed > No. At worst over allocate memory and don't use it. At the current ratio, number_mlrc_guc_id is 4k translates into a 1 page allocation. > so something like you had in early rev but abandon to avoid alloc inside > spinlock - but I'm wondering why we can't alloc bitmap for mlrc case, > while we allow allocation for slrc (as ida_simple_get may alloc, no? > That is a good question, more on that below. > > if (!guc->submission_state.guc_ids_bitmap) > > return -ENOMEM; > > > > @@ -1864,6 +1854,57 @@ static void guc_submit_request(struct i915_request > > *rq) > > spin_unlock_irqrestore(_engine->lock, flags); > > } > > > > +/* > > + * We reserve 1/16 of the guc_ids for multi-lrc as these need to be > > contiguous > > + * per the GuC submission interface. A different allocation algorithm is > > used > > + * (bitmap vs. ida) between multi-lrc and single-lrc hence the reason to > > + * partition the guc_id space. We believe the number of multi-lrc contexts > > in > > + * use should be low and 1/16 should be sufficient. > > do we have any other numbers as guideline ? > > while it is easy assumption that 1/16 from 64K contexts may be > sufficient, what about 1/16 of 1K contexts ? will that work too ? > Nope, just random split I choose. We might need to change this ratio on a VF or enforce a minimum of mlrc (e.g. 128). Easy enough to tune as needed. > also, do we have to make hard split ? what if there will be no users for > mlrc but more slrc contexts would be beneficial ? or the opposite ? > Hard split manages complexity. Could we cook some dynamic sharing algorith, sure. Would be it be overly complex and unnecessary, almost certainly. The only thing I can see changing is the ratio on a VF if needed. > > + */ > > +#define MLRC_GUC_ID_RATIO 16 > > + > > +static int
Re: [PATCH 6/8] drm/ast: Initialize encoder and connector for VGA in helper function
On 1/11/22 13:00, Thomas Zimmermann wrote: > Move encoder and connector initialization into a single helper and > put all related mode-setting structures into a single place. Done in > preparation of moving transmitter code into separate helpers. No > functional changes. > > Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas [snip] > - encoder->possible_crtcs = 1; [snip] > + encoder->possible_crtcs = drm_crtc_mask(crtc); This is a somewhat unrelated change. It's OK because is fairly simple but I would probably still do the cleanups as separate patches. Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
[PATCH v4 2/4] drm/i915/gt: Drop invalidate_csb_entries
Drop invalidate_csb_entries and directly call drm_clflush_virt_range.
This allows for one less function call, and prevent complier errors when
building for non-x86 architectures.
v2(Michael Cheng): Drop invalidate_csb_entries function and directly
invoke drm_clflush_virt_range. Thanks to Tvrtko for the
sugguestion.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 9bb7c863172f..7500c06562da 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -1646,12 +1646,6 @@ cancel_port_requests(struct intel_engine_execlists *
const execlists,
return inactive;
}
-static void invalidate_csb_entries(const u64 *first, const u64 *last)
-{
- clflush((void *)first);
- clflush((void *)last);
-}
-
/*
* Starting with Gen12, the status has a new format:
*
@@ -1999,7 +1993,7 @@ process_csb(struct intel_engine_cs *engine, struct
i915_request **inactive)
* the wash as hardware, working or not, will need to do the
* invalidation before.
*/
- invalidate_csb_entries([0], [num_entries - 1]);
+ drm_clflush_virt_range([0], num_entries * sizeof(buf[0]));
/*
* We assume that any event reflects a change in context flow
@@ -2783,8 +2777,8 @@ static void reset_csb_pointers(struct intel_engine_cs
*engine)
/* Check that the GPU does indeed update the CSB entries! */
memset(execlists->csb_status, -1, (reset_value + 1) * sizeof(u64));
- invalidate_csb_entries(>csb_status[0],
- >csb_status[reset_value]);
+ drm_clflush_virt_range(>csb_status[0],
+ sizeof(>csb_status[reset_value]));
/* Once more for luck and our trusty paranoia */
ENGINE_WRITE(engine, RING_CONTEXT_STATUS_PTR,
--
2.25.1
[PATCH v4 0/4] Use drm_clflush* instead of clflush
This patch series re-work a few i915 functions to use drm_clflush_virt_range instead of calling clflush or clflushopt directly. This will prevent errors when building for non-x86 architectures. v2: s/PAGE_SIZE/sizeof(value) for Re-work intel_write_status_page and added more patches to convert additional clflush/clflushopt to use drm_clflush*. (Michael Cheng) v3: Drop invalidate_csb_entries and directly invoke drm_clflush_virt_ran v4: Remove extra memory barriers Michael Cheng (4): drm/i915/gt: Re-work intel_write_status_page drm/i915/gt: Drop invalidate_csb_entries drm/i915/gt: Re-work reset_csb drm/i915/: Re-work clflush_write32 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 +++- drivers/gpu/drm/i915/gt/intel_engine.h | 13 - .../drm/i915/gt/intel_execlists_submission.c| 17 + 3 files changed, 12 insertions(+), 26 deletions(-) -- 2.25.1
[PATCH v4 4/4] drm/i915/: Re-work clflush_write32
Use drm_clflush_virt_range instead of clflushopt and remove the memory
barrier, since drm_clflush_virt_range takes care of that.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 498b458fd784..0854276ff7ba 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1332,10 +1332,8 @@ static void *reloc_vaddr(struct i915_vma *vma,
static void clflush_write32(u32 *addr, u32 value, unsigned int flushes)
{
if (unlikely(flushes & (CLFLUSH_BEFORE | CLFLUSH_AFTER))) {
- if (flushes & CLFLUSH_BEFORE) {
- clflushopt(addr);
- mb();
- }
+ if (flushes & CLFLUSH_BEFORE)
+ drm_clflush_virt_range(addr, sizeof(addr));
*addr = value;
@@ -1347,7 +1345,7 @@ static void clflush_write32(u32 *addr, u32 value,
unsigned int flushes)
* to ensure ordering of clflush wrt to the system.
*/
if (flushes & CLFLUSH_AFTER)
- clflushopt(addr);
+ drm_clflush_virt_range(addr, sizeof(addr));
} else
*addr = value;
}
--
2.25.1
[PATCH v4 3/4] drm/i915/gt: Re-work reset_csb
Use drm_clflush_virt_range instead of directly invoking clflush. This
will prevent compiler errors when building for non-x86 architectures.
v2(Michael Cheng): Remove extra clflush
v3(Michael Cheng): Remove memory barrier since drm_clflush_virt_range
takes care of it.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 7500c06562da..22505aa428d9 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -2944,9 +2944,8 @@ reset_csb(struct intel_engine_cs *engine, struct
i915_request **inactive)
{
struct intel_engine_execlists * const execlists = >execlists;
- mb(); /* paranoia: read the CSB pointers from after the reset */
- clflush(execlists->csb_write);
- mb();
+ drm_clflush_virt_range(execlists->csb_write,
+ sizeof(execlists->csb_write));
inactive = process_csb(engine, inactive); /* drain preemption events */
--
2.25.1
[PATCH v4 1/4] drm/i915/gt: Re-work intel_write_status_page
Re-work intel_write_status_page to use drm_clflush_virt_range. This
will prevent compiler errors when building for non-x86 architectures.
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/i915/gt/intel_engine.h | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 0e353d8c2bc8..986777c2430d 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -4,6 +4,7 @@
#include
#include
+#include
#include
#include
@@ -143,15 +144,9 @@ intel_write_status_page(struct intel_engine_cs *engine,
int reg, u32 value)
* of extra paranoia to try and ensure that the HWS takes the value
* we give and that it doesn't end up trapped inside the CPU!
*/
- if (static_cpu_has(X86_FEATURE_CLFLUSH)) {
- mb();
- clflush(>status_page.addr[reg]);
- engine->status_page.addr[reg] = value;
- clflush(>status_page.addr[reg]);
- mb();
- } else {
- WRITE_ONCE(engine->status_page.addr[reg], value);
- }
+ drm_clflush_virt_range(>status_page.addr[reg], sizeof(value));
+ WRITE_ONCE(engine->status_page.addr[reg], value);
+ drm_clflush_virt_range(>status_page.addr[reg], sizeof(value));
}
/*
--
2.25.1
RE: [RFC v2 00/22] Add Support for Plane Color Lut and CSC features
> -Original Message- > From: dri-devel On Behalf Of Harry > Wentland > Sent: Wednesday, February 2, 2022 9:42 PM > To: Shankar, Uma ; intel-...@lists.freedesktop.org; > dri- > de...@lists.freedesktop.org > Cc: sebast...@sebastianwick.net; shashank.sha...@amd.com > Subject: Re: [RFC v2 00/22] Add Support for Plane Color Lut and CSC features > > > > On 2021-09-06 17:38, Uma Shankar wrote: > > This is how a typical display color hardware pipeline looks like: > > +---+ > > |RAM| > > | +--++-++-+ | > > | | FB 1 || FB 2 || FB N| | > > | +--++-++-+ | > > +---+ > >| Plane Color Hardware Block | > > ++ > > | +---v-+ +---v---+ +---v--+ | > > | | Plane A | | Plane B | | Plane N | | > > | | DeGamma | | Degamma | | Degamma | | > > | +---+-+ +---+---+ +---+--+ | > > | | | || > > | +---v-+ +---v---+ +---v--+ | > > | |Plane A | | Plane B | | Plane N | | > > | |CSC/CTM | | CSC/CTM | | CSC/CTM | | > > | +---+-+ ++--+ ++-+ | > > | | | | | > > | +---v-+ +v--+ +v-+ | > > | | Plane A | | Plane B | | Plane N | | > > | | Gamma | | Gamma | | Gamma| | > > | +---+-+ ++--+ ++-+ | > > We've had a number of discussions on naming for these properties but I don't > think > we've arrived at a consensus. It has come up repeatedly, though, that > gamma/degamma might be misleading terms. > > I've opened a ticket on gitlab to help track this item and would like it if > we could > discuss the merits of different naming schemes over > there: > > https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/7 > > Uma, I tried to tag you but don't see you on gitlab.freedesktop.org. Thanks Harry for creating the issue. I have replied there and we can discuss and finalize the UAPI. Regards, Uma Shankar > Harry > > > | | | | | > > ++ > > +--v--v---v---| > > || || > > || Pipe Blender|| > > +++ > > ||| > > |+---v--+ | > > || Pipe DeGamma| | > > || | | > > |+---+--+ | > > ||Pipe Color | > > |+---v--+ Hardware| > > || Pipe CSC/CTM| | > > || | | > > |+---+--+ | > > ||| > > |+---v--+ | > > || Pipe Gamma | | > > || | | > > |+---+--+ | > > ||| > > +-+ > > | > > v > >Pipe Output > > > > This patch series adds properties for plane color features. It adds > > properties for degamma used to linearize data and CSC used for gamut > > conversion. It also includes Gamma support used to again non-linearize > > data as per panel supported color space. These can be utilize by user > > space to convert planes from one format to another, one color space to > > another etc. > > > > Userspace can take smart blending decisions and utilize these hardware > > supported plane color features to get accurate color profile. The same > > can help in consistent color quality from source to panel taking > > advantage of advanced color features in hardware. > > > > These patches add the property interfaces and enable helper functions. > > This series adds Intel's XE_LPD hw specific plane gamma feature. We > > can build up and add other platform/hardware specific implementation > > on top of this series. > > > > Credits: Special mention and credits to Ville Syrjala for coming up > > with a design for this feature and inputs. This series is based on his > > original design and idea. > > > > Note: Userspace support for this new UAPI will be done on Chrome in > > alignment with weston and general opensource community. > > Discussion ongoing with Harry Wentland, Pekka and community on color > > pipeline and UAPI design. Harry's RFC below: > > https://patchwork.freedesktop.org/series/89506/ > > We need to converge on a common UAPI interface which caters to
Re: [PATCH -next] drm/amdkfd: Fix resource_size.cocci warning
Am 2022-02-03 um 00:04 schrieb Yang Li: Use resource_size function on resource object instead of explicit computation. Eliminate the following coccicheck warning: ./drivers/gpu/drm/amd/amdkfd/kfd_migrate.c:978:11-14: ERROR: Missing resource_size with res Reported-by: Abaci Robot Signed-off-by: Yang Li This patch was already applied in September: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0de5472a01804f43b7c8ddb1132bbfeb8b68674f Which branch is this for? Regards, Felix --- drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c index 8430f6475723..d4287a39be56 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c @@ -975,7 +975,7 @@ int svm_migrate_init(struct amdgpu_device *adev) pgmap->type = 0; if (pgmap->type == MEMORY_DEVICE_PRIVATE) devm_release_mem_region(adev->dev, res->start, - res->end - res->start + 1); + resource_size(res)); return PTR_ERR(r); }
Re: [PATCH 5/8] drm/ast: Rename struct ast_connector to struct ast_vga_connector
On 1/11/22 13:00, Thomas Zimmermann wrote: > Prepare for introducing other connectors besides VGA. No functional > changes. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH] HPE BMC GXP SUPPORT
> Maybe it does not look like, but this is actually a v2. Nick was asked > to change the naming for the nodes already in v1. Unfortunately it did > not happen, so we have vuart, spifi, vic and more. > It is a waste of reviewers' time to ask them to perform the same review > twice or to ignore their comments. Hi Krysztof, Accept our apologies if you think you lose your time, it is clearly not our intent. This is the first time that we (I mean the team) introduce a new arch into the linux kernel and I must admit that we had hard time to understand from which angle we needed to start. I will probably write a Documentation afterward, as it is easy to find doc on how to introduce a patch or a driver, but not when you want to introduce a new chip. We are trying to do our best, and clearly want to follow all of your inputs. Mistakes happen and they are clearly not intentional and not driven in a way to make you lose your time. Helping others, and teaching something new is definitely a way to optimize your time and this is what you are currently doing with us. We appreciate it and hope you will too. vejmarie > Best regards, > Krzysztof
Re: [PATCH 4/8] drm/ast: Remove unused value dp501_maxclk
On 1/11/22 13:00, Thomas Zimmermann wrote: > Remove reading the link-rate. The value is maintained by the connector > code but never used. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH 3/8] drm/ast: Remove AST_TX_ITE66121 constant
On 1/11/22 13:00, Thomas Zimmermann wrote: > The ITE66121 is an HDMI transmitter chip. There's no code for > detecting or programming the chip within ast. Remove the enum > constant. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH 2/8] drm/ast: Move connector mode_valid function to CRTC
On 1/11/22 13:00, Thomas Zimmermann wrote: > The tests in ast_mode_valid() verify the correct resolution for the > supplied mode. This is a limitation of the CRTC, so move the function > to the CRTC helpers. No functional changes. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH 1/8] drm/ast: Fail if connector initialization fails
Hello Thomas, On 1/11/22 13:00, Thomas Zimmermann wrote: > Update the connector code to fail if the connector could not be > initialized. The current code just ignored the error and failed > later when the connector was supposed to be used. > > Signed-off-by: Thomas Zimmermann > --- Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Linux Engineering Red Hat
Re: [PATCH v6 1/3] drm/lsdc: add drm driver for loongson display controller
+static int lsdc_primary_plane_atomic_check(struct drm_plane *plane,
+ struct drm_atomic_state *state)
+{
+ struct drm_device *ddev = plane->dev;
+ struct lsdc_device *ldev = to_lsdc(ddev);
+ struct drm_plane_state *old_plane_state =
drm_atomic_get_old_plane_state(state, plane);
+ struct drm_plane_state *new_plane_state =
drm_atomic_get_new_plane_state(state, plane);
+ struct drm_framebuffer *new_fb = new_plane_state->fb;
+ struct drm_framebuffer *old_fb = old_plane_state->fb;
+ struct drm_crtc *crtc = new_plane_state->crtc;
+ u32 new_format = new_fb->format->format;
+ struct drm_crtc_state *new_crtc_state;
+ struct lsdc_crtc_state *priv_crtc_state;
+ int ret;
+
+ if (!crtc)
+ return 0;
+
+ new_crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+ if (WARN_ON(!new_crtc_state))
+ return -EINVAL;
+
+ priv_crtc_state = to_lsdc_crtc_state(new_crtc_state);
+
+ ret = drm_atomic_helper_check_plane_state(new_plane_state,
+ new_crtc_state,
+ DRM_PLANE_HELPER_NO_SCALING,
+ DRM_PLANE_HELPER_NO_SCALING,
+ false,
+ true);
+ if (ret)
+ return ret;
+
+ /*
+* Require full modeset if enabling or disabling a plane,
+* or changing its position, size, depth or format.
+*/
+ if ((!new_fb || !old_fb ||
+old_plane_state->crtc_x != new_plane_state->crtc_x ||
+old_plane_state->crtc_y != new_plane_state->crtc_y ||
+old_plane_state->crtc_w != new_plane_state->crtc_w ||
+old_plane_state->crtc_h != new_plane_state->crtc_h ||
+old_fb->format->format != new_format))
+ new_crtc_state->mode_changed = true;
+
+
+ priv_crtc_state->pix_fmt = lsdc_primary_get_default_format(crtc);
Storing the pixel format in the CRTC state is weird? What would happen
if you have a primary plane and a cursor in different formats?
Also, reading the default format from a register doesn't look right.
atomic_check can occur at any time, including before a previous commit,
or while the hardware is disabled. You should rely on either a constant
or the previous state here.
Currently, private CRTC state(priv_crtc_state) is not get used by the cursor's
atomic_check() and atomic_update(). I means this is only for the primary plane.
And both and the primary and the cursor using XRGB format, what I really
want here is let the atomic_update to update the framebuffer's format, because
the firmware (pmon) of some board set the framebuffer's format as RGB565.
If the hardware's format is same with the plane state, then there is no need to
update the FB's format register, save a function call, right?
When the plane is disabled the drm core will call the atomic_disable()
function, right?
I will reconsider this, thank for your advice and i will correct other problems
at the next version. Thanks for you take time review my patch again.
Re: [PATCH v6 1/3] drm/lsdc: add drm driver for loongson display controller
+static enum drm_mode_status
+lsdc_crtc_helper_mode_valid(struct drm_crtc *crtc,
+ const struct drm_display_mode *mode)
+{
+ struct drm_device *ddev = crtc->dev;
+ struct lsdc_device *ldev = to_lsdc(ddev);
+ const struct lsdc_chip_desc *desc = ldev->desc;
+
+ if (mode->hdisplay > desc->max_width)
+ return MODE_BAD_HVALUE;
+ if (mode->vdisplay > desc->max_height)
+ return MODE_BAD_VVALUE;
+
+ if (mode->clock > desc->max_pixel_clk) {
+ drm_dbg_kms(ddev, "mode %dx%d, pixel clock=%d is too high\n",
+ mode->hdisplay, mode->vdisplay, mode->clock);
+ return MODE_CLOCK_HIGH;
+ }
+
+ /* the crtc hardware dma take 256 bytes once a time
+* TODO: check RGB565 support
+*/
+ if ((mode->hdisplay * 4) % desc->stride_alignment) {
+ drm_dbg_kms(ddev, "stride is not %u bytes aligned\n",
+ desc->stride_alignment);
+ return MODE_BAD;
+ }
+
+ return MODE_OK;
+}
mode_valid will only prevent the mode from being advertised to the
userspace, but you need atomic_check if you want to prevent those modes
to be used by anybody.
Yes, I used to change mode with mate-display-properties tools,
what I though is the end user can't see it, they can't set it.
I will add atomic_check() support at next version, thanks.
+
+static void lsdc_update_pixclk(struct drm_crtc *crtc, unsigned int pixclk,
bool verbose)
+{
+ struct lsdc_display_pipe *dispipe;
+ struct lsdc_pll *pixpll;
+ const struct lsdc_pixpll_funcs *clkfun;
+ struct lsdc_crtc_state *priv_crtc_state;
+
+ priv_crtc_state = to_lsdc_crtc_state(crtc->state);
+
+ dispipe = container_of(crtc, struct lsdc_display_pipe, crtc);
+ pixpll = >pixpll;
+ clkfun = pixpll->funcs;
+
+ /* config the pixel pll */
+ clkfun->update(pixpll, _crtc_state->pparams);
+
+ if (verbose)
+ clkfun->print(pixpll, pixclk);
+}
+
+
+static void lsdc_crtc_helper_mode_set_nofb(struct drm_crtc *crtc)
+{
+ struct drm_device *ddev = crtc->dev;
+ struct lsdc_device *ldev = to_lsdc(ddev);
+ struct drm_display_mode *mode = >state->adjusted_mode;
+ unsigned int hr = mode->hdisplay;
+ unsigned int hss = mode->hsync_start;
+ unsigned int hse = mode->hsync_end;
+ unsigned int hfl = mode->htotal;
+ unsigned int vr = mode->vdisplay;
+ unsigned int vss = mode->vsync_start;
+ unsigned int vse = mode->vsync_end;
+ unsigned int vfl = mode->vtotal;
+ unsigned int pixclock = mode->clock;
+ unsigned int index = drm_crtc_index(crtc);
+
+
+ if (index == 0) {
+ /* CRTC 0 */
+ u32 hsync, vsync;
+
+ lsdc_reg_write32(ldev, LSDC_CRTC0_FB_ORIGIN_REG, 0);
+
+ /* 26:16 total pixels, 10:0 visiable pixels, in horizontal */
+ lsdc_reg_write32(ldev, LSDC_CRTC0_HDISPLAY_REG,
+ (mode->crtc_htotal << 16) | mode->crtc_hdisplay);
+
+ /* 26:16 total pixels, 10:0 visiable pixels, in vertical */
+ lsdc_reg_write32(ldev, LSDC_CRTC0_VDISPLAY_REG,
+ (mode->crtc_vtotal << 16) | mode->crtc_vdisplay);
+
+ /* 26:16 hsync end, 10:0 hsync start */
+ hsync = (mode->crtc_hsync_end << 16) | mode->crtc_hsync_start;
+
+ if (mode->flags & DRM_MODE_FLAG_NHSYNC)
+ hsync |= INV_HSYNC_BIT;
+
+ lsdc_reg_write32(ldev, LSDC_CRTC0_HSYNC_REG, EN_HSYNC_BIT |
hsync);
+
+ /* 26:16 vsync end, 10:0 vsync start */
+ vsync = (mode->crtc_vsync_end << 16) | mode->crtc_vsync_start;
+
+ if (mode->flags & DRM_MODE_FLAG_NVSYNC)
+ vsync |= INV_VSYNC_BIT;
+
+ lsdc_reg_write32(ldev, LSDC_CRTC0_VSYNC_REG, EN_VSYNC_BIT |
vsync);
+
+ } else if (index == 1) {
+ /* CRTC 1 */
+ u32 hsync, vsync;
+
+ lsdc_reg_write32(ldev, LSDC_CRTC1_FB_ORIGIN_REG, 0);
+
+ /* 26:16 total pixels, 10:0 visiable pixels, in horizontal */
+ lsdc_reg_write32(ldev, LSDC_CRTC1_HDISPLAY_REG,
+ (mode->crtc_htotal << 16) | mode->crtc_hdisplay);
+
+ /* 26:16 total pixels, 10:0 visiable pixels, in vertical */
+ lsdc_reg_write32(ldev, LSDC_CRTC1_VDISPLAY_REG,
+ (mode->crtc_vtotal << 16) | mode->crtc_vdisplay);
+
+ /* 26:16 hsync end, 10:0 hsync start */
+ hsync = (mode->crtc_hsync_end << 16) | mode->crtc_hsync_start;
+
+ if (mode->flags & DRM_MODE_FLAG_NHSYNC)
+ hsync |= INV_HSYNC_BIT;
+
+ lsdc_reg_write32(ldev, LSDC_CRTC1_HSYNC_REG, EN_HSYNC_BIT |
hsync);
+
+ /* 26:16 vsync end, 10:0 vsync
[PATCH] drm/i915: Add fallback inside memcpy_from_wc functions
memcpy_from_wc functions can fail if SSE4.1 is not supported or the
supplied addresses are not 16-byte aligned. It was then upto to the
caller to use memcpy as fallback.
Now fallback to memcpy is implemented inside memcpy_from_wc functions
relieving the user from checking the return value of i915_memcpy_from_wc
and doing fallback.
When doing copying from io memory address memcpy_fromio should be used
as fallback. So a new function is added to the family of memcpy_to_wc
functions which should be used while copying from io memory.
This change is implemented also with an intention to perpare for porting
memcpy_from_wc code to ARM64. Since SSE4.1 is not valid for ARM,
accelerated reads will not be supported and the driver should rely on
fallback always.
So there would be few more places in the code where fallback should be
introduced. For e.g. GuC log relay is currently not using fallback since
a GPU supporting GuC submission will mostly have SSE4.1 enabled CPU.
This is no more valid with Discrete GPU and with enabling support for
ARM64.
With fallback moved inside memcpy_from_wc function, call sites would
look neat and fallback can be implemented in a uniform way.
Signed-off-by: Balasubramani Vivekanandan
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 3 +-
drivers/gpu/drm/i915/gt/selftest_reset.c | 8 ++-
drivers/gpu/drm/i915/i915_gpu_error.c | 9 ++-
drivers/gpu/drm/i915/i915_memcpy.c | 78 --
drivers/gpu/drm/i915/i915_memcpy.h | 18 ++---
5 files changed, 77 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index e03e362d320b..b139a88fce70 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -452,8 +452,7 @@ i915_gem_object_read_from_page_iomap(struct
drm_i915_gem_object *obj, u64 offset
PAGE_SIZE);
src_ptr = src_map + offset_in_page(offset);
- if (!i915_memcpy_from_wc(dst, (void __force *)src_ptr, size))
- memcpy_fromio(dst, src_ptr, size);
+ i915_io_memcpy_from_wc(dst, src_ptr, size);
io_mapping_unmap(src_map);
}
diff --git a/drivers/gpu/drm/i915/gt/selftest_reset.c
b/drivers/gpu/drm/i915/gt/selftest_reset.c
index 37c38bdd5f47..64b8521a8b28 100644
--- a/drivers/gpu/drm/i915/gt/selftest_reset.c
+++ b/drivers/gpu/drm/i915/gt/selftest_reset.c
@@ -99,8 +99,10 @@ __igt_reset_stolen(struct intel_gt *gt,
memset_io(s, STACK_MAGIC, PAGE_SIZE);
in = (void __force *)s;
- if (i915_memcpy_from_wc(tmp, in, PAGE_SIZE))
+ if (i915_can_memcpy_from_wc(tmp, in, PAGE_SIZE)) {
+ i915_io_memcpy_from_wc(tmp, in, PAGE_SIZE);
in = tmp;
+ }
crc[page] = crc32_le(0, in, PAGE_SIZE);
io_mapping_unmap(s);
@@ -135,8 +137,10 @@ __igt_reset_stolen(struct intel_gt *gt,
PAGE_SIZE);
in = (void __force *)s;
- if (i915_memcpy_from_wc(tmp, in, PAGE_SIZE))
+ if (i915_can_memcpy_from_wc(tmp, in, PAGE_SIZE)) {
+ i915_io_memcpy_from_wc(tmp, in, PAGE_SIZE);
in = tmp;
+ }
x = crc32_le(0, in, PAGE_SIZE);
if (x != crc[page] &&
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index aee42eae4729..90db5de86c25 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -296,8 +296,10 @@ static int compress_page(struct i915_vma_compress *c,
struct z_stream_s *zstream = >zstream;
zstream->next_in = src;
- if (wc && c->tmp && i915_memcpy_from_wc(c->tmp, src, PAGE_SIZE))
+ if (wc && c->tmp && i915_can_memcpy_from_wc(c->tmp, src, PAGE_SIZE)) {
+ i915_io_memcpy_from_wc(c->tmp, src, PAGE_SIZE);
zstream->next_in = c->tmp;
+ }
zstream->avail_in = PAGE_SIZE;
do {
@@ -396,8 +398,11 @@ static int compress_page(struct i915_vma_compress *c,
if (!ptr)
return -ENOMEM;
- if (!(wc && i915_memcpy_from_wc(ptr, src, PAGE_SIZE)))
+ if (wc)
+ i915_io_memcpy_from_wc(ptr, src, PAGE_SIZE);
+ else
memcpy(ptr, src, PAGE_SIZE);
+
list_add_tail(_to_page(ptr)->lru, >page_list);
cond_resched();
diff --git a/drivers/gpu/drm/i915/i915_memcpy.c
b/drivers/gpu/drm/i915/i915_memcpy.c
index 1b021a4902de..b1f8abf35452 100644
--- a/drivers/gpu/drm/i915/i915_memcpy.c
+++ b/drivers/gpu/drm/i915/i915_memcpy.c
@@ -24,15 +24,10 @@
#include
#include
+#include
#include "i915_memcpy.h"
-#if IS_ENABLED(CONFIG_DRM_I915_DEBUG)
-#define CI_BUG_ON(expr) BUG_ON(expr)
-#else
-#define CI_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr)
-#endif
-
[Bug 215511] Dual monitor with amd 5700 causes system to hang at startup.
https://bugzilla.kernel.org/show_bug.cgi?id=215511 --- Comment #6 from Jose Mestre (pmes...@gmail.com) --- Hello, i've tried this patch and it works with 5.15.12#0f591d17e36e08313b0c440b99b0e57b47e01a9a and with 5.17.0-rc2. Kind regards. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v6 1/3] drm/lsdc: add drm driver for loongson display controller
diff --git a/drivers/gpu/drm/lsdc/Makefile b/drivers/gpu/drm/lsdc/Makefile
new file mode 100644
index ..342990654478
--- /dev/null
+++ b/drivers/gpu/drm/lsdc/Makefile
@@ -0,0 +1,15 @@
+#
+# Makefile for the lsdc drm device driver.
+#
+
+lsdc-y := \
+ lsdc_drv.o \
+ lsdc_crtc.o \
+ lsdc_irq.o \
+ lsdc_plane.o \
+ lsdc_pll.o \
+ lsdc_i2c.o \
+ lsdc_encoder.o \
+ lsdc_connector.o
+
+obj-$(CONFIG_DRM_LSDC) += lsdc.o
diff --git a/drivers/gpu/drm/lsdc/lsdc_connector.c
b/drivers/gpu/drm/lsdc/lsdc_connector.c
new file mode 100644
index ..ae5fc0c90961
--- /dev/null
+++ b/drivers/gpu/drm/lsdc/lsdc_connector.c
@@ -0,0 +1,443 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2020 Loongson Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ */
That's the MIT license, yet you claim the driver to be licensed under
the GPLv2 or later?
I just copy then paste it blindly, sorry about that.
I do not know the difference, we want open the source anyway.
I will correct it in next version, thanks.
+
+/*
+ * Authors:
+ * Sui Jingfeng
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "lsdc_drv.h"
+#include "lsdc_i2c.h"
+#include "lsdc_connector.h"
+
+
+static int lsdc_get_modes_from_edid(struct drm_connector *connector)
+{
+ struct drm_device *ddev = connector->dev;
+ struct lsdc_connector *lconn = to_lsdc_connector(connector);
+ struct edid *edid_p = (struct edid *)lconn->edid_data;
+ int num = drm_add_edid_modes(connector, edid_p);
+
+ if (num)
+ drm_connector_update_edid_property(connector, edid_p);
+
+ drm_dbg_kms(ddev, "%d modes added\n", num);
+
+ return num;
+}
+
+
+static int lsdc_get_modes_from_timings(struct drm_connector *connector)
+{
+ struct drm_device *ddev = connector->dev;
+ struct lsdc_connector *lconn = to_lsdc_connector(connector);
+ struct display_timings *disp_tim = lconn->disp_tim;
+ unsigned int num = 0;
+ unsigned int i;
+
+ for (i = 0; i < disp_tim->num_timings; i++) {
+ const struct display_timing *dt = disp_tim->timings[i];
+ struct drm_display_mode *mode;
+ struct videomode vm;
+
+ videomode_from_timing(dt, );
+ mode = drm_mode_create(ddev);
+ if (!mode) {
+ drm_err(ddev, "failed to add mode %ux%u\n",
+ dt->hactive.typ, dt->vactive.typ);
+ continue;
+ }
+
+ drm_display_mode_from_videomode(, mode);
+
+ mode->type |= DRM_MODE_TYPE_DRIVER;
+
+ if (i == disp_tim->native_mode)
+ mode->type |= DRM_MODE_TYPE_PREFERRED;
+
+ drm_mode_probed_add(connector, mode);
+ num++;
+ }
+
+ drm_dbg_kms(ddev, "%d modes added\n", num);
+
+ return num;
+}
+
+
+static int lsdc_get_modes_from_ddc(struct drm_connector *connector,
+ struct i2c_adapter *ddc)
+{
+ unsigned int num = 0;
+ struct edid *edid;
+
+ edid = drm_get_edid(connector, ddc);
+ if (edid) {
+ drm_connector_update_edid_property(connector, edid);
+ num = drm_add_edid_modes(connector, edid);
+ kfree(edid);
+ }
+
+ return num;
+}
+
+
+static int lsdc_get_modes(struct drm_connector *connector)
+{
+ struct lsdc_connector *lconn = to_lsdc_connector(connector);
+ unsigned int num = 0;
+
+ if (lconn->has_edid)
+ return lsdc_get_modes_from_edid(connector);
+
+ if (lconn->has_disp_tim)
+ return lsdc_get_modes_from_timings(connector);
+
+ if (IS_ERR_OR_NULL(lconn->ddc) == false)
+
Re: [PATCH v6 1/3] drm/lsdc: add drm driver for loongson display controller
On 2022/2/3 16:58, Maxime Ripard wrote: diff --git a/drivers/gpu/drm/lsdc/Kconfig b/drivers/gpu/drm/lsdc/Kconfig new file mode 100644 index ..7ed1b0fdbe1b --- /dev/null +++ b/drivers/gpu/drm/lsdc/Kconfig @@ -0,0 +1,38 @@ +config DRM_LSDC + tristate "DRM Support for loongson's display controller" + depends on DRM && PCI + depends on MACH_LOONGSON64 || LOONGARCH || MIPS || COMPILE_TEST + select OF + select CMA if HAVE_DMA_CONTIGUOUS + select DMA_CMA if HAVE_DMA_CONTIGUOUS + select DRM_KMS_HELPER + select DRM_KMS_FB_HELPER + select DRM_GEM_CMA_HELPER + select VIDEOMODE_HELPERS + select BACKLIGHT_PWM if CPU_LOONGSON2K + select I2C_GPIO if CPU_LOONGSON2K + select I2C_LS2X if CPU_LOONGSON2K + default m + help + This is a KMS driver for the display controller in the LS7A1000 + bridge chip and LS2K1000 SoC. The display controller has two + display pipes and it is a PCI device. + When using this driver on LS2K1000/LS2K0500 SoC, its framebuffer + is located at system memory. + If "M" is selected, the module will be called lsdc. + + If in doubt, say "Y". + +config DRM_LSDC_VRAM_DRIVER + bool "vram helper based device driver support" + depends on DRM_LSDC + select DRM_VRAM_HELPER + default y + help + When using this driver on LS7A1000 + LS3A3000/LS3A4000/LS3A5000 + platform, the LS7A1000 bridge chip has dedicated video RAM. Using + "lsdc.use_vram_helper=1" in the kernel command line will enable + this driver mode and then the framebuffer will be located at the + VRAM at the price of losing PRIME support. + + If in doubt, say "Y". This doesn't sound right. The driver should make the proper decision depending on the platform, not the user or the distribution. The LS7A1000 north bridge chip has dedicated video RAM, but the DC in LS7A1000 can also scanout from the system memory directly like a display controller in a SoC does. In fact, this display controller is envolved from early product of Loongson 2H SoC. This driver still works even if the downstream PC board manufacturer doesn't solder a video RAM on the mother board. The lsdc_should_vram_helper_based() function in lsdc_drv.c will examine if the DC device node contain a use_vram_helper property at driver loading time. If there is no use_vram_helper property, CMA helper based DRM driver will be used. Doing this way allow the user using "lsdc.use_vram_helper=0" override the default behavior even through there is a "use_vram_helper;" property in the DTS. In short, It is intend to let the command line passed from kernel has higher priority than the device tree. Otherwise the end user can not switch different driver mode through the kernel command line once the DC device node contain "use_vram_helper;" property. This driver's author already made the decision by the time when the patch is sent out, even through this**may not proper. The CMA helper based driver will be used by default, if the DC device node contain "use_vram_helper;" then VRAM based driver will be used. This is my initial intention.
Re: [PATCH] drm/vc4: crtc: Fix redundant variable assignment
On Thu, Feb 03, 2022 at 04:11:51PM +0100, Maxime Ripard wrote:
> The variable is assigned twice to the same value. Let's drop one.
>
> Reported-by: kernel test robot
> Signed-off-by: Maxime Ripard
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index 287dbc89ad64..e6cc47470e03 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -671,7 +671,6 @@ static int vc4_crtc_atomic_check(struct drm_crtc *crtc,
> const struct drm_display_mode *mode =
> _state->adjusted_mode;
> struct vc4_encoder *vc4_encoder = to_vc4_encoder(encoder);
>
> - mode = _state->adjusted_mode;
> if (vc4_encoder->type == VC4_ENCODER_TYPE_HDMI0) {
> vc4_state->hvs_load = max(mode->clock * mode->hdisplay
> / mode->htotal + 1000,
> mode->clock * 9 / 10) * 1000;
> --
> 2.34.1
Re: [PATCH v6 1/3] drm/lsdc: add drm driver for loongson display controller
On 2022/2/3 16:58, Maxime Ripard wrote: Hi, On Thu, Feb 03, 2022 at 04:25:44PM +0800, Sui Jingfeng wrote: From: suijingfeng There is a display controller in loongson's LS2K1000 SoC and LS7A1000 bridge, and the DC in those chip is a PCI device. This patch provide a minimal support for this display controller which is mainly for graphic environment bring up. This display controller has two display pipes but with only one hardware cursor. Each way has a DVO output interface and the CRTC is able to scanout from 1920x1080 resolution at 60Hz. The maxmium resolution is 2048x2048@60hz. LS2K1000 is a SoC, only system memory is available. Therefore scanout from system memory is the only choice. We prefer the CMA helper base solution because the gc1000 gpu can use etnaviv driver, in this case etnaviv and lsdc could made a compatible pair. Even through it is possible to use VRAM helper base solution on ls2k1000 by carving out part of system memory as VRAM. For LS7A1000, there are 4 gpios whos control register is located at the dc register space which is not the geneal purpose GPIO. The 4 gpios can emulate two way i2c. One for DVO0, another for DVO1. This is the reason the why we are not using the drm bridge framework. LS2K1000 and LS2K0500 SoC don't have such hardware, they use general purpose GPIO emulated i2c or hardware i2c adapter from other module to serve this purpose. Drm bridge and drm panel is suitable for those SoC, we have already implement it on our own downstream kernel. But due to the upstream kernel don't have gpio, pwm and i2c driver support for LS2K1000. We just can not upstream our support for the drm bridge subsystem. The DC in LS7A1000 can scanout from both the system memory and the dedicate VRAM attached to the ddr3 memory controller. Sadly, only scanout from the VRAM is proved to be a reliable solution for massive product. Scanout from the system memory suffer from some hardware deficiency which cause the screen flickering under RAM pressure. This is the reason why we integrate two distict helpers into one piece of device driver. But CMA base helper is still usable on ls7a1000 for normal usage, expecially on ls7a1000+ bridge chip. We have also implemented demage update on top of CMA helper which copy the demaged shadow framebuffer region from system RAM to the real framebuffer in VRAM manually. Using "lsdc.dirty_update=1" in the commmand line will enable this driver mode. LS7A1000 have a 32x32 harware cursor, we just let the two CRTC share it simply with the help of universe plane. LS7A2000 have two 64x64 harware cursor. Surport for LS7A2000 is on the way. In short, we have built-in gpio emulated i2c support, we also have hardware cursor support. The kind of tiny drivers in drm/tiny is not suitable for us, we are not "tiny". +--+ HyperTransport 3.0 | DDR4 | | +--+ | ++ || MC0 | | LS7A1000+| +--+ | | |DDR3| +--+ | LS3A4000 |<->| ++ +---+ | memory |<->| VRAM | | CPU|<->| | GC1000 | | LSDC | | controller | +--+ +--+ | ++ +-+---+-+ +| || MC1+---|---|+ +--+ | | | DDR4 | +---+DVO0 | | DVO1 +--+ +--+ VGA <--|ADV7125|<-+ +--->|TFP410|--> DVI/HDMI +---+ +--+ The above picture give a simple usage of LS7A1000, note that the encoder is not necessary adv7125 or tfp410, it is a choice of the downstream board manufacturer. Other candicate encoder can be ch7034b, sil9022 and ite66121 etc. Therefore, we need device tree to provide board specific information. Besides, the dc in both ls2k1000 and ls7k1000 have the vendor:device id of 0x0014:0x7a06, the reverison id is also same. We can't tell it apart simply (this is the firmware engineer's mistake). But firmware already flushed to the board and borad already sold out, we choose to resolve those issues by introduing device tree with board specific device support. For lsdc, there is only a 1:1 mapping of encoders and connectors. +---+ _ | | | | | CRTC0 --> DVO0 -> Encoder0 --> Connector0 ---> | Monitor | | | ^^|_| | | || |<- i2c0 + | LSDC IP CORE| |<- i2c1 + | | || _ | | ||| | | CRTC1 --> DVO1 ->
[PATCH] drm/ast: fix using freed memory
From: Tom Rix
clang static analysis reports this problem
ast_mode.c:1235:3: warning: Use of memory after it is freed
drm_connector_update_edid_property(_connector->base, edid);
^~
The second condition on
if (!flags && ast_connector->i2c)
Means that the edid is not always set. If the previous block
fails the freed edid value will be used. So set edid to NULL
after freeing.
Fixes: 55dc449a7c60 ("drm/ast: Handle failed I2C initialization gracefully")
Signed-off-by: Tom Rix
---
drivers/gpu/drm/ast/ast_mode.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index ab52efb15670e..9131dc8a1a2fc 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -1224,10 +1224,12 @@ static int ast_get_modes(struct drm_connector
*connector)
return -ENOMEM;
flags = ast_dp501_read_edid(connector->dev, (u8 *)edid);
- if (flags)
+ if (flags) {
ast->dp501_maxclk =
ast_get_dp501_max_clk(connector->dev);
- else
+ } else {
kfree(edid);
+ edid = NULL;
+ }
}
if (!flags && ast_connector->i2c)
edid = drm_get_edid(connector, _connector->i2c->adapter);
--
2.26.3
[PATCH] drm/vc4: crtc: Fix redundant variable assignment
The variable is assigned twice to the same value. Let's drop one.
Reported-by: kernel test robot
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 287dbc89ad64..e6cc47470e03 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -671,7 +671,6 @@ static int vc4_crtc_atomic_check(struct drm_crtc *crtc,
const struct drm_display_mode *mode =
_state->adjusted_mode;
struct vc4_encoder *vc4_encoder = to_vc4_encoder(encoder);
- mode = _state->adjusted_mode;
if (vc4_encoder->type == VC4_ENCODER_TYPE_HDMI0) {
vc4_state->hvs_load = max(mode->clock * mode->hdisplay
/ mode->htotal + 1000,
mode->clock * 9 / 10) * 1000;
--
2.34.1
Re: (subset) [PATCH] drm/connector: Fix typo in documentation
On Wed, 2 Feb 2022 10:43:40 +0100, Maxime Ripard wrote:
> Commit 4adc33f36d80 ("drm/edid: Split deep color modes between RGB and
> YUV444") introduced two new variables in struct drm_display_info and
> their documentation, but the documentation part had a typo resulting in
> a doc build warning.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
Re: (subset) [PATCH] drm/vc4: hdmi: Unregister codec device on unbind
On Thu, Feb 03, 2022 at 04:06:37PM +0100, Maxime Ripard wrote: > On Thu, 27 Jan 2022 12:14:52 +0100, Maxime Ripard wrote: > > On bind we will register the HDMI codec device but we don't unregister > > it on unbind, leading to a device leakage. Unregister our device at > > unbind. > > > > > > Applied to drm/drm-misc (drm-misc-fixes). This one hasn't been reviewed yet, so I dropped it for now Maxime signature.asc Description: PGP signature
[Bug 215511] Dual monitor with amd 5700 causes system to hang at startup.
https://bugzilla.kernel.org/show_bug.cgi?id=215511 --- Comment #5 from Alex Deucher (alexdeuc...@gmail.com) --- Created attachment 300385 --> https://bugzilla.kernel.org/attachment.cgi?id=300385=edit possible fix This patch should fix it. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: (subset) [PATCH] drm/vc4: hdmi: Unregister codec device on unbind
On Thu, 27 Jan 2022 12:14:52 +0100, Maxime Ripard wrote: > On bind we will register the HDMI codec device but we don't unregister > it on unbind, leading to a device leakage. Unregister our device at > unbind. > > Applied to drm/drm-misc (drm-misc-fixes). Thanks! Maxime
Re: (subset) [PATCH] drm/vc4: hdmi: Ensure we don't use 2711 HPD registers on Pi0-3
On Thu, 27 Jan 2022 14:17:54 +0100, Maxime Ripard wrote: > From: Dave Stevenson > > The existing logic was flawed in that it could try reading the > 2711 specific registers for HPD on a CM1/3 where the HPD GPIO > hadn't been defined in DT. > > Ensure we don't do the 2711 register read on invalid hardware, > and then > > [...] Applied to drm/drm-misc (drm-misc-fixes). Thanks! Maxime
Re: (subset) [PATCH] drm/vc4: hdmi: Don't try disabling SCDC on Pi0-3.
On Thu, 27 Jan 2022 14:45:59 +0100, Maxime Ripard wrote: > From: Dave Stevenson > > The code that set the scdc_enabled flag to ensure it was > disabled at boot time also ran on Pi0-3 where there is no > SCDC support. This lead to a warning in vc4_hdmi_encoder_post_crtc_disable > due to vc4_hdmi_disable_scrambling being called and trying to > read (and write) register HDMI_SCRAMBLER_CTL which doesn't > exist on those platforms. > > [...] Applied to drm/drm-misc (drm-misc-fixes). Thanks! Maxime
Re: (subset) [PATCH] drm/vc4: hdmi: Allow DBLCLK modes even if horz timing is odd.
On Thu, 27 Jan 2022 14:51:16 +0100, Maxime Ripard wrote: > From: Dave Stevenson > > The 2711 pixel valve can't produce odd horizontal timings, and > checks were added to vc4_hdmi_encoder_atomic_check and > vc4_hdmi_encoder_mode_valid to filter out/block selection of > such modes. > > [...] Applied to drm/drm-misc (drm-misc-fixes). Thanks! Maxime
Re: [PATCH v2 3/3] drm/panel: Add MIPI DBI compatible SPI driver
Hi Sam, On Wed, Feb 02, 2022 at 06:14:16PM +0100, Sam Ravnborg wrote: > Hi Noralf, > > > > > > > Parts of it is ergonomics I guess. We're used to having all those > > > properties either in the DT or the driver, but here we introduce a new > > > way that isn't done anywhere else. > > > > > > And I don't see any real downside to putting it in the DT? It's going to > > > be in an overlay, under the user's control anyway, right? > > > > > > > Ok, I'll spin a new version using DT properties. > > I like this better than anything else as we then have everything in > a single place when we add a new panel and more. > I just recall some resistance to add such HW specific setup - but the > usecase here is kinda special. The main issue was to put the initialisation sequence in the device tree. We solved that with by using a firmware instead. Given that the timings, size and so on are already used by multiple, widely used, panels, it should work just fine Maxime signature.asc Description: PGP signature
Re: [PATCH] HPE BMC GXP SUPPORT
On 03/02/2022 15:29, Rob Herring wrote:
> On Wed, Feb 2, 2022 at 10:55 AM wrote:
>>
>> From: Nick Hawkins
>>
(...)
>> +
>> + vuart_a: vuart_a@80fd0200 {
>
> serial@...
Maybe it does not look like, but this is actually a v2. Nick was asked
to change the naming for the nodes already in v1. Unfortunately it did
not happen, so we have vuart, spifi, vic and more.
It is a waste of reviewers' time to ask them to perform the same review
twice or to ignore their comments.
>
>> + compatible = "hpe,gxp-vuart";
>> + reg = <0x80fd0200 0x100>;
>> + interrupts = <2>;
>> + interrupt-parent = <>;
>> + clock-frequency = <1846153>;
>> + reg-shift = <0>;
>> + status = "okay";
>> + serial-line = <3>;
>> + vuart_cfg = <_a_cfg>;
>> + };
(...)
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
>> b/Documentation/devicetree/bindings/vendor-prefixes.yaml
>> index 294093d45a23..913f722a6b8d 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
>> @@ -514,7 +514,9 @@ patternProperties:
>>"^hoperun,.*":
>> description: Jiangsu HopeRun Software Co., Ltd.
>>"^hp,.*":
>> -description: Hewlett Packard
>> +description: Hewlett Packard Inc.
>
> Why are you changing this one?
I guess this is squashing of my patch:
https://lore.kernel.org/all/20220127075229.10299-1-krzysztof.kozlow...@canonical.com/
which is fine to me, but vendor changve should be a separate commit with
its own explanation. Now it looks indeed weird.
>
>> + "^hpe,.*":
>
> You used HPE elsewhere... Lowercase is preferred.
Best regards,
Krzysztof
Re: [PATCH v3] drm: document struct drm_mode_fb_cmd2
On Thu, 3 Feb 2022 at 13:38, Simon Ser wrote: > Follow-up for the DRM_IOCTL_MODE_GETFB2 docs. > > v2: (Daniel Stone) > - Replace fourcc.org with drm_fourcc.h because this is the > authoritative source and the website may have mismatches. > - Drop assumption that offsets will generally be 0. > - Mention that unused entries must be zero'ed out. > > v3: (Pekka) > - Mention that a handle can be re-used > - Add unit for pitches/offsets Great stuff, thanks a lot for doing the dirty work. Reviewed-by: Daniel Stone
Re: [PATCH 1/7] drm/selftests: Move i915 buddy selftests into drm
Am 03.02.22 um 14:32 schrieb Arunpravin:
- move i915 buddy selftests into drm selftests folder
- add Makefile and Kconfig support
- add sanitycheck testcase
Prerequisites
- These series of selftests patches are created on top of
drm buddy series
- Enable kselftests for DRM as a module in .config
Signed-off-by: Arunpravin
Only skimmed over this, but of hand I haven't seen anything obviously bad.
Feel free to add an Acked-by: Christian König
to the series.
Regards,
Christian.
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/selftests/Makefile| 3 +-
.../gpu/drm/selftests/drm_buddy_selftests.h | 9
drivers/gpu/drm/selftests/test-drm_buddy.c| 49 +++
4 files changed, 61 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/selftests/drm_buddy_selftests.h
create mode 100644 drivers/gpu/drm/selftests/test-drm_buddy.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index eb5a57ae3c5c..ff856df3f97f 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -71,6 +71,7 @@ config DRM_DEBUG_SELFTEST
select DRM_DP_HELPER
select DRM_LIB_RANDOM
select DRM_KMS_HELPER
+ select DRM_BUDDY
select DRM_EXPORT_FOR_TESTS if m
default n
help
diff --git a/drivers/gpu/drm/selftests/Makefile
b/drivers/gpu/drm/selftests/Makefile
index 0856e4b12f70..5ba5f9138c95 100644
--- a/drivers/gpu/drm/selftests/Makefile
+++ b/drivers/gpu/drm/selftests/Makefile
@@ -4,4 +4,5 @@ test-drm_modeset-y := test-drm_modeset_common.o
test-drm_plane_helper.o \
test-drm_damage_helper.o test-drm_dp_mst_helper.o \
test-drm_rect.o
-obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o test-drm_modeset.o test-drm_cmdline_parser.o
+obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o test-drm_modeset.o
test-drm_cmdline_parser.o \
+ test-drm_buddy.o
diff --git a/drivers/gpu/drm/selftests/drm_buddy_selftests.h
b/drivers/gpu/drm/selftests/drm_buddy_selftests.h
new file mode 100644
index ..a4bcf3a6dfe3
--- /dev/null
+++ b/drivers/gpu/drm/selftests/drm_buddy_selftests.h
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* List each unit test as selftest(name, function)
+ *
+ * The name is used as both an enum and expanded as igt__name to create
+ * a module parameter. It must be unique and legal for a C identifier.
+ *
+ * Tests are executed in order by igt/drm_buddy
+ */
+selftest(sanitycheck, igt_sanitycheck) /* keep first (selfcheck for igt) */
diff --git a/drivers/gpu/drm/selftests/test-drm_buddy.c
b/drivers/gpu/drm/selftests/test-drm_buddy.c
new file mode 100644
index ..51e4d393d22c
--- /dev/null
+++ b/drivers/gpu/drm/selftests/test-drm_buddy.c
@@ -0,0 +1,49 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#define pr_fmt(fmt) "drm_buddy: " fmt
+
+#include
+
+#include
+
+#include "../lib/drm_random.h"
+
+#define TESTS "drm_buddy_selftests.h"
+#include "drm_selftest.h"
+
+static unsigned int random_seed;
+
+static int igt_sanitycheck(void *ignored)
+{
+ pr_info("%s - ok!\n", __func__);
+ return 0;
+}
+
+#include "drm_selftest.c"
+
+static int __init test_drm_buddy_init(void)
+{
+ int err;
+
+ while (!random_seed)
+ random_seed = get_random_int();
+
+ pr_info("Testing DRM buddy manager (struct drm_buddy), with
random_seed=0x%x\n",
+ random_seed);
+ err = run_selftests(selftests, ARRAY_SIZE(selftests), NULL);
+
+ return err > 0 ? 0 : err;
+}
+
+static void __exit test_drm_buddy_exit(void)
+{
+}
+
+module_init(test_drm_buddy_init);
+module_exit(test_drm_buddy_exit);
+
+MODULE_AUTHOR("Intel Corporation");
+MODULE_LICENSE("GPL");
Re: [PATCH] HPE BMC GXP SUPPORT
On Wed, Feb 2, 2022 at 10:55 AM wrote: > > From: Nick Hawkins > > GXP is the name of the HPE SoC. > This SoC is used to implement BMC features of HPE servers > (all ProLiant, Synergy, and many Apollo, and Superdome machines) > It does support many features including: > ARMv7 architecture, and it is based on a Cortex A9 core > Use an AXI bus to which > a memory controller is attached, as well as > multiple SPI interfaces to connect boot flash, > and ROM flash, a 10/100/1000 Mac engine which > supports SGMII (2 ports) and RMII > Multiple I2C engines to drive connectivity with a host > infrastructure > A video engine which support VGA and DP, as well as > an hardware video encoder > Multiple PCIe ports > A PECI interface, and LPC eSPI > Multiple UART for debug purpose, and Virtual UART for host > connectivity > A GPIO engine > This Patch Includes: > Documentation for device tree bindings > Device Tree Bindings > GXP Timer Support > GXP Architecture Support > > Signed-off-by: Nick Hawkins > --- > .../bindings/display/hpe,gxp-thumbnail.txt| 21 + > .../devicetree/bindings/gpio/hpe,gxp-gpio.txt | 16 + > .../devicetree/bindings/i2c/hpe,gxp-i2c.txt | 19 + > .../bindings/ipmi/hpegxp-kcs-bmc-cfg.txt | 13 + > .../bindings/ipmi/hpegxp-kcs-bmc.txt | 21 + > .../memory-controllers/hpe,gxp-srom.txt | 13 + > .../devicetree/bindings/mtd/hpe,gxp.txt | 16 + > .../bindings/net/hpe,gxp-umac-mdio.txt| 21 + > .../devicetree/bindings/net/hpe,gxp-umac.txt | 20 + > .../devicetree/bindings/pwm/hpe,gxp-fan.txt | 15 + > .../bindings/serial/hpe,gxp-vuart-cfg.txt | 17 + > .../bindings/serial/hpe,gxp-vuart.txt | 23 + > .../bindings/soc/hpe/hpe,gxp-chif.txt | 16 + > .../bindings/soc/hpe/hpe,gxp-csm.txt | 14 + > .../bindings/soc/hpe/hpe,gxp-dbg.txt | 18 + > .../bindings/soc/hpe/hpe,gxp-fn2.txt | 20 + > .../bindings/soc/hpe/hpe,gxp-xreg.txt | 19 + > .../devicetree/bindings/spi/hpe,gxp-spifi.txt | 76 +++ > .../bindings/thermal/hpe,gxp-coretemp.txt | 14 + > .../bindings/timer/hpe,gxp-timer.txt | 18 + > .../devicetree/bindings/usb/hpe,gxp-udc.txt | 21 + > .../devicetree/bindings/vendor-prefixes.yaml | 4 +- > .../bindings/watchdog/hpe,gxp-wdt.txt | 11 + All these must be in DT schema format (yaml json-schema). See Documentation/devicetree/bindings/submitting-patches.rst and Documentation/devicetree/bindings/writing-schema.rst. > MAINTAINERS | 14 + > arch/arm/Kconfig | 2 + > arch/arm/boot/dts/Makefile| 2 + > arch/arm/boot/dts/hpe-bmc-dl360gen10.dts | 207 +++ > arch/arm/boot/dts/hpe-gxp.dtsi| 555 ++ Once the schemas are in place, run 'make W=1 dtbs_check' and fix the warnings. > arch/arm/configs/gxp_defconfig| 243 > arch/arm/mach-hpe/Kconfig | 21 + > arch/arm/mach-hpe/Makefile| 1 + > arch/arm/mach-hpe/gxp.c | 62 ++ > drivers/clocksource/Kconfig | 8 + > drivers/clocksource/Makefile | 1 + > drivers/clocksource/gxp_timer.c | 158 + > 35 files changed, 1719 insertions(+), 1 deletion(-) > create mode 100644 > Documentation/devicetree/bindings/display/hpe,gxp-thumbnail.txt > create mode 100644 Documentation/devicetree/bindings/gpio/hpe,gxp-gpio.txt > create mode 100644 Documentation/devicetree/bindings/i2c/hpe,gxp-i2c.txt > create mode 100644 > Documentation/devicetree/bindings/ipmi/hpegxp-kcs-bmc-cfg.txt > create mode 100644 Documentation/devicetree/bindings/ipmi/hpegxp-kcs-bmc.txt > create mode 100644 > Documentation/devicetree/bindings/memory-controllers/hpe,gxp-srom.txt > create mode 100644 Documentation/devicetree/bindings/mtd/hpe,gxp.txt > create mode 100644 > Documentation/devicetree/bindings/net/hpe,gxp-umac-mdio.txt > create mode 100644 Documentation/devicetree/bindings/net/hpe,gxp-umac.txt > create mode 100644 Documentation/devicetree/bindings/pwm/hpe,gxp-fan.txt > create mode 100644 > Documentation/devicetree/bindings/serial/hpe,gxp-vuart-cfg.txt > create mode 100644 Documentation/devicetree/bindings/serial/hpe,gxp-vuart.txt > create mode 100644 Documentation/devicetree/bindings/soc/hpe/hpe,gxp-chif.txt > create mode 100644 Documentation/devicetree/bindings/soc/hpe/hpe,gxp-csm.txt > create mode 100644 Documentation/devicetree/bindings/soc/hpe/hpe,gxp-dbg.txt > create mode 100644 Documentation/devicetree/bindings/soc/hpe/hpe,gxp-fn2.txt > create mode 100644 Documentation/devicetree/bindings/soc/hpe/hpe,gxp-xreg.txt > create mode 100644
RE: [Patch v5 15/24] drm/amdkfd: CRIU implement gpu_id remapping
One nit pick.
Regards,
David
@@ -673,15 +693,19 @@ static int kfd_ioctl_dbg_address_watch(struct file *filep,
memset((void *) _info, 0, sizeof(struct dbg_address_watch_info));
- dev = kfd_device_by_id(args->gpu_id);
- if (!dev)
+ mutex_lock(>mutex);
+ pdd = kfd_process_device_data_by_id(p, args->gpu_id);
+ mutex_unlock(>mutex);
+ if (!pdd) {
+ pr_debug("Could not find gpu id 0x%x\n", args->gpu_id);
return -EINVAL;
+ }
+ dev = pdd->dev;
if (dev->adev->asic_type == CHIP_CARRIZO) {
pr_debug("kfd_ioctl_dbg_wave_control not supported on CZ\n");
return -EINVAL;
}
-
Unnecessary extra line
cmd_from_user = (void __user *) args->content_ptr;
/* Validate arguments */
[PATCH v6 4/4] dt-bindings: drm/bridge: anx7625: Add aux-bus node
List panel under aux-bus node if it's connected to anx7625's aux bus.
Signed-off-by: Hsin-Yi Wang
---
.../display/bridge/analogix,anx7625.yaml| 17 +
1 file changed, 17 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
index 1d3e88daca041a..0d38d6fe39830f 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
@@ -83,6 +83,9 @@ properties:
type: boolean
description: let the driver enable audio HDMI codec function or not.
+ aux-bus:
+$ref: /schemas/display/dp-aux-bus.yaml#
+
ports:
$ref: /schemas/graph.yaml#/properties/ports
@@ -167,5 +170,19 @@ examples:
};
};
};
+
+aux-bus {
+panel {
+compatible = "innolux,n125hce-gn1";
+power-supply = <_disp_x>;
+backlight = <_lcd0>;
+
+port {
+panel_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
};
};
--
2.35.0.rc2.247.g8bbb082509-goog
[PATCH v6 3/4] drm/bridge: anx7625: Support reading edid through aux channel
Support reading edid through aux channel if panel is connected to aux
bus. Extend anx7625_aux_dpcd_trans() to implement aux transfer function:
1. panel is populated in devm_of_dp_aux_populate_ep_devices(), so move
anx7625_parse_dt() after.
2. Use pm runtime autosuspend since aux transfer function is called
multiple times when reading edid.
3. No-op if aux transfer length is 0.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Xin Ji
---
v5->v6:
fix Kconfig.
v4->v5:
fix header and indent.
v3->v4:
rebase to latest drm-misc-next
---
drivers/gpu/drm/bridge/analogix/Kconfig | 1 +
drivers/gpu/drm/bridge/analogix/anx7625.c | 120 ++
drivers/gpu/drm/bridge/analogix/anx7625.h | 1 +
3 files changed, 104 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
b/drivers/gpu/drm/bridge/analogix/Kconfig
index 319ba0df57be8f..03d3aaa2e84b37 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -32,6 +32,7 @@ config DRM_ANALOGIX_ANX7625
tristate "Analogix Anx7625 MIPI to DP interface support"
depends on DRM
depends on OF
+ select DRM_DP_AUX_BUS
select DRM_MIPI_DSI
help
ANX7625 is an ultra-low power 4K mobile HD transmitter
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index b7e3373994b480..a59a4f4d2c5b10 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -231,19 +232,23 @@ static int wait_aux_op_finish(struct anx7625_data *ctx)
return 0;
}
-static int anx7625_aux_dpcd_trans(struct anx7625_data *ctx, u8 op,
- u32 address, u8 len, u8 *buf)
+static int anx7625_aux_trans(struct anx7625_data *ctx, u8 op, u32 address,
+u8 len, u8 *buf)
{
struct device *dev = >client->dev;
int ret;
u8 addrh, addrm, addrl;
u8 cmd;
+ bool is_write = !(op & DP_AUX_I2C_READ);
- if (len > MAX_DPCD_BUFFER_SIZE) {
+ if (len > DP_AUX_MAX_PAYLOAD_BYTES) {
dev_err(dev, "exceed aux buffer len.\n");
return -EINVAL;
}
+ if (!len)
+ return len;
+
addrl = address & 0xFF;
addrm = (address >> 8) & 0xFF;
addrh = (address >> 16) & 0xFF;
@@ -262,7 +267,7 @@ static int anx7625_aux_dpcd_trans(struct anx7625_data *ctx,
u8 op,
ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
AP_AUX_ADDR_19_16, addrh);
- if (op == DP_AUX_NATIVE_WRITE)
+ if (is_write)
ret |= anx7625_reg_block_write(ctx, ctx->i2c.rx_p0_client,
AP_AUX_BUFF_START, len, buf);
/* Enable aux access */
@@ -275,14 +280,14 @@ static int anx7625_aux_dpcd_trans(struct anx7625_data
*ctx, u8 op,
}
ret = wait_aux_op_finish(ctx);
- if (ret) {
+ if (ret < 0) {
dev_err(dev, "aux IO error: wait aux op finish.\n");
return ret;
}
/* Write done */
- if (op == DP_AUX_NATIVE_WRITE)
- return 0;
+ if (is_write)
+ return len;
/* Read done, read out dpcd data */
ret = anx7625_reg_block_read(ctx, ctx->i2c.rx_p0_client,
@@ -292,7 +297,7 @@ static int anx7625_aux_dpcd_trans(struct anx7625_data *ctx,
u8 op,
return -EIO;
}
- return 0;
+ return len;
}
static int anx7625_video_mute_control(struct anx7625_data *ctx,
@@ -867,7 +872,7 @@ static int anx7625_hdcp_enable(struct anx7625_data *ctx)
}
/* Read downstream capability */
- anx7625_aux_dpcd_trans(ctx, DP_AUX_NATIVE_READ, 0x68028, 1, );
+ anx7625_aux_trans(ctx, DP_AUX_NATIVE_READ, 0x68028, 1, );
if (!(bcap & 0x01)) {
pr_warn("downstream not support HDCP 1.4, cap(%x).\n", bcap);
return 0;
@@ -956,7 +961,7 @@ static void anx7625_dp_stop(struct anx7625_data *ctx)
dev_dbg(dev, "notify downstream enter into standby\n");
/* Downstream monitor enter into standby mode */
data = 2;
- ret |= anx7625_aux_dpcd_trans(ctx, DP_AUX_NATIVE_WRITE, 0x000600, 1,
);
+ ret |= anx7625_aux_trans(ctx, DP_AUX_NATIVE_WRITE, 0x000600, 1, );
if (ret < 0)
DRM_DEV_ERROR(dev, "IO error : mute video fail\n");
@@ -1655,11 +1660,56 @@ static int anx7625_parse_dt(struct device *dev,
return 0;
}
+static bool anx7625_of_panel_on_aux_bus(struct device *dev)
+{
+ struct device_node *bus, *panel;
+
+ bus = of_get_child_by_name(dev->of_node, "aux-bus");
+ if (!bus)
+ return false;
+
+ panel = of_get_child_by_name(bus, "panel");
+ of_node_put(bus);
+ if (!panel)
[PATCH v6 2/4] drm/bridge: anx7625: Convert to use devm_kzalloc
Use devm_kzalloc instead of kzalloc and drop kfree(). Let the memory
handled by driver detach.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Xin Ji
---
v2->v3: remove kfree() in anx7625_i2c_remove().
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 17b23940549a42..b7e3373994b480 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -2515,7 +2515,7 @@ static int anx7625_i2c_probe(struct i2c_client *client,
return -ENODEV;
}
- platform = kzalloc(sizeof(*platform), GFP_KERNEL);
+ platform = devm_kzalloc(dev, sizeof(*platform), GFP_KERNEL);
if (!platform) {
DRM_DEV_ERROR(dev, "fail to allocate driver data\n");
return -ENOMEM;
@@ -2527,7 +2527,7 @@ static int anx7625_i2c_probe(struct i2c_client *client,
if (ret) {
if (ret != -EPROBE_DEFER)
DRM_DEV_ERROR(dev, "fail to parse DT : %d\n", ret);
- goto free_platform;
+ return ret;
}
platform->client = client;
@@ -2552,7 +2552,7 @@ static int anx7625_i2c_probe(struct i2c_client *client,
if (!platform->hdcp_workqueue) {
dev_err(dev, "fail to create work queue\n");
ret = -ENOMEM;
- goto free_platform;
+ return ret;
}
platform->pdata.intp_irq = client->irq;
@@ -2637,9 +2637,6 @@ static int anx7625_i2c_probe(struct i2c_client *client,
if (platform->hdcp_workqueue)
destroy_workqueue(platform->hdcp_workqueue);
-free_platform:
- kfree(platform);
-
return ret;
}
@@ -2666,7 +2663,6 @@ static int anx7625_i2c_remove(struct i2c_client *client)
if (platform->pdata.audio_en)
anx7625_unregister_audio(platform);
- kfree(platform);
return 0;
}
--
2.35.0.rc2.247.g8bbb082509-goog
[PATCH v6 1/4] drm/bridge: anx7625: send DPCD command to downstream
From: Xin Ji
Send DPCD command to downstream before anx7625 power down,
let downstream monitor enter into standby mode.
Signed-off-by: Xin Ji
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Hsin-Yi Wang
---
v3->v4:
Use common DP_AUX_NATIVE_READ/WRITE
Previously in:
https://patchwork.kernel.org/project/dri-devel/patch/1f36f8bf0a48fb2bba17bacec23700e58c1d407d.1641891874.git@analogixsemi.com/
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 42 +++
drivers/gpu/drm/bridge/analogix/anx7625.h | 2 --
2 files changed, 35 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 76662fce4ce61d..17b23940549a42 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -129,6 +129,23 @@ static int anx7625_reg_write(struct anx7625_data *ctx,
return ret;
}
+static int anx7625_reg_block_write(struct anx7625_data *ctx,
+ struct i2c_client *client,
+ u8 reg_addr, u8 len, u8 *buf)
+{
+ int ret;
+ struct device *dev = >dev;
+
+ i2c_access_workaround(ctx, client);
+
+ ret = i2c_smbus_write_i2c_block_data(client, reg_addr, len, buf);
+ if (ret < 0)
+ dev_err(dev, "write i2c block failed id=%x\n:%x",
+ client->addr, reg_addr);
+
+ return ret;
+}
+
static int anx7625_write_or(struct anx7625_data *ctx,
struct i2c_client *client,
u8 offset, u8 mask)
@@ -214,8 +231,8 @@ static int wait_aux_op_finish(struct anx7625_data *ctx)
return 0;
}
-static int anx7625_aux_dpcd_read(struct anx7625_data *ctx,
-u32 address, u8 len, u8 *buf)
+static int anx7625_aux_dpcd_trans(struct anx7625_data *ctx, u8 op,
+ u32 address, u8 len, u8 *buf)
{
struct device *dev = >client->dev;
int ret;
@@ -231,8 +248,7 @@ static int anx7625_aux_dpcd_read(struct anx7625_data *ctx,
addrm = (address >> 8) & 0xFF;
addrh = (address >> 16) & 0xFF;
- cmd = DPCD_CMD(len, DPCD_READ);
- cmd = ((len - 1) << 4) | 0x09;
+ cmd = DPCD_CMD(len, op);
/* Set command and length */
ret = anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
@@ -246,6 +262,9 @@ static int anx7625_aux_dpcd_read(struct anx7625_data *ctx,
ret |= anx7625_reg_write(ctx, ctx->i2c.rx_p0_client,
AP_AUX_ADDR_19_16, addrh);
+ if (op == DP_AUX_NATIVE_WRITE)
+ ret |= anx7625_reg_block_write(ctx, ctx->i2c.rx_p0_client,
+ AP_AUX_BUFF_START, len, buf);
/* Enable aux access */
ret |= anx7625_write_or(ctx, ctx->i2c.rx_p0_client,
AP_AUX_CTRL_STATUS, AP_AUX_CTRL_OP_EN);
@@ -255,14 +274,17 @@ static int anx7625_aux_dpcd_read(struct anx7625_data *ctx,
return -EIO;
}
- usleep_range(2000, 2100);
-
ret = wait_aux_op_finish(ctx);
if (ret) {
dev_err(dev, "aux IO error: wait aux op finish.\n");
return ret;
}
+ /* Write done */
+ if (op == DP_AUX_NATIVE_WRITE)
+ return 0;
+
+ /* Read done, read out dpcd data */
ret = anx7625_reg_block_read(ctx, ctx->i2c.rx_p0_client,
AP_AUX_BUFF_START, len, buf);
if (ret < 0) {
@@ -845,7 +867,7 @@ static int anx7625_hdcp_enable(struct anx7625_data *ctx)
}
/* Read downstream capability */
- anx7625_aux_dpcd_read(ctx, 0x68028, 1, );
+ anx7625_aux_dpcd_trans(ctx, DP_AUX_NATIVE_READ, 0x68028, 1, );
if (!(bcap & 0x01)) {
pr_warn("downstream not support HDCP 1.4, cap(%x).\n", bcap);
return 0;
@@ -918,6 +940,7 @@ static void anx7625_dp_stop(struct anx7625_data *ctx)
{
struct device *dev = >client->dev;
int ret;
+ u8 data;
DRM_DEV_DEBUG_DRIVER(dev, "stop dp output\n");
@@ -929,6 +952,11 @@ static void anx7625_dp_stop(struct anx7625_data *ctx)
ret |= anx7625_write_and(ctx, ctx->i2c.tx_p2_client, 0x08, 0x7f);
ret |= anx7625_video_mute_control(ctx, 1);
+
+ dev_dbg(dev, "notify downstream enter into standby\n");
+ /* Downstream monitor enter into standby mode */
+ data = 2;
+ ret |= anx7625_aux_dpcd_trans(ctx, DP_AUX_NATIVE_WRITE, 0x000600, 1,
);
if (ret < 0)
DRM_DEV_ERROR(dev, "IO error : mute video fail\n");
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.h
b/drivers/gpu/drm/bridge/analogix/anx7625.h
index 56165f5b254c14..64a8ab56529404 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.h
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.h
@@ -242,8 +242,6 @@
#define AP_AUX_COMMAND 0x27 /* com+len */
#define
Re: [PATCH 19/20] drm/i915/lmem: don't treat small BAR as an error
On 03/02/2022 13:56, Thomas Hellström wrote:
On Thu, 2022-02-03 at 11:18 +, Matthew Auld wrote:
On 03/02/2022 09:48, Thomas Hellström wrote:
On 1/26/22 16:21, Matthew Auld wrote:
Just pass along the probed io_size. The backend should be able to
utilize the entire range here, even if some of it is non-
mappable.
Changes here LGTM.
It does leave open with what to do with stolen local-memory.
Are objects in stolen local required to be mappable?
From a quick look I don't really see such users on discrete, outside
of
maybe intelfb_create(), where I guess the initial fb might be located
in
stolen on DG1. But from DG2+ it looks like it will just be located in
normal LMEM. For that I was thinking we add something like
i915_gem_object_create_region_at(), and somehow wire that up to the
{fpfn, lpfn}...
So we could then skip STOLEN completely on DG2+? Could we then also do
the same on DG1, at least assuming that creating and pinning an object
for that initial fb would be done before any other pinning into LMEM?
It looks like fbc is the main user on discrete, AFAICT, but that doesn't
seem to use the gem object interface, and instead just plugs into the
underlying drm_mm directly. So AFAIK we still want stolen on DG2/DG1 for
that.
/Thomas
Re: [PATCH 19/20] drm/i915/lmem: don't treat small BAR as an error
On Thu, 2022-02-03 at 11:18 +, Matthew Auld wrote:
> On 03/02/2022 09:48, Thomas Hellström wrote:
> >
> > On 1/26/22 16:21, Matthew Auld wrote:
> > > Just pass along the probed io_size. The backend should be able to
> > > utilize the entire range here, even if some of it is non-
> > > mappable.
> > Changes here LGTM.
> > >
> > > It does leave open with what to do with stolen local-memory.
> >
> > Are objects in stolen local required to be mappable?
>
> From a quick look I don't really see such users on discrete, outside
> of
> maybe intelfb_create(), where I guess the initial fb might be located
> in
> stolen on DG1. But from DG2+ it looks like it will just be located in
> normal LMEM. For that I was thinking we add something like
> i915_gem_object_create_region_at(), and somehow wire that up to the
> {fpfn, lpfn}...
So we could then skip STOLEN completely on DG2+? Could we then also do
the same on DG1, at least assuming that creating and pinning an object
for that initial fb would be done before any other pinning into LMEM?
/Thomas
[RFC 3/5] drm/hdmi21: Add helpers to verify non-dsc DFM requirements
Add helpers to compute DFM variables and to verify if the
DFM requirements are met or not in non dsc cases.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/drm_frl_dfm_helper.c | 161 +++
include/drm/drm_frl_dfm_helper.h | 2 +
2 files changed, 163 insertions(+)
diff --git a/drivers/gpu/drm/drm_frl_dfm_helper.c
b/drivers/gpu/drm/drm_frl_dfm_helper.c
index 8498083adf72..087905ed630a 100644
--- a/drivers/gpu/drm/drm_frl_dfm_helper.c
+++ b/drivers/gpu/drm/drm_frl_dfm_helper.c
@@ -394,3 +394,164 @@ drm_compute_payload_utilization(u32
frl_char_payload_actual, u32 frl_char_per_li
utilization = (frl_char_payload_actual * EFFICIENCY_MULTIPLIER) /
frl_char_per_line_period;
return utilization;
}
+
+/* Collect link characteristics */
+static void
+drm_frl_dfm_compute_link_characteristics(struct drm_hdmi_frl_dfm *frl_dfm)
+{
+ u32 frl_bit_rate_min_kbps;
+
+ frl_dfm->params.pixel_clock_max_khz =
+
drm_get_max_legal_pixel_rate(frl_dfm->config.pixel_clock_nominal_khz);
+ frl_dfm->params.line_time_ns =
+ drm_get_min_video_line_period(frl_dfm->config.hblank,
+ frl_dfm->config.hactive,
+
frl_dfm->params.pixel_clock_max_khz);
+ frl_bit_rate_min_kbps =
drm_get_min_frl_bit_rate(frl_dfm->config.bit_rate_kbps);
+ frl_dfm->params.char_rate_min_kbps =
drm_get_min_frl_char_rate(frl_bit_rate_min_kbps);
+ frl_dfm->params.cfrl_line =
+
drm_get_total_frl_char_per_line_period(frl_dfm->params.line_time_ns,
+
frl_dfm->params.char_rate_min_kbps,
+ frl_dfm->config.lanes);
+}
+
+/* Determine FRL link overhead */
+static void drm_frl_dfm_compute_max_frl_link_overhead(struct drm_hdmi_frl_dfm
*frl_dfm)
+{
+ u32 overhead_min;
+
+ overhead_min = drm_get_total_minimum_overhead(frl_dfm->config.lanes);
+ frl_dfm->params.overhead_max = drm_get_max_overhead(overhead_min);
+}
+
+/* Audio support Verification computations */
+static void
+drm_frl_dfm_compute_audio_hblank_min(struct drm_hdmi_frl_dfm *frl_dfm)
+{
+ u32 num_audio_pkt, audio_pkt_rate;
+
+ /*
+* TBD: get the actual audio pkt type as described in
+* table 6.44 of HDMI2.1 spec to find the num_audio_pkt,
+* for now assume audio sample packet and audio packet
+* layout as 1, resulting in number of audio packets
+* required to carry each audio sample or audio frame
+* as 1
+*/
+ num_audio_pkt = 1;
+ audio_pkt_rate = drm_get_audio_pkt_rate(frl_dfm->config.audio_hz,
num_audio_pkt);
+ frl_dfm->params.num_audio_pkts_line =
+drm_get_audio_pkts_hblank(audio_pkt_rate,
frl_dfm->params.line_time_ns);
+ frl_dfm->params.hblank_audio_min =
+
drm_get_audio_hblank_min(frl_dfm->params.num_audio_pkts_line);
+}
+
+/*
+ * Determine the number of tribytes required for active video , blanking period
+ * with the pixel configuration
+ */
+static void
+drm_frl_dfm_compute_tbactive_tbblank(struct drm_hdmi_frl_dfm *frl_dfm)
+{
+ u32 bpp, bytes_per_line;
+
+ bpp = drm_get_frl_bits_per_pixel(frl_dfm->config.color_format,
frl_dfm->config.bpc);
+ bytes_per_line = drm_get_video_bytes_per_line(bpp,
frl_dfm->config.hactive);
+
+ frl_dfm->params.tb_active =
drm_get_active_video_tribytes_reqd(bytes_per_line);
+ frl_dfm->params.tb_blank =
+ drm_get_blanking_tribytes_avail(frl_dfm->config.color_format,
+ frl_dfm->config.hblank,
+ frl_dfm->config.bpc);
+}
+
+/* Verify the configuration meets the capacity requirements for the FRL
configuration*/
+static bool
+drm_frl_dfm_verify_frl_capacity_requirement(struct drm_hdmi_frl_dfm *frl_dfm)
+{
+ u32 tactive_ref_ns, tblank_ref_ns, tactive_min_ns, tblank_min_ns;
+ u32 tborrowed_ns;
+
+ frl_dfm->params.ftb_avg_k =
+
drm_get_avg_tribyte_rate(frl_dfm->params.pixel_clock_max_khz,
+frl_dfm->params.tb_active,
frl_dfm->params.tb_blank,
+frl_dfm->config.hactive,
frl_dfm->config.hblank);
+ tactive_ref_ns = drm_get_tactive_ref(frl_dfm->params.line_time_ns,
+frl_dfm->config.hblank,
+frl_dfm->config.hactive);
+ tblank_ref_ns = drm_get_tblank_ref(frl_dfm->params.line_time_ns,
+ frl_dfm->config.hblank,
+ frl_dfm->config.hactive);
+ tactive_min_ns = drm_get_tactive_min(frl_dfm->config.lanes,
+
[RFC 4/5] drm/hdmi21: Add support for DFM calculation with DSC
From: Ankit Nautiyal
Add helper functions for calculating FRL capacity and DFM
requirements with given compressed bpp.
Signed-off-by: Ankit Nautiyal
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/drm_frl_dfm_helper.c | 298 +++
include/drm/drm_frl_dfm_helper.h | 3 +
2 files changed, 301 insertions(+)
diff --git a/drivers/gpu/drm/drm_frl_dfm_helper.c
b/drivers/gpu/drm/drm_frl_dfm_helper.c
index 087905ed630a..dbdcc509f791 100644
--- a/drivers/gpu/drm/drm_frl_dfm_helper.c
+++ b/drivers/gpu/drm/drm_frl_dfm_helper.c
@@ -555,3 +555,301 @@ drm_frl_dfm_nondsc_requirement_met(struct
drm_hdmi_frl_dfm *frl_dfm)
return false;
}
EXPORT_SYMBOL(drm_frl_dfm_nondsc_requirement_met);
+
+/* DSC DFM functions */
+/* Get FRL Available characters */
+static u32
+drm_get_frl_available_chars(u32 overhead_max, u32 cfrl_line)
+{
+ u32 frl_char_avlb = ((EFFICIENCY_MULTIPLIER - overhead_max) *
cfrl_line);
+
+ return frl_char_avlb / EFFICIENCY_MULTIPLIER;
+}
+
+/* Get required no. of tribytes during HCActive */
+static u32
+drm_get_frl_hcactive_tb_target(u32 dsc_bpp_x16, u32 slice_width, u32
num_slices)
+{
+ u32 bytes_target;
+
+ bytes_target = num_slices * DIV_ROUND_UP(dsc_bpp_x16 * slice_width,
+8 * BPP_MULTIPLIER);
+
+ return DIV_ROUND_UP(bytes_target, 3);
+}
+
+/* Get required no. of tribytes (estimate1) during HCBlank */
+static u32
+drm_get_frl_hcblank_tb_est1_target(u32 hcactive_target_tb,
+ u32 hactive, u32 hblank)
+{
+ return DIV_ROUND_UP(hcactive_target_tb * hblank, hactive);
+}
+
+/* Get required no. of tribytes during HCBlank */
+static u32
+drm_get_frl_hcblank_tb_target(u32 hcactive_target_tb, u32 hactive, u32 hblank,
+ u32 hcblank_audio_min, u32 cfrl_available)
+{
+ u32 hcblank_target_tb1 =
drm_get_frl_hcblank_tb_est1_target(hcactive_target_tb,
+ hactive,
hblank);
+ u32 hcblank_target_tb2 = max(hcblank_target_tb1, hcblank_audio_min);
+
+ return 4 * (min(hcblank_target_tb2,
+ (2 * cfrl_available - 3 * hcactive_target_tb) / 2) / 4);
+}
+
+/* Get the avg no of tribytes sent per sec (Kbps) */
+static u64
+drm_frl_dsc_get_ftb_avg(u32 hcactive_target_tb, u32 hcblank_target_tb,
+ u32 hactive, u32 hblank,
+ u64 fpixelclock_max_khz)
+{
+ return (hcactive_target_tb + hcblank_target_tb) * (fpixelclock_max_khz
/ (hactive + hblank));
+}
+
+/* Time to send Active tribytes in nanoseconds */
+static u32
+drm_frl_dsc_get_tactive_ref_ns(u32 line_time_ns, u32 hactive, u32 hblank)
+{
+ return (line_time_ns * hactive) / (hactive + hblank);
+}
+
+/* Time to send Blanking tribytes in nanoseconds */
+static u32
+drm_frl_dsc_get_tblank_ref_ns(u32 line_time_ns, u32 hactive, u32 hblank)
+{
+ return (line_time_ns * hblank) / (hactive + hblank);
+}
+
+/* Get time to send all tribytes in hcactive region in nsec*/
+static u32
+drm_frl_dsc_tactive_target_ns(u32 frl_lanes, u32 hcactive_target_tb, u64
ftb_avg_k,
+ u32 min_frl_char_rate_k, u32 overhead_max)
+{
+ u32 avg_tribyte_time_ns, tribyte_time_ns;
+ u32 num_chars_hcactive;
+ u32 frl_char_rate_k;
+
+ /* Avg time to transmit all active region tribytes */
+ avg_tribyte_time_ns = (hcactive_target_tb * FRL_TIMING_NS_MULTIPLIER) /
+ (ftb_avg_k * 1000);
+
+ /*
+* 2 bytes in active region = 1 FRL characters
+* 1 Tribyte in active region = 3/2 FRL characters
+*/
+
+ num_chars_hcactive = (hcactive_target_tb * 3) / 2;
+
+ /*
+* FRL rate = lanes * frl character rate
+* But actual bandwidth wil be less, due to FRL limitations so account
+* for the overhead involved.
+* FRL rate with overhead = FRL rate * (100 - overhead %) / 100
+*/
+ frl_char_rate_k = frl_lanes * min_frl_char_rate_k;
+ frl_char_rate_k = (frl_char_rate_k * (EFFICIENCY_MULTIPLIER -
overhead_max)) /
+ EFFICIENCY_MULTIPLIER;
+
+ /* Time to transmit all characters with FRL limitations */
+ tribyte_time_ns = (num_chars_hcactive * FRL_TIMING_NS_MULTIPLIER) /
+ frl_char_rate_k * 1000;
+
+ return max(avg_tribyte_time_ns, tribyte_time_ns);
+}
+
+/* Get no. of tri bytes borrowed with DSC enabled */
+static u32
+drm_frl_get_dsc_tri_bytes_borrowed(u32 tactive_target_ns, u32 ftb_avg_k,
+ u32 hcactive_target_tb)
+{
+ return (tactive_target_ns * FRL_TIMING_NS_MULTIPLIER * ftb_avg_k *
1000) -
+ hcactive_target_tb;
+}
+
+/* Get TBdelta */
+static u32
+drm_frl_get_dsc_tri_bytes_delta(u32 tactive_target_ns, u32 tactive_ref_ns,
+ u32 hcactive_target_tb, u32 ftb_avg_k,
+
[RFC 5/5] drm/hdmi21: Add frl_dfm_helper to Makefile
Add the new frl_dfm_helper file to drm Makefile Signed-off-by: Vandita Kulkarni --- drivers/gpu/drm/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 8675c2af7ae1..4fa9b48995c8 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -17,7 +17,7 @@ drm-y :=drm_aperture.o drm_auth.o drm_cache.o \ drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \ drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \ drm_client_modeset.o drm_atomic_uapi.o \ - drm_managed.o drm_vblank_work.o + drm_managed.o drm_vblank_work.o drm_frl_dfm_helper.o drm-$(CONFIG_DRM_LEGACY) += drm_agpsupport.o drm_bufs.o drm_context.o drm_dma.o \ drm_hashtab.o drm_irq.o drm_legacy_misc.o drm_lock.o \ -- 2.32.0
[RFC 2/5] drm/hdmi21: Add non dsc frl capacity computation helpers
Add helper functions for computing non dsc frl
link characteristics
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/drm_frl_dfm_helper.c | 396 +++
1 file changed, 396 insertions(+)
create mode 100644 drivers/gpu/drm/drm_frl_dfm_helper.c
diff --git a/drivers/gpu/drm/drm_frl_dfm_helper.c
b/drivers/gpu/drm/drm_frl_dfm_helper.c
new file mode 100644
index ..8498083adf72
--- /dev/null
+++ b/drivers/gpu/drm/drm_frl_dfm_helper.c
@@ -0,0 +1,396 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corp
+ */
+
+#include
+#include
+#include
+#include
+
+/* Total frl charecters per super block */
+static u32 drm_get_frl_char_per_super_blk(u32 lanes)
+{
+ u32 frl_char_per_sb;
+
+ frl_char_per_sb = (4 * FRL_CHAR_PER_CHAR_BLK) + lanes;
+ return frl_char_per_sb;
+}
+
+/*
+ * Determine the overhead due to the inclusion of
+ * the SR and SSB FRL charecters used for
+ * super block framing
+ */
+static u32 drm_get_overhead_super_blk(u32 lanes)
+{
+ return (lanes * EFFICIENCY_MULTIPLIER) /
drm_get_frl_char_per_super_blk(lanes);
+}
+
+/*
+ * Determine the overhead due to the inclusion of RS FEC pairity
+ * symbols. Each charecter block uses 8 FRL charecters for RS Pairity
+ * and there are 4 charecter blocks per super block
+ */
+static u32 drm_get_overhead_rs(u32 lanes)
+{
+ return (8 * 4 * EFFICIENCY_MULTIPLIER) /
drm_get_frl_char_per_super_blk(lanes);
+}
+
+/* Determine the overhead due to FRL Map charecters.
+ * In a bandwidth constrained application, the FRL packets will be long,
+ * there will typically be two FRL Map Charecters per Super Block most of the
time.
+ * When a tracnsition occurs between Hactive and Hblank (uncomperssed video) or
+ * HCactive and HCblank (compressed video transport), there may be a
+ * third FRL Map Charected. Therefore this spec assumes 2.5 FRL Map Charecters
+ * per Super Block.
+ */
+static u32 drm_get_overhead_frl_map_char(u32 lanes)
+{
+ return (25 * EFFICIENCY_MULTIPLIER) / (10 *
drm_get_frl_char_per_super_blk(lanes));
+}
+
+/* Total minimum overhead multiplied by EFFICIENCY_MULIPLIER */
+static u32 drm_get_total_minimum_overhead(u32 lanes)
+{
+ u32 total_overhead_min;
+ u32 overhead_sb = drm_get_overhead_super_blk(lanes);
+ u32 overhead_rs = drm_get_overhead_rs(lanes);
+ u32 overhead_map = drm_get_overhead_frl_map_char(lanes);
+
+ total_overhead_min = overhead_sb + overhead_rs + overhead_map;
+
+ return total_overhead_min;
+}
+
+/*
+ * Additional margin to the overhead is provided to account for the possibility
+ * of more Map Charecters, zero padding at the end of HCactive, and other minor
+ * items
+ */
+static u32 drm_get_max_overhead(u32 total_overhead_min)
+{
+ u32 total_overhead_max;
+
+ total_overhead_max = total_overhead_min + OVERHEAD_M;
+ return total_overhead_max;
+}
+
+/* Collect the link charecteristics */
+
+/* Determine the maximum legal pixel rate */
+static u32 drm_get_max_legal_pixel_rate(u32 fpixel_clock_nominal_k)
+{
+ u32 fpixel_clock_max_k = (fpixel_clock_nominal_k *
+ (1000 + TOLERANCE_PIXEL_CLOCK)) / 1000;
+ return fpixel_clock_max_k;
+}
+
+/* Determine the minimum Video Line period */
+static u32 drm_get_min_video_line_period(u32 hactive, u32 hblank,
+u32 fpixel_clock_max_k)
+{
+ u32 line_time_ns;
+
+ line_time_ns = ((hactive + hblank) * FRL_TIMING_NS_MULTIPLIER) /
+ fpixel_clock_max_k;
+ return line_time_ns;
+}
+
+/* Determine the worst-case slow FRL Bit Rate in kbps*/
+static u32 drm_get_min_frl_bit_rate(u32 frl_bit_rate_nominal_k)
+{
+ u32 frl_bit_rate_min_k;
+
+ frl_bit_rate_min_k = (frl_bit_rate_nominal_k / 100) *
+(100 - TOLERANCE_FRL_BIT_RATE);
+ return frl_bit_rate_min_k;
+}
+
+/* Determine the worst-case slow FRL Charecter Rate */
+static u32 drm_get_min_frl_char_rate(u32 frl_bit_rate_min_k)
+{
+ u32 frl_char_rate_min_k;
+
+ frl_char_rate_min_k = frl_bit_rate_min_k / 18;
+ return frl_char_rate_min_k;
+}
+
+/* Determine the Minimum Total FRL charecters per line period */
+static u32
+drm_get_total_frl_char_per_line_period(u32 line_time_ns, u32
frl_char_rate_min_k,
+ u32 lanes)
+{
+ u32 frl_char_per_line_period;
+
+ frl_char_per_line_period = (line_time_ns * frl_char_rate_min_k * lanes *
+ 1000) / FRL_TIMING_NS_MULTIPLIER;
+ return frl_char_per_line_period;
+}
+
+/* Audio Support Verification Computations */
+
+/*
+ * Determine Audio Related Packet Rate considering the audio clock
+ * increased to maximim rate permitted by Tolerance Audio clock
+ */
+static u32
+drm_get_audio_pkt_rate(u32 f_audio, u32 num_audio_pkt)
+{
+ u32 audio_pkt_rate;
+
+ audio_pkt_rate = ((f_audio * num_audio_pkt + (2 *
[RFC 0/5] Add data flow metering support for HDMI2.1
The below patches add support for data flow metering as mentioned in the section 6.5.6 FRL data flow metering of HDMI 2.1 specification. Add functions to calclulate the DFM parameters for the given frl config, which is further used to evaluate the data flow metering requirement as specified in the spec. As per the spec the below patches implement the frl capacity computation functions for both compressed and uncompressed video. Finally exposing 1 function each for compressed and uncompressed video to figure out if the data flow metering requirement is met or not. Ankit Nautiyal (1): drm/hdmi21: Add support for DFM calculation with DSC Vandita Kulkarni (4): drm/hdmi21: Define frl_dfm structure drm/hdmi21: Add non dsc frl capacity computation helpers drm/hdmi21: Add helpers to verify non-dsc DFM requirements drm/hdmi21: Add frl_dfm_helper to Makefile drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_frl_dfm_helper.c | 855 +++ include/drm/drm_frl_dfm_helper.h | 131 3 files changed, 987 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/drm/drm_frl_dfm_helper.c create mode 100644 include/drm/drm_frl_dfm_helper.h -- 2.32.0
[RFC 1/5] drm/hdmi21: Define frl_dfm structure
Define frl_dfm structure to hold frl characteristics
needed for frl capacity computation in order to
meet the data flow metering requirement.
Signed-off-by: Vandita Kulkarni
---
include/drm/drm_frl_dfm_helper.h | 126 +++
1 file changed, 126 insertions(+)
create mode 100644 include/drm/drm_frl_dfm_helper.h
diff --git a/include/drm/drm_frl_dfm_helper.h b/include/drm/drm_frl_dfm_helper.h
new file mode 100644
index ..16b8fcc7cbcc
--- /dev/null
+++ b/include/drm/drm_frl_dfm_helper.h
@@ -0,0 +1,126 @@
+/* SPDX-License-Identifier: MIT
+ * Copyright © 2022 Intel Corp
+ */
+
+#ifndef DRM_FRL_DFM_H_
+#define DRM_FRL_DFM_H_
+
+/* DFM constraints and tolerance values from HDMI2.1 spec */
+#define TB_BORROWED_MAX400
+#define FRL_CHAR_PER_CHAR_BLK 510
+/* Tolerance pixel clock unit is in mHz */
+#define TOLERANCE_PIXEL_CLOCK 5
+#define TOLERANCE_FRL_BIT_RATE 300
+#define TOLERANCE_AUDIO_CLOCK 1000
+#define ACR_RATE_MAX 1500
+#define EFFICIENCY_MULTIPLIER 1000
+#define OVERHEAD_M (3 * EFFICIENCY_MULTIPLIER / 1000)
+#define BPP_MULTIPLIER 16
+#define FRL_TIMING_NS_MULTIPLIER 10
+
+/* ALl the input config needed to compute DFM requirements */
+struct drm_frl_dfm_input_config {
+
+ /*
+* Pixel clock rate kHz, when FVA is
+* enabled this rate is the rate after adjustment
+*/
+ u32 pixel_clock_nominal_khz;
+
+ /* active pixels per line */
+ u32 hactive;
+
+ /* Blanking pixels per line */
+ u32 hblank;
+
+ /* Bits per component */
+ u32 bpc;
+
+ /* Pixel encoding */
+ u32 color_format;
+
+ /* FRL bit rate in kbps */
+ u32 bit_rate_kbps;
+
+ /* FRL lanes */
+ u32 lanes;
+
+ /* Number of audio channels */
+ u32 audio_channels;
+
+ /* Audio rate in Hz */
+ u32 audio_hz;
+
+ /* Selected bpp target value */
+ u32 target_bpp_16;
+
+ /*
+* Number of horizontal pixels in a slice.
+* Equivalent to PPS parameter slice_width
+*/
+ u32 slice_width;
+};
+
+/* Computed dfm parameters as per the HDMI2.1 spec */
+struct drm_frl_dfm_params {
+
+ /*
+* Link overhead in percentage
+* multiplied by 1000 (efficiency multiplier)
+*/
+ u32 overhead_max;
+
+ /* Maximum pixel rate in kHz */
+ u32 pixel_clock_max_khz;
+
+ /* Minimum video line period in nano sec */
+ u32 line_time_ns;
+
+ /* worst case slow frl character rate in kbps */
+ u32 char_rate_min_kbps;
+
+ /* minimum total frl charecters per line perios */
+ u32 cfrl_line;
+
+ /* Average tribyte rate in khz */
+ u32 ftb_avg_k;
+
+ /* Audio characteristics */
+
+ /* number of audio packets needed during hblank */
+ u32 num_audio_pkts_line;
+
+ /*
+* Minimum required hblank assuming no control preiod
+* RC compression
+*/
+ u32 hblank_audio_min;
+
+ /* Number of tribytes required to carry active video */
+ u32 tb_active;
+
+ /* Total available tribytes during the blanking period */
+ u32 tb_blank;
+
+ /*
+* Number of tribytes required to be transmitted during
+* the hblank period
+*/
+ u32 tb_borrowed;
+
+ /* DSC frl characteristics */
+
+ /* Tribytes required to carry the target bpp */
+ u32 hcactive_target;
+
+ /* tribytes available during blanking with target bpp */
+ u32 hcblank_target;
+};
+
+/* FRL DFM structure to hold involved in DFM computation */
+struct drm_hdmi_frl_dfm {
+ struct drm_frl_dfm_input_config config;
+ struct drm_frl_dfm_params params;
+};
+
+#endif
--
2.32.0
Re: [PATCH 09/21] fbcon: Replace FBCON_FLAGS_INIT with a boolean
On Wed, Feb 2, 2022 at 10:25 AM Thomas Zimmermann wrote:
> Am 31.01.22 um 22:05 schrieb Daniel Vetter:
> > It's only one flag and slightly tidier code.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Daniel Vetter
> > Cc: Tetsuo Handa
> > Cc: Greg Kroah-Hartman
> > Cc: Du Cheng
> > Cc: Thomas Zimmermann
> > Cc: Claudio Suarez
>
> Acked-by: Thomas Zimmermann
> > +++ b/drivers/video/fbdev/core/fbcon.h
> > @@ -18,8 +18,6 @@
> >
> > #include
> >
> > -#define FBCON_FLAGS_INIT 1
> > -
> > /*
> > *This is the interface between the low-level console driver and
> > the
> > *low-level frame buffer device
> > @@ -77,7 +75,7 @@ struct fbcon_ops {
> > intblank_state;
> > intgraphics;
> > intsave_graphics; /* for debug enter/leave */
> > - intflags;
> > + bool initialized;
>
> This will add 3 bytes of padding. Maybe you can put the bool elsewhere.
Several of the int variables are used as boolean flags, too.
Perhaps convert them all to bitfields?
unsigned int initialized : 1;
...
> > introtate;
> > intcur_rotate;
> > char *cursor_data;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH v3] drm: document struct drm_mode_fb_cmd2
Follow-up for the DRM_IOCTL_MODE_GETFB2 docs.
v2: (Daniel Stone)
- Replace fourcc.org with drm_fourcc.h because this is the
authoritative source and the website may have mismatches.
- Drop assumption that offsets will generally be 0.
- Mention that unused entries must be zero'ed out.
v3: (Pekka)
- Mention that a handle can be re-used
- Add unit for pitches/offsets
Signed-off-by: Simon Ser
Reviewed-by: Daniel Vetter
Acked-by: Pekka Paalanen
Cc: Daniel Stone
---
include/uapi/drm/drm_mode.h | 88 +
1 file changed, 60 insertions(+), 28 deletions(-)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index e1e351682872..0a0d56a6158e 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -663,41 +663,73 @@ struct drm_mode_fb_cmd {
#define DRM_MODE_FB_INTERLACED (1<<0) /* for interlaced framebuffers */
#define DRM_MODE_FB_MODIFIERS (1<<1) /* enables ->modifer[] */
+/**
+ * struct drm_mode_fb_cmd2 - Frame-buffer metadata.
+ *
+ * This struct holds frame-buffer metadata. There are two ways to use it:
+ *
+ * - User-space can fill this struct and perform a _IOCTL_MODE_ADDFB2
+ * ioctl to register a new frame-buffer. The new frame-buffer object ID will
+ * be set by the kernel in @fb_id.
+ * - User-space can set @fb_id and perform a _IOCTL_MODE_GETFB2 ioctl to
+ * fetch metadata about an existing frame-buffer.
+ *
+ * In case of planar formats, this struct allows up to 4 buffer objects with
+ * offsets and pitches per plane. The pitch and offset order is dictated by the
+ * format FourCC as defined by ``drm_fourcc.h``, e.g. NV12 is described as:
+ *
+ * YUV 4:2:0 image with a plane of 8 bit Y samples followed by an
+ * interleaved U/V plane containing 8 bit 2x2 subsampled colour difference
+ * samples.
+ *
+ * So it would consist of a Y plane at ``offsets[0]`` and a UV plane at
+ * ``offsets[1]``.
+ *
+ * To accommodate tiled, compressed, etc formats, a modifier can be specified.
+ * For more information see the "Format Modifiers" section. Note that even
+ * though it looks like we have a modifier per-plane, we in fact do not. The
+ * modifier for each plane must be identical. Thus all combinations of
+ * different data layouts for multi-plane formats must be enumerated as
+ * separate modifiers.
+ *
+ * All of the entries in @handles, @pitches, @offsets and @modifier must be
+ * zero when unused. Warning, for @offsets and @modifier zero can't be used to
+ * figure out whether the entry is used or not since it's a valid value (a zero
+ * offset is common, and a zero modifier is _FORMAT_MOD_LINEAR).
+ */
struct drm_mode_fb_cmd2 {
+ /** @fb_id: Object ID of the frame-buffer. */
__u32 fb_id;
+ /** @width: Width of the frame-buffer. */
__u32 width;
+ /** @height: Height of the frame-buffer. */
__u32 height;
- __u32 pixel_format; /* fourcc code from drm_fourcc.h */
- __u32 flags; /* see above flags */
+ /**
+* @pixel_format: FourCC format code, see ``DRM_FORMAT_*`` constants in
+* ``drm_fourcc.h``.
+*/
+ __u32 pixel_format;
+ /**
+* @flags: Frame-buffer flags (see _MODE_FB_INTERLACED and
+* _MODE_FB_MODIFIERS).
+*/
+ __u32 flags;
- /*
-* In case of planar formats, this ioctl allows up to 4
-* buffer objects with offsets and pitches per plane.
-* The pitch and offset order is dictated by the fourcc,
-* e.g. NV12 (https://fourcc.org/yuv.php#NV12) is described as:
-*
-* YUV 4:2:0 image with a plane of 8 bit Y samples
-* followed by an interleaved U/V plane containing
-* 8 bit 2x2 subsampled colour difference samples.
-*
-* So it would consist of Y as offsets[0] and UV as
-* offsets[1]. Note that offsets[0] will generally
-* be 0 (but this is not required).
-*
-* To accommodate tiled, compressed, etc formats, a
-* modifier can be specified. The default value of zero
-* indicates "native" format as specified by the fourcc.
-* Vendor specific modifier token. Note that even though
-* it looks like we have a modifier per-plane, we in fact
-* do not. The modifier for each plane must be identical.
-* Thus all combinations of different data layouts for
-* multi plane formats must be enumerated as separate
-* modifiers.
+ /**
+* @handles: GEM buffer handle, one per plane. Set to 0 if the plane is
+* unused. The same handle can be used for multiple planes.
*/
__u32 handles[4];
- __u32 pitches[4]; /* pitch for each plane */
- __u32 offsets[4]; /* offset of each plane */
- __u64 modifier[4]; /* ie, tiling, compress */
+ /** @pitches: Pitch (aka. stride) in bytes, one per plane. */
+ __u32 pitches[4];
+ /** @offsets: Offset into the buffer
Re: [PATCH v6 1/3] drm/lsdc: add drm driver for loongson display controller
On Thu, Feb 03, 2022 at 12:29:11PM +0100, Krzysztof Kozlowski wrote: > On Thu, 3 Feb 2022 at 12:08, Dan Carpenter wrote: > > > > > > This does not look like compliant with GPL-2.0. You cannot call a > > > license GPL-2.0 and restrict it with some other provisions. > > > > That's the MIT license. It's not the GPL-2.0 license but it is > > compliant. > > It's compliant when included as "OR" for example in SPDX tag. The > current solution - SPDX and MIT license text - is not the proper way > to describe this. Otherwise one could argue that both licenses apply > at the same time and one has to fulfill both of them, which is > ridiculous. There is a SPDX tag for the proper case - GPL or MIT. You're saying a bunch of different things. We both agree that the SPDX text is confusing because it says GPL-2.0+ but it has the text from the MIT license. "This does not look like compliant with GPL-2.0." Wrong. The MIT license is compatible with the GPL-2.0. "You cannot call a license GPL-2.0 and restrict it with some other provisions." Wrong. The MIT license just says you have to include the No Warranty text. The GPL has it's own list of requirements. But you can combine MIT and GPL code and easily comply with both requirements. That's what "compatible" means in this context. In the kernel we have MIT licensed code which is dual licensed. This means that someone can take that driver and release it as closed source software if they want. // SPDX-License-Identifier: GPL-2.0 OR MIT Then we also have code which was originally MIT licensed but now you have to comply with the GPL as well. // SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) AND MIT These examples were cut and paste from Documentation/process/license-rules.rst regards, dan carpenter
[PATCH 7/7] drm/selftests: add drm buddy pathological testcase
create a pot-sized mm, then allocate one of each possible
order within. This should leave the mm with exactly one
page left. Free the largest block, then whittle down again.
Eventually we will have a fully 50% fragmented mm.
Signed-off-by: Arunpravin
---
.../gpu/drm/selftests/drm_buddy_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_buddy.c| 136 ++
2 files changed, 137 insertions(+)
diff --git a/drivers/gpu/drm/selftests/drm_buddy_selftests.h
b/drivers/gpu/drm/selftests/drm_buddy_selftests.h
index 411d072cbfc5..455b756c4ae5 100644
--- a/drivers/gpu/drm/selftests/drm_buddy_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_buddy_selftests.h
@@ -12,3 +12,4 @@ selftest(buddy_alloc_range, igt_buddy_alloc_range)
selftest(buddy_alloc_optimistic, igt_buddy_alloc_optimistic)
selftest(buddy_alloc_pessimistic, igt_buddy_alloc_pessimistic)
selftest(buddy_alloc_smoke, igt_buddy_alloc_smoke)
+selftest(buddy_alloc_pathological, igt_buddy_alloc_pathological)
diff --git a/drivers/gpu/drm/selftests/test-drm_buddy.c
b/drivers/gpu/drm/selftests/test-drm_buddy.c
index 2074e8c050a4..b2d0313a4bc5 100644
--- a/drivers/gpu/drm/selftests/test-drm_buddy.c
+++ b/drivers/gpu/drm/selftests/test-drm_buddy.c
@@ -338,6 +338,142 @@ static void igt_mm_config(u64 *size, u64 *chunk_size)
*size = (u64)s << 12;
}
+static int igt_buddy_alloc_pathological(void *arg)
+{
+ u64 mm_size, size, min_page_size, start = 0;
+ struct drm_buddy_block *block;
+ const int max_order = 3;
+ unsigned long flags = 0;
+ int order, top, err;
+ struct drm_buddy mm;
+ LIST_HEAD(blocks);
+ LIST_HEAD(holes);
+ LIST_HEAD(tmp);
+
+ /*
+* Create a pot-sized mm, then allocate one of each possible
+* order within. This should leave the mm with exactly one
+* page left. Free the largest block, then whittle down again.
+* Eventually we will have a fully 50% fragmented mm.
+*/
+
+ mm_size = PAGE_SIZE << max_order;
+ err = drm_buddy_init(, mm_size, PAGE_SIZE);
+ if (err) {
+ pr_err("buddy_init failed(%d)\n", err);
+ return err;
+ }
+ BUG_ON(mm.max_order != max_order);
+
+ for (top = max_order; top; top--) {
+ /* Make room by freeing the largest allocated block */
+ block = list_first_entry_or_null(, typeof(*block), link);
+ if (block) {
+ list_del(>link);
+ drm_buddy_free_block(, block);
+ }
+
+ for (order = top; order--; ) {
+ size = min_page_size = get_size(order, PAGE_SIZE);
+ err = drm_buddy_alloc_blocks(, start, mm_size, size,
+min_page_size, ,
flags);
+ if (err) {
+ pr_info("buddy_alloc hit -ENOMEM with order=%d,
top=%d\n",
+ order, top);
+ goto err;
+ }
+
+ block = list_first_entry_or_null(,
+struct drm_buddy_block,
+link);
+ if (!block) {
+ pr_err("alloc_blocks has no blocks\n");
+ err = -EINVAL;
+ goto err;
+ }
+
+ list_del(>link);
+ list_add_tail(>link, );
+ }
+
+ /* There should be one final page for this sub-allocation */
+ size = min_page_size = get_size(0, PAGE_SIZE);
+ err = drm_buddy_alloc_blocks(, start, mm_size, size,
min_page_size, , flags);
+ if (err) {
+ pr_info("buddy_alloc hit -ENOME for hole\n");
+ goto err;
+ }
+
+ block = list_first_entry_or_null(,
+struct drm_buddy_block,
+link);
+ if (!block) {
+ pr_err("alloc_blocks has no blocks\n");
+ err = -EINVAL;
+ goto err;
+ }
+
+ list_del(>link);
+ list_add_tail(>link, );
+
+ size = min_page_size = get_size(top, PAGE_SIZE);
+ err = drm_buddy_alloc_blocks(, start, mm_size, size,
min_page_size, , flags);
+ if (!err) {
+ pr_info("buddy_alloc unexpectedly succeeded at
top-order %d/%d, it should be full!",
+ top, max_order);
+ block = list_first_entry_or_null(,
+struct drm_buddy_block,
+
