Re: [PATCH] drm/msm: Initialize mode_config earlier
On Mon, Jan 16, 2023 at 08:51:22PM -0600, Bjorn Andersson wrote: > On Fri, Jan 13, 2023 at 10:57:18AM +0200, Dmitry Baryshkov wrote: > > On 13/01/2023 06:23, Dmitry Baryshkov wrote: > > > On 13/01/2023 06:10, Bjorn Andersson wrote: > > > > Invoking drm_bridge_hpd_notify() on a drm_bridge with a HPD-enabled > > > > bridge_connector ends up in drm_bridge_connector_hpd_cb() calling > > > > drm_kms_helper_hotplug_event(), which assumes that the associated > > > > drm_device's mode_config.funcs is a valid pointer. > > > > > > > > But in the MSM DisplayPort driver the HPD enablement happens at bind > > > > time and mode_config.funcs is initialized late in msm_drm_init(). This > > > > means that there's a window for hot plug events to dereference a NULL > > > > mode_config.funcs. > > > > > > > > Move the assignment of mode_config.funcs before the bind, to avoid this > > > > scenario. > > > > > > Cam we make DP driver not to report HPD events until the enable_hpd() > > > was called? I think this is what was fixed by your internal_hpd > > > patchset. > > > > Or to express this in another words: I thought that internal_hpd already > > deferred enabling hpd event reporting till the time when we need it, didn't > > it? > > > > I added a WARN_ON(1) in drm_bridge_hpd_enable() to get a sense of when > this window of "opportunity" opens up, and here's the callstack: > > [ cut here ] > WARNING: CPU: 6 PID: 99 at drivers/gpu/drm/drm_bridge.c:1260 > drm_bridge_hpd_enable+0x48/0x94 [drm] > ... > Call trace: > drm_bridge_hpd_enable+0x48/0x94 [drm] > drm_bridge_connector_enable_hpd+0x30/0x3c [drm_kms_helper] > drm_kms_helper_poll_enable+0xa4/0x114 [drm_kms_helper] > drm_kms_helper_poll_init+0x6c/0x7c [drm_kms_helper] > msm_drm_bind+0x370/0x628 [msm] > try_to_bring_up_aggregate_device+0x170/0x1bc > __component_add+0xb0/0x168 > component_add+0x20/0x2c > dp_display_probe+0x40c/0x468 [msm] > platform_probe+0xb4/0xdc > really_probe+0x13c/0x300 > __driver_probe_device+0xc0/0xec > driver_probe_device+0x48/0x204 > __device_attach_driver+0x124/0x14c > bus_for_each_drv+0x90/0xdc > __device_attach+0xdc/0x1a8 > device_initial_probe+0x20/0x2c > bus_probe_device+0x40/0xa4 > deferred_probe_work_func+0x94/0xd0 > process_one_work+0x1a8/0x3c0 > worker_thread+0x254/0x47c > kthread+0xf8/0x1b8 > ret_from_fork+0x10/0x20 > ---[ end trace ]--- > > As drm_kms_helper_poll_init() is the last thing being called in > msm_drm_init() shifting around the mode_config.func assignment would not > have any impact. > > Perhaps we have shuffled other things around to avoid this bug? Either > way, let's this on hold until further proof that it's still > reproducible. As I've mentioned off list, I haven't hit the apparent race I reported here: https://lore.kernel.org/all/y1efjh11b5uqz...@hovoldconsulting.com/ since moving to 6.2. I did hit it with both 6.0 and 6.1-rc2, but it could very well be that something has changes that fixes (or hides) the issue since. Johan
Re: [PATCH] drm/ttm: Include to fix MIPS build
Hi
Am 16.01.23 um 15:40 schrieb Christian König:
Am 16.01.23 um 13:13 schrieb Thomas Zimmermann:
I'd add a Fixes tag, but don't know the commit when this was introduced.
Mhm, that code is 10+ years old. My educated guess is that we somehow
pulled in vmap/vunmap through a header which was now cleaned up.
Yeah, I assume it was introduced by a3185f91d057 ("drm/ttm: merge
ttm_bo_api.h and ttm_bo_driver.h v2")
Anyway your patch looks good to me, feel free to add my rb.
Thank you. Merged into drm-misc-next now.
Best regards
Thomas
Christian.
Am 16.01.23 um 13:10 schrieb Thomas Zimmermann:
On MIPS, vmap() and vunmap() are undeclared in ttm_bo_util.c. An
error message is shown below.
CC drivers/gpu/drm/ttm/ttm_bo_util.o
../drivers/gpu/drm/ttm/ttm_bo_util.c: In function 'ttm_bo_kmap_ttm':
../drivers/gpu/drm/ttm/ttm_bo_util.c:364:32: error: implicit
declaration of function 'vmap'; did you mean 'kmap'?
[-Werror=implicit-function-declaration]
364 | map->virtual = vmap(ttm->pages +
start_page, num_pages,
| ^~~~
| kmap
../drivers/gpu/drm/ttm/ttm_bo_util.c:364:30: warning: assignment
to 'void *' from 'int' makes pointer from integer without a cast
[-Wint-conversion]
364 | map->virtual = vmap(ttm->pages +
start_page, num_pages,
| ^
../drivers/gpu/drm/ttm/ttm_bo_util.c: In function 'ttm_bo_kunmap':
../drivers/gpu/drm/ttm/ttm_bo_util.c:429:17: error: implicit
declaration of function 'vunmap'; did you mean 'kunmap'?
[-Werror=implicit-function-declaration]
429 | vunmap(map->virtual);
| ^~
| kunmap
../drivers/gpu/drm/ttm/ttm_bo_util.c: In function 'ttm_bo_vmap':
../drivers/gpu/drm/ttm/ttm_bo_util.c:509:23: warning: assignment
to 'void *' from 'int' makes pointer from integer without a cast
[-Wint-conversion]
509 | vaddr = vmap(ttm->pages, ttm->num_pages,
0, prot);
| ^
Fix this by including .
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 12017ec24d9f..8e19a40cb41d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -29,6 +29,8 @@
* Authors: Thomas Hellstrom
*/
+#include
+
#include
#include
#include
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH 7/8] iommu/intel: Support the gfp argument to the map_pages op
On 2023/1/17 11:38, Tian, Kevin wrote: From: Jason Gunthorpe Sent: Saturday, January 7, 2023 12:43 AM @@ -2368,7 +2372,7 @@ static int iommu_domain_identity_map(struct dmar_domain *domain, return __domain_mapping(domain, first_vpfn, first_vpfn, last_vpfn - first_vpfn + 1, - DMA_PTE_READ|DMA_PTE_WRITE); + DMA_PTE_READ|DMA_PTE_WRITE, GFP_KERNEL); } Baolu, can you help confirm whether switching from GFP_ATOMIC to GFP_KERNEL is OK in this path? it looks fine to me in a quick glance but want to be conservative here. This is also good for me. The memory notifier callback runs in a process context and allowed to block. Best regards, baolu
Re: [PATCH 00/22] drm: Remove includes for drm_crtc_helper.h
Hi Am 16.01.23 um 19:37 schrieb Alex Deucher: On Mon, Jan 16, 2023 at 11:20 AM Jani Nikula wrote: On Mon, 16 Jan 2023, Thomas Zimmermann wrote: A lot of source files include drm_crtc_helper.h for its contained include statements. This leads to excessive compile-time dependencies. Where possible, remove the include statements for drm_crtc_helper.h and include the required source files directly. Also remove the include statements from drm_crtc_helper.h itself, which doesn't need most of them. I built this patchset on x86-64, aarch64 and arm. Hopefully I found all include dependencies. I think this is the right direction and I support this. Personally I think it's enough to build test and fix any fallout afterwards. To that end, I did build test this myself with my config, and it was fine, though that probably doesn't add much coverage. FWIW, Acked-by: Jani Nikula Agreed. I applied 1/22 since it was an unrelated cleanup, but the rest of the series is: Acked-by: Alex Deucher Thanks to both of you. I'll leave out the first patch when merging the series. Best regards Thomas -- Jani Nikula, Intel Open Source Graphics Center -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH 00/22] drm: Remove includes for drm_crtc_helper.h
Hi Am 16.01.23 um 21:47 schrieb Sam Ravnborg: Hi Thomas. On Mon, Jan 16, 2023 at 02:12:13PM +0100, Thomas Zimmermann wrote: A lot of source files include drm_crtc_helper.h for its contained include statements. This leads to excessive compile-time dependencies. Where possible, remove the include statements for drm_crtc_helper.h and include the required source files directly. Also remove the include statements from drm_crtc_helper.h itself, which doesn't need most of them. With this patchset drm_crtc_helper usage is reduced from 85 places to 35 places. And the 35 places is only .c files. This is a very nice reduction of bloat! I hope this has a measureable effect on building times. I cannot say what the effect is for a single header, but if we do this for all header files, the effect is measureable. I was working on something similar, but that approach only added missing includes, and did not kill all the unnessesary includes - which I think is the biggest win here. All patches are: Reviewed-by: Sam Ravnborg Thank you. For a few of them the r-b is conditional, see the specific comments posted. I fixed all your comments, including the minor complaint about the commit messages. I don't intent to send out a v2 here, but the fixed patches should soon show up in drm-misc-next. Best regards Thomas I did a build check here with the archs and config I verifies with. This covers "alpha arm arm64 sparc64 i386 x86 powerpc s390 riscv sh" and everything was fine. I have a few specific configs to pull in drivers that need a bit extra to be built. So I consider build coverage OK for applying, but it would be nice to wait a few days for the bots to verify too. My own work on slimming drm_atomic_helper.h and drm_print.h will be rebased on top of your work before I continue it. I need to look into removing unused includes too. Sam I built this patchset on x86-64, aarch64 and arm. Hopefully I found all include dependencies. Thanks to Sam Ravnborg for bringing this to my attention. Thomas Zimmermann (22): drm/amdgpu: Fix coding style drm: Remove unnecessary include statements for drm_crtc_helper.h drm/amdgpu: Remove unnecessary include statements for drm_crtc_helper.h drm/arm/komeda: Remove unnecessary include statements for drm_crtc_helper.h drm/aspeed: Remove unnecessary include statements for drm_crtc_helper.h drm/ast: Remove unnecessary include statements for drm_crtc_helper.h drm/bridge: Remove unnecessary include statements for drm_crtc_helper.h drm/gma500: Remove unnecessary include statements for drm_crtc_helper.h drm/i2c/ch7006: Remove unnecessary include statements for drm_crtc_helper.h drm/ingenic: Remove unnecessary include statements for drm_crtc_helper.h drm/kmb: Remove unnecessary include statements for drm_crtc_helper.h drm/logicvc: Remove unnecessary include statements for drm_crtc_helper.h drm/nouveau: Remove unnecessary include statements for drm_crtc_helper.h drm/radeon: Remove unnecessary include statements for drm_crtc_helper.h drm/rockchip: Remove unnecessary include statements for drm_crtc_helper.h drm/shmobile: Remove unnecessary include statements for drm_crtc_helper.h drm/sprd: Remove unnecessary include statements for drm_crtc_helper.h drm/sun4i: Remove unnecessary include statements for drm_crtc_helper.h drm/tidss: Remove unnecessary include statements for drm_crtc_helper.h drm/udl: Remove unnecessary include statements for drm_crtc_helper.h drm/vboxvideo: Remove unnecessary include statements for drm_crtc_helper.h drm/crtc-helper: Remove most include statements from drm_crtc_helper.h drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 2 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c| 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 - drivers/gpu/drm/amd/amdgpu/atombios_crtc.c | 1 - drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 1 - drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 2 ++ drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 ++ drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 2 ++ drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 ++ drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 1 - drivers/gpu/drm/arm/display/komeda/komeda_kms.h| 1 - drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 1 - drivers/gpu/drm/aspeed/aspeed_gfx_drv.c| 1 - drivers/gpu/drm/aspeed/aspeed_gfx_out.c| 1 - drivers/gpu/drm/ast/ast_drv.c | 1 - drivers/gpu/drm/ast/ast_main.c | 1 - drivers/gpu/drm/ast/ast_mode.c | 1 - drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
Re: [PATCH] drm/i915/selftests: Unwind hugepages to drop wakeref on error
On 1/16/2023 7:49 PM, Andi Shyti wrote:
Hi Nirmoy,
On Fri, Jan 13, 2023 at 01:00:53PM +0100, Nirmoy Das wrote:
From: Chris Wilson
Make sure that upon error after we have acquired the wakeref we do
release it again.
Fixes: 027c38b4121e ("drm/i915/selftests: Grab the runtime pm in shrink_thp")
Reviewed-by: Matthew Auld
Signed-off-by: Chris Wilson
Signed-off-by: Nirmoy Das
Cc: # v6.0+
---
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index c281b0ec9e05..295d6f2cc4ff 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1855,7 +1855,7 @@ static int igt_shrink_thp(void *arg)
I915_SHRINK_ACTIVE);
i915_vma_unpin(vma);
if (err)
- goto out_put;
+ goto out_wf;
/*
* Now that the pages are *unpinned* shrinking should invoke
@@ -1871,7 +1871,7 @@ static int igt_shrink_thp(void *arg)
pr_err("unexpected pages mismatch, should_swap=%s\n",
str_yes_no(should_swap));
err = -EINVAL;
- goto out_put;
+ goto out_wf;
}
aren't we missing here one out_put -> out_wf change?
This one:
@@ -1878,7 +1878,7 @@ static int igt_shrink_thp(void *arg)
pr_err("unexpected residual page-size bits, should_swap=%s\n",
str_yes_no(should_swap));
err = -EINVAL;
- goto out_put;
+ goto out_wf;
Thanks for catching this. Yes, we need this too. I will resend.
Nirmoy
}
err = i915_vma_pin(vma, 0, 0, flags);
Andi
if (should_swap == (obj->mm.page_sizes.sg || obj->mm.page_sizes.phys)) {
@@ -1883,7 +1883,7 @@ static int igt_shrink_thp(void *arg)
err = i915_vma_pin(vma, 0, 0, flags);
if (err)
- goto out_put;
+ goto out_wf;
while (n--) {
err = cpu_check(obj, n, 0xdeadbeaf);
--
2.39.0
Re: [PATCH 8/8] iommu/s390: Push the gfp parameter to the kmem_cache_alloc()'s
On Fri, 2023-01-06 at 12:42 -0400, Jason Gunthorpe wrote: > dma_alloc_cpu_table() and dma_alloc_page_table() are eventually called by > iommufd through s390_iommu_map_pages() and it should not be forced to > atomic. Thread the gfp parameter through the call chain starting from > s390_iommu_map_pages(). > > Signed-off-by: Jason Gunthorpe > --- > arch/s390/include/asm/pci_dma.h | 5 +++-- > arch/s390/pci/pci_dma.c | 31 +-- > drivers/iommu/s390-iommu.c | 15 +-- > 3 files changed, 29 insertions(+), 22 deletions(-) > ---8<--- > Looks good to me and I have no objections. Reviewed-by: Niklas Schnelle
Re: [PATCH] drm/connector: fix a kernel-doc bad line warning
Reviewed-by: Simon Ser
[PATCH v6 0/7] New DRM accel driver for Intel VPU
Hi, This patchset contains a new Linux* Kernel Driver for Intel® VPUs. VPU stands for Versatile Processing Unit and it is an AI inference accelerator integrated with Intel non-server CPUs starting from 14th generation. VPU enables efficient execution of Deep Learning applications like object detection, classification etc. The whole driver is licensed under GPL-2.0-only except for two headers imported from the firmware that are MIT licensed. User space stack is open source and available at: - UMD driver: https://github.com/intel/linux-vpu-driver - Compiler and OpenVINO plugin: https://github.com/openvinotoolkit/vpux-plugin The firmware for the VPU will be distributed as a closed source binary in the UMD driver repo. This is hopefully the last revision of the patchset with minor changes outlined below. Regards, Jacek Changelog v6: - Remove userptr ioctl as it will be probably replaced with dma-buf heaps - Added dependency on !UML - Simplify struct file_operations ivpu_fops definition - Fixed compilation issues in patch 4 and 6 - Updated TODO v5: https://lore.kernel.org/all/20230109122344.253994-1-jacek.lawrynow...@linux.intel.com/ - Rename ivpu_drm.h to ivpu_accel.h - Cleanup ivpu_mmu_config_check() - Optimize locking in ivpu_mmu_cd_add() - Invalidate user context if it has MMU faults - Move ivpu_ipc_match_consumer() outside ivpu_ipc_dispatch() v4: https://lore.kernel.org/all/20221208110733.5498-1-jacek.lawrynow...@linux.intel.com/ - Switch to the accel framework (DRIVER_COMPUTE_ACCEL) - Move the driver from drivers/gpu/drm to drivers/accel - Rename kconfig DRM_IVPU option to DRM_ACCEL_IVPU and update dependencies - Create context on open() instead of lazy allocating it - Remove status_offset from submit ioctl, as status is now reported in bo_wait ioctl - Use managed resources in ivpu_drv.c - Optimize locking in ivpu_ipc.c - add new rx_msg_lock for consumer msg list - Refactor vpu_hw_mtl_reg.h to use BIT_MASK() and GENMASK() macros - Use module_pci_driver() for mudule init - Remove mutex from "struct ivpu_pm_info" - Add explicit "vdev" arg to ivpu_dbg() - Use drm_WARN_ON() instead of WARN_ON() where possible - Add comments for boot related functions - Update firmware API headers v3: https://lore.kernel.org/all/20220924151149.323622-1-jacek.lawrynow...@linux.intel.com/ - Fixed alignment warning in ivpu_ipc.c when building with W=1 v2: https://lore.kernel.org/all/20220913121017.993825-1-jacek.lawrynow...@linux.intel.com/ - Rename the driver from "drm/vpu" to "drm/ivpu" - Add a TODO file - Add support for WC buffers v1: https://lore.kernel.org/all/20220728131709.1087188-1-jacek.lawrynow...@linux.intel.com/ Jacek Lawrynowicz (7): accel/ivpu: Introduce a new DRM driver for Intel VPU accel/ivpu: Add Intel VPU MMU support accel/ivpu: Add GEM buffer object management accel/ivpu: Add IPC driver and JSM messages accel/ivpu: Implement firmware parsing and booting accel/ivpu: Add command buffer submission logic accel/ivpu: Add PM support MAINTAINERS |9 + drivers/Makefile |1 + drivers/accel/Kconfig |2 + drivers/accel/Makefile|3 + drivers/accel/ivpu/Kconfig| 15 + drivers/accel/ivpu/Makefile | 16 + drivers/accel/ivpu/TODO | 11 + drivers/accel/ivpu/ivpu_drv.c | 654 +++ drivers/accel/ivpu/ivpu_drv.h | 190 + drivers/accel/ivpu/ivpu_fw.c | 423 ++ drivers/accel/ivpu/ivpu_fw.h | 38 + drivers/accel/ivpu/ivpu_gem.c | 753 + drivers/accel/ivpu/ivpu_gem.h | 127 +++ drivers/accel/ivpu/ivpu_hw.h | 170 drivers/accel/ivpu/ivpu_hw_mtl.c | 1084 + drivers/accel/ivpu/ivpu_hw_mtl_reg.h | 280 +++ drivers/accel/ivpu/ivpu_hw_reg_io.h | 115 +++ drivers/accel/ivpu/ivpu_ipc.c | 510 drivers/accel/ivpu/ivpu_ipc.h | 93 +++ drivers/accel/ivpu/ivpu_job.c | 614 ++ drivers/accel/ivpu/ivpu_job.h | 67 ++ drivers/accel/ivpu/ivpu_jsm_msg.c | 169 drivers/accel/ivpu/ivpu_jsm_msg.h | 23 + drivers/accel/ivpu/ivpu_mmu.c | 883 drivers/accel/ivpu/ivpu_mmu.h | 50 ++ drivers/accel/ivpu/ivpu_mmu_context.c | 398 + drivers/accel/ivpu/ivpu_mmu_context.h | 50 ++ drivers/accel/ivpu/ivpu_pm.c | 329 drivers/accel/ivpu/ivpu_pm.h | 38 + drivers/accel/ivpu/vpu_boot_api.h | 349 drivers/accel/ivpu/vpu_jsm_api.h | 999 +++ include/uapi/drm/ivpu_accel.h | 306 +++ 32 files changed, 8769 insertions(+) create mode 100644 drivers/accel/Makefile create mode 100644 drivers/accel/ivpu/Kconfig create mode 100644 drivers/accel/ivpu/Makefile create mode 100644 drivers/accel/ivpu/TODO create mode 100644 drivers/accel/ivpu/ivpu_
[PATCH v6 1/7] accel/ivpu: Introduce a new DRM driver for Intel VPU
fo_init(vdev);
+ if (ret) {
+ ivpu_err(vdev, "Failed to initialize HW info: %d\n", ret);
+ goto err_xa_destroy;
+ }
+
+ /* Power up early so the rest of init code can access VPU registers */
+ ret = ivpu_hw_power_up(vdev);
+ if (ret) {
+ ivpu_err(vdev, "Failed to power up HW: %d\n", ret);
+ goto err_xa_destroy;
+ }
+
+ return 0;
+
+err_xa_destroy:
+ xa_destroy(&vdev->context_xa);
+ return ret;
+}
+
+static void ivpu_dev_fini(struct ivpu_device *vdev)
+{
+ ivpu_shutdown(vdev);
+
+ drm_WARN_ON(&vdev->drm, !xa_empty(&vdev->context_xa));
+ xa_destroy(&vdev->context_xa);
+}
+
+static struct pci_device_id ivpu_pci_ids[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_MTL) },
+ { }
+};
+MODULE_DEVICE_TABLE(pci, ivpu_pci_ids);
+
+static int ivpu_probe(struct pci_dev *pdev, const struct pci_device_id *id)
+{
+ struct ivpu_device *vdev;
+ int ret;
+
+ vdev = devm_drm_dev_alloc(&pdev->dev, &driver, struct ivpu_device, drm);
+ if (IS_ERR(vdev))
+ return PTR_ERR(vdev);
+
+ pci_set_drvdata(pdev, vdev);
+
+ ret = ivpu_dev_init(vdev);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to initialize VPU device: %d\n",
ret);
+ return ret;
+ }
+
+ ret = drm_dev_register(&vdev->drm, 0);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to register DRM device: %d\n", ret);
+ ivpu_dev_fini(vdev);
+ }
+
+ return ret;
+}
+
+static void ivpu_remove(struct pci_dev *pdev)
+{
+ struct ivpu_device *vdev = pci_get_drvdata(pdev);
+
+ drm_dev_unregister(&vdev->drm);
+ ivpu_dev_fini(vdev);
+}
+
+static struct pci_driver ivpu_pci_driver = {
+ .name = KBUILD_MODNAME,
+ .id_table = ivpu_pci_ids,
+ .probe = ivpu_probe,
+ .remove = ivpu_remove,
+};
+
+module_pci_driver(ivpu_pci_driver);
+
+MODULE_AUTHOR("Intel Corporation");
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_LICENSE("GPL and additional rights");
+MODULE_VERSION(DRIVER_VERSION_STR);
diff --git a/drivers/accel/ivpu/ivpu_drv.h b/drivers/accel/ivpu/ivpu_drv.h
new file mode 100644
index 0..d0b006893b1ce
--- /dev/null
+++ b/drivers/accel/ivpu/ivpu_drv.h
@@ -0,0 +1,162 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2020-2023 Intel Corporation
+ */
+
+#ifndef __IVPU_DRV_H__
+#define __IVPU_DRV_H__
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define DRIVER_NAME "intel_vpu"
+#define DRIVER_DESC "Driver for Intel Versatile Processing Unit (VPU)"
+#define DRIVER_DATE "20230117"
+
+#define PCI_DEVICE_ID_MTL 0x7d1d
+
+#define IVPU_GLOBAL_CONTEXT_MMU_SSID 0
+#define IVPU_CONTEXT_LIMIT 64
+#define IVPU_NUM_ENGINES2
+
+#define IVPU_PLATFORM_SILICON 0
+#define IVPU_PLATFORM_SIMICS 2
+#define IVPU_PLATFORM_FPGA3
+#define IVPU_PLATFORM_INVALID 8
+
+#define IVPU_DBG_REGBIT(0)
+#define IVPU_DBG_IRQBIT(1)
+#define IVPU_DBG_MMUBIT(2)
+#define IVPU_DBG_FILE BIT(3)
+#define IVPU_DBG_MISC BIT(4)
+#define IVPU_DBG_FW_BOOT BIT(5)
+#define IVPU_DBG_PM BIT(6)
+#define IVPU_DBG_IPCBIT(7)
+#define IVPU_DBG_BO BIT(8)
+#define IVPU_DBG_JOBBIT(9)
+#define IVPU_DBG_JSMBIT(10)
+#define IVPU_DBG_KREF BIT(11)
+#define IVPU_DBG_RPMBIT(12)
+
+#define ivpu_err(vdev, fmt, ...) \
+ drm_err(&(vdev)->drm, "%s(): " fmt, __func__, ##__VA_ARGS__)
+
+#define ivpu_err_ratelimited(vdev, fmt, ...) \
+ drm_err_ratelimited(&(vdev)->drm, "%s(): " fmt, __func__, ##__VA_ARGS__)
+
+#define ivpu_warn(vdev, fmt, ...) \
+ drm_warn(&(vdev)->drm, "%s(): " fmt, __func__, ##__VA_ARGS__)
+
+#define ivpu_warn_ratelimited(vdev, fmt, ...) \
+ drm_err_ratelimited(&(vdev)->drm, "%s(): " fmt, __func__, ##__VA_ARGS__)
+
+#define ivpu_info(vdev, fmt, ...) drm_info(&(vdev)->drm, fmt, ##__VA_ARGS__)
+
+#define ivpu_dbg(vdev, type, fmt, args...) do {
\
+ if (unlikely(IVPU_DBG_##type & ivpu_dbg_mask)) \
+ dev_dbg((vdev)->drm.dev, "[%s] " fmt, #type, ##args); \
+} while (0)
+
+#define IVPU_WA(wa_name) (vdev->wa.wa_name)
+
+struct ivpu_wa_table {
+ bool punit_disabled;
+ bool clear_runtime_mem;
+};
+
+struct ivpu_hw_info;
+
+struct ivpu_device {
+ struct drm_device drm;
+ void __iomem *regb;
+ void __iomem *regv;
+ u32 platform;
+ u32 irq;
+
+ struct ivpu_wa_table wa;
+ struct ivpu_hw_info *hw;
+
+ struct xarray context_xa;
+ struct xa_limit context_xa_limit;
+
+ struct {
+
[PATCH v6 3/7] accel/ivpu: Add GEM buffer object management
Adds four types of GEM-based BOs for the VPU:
- shmem
- internal
- prime
All types are implemented as struct ivpu_bo, based on
struct drm_gem_object. VPU address is allocated when buffer is created
except for imported prime buffers that allocate it in BO_INFO IOCTL due
to missing file_priv arg in gem_prime_import callback.
Internal buffers are pinned on creation, the rest of buffers types
can be pinned on demand (in SUBMIT IOCTL).
Buffer VPU address, allocated pages and mappings are released when the
buffer is destroyed.
Eviction mechanism is planned for future versions.
Add two new IOCTLs: BO_CREATE, BO_INFO
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Oded Gabbay
Reviewed-by: Jeffrey Hugo
---
drivers/accel/ivpu/Makefile | 1 +
drivers/accel/ivpu/ivpu_drv.c | 30 +-
drivers/accel/ivpu/ivpu_drv.h | 1 +
drivers/accel/ivpu/ivpu_gem.c | 727 ++
drivers/accel/ivpu/ivpu_gem.h | 126 ++
include/uapi/drm/ivpu_accel.h | 94 +
6 files changed, 977 insertions(+), 2 deletions(-)
create mode 100644 drivers/accel/ivpu/ivpu_gem.c
create mode 100644 drivers/accel/ivpu/ivpu_gem.h
diff --git a/drivers/accel/ivpu/Makefile b/drivers/accel/ivpu/Makefile
index 59cd7843b2189..5d7c5862399ca 100644
--- a/drivers/accel/ivpu/Makefile
+++ b/drivers/accel/ivpu/Makefile
@@ -3,6 +3,7 @@
intel_vpu-y := \
ivpu_drv.o \
+ ivpu_gem.o \
ivpu_hw_mtl.o \
ivpu_mmu.o \
ivpu_mmu_context.o
diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
index 69ca7dae8b57c..53d92d06814bf 100644
--- a/drivers/accel/ivpu/ivpu_drv.c
+++ b/drivers/accel/ivpu/ivpu_drv.c
@@ -12,8 +12,10 @@
#include
#include
#include
+#include
#include "ivpu_drv.h"
+#include "ivpu_gem.h"
#include "ivpu_hw.h"
#include "ivpu_mmu.h"
#include "ivpu_mmu_context.h"
@@ -49,6 +51,24 @@ struct ivpu_file_priv *ivpu_file_priv_get(struct
ivpu_file_priv *file_priv)
return file_priv;
}
+struct ivpu_file_priv *ivpu_file_priv_get_by_ctx_id(struct ivpu_device *vdev,
unsigned long id)
+{
+ struct ivpu_file_priv *file_priv;
+
+ xa_lock_irq(&vdev->context_xa);
+ file_priv = xa_load(&vdev->context_xa, id);
+ /* file_priv may still be in context_xa during file_priv_release() */
+ if (file_priv && !kref_get_unless_zero(&file_priv->ref))
+ file_priv = NULL;
+ xa_unlock_irq(&vdev->context_xa);
+
+ if (file_priv)
+ ivpu_dbg(vdev, KREF, "file_priv get by id: ctx %u refcount
%u\n",
+file_priv->ctx.id, kref_read(&file_priv->ref));
+
+ return file_priv;
+}
+
static void file_priv_release(struct kref *ref)
{
struct ivpu_file_priv *file_priv = container_of(ref, struct
ivpu_file_priv, ref);
@@ -57,7 +77,7 @@ static void file_priv_release(struct kref *ref)
ivpu_dbg(vdev, FILE, "file_priv release: ctx %u\n", file_priv->ctx.id);
ivpu_mmu_user_context_fini(vdev, &file_priv->ctx);
- WARN_ON(xa_erase_irq(&vdev->context_xa, file_priv->ctx.id) !=
file_priv);
+ drm_WARN_ON(&vdev->drm, xa_erase_irq(&vdev->context_xa,
file_priv->ctx.id) != file_priv);
kfree(file_priv);
}
@@ -66,7 +86,7 @@ void ivpu_file_priv_put(struct ivpu_file_priv **link)
struct ivpu_file_priv *file_priv = *link;
struct ivpu_device *vdev = file_priv->vdev;
- WARN_ON(!file_priv);
+ drm_WARN_ON(&vdev->drm, !file_priv);
ivpu_dbg(vdev, KREF, "file_priv put: ctx %u refcount %u\n",
file_priv->ctx.id, kref_read(&file_priv->ref));
@@ -200,6 +220,8 @@ static void ivpu_postclose(struct drm_device *dev, struct
drm_file *file)
static const struct drm_ioctl_desc ivpu_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(IVPU_GET_PARAM, ivpu_get_param_ioctl, 0),
DRM_IOCTL_DEF_DRV(IVPU_SET_PARAM, ivpu_set_param_ioctl, 0),
+ DRM_IOCTL_DEF_DRV(IVPU_BO_CREATE, ivpu_bo_create_ioctl, 0),
+ DRM_IOCTL_DEF_DRV(IVPU_BO_INFO, ivpu_bo_info_ioctl, 0),
};
int ivpu_shutdown(struct ivpu_device *vdev)
@@ -227,6 +249,10 @@ static const struct drm_driver driver = {
.open = ivpu_open,
.postclose = ivpu_postclose,
+ .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+ .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+ .gem_prime_import = ivpu_gem_prime_import,
+ .gem_prime_mmap = drm_gem_prime_mmap,
.ioctls = ivpu_drm_ioctls,
.num_ioctls = ARRAY_SIZE(ivpu_drm_ioctls),
diff --git a/drivers/accel/ivpu/ivpu_drv.h b/drivers/accel/ivpu/ivpu_drv.h
index b9ce66f406968..972f71cfaa129 100644
--- a/drivers/accel/ivpu/ivpu_drv.h
+++ b/drivers/accel/ivpu/ivpu_drv.h
@@ -115,6 +115,7 @@ extern u8 ivpu_pll_min_ratio;
extern u8 ivpu_pll_max_ratio;
struct ivpu_file_priv *ivpu_file_priv_get(struct ivpu_file_priv *file_priv);
+struct ivpu_file_priv *ivpu_file_priv_get_by_ctx_id(struct ivpu_device *vdev,
unsigned long id);
void ivpu_file_priv_put(struct ivpu_file_priv **
[PATCH v6 4/7] accel/ivpu: Add IPC driver and JSM messages
The IPC driver is used to send and receive messages to/from firmware
running on the VPU.
The only supported IPC message format is Job Submission Model (JSM)
defined in vpu_jsm_api.h header.
Co-developed-by: Andrzej Kacprowski
Signed-off-by: Andrzej Kacprowski
Co-developed-by: Krystian Pradzynski
Signed-off-by: Krystian Pradzynski
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Oded Gabbay
Reviewed-by: Jeffrey Hugo
---
drivers/accel/ivpu/Makefile | 2 +
drivers/accel/ivpu/ivpu_drv.c | 13 +
drivers/accel/ivpu/ivpu_drv.h | 2 +
drivers/accel/ivpu/ivpu_hw_mtl.c | 4 +
drivers/accel/ivpu/ivpu_ipc.c | 500 +++
drivers/accel/ivpu/ivpu_ipc.h | 93 +++
drivers/accel/ivpu/ivpu_jsm_msg.c | 169 +
drivers/accel/ivpu/ivpu_jsm_msg.h | 23 +
drivers/accel/ivpu/vpu_jsm_api.h | 999 ++
9 files changed, 1805 insertions(+)
create mode 100644 drivers/accel/ivpu/ivpu_ipc.c
create mode 100644 drivers/accel/ivpu/ivpu_ipc.h
create mode 100644 drivers/accel/ivpu/ivpu_jsm_msg.c
create mode 100644 drivers/accel/ivpu/ivpu_jsm_msg.h
create mode 100644 drivers/accel/ivpu/vpu_jsm_api.h
diff --git a/drivers/accel/ivpu/Makefile b/drivers/accel/ivpu/Makefile
index 5d7c5862399ca..46595f0112e38 100644
--- a/drivers/accel/ivpu/Makefile
+++ b/drivers/accel/ivpu/Makefile
@@ -5,6 +5,8 @@ intel_vpu-y := \
ivpu_drv.o \
ivpu_gem.o \
ivpu_hw_mtl.o \
+ ivpu_ipc.o \
+ ivpu_jsm_msg.o \
ivpu_mmu.o \
ivpu_mmu_context.o
diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
index 53d92d06814bf..1eb12e157acda 100644
--- a/drivers/accel/ivpu/ivpu_drv.c
+++ b/drivers/accel/ivpu/ivpu_drv.c
@@ -17,6 +17,7 @@
#include "ivpu_drv.h"
#include "ivpu_gem.h"
#include "ivpu_hw.h"
+#include "ivpu_ipc.h"
#include "ivpu_mmu.h"
#include "ivpu_mmu_context.h"
@@ -229,6 +230,7 @@ int ivpu_shutdown(struct ivpu_device *vdev)
int ret;
ivpu_hw_irq_disable(vdev);
+ ivpu_ipc_disable(vdev);
ivpu_mmu_disable(vdev);
ret = ivpu_hw_power_down(vdev);
@@ -339,6 +341,10 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
if (!vdev->mmu)
return -ENOMEM;
+ vdev->ipc = drmm_kzalloc(&vdev->drm, sizeof(*vdev->ipc), GFP_KERNEL);
+ if (!vdev->ipc)
+ return -ENOMEM;
+
vdev->hw->ops = &ivpu_hw_mtl_ops;
vdev->platform = IVPU_PLATFORM_INVALID;
vdev->context_xa_limit.min = IVPU_GLOBAL_CONTEXT_MMU_SSID + 1;
@@ -383,6 +389,12 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
goto err_mmu_gctx_fini;
}
+ ret = ivpu_ipc_init(vdev);
+ if (ret) {
+ ivpu_err(vdev, "Failed to initialize IPC: %d\n", ret);
+ goto err_mmu_gctx_fini;
+ }
+
return 0;
err_mmu_gctx_fini:
@@ -397,6 +409,7 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
static void ivpu_dev_fini(struct ivpu_device *vdev)
{
ivpu_shutdown(vdev);
+ ivpu_ipc_fini(vdev);
ivpu_mmu_global_context_fini(vdev);
drm_WARN_ON(&vdev->drm, !xa_empty(&vdev->context_xa));
diff --git a/drivers/accel/ivpu/ivpu_drv.h b/drivers/accel/ivpu/ivpu_drv.h
index 972f71cfaa129..39b706d82e682 100644
--- a/drivers/accel/ivpu/ivpu_drv.h
+++ b/drivers/accel/ivpu/ivpu_drv.h
@@ -74,6 +74,7 @@ struct ivpu_wa_table {
struct ivpu_hw_info;
struct ivpu_mmu_info;
+struct ivpu_ipc_info;
struct ivpu_device {
struct drm_device drm;
@@ -85,6 +86,7 @@ struct ivpu_device {
struct ivpu_wa_table wa;
struct ivpu_hw_info *hw;
struct ivpu_mmu_info *mmu;
+ struct ivpu_ipc_info *ipc;
struct ivpu_mmu_context gctx;
struct xarray context_xa;
diff --git a/drivers/accel/ivpu/ivpu_hw_mtl.c b/drivers/accel/ivpu/ivpu_hw_mtl.c
index eaba2b8248b88..0e9ef4c409012 100644
--- a/drivers/accel/ivpu/ivpu_hw_mtl.c
+++ b/drivers/accel/ivpu/ivpu_hw_mtl.c
@@ -7,6 +7,7 @@
#include "ivpu_hw_mtl_reg.h"
#include "ivpu_hw_reg_io.h"
#include "ivpu_hw.h"
+#include "ivpu_ipc.h"
#include "ivpu_mmu.h"
#define TILE_FUSE_ENABLE_BOTH 0x0
@@ -934,6 +935,9 @@ static u32 ivpu_hw_mtl_irqv_handler(struct ivpu_device
*vdev, int irq)
if (REG_TEST_FLD(MTL_VPU_HOST_SS_ICB_STATUS_0, MMU_IRQ_0_INT, status))
ivpu_mmu_irq_evtq_handler(vdev);
+ if (REG_TEST_FLD(MTL_VPU_HOST_SS_ICB_STATUS_0, HOST_IPC_FIFO_INT,
status))
+ ivpu_ipc_irq_handler(vdev);
+
if (REG_TEST_FLD(MTL_VPU_HOST_SS_ICB_STATUS_0, MMU_IRQ_1_INT, status))
ivpu_dbg(vdev, IRQ, "MMU sync complete\n");
diff --git a/drivers/accel/ivpu/ivpu_ipc.c b/drivers/accel/ivpu/ivpu_ipc.c
new file mode 100644
index 0..c756476bfc5b1
--- /dev/null
+++ b/drivers/accel/ivpu/ivpu_ipc.c
@@ -0,0 +1,500 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020-2023 Intel Corporation
+ */
+
+#include
+#include
+#include
+#in
[PATCH v6 2/7] accel/ivpu: Add Intel VPU MMU support
ivpu_err(vdev, "Failed to allocate context id: %d\n", ret);
+ return ret;
+ }
file_priv = kzalloc(sizeof(*file_priv), GFP_KERNEL);
- if (!file_priv)
- return -ENOMEM;
+ if (!file_priv) {
+ ret = -ENOMEM;
+ goto err_xa_erase;
+ }
file_priv->vdev = vdev;
file_priv->priority = DRM_IVPU_CONTEXT_PRIORITY_NORMAL;
kref_init(&file_priv->ref);
+ ret = ivpu_mmu_user_context_init(vdev, &file_priv->ctx, ctx_id);
+ if (ret)
+ goto err_free_file_priv;
+
+ old = xa_store_irq(&vdev->context_xa, ctx_id, file_priv, GFP_KERNEL);
+ if (xa_is_err(old)) {
+ ret = xa_err(old);
+ ivpu_err(vdev, "Failed to store context %u: %d\n", ctx_id, ret);
+ goto err_ctx_fini;
+ }
+
+ ivpu_dbg(vdev, FILE, "file_priv create: ctx %u process %s pid %d\n",
+ctx_id, current->comm, task_pid_nr(current));
+
file->driver_priv = file_priv;
return 0;
+
+err_ctx_fini:
+ ivpu_mmu_user_context_fini(vdev, &file_priv->ctx);
+err_free_file_priv:
+ kfree(file_priv);
+err_xa_erase:
+ xa_erase_irq(&vdev->context_xa, ctx_id);
+ return ret;
}
static void ivpu_postclose(struct drm_device *dev, struct drm_file *file)
{
struct ivpu_file_priv *file_priv = file->driver_priv;
+ struct ivpu_device *vdev = to_ivpu_device(dev);
+
+ ivpu_dbg(vdev, FILE, "file_priv close: ctx %u process %s pid %d\n",
+file_priv->ctx.id, current->comm, task_pid_nr(current));
ivpu_file_priv_put(&file_priv);
}
@@ -150,6 +207,7 @@ int ivpu_shutdown(struct ivpu_device *vdev)
int ret;
ivpu_hw_irq_disable(vdev);
+ ivpu_mmu_disable(vdev);
ret = ivpu_hw_power_down(vdev);
if (ret)
@@ -251,6 +309,10 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
if (!vdev->hw)
return -ENOMEM;
+ vdev->mmu = drmm_kzalloc(&vdev->drm, sizeof(*vdev->mmu), GFP_KERNEL);
+ if (!vdev->mmu)
+ return -ENOMEM;
+
vdev->hw->ops = &ivpu_hw_mtl_ops;
vdev->platform = IVPU_PLATFORM_INVALID;
vdev->context_xa_limit.min = IVPU_GLOBAL_CONTEXT_MMU_SSID + 1;
@@ -283,8 +345,24 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
goto err_xa_destroy;
}
+ ret = ivpu_mmu_global_context_init(vdev);
+ if (ret) {
+ ivpu_err(vdev, "Failed to initialize global MMU context: %d\n",
ret);
+ goto err_power_down;
+ }
+
+ ret = ivpu_mmu_init(vdev);
+ if (ret) {
+ ivpu_err(vdev, "Failed to initialize MMU device: %d\n", ret);
+ goto err_mmu_gctx_fini;
+ }
+
return 0;
+err_mmu_gctx_fini:
+ ivpu_mmu_global_context_fini(vdev);
+err_power_down:
+ ivpu_hw_power_down(vdev);
err_xa_destroy:
xa_destroy(&vdev->context_xa);
return ret;
@@ -293,6 +371,7 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
static void ivpu_dev_fini(struct ivpu_device *vdev)
{
ivpu_shutdown(vdev);
+ ivpu_mmu_global_context_fini(vdev);
drm_WARN_ON(&vdev->drm, !xa_empty(&vdev->context_xa));
xa_destroy(&vdev->context_xa);
diff --git a/drivers/accel/ivpu/ivpu_drv.h b/drivers/accel/ivpu/ivpu_drv.h
index d0b006893b1ce..b9ce66f406968 100644
--- a/drivers/accel/ivpu/ivpu_drv.h
+++ b/drivers/accel/ivpu/ivpu_drv.h
@@ -15,6 +15,8 @@
#include
#include
+#include "ivpu_mmu_context.h"
+
#define DRIVER_NAME "intel_vpu"
#define DRIVER_DESC "Driver for Intel Versatile Processing Unit (VPU)"
#define DRIVER_DATE "20230117"
@@ -71,6 +73,7 @@ struct ivpu_wa_table {
};
struct ivpu_hw_info;
+struct ivpu_mmu_info;
struct ivpu_device {
struct drm_device drm;
@@ -81,7 +84,9 @@ struct ivpu_device {
struct ivpu_wa_table wa;
struct ivpu_hw_info *hw;
+ struct ivpu_mmu_info *mmu;
+ struct ivpu_mmu_context gctx;
struct xarray context_xa;
struct xa_limit context_xa_limit;
@@ -100,7 +105,9 @@ struct ivpu_device {
struct ivpu_file_priv {
struct kref ref;
struct ivpu_device *vdev;
+ struct ivpu_mmu_context ctx;
u32 priority;
+ bool has_mmu_faults;
};
extern int ivpu_dbg_mask;
diff --git a/drivers/accel/ivpu/ivpu_hw_mtl.c b/drivers/accel/ivpu/ivpu_hw_mtl.c
index 8a1b1c03f77b7..eaba2b8248b88 100644
--- a/drivers/accel/ivpu/ivpu_hw_mtl.c
+++ b/drivers/accel/ivpu/ivpu_hw_mtl.c
@@ -7,6 +7,7 @@
#include "ivpu_hw_mtl_reg.h"
#include "ivpu_hw_reg_io.h"
#include "ivpu_hw.h"
+#include "ivpu_mmu.h"
#define TILE_FUSE_ENABLE_BOTH
[PATCH v6 5/7] accel/ivpu: Implement firmware parsing and booting
Read, parse and boot VPU firmware image.
Co-developed-by: Andrzej Kacprowski
Signed-off-by: Andrzej Kacprowski
Co-developed-by: Krystian Pradzynski
Signed-off-by: Krystian Pradzynski
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Oded Gabbay
Reviewed-by: Jeffrey Hugo
---
drivers/accel/ivpu/Makefile | 1 +
drivers/accel/ivpu/ivpu_drv.c | 131 +-
drivers/accel/ivpu/ivpu_drv.h | 11 +
drivers/accel/ivpu/ivpu_fw.c | 419 ++
drivers/accel/ivpu/ivpu_fw.h | 38 +++
drivers/accel/ivpu/ivpu_hw_mtl.c | 10 +
drivers/accel/ivpu/vpu_boot_api.h | 349 +
include/uapi/drm/ivpu_accel.h | 21 ++
8 files changed, 979 insertions(+), 1 deletion(-)
create mode 100644 drivers/accel/ivpu/ivpu_fw.c
create mode 100644 drivers/accel/ivpu/ivpu_fw.h
create mode 100644 drivers/accel/ivpu/vpu_boot_api.h
diff --git a/drivers/accel/ivpu/Makefile b/drivers/accel/ivpu/Makefile
index 46595f0112e38..9fa6a76e9d793 100644
--- a/drivers/accel/ivpu/Makefile
+++ b/drivers/accel/ivpu/Makefile
@@ -3,6 +3,7 @@
intel_vpu-y := \
ivpu_drv.o \
+ ivpu_fw.o \
ivpu_gem.o \
ivpu_hw_mtl.o \
ivpu_ipc.o \
diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
index 1eb12e157acda..0b43e880c99c2 100644
--- a/drivers/accel/ivpu/ivpu_drv.c
+++ b/drivers/accel/ivpu/ivpu_drv.c
@@ -14,10 +14,13 @@
#include
#include
+#include "vpu_boot_api.h"
#include "ivpu_drv.h"
+#include "ivpu_fw.h"
#include "ivpu_gem.h"
#include "ivpu_hw.h"
#include "ivpu_ipc.h"
+#include "ivpu_jsm_msg.h"
#include "ivpu_mmu.h"
#include "ivpu_mmu_context.h"
@@ -32,6 +35,10 @@ int ivpu_dbg_mask;
module_param_named(dbg_mask, ivpu_dbg_mask, int, 0644);
MODULE_PARM_DESC(dbg_mask, "Driver debug mask. See IVPU_DBG_* macros.");
+int ivpu_test_mode;
+module_param_named_unsafe(test_mode, ivpu_test_mode, int, 0644);
+MODULE_PARM_DESC(test_mode, "Test mode: 0 - normal operation, 1 - fw unit
test, 2 - null hw");
+
u8 ivpu_pll_min_ratio;
module_param_named(pll_min_ratio, ivpu_pll_min_ratio, byte, 0644);
MODULE_PARM_DESC(pll_min_ratio, "Minimum PLL ratio used to set VPU frequency");
@@ -129,6 +136,28 @@ static int ivpu_get_param_ioctl(struct drm_device *dev,
void *data, struct drm_f
case DRM_IVPU_PARAM_CONTEXT_ID:
args->value = file_priv->ctx.id;
break;
+ case DRM_IVPU_PARAM_FW_API_VERSION:
+ if (args->index < VPU_FW_API_VER_NUM) {
+ struct vpu_firmware_header *fw_hdr;
+
+ fw_hdr = (struct vpu_firmware_header
*)vdev->fw->file->data;
+ args->value = fw_hdr->api_version[args->index];
+ } else {
+ ret = -EINVAL;
+ }
+ break;
+ case DRM_IVPU_PARAM_ENGINE_HEARTBEAT:
+ ret = ivpu_jsm_get_heartbeat(vdev, args->index, &args->value);
+ break;
+ case DRM_IVPU_PARAM_UNIQUE_INFERENCE_ID:
+ args->value =
(u64)atomic64_inc_return(&vdev->unique_id_counter);
+ break;
+ case DRM_IVPU_PARAM_TILE_CONFIG:
+ args->value = vdev->hw->tile_fuse;
+ break;
+ case DRM_IVPU_PARAM_SKU:
+ args->value = vdev->hw->sku;
+ break;
default:
ret = -EINVAL;
break;
@@ -225,11 +254,85 @@ static const struct drm_ioctl_desc ivpu_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(IVPU_BO_INFO, ivpu_bo_info_ioctl, 0),
};
+static int ivpu_wait_for_ready(struct ivpu_device *vdev)
+{
+ struct ivpu_ipc_consumer cons;
+ struct ivpu_ipc_hdr ipc_hdr;
+ unsigned long timeout;
+ int ret;
+
+ if (ivpu_test_mode == IVPU_TEST_MODE_FW_TEST)
+ return 0;
+
+ ivpu_ipc_consumer_add(vdev, &cons, IVPU_IPC_CHAN_BOOT_MSG);
+
+ timeout = jiffies + msecs_to_jiffies(vdev->timeout.boot);
+ while (1) {
+ ret = ivpu_ipc_irq_handler(vdev);
+ if (ret)
+ break;
+ ret = ivpu_ipc_receive(vdev, &cons, &ipc_hdr, NULL, 0);
+ if (ret != -ETIMEDOUT || time_after_eq(jiffies, timeout))
+ break;
+
+ cond_resched();
+ }
+
+ ivpu_ipc_consumer_del(vdev, &cons);
+
+ if (!ret && ipc_hdr.data_addr != IVPU_IPC_BOOT_MSG_DATA_ADDR) {
+ ivpu_err(vdev, "Invalid VPU ready message: 0x%x\n",
+ipc_hdr.data_addr);
+ return -EIO;
+ }
+
+ if (!ret)
+ ivpu_info(vdev, "VPU ready message received successfully\n");
+ else
+ ivpu_hw_diagnose_failure(vdev);
+
+ return ret;
+}
+
+/**
+ * ivpu_boot() - Start VPU firmware
+ * @vdev: VPU device
+ *
+ * This function is paired with ivpu_shutdown() but it doesn't power up the
+ * VPU because power up has to be called very early in ivpu_pr
[PATCH v6 7/7] accel/ivpu: Add PM support
- Implement cold and warm firmware boot flows
- Add hang recovery support
- Add runtime power management support
Co-developed-by: Krystian Pradzynski
Signed-off-by: Krystian Pradzynski
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Jeffrey Hugo
---
drivers/accel/ivpu/Makefile | 3 +-
drivers/accel/ivpu/ivpu_drv.c| 28 +++
drivers/accel/ivpu/ivpu_drv.h| 2 +
drivers/accel/ivpu/ivpu_fw.c | 4 +
drivers/accel/ivpu/ivpu_hw_mtl.c | 12 ++
drivers/accel/ivpu/ivpu_ipc.c| 20 +-
drivers/accel/ivpu/ivpu_job.c| 14 +-
drivers/accel/ivpu/ivpu_mmu.c| 9 +-
drivers/accel/ivpu/ivpu_pm.c | 329 +++
drivers/accel/ivpu/ivpu_pm.h | 38
10 files changed, 451 insertions(+), 8 deletions(-)
create mode 100644 drivers/accel/ivpu/ivpu_pm.c
create mode 100644 drivers/accel/ivpu/ivpu_pm.h
diff --git a/drivers/accel/ivpu/Makefile b/drivers/accel/ivpu/Makefile
index e61ece53a9ae6..80f1fb3548ae8 100644
--- a/drivers/accel/ivpu/Makefile
+++ b/drivers/accel/ivpu/Makefile
@@ -10,6 +10,7 @@ intel_vpu-y := \
ivpu_job.o \
ivpu_jsm_msg.o \
ivpu_mmu.o \
- ivpu_mmu_context.o
+ ivpu_mmu_context.o \
+ ivpu_pm.o
obj-$(CONFIG_DRM_ACCEL_IVPU) += intel_vpu.o
\ No newline at end of file
diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
index c893c8ac6bedc..2bc2f1b90671a 100644
--- a/drivers/accel/ivpu/ivpu_drv.c
+++ b/drivers/accel/ivpu/ivpu_drv.c
@@ -24,6 +24,7 @@
#include "ivpu_jsm_msg.h"
#include "ivpu_mmu.h"
#include "ivpu_mmu_context.h"
+#include "ivpu_pm.h"
#ifndef DRIVER_VERSION_STR
#define DRIVER_VERSION_STR __stringify(DRM_IVPU_DRIVER_MAJOR) "." \
@@ -462,6 +463,10 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
if (!vdev->ipc)
return -ENOMEM;
+ vdev->pm = drmm_kzalloc(&vdev->drm, sizeof(*vdev->pm), GFP_KERNEL);
+ if (!vdev->pm)
+ return -ENOMEM;
+
vdev->hw->ops = &ivpu_hw_mtl_ops;
vdev->platform = IVPU_PLATFORM_INVALID;
vdev->context_xa_limit.min = IVPU_GLOBAL_CONTEXT_MMU_SSID + 1;
@@ -521,6 +526,12 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
goto err_fw_fini;
}
+ ret = ivpu_pm_init(vdev);
+ if (ret) {
+ ivpu_err(vdev, "Failed to initialize PM: %d\n", ret);
+ goto err_ipc_fini;
+ }
+
ret = ivpu_job_done_thread_init(vdev);
if (ret) {
ivpu_err(vdev, "Failed to initialize job done thread: %d\n",
ret);
@@ -539,6 +550,8 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
goto err_job_done_thread_fini;
}
+ ivpu_pm_enable(vdev);
+
return 0;
err_job_done_thread_fini:
@@ -559,6 +572,7 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
static void ivpu_dev_fini(struct ivpu_device *vdev)
{
+ ivpu_pm_disable(vdev);
ivpu_shutdown(vdev);
ivpu_job_done_thread_fini(vdev);
ivpu_ipc_fini(vdev);
@@ -611,11 +625,25 @@ static void ivpu_remove(struct pci_dev *pdev)
ivpu_dev_fini(vdev);
}
+static const struct dev_pm_ops ivpu_drv_pci_pm = {
+ SET_SYSTEM_SLEEP_PM_OPS(ivpu_pm_suspend_cb, ivpu_pm_resume_cb)
+ SET_RUNTIME_PM_OPS(ivpu_pm_runtime_suspend_cb,
ivpu_pm_runtime_resume_cb, NULL)
+};
+
+static const struct pci_error_handlers ivpu_drv_pci_err = {
+ .reset_prepare = ivpu_pm_reset_prepare_cb,
+ .reset_done = ivpu_pm_reset_done_cb,
+};
+
static struct pci_driver ivpu_pci_driver = {
.name = KBUILD_MODNAME,
.id_table = ivpu_pci_ids,
.probe = ivpu_probe,
.remove = ivpu_remove,
+ .driver = {
+ .pm = &ivpu_drv_pci_pm,
+ },
+ .err_handler = &ivpu_drv_pci_err,
};
module_pci_driver(ivpu_pci_driver);
diff --git a/drivers/accel/ivpu/ivpu_drv.h b/drivers/accel/ivpu/ivpu_drv.h
index 5e63c70c47b38..f47b4965db2e3 100644
--- a/drivers/accel/ivpu/ivpu_drv.h
+++ b/drivers/accel/ivpu/ivpu_drv.h
@@ -76,6 +76,7 @@ struct ivpu_hw_info;
struct ivpu_mmu_info;
struct ivpu_fw_info;
struct ivpu_ipc_info;
+struct ivpu_pm_info;
struct ivpu_device {
struct drm_device drm;
@@ -89,6 +90,7 @@ struct ivpu_device {
struct ivpu_mmu_info *mmu;
struct ivpu_fw_info *fw;
struct ivpu_ipc_info *ipc;
+ struct ivpu_pm_info *pm;
struct ivpu_mmu_context gctx;
struct xarray context_xa;
diff --git a/drivers/accel/ivpu/ivpu_fw.c b/drivers/accel/ivpu/ivpu_fw.c
index 4baa0767a10dc..b463c24adb70d 100644
--- a/drivers/accel/ivpu/ivpu_fw.c
+++ b/drivers/accel/ivpu/ivpu_fw.c
@@ -14,6 +14,7 @@
#include "ivpu_gem.h"
#include "ivpu_hw.h"
#include "ivpu_ipc.h"
+#include "ivpu_pm.h"
#define FW_GLOBAL_MEM_START(2ull * SZ_1G)
#define FW_GLOBAL_MEM_END (3ull * SZ_1G)
@@ -361,9 +362,12 @@ void ivpu_fw_boot_params_setup(struct ivpu_device *vdev,
struct vpu_boot_params
/* In case of warm boot w
[PATCH v6 6/7] accel/ivpu: Add command buffer submission logic
Each of the user contexts has two command queues, one for compute engine
and one for the copy engine. Command queues are allocated and registered
in the device when the first job (command buffer) is submitted from
the user space to the VPU device. The userspace provides a list of
GEM buffer object handles to submit to the VPU, the driver resolves
buffer handles, pins physical memory if needed, increments ref count
for each buffer and stores pointers to buffer objects in
the ivpu_job objects that track jobs submitted to the device.
The VPU signals job completion with an asynchronous message that
contains the job id passed to firmware when the job was submitted.
Currently, the driver supports simple scheduling logic
where jobs submitted from user space are immediately pushed
to the VPU device command queues. In the future, it will be
extended to use hardware base scheduling and/or drm_sched.
Co-developed-by: Andrzej Kacprowski
Signed-off-by: Andrzej Kacprowski
Signed-off-by: Jacek Lawrynowicz
Reviewed-by: Oded Gabbay
Reviewed-by: Jeffrey Hugo
---
drivers/accel/ivpu/Makefile | 1 +
drivers/accel/ivpu/ivpu_drv.c | 34 +-
drivers/accel/ivpu/ivpu_drv.h | 5 +
drivers/accel/ivpu/ivpu_gem.c | 26 ++
drivers/accel/ivpu/ivpu_gem.h | 1 +
drivers/accel/ivpu/ivpu_job.c | 602 ++
drivers/accel/ivpu/ivpu_job.h | 67
include/uapi/drm/ivpu_accel.h | 92 ++
8 files changed, 824 insertions(+), 4 deletions(-)
create mode 100644 drivers/accel/ivpu/ivpu_job.c
create mode 100644 drivers/accel/ivpu/ivpu_job.h
diff --git a/drivers/accel/ivpu/Makefile b/drivers/accel/ivpu/Makefile
index 9fa6a76e9d793..e61ece53a9ae6 100644
--- a/drivers/accel/ivpu/Makefile
+++ b/drivers/accel/ivpu/Makefile
@@ -7,6 +7,7 @@ intel_vpu-y := \
ivpu_gem.o \
ivpu_hw_mtl.o \
ivpu_ipc.o \
+ ivpu_job.o \
ivpu_jsm_msg.o \
ivpu_mmu.o \
ivpu_mmu_context.o
diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
index 0b43e880c99c2..c893c8ac6bedc 100644
--- a/drivers/accel/ivpu/ivpu_drv.c
+++ b/drivers/accel/ivpu/ivpu_drv.c
@@ -20,6 +20,7 @@
#include "ivpu_gem.h"
#include "ivpu_hw.h"
#include "ivpu_ipc.h"
+#include "ivpu_job.h"
#include "ivpu_jsm_msg.h"
#include "ivpu_mmu.h"
#include "ivpu_mmu_context.h"
@@ -31,6 +32,8 @@
static const struct drm_driver driver;
+static struct lock_class_key submitted_jobs_xa_lock_class_key;
+
int ivpu_dbg_mask;
module_param_named(dbg_mask, ivpu_dbg_mask, int, 0644);
MODULE_PARM_DESC(dbg_mask, "Driver debug mask. See IVPU_DBG_* macros.");
@@ -84,8 +87,11 @@ static void file_priv_release(struct kref *ref)
ivpu_dbg(vdev, FILE, "file_priv release: ctx %u\n", file_priv->ctx.id);
+ ivpu_cmdq_release_all(file_priv);
+ ivpu_bo_remove_all_bos_from_context(&file_priv->ctx);
ivpu_mmu_user_context_fini(vdev, &file_priv->ctx);
drm_WARN_ON(&vdev->drm, xa_erase_irq(&vdev->context_xa,
file_priv->ctx.id) != file_priv);
+ mutex_destroy(&file_priv->lock);
kfree(file_priv);
}
@@ -209,10 +215,11 @@ static int ivpu_open(struct drm_device *dev, struct
drm_file *file)
file_priv->vdev = vdev;
file_priv->priority = DRM_IVPU_CONTEXT_PRIORITY_NORMAL;
kref_init(&file_priv->ref);
+ mutex_init(&file_priv->lock);
ret = ivpu_mmu_user_context_init(vdev, &file_priv->ctx, ctx_id);
if (ret)
- goto err_free_file_priv;
+ goto err_mutex_destroy;
old = xa_store_irq(&vdev->context_xa, ctx_id, file_priv, GFP_KERNEL);
if (xa_is_err(old)) {
@@ -229,7 +236,8 @@ static int ivpu_open(struct drm_device *dev, struct
drm_file *file)
err_ctx_fini:
ivpu_mmu_user_context_fini(vdev, &file_priv->ctx);
-err_free_file_priv:
+err_mutex_destroy:
+ mutex_destroy(&file_priv->lock);
kfree(file_priv);
err_xa_erase:
xa_erase_irq(&vdev->context_xa, ctx_id);
@@ -252,6 +260,8 @@ static const struct drm_ioctl_desc ivpu_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(IVPU_SET_PARAM, ivpu_set_param_ioctl, 0),
DRM_IOCTL_DEF_DRV(IVPU_BO_CREATE, ivpu_bo_create_ioctl, 0),
DRM_IOCTL_DEF_DRV(IVPU_BO_INFO, ivpu_bo_info_ioctl, 0),
+ DRM_IOCTL_DEF_DRV(IVPU_SUBMIT, ivpu_submit_ioctl, 0),
+ DRM_IOCTL_DEF_DRV(IVPU_BO_WAIT, ivpu_bo_wait_ioctl, 0),
};
static int ivpu_wait_for_ready(struct ivpu_device *vdev)
@@ -458,6 +468,8 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
vdev->context_xa_limit.max = IVPU_CONTEXT_LIMIT;
atomic64_set(&vdev->unique_id_counter, 0);
xa_init_flags(&vdev->context_xa, XA_FLAGS_ALLOC);
+ xa_init_flags(&vdev->submitted_jobs_xa, XA_FLAGS_ALLOC1);
+ lockdep_set_class(&vdev->submitted_jobs_xa.xa_lock,
&submitted_jobs_xa_lock_class_key);
ret = ivpu_pci_init(vdev);
if (ret) {
@@ -509,20 +521,30 @@ static int ivpu_dev_init(struct ivpu_device *vdev)
goto err_fw_f
Re: [PATCH v2 3/3] drm: Call vga_switcheroo_process_delayed_switch() in drm_lastclose
On Thu, Jan 12, 2023 at 09:11:56PM +0100, Thomas Zimmermann wrote: > Several lastclose helpers call vga_switcheroo_process_delayed_switch(). > It's better to call the helper from drm_lastclose() after the kernel > client's screen has been restored. This way, all drivers can benefit > without having to implement their own lastclose helper. For drivers > without vga-switcheroo, vga_switcheroo_process_delayed_switch() does > nothing. [...] > --- a/drivers/gpu/drm/drm_file.c > +++ b/drivers/gpu/drm/drm_file.c > @@ -38,6 +38,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -460,6 +461,8 @@ void drm_lastclose(struct drm_device * dev) > drm_legacy_dev_reinit(dev); > > drm_client_dev_restore(dev); > + > + vga_switcheroo_process_delayed_switch(); > } Hm, this looks like a case of midlayer fallacy: https://blog.ffwll.ch/2016/12/midlayers-once-more-with-feeling.html It is a departure from the opt-in library approach we've had so far. For switcheroo-aware EDID retrieval, there's a drm_get_edid_switcheroo() helper. How about introducing a switcheroo-aware lastclose helper which drivers can reference? Thanks, Lukas
Re: [RFC PATCH 0/4] dt-bindings: Introduce dual-link panels & panel-vendors
Hi Laurent, Thank you for taking a look at this! On 16-Jan-23 15:00, Laurent Pinchart wrote: Hi Aradhya, On Tue, Jan 03, 2023 at 12:16:11PM +0530, Aradhya Bhatia wrote: Hi all, Microtips Technology Solutions USA, and Lincoln Technology Solutions are 2 display panel vendors, and the first 2 patches add their vendor prefixes. The fourth patch, simply introduces the new compatible for the generic dual-link panels in the panel-lvds driver. This new compatible is based from a new DT binding added in the third patch explained below. The third patch introduces a dt-binding for generic dual-link LVDS panels. These panels do not have any documented constraints, except for their timing characteristics. Further, these panels have 2 pixel-sinks. In a dual-link connection between an LVDS encoder and the panel, one sink accepts the odd set of LVDS pixels and the other, the even set. A lot of this has been based from the Advantech,idk-2121wr dual-link panel[1] and Maxime's patches for generic LVDS panels[2] (which are single-link by default.) and the discussions that happened before they were finally merged. Below are some notes and points that I want to bring forward. - The advantech,idk-2121wr panel binding uses 2 boolean properties dual-link-odd/even-pixels, to signify which port sink is being used for which set of LVDS pixels. I too have added similar support and introduced constraints around those properties, so as to not break the ABI... but I believe there is a better way to achieve this. A "pixel-type" enum property could be introduced in their stead, which can accept one of the 2 options or . This method, in my opinion, is more accurate and cleaner to implement in the bindings as well. If this does sound a better I can push out a new revision where the driver supports both these methods (to not break the ABI) and the advantech,2121wr panel can remain as an exception. It's usually best not to change an existing system if there are no good reasons, so I'd ask why you think a pixel-type property would be better (including when taking into account the fact that we would have to maintain the advantech,2121wtr driver separately) if you want to go that way. Otherwise, if we were developing this from scratch, I would have no real preference. Such a property would have been a more accurate representation of the case here, voiding the need of a "oneOf:" clause, and simplifying the overall binding implementation. Furthermore, I saw this as a fair opportunity to introduce the new property because there was only one other dual link panel which used the original properties. And, while the code delta shall be same in implementing the pixel-type property irrespective of the number of existing dual-link panels that support the original method, I believe with pixel-type, we can set a fresh precedence for future scenarios (perhaps for "quad-link" LVDS, if there ever will be one). Having said that, this was merely a suggestion. If this does not seem to be a strong enough reason to change the existing system, I can keep using the original properties (as I have in the patches) and send a v2. - As an alternative to the previous point, if that method is not preferred for some reason, the advantech,2121wtr panel binding could then be merged in the panel-dual-lvds binding as part of future work. - Another tweak, I am looking forward to do as part of future work and would like all your comments is to introduce driver-based implementation of the panel timing parameters, like it is with "panel-simple". The driver can then support both the panel-timing sources (DT node or hard-coded driver structure) and the binding can remove this from the "required" section. There's been a very long discussion in the past (multiple discussions actually) regarding whether timings should be set in DT or in drivers. There were multiple arguments supporting both sides, without (it seems) a clear winner. If you want driver-side timings for dual-link panels, I'd like to understand why you think that's better. If the reasons are the same as the ones expressed when we discussed simple panels, you should also look at whether or not any of the fears expressed on either side have materialized. I went through the discussions that you mentioned above. For now, I will stick to the status-quo that there is for LVDS panels. =) Thank you! [1]: https://patchwork.freedesktop.org/patch/357122/ [2]: https://patchwork.freedesktop.org/patch/471228/ Aradhya Bhatia (4): dt-bindings: vendor-prefixes: Add microtips dt-bindings: vendor-prefixes: Add lincolntech dt-bindings: panel: Introduce dual-link LVDS panel drm: panel-lvds: Introduce dual-link panels .../display/panel/panel-dual-lvds.yaml| 157 ++ .../devicetree/bindings/vendor-prefixes.yaml | 4 + MAINTAINERS
RE: [PATCH] dt-bindings: display: bridge: renesas,rzg2l-mipi-dsi: Document RZ/V2L support
Hi All,
Gentle ping.
It is acked by Krzysztof Kozlowski and Reviewed by Geert.
It is blocking for accepting SoC dtsi patches[1] through renesas-soc tree
[1]
https://lore.kernel.org/all/20221122213529.2103849-1-biju.das...@bp.renesas.com
Cheers,
Biju
> -Original Message-
> From: Biju Das
> Sent: 22 November 2022 19:54
> To: Andrzej Hajda ; Neil Armstrong
> ; Robert Foss ; David
> Airlie ; Daniel Vetter ; Rob Herring
> ; Krzysztof Kozlowski
>
> Cc: Biju Das ; Laurent Pinchart
> ; Jonas Karlman ; Jernej
> Skrabec ; dri-devel@lists.freedesktop.org;
> devicet...@vger.kernel.org; Geert Uytterhoeven ;
> Fabrizio Castro ; linux-renesas-
> s...@vger.kernel.org
> Subject: [PATCH] dt-bindings: display: bridge: renesas,rzg2l-mipi-dsi:
> Document RZ/V2L support
>
> Document RZ/V2L DSI bindings. RZ/V2L MIPI DSI is identical to one found on
> the RZ/G2L SoC. No driver changes are required as generic compatible string
> "renesas,rzg2l-mipi-dsi" will be used as a fallback.
>
> Signed-off-by: Biju Das
> ---
> .../devicetree/bindings/display/bridge/renesas,dsi.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml
> b/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml
> index 131d5b63ec4f..e08c24633926 100644
> --- a/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml
> @@ -22,6 +22,7 @@ properties:
> items:
>- enum:
>- renesas,r9a07g044-mipi-dsi # RZ/G2{L,LC}
> + - renesas,r9a07g054-mipi-dsi # RZ/V2L
>- const: renesas,rzg2l-mipi-dsi
>
>reg:
> --
> 2.25.1
Re: [PATCH v2 3/3] drm: Call vga_switcheroo_process_delayed_switch() in drm_lastclose
Hi Am 17.01.23 um 10:44 schrieb Lukas Wunner: On Thu, Jan 12, 2023 at 09:11:56PM +0100, Thomas Zimmermann wrote: Several lastclose helpers call vga_switcheroo_process_delayed_switch(). It's better to call the helper from drm_lastclose() after the kernel client's screen has been restored. This way, all drivers can benefit without having to implement their own lastclose helper. For drivers without vga-switcheroo, vga_switcheroo_process_delayed_switch() does nothing. [...] --- a/drivers/gpu/drm/drm_file.c +++ b/drivers/gpu/drm/drm_file.c @@ -38,6 +38,7 @@ #include #include #include +#include #include #include @@ -460,6 +461,8 @@ void drm_lastclose(struct drm_device * dev) drm_legacy_dev_reinit(dev); drm_client_dev_restore(dev); + + vga_switcheroo_process_delayed_switch(); } Hm, this looks like a case of midlayer fallacy: https://blog.ffwll.ch/2016/12/midlayers-once-more-with-feeling.html It is a departure from the opt-in library approach we've had so far. For switcheroo-aware EDID retrieval, there's a drm_get_edid_switcheroo() helper. How about introducing a switcheroo-aware lastclose helper which drivers can reference? Console emulation is a mess. I'm working on it, but it takes time. Therefore a nice solution is probably not possible ATM. We could have something like drm_fb_helper_lastclose_switcheroo(), which does drm_fb_helper_lastclose() + vga_switcheroo_process_delayed_switch(). i915 and radeon could use that as-is. amdgpu and nouveau have already switched to generic fbdev emulation. We could use drm_fb_helper_lastclose_switcheroo() from the generic code as well, but it will still be somewhat midlayerish. But with all that, it's probably better to not land patch 3 at all. The hook drm_driver.lastclose is just for the old fbdev emulation. For the new fbdev emulation, we have better data structures (see drm_client_dev). The correct design would be to switch amdgpu and nouveau back to their own fbdev emulation and handle switcheroo there. But their old fbdev code needed an overhaul, so just reverting isn't an option. Best regards Thomas Thanks, Lukas -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v11 5/5] drm/bridge: cdns-dsi: Add support for J721E wrapper
Hi Rahul,
Thank you for the patch.
On Tue, Jan 03, 2023 at 03:49:51PM +0530, Rahul T R wrote:
> Add support for wrapper settings for DSI bridge on j721e. Also enable
> DPI0
>
> --- ---
> | ---| |--- |
> | DSS | DPI2 |->| DPI0 | DSI Wrapper |
> | ---| |--- |
> --- ---
>
> As shown above DPI2 output of DSS is connected to DPI0 input of DSI
> Wrapper, DSI wrapper gives control wheather to enable/disable DPI0
> input. In j721e above is the only configuration supported
>
> Signed-off-by: Rahul T R
> Reviewed-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/cadence/Kconfig| 10
> drivers/gpu/drm/bridge/cadence/Makefile | 1 +
> .../gpu/drm/bridge/cadence/cdns-dsi-core.c| 35 -
> .../gpu/drm/bridge/cadence/cdns-dsi-core.h| 20
> .../gpu/drm/bridge/cadence/cdns-dsi-j721e.c | 51 +++
> .../gpu/drm/bridge/cadence/cdns-dsi-j721e.h | 16 ++
> 6 files changed, 132 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-j721e.c
> create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-j721e.h
>
> diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
> b/drivers/gpu/drm/bridge/cadence/Kconfig
> index 5f39859dcfdd..ec35215a2003 100644
> --- a/drivers/gpu/drm/bridge/cadence/Kconfig
> +++ b/drivers/gpu/drm/bridge/cadence/Kconfig
> @@ -10,6 +10,16 @@ config DRM_CDNS_DSI
> Support Cadence DPI to DSI bridge. This is an internal
> bridge and is meant to be directly embedded in a SoC.
>
> +if DRM_CDNS_DSI
> +
> +config DRM_CDNS_DSI_J721E
> + bool "J721E Cadence DSI wrapper support"
> + default y
> + help
> + Support J721E Cadence DSI wrapper. The wrapper manages
> + the routing of the DSS DPI signal to the Cadence DSI.
> +endif
> +
> config DRM_CDNS_MHDP8546
> tristate "Cadence DPI/DP bridge"
> select DRM_DISPLAY_DP_HELPER
> diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
> b/drivers/gpu/drm/bridge/cadence/Makefile
> index 9e2f34c84480..c95fd5b81d13 100644
> --- a/drivers/gpu/drm/bridge/cadence/Makefile
> +++ b/drivers/gpu/drm/bridge/cadence/Makefile
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0-only
> obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> cdns-dsi-y := cdns-dsi-core.o
> +cdns-dsi-$(CONFIG_DRM_CDNS_DSI_J721E) += cdns-dsi-j721e.o
> obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
> cdns-mhdp8546-y := cdns-mhdp8546-core.o cdns-mhdp8546-hdcp.o
> cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) += cdns-mhdp8546-j721e.o
> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
> b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
> index 058349bfeb67..5dbfc7226b31 100644
> --- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
> +++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -23,6 +24,9 @@
> #include
>
> #include "cdns-dsi-core.h"
> +#ifdef CONFIG_DRM_CDNS_DSI_J721E
> +#include "cdns-dsi-j721e.h"
> +#endif
>
> #define IP_CONF 0x0
> #define SP_HS_FIFO_DEPTH(x) (((x) & GENMASK(30, 26)) >> 26)
> @@ -665,6 +669,10 @@ static void cdns_dsi_bridge_disable(struct drm_bridge
> *bridge)
>
> val = readl(dsi->regs + MCTL_MAIN_EN) & ~IF_EN(input->id);
> writel(val, dsi->regs + MCTL_MAIN_EN);
> +
> + if (dsi->platform_ops && dsi->platform_ops->disable)
> + dsi->platform_ops->disable(dsi);
> +
> pm_runtime_put(dsi->base.dev);
> }
>
> @@ -760,6 +768,9 @@ static void cdns_dsi_bridge_enable(struct drm_bridge
> *bridge)
> if (WARN_ON(pm_runtime_get_sync(dsi->base.dev) < 0))
> return;
>
> + if (dsi->platform_ops && dsi->platform_ops->enable)
> + dsi->platform_ops->enable(dsi);
> +
> mode = &bridge->encoder->crtc->state->adjusted_mode;
> nlanes = output->dev->lanes;
>
> @@ -1200,6 +1211,8 @@ static int cdns_dsi_drm_probe(struct platform_device
> *pdev)
> goto err_disable_pclk;
> }
>
> + dsi->platform_ops = of_device_get_match_data(&pdev->dev);
> +
> val = readl(dsi->regs + IP_CONF);
> dsi->direct_cmd_fifo_depth = 1 << (DIRCMD_FIFO_DEPTH(val) + 2);
> dsi->rx_fifo_depth = RX_FIFO_DEPTH(val);
> @@ -1235,14 +1248,27 @@ static int cdns_dsi_drm_probe(struct platform_device
> *pdev)
> dsi->base.dev = &pdev->dev;
> dsi->base.ops = &cdns_dsi_ops;
>
> + if (dsi->platform_ops && dsi->platform_ops->init) {
> + ret = dsi->platform_ops->init(dsi);
> + if (ret != 0) {
> + dev_err(&pdev->dev, "platform initialization failed:
> %d\n",
> + ret);
> + goto err_disable_runtime_pm;
> +
[PATCH 1/1] drm/bridge: sii902x: Use dev_err_probe
This helps figuring out why the device probe is deferred. Signed-off-by: Alexander Stein --- drivers/gpu/drm/bridge/sii902x.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c index d212ff7f7a87..f4a8f227c41b 100644 --- a/drivers/gpu/drm/bridge/sii902x.c +++ b/drivers/gpu/drm/bridge/sii902x.c @@ -1116,7 +1116,8 @@ static int sii902x_probe(struct i2c_client *client) sii902x->next_bridge = of_drm_find_bridge(remote); of_node_put(remote); if (!sii902x->next_bridge) - return -EPROBE_DEFER; + return dev_err_probe(dev, -EPROBE_DEFER, +"Failed to find remote bridge\n"); } mutex_init(&sii902x->mutex); -- 2.34.1
Re: [PATCH v3 6/6] ARM: dts: stm32: Use new media bus type macros
Hi Laurent
On 1/14/23 16:36, Laurent Pinchart wrote:
Hugues, Maxime, Alexandre, could one of you take this patch in your tree
for v6.3 ? The two patches that it depends on have both been merged in
v6.2.
Yes sure.
Cheers
Alex
On Thu, Jun 16, 2022 at 01:14:10AM +0300, Laurent Pinchart wrote:
Now that a header exists with macros for the media interface bus-type
values, replace hardcoding numerical constants with the corresponding
macros in the DT sources.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/stm32429i-eval.dts | 3 ++-
arch/arm/boot/dts/stm32mp157c-ev1.dts | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
b/arch/arm/boot/dts/stm32429i-eval.dts
index 0d98aca01736..5fae11e6607b 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -50,6 +50,7 @@
#include "stm32f429-pinctrl.dtsi"
#include
#include
+#include
/ {
model = "STMicroelectronics STM32429i-EVAL board";
@@ -186,7 +187,7 @@ &dcmi {
port {
dcmi_0: endpoint {
remote-endpoint = <&ov2640_0>;
- bus-type = <5>;
+ bus-type = ;
bus-width = <8>;
hsync-active = <0>;
vsync-active = <0>;
diff --git a/arch/arm/boot/dts/stm32mp157c-ev1.dts
b/arch/arm/boot/dts/stm32mp157c-ev1.dts
index d142dd30e16b..306d41a6138f 100644
--- a/arch/arm/boot/dts/stm32mp157c-ev1.dts
+++ b/arch/arm/boot/dts/stm32mp157c-ev1.dts
@@ -8,6 +8,7 @@
#include "stm32mp157c-ed1.dts"
#include
#include
+#include
/ {
model = "STMicroelectronics STM32MP157C eval daughter on eval mother";
@@ -90,7 +91,7 @@ &dcmi {
port {
dcmi_0: endpoint {
remote-endpoint = <&ov5640_0>;
- bus-type = <5>;
+ bus-type = ;
bus-width = <8>;
hsync-active = <0>;
vsync-active = <0>;
[PATCH 1/2] drm: fsl-dcu: Use dev_err_probe
fsl_dcu_drm_modeset_init can return -EPROBE_DEFER, so use dev_err_probe
to remove an invalid error message and add it to deferral description.
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 8579c7629f5e..418887654bac 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -103,10 +103,8 @@ static int fsl_dcu_load(struct drm_device *dev, unsigned
long flags)
int ret;
ret = fsl_dcu_drm_modeset_init(fsl_dev);
- if (ret < 0) {
- dev_err(dev->dev, "failed to initialize mode setting\n");
- return ret;
- }
+ if (ret < 0)
+ return dev_err_probe(dev->dev, ret, "failed to initialize mode
setting\n");
ret = drm_vblank_init(dev, dev->mode_config.num_crtc);
if (ret < 0) {
--
2.34.1
[PATCH 2/2] drm: fsl-dcu: enable PIXCLK on LS1021A
From: Matthias Schiffer
The PIXCLK needs to be enabled in SCFG before accessing certain DCU
registers, or the access will hang.
Signed-off-by: Matthias Schiffer
Signed-off-by: Alexander Stein
---
drivers/gpu/drm/fsl-dcu/Kconfig | 1 +
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 14 ++
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 3 +++
3 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/fsl-dcu/Kconfig b/drivers/gpu/drm/fsl-dcu/Kconfig
index 5ca71ef87325..c9ee98693b48 100644
--- a/drivers/gpu/drm/fsl-dcu/Kconfig
+++ b/drivers/gpu/drm/fsl-dcu/Kconfig
@@ -8,6 +8,7 @@ config DRM_FSL_DCU
select DRM_PANEL
select REGMAP_MMIO
select VIDEOMODE_HELPERS
+ select MFD_SYSCON if SOC_LS1021A
help
Choose this option if you have an Freescale DCU chipset.
If M is selected the module will be called fsl-dcu-drm.
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 418887654bac..314cb8af89ee 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -100,12 +100,26 @@ static void fsl_dcu_irq_uninstall(struct drm_device *dev)
static int fsl_dcu_load(struct drm_device *dev, unsigned long flags)
{
struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
+ struct regmap *scfg;
int ret;
ret = fsl_dcu_drm_modeset_init(fsl_dev);
if (ret < 0)
return dev_err_probe(dev->dev, ret, "failed to initialize mode
setting\n");
+ scfg = syscon_regmap_lookup_by_compatible("fsl,ls1021a-scfg");
+ if (PTR_ERR(scfg) != -ENODEV) {
+ /*
+* For simplicity, enable the PIXCLK unconditionally. Disabling
+* the clock in PM or on unload could be implemented as a future
+* improvement.
+*/
+ ret = regmap_update_bits(scfg, SCFG_PIXCLKCR,
SCFG_PIXCLKCR_PXCEN,
+ SCFG_PIXCLKCR_PXCEN);
+ if (ret < 0)
+ return dev_err_probe(dev->dev, ret, "failed to enable
pixclk\n");
+ }
+
ret = drm_vblank_init(dev, dev->mode_config.num_crtc);
if (ret < 0) {
dev_err(dev->dev, "failed to initialize vblank\n");
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
index e2049a0e8a92..566396013c04 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
@@ -160,6 +160,9 @@
#define FSL_DCU_ARGB 12
#define FSL_DCU_YUV422 14
+#define SCFG_PIXCLKCR 0x28
+#define SCFG_PIXCLKCR_PXCENBIT(31)
+
#define VF610_LAYER_REG_NUM9
#define LS1021A_LAYER_REG_NUM 10
--
2.34.1
Re: [PATCH 1/1] drm/bridge: sii902x: Use dev_err_probe
On 17.01.2023 11:59, Alexander Stein wrote: This helps figuring out why the device probe is deferred. Signed-off-by: Alexander Stein --- drivers/gpu/drm/bridge/sii902x.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c index d212ff7f7a87..f4a8f227c41b 100644 --- a/drivers/gpu/drm/bridge/sii902x.c +++ b/drivers/gpu/drm/bridge/sii902x.c @@ -1116,7 +1116,8 @@ static int sii902x_probe(struct i2c_client *client) sii902x->next_bridge = of_drm_find_bridge(remote); of_node_put(remote); if (!sii902x->next_bridge) - return -EPROBE_DEFER; + return dev_err_probe(dev, -EPROBE_DEFER, +"Failed to find remote bridge\n"); Reviewed-by: Andrzej Hajda Regards Andrzej } mutex_init(&sii902x->mutex);
Re: [PATCH v11 1/5] dt-bindings: display: bridge: Convert cdns,dsi.txt to yaml
On 03.01.2023 11:19, Rahul T R wrote: Convert cdns,dsi.txt binding to yaml format Signed-off-by: Rahul T R Reviewed-by: Rob Herring Reviewed-by: Laurent Pinchart Reviewed-by: Andrzej Hajda Regards Andrzej
Re: [PATCH v11 2/5] dt-bindings: display: bridge: cdns,dsi: Add compatible for dsi on j721e
On 03.01.2023 11:19, Rahul T R wrote: Add compatible to support dsi bridge on j721e Signed-off-by: Rahul T R Reviewed-by: Rob Herring Reviewed-by: Laurent Pinchart Reviewed-by: Andrzej Hajda Regards Andrzej --- .../bindings/display/bridge/cdns,dsi.yaml | 25 ++- 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml index 3161c33093c1..23060324d16e 100644 --- a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml +++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml @@ -16,9 +16,15 @@ properties: compatible: enum: - cdns,dsi + - ti,j721e-dsi reg: -maxItems: 1 +minItems: 1 +items: + - description: + Register block for controller's registers. + - description: + Register block for wrapper settings registers in case of TI J7 SoCs. clocks: items: @@ -67,6 +73,23 @@ properties: allOf: - $ref: ../dsi-controller.yaml# + - if: + properties: +compatible: + contains: +const: ti,j721e-dsi +then: + properties: +reg: + minItems: 2 + maxItems: 2 +power-domains: + maxItems: 1 +else: + properties: +reg: + maxItems: 1 + required: - compatible - reg
Re: [PATCH v11 3/5] drm/bridge: cdns-dsi: Move to drm/bridge/cadence
On 03.01.2023 11:19, Rahul T R wrote:
Move the cadence dsi bridge under drm/bridge/cadence directory, to
prepare for adding j721e wrapper support
Signed-off-by: Rahul T R
Reviewed-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
drivers/gpu/drm/bridge/Kconfig| 11 ---
drivers/gpu/drm/bridge/Makefile | 1 -
drivers/gpu/drm/bridge/cadence/Kconfig| 11 +++
drivers/gpu/drm/bridge/cadence/Makefile | 2 ++
.../bridge/{cdns-dsi.c => cadence/cdns-dsi-core.c}| 0
5 files changed, 13 insertions(+), 12 deletions(-)
rename drivers/gpu/drm/bridge/{cdns-dsi.c => cadence/cdns-dsi-core.c} (100%)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 57946d80b02d..8b2226f72b24 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -15,17 +15,6 @@ config DRM_PANEL_BRIDGE
menu "Display Interface Bridges"
depends on DRM && DRM_BRIDGE
-config DRM_CDNS_DSI
- tristate "Cadence DPI/DSI bridge"
- select DRM_KMS_HELPER
- select DRM_MIPI_DSI
- select DRM_PANEL_BRIDGE
- select GENERIC_PHY_MIPI_DPHY
- depends on OF
- help
- Support Cadence DPI to DSI bridge. This is an internal
- bridge and is meant to be directly embedded in a SoC.
-
config DRM_CHIPONE_ICN6211
tristate "Chipone ICN6211 MIPI-DSI/RGB Converter bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 1884803c6860..52f6e8b4a821 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,5 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_CHIPONE_ICN6211) += chipone-icn6211.o
obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_CROS_EC_ANX7688) += cros-ec-anx7688.o
diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
b/drivers/gpu/drm/bridge/cadence/Kconfig
index 1d06182bea71..5f39859dcfdd 100644
--- a/drivers/gpu/drm/bridge/cadence/Kconfig
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -1,4 +1,15 @@
# SPDX-License-Identifier: GPL-2.0-only
+config DRM_CDNS_DSI
+ tristate "Cadence DPI/DSI bridge"
+ select DRM_KMS_HELPER
+ select DRM_MIPI_DSI
+ select DRM_PANEL_BRIDGE
+ select GENERIC_PHY_MIPI_DPHY
+ depends on OF
+ help
+ Support Cadence DPI to DSI bridge. This is an internal
+ bridge and is meant to be directly embedded in a SoC.
+
config DRM_CDNS_MHDP8546
tristate "Cadence DPI/DP bridge"
select DRM_DISPLAY_DP_HELPER
diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
b/drivers/gpu/drm/bridge/cadence/Makefile
index 4d2db8df1bc6..9e2f34c84480 100644
--- a/drivers/gpu/drm/bridge/cadence/Makefile
+++ b/drivers/gpu/drm/bridge/cadence/Makefile
@@ -1,4 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
+cdns-dsi-y := cdns-dsi-core.o
obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
cdns-mhdp8546-y := cdns-mhdp8546-core.o cdns-mhdp8546-hdcp.o
cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) += cdns-mhdp8546-j721e.o
diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c
b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
similarity index 100%
rename from drivers/gpu/drm/bridge/cdns-dsi.c
rename to drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
Re: [PATCH v11 4/5] drm/bridge: cdns-dsi: Create a header file
On 03.01.2023 11:19, Rahul T R wrote: Create a header file for cdns dsi and move structure definations to prepare for adding j721e wrapper support Signed-off-by: Rahul T R Reviewed-by: Tomi Valkeinen Reviewed-by: Laurent Pinchart Reviewed-by: Andrzej Hajda Regards Andrzej
Re: [PATCH v11 5/5] drm/bridge: cdns-dsi: Add support for J721E wrapper
On 03.01.2023 11:19, Rahul T R wrote:
Add support for wrapper settings for DSI bridge on j721e. Also enable
DPI0
--- ---
| ---| |--- |
| DSS | DPI2 |->| DPI0 | DSI Wrapper |
| ---| |--- |
--- ---
As shown above DPI2 output of DSS is connected to DPI0 input of DSI
Wrapper, DSI wrapper gives control wheather to enable/disable DPI0
input. In j721e above is the only configuration supported
Signed-off-by: Rahul T R
Reviewed-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
drivers/gpu/drm/bridge/cadence/Kconfig| 10
drivers/gpu/drm/bridge/cadence/Makefile | 1 +
.../gpu/drm/bridge/cadence/cdns-dsi-core.c| 35 -
.../gpu/drm/bridge/cadence/cdns-dsi-core.h| 20
.../gpu/drm/bridge/cadence/cdns-dsi-j721e.c | 51 +++
.../gpu/drm/bridge/cadence/cdns-dsi-j721e.h | 16 ++
6 files changed, 132 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-j721e.c
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-j721e.h
diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
b/drivers/gpu/drm/bridge/cadence/Kconfig
index 5f39859dcfdd..ec35215a2003 100644
--- a/drivers/gpu/drm/bridge/cadence/Kconfig
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -10,6 +10,16 @@ config DRM_CDNS_DSI
Support Cadence DPI to DSI bridge. This is an internal
bridge and is meant to be directly embedded in a SoC.
+if DRM_CDNS_DSI
+
+config DRM_CDNS_DSI_J721E
+ bool "J721E Cadence DSI wrapper support"
+ default y
+ help
+ Support J721E Cadence DSI wrapper. The wrapper manages
+ the routing of the DSS DPI signal to the Cadence DSI.
+endif
+
config DRM_CDNS_MHDP8546
tristate "Cadence DPI/DP bridge"
select DRM_DISPLAY_DP_HELPER
diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
b/drivers/gpu/drm/bridge/cadence/Makefile
index 9e2f34c84480..c95fd5b81d13 100644
--- a/drivers/gpu/drm/bridge/cadence/Makefile
+++ b/drivers/gpu/drm/bridge/cadence/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
cdns-dsi-y := cdns-dsi-core.o
+cdns-dsi-$(CONFIG_DRM_CDNS_DSI_J721E) += cdns-dsi-j721e.o
obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
cdns-mhdp8546-y := cdns-mhdp8546-core.o cdns-mhdp8546-hdcp.o
cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) += cdns-mhdp8546-j721e.o
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
index 058349bfeb67..5dbfc7226b31 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -23,6 +24,9 @@
#include
#include "cdns-dsi-core.h"
+#ifdef CONFIG_DRM_CDNS_DSI_J721E
+#include "cdns-dsi-j721e.h"
+#endif
#define IP_CONF0x0
#define SP_HS_FIFO_DEPTH(x) (((x) & GENMASK(30, 26)) >> 26)
@@ -665,6 +669,10 @@ static void cdns_dsi_bridge_disable(struct drm_bridge
*bridge)
val = readl(dsi->regs + MCTL_MAIN_EN) & ~IF_EN(input->id);
writel(val, dsi->regs + MCTL_MAIN_EN);
+
+ if (dsi->platform_ops && dsi->platform_ops->disable)
+ dsi->platform_ops->disable(dsi);
+
pm_runtime_put(dsi->base.dev);
}
@@ -760,6 +768,9 @@ static void cdns_dsi_bridge_enable(struct drm_bridge *bridge)
if (WARN_ON(pm_runtime_get_sync(dsi->base.dev) < 0))
return;
+ if (dsi->platform_ops && dsi->platform_ops->enable)
+ dsi->platform_ops->enable(dsi);
+
mode = &bridge->encoder->crtc->state->adjusted_mode;
nlanes = output->dev->lanes;
@@ -1200,6 +1211,8 @@ static int cdns_dsi_drm_probe(struct platform_device *pdev)
goto err_disable_pclk;
}
+ dsi->platform_ops = of_device_get_match_data(&pdev->dev);
+
val = readl(dsi->regs + IP_CONF);
dsi->direct_cmd_fifo_depth = 1 << (DIRCMD_FIFO_DEPTH(val) + 2);
dsi->rx_fifo_depth = RX_FIFO_DEPTH(val);
@@ -1235,14 +1248,27 @@ static int cdns_dsi_drm_probe(struct platform_device
*pdev)
dsi->base.dev = &pdev->dev;
dsi->base.ops = &cdns_dsi_ops;
+ if (dsi->platform_ops && dsi->platform_ops->init) {
+ ret = dsi->platform_ops->init(dsi);
+ if (ret != 0) {
+ dev_err(&pdev->dev, "platform initialization failed:
%d\n",
+ ret);
+ goto err_disable_runtime_pm;
+ }
+ }
+
ret = mipi_dsi_host_register(&dsi->base);
if (ret)
- goto err_disable_runtime_pm;
+ goto err_deinit_platform;
clk_disable_unprepare(dsi->dsi_p_clk);
return 0;
[PATCH 1/2] drm/print: Add drm_dbg_ratelimited
Add a function for ratelimitted debug print. Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Reviewed-by: Matthew Auld Signed-off-by: Nirmoy Das --- include/drm/drm_print.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h index a44fb7ef257f..1d839f507319 100644 --- a/include/drm/drm_print.h +++ b/include/drm/drm_print.h @@ -602,6 +602,9 @@ void __drm_err(const char *format, ...); drm_dev_printk(drm_ ? drm_->dev : NULL, KERN_DEBUG, fmt, ## __VA_ARGS__); \ }) +#define drm_dbg_ratelimited(drm, fmt, ...) \ + __DRM_DEFINE_DBG_RATELIMITED(DRIVER, drm, fmt, ## __VA_ARGS__) + #define drm_dbg_kms_ratelimited(drm, fmt, ...) \ __DRM_DEFINE_DBG_RATELIMITED(KMS, drm, fmt, ## __VA_ARGS__) -- 2.39.0
[PATCH 2/2] drm/i915: Ratelimit debug log in vm_fault_ttm
Test like i915_gem_mman_live_selftests/igt_mmap_migrate can cause
dmesg spamming. Use ratelimit api to reduce log rate.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/7038
Cc: Matthew Auld
Reviewed-by: Matthew Auld
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 8cfed1bef629..25294ddbee46 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1077,8 +1077,9 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
}
if (err) {
- drm_dbg(dev, "Unable to make resource CPU
accessible(err = %pe)\n",
- ERR_PTR(err));
+ drm_dbg_ratelimited(dev,
+ "Unable to make resource CPU
accessible(err = %pe)\n",
+ ERR_PTR(err));
dma_resv_unlock(bo->base.resv);
ret = VM_FAULT_SIGBUS;
goto out_rpm;
--
2.39.0
Re: [Intel-gfx] [PATCH 1/2] drm/print: Add drm_dbg_ratelimited
On 17.01.2023 12:53, Nirmoy Das wrote: Add a function for ratelimitted debug print. Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Reviewed-by: Matthew Auld Signed-off-by: Nirmoy Das Reviewed-by: Andrzej Hajda Regards Andrzej --- include/drm/drm_print.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h index a44fb7ef257f..1d839f507319 100644 --- a/include/drm/drm_print.h +++ b/include/drm/drm_print.h @@ -602,6 +602,9 @@ void __drm_err(const char *format, ...); drm_dev_printk(drm_ ? drm_->dev : NULL, KERN_DEBUG, fmt, ## __VA_ARGS__);\ }) +#define drm_dbg_ratelimited(drm, fmt, ...) \ + __DRM_DEFINE_DBG_RATELIMITED(DRIVER, drm, fmt, ## __VA_ARGS__) + #define drm_dbg_kms_ratelimited(drm, fmt, ...) \ __DRM_DEFINE_DBG_RATELIMITED(KMS, drm, fmt, ## __VA_ARGS__)
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Ratelimit debug log in vm_fault_ttm
On 17.01.2023 12:53, Nirmoy Das wrote:
Test like i915_gem_mman_live_selftests/igt_mmap_migrate can cause
dmesg spamming. Use ratelimit api to reduce log rate.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/7038
Cc: Matthew Auld
Reviewed-by: Matthew Auld
Signed-off-by: Nirmoy Das
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 8cfed1bef629..25294ddbee46 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1077,8 +1077,9 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
}
if (err) {
- drm_dbg(dev, "Unable to make resource CPU accessible(err =
%pe)\n",
- ERR_PTR(err));
+ drm_dbg_ratelimited(dev,
+ "Unable to make resource CPU
accessible(err = %pe)\n",
+ ERR_PTR(err));
dma_resv_unlock(bo->base.resv);
ret = VM_FAULT_SIGBUS;
goto out_rpm;
Re: [PATCH v3 6/6] ARM: dts: stm32: Use new media bus type macros
Hi Laurent On 6/16/22 00:14, Laurent Pinchart wrote: Now that a header exists with macros for the media interface bus-type values, replace hardcoding numerical constants with the corresponding macros in the DT sources. Signed-off-by: Laurent Pinchart Applied on stm32-next. Thanks. Alex
Re: [PATCH v3 1/2] drm/panel: Add driver for the AUO A030JTN01 TFT LCD
Hi Christophe,
Le mardi 20 décembre 2022 à 13:01 +0100, Christophe Branchereau a
écrit :
> Add driver for the AUO A030JTN01 panel, which is a 320x480 3.0" 4:3
> 24-bit TFT LCD panel with non-square pixels and a delta-RGB 8-bit
> interface.
>
> Signed-off-by: Christophe Branchereau
> Signed-off-by: Paul Cercueil
> ---
> drivers/gpu/drm/panel/Kconfig | 8 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-auo-a030jtn01.c | 307
>
> 3 files changed, 316 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-auo-a030jtn01.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig
> b/drivers/gpu/drm/panel/Kconfig
> index 737edcdf9eef..23cf0f4ba2e6 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -8,6 +8,14 @@ config DRM_PANEL
> menu "Display Panels"
> depends on DRM && DRM_PANEL
>
> +config DRM_PANEL_AUO_A030JTN01
> + tristate "AUO A030JTN01"
> + depends on SPI
> + select REGMAP_SPI
> + help
> + Say Y here to enable support for the AUO A030JTN01 320x480
> 3.0" panel
> + as found in the YLM RS-97 handheld gaming console.
> +
> config DRM_PANEL_ABT_Y030XX067A
> tristate "ABT Y030XX067A 320x480 LCD panel"
> depends on OF && SPI
> diff --git a/drivers/gpu/drm/panel/Makefile
> b/drivers/gpu/drm/panel/Makefile
> index f8f9d9f6a307..af88658abcab 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -1,4 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0
> +obj-$(CONFIG_DRM_PANEL_AUO_A030JTN01) += panel-auo-a030jtn01.o
> obj-$(CONFIG_DRM_PANEL_ABT_Y030XX067A) += panel-abt-y030xx067a.o
> obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
> obj-$(CONFIG_DRM_PANEL_ASUS_Z00T_TM5P5_NT35596) += panel-asus-z00t-
> tm5p5-n35596.o
> diff --git a/drivers/gpu/drm/panel/panel-auo-a030jtn01.c
> b/drivers/gpu/drm/panel/panel-auo-a030jtn01.c
> new file mode 100644
> index ..b9fc64f9e49c
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-auo-a030jtn01.c
> @@ -0,0 +1,307 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * AU Optronics A030JTN01.0 TFT LCD panel driver
> + *
> + * Copyright (C) 2020, Paul Cercueil
> + * Copyright (C) 2020, Christophe Branchereau
>
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#define REG05 0x05
> +#define REG05_STDBYBIT(0)
> +
> +struct a030jtn01_info {
> + const struct drm_display_mode *display_modes;
> + unsigned int num_modes;
> + u16 width_mm, height_mm;
> + u32 bus_format, bus_flags;
> +};
> +
> +struct a030jtn01 {
> + struct drm_panel panel;
> + struct spi_device *spi;
> + struct regmap *map;
> +
> + const struct a030jtn01_info *panel_info;
> +
> + struct regulator *supply;
> + struct gpio_desc *reset_gpio;
> +};
> +
> +static inline struct a030jtn01 *to_a030jtn01(struct drm_panel
> *panel)
> +{
> + return container_of(panel, struct a030jtn01, panel);
> +}
> +
> +static int a030jtn01_prepare(struct drm_panel *panel)
> +{
> + struct a030jtn01 *priv = to_a030jtn01(panel);
> + struct device *dev = &priv->spi->dev;
> + int err;
> +
> + err = regulator_enable(priv->supply);
> + if (err) {
> + dev_err(dev, "Failed to enable power supply: %d\n",
> err);
> + return err;
> + }
> +
> + usleep_range(1000, 8000);
> +
> + /* Reset the chip */
> + gpiod_set_value_cansleep(priv->reset_gpio, 1);
> + usleep_range(100, 8000);
> + gpiod_set_value_cansleep(priv->reset_gpio, 0);
> + usleep_range(2000, 8000);
> +
> + /*
> + * No idea why two writes are needed. If this write is
> commented,
> + * the colors are wrong. Doesn't seem to be timing-related,
> since
> + * a msleep(200) doesn't fix it.
> + */
> + regmap_write(priv->map, 0x06, 0x00);
> +
> + /* Use (24 + 6) == 0x1e as the vertical back porch */
> + err = regmap_write(priv->map, 0x06, 0x1e);
> + if (err)
> + goto err_disable_regulator;
> +
> + /* Use (42 + 30) * 3 == 0xd8 as the horizontal back porch */
> + err = regmap_write(priv->map, 0x07, 0xd8);
> + if (err)
> + goto err_disable_regulator;
> +
> + regmap_write(priv->map, 0x05, 0x74);
Do we have register names for these? It would be better with macros
than hardcoded addresses, e.g. AUO_REG_VPORCH and AUO_REG_HPORCH, with
AUO_REG_CTRL as a "generic" name for REG05.
(Besides, you actually have 'REG05' defined above and didn't use it
here)
> +
> + return 0;
> +
> +err_disable_regulator:
> + gpiod_set_value_cansleep(priv->reset_gpio, 1);
> + regulator_disable(priv->supply);
> + return err;
> +}
> +
> +static int a030jtn01_unprepar
Re: [PATCH v2 20/20] jump_label: RFC - tolerate toggled state
On Fri, Jan 13, 2023 at 12:30:16PM -0700, Jim Cromie wrote: > __jump_label_patch currently will "crash the box" if it finds a > jump_entry not as expected. ISTM this overly harsh; it doesn't > distinguish between "alternate/opposite" state, and truly > "insane/corrupted". > > The "opposite" (but well-formed) state is a milder mis-initialization > problem, and some less severe mitigation seems practical. ATM this > just warns about it; a range/enum of outcomes: warn, crash, silence, > ok, fixup-continue, etc, are possible on a case-by-case basis. > > Ive managed to create this mis-initialization condition with > test_dynamic_debug.ko & _submod.ko. These replicate DRM's regression > on DRM_USE_DYNAMIC_DEBUG=y; drm.debug callsites in drivers/helpers > (dependent modules) are not enabled along with those in drm.ko itself. > > Ive hit this case a few times, but havent been able to isolate the > when and why. > > warn-only is something of a punt, and I'm still left with remaining > bugs which are likely related; I'm able to toggle the p-flag on > callsites in the submod, but their enablement still doesn't yield > logging activity. Right; having been in this is state is bad since it will generate inconsistent code-flow. Full on panic *might* not be warranted (as it does for corrupted text) but it is still a fairly bad situation -- so I'm not convinced we want to warn and carry on. It would be really good to figure out why the site was skipped over and got out of skew. Given it's all module stuff, the 'obvious' case would be something like a race between adding the new sites and flipping it, but I'm not seeing how -- things are rather crudely serialized by jump_label_mutex. The only other option I can come up with is that somehow the update condition in jump_label_add_module() is somehow wrong.
[PATCH v2] drm/i915/selftests: Unwind hugepages to drop wakeref on error
From: Chris Wilson
Make sure that upon error after we have acquired the wakeref we do
release it again.
v2: add another missing "goto out_wf"(Andi).
Fixes: 027c38b4121e ("drm/i915/selftests: Grab the runtime pm in shrink_thp")
Cc: Andi Shyti
Reviewed-by: Matthew Auld
Reviewed-by: Andrzej Hajda
Signed-off-by: Chris Wilson
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index c281b0ec9e05..defece0bcb81 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1855,7 +1855,7 @@ static int igt_shrink_thp(void *arg)
I915_SHRINK_ACTIVE);
i915_vma_unpin(vma);
if (err)
- goto out_put;
+ goto out_wf;
/*
* Now that the pages are *unpinned* shrinking should invoke
@@ -1871,19 +1871,19 @@ static int igt_shrink_thp(void *arg)
pr_err("unexpected pages mismatch, should_swap=%s\n",
str_yes_no(should_swap));
err = -EINVAL;
- goto out_put;
+ goto out_wf;
}
if (should_swap == (obj->mm.page_sizes.sg || obj->mm.page_sizes.phys)) {
pr_err("unexpected residual page-size bits, should_swap=%s\n",
str_yes_no(should_swap));
err = -EINVAL;
- goto out_put;
+ goto out_wf;
}
err = i915_vma_pin(vma, 0, 0, flags);
if (err)
- goto out_put;
+ goto out_wf;
while (n--) {
err = cpu_check(obj, n, 0xdeadbeaf);
--
2.39.0
Re: [PATCH v11 0/5] Add support for CDNS DSI J721E wrapper
Hi,
On 03/01/2023 12:19, Rahul T R wrote:
Following series of patches adds supports for CDNS DSI
bridge on j721e.
v11:
- Wrap commmit messages at 72 chars
- Fix the order in Kconfig and Makefile
- Clean up the includes, move macros and some headers to .c file
- Add missing forward declarations
- Add __ prefix to header gaurds
- Change dsi_platform_ops to cdns_dsi_platform_ops
- Add documentation to struct cdns_dsi_platform_ops
v10:
- Rebased to v6.2-rc1
- Accumulated the Reviewed-by acks
v9:
- Fixed below based on review comments in v8
- Added more info on wrapper in the commit message
- Fixed the description in Kconfig
- Fixed the formatting of of_match table
- exit -> deinit in platform ops
- Remove duplicate of struct declaration in cdns-dsi-j721e.h
v8:
- Rebased to 6.1-rc1
v7:
- Rebased to next-20220920
- Accumulated the Reviewed-by acks
v6:
- Dropped generic definations for properties like reg, resets etc..
- Fixed the defination for port@0 and port@1
- removed the ti,sn65dsi86 node from the example, which is not related
v5:
- Remove power-domain property in the conversion commit
- Add power-domain only for j721e compatible
- Fix white space error in one of the commit
v4:
- split conversion txt to yaml
- seperate commit for addinig new compatible
- conditionally limit the items for reg property, based on the compatible
v3:
- Convert cdns-dsi.txt binding to yaml
- Move the bridge under display/bridge/cadence
- Add new compatible to enable the wrapper module
v2:
- Moved setting DPI0 to bridge_enable, since it
should be done after pm_runtime_get
Rahul T R (5):
dt-bindings: display: bridge: Convert cdns,dsi.txt to yaml
dt-bindings: display: bridge: cdns,dsi: Add compatible for dsi on
j721e
drm/bridge: cdns-dsi: Move to drm/bridge/cadence
drm/bridge: cdns-dsi: Create a header file
drm/bridge: cdns-dsi: Add support for J721E wrapper
.../bindings/display/bridge/cdns,dsi.txt | 112 ---
.../bindings/display/bridge/cdns,dsi.yaml | 180 ++
drivers/gpu/drm/bridge/Kconfig| 11 --
drivers/gpu/drm/bridge/Makefile | 1 -
drivers/gpu/drm/bridge/cadence/Kconfig| 21 ++
drivers/gpu/drm/bridge/cadence/Makefile | 3 +
.../{cdns-dsi.c => cadence/cdns-dsi-core.c} | 83
.../gpu/drm/bridge/cadence/cdns-dsi-core.h| 84
.../gpu/drm/bridge/cadence/cdns-dsi-j721e.c | 51 +
.../gpu/drm/bridge/cadence/cdns-dsi-j721e.h | 16 ++
10 files changed, 391 insertions(+), 171 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
create mode 100644
Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml
rename drivers/gpu/drm/bridge/{cdns-dsi.c => cadence/cdns-dsi-core.c} (97%)
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-core.h
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-j721e.c
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-j721e.h
Looks good to me. As Andrzej gave his Rb, I presume it's fine for me to
push this to drm-misc-next. I'll do this a bit later today.
There was a small typo in the 5th patch, about which checkpatch gave a
warning. I'll fix that while applying.
Tomi
[PATCH] drm/ttm: fix some minor kerneldoc issues
Pointed out by the kernel test robot while merging ttm_bo_api.h and ttm_bo_driver.h. Signed-off-by: Christian König Reported-by: kernel test robot --- drivers/gpu/drm/ttm/ttm_bo_util.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index d33bff038d3a..77b50875b99f 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c @@ -127,9 +127,8 @@ EXPORT_SYMBOL(ttm_move_memcpy); * ttm_bo_move_memcpy * * @bo: A pointer to a struct ttm_buffer_object. - * @interruptible: Sleep interruptible if waiting. - * @no_wait_gpu: Return immediately if the GPU is busy. - * @new_mem: struct ttm_resource indicating where to move. + * @ctx: operation context + * @dst_mem: struct ttm_resource indicating where to move. * * Fallback move function for a mappable buffer object in mappable memory. * The function will, if successful, @@ -281,8 +280,8 @@ static int ttm_buffer_object_transfer(struct ttm_buffer_object *bo, /** * ttm_io_prot * - * bo: ttm buffer object - * res: ttm resource object + * @bo: ttm buffer object + * @res: ttm resource object * @tmp: Page protection flag for a normal, cached mapping. * * Utility function that returns the pgprot_t that should be used for @@ -621,7 +620,7 @@ static void ttm_bo_move_pipeline_evict(struct ttm_buffer_object *bo, } /** - * ttm_bo_move_accel_cleanup. + * ttm_bo_move_accel_cleanup - cleanup helper for hw copies * * @bo: A pointer to a struct ttm_buffer_object. * @fence: A fence object that signals when moving is complete. @@ -665,7 +664,7 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo, EXPORT_SYMBOL(ttm_bo_move_accel_cleanup); /** - * ttm_bo_move_sync_cleanup. + * ttm_bo_move_sync_cleanup - cleanup by waiting for the move to finish * * @bo: A pointer to a struct ttm_buffer_object. * @new_mem: struct ttm_resource indicating where to move. -- 2.34.1
Re: [PATCH] ACPI: video: Add backlight=native DMI quirk for Acer Aspire 4810T
On Fri, Jan 13, 2023 at 12:41 PM Hans de Goede wrote:
>
> The Acer Aspire 4810T predates Windows 8, so it defaults to using
> acpi_video# for backlight control, but this is non functional on
> this model.
>
> Add a DMI quirk to use the native backlight interface which does
> work properly.
>
> Signed-off-by: Hans de Goede
> ---
> drivers/acpi/video_detect.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
> index d4edd64dcc2f..fb526ba8825b 100644
> --- a/drivers/acpi/video_detect.c
> +++ b/drivers/acpi/video_detect.c
> @@ -515,6 +515,14 @@ static const struct dmi_system_id
> video_detect_dmi_table[] = {
> DMI_MATCH(DMI_PRODUCT_NAME, "Precision 7510"),
> },
> },
> + {
> +.callback = video_detect_force_native,
> +/* Acer Aspire 4810T */
> +.matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 4810T"),
> + },
> + },
> {
> .callback = video_detect_force_native,
> /* Acer Aspire 5738z */
> --
Applied as 6.2-rc material, thanks!
Re: [PATCH] drm/ttm: fix some minor kerneldoc issues
Reviewed-by: Nirmoy Das On 1/17/2023 1:33 PM, Christian König wrote: Pointed out by the kernel test robot while merging ttm_bo_api.h and ttm_bo_driver.h. Signed-off-by: Christian König Reported-by: kernel test robot --- drivers/gpu/drm/ttm/ttm_bo_util.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index d33bff038d3a..77b50875b99f 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c @@ -127,9 +127,8 @@ EXPORT_SYMBOL(ttm_move_memcpy); * ttm_bo_move_memcpy * * @bo: A pointer to a struct ttm_buffer_object. - * @interruptible: Sleep interruptible if waiting. - * @no_wait_gpu: Return immediately if the GPU is busy. - * @new_mem: struct ttm_resource indicating where to move. + * @ctx: operation context + * @dst_mem: struct ttm_resource indicating where to move. * * Fallback move function for a mappable buffer object in mappable memory. * The function will, if successful, @@ -281,8 +280,8 @@ static int ttm_buffer_object_transfer(struct ttm_buffer_object *bo, /** * ttm_io_prot * - * bo: ttm buffer object - * res: ttm resource object + * @bo: ttm buffer object + * @res: ttm resource object * @tmp: Page protection flag for a normal, cached mapping. * * Utility function that returns the pgprot_t that should be used for @@ -621,7 +620,7 @@ static void ttm_bo_move_pipeline_evict(struct ttm_buffer_object *bo, } /** - * ttm_bo_move_accel_cleanup. + * ttm_bo_move_accel_cleanup - cleanup helper for hw copies * * @bo: A pointer to a struct ttm_buffer_object. * @fence: A fence object that signals when moving is complete. @@ -665,7 +664,7 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo, EXPORT_SYMBOL(ttm_bo_move_accel_cleanup); /** - * ttm_bo_move_sync_cleanup. + * ttm_bo_move_sync_cleanup - cleanup by waiting for the move to finish * * @bo: A pointer to a struct ttm_buffer_object. * @new_mem: struct ttm_resource indicating where to move.
Re: [PATCH 7/8] iommu/intel: Support the gfp argument to the map_pages op
On Tue, Jan 17, 2023 at 03:38:51AM +, Tian, Kevin wrote: > > From: Jason Gunthorpe > > Sent: Saturday, January 7, 2023 12:43 AM > > > > @@ -2368,7 +2372,7 @@ static int iommu_domain_identity_map(struct > > dmar_domain *domain, > > > > return __domain_mapping(domain, first_vpfn, > > first_vpfn, last_vpfn - first_vpfn + 1, > > - DMA_PTE_READ|DMA_PTE_WRITE); > > + DMA_PTE_READ|DMA_PTE_WRITE, > > GFP_KERNEL); > > } > > Baolu, can you help confirm whether switching from GFP_ATOMIC to > GFP_KERNEL is OK in this path? it looks fine to me in a quick glance > but want to be conservative here. I checked it carefully myself as well, good to check again. > > @@ -4333,7 +4337,8 @@ static size_t intel_iommu_unmap(struct > > iommu_domain *domain, > > > > /* Cope with horrid API which requires us to unmap more than the > >size argument if it happens to be a large-page mapping. */ > > - BUG_ON(!pfn_to_dma_pte(dmar_domain, iova >> VTD_PAGE_SHIFT, > > &level)); > > + BUG_ON(!pfn_to_dma_pte(dmar_domain, iova >> VTD_PAGE_SHIFT, > > &level, > > + GFP_ATOMIC)); > > with level==0 it implies it's only lookup w/o pgtable allocation. From this > angle it reads better to use a more relaxed gfp e.g. GFP_KERNEL here. We should only write GFP_KERNEL if it is actually a sleepable context because it will be mighty confusing if it isn't. I couldn't tell what the context is so I left it as ATOMIC. You are correct this is only just a lookup and so the value is never used / doesn't matter. Jason
Re: [PATCH 6/8] iommu/intel: Add a gfp parameter to alloc_pgtable_page()
On Tue, Jan 17, 2023 at 03:35:08AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Saturday, January 7, 2023 12:43 AM
> >
> > @@ -2676,7 +2676,7 @@ static int copy_context_table(struct intel_iommu
> > *iommu,
> > if (!old_ce)
> > goto out;
> >
> > - new_ce = alloc_pgtable_page(iommu->node);
> > + new_ce = alloc_pgtable_page(iommu->node,
> > GFP_KERNEL);
>
> GFP_ATOMIC
Can't be:
old_ce = memremap(old_ce_phys, PAGE_SIZE,
MEMREMAP_WB);
if (!old_ce)
goto out;
new_ce = alloc_pgtable_page(iommu->node, GFP_KERNEL);
if (!new_ce)
memremap() is sleeping.
And the only caller is:
ctxt_tbls = kcalloc(ctxt_table_entries, sizeof(void *), GFP_KERNEL);
if (!ctxt_tbls)
goto out_unmap;
for (bus = 0; bus < 256; bus++) {
ret = copy_context_table(iommu, &old_rt[bus],
ctxt_tbls, bus, ext);
Jason
Re: [PATCH v3 0/7] media/drm: renesas: Add new pixel formats
Hi Tomi, (CC'ing Mauro and Hans) On Tue, Jan 10, 2023 at 04:25:37PM +0200, Tomi Valkeinen wrote: > On 26/12/2022 16:56, Laurent Pinchart wrote: > > Hi Tomi, > > > > (CC'ing Daniel and Dave) > > > > On Wed, Dec 21, 2022 at 11:24:41AM +0200, Tomi Valkeinen wrote: > >> From: Tomi Valkeinen > >> > >> Hi, > >> > >> These add new pixel formats for Renesas V3U and V4H SoCs. > >> > >> As the display pipeline is split between DRM and V4L2 components, this > >> series touches both subsystems. I'm sending all these together to > >> simplify review. If needed, I can later split this to V4L2 and DRM > >> parts, of which the V4L2 part needs to be merged first. > > > > As the changes on the DRM side are small and shouldn't conflict with > > anything else queued for v6.3, it would be easier to merge the whole > > series through the media tree. Daniel, Dave, would you be OK with that ? > > If so, could you please ack patches 6/7 and 7/7 ? > > Note that these patches depend on the two DRM driver patches in "[PATCH > v5 0/7] Renesas V4H DSI & DP output support", which are not very small > (but still not big). Good point. I'm thus leaning more towards merging this through the DRM tree then. Mauro, can we get your ack on the V4L2 part of this series ? We'll create a stable branch based on v6.2-rc1 in case it also need to be merged in the media tree due to last minute conflicts (I'm mainly thinking about the new formats). Hans, as there won't be a pull request through the media tree, if you want to review the new formats, now would be a good time. > I don't think there's a compile-time dependency between the DRM and V4L2 > parts, but there's a functional side dependency, so it would be nice to > merge these via a single tree. I can't say if DRM or V4L2 tree is > easier, but I don't expect conflicts either way. -- Regards, Laurent Pinchart
Re: linux-next: duplicate patch in the kspp tree
On Tue, Jan 17, 2023 at 5:02 AM Stephen Rothwell wrote:
>
> Hi all,
>
> The following commit is also in the drm-misc tree as a different commit
> (but the same patch):
>
> 06b19f46455c ("drm/nouveau/fb/ga102: Replace zero-length array of trailing
> structs with flex-array")
>
which branch? Because I just fetched the remote and don't have this
commit in my local repo
> This is commit
>
> 54d47689c6e3 ("drm/nouveau/fb/ga102: Replace zero-length array of trailing
> structs with flex-array")
>
> in the drm-misc tree.
>
> --
> Cheers,
> Stephen Rothwell
Re: [Intel-gfx] [PATCH 1/2] drm/print: Add drm_dbg_ratelimited
Hi, can any of the DRM maintainers please check and eventually ack this patch? On Tue, Jan 17, 2023 at 12:53:49PM +0100, Nirmoy Das wrote: > Add a function for ratelimitted debug print. > > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Thomas Zimmermann > Cc: David Airlie > Cc: Daniel Vetter > Reviewed-by: Matthew Auld > Signed-off-by: Nirmoy Das Reviewed-by: Andi Shyti Thanks, Andi > --- > include/drm/drm_print.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h > index a44fb7ef257f..1d839f507319 100644 > --- a/include/drm/drm_print.h > +++ b/include/drm/drm_print.h > @@ -602,6 +602,9 @@ void __drm_err(const char *format, ...); > drm_dev_printk(drm_ ? drm_->dev : NULL, KERN_DEBUG, fmt, ## > __VA_ARGS__); \ > }) > > +#define drm_dbg_ratelimited(drm, fmt, ...) \ > + __DRM_DEFINE_DBG_RATELIMITED(DRIVER, drm, fmt, ## __VA_ARGS__) > + > #define drm_dbg_kms_ratelimited(drm, fmt, ...) \ > __DRM_DEFINE_DBG_RATELIMITED(KMS, drm, fmt, ## __VA_ARGS__) > > -- > 2.39.0
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Ratelimit debug log in vm_fault_ttm
Hi Nirmoy,
On Tue, Jan 17, 2023 at 12:53:50PM +0100, Nirmoy Das wrote:
> Test like i915_gem_mman_live_selftests/igt_mmap_migrate can cause
> dmesg spamming. Use ratelimit api to reduce log rate.
>
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/7038
> Cc: Matthew Auld
>
> Reviewed-by: Matthew Auld
> Signed-off-by: Nirmoy Das
Reviewed-by: Andi Shyti
Thanks,
Andi
> ---
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index 8cfed1bef629..25294ddbee46 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -1077,8 +1077,9 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
> }
>
> if (err) {
> - drm_dbg(dev, "Unable to make resource CPU
> accessible(err = %pe)\n",
> - ERR_PTR(err));
> + drm_dbg_ratelimited(dev,
> + "Unable to make resource CPU
> accessible(err = %pe)\n",
> + ERR_PTR(err));
> dma_resv_unlock(bo->base.resv);
> ret = VM_FAULT_SIGBUS;
> goto out_rpm;
> --
> 2.39.0
Re: [PATCH v2] drm/i915/selftests: Unwind hugepages to drop wakeref on error
Hi Nirmoy,
On Tue, Jan 17, 2023 at 01:32:34PM +0100, Nirmoy Das wrote:
> From: Chris Wilson
>
> Make sure that upon error after we have acquired the wakeref we do
> release it again.
>
> v2: add another missing "goto out_wf"(Andi).
>
> Fixes: 027c38b4121e ("drm/i915/selftests: Grab the runtime pm in shrink_thp")
> Cc: Andi Shyti
> Reviewed-by: Matthew Auld
> Reviewed-by: Andrzej Hajda
> Signed-off-by: Chris Wilson
> Signed-off-by: Nirmoy Das
Reviewed-by: Andi Shyti
Thanks,
Andi
> ---
> drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> index c281b0ec9e05..defece0bcb81 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> @@ -1855,7 +1855,7 @@ static int igt_shrink_thp(void *arg)
> I915_SHRINK_ACTIVE);
> i915_vma_unpin(vma);
> if (err)
> - goto out_put;
> + goto out_wf;
>
> /*
>* Now that the pages are *unpinned* shrinking should invoke
> @@ -1871,19 +1871,19 @@ static int igt_shrink_thp(void *arg)
> pr_err("unexpected pages mismatch, should_swap=%s\n",
> str_yes_no(should_swap));
> err = -EINVAL;
> - goto out_put;
> + goto out_wf;
> }
>
> if (should_swap == (obj->mm.page_sizes.sg || obj->mm.page_sizes.phys)) {
> pr_err("unexpected residual page-size bits, should_swap=%s\n",
> str_yes_no(should_swap));
> err = -EINVAL;
> - goto out_put;
> + goto out_wf;
> }
>
> err = i915_vma_pin(vma, 0, 0, flags);
> if (err)
> - goto out_put;
> + goto out_wf;
>
> while (n--) {
> err = cpu_check(obj, n, 0xdeadbeaf);
> --
> 2.39.0
Re: [PATCH v4 1/2] backlight: ktz8866: Add support for Kinetic KTZ8866 backlight
On Tue, Jan 17, 2023 at 09:47:41PM +0800, Jianhua Lu wrote:
> Add support for Kinetic KTZ8866 backlight, which is used in
> Xiaomi tablet, Mi Pad 5 series. This driver lightly based on
> downstream implementation [1].
> [1]
> https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/elish-r-oss/drivers/video/backlight/ktz8866.c
>
> Signed-off-by: Jianhua Lu
> ---
> Changes in v2:
> - Add missing staitc modifier to ktz8866_write function.
>
> Changes in v3:
> - Add 2022 to Copyright line.
> - Sort headers.
> - Remove meaningless comment.
> - Use definitions instead of hardcoding.
> - Add missing maintainer info.
>
> Changes in v4:
> - Change 2022 to 2023.
> - Remove useless macro and enum.
> - Describe settings by devicetree.
> - Move header file to C file.
>
> MAINTAINERS | 6 +
> drivers/video/backlight/Kconfig | 8 ++
> drivers/video/backlight/Makefile | 1 +
> drivers/video/backlight/ktz8866.c | 195 ++
> 4 files changed, 210 insertions(+)
> create mode 100644 drivers/video/backlight/ktz8866.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 42fc47c6edfd..2084e74e1b58 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11674,6 +11674,12 @@ M: John Hawley
> S: Maintained
> F: tools/testing/ktest
>
> +KTZ8866 BACKLIGHT DRIVER
> +M: Jianhua Lu
> +S: Maintained
> +F: Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
> +F: drivers/video/backlight/ktz8866.c
> +
> L3MDEV
> M: David Ahern
> L: net...@vger.kernel.org
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index 936ba1e4d35e..2845fd7e33ad 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -190,6 +190,14 @@ config BACKLIGHT_KTD253
> which is a 1-wire GPIO-controlled backlight found in some mobile
> phones.
>
> +config BACKLIGHT_KTZ8866
> + tristate "Backlight Driver for Kinetic KTZ8866"
> + depends on I2C
> + select REGMAP_I2C
> + help
> + Say Y to enabled the backlight driver for the Kinetic KTZ8866
> + found in Xiaomi Mi Pad 5 series.
> +
> config BACKLIGHT_LM3533
> tristate "Backlight Driver for LM3533"
> depends on MFD_LM3533
> diff --git a/drivers/video/backlight/Makefile
> b/drivers/video/backlight/Makefile
> index e815f3f1deff..f70a819c304c 100644
> --- a/drivers/video/backlight/Makefile
> +++ b/drivers/video/backlight/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_BACKLIGHT_HP680) += hp680_bl.o
> obj-$(CONFIG_BACKLIGHT_HP700)+= jornada720_bl.o
> obj-$(CONFIG_BACKLIGHT_IPAQ_MICRO) += ipaq_micro_bl.o
> obj-$(CONFIG_BACKLIGHT_KTD253) += ktd253-backlight.o
> +obj-$(CONFIG_BACKLIGHT_KTZ8866) += ktz8866.o
> obj-$(CONFIG_BACKLIGHT_LM3533) += lm3533_bl.o
> obj-$(CONFIG_BACKLIGHT_LM3630A) += lm3630a_bl.o
> obj-$(CONFIG_BACKLIGHT_LM3639) += lm3639_bl.o
> diff --git a/drivers/video/backlight/ktz8866.c
> b/drivers/video/backlight/ktz8866.c
> new file mode 100644
> index ..98916f92d069
> --- /dev/null
> +++ b/drivers/video/backlight/ktz8866.c
> @@ -0,0 +1,195 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Backlight driver for the Kinetic KTZ8866
> + *
> + * Copyright (C) 2023 Jianhua Lu
Shouldn't this be:
Copyright (C) 2022, 2023 Jianhua Lu
> +static int ktz8866_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct backlight_device *backlight_dev;
> + struct backlight_properties props;
> + struct ktz8866 *ktz;
> +
> + ktz = devm_kzalloc(&client->dev, sizeof(*ktz), GFP_KERNEL);
> + if (!ktz)
> + return -ENOMEM;
> +
> + ktz->client = client;
> + ktz->regmap = devm_regmap_init_i2c(client, &ktz8866_regmap_config);
> +
> + if (IS_ERR(ktz->regmap)) {
> + dev_err(&client->dev, "failed to init regmap\n");
> + return PTR_ERR(ktz->regmap);
> + }
> +
> + memset(&props, 0, sizeof(props));
> + props.type = BACKLIGHT_RAW;
> + props.max_brightness = MAX_BRIGHTNESS;
> + props.brightness = DEFAULT_BRIGHTNESS;
There is still pending feedback from v3.
| Please set the scale property correctly. "Unknown" is never correct for
| new drivers.
Do not ignore feedback. You should either act on it or, if you disagree
or need additional clarification then, reply on the mail thread.
Daniel.
[bug report] habanalabs: add debugfs support
Hello Oded Gabbay,
The patch c216477363a3: "habanalabs: add debugfs support" from Feb
16, 2019, leads to the following Smatch static checker warning:
drivers/accel/habanalabs/common/debugfs.c:272 vm_show()
warn: sleeping in atomic context
drivers/accel/habanalabs/common/debugfs.c
241 static int vm_show(struct seq_file *s, void *data)
242 {
243 struct hl_debugfs_entry *entry = s->private;
244 struct hl_dbg_device_entry *dev_entry = entry->dev_entry;
245 struct hl_vm_hw_block_list_node *lnode;
246 struct hl_ctx *ctx;
247 struct hl_vm *vm;
248 struct hl_vm_hash_node *hnode;
249 struct hl_userptr *userptr;
250 struct hl_vm_phys_pg_pack *phys_pg_pack = NULL;
251 struct hl_va_range *va_range;
252 struct hl_vm_va_block *va_block;
253 enum vm_type *vm_type;
254 bool once = true;
255 u64 j;
256 int i;
257
258 if (!dev_entry->hdev->mmu_enable)
259 return 0;
260
261 spin_lock(&dev_entry->ctx_mem_hash_spinlock);
This is holding a spinlock.
262
263 list_for_each_entry(ctx, &dev_entry->ctx_mem_hash_list,
debugfs_list) {
264 once = false;
265 seq_puts(s,
"\n\n");
266 seq_puts(s,
"\n\n\n");
267 seq_printf(s, "ctx asid: %u\n", ctx->asid);
268
269 seq_puts(s, "\nmappings:\n\n");
270 seq_puts(s, "virtual addresssize
handle\n");
271 seq_puts(s,
"\n");
--> 272 mutex_lock(&ctx->mem_hash_lock);
^^^
so it can't take a mutex or it leads to a sleeping in atomic bug. These
can be detected at runtime by enabling CONFIG_DEBUG_ATOMIC_SLEEP.
regards,
dan carpenter
Re: [PATCH v4 2/2] dt-bindings: leds: backlight: Add Kinetic KTZ8866 backlight
On Tue, Jan 17, 2023 at 09:47:42PM +0800, Jianhua Lu wrote: > Add Kinetic KTZ8866 backlight binding documentation. > > Signed-off-by: Jianhua Lu Might be a good idea to take a look at this bit of the docs because the patchset is not in the right order (I.5): https://docs.kernel.org/devicetree/bindings/submitting-patches.html > --- > Changes in v2: > - Remove "items" between "compatible" and "const: kinetic,ktz8866" > - Change "additionalProperties" to "unevaluatedProperties" > > Changes in v3: > - Add Krzysztof's R-b > > Changes in v4: > - Drop Krzysztof's R-b > - Add some new properties > > .../leds/backlight/kinetic,ktz8866.yaml | 54 +++ > 1 file changed, 54 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml > > diff --git > a/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml > b/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml > new file mode 100644 > index ..18571d69accb > --- /dev/null > +++ b/Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml > @@ -0,0 +1,54 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/leds/backlight/kinetic,ktz8866.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Kinetic Technologies KTZ8866 backlight > + > +maintainers: > + - Jianhua Lu > + > +description: | > + The Kinetic Technologies KTZ8866 is a high efficiency 6-sinks led backlight > + with dual lcd bias power. > + https://www.kinet-ic.com/ktz8866/ > + > +allOf: > + - $ref: common.yaml# > + > +properties: > + compatible: > +const: kinetic,ktz8866 > + > + current-num-sinks: > +description: Number of LED current sinks. > + > + current-ramping-time: > +description: LED current ramping time. Needs to document know what units this value is expressed in. IIRC this should be expressed in SI units and included the property name. Something like: current-ramping-time-us: description: LED current ramping time in microseconds. > + > + led-ramping-time: > +description: LED on/off ramping time. +1 Daniel.
Re: [PATCH 3/3] drm/amdgpu/vcn: Add parameter to force (en/dis)abling indirect SRAM mode
On 16/01/2023 23:33, Limonciello, Mario wrote: > [...] > > For debugging these type of problems, I think an effective debugging > tactic would have been to mask the IP block (amdgpu.ip_block_mask). Thank you, it worked indeed - nice suggestion! Though I see two problems with that: first, I'm not sure what's the impact in the GPU functioning when I disable some IP block. Second, the parameter is a bit hard to figure - we need to clear a bit for the IP block we want to disable, and the doc suggest to read on dmesg to get this information (it seems it changes depending on the HW model), but I couldn't parse the proper bit from dmesg. Needed to instrument the kernel to find the proper bit heh The second part is easy to improve (we can just show this bit in dmesg!), I might do that instead of proposing this parameter, which seems didn't raise much excitement after all heheh Finally, I'm still curious on why Deck was working fine with the indirect SRAM mode disabled (by mistake) in many kernels - was it in practice the same as disabling the VCN IP block? Thanks, Guilherme
Re: [PATCH v4 1/2] backlight: ktz8866: Add support for Kinetic KTZ8866 backlight
On Tue, Jan 17, 2023 at 10:12:18PM +0800, Jianhua Lu wrote:
> On Tue, Jan 17, 2023 at 02:04:05PM +, Daniel Thompson wrote:
> > On Tue, Jan 17, 2023 at 09:47:41PM +0800, Jianhua Lu wrote:
> > > Add support for Kinetic KTZ8866 backlight, which is used in
> > > Xiaomi tablet, Mi Pad 5 series. This driver lightly based on
> > > downstream implementation [1].
> > > [1]
> > > https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/elish-r-oss/drivers/video/backlight/ktz8866.c
> > >
> > > Signed-off-by: Jianhua Lu
> > > ---
> > > Changes in v2:
> > > - Add missing staitc modifier to ktz8866_write function.
> > >
> > > Changes in v3:
> > > - Add 2022 to Copyright line.
> > > - Sort headers.
> > > - Remove meaningless comment.
> > > - Use definitions instead of hardcoding.
> > > - Add missing maintainer info.
> > >
> > > Changes in v4:
> > > - Change 2022 to 2023.
> > > - Remove useless macro and enum.
> > > - Describe settings by devicetree.
> > > - Move header file to C file.
> > >
> > > MAINTAINERS | 6 +
> > > drivers/video/backlight/Kconfig | 8 ++
> > > drivers/video/backlight/Makefile | 1 +
> > > drivers/video/backlight/ktz8866.c | 195 ++
> > > 4 files changed, 210 insertions(+)
> > > create mode 100644 drivers/video/backlight/ktz8866.c
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 42fc47c6edfd..2084e74e1b58 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -11674,6 +11674,12 @@ M: John Hawley
> > > S: Maintained
> > > F: tools/testing/ktest
> > >
> > > +KTZ8866 BACKLIGHT DRIVER
> > > +M: Jianhua Lu
> > > +S: Maintained
> > > +F:
> > > Documentation/devicetree/bindings/leds/backlight/kinetic,ktz8866.yaml
> > > +F: drivers/video/backlight/ktz8866.c
> > > +
> > > L3MDEV
> > > M: David Ahern
> > > L: net...@vger.kernel.org
> > > diff --git a/drivers/video/backlight/Kconfig
> > > b/drivers/video/backlight/Kconfig
> > > index 936ba1e4d35e..2845fd7e33ad 100644
> > > --- a/drivers/video/backlight/Kconfig
> > > +++ b/drivers/video/backlight/Kconfig
> > > @@ -190,6 +190,14 @@ config BACKLIGHT_KTD253
> > > which is a 1-wire GPIO-controlled backlight found in some mobile
> > > phones.
> > >
> > > +config BACKLIGHT_KTZ8866
> > > + tristate "Backlight Driver for Kinetic KTZ8866"
> > > + depends on I2C
> > > + select REGMAP_I2C
> > > + help
> > > + Say Y to enabled the backlight driver for the Kinetic KTZ8866
> > > + found in Xiaomi Mi Pad 5 series.
> > > +
> > > config BACKLIGHT_LM3533
> > > tristate "Backlight Driver for LM3533"
> > > depends on MFD_LM3533
> > > diff --git a/drivers/video/backlight/Makefile
> > > b/drivers/video/backlight/Makefile
> > > index e815f3f1deff..f70a819c304c 100644
> > > --- a/drivers/video/backlight/Makefile
> > > +++ b/drivers/video/backlight/Makefile
> > > @@ -36,6 +36,7 @@ obj-$(CONFIG_BACKLIGHT_HP680) += hp680_bl.o
> > > obj-$(CONFIG_BACKLIGHT_HP700)+= jornada720_bl.o
> > > obj-$(CONFIG_BACKLIGHT_IPAQ_MICRO) += ipaq_micro_bl.o
> > > obj-$(CONFIG_BACKLIGHT_KTD253) += ktd253-backlight.o
> > > +obj-$(CONFIG_BACKLIGHT_KTZ8866) += ktz8866.o
> > > obj-$(CONFIG_BACKLIGHT_LM3533) += lm3533_bl.o
> > > obj-$(CONFIG_BACKLIGHT_LM3630A) += lm3630a_bl.o
> > > obj-$(CONFIG_BACKLIGHT_LM3639) += lm3639_bl.o
> > > diff --git a/drivers/video/backlight/ktz8866.c
> > > b/drivers/video/backlight/ktz8866.c
> > > new file mode 100644
> > > index ..98916f92d069
> > > --- /dev/null
> > > +++ b/drivers/video/backlight/ktz8866.c
> > > @@ -0,0 +1,195 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * Backlight driver for the Kinetic KTZ8866
> > > + *
> > > + * Copyright (C) 2023 Jianhua Lu
> >
> > Shouldn't this be:
> > Copyright (C) 2022, 2023 Jianhua Lu
> >
> > > +static int ktz8866_probe(struct i2c_client *client,
> > > + const struct i2c_device_id *id)
> > > +{
> > > + struct backlight_device *backlight_dev;
> > > + struct backlight_properties props;
> > > + struct ktz8866 *ktz;
> > > +
> > > + ktz = devm_kzalloc(&client->dev, sizeof(*ktz), GFP_KERNEL);
> > > + if (!ktz)
> > > + return -ENOMEM;
> > > +
> > > + ktz->client = client;
> > > + ktz->regmap = devm_regmap_init_i2c(client, &ktz8866_regmap_config);
> > > +
> > > + if (IS_ERR(ktz->regmap)) {
> > > + dev_err(&client->dev, "failed to init regmap\n");
> > > + return PTR_ERR(ktz->regmap);
> > > + }
> > > +
> > > + memset(&props, 0, sizeof(props));
> > > + props.type = BACKLIGHT_RAW;
> > > + props.max_brightness = MAX_BRIGHTNESS;
> > > + props.brightness = DEFAULT_BRIGHTNESS;
> >
> > There is still pending feedback from v3.
> >
> > | Please set the scale property correctly. "Unknown" is never correct for
> > | new drivers.
> Do you means backlight_properties.backlight_scale?
props.scale = BACKL
Re: [PATCH v3 2/3] drm/amdgpu: Remove redundant framebuffer format check
Hi Simon, On 1/13/23 14:06, Simon Ser wrote: Hm, unfortunately I think we need to keep the check in amdgpu for the same reason as i915: amdgpu will pick a modifier if user-space didn't supply one on GFX9+. I wonder if that also applies to vmwgfx? Maybe that would be a reason to have the check in framebuffer_init()? (Not sure!) I tried to move the check to framebuffer_init(), but it ended up causing problems in the i915 driver (the kernel was emitting warnings when running the IGT tests). I was thinking of going back to the drm_gem_fb_create() approach [1], as it would make the other drivers return EINVAL in the case of a bad modifier and it wouldn't change the current behavior of i915 and amdgpu. [1] https://lore.kernel.org/dri-devel/20230103125322.855089-1-mca...@igalia.com/T/ Best Regards, - Maíra Canal
Re: [PATCH 1/2] drm/print: Add drm_dbg_ratelimited
Hi Nirmoy On Tue, Jan 17, 2023 at 12:53:49PM +0100, Nirmoy Das wrote: > Add a function for ratelimitted debug print. > > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Thomas Zimmermann > Cc: David Airlie > Cc: Daniel Vetter > Reviewed-by: Matthew Auld > Signed-off-by: Nirmoy Das Thanks for adding this. The patch as-is is: Reviewed-by: Sam Ravnborg It would have been nice to start adding kernel-doc to the non-deprecated logging functions. But as everyone else is missing this, it is OK that we miss it here. A couple of nice follow-up patches would be to introduce a KMS variant and replace the only user of DRM_DEBUG_KMS_RATELIMITED with the new variant and remove the old one. And maybe even update the remaining *ERROR_RATELIMITED users to a new variant - and drop the deprecated ones. Sam > --- > include/drm/drm_print.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h > index a44fb7ef257f..1d839f507319 100644 > --- a/include/drm/drm_print.h > +++ b/include/drm/drm_print.h > @@ -602,6 +602,9 @@ void __drm_err(const char *format, ...); > drm_dev_printk(drm_ ? drm_->dev : NULL, KERN_DEBUG, fmt, ## > __VA_ARGS__); \ > }) > > +#define drm_dbg_ratelimited(drm, fmt, ...) \ > + __DRM_DEFINE_DBG_RATELIMITED(DRIVER, drm, fmt, ## __VA_ARGS__) > + > #define drm_dbg_kms_ratelimited(drm, fmt, ...) \ > __DRM_DEFINE_DBG_RATELIMITED(KMS, drm, fmt, ## __VA_ARGS__) > > -- > 2.39.0
Re: [PATCH v3 8/8] arm64: tegra: Add simple framebuffer on Jetson Xavier NX
Hi
Am 17.11.22 um 19:40 schrieb Thierry Reding:
From: Thierry Reding
Add the framebuffer carveout reserved memory node as well as a simple-
framebuffer node that is used to bind to the framebuffer that the
bootloader has set up.
I don't know about the current status of this patchset, but feel free to
send whatever update you have.
Best regards
Thomas
Signed-off-by: Thierry Reding
---
Changes in v2:
- clear out dynamic fields and leave it up to firmware to fill them in
- mark simple-framebuffer node as disabled by default
.../nvidia/tegra194-p3509-+p3668-0001.dts | 43 +++
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 2 +-
2 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p3509-+p3668-0001.dts
b/arch/arm64/boot/dts/nvidia/tegra194-p3509-+p3668-0001.dts
index 238fd98e8e45..85b4aaa2ad4e 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194-p3509-+p3668-0001.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra194-p3509-+p3668-0001.dts
@@ -7,4 +7,47 @@
/ {
model = "NVIDIA Jetson Xavier NX Developer Kit (eMMC)";
compatible = "nvidia,p3509-+p3668-0001", "nvidia,tegra194";
+
+ chosen {
+ framebuffer {
+ compatible = "simple-framebuffer";
+ status = "disabled";
+ memory-region = <&fb>;
+ power-domains = <&bpmp TEGRA194_POWER_DOMAIN_DISP>;
+ clocks = <&bpmp TEGRA194_CLK_SOR1_REF>,
+<&bpmp TEGRA194_CLK_SOR1_OUT>,
+<&bpmp TEGRA194_CLK_SOR1_PAD_CLKOUT>,
+<&bpmp TEGRA194_CLK_PLLD2>,
+<&bpmp TEGRA194_CLK_PLLDP>,
+<&bpmp TEGRA194_CLK_NVDISPLAY_DISP>,
+<&bpmp TEGRA194_CLK_NVDISPLAYHUB>,
+<&bpmp TEGRA194_CLK_NVDISPLAY_P0>;
+ width = <0>;
+ height = <0>;
+ stride = <0>;
+ format = "x8b8g8r8";
+ };
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ fb: framebuffer@0,0 {
+ compatible = "framebuffer";
+ reg = <0x0 0x0 0x0 0x0>;
+ iommu-addresses = <&dc0 0x0 0x0 0x0 0x0>;
+ };
+ };
+
+ bus@0 {
+ host1x@13e0 {
+ display-hub@1520 {
+ display@1520 {
+ memory-region = <&fb>;
+ };
+ };
+ };
+ };
};
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index d0dbfafbc930..ec318b9e700c 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -1972,7 +1972,7 @@ display-hub@1520 {
ranges = <0x1520 0x1520 0x4>;
-display@1520 {
+ dc0: display@1520 {
compatible = "nvidia,tegra194-dc";
reg = <0x1520 0x1>;
interrupts = ;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH 1/2] drm/print: Add drm_dbg_ratelimited
Hi Sam, On 1/17/2023 3:49 PM, Sam Ravnborg wrote: Hi Nirmoy On Tue, Jan 17, 2023 at 12:53:49PM +0100, Nirmoy Das wrote: Add a function for ratelimitted debug print. Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Reviewed-by: Matthew Auld Signed-off-by: Nirmoy Das Thanks for adding this. The patch as-is is: Reviewed-by: Sam Ravnborg It would have been nice to start adding kernel-doc to the non-deprecated logging functions. But as everyone else is missing this, it is OK that we miss it here. A couple of nice follow-up patches would be to introduce a KMS variant and replace the only user of DRM_DEBUG_KMS_RATELIMITED with the new variant and remove the old one. And maybe even update the remaining *ERROR_RATELIMITED users to a new variant - and drop the deprecated ones. Thanks for reviewing this. I can definitely work on your suggested follow-up patches. Nirmoy Sam --- include/drm/drm_print.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h index a44fb7ef257f..1d839f507319 100644 --- a/include/drm/drm_print.h +++ b/include/drm/drm_print.h @@ -602,6 +602,9 @@ void __drm_err(const char *format, ...); drm_dev_printk(drm_ ? drm_->dev : NULL, KERN_DEBUG, fmt, ## __VA_ARGS__);\ }) +#define drm_dbg_ratelimited(drm, fmt, ...) \ + __DRM_DEFINE_DBG_RATELIMITED(DRIVER, drm, fmt, ## __VA_ARGS__) + #define drm_dbg_kms_ratelimited(drm, fmt, ...) \ __DRM_DEFINE_DBG_RATELIMITED(KMS, drm, fmt, ## __VA_ARGS__) -- 2.39.0
Re: [PATCH 3/3] drm/amdgpu/vcn: Add parameter to force (en/dis)abling indirect SRAM mode
On Tue, Jan 17, 2023 at 9:33 AM Guilherme G. Piccoli wrote: > > On 16/01/2023 23:33, Limonciello, Mario wrote: > > [...] > > > > For debugging these type of problems, I think an effective debugging > > tactic would have been to mask the IP block (amdgpu.ip_block_mask). > > Thank you, it worked indeed - nice suggestion! > > Though I see two problems with that: first, I'm not sure what's the > impact in the GPU functioning when I disable some IP block. > > Second, the parameter is a bit hard to figure - we need to clear a bit > for the IP block we want to disable, and the doc suggest to read on > dmesg to get this information (it seems it changes depending on the HW > model), but I couldn't parse the proper bit from dmesg. Needed to > instrument the kernel to find the proper bit heh > > The second part is easy to improve (we can just show this bit in > dmesg!), I might do that instead of proposing this parameter, which > seems didn't raise much excitement after all heheh > > Finally, I'm still curious on why Deck was working fine with the > indirect SRAM mode disabled (by mistake) in many kernels - was it in > practice the same as disabling the VCN IP block? IIRC, it depends on the fuse recipe for the particular ASIC. Alex > > Thanks, > > > Guilherme >
[Bug 216917] hibernation regression since 6.0.18 (Ryzen-5650U incl. Radeon GPU)
https://bugzilla.kernel.org/show_bug.cgi?id=216917
--- Comment #25 from Rainer Fiebig (j...@mailbox.org) ---
(In reply to Alex Deucher from comment #23)
> I'll just revert it. It is more important for kernels with the the
> drm_buddy changes.
Would the following be equivalent to what you intended with your commit?
Looks a bit awkward but hibernate/resume work with it for 6.0.19 (and a Ryzen
5600G):
uint32_t amdgpu_bo_get_preferred_domain(struct amdgpu_device *adev,
uint32_t domain)
{
if (domain == (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT)) {
domain = AMDGPU_GEM_DOMAIN_VRAM;
if ((adev->asic_type == CHIP_CARRIZO) || (adev->asic_type ==
CHIP_STONEY)) {
if (adev->gmc.real_vram_size <= AMDGPU_SG_THRESHOLD)
domain = AMDGPU_GEM_DOMAIN_GTT;
}
}
return domain;
}
Let me know whether this is worth persuing. I could then test it with 5.15.88
and 6.1.6.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
[Bug 216917] hibernation regression since 6.0.18 (Ryzen-5650U incl. Radeon GPU)
https://bugzilla.kernel.org/show_bug.cgi?id=216917
--- Comment #26 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Rainer Fiebig from comment #25)
> (In reply to Alex Deucher from comment #23)
> > I'll just revert it. It is more important for kernels with the the
> > drm_buddy changes.
>
> Would the following be equivalent to what you intended with your commit?
> Looks a bit awkward but hibernate/resume work with it for 6.0.19 (and a
> Ryzen 5600G):
>
>
> uint32_t amdgpu_bo_get_preferred_domain(struct amdgpu_device *adev,
> uint32_t domain)
> {
> if (domain == (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT)) {
> domain = AMDGPU_GEM_DOMAIN_VRAM;
> if ((adev->asic_type == CHIP_CARRIZO) || (adev->asic_type ==
> CHIP_STONEY))
> {
> if (adev->gmc.real_vram_size <= AMDGPU_SG_THRESHOLD)
> domain = AMDGPU_GEM_DOMAIN_GTT;
> }
> }
> return domain;
> }
>
>
> Let me know whether this is worth persuing. I could then test it with
> 5.15.88 and 6.1.6.
Nope. What my patch does is allow display buffers to be in either system
memory (GTT) or carve out (VRAM) depending on what is available. Without the
patch, the driver picks either VRAM or GTT depending on how much VRAM is
available on the system. This can lead to memory exhaustion in some cases with
multiple large resolution monitors depending on memory fragmentation.
What your patch does is just always use VRAM unless the chip is Carrizo or
Stoney. So it is effectively just reverting the commit (depending on how much
VRAM your system has).
--
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 2/6] drm: rcar-du: lvds: Add reset control
Hi Tomi,
On Tue, Jan 17, 2023 at 2:54 PM Tomi Valkeinen
wrote:
> From: Koji Matsuoka
>
> Reset LVDS using the reset control as CPG reset/release is required in
> H/W manual sequence.
>
> Signed-off-by: Koji Matsuoka
> Signed-off-by: LUU HOAI
> [tomi.valkeinen: Rewrite the patch description]
> Signed-off-by: Tomi Valkeinen
Thanks for your patch!
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -844,6 +853,12 @@ static int rcar_lvds_probe(struct platform_device *pdev)
> if (ret < 0)
> return ret;
>
> + lvds->rstc = devm_reset_control_get(&pdev->dev, NULL);
devm_reset_control_get_exclusive()
> + if (IS_ERR(lvds->rstc)) {
> + dev_err(&pdev->dev, "failed to get cpg reset\n");
> + return PTR_ERR(lvds->rstc);
return dev_err_probe(...);
> + }
> +
> drm_bridge_add(&lvds->bridge);
>
> return 0;
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
Re: [RFC 04/12] drm/cgroup: Track clients per owning process
Hi
On Thu, Jan 12, 2023 at 04:56:01PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> To enable propagation of settings from the cgroup drm controller to drm we
> need to start tracking which processes own which drm clients.
>
> Implement that by tracking the struct pid pointer of the owning process in
> a new XArray, pointing to a structure containing a list of associated
> struct drm_file pointers.
>
> Clients are added and removed under the filelist mutex and RCU list
> operations are used below it to allow for lockless lookup.
>
> Signed-off-by: Tvrtko Ursulin
> +int drm_clients_open(struct drm_file *file_priv)
> +{
> + struct drm_device *dev = file_priv->minor->dev;
> + struct drm_pid_clients *clients;
> + bool new_client = false;
> + unsigned long pid;
> +
> + lockdep_assert_held(&dev->filelist_mutex);
> +
> + pid = (unsigned long)rcu_access_pointer(file_priv->pid);
> + clients = xa_load(&drm_pid_clients, pid);
> + if (!clients) {
> + clients = __alloc_clients();
> + if (!clients)
> + return -ENOMEM;
> + new_client = true;
> + }
> + atomic_inc(&clients->num);
> + list_add_tail_rcu(&file_priv->clink, &clients->file_list);
> + if (new_client) {
> + void *xret;
> +
> + xret = xa_store(&drm_pid_clients, pid, clients, GFP_KERNEL);
> + if (xa_err(xret)) {
> + list_del_init(&file_priv->clink);
> + kfree(clients);
> + return PTR_ERR(clients);
This looks incorrect, rather xa_err(xret) should be returned.
Regards
Stanislaw
Re: [PATCH v2] drm/i915/selftests: Unwind hugepages to drop wakeref on error
|Reviewed-by: Nirmoy Das |
On 1/17/2023 1:32 PM, Nirmoy Das wrote:
From: Chris Wilson
Make sure that upon error after we have acquired the wakeref we do
release it again.
v2: add another missing "goto out_wf"(Andi).
Fixes: 027c38b4121e ("drm/i915/selftests: Grab the runtime pm in shrink_thp")
Cc: Andi Shyti
Reviewed-by: Matthew Auld
Reviewed-by: Andrzej Hajda
Signed-off-by: Chris Wilson
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index c281b0ec9e05..defece0bcb81 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1855,7 +1855,7 @@ static int igt_shrink_thp(void *arg)
I915_SHRINK_ACTIVE);
i915_vma_unpin(vma);
if (err)
- goto out_put;
+ goto out_wf;
/*
* Now that the pages are *unpinned* shrinking should invoke
@@ -1871,19 +1871,19 @@ static int igt_shrink_thp(void *arg)
pr_err("unexpected pages mismatch, should_swap=%s\n",
str_yes_no(should_swap));
err = -EINVAL;
- goto out_put;
+ goto out_wf;
}
if (should_swap == (obj->mm.page_sizes.sg || obj->mm.page_sizes.phys)) {
pr_err("unexpected residual page-size bits, should_swap=%s\n",
str_yes_no(should_swap));
err = -EINVAL;
- goto out_put;
+ goto out_wf;
}
err = i915_vma_pin(vma, 0, 0, flags);
if (err)
- goto out_put;
+ goto out_wf;
while (n--) {
err = cpu_check(obj, n, 0xdeadbeaf);
Re: [PATCH 4/6] drm: rcar-du: Add quirk for H3 ES1 pclk WA
Hi Tomi,
On Tue, Jan 17, 2023 at 2:54 PM Tomi Valkeinen
wrote:
> rcar_du_crtc.c does a soc_device_match() in
> rcar_du_crtc_set_display_timing() to find out if the SoC is H3 ES1, and
> if so, apply a WA.
>
> We will need another H3 ES1 check in the following patch, so rather than
> adding more soc_device_match() calls, let's add a rcar_du_device_info
> entry for the ES1, and a quirk flag,
> RCAR_DU_QUIRK_H3_ES1_PCLK_STABILITY, for the WA.
>
> Signed-off-by: Tomi Valkeinen
Thanks for your patch!
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -681,7 +724,13 @@ static int rcar_du_probe(struct platform_device *pdev)
> return PTR_ERR(rcdu);
>
> rcdu->dev = &pdev->dev;
> - rcdu->info = of_device_get_match_data(rcdu->dev);
No need to remove this line...
> +
> + soc_attr = soc_device_match(rcar_du_soc_table);
> + if (soc_attr)
> + rcdu->info = soc_attr->data;
> +
> + if (!rcdu->info)
> + rcdu->info = of_device_get_match_data(rcdu->dev);
... and no need to add these two lines.
The idiom is to set rcdu->info based on of_device_get_match_data()
first, and override based on of_device_get_match_data() when needed.
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
Re: [Intel-gfx] [RFC PATCH 00/20] Initial Xe driver submission
On Thu, Dec 22, 2022 at 4:29 PM Matthew Brost wrote: > Hello, > > This is a submission for Xe, a new driver for Intel GPUs that supports both > integrated and discrete platforms starting with Tiger Lake (first platform > with > Intel Xe Architecture). The intention of this new driver is to have a > fresh base > to work from that is unencumbered by older platforms, whilst also taking > the > opportunity to rearchitect our driver to increase sharing across the drm > subsystem, both leveraging and allowing us to contribute more towards other > shared components like TTM and drm/scheduler. The memory model is based on > VM > bind which is similar to the i915 implementation. Likewise the execbuf > implementation for Xe is very similar to execbuf3 in the i915 [1]. > > The code is at a stage where it is already functional and has experimental > support for multiple platforms starting from Tiger Lake, with initial > support > implemented in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as > well > as in NEO (for OpenCL and Level0). A Mesa MR has been posted [2] and NEO > implementation will be released publicly early next year. We also have a > suite > of IGTs for XE that will appear on the IGT list shortly. > > It has been built with the assumption of supporting multiple architectures > from > the get-go, right now with tests running both on X86 and ARM hosts. And we > intend to continue working on it and improving on it as part of the kernel > community upstream. > > The new Xe driver leverages a lot from i915 and work on i915 continues as > we > ready Xe for production throughout 2023. > > As for display, the intent is to share the display code with the i915 > driver so > that there is maximum reuse there. Currently this is being done by > compiling the > display code twice, but alternatives to that are under consideration and > we want > to have more discussion on what the best final solution will look like > over the > next few months. Right now, work is ongoing in refactoring the display > codebase > to remove as much as possible any unnecessary dependencies on i915 > specific data > structures there.. > > We currently have 2 submission backends, execlists and GuC. The execlist is > meant mostly for testing and is not fully functional while GuC backend is > fully > functional. As with the i915 and GuC submission, in Xe the GuC firmware is > required and should be placed in /lib/firmware/xe. > > The GuC firmware can be found in the below location: > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915 > > The easiest way to setup firmware is: > cp -r /lib/firmware/i915 /lib/firmware/xe > > The code has been organized such that we have all patches that touch areas > outside of drm/xe first for review, and then the actual new driver in a > separate > commit. The code which is outside of drm/xe is included in this RFC while > drm/xe is not due to the size of the commit. The drm/xe is code is > available in > a public repo listed below. > > Xe driver commit: > > https://cgit.freedesktop.org/drm/drm-xe/commit/?h=drm-xe-next&id=9cb016ebbb6a275f57b1cb512b95d5a842391ad7 Drive-by comment here because I don't see any actual xe patches on the list: You probably want to drop DRM_XE_SYNC_DMA_BUF from the uAPI. Now that we've landed the new dma-buf ioctls for sync_file import/export, there's really no reason to have it as part of submit. Dropping it should also make locking a tiny bit easier. --Jason > Xe kernel repo: > https://cgit.freedesktop.org/drm/drm-xe/ > > There's a lot of work still to happen on Xe but we're very excited about > it and > wanted to share it early and welcome feedback and discussion. > > Cheers, > Matthew Brost > > [1] https://patchwork.freedesktop.org/series/105879/ > [2] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20418 > > Maarten Lankhorst (12): > drm/amd: Convert amdgpu to use suballocation helper. > drm/radeon: Use the drm suballocation manager implementation. > drm/i915: Remove gem and overlay frontbuffer tracking > drm/i915/display: Neuter frontbuffer tracking harder > drm/i915/display: Add more macros to remove all direct calls to uncore > drm/i915/display: Remove all uncore mmio accesses in favor of intel_de > drm/i915: Rename find_section to find_bdb_section > drm/i915/regs: Set DISPLAY_MMIO_BASE to 0 for xe > drm/i915/display: Fix a use-after-free when intel_edp_init_connector > fails > drm/i915/display: Remaining changes to make xe compile > sound/hda: Allow XE as i915 replacement for sound > mei/hdcp: Also enable for XE > > Matthew Brost (5): > drm/sched: Convert drm scheduler to use a work queue rather than > kthread > drm/sched: Add generic scheduler message interface > drm/sched: Start run wq before TDR in drm_sched_start > drm/sched: Submit job before starting TDR > drm/sched: Add helper to set TDR timeout > > Thomas Hellström (3): > drm/suballoc: Introduce a generic su
[PATCH 0/3] Allow composer fallbacks for color features
This series will enable color features on sc7280 target which has primary panel as eDP The series removes dspp allocation based on encoder type and allows the datapath reservation even if dspps are not available. The series also adds a check to fail the composition during atomic check , if color management is requested and no dspps are allocated in the datapath. This can allow composer fallbacks for color features if no relevant HW blocks are available. Kalyan Thota (3): drm/msm/disp/dpu1: allow reservation even if dspps are not available. drm/msm/disp/dpu1: allow dspp selection for all the interfaces drm/msm/disp/dpu1: fail atomic check if color feature is requested with no dspp drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 11 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 18 +- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 8 +++- 3 files changed, 27 insertions(+), 10 deletions(-) -- 2.7.4
[PATCH 1/3] drm/msm/disp/dpu1: allow reservation even if dspps are not available.
if any topology requests for dspps and catalogue doesn't have the
allocation, avoid failing the reservation.
This can pave way to build logic allowing composer fallbacks
for all the color features that are handled in dspp.
Signed-off-by: Kalyan Thota
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 73b3442..c8899ae 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -343,7 +343,13 @@ static bool _dpu_rm_check_lm_and_get_connected_blks(struct
dpu_rm *rm,
return true;
idx = lm_cfg->dspp - DSPP_0;
- if (idx < 0 || idx >= ARRAY_SIZE(rm->dspp_blks)) {
+
+ if (idx < 0) {
+ DPU_DEBUG("lm doesn't have dspp, ignoring the request %d\n",
lm_cfg->dspp);
+ return true;
+ }
+
+ if (idx >= ARRAY_SIZE(rm->dspp_blks)) {
DPU_ERROR("failed to get dspp on lm %d\n", lm_cfg->dspp);
return false;
}
--
2.7.4
[PATCH 2/3] drm/msm/disp/dpu1: allow dspp selection for all the interfaces
Allow dspps to be populated as a requirement for all the encoder
types it need not be just DSI. If for any encoder the dspp
allocation doesn't go through then there can be an option to
fallback for color features.
Signed-off-by: Kalyan Thota
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 9c6817b..e39b345 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -545,7 +545,8 @@ bool dpu_encoder_use_dsc_merge(struct drm_encoder *drm_enc)
static struct msm_display_topology dpu_encoder_get_topology(
struct dpu_encoder_virt *dpu_enc,
struct dpu_kms *dpu_kms,
- struct drm_display_mode *mode)
+ struct drm_display_mode *mode,
+ struct drm_crtc_state *crtc_state)
{
struct msm_display_topology topology = {0};
int i, intf_count = 0;
@@ -563,8 +564,9 @@ static struct msm_display_topology dpu_encoder_get_topology(
* 1 LM, 1 INTF
* 2 LM, 1 INTF (stream merge to support high resolution interfaces)
*
-* Adding color blocks only to primary interface if available in
-* sufficient number
+* dspp blocks are made optional. If RM manager cannot allocate
+* dspp blocks, then reservations will still go through with non dspp
LM's
+* so as to allow color management support via composer fallbacks
*/
if (intf_count == 2)
topology.num_lm = 2;
@@ -573,11 +575,9 @@ static struct msm_display_topology
dpu_encoder_get_topology(
else
topology.num_lm = (mode->hdisplay > MAX_HDISPLAY_SPLIT) ? 2 : 1;
- if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI) {
- if (dpu_kms->catalog->dspp &&
- (dpu_kms->catalog->dspp_count >= topology.num_lm))
- topology.num_dspp = topology.num_lm;
- }
+ if (dpu_kms->catalog->dspp &&
+ (dpu_kms->catalog->dspp_count >= topology.num_lm))
+ topology.num_dspp = topology.num_lm;
topology.num_enc = 0;
topology.num_intf = intf_count;
@@ -643,7 +643,7 @@ static int dpu_encoder_virt_atomic_check(
}
}
- topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode);
+ topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode,
crtc_state);
/* Reserve dynamic resources now. */
if (!ret) {
--
2.7.4
[PATCH 3/3] drm/msm/disp/dpu1: fail atomic check if color feature is requested with no dspp
Fail atomic check if any color feature is requested with no
dspps allocated in the datapath so that composer can offload those
features.
Signed-off-by: Kalyan Thota
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 4170fbe..de8d799 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1147,6 +1147,7 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
int left_zpos_cnt = 0, right_zpos_cnt = 0;
struct drm_rect crtc_rect = { 0 };
bool needs_dirtyfb = dpu_crtc_needs_dirtyfb(crtc_state);
+ struct dpu_crtc_mixer *mixer = cstate->mixers;
pstates = kzalloc(sizeof(*pstates) * DPU_STAGE_MAX * 4, GFP_KERNEL);
@@ -1173,6 +1174,16 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
_dpu_crtc_setup_lm_bounds(crtc, crtc_state);
}
+ if (crtc_state->color_mgmt_changed) {
+ for (i = 0; i < cstate->num_mixers; i++) {
+ if (!mixer[i].hw_dspp) {
+ DPU_DEBUG("%s: failed to get dspp for crtc%d
state\n",
+ dpu_crtc->name, crtc->base.id);
+ return -EINVAL;
+ }
+ }
+ }
+
crtc_rect.x2 = mode->hdisplay;
crtc_rect.y2 = mode->vdisplay;
--
2.7.4
RE: [PATCH 3/3] drm/amdgpu/vcn: Add parameter to force (en/dis)abling indirect SRAM mode
[Public] > -Original Message- > From: Alex Deucher > Sent: Tuesday, January 17, 2023 09:11 > To: Guilherme G. Piccoli > Cc: Limonciello, Mario ; Liu, Leo > ; amd-...@lists.freedesktop.org; Jiang, Sonny > ; ker...@gpiccoli.net; Pan, Xinhui > ; dri-devel@lists.freedesktop.org; Lazar, Lijo > ; kernel-...@igalia.com; Deucher, Alexander > ; Zhu, James ; > Koenig, Christian ; Pierre-Loup Griffais > > Subject: Re: [PATCH 3/3] drm/amdgpu/vcn: Add parameter to force > (en/dis)abling indirect SRAM mode > > On Tue, Jan 17, 2023 at 9:33 AM Guilherme G. Piccoli > wrote: > > > > On 16/01/2023 23:33, Limonciello, Mario wrote: > > > [...] > > > > > > For debugging these type of problems, I think an effective debugging > > > tactic would have been to mask the IP block (amdgpu.ip_block_mask). > > > > Thank you, it worked indeed - nice suggestion! > > > > Though I see two problems with that: first, I'm not sure what's the > > impact in the GPU functioning when I disable some IP block. > > It depends on the individual block what the impact is. For example if you don't have VCN, then you can't do any accelerated video playback. > > Second, the parameter is a bit hard to figure - we need to clear a bit > > for the IP block we want to disable, and the doc suggest to read on > > dmesg to get this information (it seems it changes depending on the HW > > model), but I couldn't parse the proper bit from dmesg. Needed to > > instrument the kernel to find the proper bit heh > > Isn't it this stuff (taken from a CZN system): [7.797779] [drm] add ip block number 0 [7.797781] [drm] add ip block number 1 [7.797782] [drm] add ip block number 2 [7.797783] [drm] add ip block number 3 [7.797783] [drm] add ip block number 4 [7.797784] [drm] add ip block number 5 [7.797785] [drm] add ip block number 6 [7.797786] [drm] add ip block number 7 [7.797787] [drm] add ip block number 8 [7.797788] [drm] add ip block number 9 So for that system it would be bit 8 to disable vcn. In terms of how debugging would work: I would expect when you get your failure it will have been the previous block # that failed, and so you can reboot with that block masked and see if you get further. > > The second part is easy to improve (we can just show this bit in > > dmesg!), I might do that instead of proposing this parameter, which > > seems didn't raise much excitement after all heheh > > > > Finally, I'm still curious on why Deck was working fine with the > > indirect SRAM mode disabled (by mistake) in many kernels - was it in > > practice the same as disabling the VCN IP block? > > IIRC, it depends on the fuse recipe for the particular ASIC. > > Alex > > > > > > Thanks, > > > > > > Guilherme > >
Re: [RFC 04/12] drm/cgroup: Track clients per owning process
On 17/01/2023 16:03, Stanislaw Gruszka wrote:
Hi
On Thu, Jan 12, 2023 at 04:56:01PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
To enable propagation of settings from the cgroup drm controller to drm we
need to start tracking which processes own which drm clients.
Implement that by tracking the struct pid pointer of the owning process in
a new XArray, pointing to a structure containing a list of associated
struct drm_file pointers.
Clients are added and removed under the filelist mutex and RCU list
operations are used below it to allow for lockless lookup.
Signed-off-by: Tvrtko Ursulin
+int drm_clients_open(struct drm_file *file_priv)
+{
+ struct drm_device *dev = file_priv->minor->dev;
+ struct drm_pid_clients *clients;
+ bool new_client = false;
+ unsigned long pid;
+
+ lockdep_assert_held(&dev->filelist_mutex);
+
+ pid = (unsigned long)rcu_access_pointer(file_priv->pid);
+ clients = xa_load(&drm_pid_clients, pid);
+ if (!clients) {
+ clients = __alloc_clients();
+ if (!clients)
+ return -ENOMEM;
+ new_client = true;
+ }
+ atomic_inc(&clients->num);
+ list_add_tail_rcu(&file_priv->clink, &clients->file_list);
+ if (new_client) {
+ void *xret;
+
+ xret = xa_store(&drm_pid_clients, pid, clients, GFP_KERNEL);
+ if (xa_err(xret)) {
+ list_del_init(&file_priv->clink);
+ kfree(clients);
+ return PTR_ERR(clients);
This looks incorrect, rather xa_err(xret) should be returned.
Thanks, looks like a copy & paste error. Noted to correct before next
public post.
Regards,
Tvrtko
Re: [PATCH 3/3] drm/amdgpu/vcn: Add parameter to force (en/dis)abling indirect SRAM mode
On 17/01/2023 13:24, Limonciello, Mario wrote: > [...] >>> Though I see two problems with that: first, I'm not sure what's the >>> impact in the GPU functioning when I disable some IP block. >>> > > It depends on the individual block what the impact is. For example > if you don't have VCN, then you can't do any accelerated video playback. > >>> Second, the parameter is a bit hard to figure - we need to clear a bit >>> for the IP block we want to disable, and the doc suggest to read on >>> dmesg to get this information (it seems it changes depending on the HW >>> model), but I couldn't parse the proper bit from dmesg. Needed to >>> instrument the kernel to find the proper bit heh >>> > > Isn't it this stuff (taken from a CZN system): > > [7.797779] [drm] add ip block number 0 > [7.797781] [drm] add ip block number 1 > [7.797782] [drm] add ip block number 2 > [7.797783] [drm] add ip block number 3 > [7.797783] [drm] add ip block number 4 > [7.797784] [drm] add ip block number 5 > [7.797785] [drm] add ip block number 6 > [7.797786] [drm] add ip block number 7 > [7.797787] [drm] add ip block number 8 > [7.797788] [drm] add ip block number 9 > > So for that system it would be bit 8 to disable vcn. > > In terms of how debugging would work: > I would expect when you get your failure it will have been the previous > block # that failed, and so you can reboot with that block masked and > see if you get further. > Thanks Mario, much appreciated! You're totally right and I messed up not seeing these obvious messages... So, I'll just drop the parameter on V2. Cheers, Guilherme
Re: [PATCH 1/3] drm/msm/disp/dpu1: allow reservation even if dspps are not available.
On 17/01/2023 18:21, Kalyan Thota wrote:
if any topology requests for dspps and catalogue doesn't have the
allocation, avoid failing the reservation.
This can pave way to build logic allowing composer fallbacks
for all the color features that are handled in dspp.
Signed-off-by: Kalyan Thota
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 73b3442..c8899ae 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -343,7 +343,13 @@ static bool _dpu_rm_check_lm_and_get_connected_blks(struct
dpu_rm *rm,
return true;
idx = lm_cfg->dspp - DSPP_0;
- if (idx < 0 || idx >= ARRAY_SIZE(rm->dspp_blks)) {
+
+ if (idx < 0) {
The change doesn't correspond to commit message.
+ DPU_DEBUG("lm doesn't have dspp, ignoring the request %d\n",
lm_cfg->dspp);
+ return true;
+ }
+
+ if (idx >= ARRAY_SIZE(rm->dspp_blks)) {
DPU_ERROR("failed to get dspp on lm %d\n", lm_cfg->dspp);
return false;
}
If you'd like to remove duplicate for the (idx >= ARRAY_SIZE) check, I'd
suggest dropping the second one
--
With best wishes
Dmitry
[PATCH] drm/i915/selftest: fix intel_selftest_modify_policy argument types
From: Arnd Bergmann
The definition of intel_selftest_modify_policy() does not match the
declaration, as gcc-13 points out:
drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c:29:5: error:
conflicting types for 'intel_selftest_modify_policy' due to enum/integer
mismatch; have 'int(struct intel_engine_cs *, struct
intel_selftest_saved_policy *, u32)' {aka 'int(struct intel_engine_cs *, struct
intel_selftest_saved_policy *, unsigned int)'} [-Werror=enum-int-mismatch]
29 | int intel_selftest_modify_policy(struct intel_engine_cs *engine,
| ^~~~
In file included from
drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c:11:
drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.h:28:5: note: previous
declaration of 'intel_selftest_modify_policy' with type 'int(struct
intel_engine_cs *, struct intel_selftest_saved_policy *, enum
selftest_scheduler_modify)'
28 | int intel_selftest_modify_policy(struct intel_engine_cs *engine,
| ^~~~
Change the type in the definition to match.
Fixes: 617e87c05c72 ("drm/i915/selftest: Fix hangcheck self test for GuC
submission")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c
b/drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c
index 310fb83c527e..2990dd4d4a0d 100644
--- a/drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c
+++ b/drivers/gpu/drm/i915/selftests/intel_scheduler_helpers.c
@@ -28,8 +28,7 @@ struct intel_engine_cs *intel_selftest_find_any_engine(struct
intel_gt *gt)
int intel_selftest_modify_policy(struct intel_engine_cs *engine,
struct intel_selftest_saved_policy *saved,
-u32 modify_type)
-
+enum selftest_scheduler_modify modify_type)
{
int err;
--
2.39.0
[PATCH] nouveau: fix nv50_wndw_new_() prototype
From: Arnd Bergmann
gcc-13 complains about a mismatched function declaration:
drivers/gpu/drm/nouveau/dispnv50/wndw.c:696:1: error: conflicting types for
'nv50_wndw_new_' due to enum/integer mismatch; have 'int(const struct
nv50_wndw_func *, struct drm_device *, enum drm_plane_type, const char *, int,
const u32 *, u32, enum nv50_disp_interlock_type, u32, struct nv50_wndw **)'
{aka 'int(const struct nv50_wndw_func *, struct drm_device *, enum
drm_plane_type, const char *, int, const unsigned int *, unsigned int, enum
nv50_disp_interlock_type, unsigned int, struct nv50_wndw **)'}
[-Werror=enum-int-mismatch]
696 | nv50_wndw_new_(const struct nv50_wndw_func *func, struct drm_device
*dev,
| ^~
In file included from drivers/gpu/drm/nouveau/dispnv50/wndw.c:22:
drivers/gpu/drm/nouveau/dispnv50/wndw.h:36:5: note: previous declaration of
'nv50_wndw_new_' with type 'int(const struct nv50_wndw_func *, struct
drm_device *, enum drm_plane_type, const char *, int, const u32 *, enum
nv50_disp_interlock_type, u32, u32, struct nv50_wndw **)' {aka 'int(const
struct nv50_wndw_func *, struct drm_device *, enum drm_plane_type, const char
*, int, const unsigned int *, enum nv50_disp_interlock_type, unsigned int,
unsigned int, struct nv50_wndw **)'}
36 | int nv50_wndw_new_(const struct nv50_wndw_func *, struct drm_device *,
| ^~
All the callers are ok, just the header file mixes up the order of
the arguments.
Fixes: 53e0a3e70de6 ("drm/nouveau/kms/nv50-: simplify tracking of channel
interlocks")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/nouveau/dispnv50/wndw.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.h
b/drivers/gpu/drm/nouveau/dispnv50/wndw.h
index 591c852f326b..76a6ae5d5652 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.h
@@ -35,8 +35,9 @@ struct nv50_wndw {
int nv50_wndw_new_(const struct nv50_wndw_func *, struct drm_device *,
enum drm_plane_type, const char *name, int index,
- const u32 *format, enum nv50_disp_interlock_type,
- u32 interlock_data, u32 heads, struct nv50_wndw **);
+ const u32 *format, u32 heads,
+ enum nv50_disp_interlock_type, u32 interlock_data,
+ struct nv50_wndw **);
void nv50_wndw_flush_set(struct nv50_wndw *, u32 *interlock,
struct nv50_wndw_atom *);
void nv50_wndw_flush_clr(struct nv50_wndw *, u32 *interlock, bool flush,
--
2.39.0
Re: [PATCH 1/3] drm/msm/disp/dpu1: allow reservation even if dspps are not available.
On 17/01/2023 18:35, Dmitry Baryshkov wrote:
On 17/01/2023 18:21, Kalyan Thota wrote:
if any topology requests for dspps and catalogue doesn't have the
allocation, avoid failing the reservation.
This can pave way to build logic allowing composer fallbacks
for all the color features that are handled in dspp.
Signed-off-by: Kalyan Thota
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 73b3442..c8899ae 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -343,7 +343,13 @@ static bool
_dpu_rm_check_lm_and_get_connected_blks(struct dpu_rm *rm,
return true;
idx = lm_cfg->dspp - DSPP_0;
- if (idx < 0 || idx >= ARRAY_SIZE(rm->dspp_blks)) {
+
+ if (idx < 0) {
The change doesn't correspond to commit message.
+ DPU_DEBUG("lm doesn't have dspp, ignoring the request %d\n",
lm_cfg->dspp);
+ return true;
+ }
+
+ if (idx >= ARRAY_SIZE(rm->dspp_blks)) {
DPU_ERROR("failed to get dspp on lm %d\n", lm_cfg->dspp);
return false;
}
If you'd like to remove duplicate for the (idx >= ARRAY_SIZE) check, I'd
suggest dropping the second one
I've misread the patch. However I don't see, why would one request
DSPP_NONE while specifying topology->num_dspp. I think that you are
trying to put additional logic into a function that should just check
for the available resources.
--
With best wishes
Dmitry
Re: [Intel-gfx] [RFC PATCH 00/20] Initial Xe driver submission
On Thu, Jan 12, 2023 at 11:17 AM Matthew Brost wrote: > On Thu, Jan 12, 2023 at 10:54:25AM +0100, Lucas De Marchi wrote: > > On Thu, Jan 05, 2023 at 09:27:57PM +, Matthew Brost wrote: > > > On Tue, Jan 03, 2023 at 12:21:08PM +, Tvrtko Ursulin wrote: > > > > > > > > On 22/12/2022 22:21, Matthew Brost wrote: > > > > > Hello, > > > > > > > > > > This is a submission for Xe, a new driver for Intel GPUs that > supports both > > > > > integrated and discrete platforms starting with Tiger Lake (first > platform with > > > > > Intel Xe Architecture). The intention of this new driver is to > have a fresh base > > > > > to work from that is unencumbered by older platforms, whilst also > taking the > > > > > opportunity to rearchitect our driver to increase sharing across > the drm > > > > > subsystem, both leveraging and allowing us to contribute more > towards other > > > > > shared components like TTM and drm/scheduler. The memory model is > based on VM > > > > > bind which is similar to the i915 implementation. Likewise the > execbuf > > > > > implementation for Xe is very similar to execbuf3 in the i915 [1]. > > > > > > > > > > The code is at a stage where it is already functional and has > experimental > > > > > support for multiple platforms starting from Tiger Lake, with > initial support > > > > > implemented in Mesa (for Iris and Anv, our OpenGL and Vulkan > drivers), as well > > > > > as in NEO (for OpenCL and Level0). A Mesa MR has been posted [2] > and NEO > > > > > implementation will be released publicly early next year. We also > have a suite > > > > > of IGTs for XE that will appear on the IGT list shortly. > > > > > > > > > > It has been built with the assumption of supporting multiple > architectures from > > > > > the get-go, right now with tests running both on X86 and ARM > hosts. And we > > > > > intend to continue working on it and improving on it as part of > the kernel > > > > > community upstream. > > > > > > > > > > The new Xe driver leverages a lot from i915 and work on i915 > continues as we > > > > > ready Xe for production throughout 2023. > > > > > > > > > > As for display, the intent is to share the display code with the > i915 driver so > > > > > that there is maximum reuse there. Currently this is being done by > compiling the > > > > > display code twice, but alternatives to that are under > consideration and we want > > > > > to have more discussion on what the best final solution will look > like over the > > > > > next few months. Right now, work is ongoing in refactoring the > display codebase > > > > > to remove as much as possible any unnecessary dependencies on i915 > specific data > > > > > structures there.. > > > > > > > > > > We currently have 2 submission backends, execlists and GuC. The > execlist is > > > > > meant mostly for testing and is not fully functional while GuC > backend is fully > > > > > functional. As with the i915 and GuC submission, in Xe the GuC > firmware is > > > > > required and should be placed in /lib/firmware/xe. > > > > > > > > What is the plan going forward for the execlists backend? I think it > would > > > > be preferable to not upstream something semi-functional and so to > carry > > > > technical debt in the brand new code base, from the very start. If > it is for > > > > Tigerlake, which is the starting platform for Xe, could it be made > GuC only > > > > Tigerlake for instance? > > > > > > > > > > A little background here. In the original PoC written by Jason and > Dave, > > > the execlist backend was the only one present and it was in > semi-working > > > state. As soon as myself and a few others started working on Xe we went > > > full in a on the GuC backend. We left the execlist backend basically in > > > the state it was in. We left it in place for 2 reasons. > > > > > > 1. Having 2 backends from the start ensured we layered our code > > > correctly. The layer was a complete disaster in the i915 so we really > > > wanted to avoid that. > > > 2. The thought was it might be needed for early product bring up one > > > day. > > > > > > As I think about this a bit more, we likely just delete execlist > backend > > > before merging this upstream and perhaps just carry 1 large patch > > > internally with this implementation that we can use as needed. Final > > > decession TDB though. > > > > but that might regress after some time on "let's keep 2 backends so we > > layer the code correctly". Leaving the additional backend behind > > CONFIG_BROKEN or XE_EXPERIMENTAL, or something like that, not > > enabled by distros, but enabled in CI would be a good idea IMO. > > > > Carrying a large patch out of tree would make things harder for new > > platforms. A perfect backend split would make it possible, but like I > > said, we are likely not to have it if we delete the second backend. > > > > Good points here Lucas. One thing that we absolutely have wrong is > falling back to execlists if GuC firmware is missing. We def should not > be
Re: [PATCH v3 0/7] media/drm: renesas: Add new pixel formats
Em Tue, 17 Jan 2023 15:38:25 +0200 Laurent Pinchart escreveu: > Hi Tomi, > > (CC'ing Mauro and Hans) > > On Tue, Jan 10, 2023 at 04:25:37PM +0200, Tomi Valkeinen wrote: > > On 26/12/2022 16:56, Laurent Pinchart wrote: > > > Hi Tomi, > > > > > > (CC'ing Daniel and Dave) > > > > > > On Wed, Dec 21, 2022 at 11:24:41AM +0200, Tomi Valkeinen wrote: > > >> From: Tomi Valkeinen > > >> > > >> Hi, > > >> > > >> These add new pixel formats for Renesas V3U and V4H SoCs. > > >> > > >> As the display pipeline is split between DRM and V4L2 components, this > > >> series touches both subsystems. I'm sending all these together to > > >> simplify review. If needed, I can later split this to V4L2 and DRM > > >> parts, of which the V4L2 part needs to be merged first. > > > > > > As the changes on the DRM side are small and shouldn't conflict with > > > anything else queued for v6.3, it would be easier to merge the whole > > > series through the media tree. Daniel, Dave, would you be OK with that ? > > > If so, could you please ack patches 6/7 and 7/7 ? > > > > Note that these patches depend on the two DRM driver patches in "[PATCH > > v5 0/7] Renesas V4H DSI & DP output support", which are not very small > > (but still not big). > > Good point. I'm thus leaning more towards merging this through the DRM > tree then. Mauro, can we get your ack on the V4L2 part of this series ? > We'll create a stable branch based on v6.2-rc1 in case it also need to > be merged in the media tree due to last minute conflicts (I'm mainly > thinking about the new formats). Feel free to merge the V4L2 patches via DRM tree with my ack: Acked-by: Mauro Carvalho Chehab > > Hans, as there won't be a pull request through the media tree, if you > want to review the new formats, now would be a good time. > > > I don't think there's a compile-time dependency between the DRM and V4L2 > > parts, but there's a functional side dependency, so it would be nice to > > merge these via a single tree. I can't say if DRM or V4L2 tree is > > easier, but I don't expect conflicts either way. > Thanks, Mauro
[PATCH] drm/panfrost: fix GENERIC_ATOMIC64 dependency
From: Arnd Bergmann
On ARMv5 and earlier, a randconfig build can still run into
WARNING: unmet direct dependencies detected for IOMMU_IO_PGTABLE_LPAE
Depends on [n]: IOMMU_SUPPORT [=y] && (ARM [=y] || ARM64 || COMPILE_TEST
[=y]) && !GENERIC_ATOMIC64 [=y]
Selected by [y]:
- DRM_PANFROST [=y] && HAS_IOMEM [=y] && DRM [=y] && (ARM [=y] || ARM64 ||
COMPILE_TEST [=y] && !GENERIC_ATOMIC64 [=y]) && MMU [=y]
Rework the dependencies to always require a working cmpxchg64.
Fixes: db594ba3fcf9 ("drm/panfrost: depend on !GENERIC_ATOMIC64 when using
COMPILE_TEST")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/panfrost/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/Kconfig b/drivers/gpu/drm/panfrost/Kconfig
index 079600328be1..e6403a9d66ad 100644
--- a/drivers/gpu/drm/panfrost/Kconfig
+++ b/drivers/gpu/drm/panfrost/Kconfig
@@ -3,7 +3,8 @@
config DRM_PANFROST
tristate "Panfrost (DRM support for ARM Mali Midgard/Bifrost GPUs)"
depends on DRM
- depends on ARM || ARM64 || (COMPILE_TEST && !GENERIC_ATOMIC64)
+ depends on ARM || ARM64 || COMPILE_TEST
+ depends on !GENERIC_ATOMIC64# for IOMMU_IO_PGTABLE_LPAE
depends on MMU
select DRM_SCHED
select IOMMU_SUPPORT
--
2.39.0
[linux-next:master] BUILD REGRESSION 9ce08dd7ea24253aac5fd2519f9aea27dfb390c9
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 9ce08dd7ea24253aac5fd2519f9aea27dfb390c9 Add linux-next specific files for 20230117 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202301100332.4eaki4d1-...@intel.com https://lore.kernel.org/oe-kbuild-all/202301171414.xpf8wpxn-...@intel.com https://lore.kernel.org/oe-kbuild-all/202301171511.4zszviyp-...@intel.com Error/Warning: (recently discovered and may have been fixed) Documentation/mm/unevictable-lru.rst:186: WARNING: Title underline too short. ERROR: modpost: "kunit_running" [drivers/gpu/drm/vc4/vc4.ko] undefined! arch/arm/kernel/entry-armv.S:485:5: warning: "CONFIG_ARM_THUMB" is not defined, evaluates to 0 [-Wundef] drivers/gpu/drm/ttm/ttm_bo_util.c:364:32: error: implicit declaration of function 'vmap'; did you mean 'kmap'? [-Werror=implicit-function-declaration] drivers/gpu/drm/ttm/ttm_bo_util.c:429:17: error: implicit declaration of function 'vunmap'; did you mean 'kunmap'? [-Werror=implicit-function-declaration] drivers/scsi/qla2xxx/qla_mid.c:1094:51: warning: format '%ld' expects argument of type 'long int', but argument 5 has type 'unsigned int' [-Wformat=] drivers/scsi/qla2xxx/qla_mid.c:1189:6: warning: no previous prototype for 'qla_trim_buf' [-Wmissing-prototypes] drivers/scsi/qla2xxx/qla_mid.c:1221:6: warning: no previous prototype for '__qla_adjust_buf' [-Wmissing-prototypes] libbpf: failed to find '.BTF' ELF section in vmlinux usr/include/asm/kvm.h:508:17: error: expected specifier-qualifier-list before '__DECLARE_FLEX_ARRAY' Unverified Error/Warning (likely false positive, please contact us if interested): FAILED: load BTF from vmlinux: No data available drivers/firmware/arm_scmi/bus.c:156:24: warning: Uninitialized variable: victim->id_table [uninitvar] drivers/firmware/arm_scmi/virtio.c:341:12: warning: Uninitialized variable: msg->poll_status [uninitvar] drivers/gpio/gpio-mxc.c:293:32: warning: Uninitialized variable: port->hwdata [uninitvar] drivers/gpio/gpio-mxc.c:550:31: warning: Shifting signed 32-bit value by 31 bits is implementation-defined behaviour [shiftTooManyBitsSigned] drivers/gpio/gpio-mxc.c:550:31: warning: Signed integer overflow for expression '1<https://01.org/lkp
[PATCH] vc4: fix build failure in vc4_dsi_dev_probe()
From: Arnd Bergmann
The bridge->of_node field is defined inside of an #ifdef, which
results in a build failure when compile-testing the vc4_dsi driver
without CONFIG_OF:
drivers/gpu/drm/vc4/vc4_dsi.c: In function 'vc4_dsi_dev_probe':
drivers/gpu/drm/vc4/vc4_dsi.c:1822:20: error: 'struct drm_bridge' has no member
named 'of_node'
1822 | dsi->bridge.of_node = dev->of_node;
Add another #ifdef in the place it is used in. Alternatively we
could consider dropping the #ifdef in the struct definition
and all other users.
Fixes: 78df640394cd ("drm/vc4: dsi: Convert to using a bridge instead of
encoder")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/vc4/vc4_dsi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index 2a71321b9222..a5c075f802e4 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -1819,7 +1819,9 @@ static int vc4_dsi_dev_probe(struct platform_device *pdev)
dsi->pdev = pdev;
dsi->bridge.funcs = &vc4_dsi_bridge_funcs;
+#ifdef CONFIG_OF
dsi->bridge.of_node = dev->of_node;
+#endif
dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
dsi->dsi_host.ops = &vc4_dsi_host_ops;
dsi->dsi_host.dev = dev;
--
2.39.0
[PATCH] drm: panel: visionox: add backlight dependency
From: Arnd Bergmann
The newly added driver uses the backlight subsystem but is missing the
corresponding Kconfig dependency:
arm-linux-gnueabi-ld: drivers/gpu/drm/panel/panel-visionox-vtdr6130.o: in
function `visionox_vtdr6130_probe':
panel-visionox-vtdr6130.c:(.text+0xdee): undefined reference to
`devm_backlight_device_register'
Fixes: 65dc9360f741 ("drm: panel: Add Himax HX8394 panel controller driver")
Signed-off-by: Arnd Bergmann
---
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 dd79928f5482..8f2046caaa6b 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -742,6 +742,7 @@ config DRM_PANEL_VISIONOX_VTDR6130
tristate "Visionox VTDR6130"
depends on OF
depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
help
Say Y here if you want to enable support for Visionox
VTDR6130 1080x2400 AMOLED DSI panel.
--
2.39.0
Re: [PATCH 2/3] drm/msm/disp/dpu1: allow dspp selection for all the interfaces
On 17/01/2023 18:21, Kalyan Thota wrote:
Allow dspps to be populated as a requirement for all the encoder
types it need not be just DSI. If for any encoder the dspp
allocation doesn't go through then there can be an option to
fallback for color features.
Signed-off-by: Kalyan Thota
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 9c6817b..e39b345 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -545,7 +545,8 @@ bool dpu_encoder_use_dsc_merge(struct drm_encoder *drm_enc)
static struct msm_display_topology dpu_encoder_get_topology(
struct dpu_encoder_virt *dpu_enc,
struct dpu_kms *dpu_kms,
- struct drm_display_mode *mode)
+ struct drm_display_mode *mode,
+ struct drm_crtc_state *crtc_state)
Is this new argument used at all?
{
struct msm_display_topology topology = {0};
int i, intf_count = 0;
@@ -563,8 +564,9 @@ static struct msm_display_topology dpu_encoder_get_topology(
* 1 LM, 1 INTF
* 2 LM, 1 INTF (stream merge to support high resolution interfaces)
*
-* Adding color blocks only to primary interface if available in
-* sufficient number
+* dspp blocks are made optional. If RM manager cannot allocate
+* dspp blocks, then reservations will still go through with non dspp
LM's
+* so as to allow color management support via composer fallbacks
*/
No, this is not the way to go.
First, RM should prefer non-DSPP-enabled LMs if DSPP blocks are not
required. Right now your patch makes it possible to allocate LMs, that
have DSPP attached, for non-CTM-enabled encoder and later fail
allocation of DSPP for the CRTC which has CTM blob attached.
Second, the decision on using DSPPs should come from
dpu_crtc_atomic_check(). Pass 'bool need_dspp' to this function from
dpu_atomic_check(). Fail if the need_dspp constraint can't be fulfilled.
if (intf_count == 2)
topology.num_lm = 2;
@@ -573,11 +575,9 @@ static struct msm_display_topology
dpu_encoder_get_topology(
else
topology.num_lm = (mode->hdisplay > MAX_HDISPLAY_SPLIT) ? 2 : 1;
- if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI) {
- if (dpu_kms->catalog->dspp &&
- (dpu_kms->catalog->dspp_count >= topology.num_lm))
- topology.num_dspp = topology.num_lm;
- }
+ if (dpu_kms->catalog->dspp &&
+ (dpu_kms->catalog->dspp_count >= topology.num_lm))
+ topology.num_dspp = topology.num_lm;
topology.num_enc = 0;
topology.num_intf = intf_count;
@@ -643,7 +643,7 @@ static int dpu_encoder_virt_atomic_check(
}
}
- topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode);
+ topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode,
crtc_state);
/* Reserve dynamic resources now. */
if (!ret) {
--
With best wishes
Dmitry
[Bug 216917] hibernation regression since 6.0.18 (Ryzen-5650U incl. Radeon GPU)
https://bugzilla.kernel.org/show_bug.cgi?id=216917
--- Comment #27 from Rainer Fiebig (j...@mailbox.org) ---
(In reply to Alex Deucher from comment #26)
> (In reply to Rainer Fiebig from comment #25)
> > (In reply to Alex Deucher from comment #23)
> > > I'll just revert it. It is more important for kernels with the the
> > > drm_buddy changes.
> >
> > Would the following be equivalent to what you intended with your commit?
> > Looks a bit awkward but hibernate/resume work with it for 6.0.19 (and a
> > Ryzen 5600G):
> >
> >
> > uint32_t amdgpu_bo_get_preferred_domain(struct amdgpu_device *adev,
> > uint32_t domain)
> > {
> > if (domain == (AMDGPU_GEM_DOMAIN_VRAM | AMDGPU_GEM_DOMAIN_GTT)) {
> > domain = AMDGPU_GEM_DOMAIN_VRAM;
> > if ((adev->asic_type == CHIP_CARRIZO) || (adev->asic_type ==
> > CHIP_STONEY))
> > {
> > if (adev->gmc.real_vram_size <= AMDGPU_SG_THRESHOLD)
> > domain = AMDGPU_GEM_DOMAIN_GTT;
> > }
> > }
> > return domain;
> > }
> >
> >
> > Let me know whether this is worth persuing. I could then test it with
> > 5.15.88 and 6.1.6.
>
> Nope. What my patch does is allow display buffers to be in either system
> memory (GTT) or carve out (VRAM) depending on what is available. Without
> the patch, the driver picks either VRAM or GTT depending on how much VRAM is
> available on the system. This can lead to memory exhaustion in some cases
> with multiple large resolution monitors depending on memory fragmentation.
>
> What your patch does is just always use VRAM unless the chip is Carrizo or
> Stoney. So it is effectively just reverting the commit (depending on how
> much VRAM your system has).
I see. Thanks a lot for the explanation!
--
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 V10 1/4] drm: of: Add drm_of_get_dsi_bus helper function
Hi,
On Thu, Jan 12, 2023 at 11:53:55AM -0600, Chris Morgan wrote:
> From: Chris Morgan
>
> Add helper function to find DSI host for devices where DSI panel is not
> a minor of a DSI bus (such as the Samsung AMS495QA01 panel or the
> official Raspberry Pi touchscreen display).
>
> Signed-off-by: Chris Morgan
> Signed-off-by: Maya Matuszczyk
> ---
> drivers/gpu/drm/drm_of.c | 70
> include/drm/drm_of.h | 10 ++
> 2 files changed, 80 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index 7bbcb999bb75..6c2c97a716fe 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -493,3 +494,72 @@ int drm_of_get_data_lanes_count_ep(const struct
> device_node *port,
> return ret;
> }
> EXPORT_SYMBOL_GPL(drm_of_get_data_lanes_count_ep);
> +
> +#if IS_ENABLED(CONFIG_DRM_MIPI_DSI)
> +
> +/**
> + * drm_of_get_dsi_bus - find the DSI bus for a given device
> + * @dev: parent device of display (SPI, I2C)
> + * @info: DSI device info to be updated with DSI node. This is optional
> + * and if not needed can be NULL.
> + *
> + * Gets parent DSI bus for a DSI device controlled through a bus other
> + * than MIPI-DCS (SPI, I2C, etc.) using the Device Tree.
> + *
> + * Returns pointer to mipi_dsi_host if successful, -EINVAL if the
> + * request is unsupported, -EPROBE_DEFER if the DSI host is found but
> + * not available, or -ENODEV otherwise.
> + */
> +struct mipi_dsi_host *drm_of_get_dsi_bus(struct device *dev,
> + struct mipi_dsi_device_info *info)
> +{
> + struct mipi_dsi_host *dsi_host;
> + struct device_node *endpoint, *dsi_host_node;
> +
> + /*
> + * Get first endpoint child from device.
> + */
> + endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
> + if (!endpoint)
> + return ERR_PTR(-ENODEV);
> +
> + /*
> + * Follow the first endpoint to get the DSI host node.
> + */
> + dsi_host_node = of_graph_get_remote_port_parent(endpoint);
> + if (!dsi_host_node)
> + goto error;
> +
> + /*
> + * Get the DSI host from the DSI host node. If we get an error
> + * or the return is null assume we're not ready to probe just
> + * yet. Release the DSI host node since we're done with it.
> + */
> + dsi_host = of_find_mipi_dsi_host_by_node(dsi_host_node);
> + of_node_put(dsi_host_node);
> + if (IS_ERR_OR_NULL(dsi_host)) {
> + of_node_put(endpoint);
> + return ERR_PTR(-EPROBE_DEFER);
> + }
> +
> + /*
> + * Set the node of the mipi_dsi_device_info to the correct node
> + * and then release the endpoint node since we're done with it.
> + * since this is optional, check if the info is NULL first.
> + */
> + if (info) {
> + info->node = of_graph_get_remote_port(endpoint);
it looks to me that the info->node is actually the DSI device OF node,
not its host port. Which begs the question, why should we even return it
there, since there's a pretty big chance that dev->of.node ==
info->node, and you obviously don't care about the channel and type fields.
I've had a look and node of the current users of
mipi_dsi_device_register_full actually register a mipi_dsi_device_info
with a node pointer set to !NULL, including the driver in this series.
So, why do we care about the device info at all?
> + if (IS_ERR_OR_NULL(info->node))
of_graph_get_remote_port doesn't return an error pointer.
> --- a/include/drm/drm_of.h
> +++ b/include/drm/drm_of.h
> @@ -15,6 +15,8 @@ struct drm_encoder;
> struct drm_panel;
> struct drm_bridge;
> struct device_node;
> +struct mipi_dsi_device_info;
> +struct mipi_dsi_host;
>
> /**
> * enum drm_lvds_dual_link_pixels - Pixel order of an LVDS dual-link
> connection
> @@ -56,6 +58,8 @@ int drm_of_get_data_lanes_count_ep(const struct device_node
> *port,
> int port_reg, int reg,
> const unsigned int min,
> const unsigned int max);
> +struct mipi_dsi_host *drm_of_get_dsi_bus(struct device *dev,
> + struct mipi_dsi_device_info *info);
> #else
> static inline uint32_t drm_of_crtc_port_mask(struct drm_device *dev,
> struct device_node *port)
> @@ -127,6 +131,12 @@ drm_of_get_data_lanes_count_ep(const struct device_node
> *port,
> {
> return -EINVAL;
> }
> +static inline struct
> +mipi_dsi_host *drm_of_get_dsi_bus(struct device *dev,
> + struct mipi_dsi_device_info *info)
> +{
> + return ERR_PTR(-EINVAL);
> +}
> #endif
So it looks to me that if CONFIG_OF is defined, we'll define an external
symbol declared for drm_of_get_dsi_bus, but that functi
Re: (subset) [PATCH] drm/atomic-helper: fix kernel-doc problems
On Mon, 16 Jan 2023 23:02:16 -0800, Randy Dunlap wrote: > Fix a kernel-doc warning and other kernel-doc formatting for > drm_atomic_helper_connect_tv_check(). > > drivers/gpu/drm/drm_atomic_state_helper.c:560: warning: Cannot understand * > @drm_atomic_helper_connector_tv_check: Validate an analog TV connector state > on line 560 - I thought it was a doc line > > > [...] Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime
Re: (subset) [PATCH] drm/connector: fix a kernel-doc bad line warning
On Mon, 16 Jan 2023 23:02:24 -0800, Randy Dunlap wrote: > Building the kernel documentation causes this warning 7 times. > Fix it by adding a " *" line instead of a blank line. > > drivers/gpu/drm/drm_connector.c:1849: warning: bad line: > > Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime
Re: (subset) [PATCH] vc4: fix build failure in vc4_dsi_dev_probe()
On Tue, 17 Jan 2023 17:52:51 +0100, Arnd Bergmann wrote: > The bridge->of_node field is defined inside of an #ifdef, which > results in a build failure when compile-testing the vc4_dsi driver > without CONFIG_OF: > > drivers/gpu/drm/vc4/vc4_dsi.c: In function 'vc4_dsi_dev_probe': > drivers/gpu/drm/vc4/vc4_dsi.c:1822:20: error: 'struct drm_bridge' has no > member named 'of_node' > 1822 | dsi->bridge.of_node = dev->of_node; > > [...] Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime
[PATCH] [v2] drm/amd/display: fix dp_retrieve_lttpr_cap return code
From: Arnd Bergmann
The dp_retrieve_lttpr_cap() return type changed from 'bool'
to 'enum dc_status', so now the early 'return' uses the wrong
type:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c: In function
'dp_retrieve_lttpr_cap':
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:5075:24: error:
implicit conversion from 'enum ' to 'enum dc_status'
[-Werror=enum-conversion]
5075 | return false;
|^
Convert it to return 'DC_ERROR_UNEXPECTED', which was apparently set
as a default return code here but never used.
Fixes: b473bd5fc333 ("drm/amd/display: refine wake up aux in retrieve link
caps")
Signed-off-by: Arnd Bergmann
---
v2 changes:
- use DC_ERROR_UNEXPECTED instead of DC_OK
- remove bogus initializers
---
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 6 +++---
1 file changed, 3 insertions(+), 3 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 9edfcdf3db3b..cf512362b4f1 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
@@ -5088,14 +5088,14 @@ static bool dpcd_read_sink_ext_caps(struct dc_link
*link)
enum dc_status dp_retrieve_lttpr_cap(struct dc_link *link)
{
uint8_t lttpr_dpcd_data[8];
- enum dc_status status = DC_ERROR_UNEXPECTED;
- bool is_lttpr_present = false;
+ enum dc_status status;
+ bool is_lttpr_present;
/* Logic to determine LTTPR support*/
bool vbios_lttpr_interop = link->dc->caps.vbios_lttpr_aware;
if (!vbios_lttpr_interop ||
!link->dc->caps.extended_aux_timeout_support)
- return false;
+ return DC_ERROR_UNEXPECTED;
/* By reading LTTPR capability, RX assumes that we will enable
* LTTPR extended aux timeout if LTTPR is present.
--
2.39.0
[PATCH] drm/msm/dp: Remove INIT_SETUP delay
During initalization of the DisplayPort controller an EV_HPD_INIT_SETUP event is generated, but with a delay of 100 units. This delay existed to circumvent bug in the QMP combo PHY driver, where if the DP part was powered up before USB, the common properties would not be properly initialized - and USB wouldn't work. This issue was resolved in the recent refactoring of the QMP driver, so it's now possible to remove this delay. While there is still a timing dependency in the current implementation, test indicates that it's now possible to boot with an external display on USB Type-C and have the display power up, without disconnecting and reconnecting the cable. Signed-off-by: Bjorn Andersson --- drivers/gpu/drm/msm/dp/dp_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c index db9783ffd5cf..bde1a7ce442f 100644 --- a/drivers/gpu/drm/msm/dp/dp_display.c +++ b/drivers/gpu/drm/msm/dp/dp_display.c @@ -1506,7 +1506,7 @@ void msm_dp_irq_postinstall(struct msm_dp *dp_display) dp = container_of(dp_display, struct dp_display_private, dp_display); if (!dp_display->is_edp) - dp_add_event(dp, EV_HPD_INIT_SETUP, 0, 100); + dp_add_event(dp, EV_HPD_INIT_SETUP, 0, 0); } bool msm_dp_wide_bus_available(const struct msm_dp *dp_display) -- 2.37.3
[PATCH 1/2] drm/radeon: Do not use deprecated drm log API
Replace deprecated DRM_DEBUG_KMS_RATELIMITED() and DRM_ERROR()
with proper APIs.
Cc: Alex Deucher
Cc: Christian König
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/radeon/radeon_dp_auxch.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_dp_auxch.c
b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
index 69379b95146e..76ce66efb5f8 100644
--- a/drivers/gpu/drm/radeon/radeon_dp_auxch.c
+++ b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
@@ -158,7 +158,7 @@ radeon_dp_aux_transfer_native(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg
} while (retry_count++ < 1000);
if (retry_count >= 1000) {
- DRM_ERROR("auxch hw never signalled completion, error %08x\n",
tmp);
+ pr_err("auxch hw never signalled completion, error %08x\n",
tmp);
ret = -EIO;
goto done;
}
@@ -168,8 +168,7 @@ radeon_dp_aux_transfer_native(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg
goto done;
}
if (tmp & AUX_RX_ERROR_FLAGS) {
- DRM_DEBUG_KMS_RATELIMITED("dp_aux_ch flags not zero: %08x\n",
- tmp);
+ drm_dbg_kms_ratelimited(dev, "dp_aux_ch flags not zero:
%08x\n", tmp);
ret = -EIO;
goto done;
}
--
2.39.0
[PATCH 2/2] drm_print: Remove deprecated DRM_DEBUG_KMS_RATELIMITED()
There are no current users of DRM_DEBUG_KMS_RATELIMITED() so remove it. Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Cc: Sam Ravnborg Signed-off-by: Nirmoy Das --- include/drm/drm_print.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h index a44fb7ef257f..c3753da97c4e 100644 --- a/include/drm/drm_print.h +++ b/include/drm/drm_print.h @@ -605,9 +605,6 @@ void __drm_err(const char *format, ...); #define drm_dbg_kms_ratelimited(drm, fmt, ...) \ __DRM_DEFINE_DBG_RATELIMITED(KMS, drm, fmt, ## __VA_ARGS__) -/* NOTE: this is deprecated in favor of drm_dbg_kms_ratelimited(NULL, ...). */ -#define DRM_DEBUG_KMS_RATELIMITED(fmt, ...) drm_dbg_kms_ratelimited(NULL, fmt, ## __VA_ARGS__) - /* * struct drm_device based WARNs * -- 2.39.0
[PATCH] accel: Add .mmap to DRM_ACCEL_FOPS
In reviewing the ivpu driver, DEFINE_DRM_ACCEL_FOPS could have been used if DRM_ACCEL_FOPS defined .mmap to be drm_gem_mmap. Lets add that since accel drivers are a variant of drm drivers, modern drm drivers are expected to use GEM, and mmap() is a common operation that is expected to be heavily used in accel drivers thus the common accel driver should be able to just use DEFINE_DRM_ACCEL_FOPS() for convenience. Signed-off-by: Jeffrey Hugo --- include/drm/drm_accel.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/drm/drm_accel.h b/include/drm/drm_accel.h index 65c0affb..d495506 100644 --- a/include/drm/drm_accel.h +++ b/include/drm/drm_accel.h @@ -27,7 +27,8 @@ .compat_ioctl = drm_compat_ioctl,\ .poll = drm_poll,\ .read = drm_read,\ - .llseek = noop_llseek + .llseek = noop_llseek, \ + .mmap = drm_gem_mmap /** * DEFINE_DRM_ACCEL_FOPS() - macro to generate file operations for accelerators drivers -- 2.7.4
Re: [PATCH 1/2] drm/radeon: Do not use deprecated drm log API
On Tue, Jan 17, 2023 at 12:45 PM Nirmoy Das wrote:
>
> Replace deprecated DRM_DEBUG_KMS_RATELIMITED() and DRM_ERROR()
> with proper APIs.
>
> Cc: Alex Deucher
> Cc: Christian König
>
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/radeon/radeon_dp_auxch.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_dp_auxch.c
> b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
> index 69379b95146e..76ce66efb5f8 100644
> --- a/drivers/gpu/drm/radeon/radeon_dp_auxch.c
> +++ b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
> @@ -158,7 +158,7 @@ radeon_dp_aux_transfer_native(struct drm_dp_aux *aux,
> struct drm_dp_aux_msg *msg
> } while (retry_count++ < 1000);
>
> if (retry_count >= 1000) {
> - DRM_ERROR("auxch hw never signalled completion, error
> %08x\n", tmp);
> + pr_err("auxch hw never signalled completion, error %08x\n",
> tmp);
Please use dev_err() instead so we get device identification on error
messages. Makes it much easier when you have multiple GPUs in a
system.
Alex
> ret = -EIO;
> goto done;
> }
> @@ -168,8 +168,7 @@ radeon_dp_aux_transfer_native(struct drm_dp_aux *aux,
> struct drm_dp_aux_msg *msg
> goto done;
> }
> if (tmp & AUX_RX_ERROR_FLAGS) {
> - DRM_DEBUG_KMS_RATELIMITED("dp_aux_ch flags not zero: %08x\n",
> - tmp);
> + drm_dbg_kms_ratelimited(dev, "dp_aux_ch flags not zero:
> %08x\n", tmp);
> ret = -EIO;
> goto done;
> }
> --
> 2.39.0
>
Re: [PATCH 1/2] drm/radeon: Do not use deprecated drm log API
On 1/17/2023 6:48 PM, Alex Deucher wrote:
On Tue, Jan 17, 2023 at 12:45 PM Nirmoy Das wrote:
Replace deprecated DRM_DEBUG_KMS_RATELIMITED() and DRM_ERROR()
with proper APIs.
Cc: Alex Deucher
Cc: Christian König
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/radeon/radeon_dp_auxch.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_dp_auxch.c
b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
index 69379b95146e..76ce66efb5f8 100644
--- a/drivers/gpu/drm/radeon/radeon_dp_auxch.c
+++ b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
@@ -158,7 +158,7 @@ radeon_dp_aux_transfer_native(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg
} while (retry_count++ < 1000);
if (retry_count >= 1000) {
- DRM_ERROR("auxch hw never signalled completion, error %08x\n",
tmp);
+ pr_err("auxch hw never signalled completion, error %08x\n",
tmp);
Please use dev_err() instead so we get device identification on error
messages. Makes it much easier when you have multiple GPUs in a
system.
Thanks for your quick review, Alex. I will resend with dev_err().
Nirmoy
Alex
ret = -EIO;
goto done;
}
@@ -168,8 +168,7 @@ radeon_dp_aux_transfer_native(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg
goto done;
}
if (tmp & AUX_RX_ERROR_FLAGS) {
- DRM_DEBUG_KMS_RATELIMITED("dp_aux_ch flags not zero: %08x\n",
- tmp);
+ drm_dbg_kms_ratelimited(dev, "dp_aux_ch flags not zero:
%08x\n", tmp);
ret = -EIO;
goto done;
}
--
2.39.0
[PATCH 2/2] drm/i915: Fix a memory leak with reused mmap_offset
drm_vma_node_allow() and drm_vma_node_revoke() should be called in balanced pairs. We call drm_vma_node_allow() once per-file everytime a user calls mmap_offset, but only call drm_vma_node_revoke once per-file on each mmap_offset. As the mmap_offset is reused by the client, the per-file vm_count may remain non-zero and the rbtree leaked. Call drm_vma_node_allow_once() instead to prevent that memory leak. Cc: Tvrtko Ursulin Cc: Andi Shyti Signed-off-by: Nirmoy Das --- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c index 4f69bff63068..2aac6bf78740 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c @@ -697,7 +697,7 @@ mmap_offset_attach(struct drm_i915_gem_object *obj, GEM_BUG_ON(lookup_mmo(obj, mmap_type) != mmo); out: if (file) - drm_vma_node_allow(&mmo->vma_node, file); + drm_vma_node_allow_once(&mmo->vma_node, file); return mmo; err: -- 2.39.0
[PATCH 1/2] drm/drm_vma_manager: Add drm_vma_node_allow_once()
Currently there is no easy way for a drm driver to safely check and allow
drm_vma_offset_node for a drm file just once. Allow drm drivers to call
non-refcounted version of drm_vma_node_allow() so that a driver doesn't
need to keep track of each drm_vma_node_allow() to call subsequent
drm_vma_node_revoke() to prevent memory leak.
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: Tvrtko Ursulin
Cc: Andi Shyti
Suggested-by: Chris Wilson
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/drm_vma_manager.c | 76 ++-
include/drm/drm_vma_manager.h | 1 +
2 files changed, 55 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/drm_vma_manager.c
b/drivers/gpu/drm/drm_vma_manager.c
index 7de37f8c68fd..83229a031af0 100644
--- a/drivers/gpu/drm/drm_vma_manager.c
+++ b/drivers/gpu/drm/drm_vma_manager.c
@@ -240,27 +240,8 @@ void drm_vma_offset_remove(struct drm_vma_offset_manager
*mgr,
}
EXPORT_SYMBOL(drm_vma_offset_remove);
-/**
- * drm_vma_node_allow - Add open-file to list of allowed users
- * @node: Node to modify
- * @tag: Tag of file to remove
- *
- * Add @tag to the list of allowed open-files for this node. If @tag is
- * already on this list, the ref-count is incremented.
- *
- * The list of allowed-users is preserved across drm_vma_offset_add() and
- * drm_vma_offset_remove() calls. You may even call it if the node is currently
- * not added to any offset-manager.
- *
- * You must remove all open-files the same number of times as you added them
- * before destroying the node. Otherwise, you will leak memory.
- *
- * This is locked against concurrent access internally.
- *
- * RETURNS:
- * 0 on success, negative error code on internal failure (out-of-mem)
- */
-int drm_vma_node_allow(struct drm_vma_offset_node *node, struct drm_file *tag)
+static int vma_node_allow(struct drm_vma_offset_node *node,
+ struct drm_file *tag, bool ref_counted)
{
struct rb_node **iter;
struct rb_node *parent = NULL;
@@ -282,7 +263,8 @@ int drm_vma_node_allow(struct drm_vma_offset_node *node,
struct drm_file *tag)
entry = rb_entry(*iter, struct drm_vma_offset_file, vm_rb);
if (tag == entry->vm_tag) {
- entry->vm_count++;
+ if (ref_counted)
+ entry->vm_count++;
goto unlock;
} else if (tag > entry->vm_tag) {
iter = &(*iter)->rb_right;
@@ -307,8 +289,58 @@ int drm_vma_node_allow(struct drm_vma_offset_node *node,
struct drm_file *tag)
kfree(new);
return ret;
}
+
+/**
+ * drm_vma_node_allow - Add open-file to list of allowed users
+ * @node: Node to modify
+ * @tag: Tag of file to remove
+ *
+ * Add @tag to the list of allowed open-files for this node. If @tag is
+ * already on this list, the ref-count is incremented.
+ *
+ * The list of allowed-users is preserved across drm_vma_offset_add() and
+ * drm_vma_offset_remove() calls. You may even call it if the node is currently
+ * not added to any offset-manager.
+ *
+ * You must remove all open-files the same number of times as you added them
+ * before destroying the node. Otherwise, you will leak memory.
+ *
+ * This is locked against concurrent access internally.
+ *
+ * RETURNS:
+ * 0 on success, negative error code on internal failure (out-of-mem)
+ */
+int drm_vma_node_allow(struct drm_vma_offset_node *node, struct drm_file *tag)
+{
+ return vma_node_allow(node, tag, true);
+}
EXPORT_SYMBOL(drm_vma_node_allow);
+/**
+ * drm_vma_node_allow_once - Add open-file to list of allowed users
+ * @node: Node to modify
+ * @tag: Tag of file to remove
+ *
+ * Add @tag to the list of allowed open-files for this node.
+ *
+ * The list of allowed-users is preserved across drm_vma_offset_add() and
+ * drm_vma_offset_remove() calls. You may even call it if the node is currently
+ * not added to any offset-manager.
+ *
+ * This is not ref-counted unlike drm_vma_node_allow() hence
drm_vma_node_revoke()
+ * should only be called once after this.
+ *
+ * This is locked against concurrent access internally.
+ *
+ * RETURNS:
+ * 0 on success, negative error code on internal failure (out-of-mem)
+ */
+int drm_vma_node_allow_once(struct drm_vma_offset_node *node, struct drm_file
*tag)
+{
+ return vma_node_allow(node, tag, false);
+}
+EXPORT_SYMBOL(drm_vma_node_allow_once);
+
/**
* drm_vma_node_revoke - Remove open-file from list of allowed users
* @node: Node to modify
diff --git a/include/drm/drm_vma_manager.h b/include/drm/drm_vma_manager.h
index 4f8c35206f7c..6c2a2f21dbf0 100644
--- a/include/drm/drm_vma_manager.h
+++ b/include/drm/drm_vma_manager.h
@@ -74,6 +74,7 @@ void drm_vma_offset_remove(struct drm_vma_offset_manager *mgr,
struct drm_vma_offset_node *node);
int drm_vma_node_allow(struct drm_vma_offset_node *node, stru
[PATCH v2 1/2] drm/amdgpu/vcn: Adjust firmware names indentation
This is an incredibly trivial fix, just for the sake of "aesthetical" organization of the defines. Some were space based, most were tab based and there was a lack of "alignment", now it's all the same and aligned. Cc: James Zhu Cc: Lazar Lijo Cc: Leo Liu Cc: Mario Limonciello Cc: Sonny Jiang Reviewed-by: Alex Deucher Signed-off-by: Guilherme G. Piccoli --- V2: * Added Alex's review tag - thanks! drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 38 - 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c index f8397d993f23..1b1a3c9e1863 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c @@ -36,26 +36,26 @@ #include "soc15d.h" /* Firmware Names */ -#define FIRMWARE_RAVEN "amdgpu/raven_vcn.bin" -#define FIRMWARE_PICASSO "amdgpu/picasso_vcn.bin" -#define FIRMWARE_RAVEN2"amdgpu/raven2_vcn.bin" -#define FIRMWARE_ARCTURUS "amdgpu/arcturus_vcn.bin" -#define FIRMWARE_RENOIR"amdgpu/renoir_vcn.bin" -#define FIRMWARE_GREEN_SARDINE "amdgpu/green_sardine_vcn.bin" -#define FIRMWARE_NAVI10"amdgpu/navi10_vcn.bin" -#define FIRMWARE_NAVI14"amdgpu/navi14_vcn.bin" -#define FIRMWARE_NAVI12"amdgpu/navi12_vcn.bin" -#define FIRMWARE_SIENNA_CICHLID"amdgpu/sienna_cichlid_vcn.bin" -#define FIRMWARE_NAVY_FLOUNDER "amdgpu/navy_flounder_vcn.bin" -#define FIRMWARE_VANGOGH "amdgpu/vangogh_vcn.bin" +#define FIRMWARE_RAVEN "amdgpu/raven_vcn.bin" +#define FIRMWARE_PICASSO "amdgpu/picasso_vcn.bin" +#define FIRMWARE_RAVEN2"amdgpu/raven2_vcn.bin" +#define FIRMWARE_ARCTURUS "amdgpu/arcturus_vcn.bin" +#define FIRMWARE_RENOIR"amdgpu/renoir_vcn.bin" +#define FIRMWARE_GREEN_SARDINE "amdgpu/green_sardine_vcn.bin" +#define FIRMWARE_NAVI10"amdgpu/navi10_vcn.bin" +#define FIRMWARE_NAVI14"amdgpu/navi14_vcn.bin" +#define FIRMWARE_NAVI12"amdgpu/navi12_vcn.bin" +#define FIRMWARE_SIENNA_CICHLID"amdgpu/sienna_cichlid_vcn.bin" +#define FIRMWARE_NAVY_FLOUNDER "amdgpu/navy_flounder_vcn.bin" +#define FIRMWARE_VANGOGH "amdgpu/vangogh_vcn.bin" #define FIRMWARE_DIMGREY_CAVEFISH "amdgpu/dimgrey_cavefish_vcn.bin" -#define FIRMWARE_ALDEBARAN "amdgpu/aldebaran_vcn.bin" -#define FIRMWARE_BEIGE_GOBY"amdgpu/beige_goby_vcn.bin" -#define FIRMWARE_YELLOW_CARP "amdgpu/yellow_carp_vcn.bin" -#define FIRMWARE_VCN_3_1_2 "amdgpu/vcn_3_1_2.bin" -#define FIRMWARE_VCN4_0_0 "amdgpu/vcn_4_0_0.bin" -#define FIRMWARE_VCN4_0_2 "amdgpu/vcn_4_0_2.bin" -#define FIRMWARE_VCN4_0_4 "amdgpu/vcn_4_0_4.bin" +#define FIRMWARE_ALDEBARAN "amdgpu/aldebaran_vcn.bin" +#define FIRMWARE_BEIGE_GOBY"amdgpu/beige_goby_vcn.bin" +#define FIRMWARE_YELLOW_CARP "amdgpu/yellow_carp_vcn.bin" +#define FIRMWARE_VCN_3_1_2 "amdgpu/vcn_3_1_2.bin" +#define FIRMWARE_VCN4_0_0 "amdgpu/vcn_4_0_0.bin" +#define FIRMWARE_VCN4_0_2 "amdgpu/vcn_4_0_2.bin" +#define FIRMWARE_VCN4_0_4 "amdgpu/vcn_4_0_4.bin" MODULE_FIRMWARE(FIRMWARE_RAVEN); MODULE_FIRMWARE(FIRMWARE_PICASSO); -- 2.39.0
