[Bug 208611] amdgpu crash on sharing image memory between Vulkan and OpenGL
https://bugzilla.kernel.org/show_bug.cgi?id=208611 Ivan Molodetskikh (yalt...@gmail.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Ivan Molodetskikh (yalt...@gmail.com) --- This was resolved in mesa; forgot to close this. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[drm-misc:for-linux-next 10/12] drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c:422:31: warning: cast to pointer from integer of different size
tree: git://anongit.freedesktop.org/drm/drm-misc for-linux-next
head: 82d750e9d2f5d0594c8f7057ce59127e701af781
commit: 6b252cf42281045a9f803d2198023500cfa6ebd2 [10/12] drm/nouveau: nvkm/vmm:
implement raw ops to manage uvmm
config: mips-allyesconfig
(https://download.01.org/0day-ci/archive/20230805/202308050843.67kjqpqz-...@intel.com/config)
compiler: mips-linux-gcc (GCC) 12.3.0
reproduce:
(https://download.01.org/0day-ci/archive/20230805/202308050843.67kjqpqz-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202308050843.67kjqpqz-...@intel.com/
All warnings (new ones prefixed by >>):
In file included from drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h:4,
from drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.h:5,
from drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c:22:
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c: In function
'nvkm_uvmm_mthd_raw_map':
>> drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c:422:31: warning: cast to
>> pointer from integer of different size [-Wint-to-pointer-cast]
422 | (void *)args->argv, args->argc);
| ^
drivers/gpu/drm/nouveau/include/nvkm/core/memory.h:66:43: note: in
definition of macro 'nvkm_memory_map'
66 | (p)->func->map((p),(o),(vm),(va),(av),(ac))
| ^~
vim +422 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c
388
389 static int
390 nvkm_uvmm_mthd_raw_map(struct nvkm_uvmm *uvmm, struct nvif_vmm_raw_v0
*args)
391 {
392 struct nvkm_client *client = uvmm->object.client;
393 struct nvkm_vmm *vmm = uvmm->vmm;
394 struct nvkm_vma vma = {
395 .addr = args->addr,
396 .size = args->size,
397 .used = true,
398 .mapref = false,
399 .no_comp = true,
400 };
401 struct nvkm_memory *memory;
402 u64 handle = args->memory;
403 u8 refd;
404 int ret;
405
406 if (!nvkm_vmm_in_managed_range(vmm, args->addr, args->size))
407 return -EINVAL;
408
409 ret = nvkm_uvmm_page_index(uvmm, args->size, args->shift,
);
410 if (ret)
411 return ret;
412
413 vma.page = vma.refd = refd;
414
415 memory = nvkm_umem_search(client, args->memory);
416 if (IS_ERR(memory)) {
417 VMM_DEBUG(vmm, "memory %016llx %ld\n", handle,
PTR_ERR(memory));
418 return PTR_ERR(memory);
419 }
420
421 ret = nvkm_memory_map(memory, args->offset, vmm, ,
> 422(void *)args->argv, args->argc);
423
424 nvkm_memory_unref();
425 nvkm_memory_unref();
426 return ret;
427 }
428
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: [PATCH 1/2] dt-bindings: display/msm: document DPU on SM7150
On Thu, 03 Aug 2023 22:47:23 +0300, Danila Tikhonov wrote: > Document the DPU hardware found on the Qualcomm SM7150 platform. > > Signed-off-by: Danila Tikhonov > --- > .../bindings/display/msm/qcom,sm7150-dpu.yaml | 116 ++ > 1 file changed, 116 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/msm/qcom,sm7150-dpu.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: Documentation/devicetree/bindings/display/msm/qcom,sm7150-dpu.example.dts:24:18: fatal error: dt-bindings/clock/qcom,sm7150-dispcc.h: No such file or directory 24 | #include | ^~~~ compilation terminated. make[2]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/display/msm/qcom,sm7150-dpu.example.dtb] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1500: dt_binding_check] Error 2 make: *** [Makefile:234: __sub-make] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230803194724.154591-2-dan...@jiaxyga.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: nouveau bug in linux/6.1.38-2
On Fri, Aug 4, 2023 at 8:10 PM Olaf Skibbe wrote: > > Dear all, > > On Fri, 4 Aug 2023 at 14:15, Karol Herbst wrote: > > >>> 62aecf23f3d1 drm/nouveau: add nv_encoder pointer check for NULL > >>> fb725beca62d drm/nouveau/dp: check for NULL nv_connector->native_mode > >>> 90748be0f4f3 drm/nouveau: don't detect DSM for non-NVIDIA device > >>> 5a144bad3e75 nouveau: fix client work fence deletion race > > > > mind retrying with only fb725beca62d and 62aecf23f3d1 reverted? Would > > be weird if the other two commits are causing it. If that's the case, > > it's a bit worrying that reverting either of the those causes issues, > > but maybe there is a good reason for it. Anyway, mind figuring out > > which of the two you need reverted to fix your issue? Thanks! > > The result is: > > Patch with commit fb725beca62d reverted: Graphics works. I attached the > respective patch again to this mail. > Mind checking if instead of reverting the entire commit that this is enough to fix it as well? https://gitlab.freedesktop.org/karolherbst/nouveau/-/commit/f99ae069876f7ffeb6368da0381485e8c3adda43.patch > Patch with commit 62aecf23f3d1 reverted: Screen remains black, error > message: > > # dmesg | grep -A 36 "cut here" > [2.921358] [ cut here ] > [2.921361] WARNING: CPU: 1 PID: 176 at > drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c:460 nvkm_dp_acquire+0x26a/0x490 > [nouveau] > [2.921627] Modules linked in: sd_mod(E) t10_pi(E) crc64_rocksoft(E) > sr_mod(E) crc64(E) crc_t10dif(E) crct10dif_generic(E) cdrom(E) nouveau(E+) > mxm_wmi(E) i2c_algo_bit(E) drm_display_helper(E) cec(E) ahci(E) rc_core(E) > drm_ttm_helper(E) libahci(E) ttm(E) ehci_pci(E) crct10dif_pclmul(E) > crct10dif_common(E) ehci_hcd(E) drm_kms_helper(E) crc32_pclmul(E) > firewire_ohci(E) sdhci_pci(E) cqhci(E) libata(E) e1000e(E) sdhci(E) > psmouse(E) crc32c_intel(E) lpc_ich(E) ptp(E) i2c_i801(E) scsi_mod(E) > i2c_smbus(E) firewire_core(E) scsi_common(E) usbcore(E) crc_itu_t(E) > mmc_core(E) drm(E) pps_core(E) usb_common(E) battery(E) video(E) wmi(E) > button(E) > [2.921695] CPU: 1 PID: 176 Comm: kworker/u16:5 Tainted: GE > 6.1.0-0.a.test-amd64 #1 Debian 6.1.38-2a~test > [2.921701] Hardware name: Dell Inc. Latitude E6510/0N5KHN, BIOS A17 > 05/12/2017 > [2.921705] Workqueue: nvkm-disp nv50_disp_super [nouveau] > [2.921948] RIP: 0010:nvkm_dp_acquire+0x26a/0x490 [nouveau] > [2.922192] Code: 48 8b 44 24 58 65 48 2b 04 25 28 00 00 00 0f 85 37 02 00 > 00 48 83 c4 60 44 89 e0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc <0f> 0b > c1 e8 03 41 88 6d 62 44 89 fe 48 89 df 48 69 c0 cf 0d d6 26 > [2.922196] RSP: 0018:c077c04dfd60 EFLAGS: 00010246 > [2.922201] RAX: 00041eb0 RBX: 9a8482624c00 RCX: > 00041eb0 > [2.922204] RDX: c0b47760 RSI: RDI: > c077c04dfcf0 > [2.922206] RBP: 0001 R08: c077c04dfc64 R09: > 5b76 > [2.922209] R10: 000d R11: c077c04dfde0 R12: > ffea > [2.922212] R13: 9a8517541e00 R14: 00044d45 R15: > > [2.922215] FS: () GS:9a85a3c4() > knlGS: > [2.922219] CS: 0010 DS: ES: CR0: 80050033 > [2.92] CR2: 55f660bcb3a8 CR3: 00019761 CR4: > 06e0 > [2.96] Call Trace: > [2.922231] > [2.922235] ? __warn+0x7d/0xc0 > [2.922244] ? nvkm_dp_acquire+0x26a/0x490 [nouveau] > [2.922487] ? report_bug+0xe6/0x170 > [2.922494] ? handle_bug+0x41/0x70 > [2.922501] ? exc_invalid_op+0x13/0x60 > [2.922505] ? asm_exc_invalid_op+0x16/0x20 > [2.922512] ? init_reset_begun+0x20/0x20 [nouveau] > [2.922708] ? nvkm_dp_acquire+0x26a/0x490 [nouveau] > [2.922954] nv50_disp_super_2_2+0x70/0x430 [nouveau] > [2.923200] nv50_disp_super+0x113/0x210 [nouveau] > [2.923445] process_one_work+0x1c7/0x380 > [2.923456] worker_thread+0x4d/0x380 > [2.923463] ? rescuer_thread+0x3a0/0x3a0 > [2.923469] kthread+0xe9/0x110 > [2.923476] ? kthread_complete_and_exit+0x20/0x20 > [2.923482] ret_from_fork+0x22/0x30 > [2.923493] > [2.923494] ---[ end trace ]--- > > (Maybe it's worth to mention that the LED back-light is on, while the > screen appears black.) > > Cheers, > Olaf > > P.S.: By the way: as a linux user for more than 20 years, I am very > pleased to have the opportunity to contribute at least a little bit to > the improvement. I'd like to use the chance to thank you all very much > for building and developing this great operating system.
Re: [PATCH] drm: Drop select FRAMEBUFFER_CONSOLE for DRM_FBDEV_EMULATION
Randy Dunlap writes:
Hello Randy,
> On 8/4/23 05:51, Javier Martinez Canillas wrote:
>> The commit c242f48433e7 ("drm: Make FB_CORE to be selected if DRM fbdev
>> emulation is enabled") changed DRM_FBDEV_EMULATION from 'depends on FB'
>> to an effective 'select FB_CORE', so any config that previously had DRM=y
>> and FB=n now has FB_CORE=y and FRAMEBUFFER_CONSOLE=y.
>>
>> This leads to unmet direct dependencies detected for FRAMEBUFFER_CONSOLE
>> as reported by Arthur Grillo, e.g:
>>
>> WARNING: unmet direct dependencies detected for FRAMEBUFFER_CONSOLE
>> Depends on [n]: VT [=n] && FB_CORE [=y] && !UML [=y]
>> Selected by [y]:
>> - DRM_FBDEV_EMULATION [=y] && HAS_IOMEM [=y] && DRM [=y] && !EXPERT [=n]
>>
>> Arnd Bergmann suggests to drop the select FRAMEBUFFER_CONSOLE for the
>> DRM_FBDEV_EMULATION Kconfig symbol, since a possible use case could
>> be to enable DRM fbdev emulation but without a framebuffer console.
>>
>> Fixes: c242f48433e7 ("drm: Make FB_CORE to be selected if DRM fbdev
>> emulation is enabled")
>> Reported-by: Arthur Grillo
>> Closes:
>> https://lore.kernel.org/dri-devel/20230726220325.278976-1-arthurgri...@riseup.net
>> Suggested-by: Arnd Bergmann
>> Signed-off-by: Javier Martinez Canillas
>
> Acked-by: Randy Dunlap
> Tested-by: Randy Dunlap # build-tested
>
I have already pushed this patch so I won't be able to add these tags but
thanks a lot for testing and confirming that the patch fixes your issue!
> Thanks.
>
>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
RE: [RFC v1 1/3] mm/mmu_notifier: Add a new notifier for mapping updates (new pages)
Hi David, > > > Right, the "the zero pages are changed into writable pages" in your > above comment just might not apply, because there won't be any > >> page > replacement (hopefully :) ). > >> > >>> If the page replacement does not happen when there are new > writes > >> to the > >>> area where the hole previously existed, then would we still get an > >> invalidate > >>> when this happens? Is there any other way to get notified when the > >> zeroed > >>> page is written to if the invalidate does not get triggered? > >> > >> What David is saying is that memfd does not use the zero page > >> optimization for hole punches. Any access to the memory, including > >> read-only access through hmm_range_fault() will allocate unique > >> pages. Since there is no zero page and no zero-page replacement > there > >> is no issue with invalidations. > > > It looks like even with hmm_range_fault(), the invalidate does not get > > triggered when the hole is refilled with new pages because of writes. > > This is probably because hmm_range_fault() does not fault in any > pages > > that get invalidated later when writes occur. > hmm_range_fault() returns the current content of the VMAs, or it > faults. If it returns pages then it came from one of these two places. > If your VMA is incoherent with what you are doing then you have > bigger > problems, or maybe you found a bug. > >> > >> Note it will only fault in pages if HMM_PFN_REQ_FAULT is specified. You > >> are setting that however you aren't setting HMM_PFN_REQ_WRITE which > is > >> what would trigger a fault to bring in the new pages. Does setting that > >> fix the issue you are seeing? > > No, adding HMM_PFN_REQ_WRITE still doesn't help in fixing the issue. > > Although, I do not have THP enabled (or built-in), shmem does not evict > > the pages after hole punch as noted in the comment in shmem_fallocate(): > > if ((u64)unmap_end > (u64)unmap_start) > > unmap_mapping_range(mapping, unmap_start, > > 1 + unmap_end - unmap_start, > > 0); > > shmem_truncate_range(inode, offset, offset + len - 1); > > /* No need to unmap again: hole-punching leaves COWed pages > */ > > > > As a result, the pfn is still valid and the pte is pte_present() and > > pte_write(). > > This is the reason why adding in HMM_PFN_REQ_WRITE does not help; > > Just to understand your setup: you are definitely using a MAP_SHARED > shmem mapping, and not accidentally a MAP_PRIVATE mapping? In terms of setup, I am just running the udmabuf selftest (shmem-based) introduced in patch #3 of this series: https://lore.kernel.org/all/20230718082858.1570809-4-vivek.kasire...@intel.com/ And, it indeed uses a MAP_SHARED mapping. Thanks, Vivek > > -- > Cheers, > > David / dhildenb
[RFC] PM / QoS: Decouple request alloc from dev_pm_qos_mtx (alternative solution)
From: Rob Clark
Similar to the previous patch, move the allocation out from under
dev_pm_qos_mtx, by speculatively doing the allocation and handle
any race after acquiring dev_pm_qos_mtx by freeing the redundant
allocation.
Suggested-by: Rafael J. Wysocki
Signed-off-by: Rob Clark
---
This is an alternative to
https://patchwork.freedesktop.org/patch/551417/?series=115028=4
So, this does _slightly_ change error paths, for ex
dev_pm_qos_update_user_latency_tolerance() will now allocate
dev->power.qos in some error cases. But this seems harmless?
A slightly more complicated version of this could conserve the
previous error path behavior, but I figured I'd try the simpler
thing first.
drivers/base/power/qos.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/base/power/qos.c b/drivers/base/power/qos.c
index 1b73a704aac1..c7ba85e89c42 100644
--- a/drivers/base/power/qos.c
+++ b/drivers/base/power/qos.c
@@ -920,8 +920,12 @@ s32 dev_pm_qos_get_user_latency_tolerance(struct device
*dev)
int dev_pm_qos_update_user_latency_tolerance(struct device *dev, s32 val)
{
struct dev_pm_qos *qos = dev_pm_qos_constraints_allocate();
+ struct dev_pm_qos_request *req = NULL;
int ret = 0;
+ if (!dev->power.qos->latency_tolerance_req)
+ req = kzalloc(sizeof(*req), GFP_KERNEL);
+
mutex_lock(_pm_qos_mtx);
dev_pm_qos_constraints_set(dev, qos);
@@ -935,8 +939,6 @@ int dev_pm_qos_update_user_latency_tolerance(struct device
*dev, s32 val)
goto out;
if (!dev->power.qos->latency_tolerance_req) {
- struct dev_pm_qos_request *req;
-
if (val < 0) {
if (val == PM_QOS_LATENCY_TOLERANCE_NO_CONSTRAINT)
ret = 0;
@@ -944,17 +946,15 @@ int dev_pm_qos_update_user_latency_tolerance(struct
device *dev, s32 val)
ret = -EINVAL;
goto out;
}
- req = kzalloc(sizeof(*req), GFP_KERNEL);
if (!req) {
ret = -ENOMEM;
goto out;
}
ret = __dev_pm_qos_add_request(dev, req,
DEV_PM_QOS_LATENCY_TOLERANCE, val);
- if (ret < 0) {
- kfree(req);
+ if (ret < 0)
goto out;
- }
dev->power.qos->latency_tolerance_req = req;
+ req = NULL;
} else {
if (val < 0) {
__dev_pm_qos_drop_user_request(dev,
DEV_PM_QOS_LATENCY_TOLERANCE);
@@ -966,6 +966,7 @@ int dev_pm_qos_update_user_latency_tolerance(struct device
*dev, s32 val)
out:
mutex_unlock(_pm_qos_mtx);
+ kfree(req);
return ret;
}
EXPORT_SYMBOL_GPL(dev_pm_qos_update_user_latency_tolerance);
--
2.41.0
Re: [Intel-xe] [PATCH v5] Documentation/gpu: Add a VM_BIND async draft document
On Fri, 2023-08-04 at 16:02 -0400, Rodrigo Vivi wrote: > On Wed, Jul 19, 2023 at 07:50:21PM +, Zanoni, Paulo R wrote: > > On Sat, 2023-07-15 at 17:45 +0200, Thomas Hellström wrote: > > > Add a motivation for and description of asynchronous VM_BIND operation > > > > I think I may have missed some other documentation, which would explain > > some of my questions below, so please be patient with my > > misunderstandings. But here's a review from the POV of a UMD person. > > > > > > > > > > v2: > > > - Fix typos (Nirmoy Das) > > > - Improve the description of a memory fence (Oak Zeng) > > > - Add a reference to the document in the Xe RFC. > > > - Add pointers to sample uAPI suggestions > > > v3: > > > - Address review comments (Danilo Krummrich) > > > - Formatting fixes > > > v4: > > > - Address typos (Francois Dugast) > > > - Explain why in-fences are not allowed for VM_BIND operations for long- > > > running workloads (Matthew Brost) > > > v5: > > > - More typo- and style fixing > > > - Further clarify the implications of disallowing in-fences for VM_BIND > > > operations for long-running workloads (Matthew Brost) > > > > > > Signed-off-by: Thomas Hellström > > > Acked-by: Nirmoy Das > > > --- > > > Documentation/gpu/drm-vm-bind-async.rst | 171 > > > Documentation/gpu/rfc/xe.rst| 4 +- > > > 2 files changed, 173 insertions(+), 2 deletions(-) > > > create mode 100644 Documentation/gpu/drm-vm-bind-async.rst > > > > > > diff --git a/Documentation/gpu/drm-vm-bind-async.rst > > > b/Documentation/gpu/drm-vm-bind-async.rst > > > new file mode 100644 > > > index ..d2b02a38198a > > > --- /dev/null > > > +++ b/Documentation/gpu/drm-vm-bind-async.rst > > > @@ -0,0 +1,171 @@ > > > + > > > +Asynchronous VM_BIND > > > + > > > + > > > +Nomenclature: > > > += > > > + > > > +* ``VRAM``: On-device memory. Sometimes referred to as device local > > > memory. > > > + > > > +* ``gpu_vm``: A GPU address space. Typically per process, but can be > > > shared by > > > + multiple processes. > > > + > > > +* ``VM_BIND``: An operation or a list of operations to modify a gpu_vm > > > using > > > + an IOCTL. The operations include mapping and unmapping system- or > > > + VRAM memory. > > > + > > > +* ``syncobj``: A container that abstracts synchronization objects. The > > > + synchronization objects can be either generic, like dma-fences or > > > + driver specific. A syncobj typically indicates the type of the > > > + underlying synchronization object. > > > + > > > +* ``in-syncobj``: Argument to a VM_BIND IOCTL, the VM_BIND operation > > > waits > > > + for these before starting. > > > + > > > +* ``out-syncobj``: Argument to a VM_BIND_IOCTL, the VM_BIND operation > > > + signals these when the bind operation is complete. > > > + > > > +* ``memory fence``: A synchronization object, different from a dma-fence. > > > > Since you've mentioned it twice in this document already, for > > completeness would you mind also giving a definition for dma-fence in > > what it relates/contrasts to the rest of the text? > > Maybe worth a link to the dma-fence doc itself? > (somehow making sphinx to point out to driver-api/dma-buf.html#dma-fences) > > But the differences are written below Paulo: > > > > > > > > + A memory fence uses the value of a specified memory location to > > > determine > > > + signaled status. A memory fence can be awaited and signaled by both > > > + the GPU and CPU. Memory fences are sometimes referred to as > > > + user-fences, userspace-fences or gpu futexes and do not necessarily > > > obey > > > + the dma-fence rule of signaling within a "reasonable amount of time". > > > + The kernel should thus avoid waiting for memory fences with locks held. > > ^ > > > > + > > > +* ``long-running workload``: A workload that may take more than the > > > + current stipulated dma-fence maximum signal delay to complete and > > > > Where is this delay defined? Is this the same as the gpuhang timer? > > dma-fence defines it in a very "cool" way: "reasonable amount of time": > https://www.kernel.org/doc/html/latest/driver-api/dma-buf.html#dma-fences > > so, in contrast, long-running workload is *anything* above that > "reasonable amount of time". That answers it but doesn't exactly answer it either. In practice, how much is that "reasonable amount of time"? This is documentation, it should avoid using vague statements or hypothetical cases. The documentation you posted suggested this may be the same as the GPU hang timeout, but doesn't give a definitive answer (because multiple drivers may define it differently, apparently). In practice, what do drivers do? As a user-space developer, how long can I wait before things fail? Is there a way to figure out, maybe query a parameter somewhere? Which driver waits the least? Which driver waits the most? Is 10 seconds "reasonable amount of time"? My
[Bug 217764] New: nouveau: system hangs when changing pstate on GeForce GT 320M (NVAF (MCP89))
https://bugzilla.kernel.org/show_bug.cgi?id=217764 Bug ID: 217764 Summary: nouveau: system hangs when changing pstate on GeForce GT 320M (NVAF (MCP89)) Product: Drivers Version: 2.5 Hardware: i386 OS: Linux Status: NEW Severity: normal Priority: P3 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: dsw...@outlook.com Regression: No Created attachment 304780 --> https://bugzilla.kernel.org/attachment.cgi?id=304780=edit Crash log System hangs after pstate is changed with /sys/kernel/debug/dri/0/pstate interface to any option (like 0f). It hangs sometimes right after changing, and sometimes after few moments. According to kernel log it seems it attempts to divide by zero for some reason in gt215_clk_info (drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c) and fails with divide by zero interrupt which causes system to hang. It happens on MacbookPro7,1 (Macbook Pro 13 inch Mid 2010) with NVIDIA GeForce GT 320M on Fedora 38 with Linux version 6.4.7-200.fc38.x86_64. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[RFC PATCH 09/10] drm/panel: sony-acx565akm: Don't double-check enabled state in disable
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
The acx565akm seems to do some unique stuff with the "enabled"
state. Specifically:
1. It seems to detect the enabled state based on how the bootloader
left the panel.
2. It uses the enabled state to prevent certain sysfs files from
accessing a disabled panel.
We'll leave the "enabled" state tracking for this. However, we can at
least get rid of the double-check when trying to disable. In order to
do this we use the new drm_panel_helper_shutdown() from remove() which
double-checks for us.
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/panel/panel-sony-acx565akm.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
index 3d6a286056a0..8a8326a94d72 100644
--- a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
+++ b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#define CTRL_DISP_BRIGHTNESS_CTRL_ON BIT(5)
#define CTRL_DISP_AMBIENT_LIGHT_CTRL_ONBIT(4)
@@ -454,9 +455,6 @@ static int acx565akm_power_on(struct acx565akm_panel *lcd)
static void acx565akm_power_off(struct acx565akm_panel *lcd)
{
- if (!lcd->enabled)
- return;
-
acx565akm_set_display_state(lcd, 0);
acx565akm_set_sleep_mode(lcd, 1);
lcd->enabled = false;
@@ -656,8 +654,7 @@ static void acx565akm_remove(struct spi_device *spi)
if (lcd->has_bc)
acx565akm_backlight_cleanup(lcd);
- drm_panel_disable(>panel);
- drm_panel_unprepare(>panel);
+ drm_panel_helper_shutdown(>panel);
}
static const struct of_device_id acx565akm_of_match[] = {
--
2.41.0.585.gd2178a4bd4-goog
[RFC PATCH 10/10] drm/panel: Update TODO list item for cleaning up prepared/enabled tracking
Now that most panels have been updated not to track/double-check their
prepared/enabled state update the TODO with next steps.
Signed-off-by: Douglas Anderson
---
Documentation/gpu/todo.rst | 33 +
1 file changed, 13 insertions(+), 20 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 139980487ccf..c73d9dbebbf4 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -460,26 +460,19 @@ Contact: Thomas Zimmermann
Level: Starter
-Clean up checks for already prepared/enabled in panels
---
-
-In a whole pile of panel drivers, we have code to make the
-prepare/unprepare/enable/disable callbacks behave as no-ops if they've already
-been called. To get some idea of the duplicated code, try::
-
- git grep 'if.*>prepared' -- drivers/gpu/drm/panel
- git grep 'if.*>enabled' -- drivers/gpu/drm/panel
-
-In the patch ("drm/panel: Check for already prepared/enabled in drm_panel")
-we've moved this check to the core. Now we can most definitely remove the
-check from the individual panels and save a pile of code.
-
-In adition to removing the check from the individual panels, it is believed
-that even the core shouldn't need this check and that should be considered
-an error if other code ever relies on this check. The check in the core
-currently prints a warning whenever something is relying on this check with
-dev_warn(). After a little while, we likely want to promote this to a
-WARN(1) to help encourage folks not to rely on this behavior.
+Never double prepare/enable/disable/unprepare a panel
+-
+
+As of commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in
+drm_panel"), we have a check in the drm_panel core to make sure nobody
+double-calls prepare/enable/disable/unprepare. However, that extra double-check
+shouldn't be necessary. The caller should always be matching up calls of
+prepare/unprepare and matching up calls of enable/disable.
+
+Hopefully the warning printed will encourage everyone to fix this. Eventually
+we'll likely want to change this to a WARN_ON and (perhaps) fully remove the
+check. NOTE: even if we remove the double-check, drm_panel core still needs
+to track the enabled/prepared state for its own purposes.
Contact: Douglas Anderson
--
2.41.0.585.gd2178a4bd4-goog
[RFC PATCH 08/10] drm/panel: rm67191: Don't store+check enabled
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
The conversion of the rm67191 panel driver follows many of the other
panel drivers but is separated out because it has a few differences
that need to be called out.
Like otm8009a, this panel also uses the "prepared" flag to prevent the
backlight functions from running when the panel is powered off. This
is probably not the safest thing to do but the old behavior was
preserved. See the discussion in the patch ("drm/panel: otm8009a:
Don't double check prepared/enabled"). Because of this, I've left the
driver tracking "prepared" but removed its tracking of "enabled".
This panel also used to directly call its disable/unprepare functions
at shutdown time instead of calling into drm_panel. Now we're calling
drm_panel_helper_shutdown() which in turn calls
drm_panel_unprepare()/drm_panel_disable(). That paves the way if
anyone wants to use a the panel follower APIs with this panel.
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/panel/panel-raydium-rm67191.c | 21 ++-
1 file changed, 2 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-raydium-rm67191.c
b/drivers/gpu/drm/panel/panel-raydium-rm67191.c
index dbb1ed4efbed..fb378924c0b3 100644
--- a/drivers/gpu/drm/panel/panel-raydium-rm67191.c
+++ b/drivers/gpu/drm/panel/panel-raydium-rm67191.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
/* Panel specific color-format bits */
#define COL_FMT_16BPP 0x55
@@ -205,7 +206,6 @@ struct rad_panel {
unsigned int num_supplies;
bool prepared;
- bool enabled;
};
static const struct drm_display_mode default_mode = {
@@ -267,9 +267,6 @@ static int rad_panel_prepare(struct drm_panel *panel)
struct rad_panel *rad = to_rad_panel(panel);
int ret;
- if (rad->prepared)
- return 0;
-
ret = regulator_bulk_enable(rad->num_supplies, rad->supplies);
if (ret)
return ret;
@@ -291,9 +288,6 @@ static int rad_panel_unprepare(struct drm_panel *panel)
struct rad_panel *rad = to_rad_panel(panel);
int ret;
- if (!rad->prepared)
- return 0;
-
/*
* Right after asserting the reset, we need to release it, so that the
* touch driver can have an active connection with the touch controller
@@ -322,9 +316,6 @@ static int rad_panel_enable(struct drm_panel *panel)
int color_format = color_format_from_dsi_format(dsi->format);
int ret;
- if (rad->enabled)
- return 0;
-
dsi->mode_flags |= MIPI_DSI_MODE_LPM;
ret = rad_panel_push_cmd_list(dsi);
@@ -389,8 +380,6 @@ static int rad_panel_enable(struct drm_panel *panel)
backlight_enable(rad->backlight);
- rad->enabled = true;
-
return 0;
fail:
@@ -406,9 +395,6 @@ static int rad_panel_disable(struct drm_panel *panel)
struct device *dev = >dev;
int ret;
- if (!rad->enabled)
- return 0;
-
dsi->mode_flags |= MIPI_DSI_MODE_LPM;
backlight_disable(rad->backlight);
@@ -429,8 +415,6 @@ static int rad_panel_disable(struct drm_panel *panel)
return ret;
}
- rad->enabled = false;
-
return 0;
}
@@ -633,8 +617,7 @@ static void rad_panel_shutdown(struct mipi_dsi_device *dsi)
{
struct rad_panel *rad = mipi_dsi_get_drvdata(dsi);
- rad_panel_disable(>panel);
- rad_panel_unprepare(>panel);
+ drm_panel_helper_shutdown(>panel);
}
static const struct of_device_id rad_of_match[] = {
--
2.41.0.585.gd2178a4bd4-goog
[RFC PATCH 07/10] drm/panel: st7703: Don't store+check prepared
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
For the st7703 panel driver this is fairly straightforward. Like with
many other panels, we need to use the new drm_panel_helper_shutdown()
function to make sure that remove() and shutdown() don't try to
disable/unprepare a panel that hasn't been prepared/enabled. One thing
that is a little different for st7703 is that it has a special
"allpixelson" debugfs file. When this file is written the driver hacks
a disable/unprepare and then a prepare/enable to try to reset the
panel. This debugfs file didn't appear to be particularly safe to use
even before this patch since it would cause a disabled/unprepared
panel to become prepared/enabled. It is nominally even less safe after
this patch since calling it on a panel that wasn't prepared/enabled
will now likely cause a regulator underflow message. If this matters
to anyone, it could be fixed in a future patch.
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 20 ++-
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
index 6a3945639535..dde903e803d1 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#define DRV_NAME "panel-sitronix-st7703"
@@ -58,7 +59,6 @@ struct st7703 {
struct gpio_desc *reset_gpio;
struct regulator *vcc;
struct regulator *iovcc;
- bool prepared;
struct dentry *debugfs;
const struct st7703_panel_desc *desc;
@@ -486,13 +486,9 @@ static int st7703_unprepare(struct drm_panel *panel)
{
struct st7703 *ctx = panel_to_st7703(panel);
- if (!ctx->prepared)
- return 0;
-
gpiod_set_value_cansleep(ctx->reset_gpio, 1);
regulator_disable(ctx->iovcc);
regulator_disable(ctx->vcc);
- ctx->prepared = false;
return 0;
}
@@ -502,9 +498,6 @@ static int st7703_prepare(struct drm_panel *panel)
struct st7703 *ctx = panel_to_st7703(panel);
int ret;
- if (ctx->prepared)
- return 0;
-
dev_dbg(ctx->dev, "Resetting the panel\n");
ret = regulator_enable(ctx->vcc);
if (ret < 0) {
@@ -522,8 +515,6 @@ static int st7703_prepare(struct drm_panel *panel)
gpiod_set_value_cansleep(ctx->reset_gpio, 0);
msleep(20);
- ctx->prepared = true;
-
return 0;
disable_vcc:
@@ -665,15 +656,8 @@ static int st7703_probe(struct mipi_dsi_device *dsi)
static void st7703_shutdown(struct mipi_dsi_device *dsi)
{
struct st7703 *ctx = mipi_dsi_get_drvdata(dsi);
- int ret;
- ret = drm_panel_unprepare(>panel);
- if (ret < 0)
- dev_err(>dev, "Failed to unprepare panel: %d\n", ret);
-
- ret = drm_panel_disable(>panel);
- if (ret < 0)
- dev_err(>dev, "Failed to disable panel: %d\n", ret);
+ drm_panel_helper_shutdown(>panel);
}
static void st7703_remove(struct mipi_dsi_device *dsi)
--
2.41.0.585.gd2178a4bd4-goog
[RFC PATCH 06/10] drm/panel: Don't store+check prepared/enabled for panels disabled at shutdown
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
This is much like the patch ("drm/panel: Don't store+check
prepared/enabled for panels needing shutdown") but this set of panels
used to _just_ call their disable() function at shutdown time. Now
both the disable() and unprepare() will be called. This is probably an
improvement and probably makes the power sequencing more correct, but
it is a change in behavior that needs to be called out. It also has
the potential to delay shutdown by a small amount of time.
As talked about in patch ("drm/panel: Don't store+check
prepared/enabled for panels needing shutdown"), this patch doesn't
attempt to validate that any remove() functions touched will actually
work properly. The main goal here is to avoid storing and
double-checking the prepared and enabled state.
Signed-off-by: Douglas Anderson
---
.../gpu/drm/panel/panel-jdi-lt070me05000.c| 30 ++--
.../drm/panel/panel-panasonic-vvx10f034n00.c | 42 ++---
drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 45 ++
.../gpu/drm/panel/panel-sharp-lq101r1sx01.c | 46 ++-
.../gpu/drm/panel/panel-sharp-ls043t1le01.c | 19 ++--
5 files changed, 16 insertions(+), 166 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
index 8f4f137a2af6..28b7ae491d12 100644
--- a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
+++ b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
static const char * const regulator_names[] = {
"vddp",
@@ -41,9 +42,6 @@ struct jdi_panel {
struct gpio_desc *dcdc_en_gpio;
struct backlight_device *backlight;
- bool prepared;
- bool enabled;
-
const struct drm_display_mode *mode;
};
@@ -180,13 +178,8 @@ static int jdi_panel_disable(struct drm_panel *panel)
{
struct jdi_panel *jdi = to_jdi_panel(panel);
- if (!jdi->enabled)
- return 0;
-
backlight_disable(jdi->backlight);
- jdi->enabled = false;
-
return 0;
}
@@ -196,9 +189,6 @@ static int jdi_panel_unprepare(struct drm_panel *panel)
struct device *dev = >dsi->dev;
int ret;
- if (!jdi->prepared)
- return 0;
-
jdi_panel_off(jdi);
ret = regulator_bulk_disable(ARRAY_SIZE(jdi->supplies), jdi->supplies);
@@ -211,8 +201,6 @@ static int jdi_panel_unprepare(struct drm_panel *panel)
gpiod_set_value(jdi->dcdc_en_gpio, 0);
- jdi->prepared = false;
-
return 0;
}
@@ -222,9 +210,6 @@ static int jdi_panel_prepare(struct drm_panel *panel)
struct device *dev = >dsi->dev;
int ret;
- if (jdi->prepared)
- return 0;
-
ret = regulator_bulk_enable(ARRAY_SIZE(jdi->supplies), jdi->supplies);
if (ret < 0) {
dev_err(dev, "regulator enable failed, %d\n", ret);
@@ -254,8 +239,6 @@ static int jdi_panel_prepare(struct drm_panel *panel)
goto poweroff;
}
- jdi->prepared = true;
-
return 0;
poweroff:
@@ -276,13 +259,8 @@ static int jdi_panel_enable(struct drm_panel *panel)
{
struct jdi_panel *jdi = to_jdi_panel(panel);
- if (jdi->enabled)
- return 0;
-
backlight_enable(jdi->backlight);
- jdi->enabled = true;
-
return 0;
}
@@ -487,9 +465,7 @@ static void jdi_panel_remove(struct mipi_dsi_device *dsi)
struct jdi_panel *jdi = mipi_dsi_get_drvdata(dsi);
int ret;
- ret = jdi_panel_disable(>base);
- if (ret < 0)
- dev_err(>dev, "failed to disable panel: %d\n", ret);
+ drm_panel_helper_shutdown(>base);
ret = mipi_dsi_detach(dsi);
if (ret < 0)
@@ -503,7 +479,7 @@ static void jdi_panel_shutdown(struct mipi_dsi_device *dsi)
{
struct jdi_panel *jdi = mipi_dsi_get_drvdata(dsi);
- jdi_panel_disable(>base);
+ drm_panel_helper_shutdown(>base);
}
static struct mipi_dsi_driver jdi_panel_driver = {
diff --git a/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
b/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
index 8ba6d8287938..1a4121bd0ec1 100644
--- a/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
+++ b/drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
/*
* When power is turned off to this panel a minimum off time of 500ms has to be
@@ -32,9 +33,6 @@ struct wuxga_nt_panel {
struct regulator *supply;
- bool prepared;
- bool enabled;
-
ktime_t earliest_wake;
[RFC PATCH 05/10] drm/panel: Don't store+check prepared/enabled for panels needing shutdown
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
A number of panels seemed to need the extra double-checking of the
prepared/enabled state to handle driver remove and/or shutdown. This
set of drivers was easy to transform and used to call
drm_panel_unprepare() and drm_panel_disable(). It's easy to move them
to call the drm_panel_helper_shutdown() that does the double-checking
for the panels.
NOTE: this patch doesn't attempt to sanitize the shutdown or remove
functions of these panels, it merely tries to preserve the old
behavior while removing the need for the panels to track
prepared/enabled state themselves. Specifically it can be noted that
removing an in-use panel is not necessarily straightfoward and may not
be correct in most panels.
ALSO NOTE: some of the panels touched in this path used to not
complain about disable/unprepare error at shutdown time. Now that
we're using the drm_panel_helper_shutdown() function we'll
consistently warn about these errors.
THIRDLY NOTE: One of these panels, "boe-himax8279d", used to call its
unprepare() and disable() functions directly instead of calling
drm_panel_unprepare() and drm_panel_disable(). I believe that the only
difference is that "boe-himax8279d" will now turn off its backlight at
shutdown/remove. This will also pave the way if anyone wants to use
this panel w/ the new "panel follower" APIs.
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/panel/panel-boe-himax8279d.c | 36 ++---
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 16 +-
drivers/gpu/drm/panel/panel-edp.c | 34 ++---
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 21 +---
drivers/gpu/drm/panel/panel-himax-hx8394.c| 21 +---
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 51 ++-
drivers/gpu/drm/panel/panel-khadas-ts050.c| 35 ++---
.../drm/panel/panel-kingdisplay-kd097d04.c| 43 ++--
.../drm/panel/panel-leadtek-ltk050h3146w.c| 21 +---
.../drm/panel/panel-leadtek-ltk500hd1829.c| 21 +---
.../gpu/drm/panel/panel-novatek-nt36672a.c| 24 ++---
.../drm/panel/panel-olimex-lcd-olinuxino.c| 45 +---
.../drm/panel/panel-osd-osd101t2587-53ts.c| 37 ++
.../gpu/drm/panel/panel-samsung-atna33xc20.c | 31 ++-
drivers/gpu/drm/panel/panel-simple.c | 34 ++---
drivers/gpu/drm/panel/panel-tdo-tl070wsh30.c | 19 ++-
.../gpu/drm/panel/panel-xinpeng-xpp055c272.c | 21 +---
17 files changed, 45 insertions(+), 465 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-boe-himax8279d.c
b/drivers/gpu/drm/panel/panel-boe-himax8279d.c
index 11b64acbe8a9..cccf9400fa99 100644
--- a/drivers/gpu/drm/panel/panel-boe-himax8279d.c
+++ b/drivers/gpu/drm/panel/panel-boe-himax8279d.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
@@ -47,9 +48,6 @@ struct panel_info {
struct gpio_desc *enable_gpio;
struct gpio_desc *pp33_gpio;
struct gpio_desc *pp18_gpio;
-
- bool prepared;
- bool enabled;
};
static inline struct panel_info *to_panel_info(struct drm_panel *panel)
@@ -86,17 +84,12 @@ static int boe_panel_disable(struct drm_panel *panel)
struct panel_info *pinfo = to_panel_info(panel);
int err;
- if (!pinfo->enabled)
- return 0;
-
err = mipi_dsi_dcs_set_display_off(pinfo->link);
if (err < 0) {
dev_err(panel->dev, "failed to set display off: %d\n", err);
return err;
}
- pinfo->enabled = false;
-
return 0;
}
@@ -105,9 +98,6 @@ static int boe_panel_unprepare(struct drm_panel *panel)
struct panel_info *pinfo = to_panel_info(panel);
int err;
- if (!pinfo->prepared)
- return 0;
-
err = mipi_dsi_dcs_set_display_off(pinfo->link);
if (err < 0)
dev_err(panel->dev, "failed to set display off: %d\n", err);
@@ -121,8 +111,6 @@ static int boe_panel_unprepare(struct drm_panel *panel)
disable_gpios(pinfo);
- pinfo->prepared = false;
-
return 0;
}
@@ -131,9 +119,6 @@ static int boe_panel_prepare(struct drm_panel *panel)
struct panel_info *pinfo = to_panel_info(panel);
int err;
- if (pinfo->prepared)
- return 0;
-
gpiod_set_value(pinfo->pp18_gpio, 1);
/* T1: 5ms - 6ms */
usleep_range(5000, 6000);
@@ -180,8 +165,6 @@ static int boe_panel_prepare(struct drm_panel *panel)
/* T7: 20ms - 21ms */
usleep_range(2, 21000);
- pinfo->prepared = true;
-
return 0;
poweroff:
@@ -194,9 +177,6 @@ static
[RFC PATCH 03/10] drm/panel: otm8009a: Don't double check prepared/enabled
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
For the "otm8009a" driver we fully remove the storing of the "enabled"
state and we remove the double-checking, but we still keep the storing
of the "prepared" state since the backlight code in the driver checks
it. This backlight code may not be perfectly safe since there doesn't
appear to be sufficient synchronization between the backlight driver
(which userspace can call into directly) and the code that's
unpreparing the panel. However, this lack of safety is not new and can
be addressed in a future patch.
Signed-off-by: Douglas Anderson
---
>From quick inspection, I think the right way to handle the backlight
properly is:
1. Start calling backlight_get_brightness() instead of directly
getting "bd->props.brightness" and bd->props.power. This should
return 0 for a disabled (or blanked or powered off) backlight.
2. Cache the backlight level in "struct otm8009a"
3. If the backlight isn't changing compared to the cached value, make
otm8009a_backlight_update_status() a no-op.
4. Remove the caching of the "prepared" value.
That should work and always be safe because we always enable/disable
the backlight in the panel's enable() and disable() functions. The
backlight core has proper locking in this case. A disabled backlight
will always return a level of 0 which will always make the backlight's
update_status a no-op when the panel is disabled and keep us from
trying to talk to the panel when it's off. Userspace can't directly
cause a backlight to be enabled/disabled, it can only affect the other
blanking modes.
.../gpu/drm/panel/panel-orisetech-otm8009a.c| 17 -
1 file changed, 17 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
index 898b892f1143..93183f30d7d6 100644
--- a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
+++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
@@ -70,7 +70,6 @@ struct otm8009a {
struct gpio_desc *reset_gpio;
struct regulator *supply;
bool prepared;
- bool enabled;
};
static const struct drm_display_mode modes[] = {
@@ -267,9 +266,6 @@ static int otm8009a_disable(struct drm_panel *panel)
struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
int ret;
- if (!ctx->enabled)
- return 0; /* This is not an issue so we return 0 here */
-
backlight_disable(ctx->bl_dev);
ret = mipi_dsi_dcs_set_display_off(dsi);
@@ -282,8 +278,6 @@ static int otm8009a_disable(struct drm_panel *panel)
msleep(120);
- ctx->enabled = false;
-
return 0;
}
@@ -291,9 +285,6 @@ static int otm8009a_unprepare(struct drm_panel *panel)
{
struct otm8009a *ctx = panel_to_otm8009a(panel);
- if (!ctx->prepared)
- return 0;
-
if (ctx->reset_gpio) {
gpiod_set_value_cansleep(ctx->reset_gpio, 1);
msleep(20);
@@ -311,9 +302,6 @@ static int otm8009a_prepare(struct drm_panel *panel)
struct otm8009a *ctx = panel_to_otm8009a(panel);
int ret;
- if (ctx->prepared)
- return 0;
-
ret = regulator_enable(ctx->supply);
if (ret < 0) {
dev_err(panel->dev, "failed to enable supply: %d\n", ret);
@@ -341,13 +329,8 @@ static int otm8009a_enable(struct drm_panel *panel)
{
struct otm8009a *ctx = panel_to_otm8009a(panel);
- if (ctx->enabled)
- return 0;
-
backlight_enable(ctx->bl_dev);
- ctx->enabled = true;
-
return 0;
}
--
2.41.0.585.gd2178a4bd4-goog
[RFC PATCH 04/10] drm/panel_helper: Introduce drm_panel_helper
The goal of this file is to contain helper functions for panel drivers
to use. To start off with, let's add drm_panel_helper_shutdown() for
use by panels that want to make sure they're powered off at
shutdown/remove time if they happen to be powered on.
The main goal of introducting this function is so that panel drivers
don't need to track the enabled/prepared state themselves.
Signed-off-by: Douglas Anderson
---
If I've misunderstood and the drm_panel_helper_shutdown() should
belong in some other file and we don't need to introduce a "helper"
for this then please le me know.
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_panel_helper.c | 37 ++
include/drm/drm_panel_helper.h | 13 +++
3 files changed, 51 insertions(+)
create mode 100644 drivers/gpu/drm/drm_panel_helper.c
create mode 100644 include/drm/drm_panel_helper.h
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 215e78e79125..e811f3d68235 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -118,6 +118,7 @@ drm_kms_helper-y := \
drm_gem_framebuffer_helper.o \
drm_kms_helper_common.o \
drm_modeset_helper.o \
+ drm_panel_helper.o \
drm_plane_helper.o \
drm_probe_helper.o \
drm_rect.o \
diff --git a/drivers/gpu/drm/drm_panel_helper.c
b/drivers/gpu/drm/drm_panel_helper.c
new file mode 100644
index ..85a55b5731cf
--- /dev/null
+++ b/drivers/gpu/drm/drm_panel_helper.c
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2023 Google Inc.
+ */
+
+#include
+
+#include
+#include
+
+/**
+ * drm_panel_helper_shutdown - helper for panels to use at shutdown time
+ * @panel: DRM panel
+ *
+ * Panels may call this function unconditionally at shutdown time to ensure
+ * that they are disabled and unprepared if necessary.
+ *
+ * As part of this function:
+ * - The backlight will be turned off, if it was on.
+ * - Any panel followers will be power sequenced.
+ */
+void drm_panel_helper_shutdown(struct drm_panel *panel)
+{
+ int ret;
+
+ if (panel->enabled) {
+ ret = drm_panel_disable(panel);
+ if (ret)
+ dev_warn(panel->dev, "Error disabling panel %d\n", ret);
+ }
+ if (panel->prepared) {
+ ret = drm_panel_unprepare(panel);
+ if (ret)
+ dev_warn(panel->dev, "Error unpreparing panel %d\n",
ret);
+ }
+}
+EXPORT_SYMBOL_GPL(drm_panel_helper_shutdown);
diff --git a/include/drm/drm_panel_helper.h b/include/drm/drm_panel_helper.h
new file mode 100644
index ..5621482053a9
--- /dev/null
+++ b/include/drm/drm_panel_helper.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright 2023 Google Inc.
+ */
+
+#ifndef DRM_PANEL_HELPER_H
+#define DRM_PANEL_HELPER_H
+
+struct drm_panel;
+
+void drm_panel_helper_shutdown(struct drm_panel *panel);
+
+#endif /* DRM_PANEL_HELPER_H */
--
2.41.0.585.gd2178a4bd4-goog
[RFC PATCH 02/10] drm/panel: s6e63m0: Don't store+check prepared/enabled
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
For the s6e63m0 panel driver, this actually fixes a subtle/minor error
handling bug in s6e63m0_prepare(). In one error case s6e63m0_prepare()
called s6e63m0_unprepare() directly if there was an error. This call
to s6e63m0_unprepare() would have been a no-op since ctx->prepared
wasn't set yet.
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 25 ---
1 file changed, 25 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
index b34fa4d5de07..a0e5698275a5 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
@@ -270,9 +270,6 @@ struct s6e63m0 {
struct regulator_bulk_data supplies[2];
struct gpio_desc *reset_gpio;
- bool prepared;
- bool enabled;
-
/*
* This field is tested by functions directly accessing bus before
* transfer, transfer is skipped if it is set. In case of transfer
@@ -502,9 +499,6 @@ static int s6e63m0_disable(struct drm_panel *panel)
{
struct s6e63m0 *ctx = panel_to_s6e63m0(panel);
- if (!ctx->enabled)
- return 0;
-
backlight_disable(ctx->bl_dev);
s6e63m0_dcs_write_seq_static(ctx, MIPI_DCS_SET_DISPLAY_OFF);
@@ -512,8 +506,6 @@ static int s6e63m0_disable(struct drm_panel *panel)
s6e63m0_dcs_write_seq_static(ctx, MIPI_DCS_ENTER_SLEEP_MODE);
msleep(120);
- ctx->enabled = false;
-
return 0;
}
@@ -522,17 +514,12 @@ static int s6e63m0_unprepare(struct drm_panel *panel)
struct s6e63m0 *ctx = panel_to_s6e63m0(panel);
int ret;
- if (!ctx->prepared)
- return 0;
-
s6e63m0_clear_error(ctx);
ret = s6e63m0_power_off(ctx);
if (ret < 0)
return ret;
- ctx->prepared = false;
-
return 0;
}
@@ -541,9 +528,6 @@ static int s6e63m0_prepare(struct drm_panel *panel)
struct s6e63m0 *ctx = panel_to_s6e63m0(panel);
int ret;
- if (ctx->prepared)
- return 0;
-
ret = s6e63m0_power_on(ctx);
if (ret < 0)
return ret;
@@ -564,8 +548,6 @@ static int s6e63m0_prepare(struct drm_panel *panel)
if (ret < 0)
s6e63m0_unprepare(panel);
- ctx->prepared = true;
-
return ret;
}
@@ -573,9 +555,6 @@ static int s6e63m0_enable(struct drm_panel *panel)
{
struct s6e63m0 *ctx = panel_to_s6e63m0(panel);
- if (ctx->enabled)
- return 0;
-
s6e63m0_dcs_write_seq_static(ctx, MIPI_DCS_EXIT_SLEEP_MODE);
msleep(120);
s6e63m0_dcs_write_seq_static(ctx, MIPI_DCS_SET_DISPLAY_ON);
@@ -588,8 +567,6 @@ static int s6e63m0_enable(struct drm_panel *panel)
backlight_enable(ctx->bl_dev);
- ctx->enabled = true;
-
return 0;
}
@@ -709,8 +686,6 @@ int s6e63m0_probe(struct device *dev, void *trsp,
dev_set_drvdata(dev, ctx);
ctx->dev = dev;
- ctx->enabled = false;
- ctx->prepared = false;
ret = device_property_read_u32(dev, "max-brightness", _brightness);
if (ret)
--
2.41.0.585.gd2178a4bd4-goog
[RFC PATCH 01/10] drm/panel: Don't store+check prepared/enabled for simple cases
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
This pile of panel drivers appears to be simple to handle. Based on
code inspection they seemed to be using the prepared/enabled state
simply for double-checking that nothing else in the kernel called them
inconsistently. Now that the core drm_panel is doing the double
checking (and warning) it should be very clear that these devices
don't need their own double-check.
Signed-off-by: Douglas Anderson
---
.../drm/panel/panel-asus-z00t-tm5p5-n35596.c | 9 -
.../gpu/drm/panel/panel-boe-bf060y8m-aj0.c| 9 -
drivers/gpu/drm/panel/panel-jdi-fhd-r63452.c | 9 -
drivers/gpu/drm/panel/panel-novatek-nt35950.c | 9 -
drivers/gpu/drm/panel/panel-novatek-nt36523.c | 12 --
drivers/gpu/drm/panel/panel-raydium-rm68200.c | 38 ---
.../panel/panel-samsung-s6e88a0-ams452ef01.c | 10 -
drivers/gpu/drm/panel/panel-samsung-sofef00.c | 9 -
.../gpu/drm/panel/panel-sharp-ls060t1sx01.c | 10 -
drivers/gpu/drm/panel/panel-sony-td4353-jdi.c | 9 -
.../panel/panel-sony-tulip-truly-nt35521.c| 18 -
.../drm/panel/panel-startek-kd070fhfid015.c | 11 --
drivers/gpu/drm/panel/panel-truly-nt35597.c | 20 --
drivers/gpu/drm/panel/panel-visionox-r66451.c | 16
.../gpu/drm/panel/panel-visionox-rm69299.c| 8
.../gpu/drm/panel/panel-visionox-vtdr6130.c | 9 -
16 files changed, 206 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c
b/drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c
index 075a7af81eff..bcaa63d1955f 100644
--- a/drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c
+++ b/drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c
@@ -16,7 +16,6 @@ struct tm5p5_nt35596 {
struct mipi_dsi_device *dsi;
struct regulator_bulk_data supplies[2];
struct gpio_desc *reset_gpio;
- bool prepared;
};
static inline struct tm5p5_nt35596 *to_tm5p5_nt35596(struct drm_panel *panel)
@@ -112,9 +111,6 @@ static int tm5p5_nt35596_prepare(struct drm_panel *panel)
struct device *dev = >dsi->dev;
int ret;
- if (ctx->prepared)
- return 0;
-
ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
if (ret < 0) {
dev_err(dev, "Failed to enable regulators: %d\n", ret);
@@ -132,7 +128,6 @@ static int tm5p5_nt35596_prepare(struct drm_panel *panel)
return ret;
}
- ctx->prepared = true;
return 0;
}
@@ -142,9 +137,6 @@ static int tm5p5_nt35596_unprepare(struct drm_panel *panel)
struct device *dev = >dsi->dev;
int ret;
- if (!ctx->prepared)
- return 0;
-
ret = tm5p5_nt35596_off(ctx);
if (ret < 0)
dev_err(dev, "Failed to un-initialize panel: %d\n", ret);
@@ -153,7 +145,6 @@ static int tm5p5_nt35596_unprepare(struct drm_panel *panel)
regulator_bulk_disable(ARRAY_SIZE(ctx->supplies),
ctx->supplies);
- ctx->prepared = false;
return 0;
}
diff --git a/drivers/gpu/drm/panel/panel-boe-bf060y8m-aj0.c
b/drivers/gpu/drm/panel/panel-boe-bf060y8m-aj0.c
index 90098b753e3b..e77db8597eb7 100644
--- a/drivers/gpu/drm/panel/panel-boe-bf060y8m-aj0.c
+++ b/drivers/gpu/drm/panel/panel-boe-bf060y8m-aj0.c
@@ -34,7 +34,6 @@ struct boe_bf060y8m_aj0 {
struct mipi_dsi_device *dsi;
struct regulator_bulk_data vregs[BF060Y8M_VREG_MAX];
struct gpio_desc *reset_gpio;
- bool prepared;
};
static inline
@@ -129,9 +128,6 @@ static int boe_bf060y8m_aj0_prepare(struct drm_panel *panel)
struct device *dev = >dsi->dev;
int ret;
- if (boe->prepared)
- return 0;
-
/*
* Enable EL Driving Voltage first - doing that at the beginning
* or at the end of the power sequence doesn't matter, so enable
@@ -166,7 +162,6 @@ static int boe_bf060y8m_aj0_prepare(struct drm_panel *panel)
return ret;
}
- boe->prepared = true;
return 0;
err_vci:
@@ -186,9 +181,6 @@ static int boe_bf060y8m_aj0_unprepare(struct drm_panel
*panel)
struct device *dev = >dsi->dev;
int ret;
- if (!boe->prepared)
- return 0;
-
ret = boe_bf060y8m_aj0_off(boe);
if (ret < 0)
dev_err(dev, "Failed to un-initialize panel: %d\n", ret);
@@ -196,7 +188,6 @@ static int boe_bf060y8m_aj0_unprepare(struct drm_panel
*panel)
gpiod_set_value_cansleep(boe->reset_gpio, 1);
ret = regulator_bulk_disable(ARRAY_SIZE(boe->vregs), boe->vregs);
- boe->prepared =
[RFC PATCH 00/10] drm/panel: Remove most store/double-check of prepared/enabled state
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is now in the core and not
needed in individual drivers.
This series attempts to do just that. While the original grep, AKA:
git grep 'if.*>prepared' -- drivers/gpu/drm/panel
git grep 'if.*>enabled' -- drivers/gpu/drm/panel
...still produces a few hits after my series, they are _mostly_ all
gone. The ones that are left are less trivial to fix.
One of the main reasons that many panels probably needed to store and
double-check their prepared/enabled appears to have been to handle
shutdown and/or remove. Panels drivers often wanted to force the power
off for panels in these cases and this was a good reason for the
double-check. As part of this series a new helper is added that uses
the state tracking that the drm_panel core is doing so each individual
panel driver doesn't need to do it.
This series changes a lot of drivers and obviously the author can't
test on all of them. The changes here are also not completely trivial
in all cases. Please double-check your drivers carefully to make sure
something wasn't missed. After looking at over 40 drivers I'll admit
that my eyes glazed over a little.
I've attempted to organize these patches like to group together panels
that needed similar handling. Panels that had code that didn't seem to
match anyone else got their own patch. I made judgement calls on what
I considered "similar".
As noted in individual patches, there are some cases here where I
expect behavior to change a little bit. I'm hoping these changes are
for the better and don't cause any problems. Fingers crossed.
I have at least confirmed that "allmodconfig" for arm64 doesn't fall
on its face with this series. I haven't done a ton of other testing.
Douglas Anderson (10):
drm/panel: Don't store+check prepared/enabled for simple cases
drm/panel: s6e63m0: Don't store+check prepared/enabled
drm/panel: otm8009a: Don't double check prepared/enabled
drm/panel_helper: Introduce drm_panel_helper
drm/panel: Don't store+check prepared/enabled for panels needing
shutdown
drm/panel: Don't store+check prepared/enabled for panels disabled at
shutdown
drm/panel: st7703: Don't store+check prepared
drm/panel: rm67191: Don't store+check enabled
drm/panel: sony-acx565akm: Don't double-check enabled state in disable
drm/panel: Update TODO list item for cleaning up prepared/enabled
tracking
Documentation/gpu/todo.rst| 33 +---
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_panel_helper.c| 37 ++
.../drm/panel/panel-asus-z00t-tm5p5-n35596.c | 9
.../gpu/drm/panel/panel-boe-bf060y8m-aj0.c| 9
drivers/gpu/drm/panel/panel-boe-himax8279d.c | 36 ++---
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 16 +-
drivers/gpu/drm/panel/panel-edp.c | 34 ++---
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 21 +---
drivers/gpu/drm/panel/panel-himax-hx8394.c| 21 +---
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 51 ++-
drivers/gpu/drm/panel/panel-jdi-fhd-r63452.c | 9
.../gpu/drm/panel/panel-jdi-lt070me05000.c| 30 ++-
drivers/gpu/drm/panel/panel-khadas-ts050.c| 35 ++---
.../drm/panel/panel-kingdisplay-kd097d04.c| 43 ++--
.../drm/panel/panel-leadtek-ltk050h3146w.c| 21 +---
.../drm/panel/panel-leadtek-ltk500hd1829.c| 21 +---
drivers/gpu/drm/panel/panel-novatek-nt35950.c | 9
drivers/gpu/drm/panel/panel-novatek-nt36523.c | 12 -
.../gpu/drm/panel/panel-novatek-nt36672a.c| 24 ++---
.../drm/panel/panel-olimex-lcd-olinuxino.c| 45 +---
.../gpu/drm/panel/panel-orisetech-otm8009a.c | 17 ---
.../drm/panel/panel-osd-osd101t2587-53ts.c| 37 ++
.../drm/panel/panel-panasonic-vvx10f034n00.c | 42 ++-
drivers/gpu/drm/panel/panel-raydium-rm67191.c | 21 +---
drivers/gpu/drm/panel/panel-raydium-rm68200.c | 38 --
.../gpu/drm/panel/panel-samsung-atna33xc20.c | 31 ++-
drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 25 -
.../panel/panel-samsung-s6e88a0-ams452ef01.c | 10
drivers/gpu/drm/panel/panel-samsung-sofef00.c | 9
drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 45 ++--
.../gpu/drm/panel/panel-sharp-lq101r1sx01.c | 46 ++---
.../gpu/drm/panel/panel-sharp-ls043t1le01.c | 19 ++-
.../gpu/drm/panel/panel-sharp-ls060t1sx01.c | 10
drivers/gpu/drm/panel/panel-simple.c | 34 ++---
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 20 +---
drivers/gpu/drm/panel/panel-sony-acx565akm.c | 7 +--
Re: [PATCH 1/4] vgacon: rework Kconfig dependencies
On Tue, Aug 1, 2023, at 19:05, Russell King (Oracle) wrote:
> On Fri, Jul 07, 2023 at 11:52:23AM +0200, Arnd Bergmann wrote:
>> From: Arnd Bergmann
>>
>> The list of dependencies here is phrased as an opt-out, but this is missing
>> a lot of architectures that don't actually support VGA consoles, and some
>> of the entries are stale:
>>
>> - powerpc used to support VGA consoles in the old arch/ppc codebase, but
>>the merged arch/powerpc never did
>>
>> - arm lists footbridge, integrator and netwinder, but netwinder is actually
>>part of footbridge, and integrator does not appear to have an actual
>>VGA hardware, or list it in its ATAG or DT.
>
> Integrator/AP has PCI, and I have had PCI VGA cards plugged in to that
> hardware when I've had it.
I'm pretty sure it can no longer work and broke a while ago,
so I would prefer to leave it out unless someone actually has
a reason to use it and puts the work in to restore the support.
>From what I can tell, it's broken in at least three ways with
the new PCI host driver:
- the PCI memory space is identity mapped to its CPU physical
address as of d3721efce22d1 ("ARM: dts: integratorap: Fix
PCI windows"), which is generally better for compatibility
with broken drivers that read the BAR directly, but it
prevents memory mapped ISA-style devices including VGA text
buffer.
- vga_base is no longer set by the new PCI host driver, so
any accesses to the text buffer just end up in user space
memory at (__iomem*)0xb8000
- there is no DT binding for setting the global screen_info
to whatever the boot firmware has initialized
the VGA BIOS to, and the default 80x30 on Arm does not match
the typical 80x25 text that would be set by the BIOS.
> Provided any platform sets up PCI in a compatible way, and can run the
> VGA's BIOS to initialise the card, then vgacon is supportable.
It looks like only footbridge does at this point, all the other
platforms would need to fix at least some of the three things I
mentioned above, in particular plat-orion is the only thing
setting vga_base but also has the identity map issue.
My impression is that nobody has cared about vgacon on most
Arm systems since it's harder to get working than fbcon with
a native PCI driver (or the built-in pl110 on integrator) but
also less useful.
Arnd
Re: [PATCH v3 3/9] PM / QoS: Fix constraints alloc vs reclaim locking
On Fri, Aug 4, 2023 at 10:38 PM Rob Clark wrote:
>
> On Fri, Aug 4, 2023 at 12:11 PM Rafael J. Wysocki wrote:
> >
> > On Fri, Aug 4, 2023 at 8:38 PM Rob Clark wrote:
> > >
> > > On Fri, Aug 4, 2023 at 10:07 AM Rafael J. Wysocki
> > > wrote:
> > > >
> > > > On Fri, Aug 4, 2023 at 12:02 AM Rob Clark wrote:
> > > > >
> > > > > From: Rob Clark
> > > > >
> > > > > In the process of adding lockdep annotation for drm GPU scheduler's
> > > > > job_run() to detect potential deadlock against shrinker/reclaim, I hit
> > > > > this lockdep splat:
> > > > >
> > > > >==
> > > > >WARNING: possible circular locking dependency detected
> > > > >6.2.0-rc8-debug+ #558 Tainted: GW
> > > > >--
> > > > >ring0/125 is trying to acquire lock:
> > > > >ffd6d6ce0f28 (dev_pm_qos_mtx){+.+.}-{3:3}, at:
> > > > > dev_pm_qos_update_request+0x38/0x68
> > > > >
> > > > >but task is already holding lock:
> > > > >ff8087239208 (>active_lock){+.+.}-{3:3}, at:
> > > > > msm_gpu_submit+0xec/0x178
> > > > >
> > > > >which lock already depends on the new lock.
> > > > >
> > > > >the existing dependency chain (in reverse order) is:
> > > > >
> > > > >-> #4 (>active_lock){+.+.}-{3:3}:
> > > > > __mutex_lock+0xcc/0x3c8
> > > > > mutex_lock_nested+0x30/0x44
> > > > > msm_gpu_submit+0xec/0x178
> > > > > msm_job_run+0x78/0x150
> > > > > drm_sched_main+0x290/0x370
> > > > > kthread+0xf0/0x100
> > > > > ret_from_fork+0x10/0x20
> > > > >
> > > > >-> #3 (dma_fence_map){}-{0:0}:
> > > > > __dma_fence_might_wait+0x74/0xc0
> > > > > dma_resv_lockdep+0x1f4/0x2f4
> > > > > do_one_initcall+0x104/0x2bc
> > > > > kernel_init_freeable+0x344/0x34c
> > > > > kernel_init+0x30/0x134
> > > > > ret_from_fork+0x10/0x20
> > > > >
> > > > >-> #2 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}:
> > > > > fs_reclaim_acquire+0x80/0xa8
> > > > > slab_pre_alloc_hook.constprop.0+0x40/0x25c
> > > > > __kmem_cache_alloc_node+0x60/0x1cc
> > > > > __kmalloc+0xd8/0x100
> > > > > topology_parse_cpu_capacity+0x8c/0x178
> > > > > get_cpu_for_node+0x88/0xc4
> > > > > parse_cluster+0x1b0/0x28c
> > > > > parse_cluster+0x8c/0x28c
> > > > > init_cpu_topology+0x168/0x188
> > > > > smp_prepare_cpus+0x24/0xf8
> > > > > kernel_init_freeable+0x18c/0x34c
> > > > > kernel_init+0x30/0x134
> > > > > ret_from_fork+0x10/0x20
> > > > >
> > > > >-> #1 (fs_reclaim){+.+.}-{0:0}:
> > > > > __fs_reclaim_acquire+0x3c/0x48
> > > > > fs_reclaim_acquire+0x54/0xa8
> > > > > slab_pre_alloc_hook.constprop.0+0x40/0x25c
> > > > > __kmem_cache_alloc_node+0x60/0x1cc
> > > > > kmalloc_trace+0x50/0xa8
> > > > > dev_pm_qos_constraints_allocate+0x38/0x100
> > > > > __dev_pm_qos_add_request+0xb0/0x1e8
> > > > > dev_pm_qos_add_request+0x58/0x80
> > > > > dev_pm_qos_expose_latency_limit+0x60/0x13c
> > > > > register_cpu+0x12c/0x130
> > > > > topology_init+0xac/0xbc
> > > > > do_one_initcall+0x104/0x2bc
> > > > > kernel_init_freeable+0x344/0x34c
> > > > > kernel_init+0x30/0x134
> > > > > ret_from_fork+0x10/0x20
> > > > >
> > > > >-> #0 (dev_pm_qos_mtx){+.+.}-{3:3}:
> > > > > __lock_acquire+0xe00/0x1060
> > > > > lock_acquire+0x1e0/0x2f8
> > > > > __mutex_lock+0xcc/0x3c8
> > > > > mutex_lock_nested+0x30/0x44
> > > > > dev_pm_qos_update_request+0x38/0x68
> > > > > msm_devfreq_boost+0x40/0x70
> > > > > msm_devfreq_active+0xc0/0xf0
> > > > > msm_gpu_submit+0x10c/0x178
> > > > > msm_job_run+0x78/0x150
> > > > > drm_sched_main+0x290/0x370
> > > > > kthread+0xf0/0x100
> > > > > ret_from_fork+0x10/0x20
> > > > >
> > > > >other info that might help us debug this:
> > > > >
> > > > >Chain exists of:
> > > > > dev_pm_qos_mtx --> dma_fence_map --> >active_lock
> > > > >
> > > > > Possible unsafe locking scenario:
> > > > >
> > > > > CPU0CPU1
> > > > >
> > > > > lock(>active_lock);
> > > > > lock(dma_fence_map);
> > > > > lock(>active_lock);
> > > > > lock(dev_pm_qos_mtx);
> > > > >
> > > > > *** DEADLOCK ***
> > > > >
> > > > >3 locks held by ring0/123:
> > > > > #0: ff8087251170 (>lock){+.+.}-{3:3}, at:
> > > > > msm_job_run+0x64/0x150
> > > > > #1: ffd00b0e57e8 (dma_fence_map){}-{0:0}, at:
> > > > > msm_job_run+0x68/0x150
> > > > >
Re: [PATCH v3 3/9] PM / QoS: Fix constraints alloc vs reclaim locking
On Fri, Aug 4, 2023 at 12:11 PM Rafael J. Wysocki wrote:
>
> On Fri, Aug 4, 2023 at 8:38 PM Rob Clark wrote:
> >
> > On Fri, Aug 4, 2023 at 10:07 AM Rafael J. Wysocki wrote:
> > >
> > > On Fri, Aug 4, 2023 at 12:02 AM Rob Clark wrote:
> > > >
> > > > From: Rob Clark
> > > >
> > > > In the process of adding lockdep annotation for drm GPU scheduler's
> > > > job_run() to detect potential deadlock against shrinker/reclaim, I hit
> > > > this lockdep splat:
> > > >
> > > >==
> > > >WARNING: possible circular locking dependency detected
> > > >6.2.0-rc8-debug+ #558 Tainted: GW
> > > >--
> > > >ring0/125 is trying to acquire lock:
> > > >ffd6d6ce0f28 (dev_pm_qos_mtx){+.+.}-{3:3}, at:
> > > > dev_pm_qos_update_request+0x38/0x68
> > > >
> > > >but task is already holding lock:
> > > >ff8087239208 (>active_lock){+.+.}-{3:3}, at:
> > > > msm_gpu_submit+0xec/0x178
> > > >
> > > >which lock already depends on the new lock.
> > > >
> > > >the existing dependency chain (in reverse order) is:
> > > >
> > > >-> #4 (>active_lock){+.+.}-{3:3}:
> > > > __mutex_lock+0xcc/0x3c8
> > > > mutex_lock_nested+0x30/0x44
> > > > msm_gpu_submit+0xec/0x178
> > > > msm_job_run+0x78/0x150
> > > > drm_sched_main+0x290/0x370
> > > > kthread+0xf0/0x100
> > > > ret_from_fork+0x10/0x20
> > > >
> > > >-> #3 (dma_fence_map){}-{0:0}:
> > > > __dma_fence_might_wait+0x74/0xc0
> > > > dma_resv_lockdep+0x1f4/0x2f4
> > > > do_one_initcall+0x104/0x2bc
> > > > kernel_init_freeable+0x344/0x34c
> > > > kernel_init+0x30/0x134
> > > > ret_from_fork+0x10/0x20
> > > >
> > > >-> #2 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}:
> > > > fs_reclaim_acquire+0x80/0xa8
> > > > slab_pre_alloc_hook.constprop.0+0x40/0x25c
> > > > __kmem_cache_alloc_node+0x60/0x1cc
> > > > __kmalloc+0xd8/0x100
> > > > topology_parse_cpu_capacity+0x8c/0x178
> > > > get_cpu_for_node+0x88/0xc4
> > > > parse_cluster+0x1b0/0x28c
> > > > parse_cluster+0x8c/0x28c
> > > > init_cpu_topology+0x168/0x188
> > > > smp_prepare_cpus+0x24/0xf8
> > > > kernel_init_freeable+0x18c/0x34c
> > > > kernel_init+0x30/0x134
> > > > ret_from_fork+0x10/0x20
> > > >
> > > >-> #1 (fs_reclaim){+.+.}-{0:0}:
> > > > __fs_reclaim_acquire+0x3c/0x48
> > > > fs_reclaim_acquire+0x54/0xa8
> > > > slab_pre_alloc_hook.constprop.0+0x40/0x25c
> > > > __kmem_cache_alloc_node+0x60/0x1cc
> > > > kmalloc_trace+0x50/0xa8
> > > > dev_pm_qos_constraints_allocate+0x38/0x100
> > > > __dev_pm_qos_add_request+0xb0/0x1e8
> > > > dev_pm_qos_add_request+0x58/0x80
> > > > dev_pm_qos_expose_latency_limit+0x60/0x13c
> > > > register_cpu+0x12c/0x130
> > > > topology_init+0xac/0xbc
> > > > do_one_initcall+0x104/0x2bc
> > > > kernel_init_freeable+0x344/0x34c
> > > > kernel_init+0x30/0x134
> > > > ret_from_fork+0x10/0x20
> > > >
> > > >-> #0 (dev_pm_qos_mtx){+.+.}-{3:3}:
> > > > __lock_acquire+0xe00/0x1060
> > > > lock_acquire+0x1e0/0x2f8
> > > > __mutex_lock+0xcc/0x3c8
> > > > mutex_lock_nested+0x30/0x44
> > > > dev_pm_qos_update_request+0x38/0x68
> > > > msm_devfreq_boost+0x40/0x70
> > > > msm_devfreq_active+0xc0/0xf0
> > > > msm_gpu_submit+0x10c/0x178
> > > > msm_job_run+0x78/0x150
> > > > drm_sched_main+0x290/0x370
> > > > kthread+0xf0/0x100
> > > > ret_from_fork+0x10/0x20
> > > >
> > > >other info that might help us debug this:
> > > >
> > > >Chain exists of:
> > > > dev_pm_qos_mtx --> dma_fence_map --> >active_lock
> > > >
> > > > Possible unsafe locking scenario:
> > > >
> > > > CPU0CPU1
> > > >
> > > > lock(>active_lock);
> > > > lock(dma_fence_map);
> > > > lock(>active_lock);
> > > > lock(dev_pm_qos_mtx);
> > > >
> > > > *** DEADLOCK ***
> > > >
> > > >3 locks held by ring0/123:
> > > > #0: ff8087251170 (>lock){+.+.}-{3:3}, at:
> > > > msm_job_run+0x64/0x150
> > > > #1: ffd00b0e57e8 (dma_fence_map){}-{0:0}, at:
> > > > msm_job_run+0x68/0x150
> > > > #2: ff8087251208 (>active_lock){+.+.}-{3:3}, at:
> > > > msm_gpu_submit+0xec/0x178
> > > >
> > > >stack backtrace:
> > > >CPU: 6 PID: 123 Comm: ring0 Not tainted 6.2.0-rc8-debug+ #559
> > > >Hardware name: Google Lazor (rev1 - 2) with LTE (DT)
> > > >Call trace:
> >
Re: [Intel-xe] [RFC PATCH] Documentation/gpu: Draft VM_BIND locking document
On Fri, Jun 30, 2023 at 06:44:52PM +0200, Thomas Hellström wrote: > Add the first version of the VM_BIND locking document which is > intended to be part of the xe driver upstreaming agreement. > > The document describes and discuss the locking used during exec- > functions, evicton and for userptr gmvas. Intention is to be using the > same nomenclature as the drm-vm-bind-async.rst, but to keep naming a > little shorter, use gvm and gmva instead of gpu_vm and gpu_vma which > is used in the previous document, with an intention to modify also > that document. I preferred the gpu_vm and gpu_vma as written in the async doc. Much easier to read imho. > > Signed-off-by: Thomas Hellström > --- > Documentation/gpu/drm-vm-bind-locking.rst | 339 ++ > 1 file changed, 339 insertions(+) > create mode 100644 Documentation/gpu/drm-vm-bind-locking.rst > > diff --git a/Documentation/gpu/drm-vm-bind-locking.rst > b/Documentation/gpu/drm-vm-bind-locking.rst > new file mode 100644 > index ..f5d1a40a2906 > --- /dev/null > +++ b/Documentation/gpu/drm-vm-bind-locking.rst > @@ -0,0 +1,339 @@ > +=== > +VM_BIND locking > +=== > + > +This document attempts to describe what's needed to get VM_BIND locking > right, > +including the userptr mmu_notifier locking and it will also discuss some > +optimizations to get rid of the looping through of all userptr mappings and > +external / shared object mappings that is needed in the simplest > +implementation. It will also discuss some implications for faulting gvms. > + > +Nomenclature > + > + > +* ``Context``: GPU execution context. > +* ``gvm``: Abstraction of a GPU address space with meta-data. Typically > + one per client (DRM file-private), or one per context. > +* ``gvma``: Abstraction of a GPU address range within a gvma with within a gpu_vm you meant? > + associated meta-data. The backing storage of a gvma can either be > + a gem buffer object or anonymous pages mapped also into the CPU > + address space for the process. > +* ``userptr gvma or just userptr``: A gvma, the backing store of > + which is anonymous pages as described above. > +* ``revalidating``: Revalidating a gvma means making the latest version > + of the backing store resident and making sure the gvma's > + page-table entries point to that backing store. > +* ``dma_fence``: A struct dma_fence that is similar to a struct completion > + and which tracks GPU activity. When the GPU activity is finished, > + the dma_fence signals. > +* ``dma_resv``: A struct dma_resv (AKA reservation object) that is used > + to track GPU activity in the form of multiple dma_fences on a > + gvm or a gem buffer object. The dma_resv contains an array / list > + of dma_fences and a lock that needs to be held when adding > + additional dma_fences to the dma_resv. The lock is of a type that > + allows deadlock-safe locking of multiple dma_resvs in arbitrary order. > +* ``exec function``: An exec function is a function that revalidates all > + affected gvmas, submits a GPU command batch and registers the > + dma_fence representing the GPU command's activity with all affected > + dma_resvs. For completeness, although not covered by this document, > + it's worth mentioning that an exec function may also be the > + revalidation worker that is used by some drivers in compute / > + long-running mode. > +* ``local object``: A GEM object which is local to a gvm. Shared gem > + objects also share the gvm's dma_resv. > +* ``shared object``: AKA external object: A GEM object which may be shared > + by multiple gvms and whose backing storage may be shared with > + other drivers. > + > + > +Introducing the locks > += > + > +One of the benefits of VM_BIND is that local GEM objects share the gvm's > +dma_resv object and hence the dma_resv lock. So even with a huge > +number of local GEM objects, only one lock is needed to make the exec > +sequence atomic. > + > +The following locks and locking orders are used: > + > +* The ``gvm->lock`` (optionally an rwsem). Protects how the gvm is > + partitioned into gvmas, protects the gvm's list of external objects, > + and can also with some simplification protect the gvm's list of > + userptr gvmas. With the CPU mm analogy this would correspond to the > + mmap_lock. > +* The ``userptr_seqlock``. This lock is taken in read mode for each > + userptr gvma on the gvm's userptr list, and in write mode during mmu > + notifier invalidation. is this something that exists withing the mmu_notifier or a new lock when handling the notifier? > +* The ``gvm->resv`` lock. Protects the gvm's list of gvmas needing > + rebinding, and also the residency of all the gvm's local GEM object. > +* The ``gvm->userptr_notifier_lock``. This is an rwsem that is taken in read > + mode during exec and write mode during a mmu notifier invalidation. In > + the absence of a separate page-table lock, this lock can serve
Re: [Intel-xe] [PATCH v5] Documentation/gpu: Add a VM_BIND async draft document
On Wed, Jul 19, 2023 at 07:50:21PM +, Zanoni, Paulo R wrote: > On Sat, 2023-07-15 at 17:45 +0200, Thomas Hellström wrote: > > Add a motivation for and description of asynchronous VM_BIND operation > > I think I may have missed some other documentation, which would explain > some of my questions below, so please be patient with my > misunderstandings. But here's a review from the POV of a UMD person. > > > > > > v2: > > - Fix typos (Nirmoy Das) > > - Improve the description of a memory fence (Oak Zeng) > > - Add a reference to the document in the Xe RFC. > > - Add pointers to sample uAPI suggestions > > v3: > > - Address review comments (Danilo Krummrich) > > - Formatting fixes > > v4: > > - Address typos (Francois Dugast) > > - Explain why in-fences are not allowed for VM_BIND operations for long- > > running workloads (Matthew Brost) > > v5: > > - More typo- and style fixing > > - Further clarify the implications of disallowing in-fences for VM_BIND > > operations for long-running workloads (Matthew Brost) > > > > Signed-off-by: Thomas Hellström > > Acked-by: Nirmoy Das > > --- > > Documentation/gpu/drm-vm-bind-async.rst | 171 > > Documentation/gpu/rfc/xe.rst| 4 +- > > 2 files changed, 173 insertions(+), 2 deletions(-) > > create mode 100644 Documentation/gpu/drm-vm-bind-async.rst > > > > diff --git a/Documentation/gpu/drm-vm-bind-async.rst > > b/Documentation/gpu/drm-vm-bind-async.rst > > new file mode 100644 > > index ..d2b02a38198a > > --- /dev/null > > +++ b/Documentation/gpu/drm-vm-bind-async.rst > > @@ -0,0 +1,171 @@ > > + > > +Asynchronous VM_BIND > > + > > + > > +Nomenclature: > > += > > + > > +* ``VRAM``: On-device memory. Sometimes referred to as device local memory. > > + > > +* ``gpu_vm``: A GPU address space. Typically per process, but can be > > shared by > > + multiple processes. > > + > > +* ``VM_BIND``: An operation or a list of operations to modify a gpu_vm > > using > > + an IOCTL. The operations include mapping and unmapping system- or > > + VRAM memory. > > + > > +* ``syncobj``: A container that abstracts synchronization objects. The > > + synchronization objects can be either generic, like dma-fences or > > + driver specific. A syncobj typically indicates the type of the > > + underlying synchronization object. > > + > > +* ``in-syncobj``: Argument to a VM_BIND IOCTL, the VM_BIND operation waits > > + for these before starting. > > + > > +* ``out-syncobj``: Argument to a VM_BIND_IOCTL, the VM_BIND operation > > + signals these when the bind operation is complete. > > + > > +* ``memory fence``: A synchronization object, different from a dma-fence. > > Since you've mentioned it twice in this document already, for > completeness would you mind also giving a definition for dma-fence in > what it relates/contrasts to the rest of the text? Maybe worth a link to the dma-fence doc itself? (somehow making sphinx to point out to driver-api/dma-buf.html#dma-fences) But the differences are written below Paulo: > > > > + A memory fence uses the value of a specified memory location to determine > > + signaled status. A memory fence can be awaited and signaled by both > > + the GPU and CPU. Memory fences are sometimes referred to as > > + user-fences, userspace-fences or gpu futexes and do not necessarily obey > > + the dma-fence rule of signaling within a "reasonable amount of time". > > + The kernel should thus avoid waiting for memory fences with locks held. ^ > > + > > +* ``long-running workload``: A workload that may take more than the > > + current stipulated dma-fence maximum signal delay to complete and > > Where is this delay defined? Is this the same as the gpuhang timer? dma-fence defines it in a very "cool" way: "reasonable amount of time": https://www.kernel.org/doc/html/latest/driver-api/dma-buf.html#dma-fences so, in contrast, long-running workload is *anything* above that "reasonable amount of time". > > > > + which therefore needs to set the gpu_vm or the GPU execution context in > > + a certain mode that disallows completion dma-fences. > > + > > +* ``exec function``: An exec function is a function that revalidates all > > + affected gpu_vmas, submits a GPU command batch and registers the > > + dma_fence representing the GPU command's activity with all affected > > + dma_resvs. For completeness, although not covered by this document, > > + it's worth mentioning that an exec function may also be the > > + revalidation worker that is used by some drivers in compute / > > + long-running mode. > > + > > +* ``bind context``: A context identifier used for the VM_BIND > > + operation. VM_BIND operations that use the same bind context can be > > + assumed, where it matters, to complete in order of submission. No such > > + assumptions can be made for VM_BIND operations using separate bind > > contexts. > > + > > +* ``UMD``:
Re: [PATCH] drm: Drop select FRAMEBUFFER_CONSOLE for DRM_FBDEV_EMULATION
On 8/4/23 05:51, Javier Martinez Canillas wrote:
> The commit c242f48433e7 ("drm: Make FB_CORE to be selected if DRM fbdev
> emulation is enabled") changed DRM_FBDEV_EMULATION from 'depends on FB'
> to an effective 'select FB_CORE', so any config that previously had DRM=y
> and FB=n now has FB_CORE=y and FRAMEBUFFER_CONSOLE=y.
>
> This leads to unmet direct dependencies detected for FRAMEBUFFER_CONSOLE
> as reported by Arthur Grillo, e.g:
>
> WARNING: unmet direct dependencies detected for FRAMEBUFFER_CONSOLE
> Depends on [n]: VT [=n] && FB_CORE [=y] && !UML [=y]
> Selected by [y]:
> - DRM_FBDEV_EMULATION [=y] && HAS_IOMEM [=y] && DRM [=y] && !EXPERT [=n]
>
> Arnd Bergmann suggests to drop the select FRAMEBUFFER_CONSOLE for the
> DRM_FBDEV_EMULATION Kconfig symbol, since a possible use case could
> be to enable DRM fbdev emulation but without a framebuffer console.
>
> Fixes: c242f48433e7 ("drm: Make FB_CORE to be selected if DRM fbdev emulation
> is enabled")
> Reported-by: Arthur Grillo
> Closes:
> https://lore.kernel.org/dri-devel/20230726220325.278976-1-arthurgri...@riseup.net
> Suggested-by: Arnd Bergmann
> Signed-off-by: Javier Martinez Canillas
Acked-by: Randy Dunlap
Tested-by: Randy Dunlap # build-tested
Thanks.
> ---
>
> drivers/gpu/drm/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index b51c6a141dfa..2a44b9419d4d 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -135,7 +135,6 @@ config DRM_DEBUG_MODESET_LOCK
> config DRM_FBDEV_EMULATION
> bool "Enable legacy fbdev support for your modesetting driver"
> depends on DRM
> - select FRAMEBUFFER_CONSOLE if !EXPERT
> select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
> default y
> help
--
~Randy
Re: [PATCH v3 3/9] PM / QoS: Fix constraints alloc vs reclaim locking
On Fri, Aug 4, 2023 at 8:38 PM Rob Clark wrote:
>
> On Fri, Aug 4, 2023 at 10:07 AM Rafael J. Wysocki wrote:
> >
> > On Fri, Aug 4, 2023 at 12:02 AM Rob Clark wrote:
> > >
> > > From: Rob Clark
> > >
> > > In the process of adding lockdep annotation for drm GPU scheduler's
> > > job_run() to detect potential deadlock against shrinker/reclaim, I hit
> > > this lockdep splat:
> > >
> > >==
> > >WARNING: possible circular locking dependency detected
> > >6.2.0-rc8-debug+ #558 Tainted: GW
> > >--
> > >ring0/125 is trying to acquire lock:
> > >ffd6d6ce0f28 (dev_pm_qos_mtx){+.+.}-{3:3}, at:
> > > dev_pm_qos_update_request+0x38/0x68
> > >
> > >but task is already holding lock:
> > >ff8087239208 (>active_lock){+.+.}-{3:3}, at:
> > > msm_gpu_submit+0xec/0x178
> > >
> > >which lock already depends on the new lock.
> > >
> > >the existing dependency chain (in reverse order) is:
> > >
> > >-> #4 (>active_lock){+.+.}-{3:3}:
> > > __mutex_lock+0xcc/0x3c8
> > > mutex_lock_nested+0x30/0x44
> > > msm_gpu_submit+0xec/0x178
> > > msm_job_run+0x78/0x150
> > > drm_sched_main+0x290/0x370
> > > kthread+0xf0/0x100
> > > ret_from_fork+0x10/0x20
> > >
> > >-> #3 (dma_fence_map){}-{0:0}:
> > > __dma_fence_might_wait+0x74/0xc0
> > > dma_resv_lockdep+0x1f4/0x2f4
> > > do_one_initcall+0x104/0x2bc
> > > kernel_init_freeable+0x344/0x34c
> > > kernel_init+0x30/0x134
> > > ret_from_fork+0x10/0x20
> > >
> > >-> #2 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}:
> > > fs_reclaim_acquire+0x80/0xa8
> > > slab_pre_alloc_hook.constprop.0+0x40/0x25c
> > > __kmem_cache_alloc_node+0x60/0x1cc
> > > __kmalloc+0xd8/0x100
> > > topology_parse_cpu_capacity+0x8c/0x178
> > > get_cpu_for_node+0x88/0xc4
> > > parse_cluster+0x1b0/0x28c
> > > parse_cluster+0x8c/0x28c
> > > init_cpu_topology+0x168/0x188
> > > smp_prepare_cpus+0x24/0xf8
> > > kernel_init_freeable+0x18c/0x34c
> > > kernel_init+0x30/0x134
> > > ret_from_fork+0x10/0x20
> > >
> > >-> #1 (fs_reclaim){+.+.}-{0:0}:
> > > __fs_reclaim_acquire+0x3c/0x48
> > > fs_reclaim_acquire+0x54/0xa8
> > > slab_pre_alloc_hook.constprop.0+0x40/0x25c
> > > __kmem_cache_alloc_node+0x60/0x1cc
> > > kmalloc_trace+0x50/0xa8
> > > dev_pm_qos_constraints_allocate+0x38/0x100
> > > __dev_pm_qos_add_request+0xb0/0x1e8
> > > dev_pm_qos_add_request+0x58/0x80
> > > dev_pm_qos_expose_latency_limit+0x60/0x13c
> > > register_cpu+0x12c/0x130
> > > topology_init+0xac/0xbc
> > > do_one_initcall+0x104/0x2bc
> > > kernel_init_freeable+0x344/0x34c
> > > kernel_init+0x30/0x134
> > > ret_from_fork+0x10/0x20
> > >
> > >-> #0 (dev_pm_qos_mtx){+.+.}-{3:3}:
> > > __lock_acquire+0xe00/0x1060
> > > lock_acquire+0x1e0/0x2f8
> > > __mutex_lock+0xcc/0x3c8
> > > mutex_lock_nested+0x30/0x44
> > > dev_pm_qos_update_request+0x38/0x68
> > > msm_devfreq_boost+0x40/0x70
> > > msm_devfreq_active+0xc0/0xf0
> > > msm_gpu_submit+0x10c/0x178
> > > msm_job_run+0x78/0x150
> > > drm_sched_main+0x290/0x370
> > > kthread+0xf0/0x100
> > > ret_from_fork+0x10/0x20
> > >
> > >other info that might help us debug this:
> > >
> > >Chain exists of:
> > > dev_pm_qos_mtx --> dma_fence_map --> >active_lock
> > >
> > > Possible unsafe locking scenario:
> > >
> > > CPU0CPU1
> > >
> > > lock(>active_lock);
> > > lock(dma_fence_map);
> > > lock(>active_lock);
> > > lock(dev_pm_qos_mtx);
> > >
> > > *** DEADLOCK ***
> > >
> > >3 locks held by ring0/123:
> > > #0: ff8087251170 (>lock){+.+.}-{3:3}, at:
> > > msm_job_run+0x64/0x150
> > > #1: ffd00b0e57e8 (dma_fence_map){}-{0:0}, at:
> > > msm_job_run+0x68/0x150
> > > #2: ff8087251208 (>active_lock){+.+.}-{3:3}, at:
> > > msm_gpu_submit+0xec/0x178
> > >
> > >stack backtrace:
> > >CPU: 6 PID: 123 Comm: ring0 Not tainted 6.2.0-rc8-debug+ #559
> > >Hardware name: Google Lazor (rev1 - 2) with LTE (DT)
> > >Call trace:
> > > dump_backtrace.part.0+0xb4/0xf8
> > > show_stack+0x20/0x38
> > > dump_stack_lvl+0x9c/0xd0
> > > dump_stack+0x18/0x34
> > > print_circular_bug+0x1b4/0x1f0
> > > check_noncircular+0x78/0xac
> > > __lock_acquire+0xe00/0x1060
> > > lock_acquire+0x1e0/0x2f8
> > >
Re: [git pull] drm fixes for 6.5-rc5
The pull request you sent on Fri, 4 Aug 2023 15:07:56 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-08-04 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/4142fc6743d39271e712936d9fb284cd84cb6010 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH v2 1/2] pwm: Manage owner assignment implicitly for drivers
Dne petek, 04. avgust 2023 ob 16:27:06 CEST je Uwe Kleine-König napisal(a): > Instead of requiring each driver to care for assigning the owner member > of struct pwm_ops, handle that implicitly using a macro. Note that the > owner member has to be moved to struct pwm_chip, as the ops structure > usually lives in read-only memory and so cannot be modified. > > The upside is that new lowlevel drivers cannot forget the assignment and > save one line each. The pwm-crc driver didn't assign .owner, that's not > a problem in practise though as the driver cannot be compiled as a > module. > > Signed-off-by: Uwe Kleine-König > --- > drivers/gpio/gpio-mvebu.c | 1 - > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 1 - > drivers/leds/rgb/leds-qcom-lpg.c | 1 - > drivers/pwm/core.c| 24 ++-- > drivers/pwm/pwm-ab8500.c | 1 - > drivers/pwm/pwm-apple.c | 1 - > drivers/pwm/pwm-atmel-hlcdc.c | 1 - > drivers/pwm/pwm-atmel-tcb.c | 1 - > drivers/pwm/pwm-atmel.c | 1 - > drivers/pwm/pwm-bcm-iproc.c | 1 - > drivers/pwm/pwm-bcm-kona.c| 1 - > drivers/pwm/pwm-bcm2835.c | 1 - > drivers/pwm/pwm-berlin.c | 1 - > drivers/pwm/pwm-brcmstb.c | 1 - > drivers/pwm/pwm-clk.c | 1 - > drivers/pwm/pwm-clps711x.c| 1 - > drivers/pwm/pwm-cros-ec.c | 1 - > drivers/pwm/pwm-dwc.c | 1 - > drivers/pwm/pwm-ep93xx.c | 1 - > drivers/pwm/pwm-fsl-ftm.c | 1 - > drivers/pwm/pwm-hibvt.c | 1 - > drivers/pwm/pwm-img.c | 1 - > drivers/pwm/pwm-imx-tpm.c | 1 - > drivers/pwm/pwm-imx1.c| 1 - > drivers/pwm/pwm-imx27.c | 1 - > drivers/pwm/pwm-intel-lgm.c | 1 - > drivers/pwm/pwm-iqs620a.c | 1 - > drivers/pwm/pwm-jz4740.c | 1 - > drivers/pwm/pwm-keembay.c | 1 - > drivers/pwm/pwm-lp3943.c | 1 - > drivers/pwm/pwm-lpc18xx-sct.c | 1 - > drivers/pwm/pwm-lpc32xx.c | 1 - > drivers/pwm/pwm-lpss.c| 1 - > drivers/pwm/pwm-mediatek.c| 1 - > drivers/pwm/pwm-meson.c | 1 - > drivers/pwm/pwm-microchip-core.c | 1 - > drivers/pwm/pwm-mtk-disp.c| 1 - > drivers/pwm/pwm-mxs.c | 1 - > drivers/pwm/pwm-ntxec.c | 1 - > drivers/pwm/pwm-omap-dmtimer.c| 1 - > drivers/pwm/pwm-pca9685.c | 1 - > drivers/pwm/pwm-pxa.c | 1 - > drivers/pwm/pwm-raspberrypi-poe.c | 1 - > drivers/pwm/pwm-rcar.c| 1 - > drivers/pwm/pwm-renesas-tpu.c | 1 - > drivers/pwm/pwm-rockchip.c| 1 - > drivers/pwm/pwm-rz-mtu3.c | 1 - > drivers/pwm/pwm-samsung.c | 1 - > drivers/pwm/pwm-sifive.c | 1 - > drivers/pwm/pwm-sl28cpld.c| 1 - > drivers/pwm/pwm-spear.c | 1 - > drivers/pwm/pwm-sprd.c| 1 - > drivers/pwm/pwm-sti.c | 1 - > drivers/pwm/pwm-stm32-lp.c| 1 - > drivers/pwm/pwm-stm32.c | 1 - > drivers/pwm/pwm-stmpe.c | 1 - > drivers/pwm/pwm-sun4i.c | 1 - For sun4i: Acked-by: Jernej Skrabec Best regards, Jernej > drivers/pwm/pwm-sunplus.c | 1 - > drivers/pwm/pwm-tegra.c | 1 - > drivers/pwm/pwm-tiecap.c | 1 - > drivers/pwm/pwm-tiehrpwm.c| 1 - > drivers/pwm/pwm-twl-led.c | 2 -- > drivers/pwm/pwm-twl.c | 2 -- > drivers/pwm/pwm-visconti.c| 1 - > drivers/pwm/pwm-vt8500.c | 1 - > drivers/pwm/pwm-xilinx.c | 1 - > drivers/staging/greybus/pwm.c | 1 - > include/linux/pwm.h | 10 ++
Re: [PATCH v2 1/2] pwm: Manage owner assignment implicitly for drivers
On 8/4/23 07:27, Uwe Kleine-König wrote:
Instead of requiring each driver to care for assigning the owner member
of struct pwm_ops, handle that implicitly using a macro. Note that the
owner member has to be moved to struct pwm_chip, as the ops structure
usually lives in read-only memory and so cannot be modified.
The upside is that new lowlevel drivers cannot forget the assignment and
save one line each. The pwm-crc driver didn't assign .owner, that's not
a problem in practise though as the driver cannot be compiled as a
module.
Signed-off-by: Uwe Kleine-König > ---
drivers/pwm/pwm-bcm-iproc.c | 1 -
drivers/pwm/pwm-bcm-kona.c| 1 -
drivers/pwm/pwm-bcm2835.c | 1 -
drivers/pwm/pwm-brcmstb.c | 1 -
Reviewed-by: Florian Fainelli #
pwm-{bcm,brcm}*.c
--
Florian
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [PATCH v2 1/2] pwm: Manage owner assignment implicitly for drivers
On Fri, Aug 4, 2023 at 5:28 PM Uwe Kleine-König wrote: > > Instead of requiring each driver to care for assigning the owner member > of struct pwm_ops, handle that implicitly using a macro. Note that the > owner member has to be moved to struct pwm_chip, as the ops structure > usually lives in read-only memory and so cannot be modified. > > The upside is that new lowlevel drivers cannot forget the assignment and low level > save one line each. The pwm-crc driver didn't assign .owner, that's not > a problem in practise though as the driver cannot be compiled as a > module. ... > drivers/pwm/pwm-lpss.c| 1 - Acked-by: Andy Shevchenko # Intel LPSS -- With Best Regards, Andy Shevchenko
Re: [PATCH v3 3/9] PM / QoS: Fix constraints alloc vs reclaim locking
On Fri, Aug 4, 2023 at 10:07 AM Rafael J. Wysocki wrote:
>
> On Fri, Aug 4, 2023 at 12:02 AM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > In the process of adding lockdep annotation for drm GPU scheduler's
> > job_run() to detect potential deadlock against shrinker/reclaim, I hit
> > this lockdep splat:
> >
> >==
> >WARNING: possible circular locking dependency detected
> >6.2.0-rc8-debug+ #558 Tainted: GW
> >--
> >ring0/125 is trying to acquire lock:
> >ffd6d6ce0f28 (dev_pm_qos_mtx){+.+.}-{3:3}, at:
> > dev_pm_qos_update_request+0x38/0x68
> >
> >but task is already holding lock:
> >ff8087239208 (>active_lock){+.+.}-{3:3}, at:
> > msm_gpu_submit+0xec/0x178
> >
> >which lock already depends on the new lock.
> >
> >the existing dependency chain (in reverse order) is:
> >
> >-> #4 (>active_lock){+.+.}-{3:3}:
> > __mutex_lock+0xcc/0x3c8
> > mutex_lock_nested+0x30/0x44
> > msm_gpu_submit+0xec/0x178
> > msm_job_run+0x78/0x150
> > drm_sched_main+0x290/0x370
> > kthread+0xf0/0x100
> > ret_from_fork+0x10/0x20
> >
> >-> #3 (dma_fence_map){}-{0:0}:
> > __dma_fence_might_wait+0x74/0xc0
> > dma_resv_lockdep+0x1f4/0x2f4
> > do_one_initcall+0x104/0x2bc
> > kernel_init_freeable+0x344/0x34c
> > kernel_init+0x30/0x134
> > ret_from_fork+0x10/0x20
> >
> >-> #2 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}:
> > fs_reclaim_acquire+0x80/0xa8
> > slab_pre_alloc_hook.constprop.0+0x40/0x25c
> > __kmem_cache_alloc_node+0x60/0x1cc
> > __kmalloc+0xd8/0x100
> > topology_parse_cpu_capacity+0x8c/0x178
> > get_cpu_for_node+0x88/0xc4
> > parse_cluster+0x1b0/0x28c
> > parse_cluster+0x8c/0x28c
> > init_cpu_topology+0x168/0x188
> > smp_prepare_cpus+0x24/0xf8
> > kernel_init_freeable+0x18c/0x34c
> > kernel_init+0x30/0x134
> > ret_from_fork+0x10/0x20
> >
> >-> #1 (fs_reclaim){+.+.}-{0:0}:
> > __fs_reclaim_acquire+0x3c/0x48
> > fs_reclaim_acquire+0x54/0xa8
> > slab_pre_alloc_hook.constprop.0+0x40/0x25c
> > __kmem_cache_alloc_node+0x60/0x1cc
> > kmalloc_trace+0x50/0xa8
> > dev_pm_qos_constraints_allocate+0x38/0x100
> > __dev_pm_qos_add_request+0xb0/0x1e8
> > dev_pm_qos_add_request+0x58/0x80
> > dev_pm_qos_expose_latency_limit+0x60/0x13c
> > register_cpu+0x12c/0x130
> > topology_init+0xac/0xbc
> > do_one_initcall+0x104/0x2bc
> > kernel_init_freeable+0x344/0x34c
> > kernel_init+0x30/0x134
> > ret_from_fork+0x10/0x20
> >
> >-> #0 (dev_pm_qos_mtx){+.+.}-{3:3}:
> > __lock_acquire+0xe00/0x1060
> > lock_acquire+0x1e0/0x2f8
> > __mutex_lock+0xcc/0x3c8
> > mutex_lock_nested+0x30/0x44
> > dev_pm_qos_update_request+0x38/0x68
> > msm_devfreq_boost+0x40/0x70
> > msm_devfreq_active+0xc0/0xf0
> > msm_gpu_submit+0x10c/0x178
> > msm_job_run+0x78/0x150
> > drm_sched_main+0x290/0x370
> > kthread+0xf0/0x100
> > ret_from_fork+0x10/0x20
> >
> >other info that might help us debug this:
> >
> >Chain exists of:
> > dev_pm_qos_mtx --> dma_fence_map --> >active_lock
> >
> > Possible unsafe locking scenario:
> >
> > CPU0CPU1
> >
> > lock(>active_lock);
> > lock(dma_fence_map);
> > lock(>active_lock);
> > lock(dev_pm_qos_mtx);
> >
> > *** DEADLOCK ***
> >
> >3 locks held by ring0/123:
> > #0: ff8087251170 (>lock){+.+.}-{3:3}, at:
> > msm_job_run+0x64/0x150
> > #1: ffd00b0e57e8 (dma_fence_map){}-{0:0}, at:
> > msm_job_run+0x68/0x150
> > #2: ff8087251208 (>active_lock){+.+.}-{3:3}, at:
> > msm_gpu_submit+0xec/0x178
> >
> >stack backtrace:
> >CPU: 6 PID: 123 Comm: ring0 Not tainted 6.2.0-rc8-debug+ #559
> >Hardware name: Google Lazor (rev1 - 2) with LTE (DT)
> >Call trace:
> > dump_backtrace.part.0+0xb4/0xf8
> > show_stack+0x20/0x38
> > dump_stack_lvl+0x9c/0xd0
> > dump_stack+0x18/0x34
> > print_circular_bug+0x1b4/0x1f0
> > check_noncircular+0x78/0xac
> > __lock_acquire+0xe00/0x1060
> > lock_acquire+0x1e0/0x2f8
> > __mutex_lock+0xcc/0x3c8
> > mutex_lock_nested+0x30/0x44
> > dev_pm_qos_update_request+0x38/0x68
> > msm_devfreq_boost+0x40/0x70
> > msm_devfreq_active+0xc0/0xf0
> > msm_gpu_submit+0x10c/0x178
> > msm_job_run+0x78/0x150
> > drm_sched_main+0x290/0x370
> > kthread+0xf0/0x100
[PATCH drm-misc-next v10 12/12] drm/nouveau: debugfs: implement DRM GPU VA debugfs
Provide the driver indirection iterating over all DRM GPU VA spaces to
enable the common 'gpuvas' debugfs file for dumping DRM GPU VA spaces.
Reviewed-by: Dave Airlie
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 99d022a91afc..053f703f2f68 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -203,6 +203,44 @@ nouveau_debugfs_pstate_open(struct inode *inode, struct
file *file)
return single_open(file, nouveau_debugfs_pstate_get, inode->i_private);
}
+static void
+nouveau_debugfs_gpuva_regions(struct seq_file *m, struct nouveau_uvmm *uvmm)
+{
+ MA_STATE(mas, >region_mt, 0, 0);
+ struct nouveau_uvma_region *reg;
+
+ seq_puts (m, " VA regions | start | range |
end\n");
+ seq_puts (m,
"\n");
+ mas_for_each(, reg, ULONG_MAX)
+ seq_printf(m, " | 0x%016llx | 0x%016llx |
0x%016llx\n",
+ reg->va.addr, reg->va.range, reg->va.addr +
reg->va.range);
+}
+
+static int
+nouveau_debugfs_gpuva(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = (struct drm_info_node *) m->private;
+ struct nouveau_drm *drm = nouveau_drm(node->minor->dev);
+ struct nouveau_cli *cli;
+
+ mutex_lock(>clients_lock);
+ list_for_each_entry(cli, >clients, head) {
+ struct nouveau_uvmm *uvmm = nouveau_cli_uvmm(cli);
+
+ if (!uvmm)
+ continue;
+
+ nouveau_uvmm_lock(uvmm);
+ drm_debugfs_gpuva_info(m, >umgr);
+ seq_puts(m, "\n");
+ nouveau_debugfs_gpuva_regions(m, uvmm);
+ nouveau_uvmm_unlock(uvmm);
+ }
+ mutex_unlock(>clients_lock);
+
+ return 0;
+}
+
static const struct file_operations nouveau_pstate_fops = {
.owner = THIS_MODULE,
.open = nouveau_debugfs_pstate_open,
@@ -214,6 +252,7 @@ static const struct file_operations nouveau_pstate_fops = {
static struct drm_info_list nouveau_debugfs_list[] = {
{ "vbios.rom", nouveau_debugfs_vbios_image, 0, NULL },
{ "strap_peek", nouveau_debugfs_strap_peek, 0, NULL },
+ DRM_DEBUGFS_GPUVA_INFO(nouveau_debugfs_gpuva, NULL),
};
#define NOUVEAU_DEBUGFS_ENTRIES ARRAY_SIZE(nouveau_debugfs_list)
--
2.41.0
[PATCH drm-misc-next v10 11/12] drm/nouveau: implement new VM_BIND uAPI
This commit provides the implementation for the new uapi motivated by the
Vulkan API. It allows user mode drivers (UMDs) to:
1) Initialize a GPU virtual address (VA) space via the new
DRM_IOCTL_NOUVEAU_VM_INIT ioctl for UMDs to specify the portion of VA
space managed by the kernel and userspace, respectively.
2) Allocate and free a VA space region as well as bind and unbind memory
to the GPUs VA space via the new DRM_IOCTL_NOUVEAU_VM_BIND ioctl.
UMDs can request the named operations to be processed either
synchronously or asynchronously. It supports DRM syncobjs
(incl. timelines) as synchronization mechanism. The management of the
GPU VA mappings is implemented with the DRM GPU VA manager.
3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl. The
execution happens asynchronously. It supports DRM syncobj (incl.
timelines) as synchronization mechanism. DRM GEM object locking is
handled with drm_exec.
Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC, use the DRM
GPU scheduler for the asynchronous paths.
Reviewed-by: Dave Airlie
Signed-off-by: Danilo Krummrich
---
Documentation/gpu/driver-uapi.rst |3 +
drivers/gpu/drm/nouveau/Kbuild |3 +
drivers/gpu/drm/nouveau/Kconfig |2 +
drivers/gpu/drm/nouveau/nouveau_abi16.c | 24 +
drivers/gpu/drm/nouveau/nouveau_abi16.h |1 +
drivers/gpu/drm/nouveau/nouveau_bo.c| 159 +-
drivers/gpu/drm/nouveau/nouveau_bo.h|3 +-
drivers/gpu/drm/nouveau/nouveau_drm.c | 27 +-
drivers/gpu/drm/nouveau/nouveau_drv.h | 58 +-
drivers/gpu/drm/nouveau/nouveau_exec.c | 411 +
drivers/gpu/drm/nouveau/nouveau_exec.h | 54 +
drivers/gpu/drm/nouveau/nouveau_gem.c | 49 +-
drivers/gpu/drm/nouveau/nouveau_gem.h |3 +-
drivers/gpu/drm/nouveau/nouveau_mem.h |5 +
drivers/gpu/drm/nouveau/nouveau_prime.c | 13 +-
drivers/gpu/drm/nouveau/nouveau_sched.c | 419 +
drivers/gpu/drm/nouveau/nouveau_sched.h | 127 ++
drivers/gpu/drm/nouveau/nouveau_uvmm.c | 1921 +++
drivers/gpu/drm/nouveau/nouveau_uvmm.h | 108 ++
19 files changed, 3321 insertions(+), 69 deletions(-)
create mode 100644 drivers/gpu/drm/nouveau/nouveau_exec.c
create mode 100644 drivers/gpu/drm/nouveau/nouveau_exec.h
create mode 100644 drivers/gpu/drm/nouveau/nouveau_sched.c
create mode 100644 drivers/gpu/drm/nouveau/nouveau_sched.h
create mode 100644 drivers/gpu/drm/nouveau/nouveau_uvmm.c
create mode 100644 drivers/gpu/drm/nouveau/nouveau_uvmm.h
diff --git a/Documentation/gpu/driver-uapi.rst
b/Documentation/gpu/driver-uapi.rst
index 9c7ca6e33a68..c08bcbb95fb3 100644
--- a/Documentation/gpu/driver-uapi.rst
+++ b/Documentation/gpu/driver-uapi.rst
@@ -13,4 +13,7 @@ drm/nouveau uAPI
VM_BIND / EXEC uAPI
---
+.. kernel-doc:: drivers/gpu/drm/nouveau/nouveau_exec.c
+:doc: Overview
+
.. kernel-doc:: include/uapi/drm/nouveau_drm.h
diff --git a/drivers/gpu/drm/nouveau/Kbuild b/drivers/gpu/drm/nouveau/Kbuild
index 5e5617006da5..cf6b3a80c0c8 100644
--- a/drivers/gpu/drm/nouveau/Kbuild
+++ b/drivers/gpu/drm/nouveau/Kbuild
@@ -47,6 +47,9 @@ nouveau-y += nouveau_prime.o
nouveau-y += nouveau_sgdma.o
nouveau-y += nouveau_ttm.o
nouveau-y += nouveau_vmm.o
+nouveau-y += nouveau_exec.o
+nouveau-y += nouveau_sched.o
+nouveau-y += nouveau_uvmm.o
# DRM - modesetting
nouveau-$(CONFIG_DRM_NOUVEAU_BACKLIGHT) += nouveau_backlight.o
diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig
index a70bd65e1400..c52e8096cca4 100644
--- a/drivers/gpu/drm/nouveau/Kconfig
+++ b/drivers/gpu/drm/nouveau/Kconfig
@@ -10,6 +10,8 @@ config DRM_NOUVEAU
select DRM_KMS_HELPER
select DRM_TTM
select DRM_TTM_HELPER
+ select DRM_EXEC
+ select DRM_SCHED
select I2C
select I2C_ALGOBIT
select BACKLIGHT_CLASS_DEVICE if DRM_NOUVEAU_BACKLIGHT
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index 82dab51d8aeb..30afbec9e3b1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -35,6 +35,7 @@
#include "nouveau_chan.h"
#include "nouveau_abi16.h"
#include "nouveau_vmm.h"
+#include "nouveau_sched.h"
static struct nouveau_abi16 *
nouveau_abi16(struct drm_file *file_priv)
@@ -125,6 +126,17 @@ nouveau_abi16_chan_fini(struct nouveau_abi16 *abi16,
{
struct nouveau_abi16_ntfy *ntfy, *temp;
+ /* When a client exits without waiting for it's queued up jobs to
+* finish it might happen that we fault the channel. This is due to
+* drm_file_free() calling drm_gem_release() before the postclose()
+* callback. Hence, we can't tear down this scheduler entity before
+* uvmm mappings are unmapped. Currently, we can't detect this case.
+*
+* However, this should be rare and harmless, since the channel isn't
+* needed anymore.
+*/
+
[PATCH drm-misc-next v10 10/12] drm/nouveau: nvkm/vmm: implement raw ops to manage uvmm
The new VM_BIND UAPI uses the DRM GPU VA manager to manage the VA space.
Hence, we a need a way to manipulate the MMUs page tables without going
through the internal range allocator implemented by nvkm/vmm.
This patch adds a raw interface for nvkm/vmm to pass the resposibility
for managing the address space and the corresponding map/unmap/sparse
operations to the upper layers.
Reviewed-by: Dave Airlie
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/include/nvif/if000c.h | 26 ++-
drivers/gpu/drm/nouveau/include/nvif/vmm.h| 19 +-
.../gpu/drm/nouveau/include/nvkm/subdev/mmu.h | 20 +-
drivers/gpu/drm/nouveau/nouveau_svm.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_vmm.c | 4 +-
drivers/gpu/drm/nouveau/nvif/vmm.c| 100 +++-
.../gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c| 213 --
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 197
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 25 ++
.../drm/nouveau/nvkm/subdev/mmu/vmmgf100.c| 16 +-
.../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c| 16 +-
.../gpu/drm/nouveau/nvkm/subdev/mmu/vmmnv50.c | 27 ++-
12 files changed, 566 insertions(+), 99 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvif/if000c.h
b/drivers/gpu/drm/nouveau/include/nvif/if000c.h
index 9c7ff56831c5..a5a182b3c28d 100644
--- a/drivers/gpu/drm/nouveau/include/nvif/if000c.h
+++ b/drivers/gpu/drm/nouveau/include/nvif/if000c.h
@@ -3,7 +3,10 @@
struct nvif_vmm_v0 {
__u8 version;
__u8 page_nr;
- __u8 managed;
+#define NVIF_VMM_V0_TYPE_UNMANAGED 0x00
+#define NVIF_VMM_V0_TYPE_MANAGED 0x01
+#define NVIF_VMM_V0_TYPE_RAW 0x02
+ __u8 type;
__u8 pad03[5];
__u64 addr;
__u64 size;
@@ -17,6 +20,7 @@ struct nvif_vmm_v0 {
#define NVIF_VMM_V0_UNMAP 0x04
#define NVIF_VMM_V0_PFNMAP 0x05
#define NVIF_VMM_V0_PFNCLR 0x06
+#define NVIF_VMM_V0_RAW0x07
#define NVIF_VMM_V0_MTHD(i) ((i) +
0x80)
struct nvif_vmm_page_v0 {
@@ -66,6 +70,26 @@ struct nvif_vmm_unmap_v0 {
__u64 addr;
};
+struct nvif_vmm_raw_v0 {
+ __u8 version;
+#define NVIF_VMM_RAW_V0_GET0x0
+#define NVIF_VMM_RAW_V0_PUT0x1
+#define NVIF_VMM_RAW_V0_MAP0x2
+#define NVIF_VMM_RAW_V0_UNMAP 0x3
+#define NVIF_VMM_RAW_V0_SPARSE 0x4
+ __u8 op;
+ __u8 sparse;
+ __u8 ref;
+ __u8 shift;
+ __u32 argc;
+ __u8 pad01[7];
+ __u64 addr;
+ __u64 size;
+ __u64 offset;
+ __u64 memory;
+ __u64 argv;
+};
+
struct nvif_vmm_pfnmap_v0 {
__u8 version;
__u8 page;
diff --git a/drivers/gpu/drm/nouveau/include/nvif/vmm.h
b/drivers/gpu/drm/nouveau/include/nvif/vmm.h
index a2ee92201ace..0ecedd0ee0a5 100644
--- a/drivers/gpu/drm/nouveau/include/nvif/vmm.h
+++ b/drivers/gpu/drm/nouveau/include/nvif/vmm.h
@@ -4,6 +4,12 @@
struct nvif_mem;
struct nvif_mmu;
+enum nvif_vmm_type {
+ UNMANAGED,
+ MANAGED,
+ RAW,
+};
+
enum nvif_vmm_get {
ADDR,
PTES,
@@ -30,8 +36,9 @@ struct nvif_vmm {
int page_nr;
};
-int nvif_vmm_ctor(struct nvif_mmu *, const char *name, s32 oclass, bool
managed,
- u64 addr, u64 size, void *argv, u32 argc, struct nvif_vmm *);
+int nvif_vmm_ctor(struct nvif_mmu *, const char *name, s32 oclass,
+ enum nvif_vmm_type, u64 addr, u64 size, void *argv, u32 argc,
+ struct nvif_vmm *);
void nvif_vmm_dtor(struct nvif_vmm *);
int nvif_vmm_get(struct nvif_vmm *, enum nvif_vmm_get, bool sparse,
u8 page, u8 align, u64 size, struct nvif_vma *);
@@ -39,4 +46,12 @@ void nvif_vmm_put(struct nvif_vmm *, struct nvif_vma *);
int nvif_vmm_map(struct nvif_vmm *, u64 addr, u64 size, void *argv, u32 argc,
struct nvif_mem *, u64 offset);
int nvif_vmm_unmap(struct nvif_vmm *, u64);
+
+int nvif_vmm_raw_get(struct nvif_vmm *vmm, u64 addr, u64 size, u8 shift);
+int nvif_vmm_raw_put(struct nvif_vmm *vmm, u64 addr, u64 size, u8 shift);
+int nvif_vmm_raw_map(struct nvif_vmm *vmm, u64 addr, u64 size, u8 shift,
+void *argv, u32 argc, struct nvif_mem *mem, u64 offset);
+int nvif_vmm_raw_unmap(struct nvif_vmm *vmm, u64 addr, u64 size,
+ u8 shift, bool sparse);
+int nvif_vmm_raw_sparse(struct nvif_vmm *vmm, u64 addr, u64 size, bool ref);
#endif
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h
index 70e7887ef4b4..2fd2f2433fc7 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h
+++
[PATCH drm-misc-next v10 09/12] drm/nouveau: chan: provide nouveau_channel_kill()
The new VM_BIND UAPI implementation introduced in subsequent commits
will allow asynchronous jobs processing push buffers and emitting fences.
If a job times out, we need a way to recover from this situation. For
now, simply kill the channel to unblock all hung up jobs and signal
userspace that the device is dead on the next EXEC or VM_BIND ioctl.
Reviewed-by: Dave Airlie
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_chan.c | 14 +++---
drivers/gpu/drm/nouveau/nouveau_chan.h | 1 +
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index f69be4c8f9f2..1fd5ccf41128 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -40,6 +40,14 @@ MODULE_PARM_DESC(vram_pushbuf, "Create DMA push buffers in
VRAM");
int nouveau_vram_pushbuf;
module_param_named(vram_pushbuf, nouveau_vram_pushbuf, int, 0400);
+void
+nouveau_channel_kill(struct nouveau_channel *chan)
+{
+ atomic_set(>killed, 1);
+ if (chan->fence)
+ nouveau_fence_context_kill(chan->fence, -ENODEV);
+}
+
static int
nouveau_channel_killed(struct nvif_event *event, void *repv, u32 repc)
{
@@ -47,9 +55,9 @@ nouveau_channel_killed(struct nvif_event *event, void *repv,
u32 repc)
struct nouveau_cli *cli = (void *)chan->user.client;
NV_PRINTK(warn, cli, "channel %d killed!\n", chan->chid);
- atomic_set(>killed, 1);
- if (chan->fence)
- nouveau_fence_context_kill(chan->fence, -ENODEV);
+
+ if (unlikely(!atomic_read(>killed)))
+ nouveau_channel_kill(chan);
return NVIF_EVENT_DROP;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.h
b/drivers/gpu/drm/nouveau/nouveau_chan.h
index bad7466bd0d5..5de2ef4e98c2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.h
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.h
@@ -66,6 +66,7 @@ int nouveau_channel_new(struct nouveau_drm *, struct
nvif_device *, bool priv,
u32 vram, u32 gart, struct nouveau_channel **);
void nouveau_channel_del(struct nouveau_channel **);
int nouveau_channel_idle(struct nouveau_channel *);
+void nouveau_channel_kill(struct nouveau_channel *);
extern int nouveau_vram_pushbuf;
--
2.41.0
[PATCH drm-misc-next v10 08/12] drm/nouveau: fence: fail to emit when fence context is killed
The new VM_BIND UAPI implementation introduced in subsequent commits
will allow asynchronous jobs processing push buffers and emitting
fences.
If a fence context is killed, e.g. due to a channel fault, jobs which
are already queued for execution might still emit new fences. In such a
case a job would hang forever.
To fix that, fail to emit a new fence on a killed fence context with
-ENODEV to unblock the job.
Reviewed-by: Dave Airlie
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 7 +++
drivers/gpu/drm/nouveau/nouveau_fence.h | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index e946408f945b..77c739a55b19 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -96,6 +96,7 @@ nouveau_fence_context_kill(struct nouveau_fence_chan *fctx,
int error)
if (nouveau_fence_signal(fence))
nvif_event_block(>event);
}
+ fctx->killed = 1;
spin_unlock_irqrestore(>lock, flags);
}
@@ -229,6 +230,12 @@ nouveau_fence_emit(struct nouveau_fence *fence, struct
nouveau_channel *chan)
dma_fence_get(>base);
spin_lock_irq(>lock);
+ if (unlikely(fctx->killed)) {
+ spin_unlock_irq(>lock);
+ dma_fence_put(>base);
+ return -ENODEV;
+ }
+
if (nouveau_fence_update(chan, fctx))
nvif_event_block(>event);
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.h
b/drivers/gpu/drm/nouveau/nouveau_fence.h
index 7c73c7c9834a..2c72d96ef17d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.h
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.h
@@ -44,7 +44,7 @@ struct nouveau_fence_chan {
char name[32];
struct nvif_event event;
- int notify_ref, dead;
+ int notify_ref, dead, killed;
};
struct nouveau_fence_priv {
--
2.41.0
[PATCH drm-misc-next v10 07/12] drm/nouveau: fence: separate fence alloc and emit
The new (VM_BIND) UAPI exports DMA fences through DRM syncobjs. Hence,
in order to emit fences within DMA fence signalling critical sections
(e.g. as typically done in the DRM GPU schedulers run_job() callback) we
need to separate fence allocation and fence emitting.
Reviewed-by: Dave Airlie
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 9 -
drivers/gpu/drm/nouveau/nouveau_bo.c| 52 +++--
drivers/gpu/drm/nouveau/nouveau_chan.c | 6 ++-
drivers/gpu/drm/nouveau/nouveau_dmem.c | 9 +++--
drivers/gpu/drm/nouveau/nouveau_fence.c | 16 +++-
drivers/gpu/drm/nouveau/nouveau_fence.h | 3 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 5 ++-
7 files changed, 59 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index a6f2e681bde9..a34924523133 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -1122,11 +1122,18 @@ nv04_page_flip_emit(struct nouveau_channel *chan,
PUSH_NVSQ(push, NV_SW, NV_SW_PAGE_FLIP, 0x);
PUSH_KICK(push);
- ret = nouveau_fence_new(chan, false, pfence);
+ ret = nouveau_fence_new(pfence);
if (ret)
goto fail;
+ ret = nouveau_fence_emit(*pfence, chan);
+ if (ret)
+ goto fail_fence_unref;
+
return 0;
+
+fail_fence_unref:
+ nouveau_fence_unref(pfence);
fail:
spin_lock_irqsave(>event_lock, flags);
list_del(>head);
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 6130c99b6b2c..e38e448d9632 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -823,29 +823,39 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int
evict,
mutex_lock(>mutex);
else
mutex_lock_nested(>mutex, SINGLE_DEPTH_NESTING);
+
ret = nouveau_fence_sync(nouveau_bo(bo), chan, true,
ctx->interruptible);
- if (ret == 0) {
- ret = drm->ttm.move(chan, bo, bo->resource, new_reg);
- if (ret == 0) {
- ret = nouveau_fence_new(chan, false, );
- if (ret == 0) {
- /* TODO: figure out a better solution here
-*
-* wait on the fence here explicitly as going
through
-* ttm_bo_move_accel_cleanup somehow doesn't
seem to do it.
-*
-* Without this the operation can timeout and
we'll fallback to a
-* software copy, which might take several
minutes to finish.
-*/
- nouveau_fence_wait(fence, false, false);
- ret = ttm_bo_move_accel_cleanup(bo,
- >base,
- evict, false,
- new_reg);
- nouveau_fence_unref();
- }
- }
+ if (ret)
+ goto out_unlock;
+
+ ret = drm->ttm.move(chan, bo, bo->resource, new_reg);
+ if (ret)
+ goto out_unlock;
+
+ ret = nouveau_fence_new();
+ if (ret)
+ goto out_unlock;
+
+ ret = nouveau_fence_emit(fence, chan);
+ if (ret) {
+ nouveau_fence_unref();
+ goto out_unlock;
}
+
+ /* TODO: figure out a better solution here
+*
+* wait on the fence here explicitly as going through
+* ttm_bo_move_accel_cleanup somehow doesn't seem to do it.
+*
+* Without this the operation can timeout and we'll fallback to a
+* software copy, which might take several minutes to finish.
+*/
+ nouveau_fence_wait(fence, false, false);
+ ret = ttm_bo_move_accel_cleanup(bo, >base, evict, false,
+ new_reg);
+ nouveau_fence_unref();
+
+out_unlock:
mutex_unlock(>mutex);
return ret;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index 6d639314250a..f69be4c8f9f2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -62,9 +62,11 @@ nouveau_channel_idle(struct nouveau_channel *chan)
struct nouveau_fence *fence = NULL;
int ret;
- ret = nouveau_fence_new(chan, false, );
+ ret = nouveau_fence_new();
if (!ret) {
- ret = nouveau_fence_wait(fence, false, false);
+ ret = nouveau_fence_emit(fence, chan);
+ if (!ret)
Re: [PATCH v2] drm/amd/display: ensure async flips are only accepted for fast updates
On 2023-08-04 14:20, Hamza Mahfooz wrote:
> We should be checking to see if async flips are supported in
> amdgpu_dm_atomic_check() (i.e. not dm_crtc_helper_atomic_check()). Also,
> async flipping isn't supported if a plane's framebuffer changes memory
> domains during an atomic commit. So, move the check from
> dm_crtc_helper_atomic_check() to amdgpu_dm_atomic_check() and check if
> the memory domain has changed in amdgpu_dm_atomic_check().
>
> Cc: sta...@vger.kernel.org
> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2733
> Fixes: 3f86b60691e6 ("drm/amd/display: only accept async flips for fast
> updates")
> Signed-off-by: Hamza Mahfooz
Reviewed-by: Harry Wentland
Harry
> ---
> v2: link issue and revert back to the old way of setting update_type.
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 24 ---
> .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 12 --
> 2 files changed, 21 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 32fb551862b0..1d3afab5bc85 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -8086,10 +8086,12 @@ static void amdgpu_dm_commit_planes(struct
> drm_atomic_state *state,
>* fast updates.
>*/
> if (crtc->state->async_flip &&
> - acrtc_state->update_type != UPDATE_TYPE_FAST)
> + (acrtc_state->update_type != UPDATE_TYPE_FAST ||
> + get_mem_type(old_plane_state->fb) != get_mem_type(fb)))
> drm_warn_once(state->dev,
> "[PLANE:%d:%s] async flip with non-fast
> update\n",
> plane->base.id, plane->name);
> +
> bundle->flip_addrs[planes_count].flip_immediate =
> crtc->state->async_flip &&
> acrtc_state->update_type == UPDATE_TYPE_FAST &&
> @@ -10050,6 +10052,11 @@ static int amdgpu_dm_atomic_check(struct drm_device
> *dev,
>
> /* Remove exiting planes if they are modified */
> for_each_oldnew_plane_in_state_reverse(state, plane, old_plane_state,
> new_plane_state, i) {
> + if (old_plane_state->fb && new_plane_state->fb &&
> + get_mem_type(old_plane_state->fb) !=
> + get_mem_type(new_plane_state->fb))
> + lock_and_validation_needed = true;
> +
> ret = dm_update_plane_state(dc, state, plane,
> old_plane_state,
> new_plane_state,
> @@ -10297,9 +10304,20 @@ static int amdgpu_dm_atomic_check(struct drm_device
> *dev,
> struct dm_crtc_state *dm_new_crtc_state =
> to_dm_crtc_state(new_crtc_state);
>
> + /*
> + * Only allow async flips for fast updates that don't change
> + * the FB pitch, the DCC state, rotation, etc.
> + */
> + if (new_crtc_state->async_flip && lock_and_validation_needed) {
> + drm_dbg_atomic(crtc->dev,
> +"[CRTC:%d:%s] async flips are only
> supported for fast updates\n",
> +crtc->base.id, crtc->name);
> + ret = -EINVAL;
> + goto fail;
> + }
> +
> dm_new_crtc_state->update_type = lock_and_validation_needed ?
> - UPDATE_TYPE_FULL :
> - UPDATE_TYPE_FAST;
> + UPDATE_TYPE_FULL : UPDATE_TYPE_FAST;
> }
>
> /* Must be success */
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
> index 30d4c6fd95f5..440fc0869a34 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
> @@ -398,18 +398,6 @@ static int dm_crtc_helper_atomic_check(struct drm_crtc
> *crtc,
> return -EINVAL;
> }
>
> - /*
> - * Only allow async flips for fast updates that don't change the FB
> - * pitch, the DCC state, rotation, etc.
> - */
> - if (crtc_state->async_flip &&
> - dm_crtc_state->update_type != UPDATE_TYPE_FAST) {
> - drm_dbg_atomic(crtc->dev,
> -"[CRTC:%d:%s] async flips are only supported for
> fast updates\n",
> -crtc->base.id, crtc->name);
> - return -EINVAL;
> - }
> -
> /* In some use cases, like reset, no stream is attached */
> if (!dm_crtc_state->stream)
> return 0;
[PATCH drm-misc-next v10 06/12] drm/nouveau: move usercopy helpers to nouveau_drv.h
Move the usercopy helpers to a common driver header file to make it
usable for the new API added in subsequent commits.
Reviewed-by: Dave Airlie
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_drv.h | 26 ++
drivers/gpu/drm/nouveau/nouveau_gem.c | 26 --
2 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 81350e685b50..d28236021971 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -130,6 +130,32 @@ nouveau_cli(struct drm_file *fpriv)
return fpriv ? fpriv->driver_priv : NULL;
}
+static inline void
+u_free(void *addr)
+{
+ kvfree(addr);
+}
+
+static inline void *
+u_memcpya(uint64_t user, unsigned int nmemb, unsigned int size)
+{
+ void *mem;
+ void __user *userptr = (void __force __user *)(uintptr_t)user;
+
+ size *= nmemb;
+
+ mem = kvmalloc(size, GFP_KERNEL);
+ if (!mem)
+ return ERR_PTR(-ENOMEM);
+
+ if (copy_from_user(mem, userptr, size)) {
+ u_free(mem);
+ return ERR_PTR(-EFAULT);
+ }
+
+ return mem;
+}
+
#include
#include
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 45ca4eb98f54..a48f42aaeab9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -613,32 +613,6 @@ nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
return 0;
}
-static inline void
-u_free(void *addr)
-{
- kvfree(addr);
-}
-
-static inline void *
-u_memcpya(uint64_t user, unsigned nmemb, unsigned size)
-{
- void *mem;
- void __user *userptr = (void __force __user *)(uintptr_t)user;
-
- size *= nmemb;
-
- mem = kvmalloc(size, GFP_KERNEL);
- if (!mem)
- return ERR_PTR(-ENOMEM);
-
- if (copy_from_user(mem, userptr, size)) {
- u_free(mem);
- return ERR_PTR(-EFAULT);
- }
-
- return mem;
-}
-
static int
nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
struct drm_nouveau_gem_pushbuf *req,
--
2.41.0
[PATCH drm-misc-next v10 05/12] drm/nouveau: bo: initialize GEM GPU VA interface
Initialize the GEM's DRM GPU VA manager interface in preparation for the (u)vmm implementation, provided by subsequent commits, to make use of it. Reviewed-by: Dave Airlie Signed-off-by: Danilo Krummrich --- drivers/gpu/drm/nouveau/nouveau_bo.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index 7724fe63067d..6130c99b6b2c 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -215,6 +215,7 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int *align, u32 domain, nvbo = kzalloc(sizeof(struct nouveau_bo), GFP_KERNEL); if (!nvbo) return ERR_PTR(-ENOMEM); + INIT_LIST_HEAD(>head); INIT_LIST_HEAD(>entry); INIT_LIST_HEAD(>vma_list); @@ -339,6 +340,11 @@ nouveau_bo_new(struct nouveau_cli *cli, u64 size, int align, dma_resv_init(>bo.base._resv); drm_vma_node_reset(>bo.base.vma_node); + /* This must be called before ttm_bo_init_reserved(). Subsequent +* bo_move() callbacks might already iterate the GEMs GPUVA list. +*/ + drm_gem_gpuva_init(>bo.base); + ret = nouveau_bo_init(nvbo, size, align, domain, sg, robj); if (ret) return ret; -- 2.41.0
[PATCH drm-misc-next v10 04/12] drm/nouveau: get vmm via nouveau_cli_vmm()
Provide a getter function for the client's current vmm context. Since
we'll add a new (u)vmm context for UMD bindings in subsequent commits,
this will keep the code clean.
Reviewed-by: Dave Airlie
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_drv.h | 9 +
drivers/gpu/drm/nouveau/nouveau_gem.c | 6 +++---
4 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index c2ec91cc845d..7724fe63067d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -204,7 +204,7 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int
*align, u32 domain,
struct nouveau_drm *drm = cli->drm;
struct nouveau_bo *nvbo;
struct nvif_mmu *mmu = >mmu;
- struct nvif_vmm *vmm = cli->svm.cli ? >svm.vmm : >vmm.vmm;
+ struct nvif_vmm *vmm = _cli_vmm(cli)->vmm;
int i, pi = -1;
if (!*size) {
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index 3dfbc374478e..6d639314250a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -149,7 +149,7 @@ nouveau_channel_prep(struct nouveau_drm *drm, struct
nvif_device *device,
chan->device = device;
chan->drm = drm;
- chan->vmm = cli->svm.cli ? >svm : >vmm;
+ chan->vmm = nouveau_cli_vmm(cli);
atomic_set(>killed, 0);
/* allocate memory for dma push buffer */
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index b5de312a523f..81350e685b50 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -112,6 +112,15 @@ struct nouveau_cli_work {
struct dma_fence_cb cb;
};
+static inline struct nouveau_vmm *
+nouveau_cli_vmm(struct nouveau_cli *cli)
+{
+ if (cli->svm.cli)
+ return >svm;
+
+ return >vmm;
+}
+
void nouveau_cli_work_queue(struct nouveau_cli *, struct dma_fence *,
struct nouveau_cli_work *);
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index ab9062e50977..45ca4eb98f54 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -103,7 +103,7 @@ nouveau_gem_object_open(struct drm_gem_object *gem, struct
drm_file *file_priv)
struct nouveau_bo *nvbo = nouveau_gem_object(gem);
struct nouveau_drm *drm = nouveau_bdev(nvbo->bo.bdev);
struct device *dev = drm->dev->dev;
- struct nouveau_vmm *vmm = cli->svm.cli ? >svm : >vmm;
+ struct nouveau_vmm *vmm = nouveau_cli_vmm(cli);
struct nouveau_vma *vma;
int ret;
@@ -180,7 +180,7 @@ nouveau_gem_object_close(struct drm_gem_object *gem, struct
drm_file *file_priv)
struct nouveau_bo *nvbo = nouveau_gem_object(gem);
struct nouveau_drm *drm = nouveau_bdev(nvbo->bo.bdev);
struct device *dev = drm->dev->dev;
- struct nouveau_vmm *vmm = cli->svm.cli ? >svm : & cli->vmm;
+ struct nouveau_vmm *vmm = nouveau_cli_vmm(cli);
struct nouveau_vma *vma;
int ret;
@@ -269,7 +269,7 @@ nouveau_gem_info(struct drm_file *file_priv, struct
drm_gem_object *gem,
{
struct nouveau_cli *cli = nouveau_cli(file_priv);
struct nouveau_bo *nvbo = nouveau_gem_object(gem);
- struct nouveau_vmm *vmm = cli->svm.cli ? >svm : >vmm;
+ struct nouveau_vmm *vmm = nouveau_cli_vmm(cli);
struct nouveau_vma *vma;
if (is_power_of_2(nvbo->valid_domains))
--
2.41.0
[PATCH drm-misc-next v10 02/12] drm/nouveau: fixup the uapi header file.
From: Dave Airlie
nouveau > 10 years ago had a plan for new multiplexer inside a multiplexer
API using nvif. It never fully reached fruition, fast forward 10 years,
and the new vulkan driver is avoiding libdrm and calling ioctls, and
these 3 ioctls, getparam, channel alloc + free don't seem to be things
we'd want to use nvif for.
Undeprecate and put them into the uapi header so we can just copy it
into mesa later.
v2: use uapi types.
Reviewed-by: Faith Ekstrand
Signed-off-by: Dave Airlie
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_abi16.h | 41 -
include/uapi/drm/nouveau_drm.h | 48 +++--
2 files changed, 45 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.h
b/drivers/gpu/drm/nouveau/nouveau_abi16.h
index 27eae85f33e6..d5d80d0d9011 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.h
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.h
@@ -43,28 +43,6 @@ int nouveau_abi16_usif(struct drm_file *, void *data, u32
size);
#define NOUVEAU_GEM_DOMAIN_VRAM (1 << 1)
#define NOUVEAU_GEM_DOMAIN_GART (1 << 2)
-struct drm_nouveau_channel_alloc {
- uint32_t fb_ctxdma_handle;
- uint32_t tt_ctxdma_handle;
-
- int channel;
- uint32_t pushbuf_domains;
-
- /* Notifier memory */
- uint32_t notifier_handle;
-
- /* DRM-enforced subchannel assignments */
- struct {
- uint32_t handle;
- uint32_t grclass;
- } subchan[8];
- uint32_t nr_subchan;
-};
-
-struct drm_nouveau_channel_free {
- int channel;
-};
-
struct drm_nouveau_grobj_alloc {
int channel;
uint32_t handle;
@@ -83,31 +61,12 @@ struct drm_nouveau_gpuobj_free {
uint32_t handle;
};
-#define NOUVEAU_GETPARAM_PCI_VENDOR 3
-#define NOUVEAU_GETPARAM_PCI_DEVICE 4
-#define NOUVEAU_GETPARAM_BUS_TYPE5
-#define NOUVEAU_GETPARAM_FB_SIZE 8
-#define NOUVEAU_GETPARAM_AGP_SIZE9
-#define NOUVEAU_GETPARAM_CHIPSET_ID 11
-#define NOUVEAU_GETPARAM_VM_VRAM_BASE12
-#define NOUVEAU_GETPARAM_GRAPH_UNITS 13
-#define NOUVEAU_GETPARAM_PTIMER_TIME 14
-#define NOUVEAU_GETPARAM_HAS_BO_USAGE15
-#define NOUVEAU_GETPARAM_HAS_PAGEFLIP16
-struct drm_nouveau_getparam {
- uint64_t param;
- uint64_t value;
-};
-
struct drm_nouveau_setparam {
uint64_t param;
uint64_t value;
};
-#define DRM_IOCTL_NOUVEAU_GETPARAM DRM_IOWR(DRM_COMMAND_BASE +
DRM_NOUVEAU_GETPARAM, struct drm_nouveau_getparam)
#define DRM_IOCTL_NOUVEAU_SETPARAM DRM_IOWR(DRM_COMMAND_BASE +
DRM_NOUVEAU_SETPARAM, struct drm_nouveau_setparam)
-#define DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC DRM_IOWR(DRM_COMMAND_BASE +
DRM_NOUVEAU_CHANNEL_ALLOC, struct drm_nouveau_channel_alloc)
-#define DRM_IOCTL_NOUVEAU_CHANNEL_FREE DRM_IOW (DRM_COMMAND_BASE +
DRM_NOUVEAU_CHANNEL_FREE, struct drm_nouveau_channel_free)
#define DRM_IOCTL_NOUVEAU_GROBJ_ALLOCDRM_IOW (DRM_COMMAND_BASE +
DRM_NOUVEAU_GROBJ_ALLOC, struct drm_nouveau_grobj_alloc)
#define DRM_IOCTL_NOUVEAU_NOTIFIEROBJ_ALLOC DRM_IOWR(DRM_COMMAND_BASE +
DRM_NOUVEAU_NOTIFIEROBJ_ALLOC, struct drm_nouveau_notifierobj_alloc)
#define DRM_IOCTL_NOUVEAU_GPUOBJ_FREEDRM_IOW (DRM_COMMAND_BASE +
DRM_NOUVEAU_GPUOBJ_FREE, struct drm_nouveau_gpuobj_free)
diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
index 853a327433d3..ca917e55b38f 100644
--- a/include/uapi/drm/nouveau_drm.h
+++ b/include/uapi/drm/nouveau_drm.h
@@ -33,6 +33,44 @@
extern "C" {
#endif
+#define NOUVEAU_GETPARAM_PCI_VENDOR 3
+#define NOUVEAU_GETPARAM_PCI_DEVICE 4
+#define NOUVEAU_GETPARAM_BUS_TYPE5
+#define NOUVEAU_GETPARAM_FB_SIZE 8
+#define NOUVEAU_GETPARAM_AGP_SIZE9
+#define NOUVEAU_GETPARAM_CHIPSET_ID 11
+#define NOUVEAU_GETPARAM_VM_VRAM_BASE12
+#define NOUVEAU_GETPARAM_GRAPH_UNITS 13
+#define NOUVEAU_GETPARAM_PTIMER_TIME 14
+#define NOUVEAU_GETPARAM_HAS_BO_USAGE15
+#define NOUVEAU_GETPARAM_HAS_PAGEFLIP16
+struct drm_nouveau_getparam {
+ __u64 param;
+ __u64 value;
+};
+
+struct drm_nouveau_channel_alloc {
+ __u32 fb_ctxdma_handle;
+ __u32 tt_ctxdma_handle;
+
+ __s32 channel;
+ __u32 pushbuf_domains;
+
+ /* Notifier memory */
+ __u32 notifier_handle;
+
+ /* DRM-enforced subchannel assignments */
+ struct {
+ __u32 handle;
+ __u32 grclass;
+ } subchan[8];
+ __u32 nr_subchan;
+};
+
+struct drm_nouveau_channel_free {
+ __s32 channel;
+};
+
#define NOUVEAU_GEM_DOMAIN_CPU (1 << 0)
#define NOUVEAU_GEM_DOMAIN_VRAM (1 << 1)
#define NOUVEAU_GEM_DOMAIN_GART (1 << 2)
@@ -126,10 +164,10 @@ struct drm_nouveau_gem_cpu_fini {
__u32 handle;
};
-#define DRM_NOUVEAU_GETPARAM 0x00 /* deprecated */
+#define
[PATCH drm-misc-next v10 03/12] drm/nouveau: new VM_BIND uAPI interfaces
This commit provides the interfaces for the new UAPI motivated by the
Vulkan API. It allows user mode drivers (UMDs) to:
1) Initialize a GPU virtual address (VA) space via the new
DRM_IOCTL_NOUVEAU_VM_INIT ioctl. UMDs can provide a kernel reserved
VA area.
2) Bind and unbind GPU VA space mappings via the new
DRM_IOCTL_NOUVEAU_VM_BIND ioctl.
3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl.
Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC support
asynchronous processing with DRM syncobjs as synchronization mechanism.
The default DRM_IOCTL_NOUVEAU_VM_BIND is synchronous processing,
DRM_IOCTL_NOUVEAU_EXEC supports asynchronous processing only.
Reviewed-by: Faith Ekstrand
Reviewed-by: Dave Airlie
Co-developed-by: Dave Airlie
Signed-off-by: Danilo Krummrich
---
Documentation/gpu/driver-uapi.rst | 8 ++
include/uapi/drm/nouveau_drm.h| 217 ++
2 files changed, 225 insertions(+)
diff --git a/Documentation/gpu/driver-uapi.rst
b/Documentation/gpu/driver-uapi.rst
index 4411e6919a3d..9c7ca6e33a68 100644
--- a/Documentation/gpu/driver-uapi.rst
+++ b/Documentation/gpu/driver-uapi.rst
@@ -6,3 +6,11 @@ drm/i915 uAPI
=
.. kernel-doc:: include/uapi/drm/i915_drm.h
+
+drm/nouveau uAPI
+
+
+VM_BIND / EXEC uAPI
+---
+
+.. kernel-doc:: include/uapi/drm/nouveau_drm.h
diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
index ca917e55b38f..b1ad9d5ffce8 100644
--- a/include/uapi/drm/nouveau_drm.h
+++ b/include/uapi/drm/nouveau_drm.h
@@ -76,6 +76,8 @@ struct drm_nouveau_channel_free {
#define NOUVEAU_GEM_DOMAIN_GART (1 << 2)
#define NOUVEAU_GEM_DOMAIN_MAPPABLE (1 << 3)
#define NOUVEAU_GEM_DOMAIN_COHERENT (1 << 4)
+/* The BO will never be shared via import or export. */
+#define NOUVEAU_GEM_DOMAIN_NO_SHARE (1 << 5)
#define NOUVEAU_GEM_TILE_COMP0x0003 /* nv50-only */
#define NOUVEAU_GEM_TILE_LAYOUT_MASK 0xff00
@@ -164,6 +166,215 @@ struct drm_nouveau_gem_cpu_fini {
__u32 handle;
};
+/**
+ * struct drm_nouveau_sync - sync object
+ *
+ * This structure serves as synchronization mechanism for (potentially)
+ * asynchronous operations such as EXEC or VM_BIND.
+ */
+struct drm_nouveau_sync {
+ /**
+* @flags: the flags for a sync object
+*
+* The first 8 bits are used to determine the type of the sync object.
+*/
+ __u32 flags;
+#define DRM_NOUVEAU_SYNC_SYNCOBJ 0x0
+#define DRM_NOUVEAU_SYNC_TIMELINE_SYNCOBJ 0x1
+#define DRM_NOUVEAU_SYNC_TYPE_MASK 0xf
+ /**
+* @handle: the handle of the sync object
+*/
+ __u32 handle;
+ /**
+* @timeline_value:
+*
+* The timeline point of the sync object in case the syncobj is of
+* type DRM_NOUVEAU_SYNC_TIMELINE_SYNCOBJ.
+*/
+ __u64 timeline_value;
+};
+
+/**
+ * struct drm_nouveau_vm_init - GPU VA space init structure
+ *
+ * Used to initialize the GPU's VA space for a user client, telling the kernel
+ * which portion of the VA space is managed by the UMD and kernel respectively.
+ *
+ * For the UMD to use the VM_BIND uAPI, this must be called before any BOs or
+ * channels are created; if called afterwards DRM_IOCTL_NOUVEAU_VM_INIT fails
+ * with -ENOSYS.
+ */
+struct drm_nouveau_vm_init {
+ /**
+* @kernel_managed_addr: start address of the kernel managed VA space
+* region
+*/
+ __u64 kernel_managed_addr;
+ /**
+* @kernel_managed_size: size of the kernel managed VA space region in
+* bytes
+*/
+ __u64 kernel_managed_size;
+};
+
+/**
+ * struct drm_nouveau_vm_bind_op - VM_BIND operation
+ *
+ * This structure represents a single VM_BIND operation. UMDs should pass
+ * an array of this structure via struct drm_nouveau_vm_bind's _ptr field.
+ */
+struct drm_nouveau_vm_bind_op {
+ /**
+* @op: the operation type
+*/
+ __u32 op;
+/**
+ * @DRM_NOUVEAU_VM_BIND_OP_MAP:
+ *
+ * Map a GEM object to the GPU's VA space. Optionally, the
+ * _NOUVEAU_VM_BIND_SPARSE flag can be passed to instruct the kernel to
+ * create sparse mappings for the given range.
+ */
+#define DRM_NOUVEAU_VM_BIND_OP_MAP 0x0
+/**
+ * @DRM_NOUVEAU_VM_BIND_OP_UNMAP:
+ *
+ * Unmap an existing mapping in the GPU's VA space. If the region the mapping
+ * is located in is a sparse region, new sparse mappings are created where the
+ * unmapped (memory backed) mapping was mapped previously. To remove a sparse
+ * region the _NOUVEAU_VM_BIND_SPARSE must be set.
+ */
+#define DRM_NOUVEAU_VM_BIND_OP_UNMAP 0x1
+ /**
+* @flags: the flags for a _nouveau_vm_bind_op
+*/
+ __u32 flags;
+/**
+ * @DRM_NOUVEAU_VM_BIND_SPARSE:
+ *
+ * Indicates that an allocated VA space region should be sparse.
+ */
+#define DRM_NOUVEAU_VM_BIND_SPARSE (1 << 8)
+ /**
+* @handle: the handle of the DRM GEM object to map
+
[PATCH drm-misc-next v10 01/12] drm/gem: fix lockdep check for dma-resv lock
When no custom lock is set to protect a GEMs GPUVA list, lockdep checks
should fall back to the GEM objects dma-resv lock. With the current
implementation we're setting the lock_dep_map of the GEM objects 'resv'
pointer (in case no custom lock_dep_map is set yet) on
drm_gem_private_object_init().
However, the GEM objects 'resv' pointer might still change after
drm_gem_private_object_init() is called, e.g. through
ttm_bo_init_reserved(). This can result in the wrong lock being tracked.
To fix this, call dma_resv_held() directly from
drm_gem_gpuva_assert_lock_held() and fall back to the GEMs lock_dep_map
pointer only if an actual custom lock is set.
Fixes: e6303f323b1a ("drm: manager to keep track of GPUs VA mappings")
Reviewed-by: Dave Airlie
Signed-off-by: Danilo Krummrich
---
include/drm/drm_gem.h | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index c0b13c43b459..bc9f6aa2f3fe 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -551,15 +551,17 @@ int drm_gem_evict(struct drm_gem_object *obj);
* @lock: the lock used to protect the gpuva list. The locking primitive
* must contain a dep_map field.
*
- * Call this if you're not proctecting access to the gpuva list
- * with the dma-resv lock, otherwise, drm_gem_gpuva_init() takes care
- * of initializing lock_dep_map for you.
+ * Call this if you're not proctecting access to the gpuva list with the
+ * dma-resv lock, but with a custom lock.
*/
#define drm_gem_gpuva_set_lock(obj, lock) \
- if (!(obj)->gpuva.lock_dep_map) \
+ if (!WARN((obj)->gpuva.lock_dep_map, \
+ "GEM GPUVA lock should be set only once.")) \
(obj)->gpuva.lock_dep_map = &(lock)->dep_map
#define drm_gem_gpuva_assert_lock_held(obj) \
- lockdep_assert(lock_is_held((obj)->gpuva.lock_dep_map))
+ lockdep_assert((obj)->gpuva.lock_dep_map ? \
+ lock_is_held((obj)->gpuva.lock_dep_map) : \
+ dma_resv_held((obj)->resv))
#else
#define drm_gem_gpuva_set_lock(obj, lock) do {} while (0)
#define drm_gem_gpuva_assert_lock_held(obj) do {} while (0)
@@ -573,11 +575,12 @@ int drm_gem_evict(struct drm_gem_object *obj);
*
* Calling this function is only necessary for drivers intending to support the
* _driver_feature DRIVER_GEM_GPUVA.
+ *
+ * See also drm_gem_gpuva_set_lock().
*/
static inline void drm_gem_gpuva_init(struct drm_gem_object *obj)
{
INIT_LIST_HEAD(>gpuva.list);
- drm_gem_gpuva_set_lock(obj, >resv->lock.base);
}
/**
--
2.41.0
[PATCH drm-misc-next v10 00/12] Nouveau VM_BIND UAPI & DRM GPUVA Manager (merged)
This patch series provides a new UAPI for the Nouveau driver in order to support Vulkan features, such as sparse bindings and sparse residency. Furthermore, with the DRM GPUVA manager it provides a new DRM core feature to keep track of GPU virtual address (VA) mappings in a more generic way (merged into drm-misc/drm-misc-next since V8). The DRM GPUVA manager is indented to help drivers implement userspace-manageable GPU VA spaces in reference to the Vulkan API. In order to achieve this goal it serves the following purposes in this context. 1) Provide infrastructure to track GPU VA allocations and mappings, using an interval tree (RB-tree). 2) Generically connect GPU VA mappings to their backing buffers, in particular DRM GEM objects. 3) Provide a common implementation to perform more complex mapping operations on the GPU VA space. In particular splitting and merging of GPU VA mappings, e.g. for intersecting mapping requests or partial unmap requests. The new VM_BIND Nouveau UAPI build on top of the DRM GPUVA manager, itself providing the following new interfaces. 1) Initialize a GPU VA space via the new DRM_IOCTL_NOUVEAU_VM_INIT ioctl for UMDs to specify the portion of VA space managed by the kernel and userspace, respectively. 2) Allocate and free a VA space region as well as bind and unbind memory to the GPUs VA space via the new DRM_IOCTL_NOUVEAU_VM_BIND ioctl. 3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl. Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC, make use of the DRM scheduler to queue jobs and support asynchronous processing with DRM syncobjs as synchronization mechanism. By default DRM_IOCTL_NOUVEAU_VM_BIND does synchronous processing, DRM_IOCTL_NOUVEAU_EXEC supports asynchronous processing only. The new VM_BIND UAPI for Nouveau makes also use of drm_exec (execution context for GEM buffers) by Christian König. Since the patch implementing drm_exec was not yet merged into drm-next it is part of this series, as well as a small fix for this patch, which was found while testing this series. This patch series is also available at [1]. There is a Mesa NVK merge request by Dave Airlie [2] implementing the corresponding userspace parts for this series. The Vulkan CTS test suite passes the sparse binding and sparse residency test cases for the new UAPI together with Dave's Mesa work. There are also some test cases in the igt-gpu-tools project [3] for the new UAPI and hence the DRM GPU VA manager. However, most of them are testing the DRM GPU VA manager's logic through Nouveau's new UAPI and should be considered just as helper for implementation. However, I absolutely intend to change those test cases to proper kunit test cases for the DRM GPUVA manager, once and if we agree on it's usefulness and design. [1] https://gitlab.freedesktop.org/nouvelles/kernel/-/tree/new-uapi-drm-next / https://gitlab.freedesktop.org/nouvelles/kernel/-/merge_requests/1 [2] https://gitlab.freedesktop.org/nouveau/mesa/-/merge_requests/150/ [3] https://gitlab.freedesktop.org/dakr/igt-gpu-tools/-/tree/wip_nouveau_vm_bind Changes in V2: == Nouveau: - Reworked the Nouveau VM_BIND UAPI to avoid memory allocations in fence signalling critical sections. Updates to the VA space are split up in three separate stages, where only the 2. stage executes in a fence signalling critical section: 1. update the VA space, allocate new structures and page tables 2. (un-)map the requested memory bindings 3. free structures and page tables - Separated generic job scheduler code from specific job implementations. - Separated the EXEC and VM_BIND implementation of the UAPI. - Reworked the locking parts of the nvkm/vmm RAW interface, such that (un-)map operations can be executed in fence signalling critical sections. GPUVA Manager: - made drm_gpuva_regions optional for users of the GPUVA manager - allow NULL GEMs for drm_gpuva entries - swichted from drm_mm to maple_tree for track drm_gpuva / drm_gpuva_region entries - provide callbacks for users to allocate custom drm_gpuva_op structures to allow inheritance - added user bits to drm_gpuva_flags - added a prefetch operation type in order to support generating prefetch operations in the same way other operations generated - hand the responsibility for mutual exclusion for a GEM's drm_gpuva list to the user; simplified corresponding (un-)link functions Maple Tree: - I added two maple tree patches to the series, one to support custom tree walk macros and one to hand the locking responsibility to the user of the GPUVA manager without pre-defined lockdep checks. Changes in V3: == Nouveau: - Reworked the Nouveau VM_BIND UAPI to do the job cleanup (including page table cleanup) within a workqueue
[PATCH v2] drm/amd/display: ensure async flips are only accepted for fast updates
We should be checking to see if async flips are supported in
amdgpu_dm_atomic_check() (i.e. not dm_crtc_helper_atomic_check()). Also,
async flipping isn't supported if a plane's framebuffer changes memory
domains during an atomic commit. So, move the check from
dm_crtc_helper_atomic_check() to amdgpu_dm_atomic_check() and check if
the memory domain has changed in amdgpu_dm_atomic_check().
Cc: sta...@vger.kernel.org
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2733
Fixes: 3f86b60691e6 ("drm/amd/display: only accept async flips for fast
updates")
Signed-off-by: Hamza Mahfooz
---
v2: link issue and revert back to the old way of setting update_type.
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 24 ---
.../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 12 --
2 files changed, 21 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 32fb551862b0..1d3afab5bc85 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8086,10 +8086,12 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
* fast updates.
*/
if (crtc->state->async_flip &&
- acrtc_state->update_type != UPDATE_TYPE_FAST)
+ (acrtc_state->update_type != UPDATE_TYPE_FAST ||
+get_mem_type(old_plane_state->fb) != get_mem_type(fb)))
drm_warn_once(state->dev,
"[PLANE:%d:%s] async flip with non-fast
update\n",
plane->base.id, plane->name);
+
bundle->flip_addrs[planes_count].flip_immediate =
crtc->state->async_flip &&
acrtc_state->update_type == UPDATE_TYPE_FAST &&
@@ -10050,6 +10052,11 @@ static int amdgpu_dm_atomic_check(struct drm_device
*dev,
/* Remove exiting planes if they are modified */
for_each_oldnew_plane_in_state_reverse(state, plane, old_plane_state,
new_plane_state, i) {
+ if (old_plane_state->fb && new_plane_state->fb &&
+ get_mem_type(old_plane_state->fb) !=
+ get_mem_type(new_plane_state->fb))
+ lock_and_validation_needed = true;
+
ret = dm_update_plane_state(dc, state, plane,
old_plane_state,
new_plane_state,
@@ -10297,9 +10304,20 @@ static int amdgpu_dm_atomic_check(struct drm_device
*dev,
struct dm_crtc_state *dm_new_crtc_state =
to_dm_crtc_state(new_crtc_state);
+ /*
+* Only allow async flips for fast updates that don't change
+* the FB pitch, the DCC state, rotation, etc.
+*/
+ if (new_crtc_state->async_flip && lock_and_validation_needed) {
+ drm_dbg_atomic(crtc->dev,
+ "[CRTC:%d:%s] async flips are only
supported for fast updates\n",
+ crtc->base.id, crtc->name);
+ ret = -EINVAL;
+ goto fail;
+ }
+
dm_new_crtc_state->update_type = lock_and_validation_needed ?
-UPDATE_TYPE_FULL :
-UPDATE_TYPE_FAST;
+ UPDATE_TYPE_FULL : UPDATE_TYPE_FAST;
}
/* Must be success */
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
index 30d4c6fd95f5..440fc0869a34 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
@@ -398,18 +398,6 @@ static int dm_crtc_helper_atomic_check(struct drm_crtc
*crtc,
return -EINVAL;
}
- /*
-* Only allow async flips for fast updates that don't change the FB
-* pitch, the DCC state, rotation, etc.
-*/
- if (crtc_state->async_flip &&
- dm_crtc_state->update_type != UPDATE_TYPE_FAST) {
- drm_dbg_atomic(crtc->dev,
- "[CRTC:%d:%s] async flips are only supported for
fast updates\n",
- crtc->base.id, crtc->name);
- return -EINVAL;
- }
-
/* In some use cases, like reset, no stream is attached */
if (!dm_crtc_state->stream)
return 0;
--
2.41.0
Re: [PATCH] drm/amd/display: ensure async flips are only accepted for fast updates
On 2023-08-04 11:56, Hamza Mahfooz wrote:
> We should be checking to see if async flips are supported in
> amdgpu_dm_atomic_check() (i.e. not dm_crtc_helper_atomic_check()). Also,
> async flipping isn't supported if a plane's framebuffer changes memory
> domains during an atomic commit. So, move the check from
> dm_crtc_helper_atomic_check() to amdgpu_dm_atomic_check() and check if
> the memory domain has changed in amdgpu_dm_atomic_check().
>
> Cc: sta...@vger.kernel.org
> Fixes: 3f86b60691e6 ("drm/amd/display: only accept async flips for fast
> updates")
> Tested-by: Marcus Seyfarth
> Signed-off-by: Hamza Mahfooz
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 25 ---
> .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 12 -
> 2 files changed, 21 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 32fb551862b0..e561d99b3f40 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -8086,7 +8086,8 @@ static void amdgpu_dm_commit_planes(struct
> drm_atomic_state *state,
>* fast updates.
>*/
> if (crtc->state->async_flip &&
> - acrtc_state->update_type != UPDATE_TYPE_FAST)
> + (acrtc_state->update_type != UPDATE_TYPE_FAST ||
> + get_mem_type(old_plane_state->fb) != get_mem_type(fb)))
> drm_warn_once(state->dev,
> "[PLANE:%d:%s] async flip with non-fast
> update\n",
> plane->base.id, plane->name);
> @@ -10050,12 +10051,18 @@ static int amdgpu_dm_atomic_check(struct drm_device
> *dev,
>
> /* Remove exiting planes if they are modified */
> for_each_oldnew_plane_in_state_reverse(state, plane, old_plane_state,
> new_plane_state, i) {
> + if (old_plane_state->fb && new_plane_state->fb &&
> + get_mem_type(old_plane_state->fb) !=
> + get_mem_type(new_plane_state->fb))
> + lock_and_validation_needed = true;
> +
> ret = dm_update_plane_state(dc, state, plane,
> old_plane_state,
> new_plane_state,
> false,
> _and_validation_needed,
> _top_most_overlay);
> +
nit: extraneous newline
> if (ret) {
> DRM_DEBUG_DRIVER("dm_update_plane_state() failed\n");
> goto fail;
> @@ -10069,6 +10076,7 @@ static int amdgpu_dm_atomic_check(struct drm_device
> *dev,
> new_crtc_state,
> false,
> _and_validation_needed);
> +
nit: extraneous newline
> if (ret) {
> DRM_DEBUG_DRIVER("DISABLE: dm_update_crtc_state()
> failed\n");
> goto fail;
> @@ -10297,9 +10305,18 @@ static int amdgpu_dm_atomic_check(struct drm_device
> *dev,
> struct dm_crtc_state *dm_new_crtc_state =
> to_dm_crtc_state(new_crtc_state);
>
> - dm_new_crtc_state->update_type = lock_and_validation_needed ?
> - UPDATE_TYPE_FULL :
> - UPDATE_TYPE_FAST;
> + /*
> + * Only allow async flips for fast updates that don't change
> + * the FB pitch, the DCC state, rotation, etc.
> + */
> + if (new_crtc_state->async_flip && lock_and_validation_needed) {
> + drm_dbg_atomic(crtc->dev,
> +"[CRTC:%d:%s] async flips are only
> supported for fast updates\n",
> +crtc->base.id, crtc->name);
> + ret = -EINVAL;
> + goto fail;
> + } else
nit: Add braces here as well
> + dm_new_crtc_state->update_type = UPDATE_TYPE_FAST;
If async_flip is false you'll be setting update_type to FAST here
uncoditionally.
You'll still need the lock_and_validation check here, i.e. this:
> dm_new_crtc_state->update_type = lock_and_validation_needed ?
>UPDATE_TYPE_FULL :
>UPDATE_TYPE_FAST;
Harry
> }
>
> /* Must be success */
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
> index 30d4c6fd95f5..440fc0869a34 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
> +++
Re: [PATCH v3 3/9] PM / QoS: Fix constraints alloc vs reclaim locking
On Fri, Aug 4, 2023 at 12:02 AM Rob Clark wrote:
>
> From: Rob Clark
>
> In the process of adding lockdep annotation for drm GPU scheduler's
> job_run() to detect potential deadlock against shrinker/reclaim, I hit
> this lockdep splat:
>
>==
>WARNING: possible circular locking dependency detected
>6.2.0-rc8-debug+ #558 Tainted: GW
>--
>ring0/125 is trying to acquire lock:
>ffd6d6ce0f28 (dev_pm_qos_mtx){+.+.}-{3:3}, at:
> dev_pm_qos_update_request+0x38/0x68
>
>but task is already holding lock:
>ff8087239208 (>active_lock){+.+.}-{3:3}, at:
> msm_gpu_submit+0xec/0x178
>
>which lock already depends on the new lock.
>
>the existing dependency chain (in reverse order) is:
>
>-> #4 (>active_lock){+.+.}-{3:3}:
> __mutex_lock+0xcc/0x3c8
> mutex_lock_nested+0x30/0x44
> msm_gpu_submit+0xec/0x178
> msm_job_run+0x78/0x150
> drm_sched_main+0x290/0x370
> kthread+0xf0/0x100
> ret_from_fork+0x10/0x20
>
>-> #3 (dma_fence_map){}-{0:0}:
> __dma_fence_might_wait+0x74/0xc0
> dma_resv_lockdep+0x1f4/0x2f4
> do_one_initcall+0x104/0x2bc
> kernel_init_freeable+0x344/0x34c
> kernel_init+0x30/0x134
> ret_from_fork+0x10/0x20
>
>-> #2 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}:
> fs_reclaim_acquire+0x80/0xa8
> slab_pre_alloc_hook.constprop.0+0x40/0x25c
> __kmem_cache_alloc_node+0x60/0x1cc
> __kmalloc+0xd8/0x100
> topology_parse_cpu_capacity+0x8c/0x178
> get_cpu_for_node+0x88/0xc4
> parse_cluster+0x1b0/0x28c
> parse_cluster+0x8c/0x28c
> init_cpu_topology+0x168/0x188
> smp_prepare_cpus+0x24/0xf8
> kernel_init_freeable+0x18c/0x34c
> kernel_init+0x30/0x134
> ret_from_fork+0x10/0x20
>
>-> #1 (fs_reclaim){+.+.}-{0:0}:
> __fs_reclaim_acquire+0x3c/0x48
> fs_reclaim_acquire+0x54/0xa8
> slab_pre_alloc_hook.constprop.0+0x40/0x25c
> __kmem_cache_alloc_node+0x60/0x1cc
> kmalloc_trace+0x50/0xa8
> dev_pm_qos_constraints_allocate+0x38/0x100
> __dev_pm_qos_add_request+0xb0/0x1e8
> dev_pm_qos_add_request+0x58/0x80
> dev_pm_qos_expose_latency_limit+0x60/0x13c
> register_cpu+0x12c/0x130
> topology_init+0xac/0xbc
> do_one_initcall+0x104/0x2bc
> kernel_init_freeable+0x344/0x34c
> kernel_init+0x30/0x134
> ret_from_fork+0x10/0x20
>
>-> #0 (dev_pm_qos_mtx){+.+.}-{3:3}:
> __lock_acquire+0xe00/0x1060
> lock_acquire+0x1e0/0x2f8
> __mutex_lock+0xcc/0x3c8
> mutex_lock_nested+0x30/0x44
> dev_pm_qos_update_request+0x38/0x68
> msm_devfreq_boost+0x40/0x70
> msm_devfreq_active+0xc0/0xf0
> msm_gpu_submit+0x10c/0x178
> msm_job_run+0x78/0x150
> drm_sched_main+0x290/0x370
> kthread+0xf0/0x100
> ret_from_fork+0x10/0x20
>
>other info that might help us debug this:
>
>Chain exists of:
> dev_pm_qos_mtx --> dma_fence_map --> >active_lock
>
> Possible unsafe locking scenario:
>
> CPU0CPU1
>
> lock(>active_lock);
> lock(dma_fence_map);
> lock(>active_lock);
> lock(dev_pm_qos_mtx);
>
> *** DEADLOCK ***
>
>3 locks held by ring0/123:
> #0: ff8087251170 (>lock){+.+.}-{3:3}, at: msm_job_run+0x64/0x150
> #1: ffd00b0e57e8 (dma_fence_map){}-{0:0}, at:
> msm_job_run+0x68/0x150
> #2: ff8087251208 (>active_lock){+.+.}-{3:3}, at:
> msm_gpu_submit+0xec/0x178
>
>stack backtrace:
>CPU: 6 PID: 123 Comm: ring0 Not tainted 6.2.0-rc8-debug+ #559
>Hardware name: Google Lazor (rev1 - 2) with LTE (DT)
>Call trace:
> dump_backtrace.part.0+0xb4/0xf8
> show_stack+0x20/0x38
> dump_stack_lvl+0x9c/0xd0
> dump_stack+0x18/0x34
> print_circular_bug+0x1b4/0x1f0
> check_noncircular+0x78/0xac
> __lock_acquire+0xe00/0x1060
> lock_acquire+0x1e0/0x2f8
> __mutex_lock+0xcc/0x3c8
> mutex_lock_nested+0x30/0x44
> dev_pm_qos_update_request+0x38/0x68
> msm_devfreq_boost+0x40/0x70
> msm_devfreq_active+0xc0/0xf0
> msm_gpu_submit+0x10c/0x178
> msm_job_run+0x78/0x150
> drm_sched_main+0x290/0x370
> kthread+0xf0/0x100
> ret_from_fork+0x10/0x20
>
> The issue is that dev_pm_qos_mtx is held in the runpm suspend/resume (or
> freq change) path, but it is also held across allocations that could
> recurse into shrinker.
>
> Solve this by changing dev_pm_qos_constraints_allocate() into a function
> that can be called unconditionally before
Re: [PATCH] drm/msm/a6xx: Fix GMU lockdep splat
Hi,
On Thu, Aug 3, 2023 at 10:34 AM Rob Clark wrote:
>
> From: Rob Clark
>
> For normal GPU devfreq, we need to acquire the GMU lock while already
> holding devfreq locks. But in the teardown path, we were calling
> dev_pm_domain_detach() while already holding the GMU lock, resulting in
> this lockdep splat:
>
>==
>WARNING: possible circular locking dependency detected
>6.4.3-debug+ #3 Not tainted
>--
>ring0/391 is trying to acquire lock:
>ff80a025c078 (>lock){+.+.}-{3:3}, at:
> qos_notifier_call+0x30/0x74
>
>but task is already holding lock:
>ff809b8c1ce8 (&(c->notifiers)->rwsem){}-{3:3}, at:
> blocking_notifier_call_chain+0x34/0x78
>
>which lock already depends on the new lock.
>
>the existing dependency chain (in reverse order) is:
>
>-> #4 (&(c->notifiers)->rwsem){}-{3:3}:
> down_write+0x58/0x74
> __blocking_notifier_chain_register+0x64/0x84
> blocking_notifier_chain_register+0x1c/0x28
> freq_qos_add_notifier+0x5c/0x7c
> dev_pm_qos_add_notifier+0xd4/0xf0
> devfreq_add_device+0x42c/0x560
> devm_devfreq_add_device+0x6c/0xb8
> msm_devfreq_init+0xa8/0x16c [msm]
> msm_gpu_init+0x368/0x54c [msm]
> adreno_gpu_init+0x248/0x2b0 [msm]
> a6xx_gpu_init+0x2d0/0x384 [msm]
> adreno_bind+0x264/0x2bc [msm]
> component_bind_all+0x124/0x1f4
> msm_drm_bind+0x2d0/0x5f4 [msm]
> try_to_bring_up_aggregate_device+0x88/0x1a4
> __component_add+0xd4/0x128
> component_add+0x1c/0x28
> dp_display_probe+0x37c/0x3c0 [msm]
> platform_probe+0x70/0xc0
> really_probe+0x148/0x280
> __driver_probe_device+0xfc/0x114
> driver_probe_device+0x44/0x100
> __device_attach_driver+0x64/0xdc
> bus_for_each_drv+0xb0/0xd8
> __device_attach+0xe4/0x140
> device_initial_probe+0x1c/0x28
> bus_probe_device+0x44/0xb0
> deferred_probe_work_func+0xb0/0xc8
> process_one_work+0x288/0x3d8
> worker_thread+0x1f0/0x260
> kthread+0xf0/0x100
> ret_from_fork+0x10/0x20
>
>-> #3 (dev_pm_qos_mtx){+.+.}-{3:3}:
> __mutex_lock+0xc8/0x388
> mutex_lock_nested+0x2c/0x38
> dev_pm_qos_remove_notifier+0x3c/0xc8
> genpd_remove_device+0x40/0x11c
> genpd_dev_pm_detach+0x88/0x130
> dev_pm_domain_detach+0x2c/0x3c
> a6xx_gmu_remove+0x44/0xdc [msm]
> a6xx_destroy+0x7c/0xa4 [msm]
> adreno_unbind+0x50/0x64 [msm]
> component_unbind+0x44/0x64
> component_unbind_all+0xb4/0xbc
> msm_drm_uninit.isra.0+0x124/0x17c [msm]
> msm_drm_bind+0x340/0x5f4 [msm]
> try_to_bring_up_aggregate_device+0x88/0x1a4
> __component_add+0xd4/0x128
> component_add+0x1c/0x28
> dp_display_probe+0x37c/0x3c0 [msm]
> platform_probe+0x70/0xc0
> really_probe+0x148/0x280
> __driver_probe_device+0xfc/0x114
> driver_probe_device+0x44/0x100
> __device_attach_driver+0x64/0xdc
> bus_for_each_drv+0xb0/0xd8
> __device_attach+0xe4/0x140
> device_initial_probe+0x1c/0x28
> bus_probe_device+0x44/0xb0
> deferred_probe_work_func+0xb0/0xc8
> process_one_work+0x288/0x3d8
> worker_thread+0x1f0/0x260
> kthread+0xf0/0x100
> ret_from_fork+0x10/0x20
>
>-> #2 (_gpu->gmu.lock){+.+.}-{3:3}:
> __mutex_lock+0xc8/0x388
> mutex_lock_nested+0x2c/0x38
> a6xx_gpu_set_freq+0x38/0x64 [msm]
> msm_devfreq_target+0x170/0x18c [msm]
> devfreq_set_target+0x90/0x1e4
> devfreq_update_target+0xb4/0xf0
> update_devfreq+0x1c/0x28
> devfreq_monitor+0x3c/0x10c
> process_one_work+0x288/0x3d8
> worker_thread+0x1f0/0x260
> kthread+0xf0/0x100
> ret_from_fork+0x10/0x20
>
>-> #1 (>lock){+.+.}-{3:3}:
> __mutex_lock+0xc8/0x388
> mutex_lock_nested+0x2c/0x38
> msm_devfreq_get_dev_status+0x4c/0x104 [msm]
> devfreq_simple_ondemand_func+0x5c/0x128
> devfreq_update_target+0x68/0xf0
> update_devfreq+0x1c/0x28
> devfreq_monitor+0x3c/0x10c
> process_one_work+0x288/0x3d8
> worker_thread+0x1f0/0x260
> kthread+0xf0/0x100
> ret_from_fork+0x10/0x20
>
>-> #0 (>lock){+.+.}-{3:3}:
> __lock_acquire+0xdf8/0x109c
> lock_acquire+0x234/0x284
> __mutex_lock+0xc8/0x388
> mutex_lock_nested+0x2c/0x38
> qos_notifier_call+0x30/0x74
> qos_min_notifier_call+0x1c/0x28
> notifier_call_chain+0xf4/0x114
>
Re: [PATCH] drm: Drop select FRAMEBUFFER_CONSOLE for DRM_FBDEV_EMULATION
Arthur Grillo writes:
> On 04/08/23 09:51, Javier Martinez Canillas wrote:
>> The commit c242f48433e7 ("drm: Make FB_CORE to be selected if DRM fbdev
>> emulation is enabled") changed DRM_FBDEV_EMULATION from 'depends on FB'
>> to an effective 'select FB_CORE', so any config that previously had DRM=y
>> and FB=n now has FB_CORE=y and FRAMEBUFFER_CONSOLE=y.
>>
>> This leads to unmet direct dependencies detected for FRAMEBUFFER_CONSOLE
>> as reported by Arthur Grillo, e.g:
>>
>> WARNING: unmet direct dependencies detected for FRAMEBUFFER_CONSOLE
>> Depends on [n]: VT [=n] && FB_CORE [=y] && !UML [=y]
>> Selected by [y]:
>> - DRM_FBDEV_EMULATION [=y] && HAS_IOMEM [=y] && DRM [=y] && !EXPERT [=n]
>>
>> Arnd Bergmann suggests to drop the select FRAMEBUFFER_CONSOLE for the
>> DRM_FBDEV_EMULATION Kconfig symbol, since a possible use case could
>> be to enable DRM fbdev emulation but without a framebuffer console.
>>
>> Fixes: c242f48433e7 ("drm: Make FB_CORE to be selected if DRM fbdev
>> emulation is enabled")
>> Reported-by: Arthur Grillo
>> Closes:
>> https://lore.kernel.org/dri-devel/20230726220325.278976-1-arthurgri...@riseup.net
>> Suggested-by: Arnd Bergmann
>> Signed-off-by: Javier Martinez Canillas
>> ---
>
> Greate patch! I was about to send the same one XD.
>
> Reviewed-by: Arthur Grillo
>
Pushed to drm-misc (drm-misc-next). Thanks!
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
[PATCH 1/2] dt-bindings: display: newvision, nv3051d: Add Anbernic 351V Support
From: Chris Morgan Document the Anbernic RG351V panel, which appears to be identical to the panel used in their 353 series except for in inclusion of an additional DSI format flag. Signed-off-by: Chris Morgan --- .../display/panel/newvision,nv3051d.yaml | 18 +++--- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml b/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml index 116c1b6030a2..1226db3613e6 100644 --- a/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml +++ b/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml @@ -8,8 +8,8 @@ title: NewVision NV3051D based LCD panel description: | The NewVision NV3051D is a driver chip used to drive DSI panels. For now, - this driver only supports the 640x480 panels found in the Anbernic RG353 - based devices. + this driver only supports the 640x480 panels found in the Anbernic RG351 + and 353 based devices. maintainers: - Chris Morgan @@ -19,11 +19,15 @@ allOf: properties: compatible: -items: - - enum: - - anbernic,rg353p-panel - - anbernic,rg353v-panel - - const: newvision,nv3051d +oneOf: + - items: + - enum: + - anbernic,rg353p-panel + - anbernic,rg353v-panel + - const: newvision,nv3051d + + - items: + - const: anbernic,rg351v-panel reg: true backlight: true -- 2.34.1
[PATCH 2/2] drm/panel: nv3051d: Add Support for Anbernic 351V
From: Chris Morgan
Add support for the Anbernic 351V. Just like the 353 series the
underlying vendor is unknown/unmarked (at least not visible in a
non-destructive manner). The panel had slightly different init
sequences and timings in the BSP kernel, but works fine with the
same ones used in the existing driver. The panel will not work without
the inclusion of the MIPI_DSI_CLOCK_NON_CONTINUOUS flag, and this flag
prevents the 353 series from working correctly, so a new compatible
string is added.
Tested colors and timings using modetest and all seem to work identical
to the 353 otherwise.
Signed-off-by: Chris Morgan
---
.../gpu/drm/panel/panel-newvision-nv3051d.c| 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
b/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
index a07958038ffd..dc0d6dcca683 100644
--- a/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
+++ b/drivers/gpu/drm/panel/panel-newvision-nv3051d.c
@@ -28,6 +28,7 @@ struct nv3051d_panel_info {
unsigned int num_modes;
u16 width_mm, height_mm;
u32 bus_flags;
+ unsigned long mode_flags;
};
struct panel_nv3051d {
@@ -385,8 +386,7 @@ static int panel_nv3051d_probe(struct mipi_dsi_device *dsi)
dsi->lanes = 4;
dsi->format = MIPI_DSI_FMT_RGB888;
- dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
- MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET;
+ dsi->mode_flags = ctx->panel_info->mode_flags;
drm_panel_init(>panel, >dev, _nv3051d_funcs,
DRM_MODE_CONNECTOR_DSI);
@@ -480,10 +480,24 @@ static const struct nv3051d_panel_info nv3051d_rgxx3_info
= {
.width_mm = 70,
.height_mm = 57,
.bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET,
+};
+
+static const struct nv3051d_panel_info nv3051d_rg351v_info = {
+ .display_modes = nv3051d_rgxx3_modes,
+ .num_modes = ARRAY_SIZE(nv3051d_rgxx3_modes),
+ .width_mm = 70,
+ .height_mm = 57,
+ .bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_NO_EOT_PACKET |
+ MIPI_DSI_CLOCK_NON_CONTINUOUS,
};
static const struct of_device_id newvision_nv3051d_of_match[] = {
{ .compatible = "newvision,nv3051d", .data = _rgxx3_info },
+ { .compatible = "anbernic,rg351v-panel", .data = _rg351v_info },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, newvision_nv3051d_of_match);
--
2.34.1
[PATCH 0/2] Support Anbernic RG351V Panel
From: Chris Morgan Add support for the Anbernic RG351V panel. This panel is mostly identical to the one used in the 353 series, except it has a different panel ID when queried (0x4000 for the 351V, 0x3052 for the 353 panel) and will not work without the inclusion of the MIPI_DSI_CLOCK_NON_CONTINUOUS flag. Chris Morgan (2): dt-bindings: display: newvision,nv3051d: Add Anbernic 351V Support drm/panel: nv3051d: Add Support for Anbernic 351V .../display/panel/newvision,nv3051d.yaml | 18 +++--- .../gpu/drm/panel/panel-newvision-nv3051d.c| 18 -- 2 files changed, 27 insertions(+), 9 deletions(-) -- 2.34.1
Re: [PATCH] PCI/VGA: Make the vga_is_firmware_default() arch-independent
On Fri, Aug 04, 2023 at 11:11:12AM +0800, suijingfeng wrote: > On 2023/8/3 20:25, kernel test robot wrote: > > Hi Sui, > > > > kernel test robot noticed the following build errors: > > > > [auto build test ERROR on pci/next] > > [also build test ERROR on pci/for-linus linus/master v6.5-rc4 next-20230803] > > [If your patch is applied to the wrong git tree, kindly drop us a note. > > And when submitting patch, we suggest to use '--base' as documented in > > https://git-scm.com/docs/git-format-patch#_base_tree_information] > > > > url: > > https://github.com/intel-lab-lkp/linux/commits/Sui-Jingfeng/PCI-VGA-Make-the-vga_is_firmware_default-arch-independent/20230803-161838 > > base: https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git next > > patch link: > > https://lore.kernel.org/r/20230803081758.968742-1-suijingfeng%40loongson.cn > > patch subject: [PATCH] PCI/VGA: Make the vga_is_firmware_default() > > arch-independent > > config: arm64-randconfig-r026-20230731 > > (https://download.01.org/0day-ci/archive/20230803/202308032022.yizngbbk-...@intel.com/config) > > compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.git > > 4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a) > > reproduce: > > (https://download.01.org/0day-ci/archive/20230803/202308032022.yizngbbk-...@intel.com/reproduce) > > > > If you fix the issue in a separate patch/commit (i.e. not just a new > > version of > > the same patch/commit), kindly add following tags > > | Reported-by: kernel test robot > > | Closes: > > https://lore.kernel.org/oe-kbuild-all/202308032022.yizngbbk-...@intel.com/ > > > > All errors (new ones prefixed by >>): > > > > > > ld.lld: error: undefined symbol: screen_info > > >>> referenced by vgaarb.c:86 (drivers/pci/vgaarb.c:86) > > >>> > > drivers/pci/vgaarb.o:(vga_arb_firmware_fb_addr_tracker) in archive vmlinux.a > > >>> referenced by vgaarb.c:86 (drivers/pci/vgaarb.c:86) > > >>> > > drivers/pci/vgaarb.o:(vga_arb_firmware_fb_addr_tracker) in archive vmlinux.a > > >>> referenced by vgaarb.c:88 (drivers/pci/vgaarb.c:88) > > >>> > > drivers/pci/vgaarb.o:(vga_arb_firmware_fb_addr_tracker) in archive vmlinux.a > > >>> referenced 3 more times > > > This is a more like arch-specific problem, It will be pain at many places on > platforms > that do not export the screen_info symbol. Not only here. > > I have already explained that screen_info is arch-dependent many times, but > no one cares about me. > By using (looking at) screen_info, vgaarb gets infected, and becomes > arch-dependent as well. > vgaarb deals with VGA class (pdev->class == 0x0300XX) devices only, This > makes it device-dependent. > Hence, It only works correctly for a small set of PCIe devices on x86. This build error report is from an automated service; there's nothing personal about it and the automated service isn't going to respond to you. The build issue is just something that will have to be resolved before we can consider merging the patch. Any explanation needs to go in the commit logs for the relevant patches. > arch-dependent, device-dependent, subsystem-dependent (part of it rely on > ACPI) and > loading order dependent, those dependent itself are the problems. > It results in various undefined (uncertain) behaviors on non-x86 > architectures. > > Even on x86, some platform choose to relay on the firmware to solve the > multiple GPU coexist problem. > so it is also firmware-dependent. > > This patch solves part of the above problems listed, target at the *device > level*, as early as possible. > while they still a few problems could be only solved at the *driver level*. > For an example, The display controller in Intel N2000 and d2000 series don't > has a dedicated VRAM bar. > they use the "stolen memory", which is carve out by somebody (either bios or > kernel?). > >
Re: [PATCH] drm/amdkfd: fix build failure without CONFIG_DYNAMIC_DEBUG
On 2023-08-04 9:29, Arnd Bergmann wrote:
From: Arnd Bergmann
When CONFIG_DYNAMIC_DEBUG is disabled altogether, calling
_dynamic_func_call_no_desc() does not work:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c: In function
'svm_range_set_attr':
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:52:9: error: implicit
declaration of function '_dynamic_func_call_no_desc'
[-Werror=implicit-function-declaration]
52 | _dynamic_func_call_no_desc("svm_range_dump",
svm_range_debug_dump, svms)
| ^~
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:3564:9: note: in expansion of
macro 'dynamic_svm_range_dump'
3564 | dynamic_svm_range_dump(svms);
| ^~
Add a compile-time conditional in addition to the runtime check.
Fixes: 8923137dbe4b2 ("drm/amdkfd: avoid svm dump when dynamic debug disabled")
Signed-off-by: Arnd Bergmann
The patch is
Reviewed-by: Felix Kuehling
I'm applying it to amd-staging-drm-next.
Thanks,
Felix
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
index 308384dbc502d..44e710821b6d9 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
@@ -23,6 +23,7 @@
#include
#include
+#include
#include
#include
@@ -48,8 +49,13 @@
* page table is updated.
*/
#define AMDGPU_SVM_RANGE_RETRY_FAULT_PENDING (2UL * NSEC_PER_MSEC)
+#if IS_ENABLED(CONFIG_DYNAMIC_DEBUG)
#define dynamic_svm_range_dump(svms) \
_dynamic_func_call_no_desc("svm_range_dump", svm_range_debug_dump, svms)
+#else
+#define dynamic_svm_range_dump(svms) \
+ do { if (0) svm_range_debug_dump(svms); } while (0)
+#endif
/* Giant svm range split into smaller ranges based on this, it is decided using
* minimum of all dGPU/APU 1/32 VRAM size, between 2MB to 1GB and alignment to
Re: [PATCH] drm: Drop select FRAMEBUFFER_CONSOLE for DRM_FBDEV_EMULATION
On 04/08/23 09:51, Javier Martinez Canillas wrote:
> The commit c242f48433e7 ("drm: Make FB_CORE to be selected if DRM fbdev
> emulation is enabled") changed DRM_FBDEV_EMULATION from 'depends on FB'
> to an effective 'select FB_CORE', so any config that previously had DRM=y
> and FB=n now has FB_CORE=y and FRAMEBUFFER_CONSOLE=y.
>
> This leads to unmet direct dependencies detected for FRAMEBUFFER_CONSOLE
> as reported by Arthur Grillo, e.g:
>
> WARNING: unmet direct dependencies detected for FRAMEBUFFER_CONSOLE
> Depends on [n]: VT [=n] && FB_CORE [=y] && !UML [=y]
> Selected by [y]:
> - DRM_FBDEV_EMULATION [=y] && HAS_IOMEM [=y] && DRM [=y] && !EXPERT [=n]
>
> Arnd Bergmann suggests to drop the select FRAMEBUFFER_CONSOLE for the
> DRM_FBDEV_EMULATION Kconfig symbol, since a possible use case could
> be to enable DRM fbdev emulation but without a framebuffer console.
>
> Fixes: c242f48433e7 ("drm: Make FB_CORE to be selected if DRM fbdev emulation
> is enabled")
> Reported-by: Arthur Grillo
> Closes:
> https://lore.kernel.org/dri-devel/20230726220325.278976-1-arthurgri...@riseup.net
> Suggested-by: Arnd Bergmann
> Signed-off-by: Javier Martinez Canillas
> ---
Greate patch! I was about to send the same one XD.
Reviewed-by: Arthur Grillo
Best Regards,
~Arthur Grillo
>
> drivers/gpu/drm/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index b51c6a141dfa..2a44b9419d4d 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -135,7 +135,6 @@ config DRM_DEBUG_MODESET_LOCK
> config DRM_FBDEV_EMULATION
> bool "Enable legacy fbdev support for your modesetting driver"
> depends on DRM
> - select FRAMEBUFFER_CONSOLE if !EXPERT
> select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
> default y
> help
[PATCH] drm/amd/display: ensure async flips are only accepted for fast updates
We should be checking to see if async flips are supported in
amdgpu_dm_atomic_check() (i.e. not dm_crtc_helper_atomic_check()). Also,
async flipping isn't supported if a plane's framebuffer changes memory
domains during an atomic commit. So, move the check from
dm_crtc_helper_atomic_check() to amdgpu_dm_atomic_check() and check if
the memory domain has changed in amdgpu_dm_atomic_check().
Cc: sta...@vger.kernel.org
Fixes: 3f86b60691e6 ("drm/amd/display: only accept async flips for fast
updates")
Tested-by: Marcus Seyfarth
Signed-off-by: Hamza Mahfooz
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 25 ---
.../amd/display/amdgpu_dm/amdgpu_dm_crtc.c| 12 -
2 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 32fb551862b0..e561d99b3f40 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8086,7 +8086,8 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
* fast updates.
*/
if (crtc->state->async_flip &&
- acrtc_state->update_type != UPDATE_TYPE_FAST)
+ (acrtc_state->update_type != UPDATE_TYPE_FAST ||
+get_mem_type(old_plane_state->fb) != get_mem_type(fb)))
drm_warn_once(state->dev,
"[PLANE:%d:%s] async flip with non-fast
update\n",
plane->base.id, plane->name);
@@ -10050,12 +10051,18 @@ static int amdgpu_dm_atomic_check(struct drm_device
*dev,
/* Remove exiting planes if they are modified */
for_each_oldnew_plane_in_state_reverse(state, plane, old_plane_state,
new_plane_state, i) {
+ if (old_plane_state->fb && new_plane_state->fb &&
+ get_mem_type(old_plane_state->fb) !=
+ get_mem_type(new_plane_state->fb))
+ lock_and_validation_needed = true;
+
ret = dm_update_plane_state(dc, state, plane,
old_plane_state,
new_plane_state,
false,
_and_validation_needed,
_top_most_overlay);
+
if (ret) {
DRM_DEBUG_DRIVER("dm_update_plane_state() failed\n");
goto fail;
@@ -10069,6 +10076,7 @@ static int amdgpu_dm_atomic_check(struct drm_device
*dev,
new_crtc_state,
false,
_and_validation_needed);
+
if (ret) {
DRM_DEBUG_DRIVER("DISABLE: dm_update_crtc_state()
failed\n");
goto fail;
@@ -10297,9 +10305,18 @@ static int amdgpu_dm_atomic_check(struct drm_device
*dev,
struct dm_crtc_state *dm_new_crtc_state =
to_dm_crtc_state(new_crtc_state);
- dm_new_crtc_state->update_type = lock_and_validation_needed ?
-UPDATE_TYPE_FULL :
-UPDATE_TYPE_FAST;
+ /*
+* Only allow async flips for fast updates that don't change
+* the FB pitch, the DCC state, rotation, etc.
+*/
+ if (new_crtc_state->async_flip && lock_and_validation_needed) {
+ drm_dbg_atomic(crtc->dev,
+ "[CRTC:%d:%s] async flips are only
supported for fast updates\n",
+ crtc->base.id, crtc->name);
+ ret = -EINVAL;
+ goto fail;
+ } else
+ dm_new_crtc_state->update_type = UPDATE_TYPE_FAST;
}
/* Must be success */
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
index 30d4c6fd95f5..440fc0869a34 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
@@ -398,18 +398,6 @@ static int dm_crtc_helper_atomic_check(struct drm_crtc
*crtc,
return -EINVAL;
}
- /*
-* Only allow async flips for fast updates that don't change the FB
-* pitch, the DCC state, rotation, etc.
-*/
- if (crtc_state->async_flip &&
- dm_crtc_state->update_type != UPDATE_TYPE_FAST) {
- drm_dbg_atomic(crtc->dev,
- "[CRTC:%d:%s] async flips are only supported for
fast updates\n",
-
Re: [PATCH 1/2] drm: rcar-du: Add more formats to DRM_MODE_BLEND_PIXEL_NONE support
Hi Damian,
(CC'ing Tomi)
On Fri, Aug 04, 2023 at 11:49:32AM -0400, Damian Hobson-Garcia wrote:
> On 2023/08/03 20:06, Laurent Pinchart wrote:
> > On Fri, Aug 04, 2023 at 02:53:17AM +0300, Laurent Pinchart wrote:
> >> On Fri, Aug 04, 2023 at 02:47:04AM +0300, Laurent Pinchart wrote:
> >>> Hi Damian,
> >>>
> >>> Thank you for the patch.
> >>>
> >>> On Fri, Jul 28, 2023 at 04:07:13PM -0400, Damian Hobson-Garcia wrote:
> Add additional pixel formats for which blending is disabling when
> >>> Did you mean "disabled" instead of "disabling" ?
>
> Oops. Yes, that's exactly what I meant.
>
> >>>
> DRM_MODE_BLEND_PIXEL_NONE is set.
>
> Refactor the fourcc selection into a separate function to handle the
> increased number of formats.
>
> Signed-off-by: Damian Hobson-Garcia
> ---
> drivers/gpu/drm/renesas/rcar-du/rcar_du_vsp.c | 49 ---
> 1 file changed, 32 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_vsp.c
> b/drivers/gpu/drm/renesas/rcar-du/rcar_du_vsp.c
> index 45c05d0ffc70..96241c03b60f 100644
> --- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_vsp.c
> @@ -176,6 +176,37 @@ static const u32 rcar_du_vsp_formats_gen4[] = {
> DRM_FORMAT_Y212,
> };
>
> +static u32 rcar_du_vsp_state_get_format(struct rcar_du_vsp_plane_state
> *state)
> +{
> +u32 fourcc = state->format->fourcc;
> +
> +if (state->state.pixel_blend_mode == DRM_MODE_BLEND_PIXEL_NONE)
> {
> +switch (fourcc) {
> +case DRM_FORMAT_ARGB1555:
> +fourcc = DRM_FORMAT_XRGB1555;
> +break;
> +
> +case DRM_FORMAT_ARGB:
> +fourcc = DRM_FORMAT_XRGB;
> +break;
> +
> +case DRM_FORMAT_ARGB:
> +fourcc = DRM_FORMAT_XRGB;
> +break;
> +
> +case DRM_FORMAT_BGRA:
> +fourcc = DRM_FORMAT_BGRX;
> +break;
> +
> +case DRM_FORMAT_RGBA1010102:
> +fourcc = DRM_FORMAT_RGBX1010102;
> +break;
> >>> Should DRM_FORMAT_ARGB2101010 be added as well, or did you leave it out
> >>> intentionally ?
>
> Yes, it was intentionally left out for the time being for the
> reason that you noted (i.e. DRM_FORMAT_XRGB2101010 not
> being handled by the DU driver).
>
> >> It looks like DRM_FORMAT_ARGB2101010 will require a bit more work, as
> >> DRM_FORMAT_XRGB2101010 is not handled by the DU driver at the moment.
> >> Let's do so with a patch on top of this series.
> Yes, I was thinking the same thing.
> > Replying to myself again, the datasheet doesn't explicitly list
> > DRM_FORMAT_XRGB2101010 as supported, but the generic mechanism to
> > specify the location of the components should work fine for that format.
> > Is this something you would be able to test ?
>
> Unfortunately I don't have a Gen 4 system on hand to test the 2-10-10-10
> formats with.
> I will double-check with the office in Japan, but I don't think that
> they have one either.
Tomi, is this something you could test ?
> >> There's no need to send
> >> a v2, I can handle the simple change in the commit message if you let me
> >> know whether my comment is right or wrong.
--
Regards,
Laurent Pinchart
RE: [PATCH v4 1/1] drm/i915: Move abs_diff() to math.h
From: Andrew Morton
> Sent: 03 August 2023 18:25
>
> On Thu, 3 Aug 2023 16:19:18 +0300 Andy Shevchenko
> wrote:
>
> > abs_diff() belongs to math.h. Move it there.
> > This will allow others to use it.
> >
> > ...
> >
> > --- a/include/linux/math.h
> > +++ b/include/linux/math.h
> > @@ -155,6 +155,13 @@ __STRUCT_FRACT(u32)
> > __builtin_types_compatible_p(typeof(x), unsigned type), \
> > ({ signed type __x = (x); __x < 0 ? -__x : __x; }), other)
> >
> > +#define abs_diff(a, b) ({ \
> > + typeof(a) __a = (a);\
> > + typeof(b) __b = (b);\
> > + (void)(&__a == &__b); \
> > + __a > __b ? (__a - __b) : (__b - __a); \
> > +})
>
> Can we document it please?
>
> Also, the open-coded type comparison could be replaced with __typecheck()?
>
> And why the heck isn't __typecheck() in typecheck.h, to be included by
> minmax.h.
And why would you want to use __typecheck() anyway?
It pretty much isn't the test you are looking for.
If you are trying to explicitly avoid converting negative value
to large positive unsigned ones then you want something like:
is_signed_type(typeof(a)) == is_signed_type(typeof(b))
but it isn't even that simple :-)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
Re: [PATCH v2] drm/msm/dpu: Drop encoder vsync_event
On Wed, 02 Aug 2023 10:01:13 -0700, Jessica Zhang wrote: > Drop vsync_event and vsync_event_work handlers as they are unnecessary. > In addition drop the dpu_enc_ktime_template event class as it will be > unused after the vsync_event handlers are dropped. > > Applied, thanks! [1/1] drm/msm/dpu: Drop encoder vsync_event https://gitlab.freedesktop.org/lumag/msm/-/commit/fdcb8fe0c9f0 Best regards, -- Dmitry Baryshkov
Re: [PATCH] drm/msm/dpu: clean up some inconsistent indenting
On Fri, 04 Aug 2023 15:57:46 +0800, Jiapeng Chong wrote: > No functional modification involved. > > drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c:183 dpu_core_perf_crtc_check() > warn: inconsistent indenting. > > Applied, thanks! [1/1] drm/msm/dpu: clean up some inconsistent indenting https://gitlab.freedesktop.org/lumag/msm/-/commit/b0fe70105056 Best regards, -- Dmitry Baryshkov
Re: [PATCH v5 0/8] drm/msm/dpu: change interrupts code to make 0 be the no IRQ
On Wed, 02 Aug 2023 13:04:18 +0300, Dmitry Baryshkov wrote: > Having an explicit init of interrupt fields to -1 for not existing IRQs > makes it easier to forget and/or miss such initialisation, resulting in > a wrong interrupt definition. > > Instead shift all IRQ indices to turn '0' to be the non-existing IRQ. > > Dependencies: [1] > > [...] Applied, thanks! [1/8] drm/msm/dpu: fix the irq index in dpu_encoder_phys_wb_wait_for_commit_done https://gitlab.freedesktop.org/lumag/msm/-/commit/d93cf453f51d Best regards, -- Dmitry Baryshkov
Re: [PATCH] drm/msm/dpu: initialise clk_rate to 0 in _dpu_core_perf_get_core_clk_rate
On Fri, 04 Aug 2023 12:48:04 +0300, Dmitry Baryshkov wrote: > When removing the core perf tune overrides, I also occasionaly removed the > initialisation of the clk_rate variable. Initialise it to 0 to let max() > correctly calculate the maximum of requested clock rates. > > Applied, thanks! [1/1] drm/msm/dpu: initialise clk_rate to 0 in _dpu_core_perf_get_core_clk_rate https://gitlab.freedesktop.org/lumag/msm/-/commit/34202be95237 Best regards, -- Dmitry Baryshkov
Re: [PATCH] drm/msm/mdp5: Don't leak some plane state
On Thu, 03 Aug 2023 22:45:21 +0200, Daniel Vetter wrote:
> Apparently no one noticed that mdp5 plane states leak like a sieve
> ever since we introduced plane_state->commit refcount a few years ago
> in 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too
> early by tracking commits, v3.")
>
> Fix it by using the right helpers.
>
> [...]
Applied, thanks!
[1/1] drm/msm/mdp5: Don't leak some plane state
https://gitlab.freedesktop.org/lumag/msm/-/commit/fd0ad3b2365c
Best regards,
--
Dmitry Baryshkov
Re: [PATCH 3/3] drm/mst: adjust the function drm_dp_remove_payload_part2()
On Fri, Aug 04, 2023 at 02:20:29PM +0800, Wayne Lin wrote:
> [...]
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index e04f87ff755a..4270178f95f6 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -3382,8 +3382,7 @@ EXPORT_SYMBOL(drm_dp_remove_payload_part1);
> * drm_dp_remove_payload_part2() - Remove an MST payload locally
> * @mgr: Manager to use.
> * @mst_state: The MST atomic state
> - * @old_payload: The payload with its old state
> - * @new_payload: The payload with its latest state
> + * @payload: The payload with its latest state
> *
> * Updates the starting time slots of all other payloads which would have
> been shifted towards
> * the start of the payload ID table as a result of removing a payload.
> Driver should call this
> @@ -3392,25 +3391,36 @@ EXPORT_SYMBOL(drm_dp_remove_payload_part1);
> */
> void drm_dp_remove_payload_part2(struct drm_dp_mst_topology_mgr *mgr,
>struct drm_dp_mst_topology_state *mst_state,
> - const struct drm_dp_mst_atomic_payload
> *old_payload,
> - struct drm_dp_mst_atomic_payload *new_payload)
> + struct drm_dp_mst_atomic_payload *payload)
> {
> struct drm_dp_mst_atomic_payload *pos;
> + u8 time_slots_to_remove;
> + u8 next_payload_vc_start = mgr->next_start_slot;
> +
> + /* Find the current allocated time slot number of the payload */
> + list_for_each_entry(pos, _state->payloads, next) {
> + if (pos != payload &&
> + pos->vc_start_slot > payload->vc_start_slot &&
> + pos->vc_start_slot < next_payload_vc_start)
> + next_payload_vc_start = pos->vc_start_slot;
> + }
> +
> + time_slots_to_remove = next_payload_vc_start - payload->vc_start_slot;
Imo, the intuitive way would be to pass the old payload state to this
function - which already contains the required time_slots param - and
refactor things instead moving vc_start_slot from the payload state to
mgr suggested by Ville earlier.
--Imre
> /* Remove local payload allocation */
> list_for_each_entry(pos, _state->payloads, next) {
> - if (pos != new_payload && pos->vc_start_slot >
> new_payload->vc_start_slot)
> - pos->vc_start_slot -= old_payload->time_slots;
> + if (pos != payload && pos->vc_start_slot >
> payload->vc_start_slot)
> + pos->vc_start_slot -= time_slots_to_remove;
> }
> - new_payload->vc_start_slot = -1;
> + payload->vc_start_slot = -1;
>
> mgr->payload_count--;
> - mgr->next_start_slot -= old_payload->time_slots;
> + mgr->next_start_slot -= time_slots_to_remove;
>
> - if (new_payload->delete)
> - drm_dp_mst_put_port_malloc(new_payload->port);
> + if (payload->delete)
> + drm_dp_mst_put_port_malloc(payload->port);
>
> - new_payload->payload_allocation_status =
> DRM_DP_MST_PAYLOAD_ALLOCATION_NONE;
> + payload->payload_allocation_status = DRM_DP_MST_PAYLOAD_ALLOCATION_NONE;
> }
Re: [PATCH v2 13/13] drm/msm/adreno: Switch to chip-id for identifying GPU
On Fri, 28 Jul 2023 at 00:23, Rob Clark wrote: > > From: Rob Clark > > Since the revision becomes an opaque identifier with future GPUs, move > away from treating different ranges of bits as having a given meaning. > This means that we need to explicitly list different patch revisions in > the device table. > > Signed-off-by: Rob Clark > --- > drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 2 +- > drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +- > drivers/gpu/drm/msm/adreno/a5xx_power.c| 2 +- > drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 14 ++- > drivers/gpu/drm/msm/adreno/adreno_device.c | 137 +++-- > drivers/gpu/drm/msm/adreno/adreno_gpu.c| 14 +-- > drivers/gpu/drm/msm/adreno/adreno_gpu.h| 49 > 7 files changed, 115 insertions(+), 105 deletions(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
[PATCH] drm/panel: simple: Fix AUO G121EAN01 panel timings according to the docs
Commit 03e909acd95a ("drm/panel: simple: Add support for AUO G121EAN01.4
panel") added support for this panel model, but the timings it implements
are very different from what the datasheet describes. I checked both the
G121EAN01.0 datasheet from [0] and the G121EAN01.4 one from [1] and they
all have the same timings: for example the LVDS clock typical value is 74.4
MHz, not 66.7 MHz as implemented.
Replace the timings with the ones from the documentation. These timings
have been tested and the clock frequencies verified with an oscilloscope to
ensure they are correct.
Also use struct display_timing instead of struct drm_display_mode in order
to also specify the minimum and maximum values.
[0] https://embedded.avnet.com/product/g121ean01-0/
[1] https://embedded.avnet.com/product/g121ean01-4/
Fixes: 03e909acd95a ("drm/panel: simple: Add support for AUO G121EAN01.4 panel")
Signed-off-by: Luca Ceresoli
---
drivers/gpu/drm/panel/panel-simple.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 701013b3ad13..56854f78441e 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -999,21 +999,21 @@ static const struct panel_desc auo_g104sn02 = {
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
-static const struct drm_display_mode auo_g121ean01_mode = {
- .clock = 66700,
- .hdisplay = 1280,
- .hsync_start = 1280 + 58,
- .hsync_end = 1280 + 58 + 8,
- .htotal = 1280 + 58 + 8 + 70,
- .vdisplay = 800,
- .vsync_start = 800 + 6,
- .vsync_end = 800 + 6 + 4,
- .vtotal = 800 + 6 + 4 + 10,
+static const struct display_timing auo_g121ean01_timing = {
+ .pixelclock = { 6000, 7440, 9000 },
+ .hactive = { 1280, 1280, 1280 },
+ .hfront_porch = { 20, 50, 100 },
+ .hback_porch = { 20, 50, 100 },
+ .hsync_len = { 30, 100, 200 },
+ .vactive = { 800, 800, 800 },
+ .vfront_porch = { 2, 10, 25 },
+ .vback_porch = { 2, 10, 25 },
+ .vsync_len = { 4, 18, 50 },
};
static const struct panel_desc auo_g121ean01 = {
- .modes = _g121ean01_mode,
- .num_modes = 1,
+ .timings = _g121ean01_timing,
+ .num_timings = 1,
.bpc = 8,
.size = {
.width = 261,
--
2.34.1
[PATCH] drm/panel: simple: Fix Innolux G156HCE-L01 LVDS clock
This panel has been implemented in commit 225213f24c79 ("drm/panel-simple:
Add Innolux G156HCE-L01 panel entry") with a higher clock than the typical
one mentioned on the documentation to avoid flickering on the unit
tested. Testing on a different unit shows that the panel actually works
with the intended 70.93 MHz clock and even lower frequencies so the
flickering is likely caused either by a defective unit or by other
different components such as the bridge.
Fixes: 225213f24c79 ("drm/panel-simple: Add Innolux G156HCE-L01 panel entry")
Signed-off-by: Luca Ceresoli
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 56854f78441e..ec3a73bbfe30 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2379,7 +2379,7 @@ static const struct panel_desc innolux_g121x1_l03 = {
};
static const struct display_timing innolux_g156hce_l01_timings = {
- .pixelclock = { 12000, 14400, 15000 },
+ .pixelclock = { 12000, 14186, 15000 },
.hactive = { 1920, 1920, 1920 },
.hfront_porch = { 80, 90, 100 },
.hback_porch = { 80, 90, 100 },
--
2.34.1
Re: [PATCH 1/4] drm/bridge: lt8912b: Fix bridge_detach
On Fri, Aug 4, 2023 at 12:48 PM Tomi Valkeinen
wrote:
>
> The driver calls lt8912_bridge_detach() from its lt8912_remove()
> function. As the DRM core detaches bridges automatically, this leads to
> calling lt8912_bridge_detach() twice. The code probably has tried to
> manage the double-call with the 'is_attached' variable, but the driver
> never sets the variable to false, so its of no help.
>
> Fix the issue by dropping the call to lt8912_bridge_detach() from
> lt8912_remove(), as the DRM core will handle the detach call for us,
> and also drop the useless is_attached field.
>
> Fixes: 88abfc2b9e61 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/bridge/lontium-lt8912b.c | 16 +---
> 1 file changed, 5 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c
> b/drivers/gpu/drm/bridge/lontium-lt8912b.c
> index 4eaea67fb71c..0e581f6e3c88 100644
> --- a/drivers/gpu/drm/bridge/lontium-lt8912b.c
> +++ b/drivers/gpu/drm/bridge/lontium-lt8912b.c
> @@ -45,7 +45,6 @@ struct lt8912 {
>
> u8 data_lanes;
> bool is_power_on;
> - bool is_attached;
> };
>
> static int lt8912_write_init_config(struct lt8912 *lt)
> @@ -575,8 +574,6 @@ static int lt8912_bridge_attach(struct drm_bridge *bridge,
> if (ret)
> goto error;
>
> - lt->is_attached = true;
> -
> return 0;
>
> error:
> @@ -588,15 +585,13 @@ static void lt8912_bridge_detach(struct drm_bridge
> *bridge)
> {
> struct lt8912 *lt = bridge_to_lt8912(bridge);
>
> - if (lt->is_attached) {
> - lt8912_hard_power_off(lt);
> + lt8912_hard_power_off(lt);
>
> - if (lt->hdmi_port->ops & DRM_BRIDGE_OP_HPD)
> - drm_bridge_hpd_disable(lt->hdmi_port);
> + if (lt->hdmi_port->ops & DRM_BRIDGE_OP_HPD)
> + drm_bridge_hpd_disable(lt->hdmi_port);
>
> - drm_connector_unregister(>connector);
> - drm_connector_cleanup(>connector);
> - }
> + drm_connector_unregister(>connector);
> + drm_connector_cleanup(>connector);
> }
>
> static enum drm_connector_status
> @@ -750,7 +745,6 @@ static void lt8912_remove(struct i2c_client *client)
> {
> struct lt8912 *lt = i2c_get_clientdata(client);
>
> - lt8912_bridge_detach(>bridge);
> drm_bridge_remove(>bridge);
> lt8912_free_i2c(lt);
> lt8912_put_dt(lt);
>
> --
> 2.34.1
>
Reviewed-by: Robert Foss
Re: [PATCH 2/4] drm/bridge: lt8912b: Fix crash on bridge detach
On Fri, Aug 4, 2023 at 12:48 PM Tomi Valkeinen
wrote:
>
> The lt8912b driver, in its bridge detach function, calls
> drm_connector_unregister() and drm_connector_cleanup().
>
> drm_connector_unregister() should be called only for connectors
> explicitly registered with drm_connector_register(), which is not the
> case in lt8912b.
>
> The driver's drm_connector_funcs.destroy hook is set to
> drm_connector_cleanup().
>
> Thus the driver should not call either drm_connector_unregister() nor
> drm_connector_cleanup() in its lt8912_bridge_detach(), as they cause a
> crash on bridge detach:
>
> Unable to handle kernel NULL pointer dereference at virtual address
>
> Mem abort info:
> ESR = 0x9606
> EC = 0x25: DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> FSC = 0x06: level 2 translation fault
> Data abort info:
> ISV = 0, ISS = 0x0006, ISS2 = 0x
> CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> user pgtable: 4k pages, 48-bit VAs, pgdp=858f3000
> [] pgd=080085918003, p4d=080085918003,
> pud=080085431003, pmd=
> Internal error: Oops: 9606 [#1] PREEMPT SMP
> Modules linked in: tidss(-) display_connector lontium_lt8912b tc358768
> panel_lvds panel_simple drm_dma_helper drm_kms_helper drm
> drm_panel_orientation_quirks
> CPU: 3 PID: 462 Comm: rmmod Tainted: GW 6.5.0-rc2+ #2
> Hardware name: Toradex Verdin AM62 on Verdin Development Board (DT)
> pstate: 8005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : drm_connector_cleanup+0x78/0x2d4 [drm]
> lr : lt8912_bridge_detach+0x54/0x6c [lontium_lt8912b]
> sp : 800082ed3a90
> x29: 800082ed3a90 x28: 040c1940 x27:
> x26: x25: dead0122 x24: dead0122
> x23: dead0100 x22: 03fb6388 x21:
> x20: x19: 03fb6260 x18: fffe56e8
> x17: x16: 0010 x15: 0038
> x14: x13: 800081914b48 x12: 040e
> x11: 015a x10: 80008196ebb8 x9 : 800081914b48
> x8 : efff x7 : 040c1940 x6 : 80007aa649d0
> x5 : x4 : 0001 x3 : 80008159e008
> x2 : x1 : x0 :
> Call trace:
> drm_connector_cleanup+0x78/0x2d4 [drm]
> lt8912_bridge_detach+0x54/0x6c [lontium_lt8912b]
> drm_bridge_detach+0x44/0x84 [drm]
> drm_encoder_cleanup+0x40/0xb8 [drm]
> drmm_encoder_alloc_release+0x1c/0x30 [drm]
> drm_managed_release+0xac/0x148 [drm]
> drm_dev_put.part.0+0x88/0xb8 [drm]
> devm_drm_dev_init_release+0x14/0x24 [drm]
> devm_action_release+0x14/0x20
> release_nodes+0x5c/0x90
> devres_release_all+0x8c/0xe0
> device_unbind_cleanup+0x18/0x68
> device_release_driver_internal+0x208/0x23c
> driver_detach+0x4c/0x94
> bus_remove_driver+0x70/0xf4
> driver_unregister+0x30/0x60
> platform_driver_unregister+0x14/0x20
> tidss_platform_driver_exit+0x18/0xb2c [tidss]
> __arm64_sys_delete_module+0x1a0/0x2b4
> invoke_syscall+0x48/0x110
> el0_svc_common.constprop.0+0x60/0x10c
> do_el0_svc_compat+0x1c/0x40
> el0_svc_compat+0x40/0xac
> el0t_32_sync_handler+0xb0/0x138
> el0t_32_sync+0x194/0x198
> Code: 9104a276 f2fbd5b7 aa0203e1 91008af8 (f85c0420)
>
> Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/bridge/lontium-lt8912b.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c
> b/drivers/gpu/drm/bridge/lontium-lt8912b.c
> index 0e581f6e3c88..2d752e083433 100644
> --- a/drivers/gpu/drm/bridge/lontium-lt8912b.c
> +++ b/drivers/gpu/drm/bridge/lontium-lt8912b.c
> @@ -589,9 +589,6 @@ static void lt8912_bridge_detach(struct drm_bridge
> *bridge)
>
> if (lt->hdmi_port->ops & DRM_BRIDGE_OP_HPD)
> drm_bridge_hpd_disable(lt->hdmi_port);
> -
> - drm_connector_unregister(>connector);
> - drm_connector_cleanup(>connector);
> }
>
> static enum drm_connector_status
>
> --
> 2.34.1
>
Reviewed-by: Robert Foss
Re: [PATCH] drm/msm/dpu: initialise clk_rate to 0 in _dpu_core_perf_get_core_clk_rate
On 8/4/2023 2:48 AM, Dmitry Baryshkov wrote:
When removing the core perf tune overrides, I also occasionaly removed the
initialisation of the clk_rate variable. Initialise it to 0 to let max()
correctly calculate the maximum of requested clock rates.
Reported-by: Dan Carpenter
Fixes: 6a4bc73915af ("drm/msm/dpu: drop separate dpu_core_perf_tune overrides")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 1 +
1 file changed, 1 insertion(+)
Reviewed-by: Abhinav Kumar
Re: [PATCH 2/3] drm/mst: Refactor the flow for payload allocation/removement
Hi Wayne, kernel test robot noticed the following build warnings: [auto build test WARNING on drm-misc/drm-misc-next] [also build test WARNING on drm-intel/for-linux-next-fixes drm/drm-next linus/master v6.5-rc4 next-20230804] [cannot apply to drm-intel/for-linux-next] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Wayne-Lin/drm-mst-delete-unnecessary-case-in-drm_dp_add_payload_part2/20230804-142405 base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next patch link: https://lore.kernel.org/r/20230804062029.5686-3-Wayne.Lin%40amd.com patch subject: [PATCH 2/3] drm/mst: Refactor the flow for payload allocation/removement config: s390-randconfig-r044-20230731 (https://download.01.org/0day-ci/archive/20230804/202308042253.lm5xmnna-...@intel.com/config) compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project.git 4a5ac14ee968ff0ad5d2cc1ffa0299048db4c88a) reproduce: (https://download.01.org/0day-ci/archive/20230804/202308042253.lm5xmnna-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202308042253.lm5xmnna-...@intel.com/ All warnings (new ones prefixed by >>): In file included from drivers/gpu/drm/nouveau/dispnv50/disp.c:24: In file included from drivers/gpu/drm/nouveau/dispnv50/disp.h:4: In file included from drivers/gpu/drm/nouveau/include/nvif/mem.h:3: In file included from drivers/gpu/drm/nouveau/include/nvif/mmu.h:3: In file included from drivers/gpu/drm/nouveau/include/nvif/object.h:4: In file included from drivers/gpu/drm/nouveau/include/nvif/os.h:8: In file included from include/linux/pci.h:39: In file included from include/linux/io.h:13: In file included from arch/s390/include/asm/io.h:75: include/asm-generic/io.h:547:31: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] 547 | val = __raw_readb(PCI_IOBASE + addr); | ~~ ^ include/asm-generic/io.h:560:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] 560 | val = __le16_to_cpu((__le16 __force)__raw_readw(PCI_IOBASE + addr)); | ~~ ^ include/uapi/linux/byteorder/big_endian.h:37:59: note: expanded from macro '__le16_to_cpu' 37 | #define __le16_to_cpu(x) __swab16((__force __u16)(__le16)(x)) | ^ include/uapi/linux/swab.h:102:54: note: expanded from macro '__swab16' 102 | #define __swab16(x) (__u16)__builtin_bswap16((__u16)(x)) | ^ In file included from drivers/gpu/drm/nouveau/dispnv50/disp.c:24: In file included from drivers/gpu/drm/nouveau/dispnv50/disp.h:4: In file included from drivers/gpu/drm/nouveau/include/nvif/mem.h:3: In file included from drivers/gpu/drm/nouveau/include/nvif/mmu.h:3: In file included from drivers/gpu/drm/nouveau/include/nvif/object.h:4: In file included from drivers/gpu/drm/nouveau/include/nvif/os.h:8: In file included from include/linux/pci.h:39: In file included from include/linux/io.h:13: In file included from arch/s390/include/asm/io.h:75: include/asm-generic/io.h:573:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] 573 | val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr)); | ~~ ^ include/uapi/linux/byteorder/big_endian.h:35:59: note: expanded from macro '__le32_to_cpu' 35 | #define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x)) | ^ include/uapi/linux/swab.h:115:54: note: expanded from macro '__swab32' 115 | #define __swab32(x) (__u32)__builtin_bswap32((__u32)(x)) | ^ In file included from drivers/gpu/drm/nouveau/dispnv50/disp.c:24: In file included from drivers/gpu/drm/nouveau/dispnv50/disp.h:4: In file included from drivers/gpu/drm/nouveau/include/nvif/mem.h:3: In file included from drivers/gpu/drm/nouveau/include/nvif/mmu.h:3: In file included from drivers/gpu/drm/nouveau/include/nvif/object.h:4: In file included from drivers/gpu/drm/nouveau/include/nvif/os.h:8: In file included from include/linux/pci.h:39: In file included from include/linux/io.h:13: In file included from arc
Re: [PATCH 0/5 v4] accel/qaic: Improve bounds checking in encode/decode
On 7/12/2023 12:30 AM, Dan Carpenter wrote: On Tue, Jul 11, 2023 at 11:33:25AM -0600, Jeffrey Hugo wrote: On 7/11/2023 2:20 AM, Dan Carpenter wrote: Fixed in v4: Send the correct [PATCH 1/5] patch. Fixed in v3: Redo messed up threading Fixed two things in v2: Include the file. Change the >= in encode and decode to >. regards, dan carpenter Did you intentionally drop tags from previous versions? Sorry, I kept messing up the resends. For 1-3, 5 Reviewed-by: Jeffrey Hugo Looks like 3,5 are reviewed by Pranjal and also good. I see 5 is also reviewed by Dafna. Expect those to be merged. 1,2 need a review from Pranjal, but I expect all is good and will be merged. I did not see feedback on my question for 4. Would like your feedback before queuing that one up. Sorry, again. Yeah. I think you're right. Could we queue the rest and I will resend 4 separately? I know it's a headache. If not it's fine, I can resend them all. Resend for #4 is still coming, right? I just don't want to forget about it. -Jeff
Re: [PATCH 2/2] drm/panel-simple: Add Innolux G156HCE-L01 panel entry
Hi Marek, Neil, On Fri, 4 Aug 2023 10:19:12 +0200 Luca Ceresoli wrote: > Hi Marek, > > On Thu, 3 Aug 2023 19:10:35 +0200 > Marek Vasut wrote: > > > On 8/3/23 17:06, Luca Ceresoli wrote: > > > Hi Marek, > > > > > > On Thu, 3 Aug 2023 16:25:37 +0200 > > > Marek Vasut wrote: > > > > > >> On 8/3/23 16:23, Luca Ceresoli wrote: > > >>> Hi Marek, > > >> > > >> Hi, > > >> > > >>> On Mon, 31 Jul 2023 23:02:58 +0200 > > >>> Marek Vasut wrote: > > >>> > > Add support for Innolux G156HCE-L01 15.6" 1920x1080 24bpp > > dual-link LVDS TFT panel. Documentation is available at [1]. > > >>> > > >>> Interesting, I'm bringing up this exact panel right now and found your > > >>> patch. > > >>> > > The middle frequency is tuned slightly upward from 70.93 MHz > > to 72 MHz, otherwise the panel shows slight flicker. > > >>> > > >>> Using 70.93 MHz here does not show any flickering. I even tried going > > >>> in the opposite direction and set 70 MHz, and to use different > > >>> backlight settings, all without any flickering. > > >>> > > >>> Do you think you might be using a defective device? Would you have a > > >>> chance of testing another sample? > > >> > > >> I have literally one such display. > > >> > > >> Which SoC do you use (and if applicable, which bridge) ? > > > > > > The panel is driven by the DSI-2 output of a i.MX8MP through a TI > > > SN65DSI84 bridge. > > > > I use the LT9211 , so I wonder whether this might be another Lontium > > specific oddity. > > Or maybe not. After checking the LVDS clock with an oscilloscope I > discovered I was actually sending 77 MHz. After fixing it I found that > my panel (of which I only have one sample as well) does not display any > output with pixel clocks <= 75 MHz. It works with clocks >= 76 MHz. After checking lots of other details in my video setup and doing cleanups, I finally managed to have this panel working with the intended 70.93 MHz clock (and also lower clocks such as 70.00 MHz). Is it too late to change this patch? Or should I send a patch on top? Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
[PATCH v2 1/2] pwm: Manage owner assignment implicitly for drivers
Instead of requiring each driver to care for assigning the owner member
of struct pwm_ops, handle that implicitly using a macro. Note that the
owner member has to be moved to struct pwm_chip, as the ops structure
usually lives in read-only memory and so cannot be modified.
The upside is that new lowlevel drivers cannot forget the assignment and
save one line each. The pwm-crc driver didn't assign .owner, that's not
a problem in practise though as the driver cannot be compiled as a
module.
Signed-off-by: Uwe Kleine-König
---
drivers/gpio/gpio-mvebu.c | 1 -
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 1 -
drivers/leds/rgb/leds-qcom-lpg.c | 1 -
drivers/pwm/core.c| 24 ++--
drivers/pwm/pwm-ab8500.c | 1 -
drivers/pwm/pwm-apple.c | 1 -
drivers/pwm/pwm-atmel-hlcdc.c | 1 -
drivers/pwm/pwm-atmel-tcb.c | 1 -
drivers/pwm/pwm-atmel.c | 1 -
drivers/pwm/pwm-bcm-iproc.c | 1 -
drivers/pwm/pwm-bcm-kona.c| 1 -
drivers/pwm/pwm-bcm2835.c | 1 -
drivers/pwm/pwm-berlin.c | 1 -
drivers/pwm/pwm-brcmstb.c | 1 -
drivers/pwm/pwm-clk.c | 1 -
drivers/pwm/pwm-clps711x.c| 1 -
drivers/pwm/pwm-cros-ec.c | 1 -
drivers/pwm/pwm-dwc.c | 1 -
drivers/pwm/pwm-ep93xx.c | 1 -
drivers/pwm/pwm-fsl-ftm.c | 1 -
drivers/pwm/pwm-hibvt.c | 1 -
drivers/pwm/pwm-img.c | 1 -
drivers/pwm/pwm-imx-tpm.c | 1 -
drivers/pwm/pwm-imx1.c| 1 -
drivers/pwm/pwm-imx27.c | 1 -
drivers/pwm/pwm-intel-lgm.c | 1 -
drivers/pwm/pwm-iqs620a.c | 1 -
drivers/pwm/pwm-jz4740.c | 1 -
drivers/pwm/pwm-keembay.c | 1 -
drivers/pwm/pwm-lp3943.c | 1 -
drivers/pwm/pwm-lpc18xx-sct.c | 1 -
drivers/pwm/pwm-lpc32xx.c | 1 -
drivers/pwm/pwm-lpss.c| 1 -
drivers/pwm/pwm-mediatek.c| 1 -
drivers/pwm/pwm-meson.c | 1 -
drivers/pwm/pwm-microchip-core.c | 1 -
drivers/pwm/pwm-mtk-disp.c| 1 -
drivers/pwm/pwm-mxs.c | 1 -
drivers/pwm/pwm-ntxec.c | 1 -
drivers/pwm/pwm-omap-dmtimer.c| 1 -
drivers/pwm/pwm-pca9685.c | 1 -
drivers/pwm/pwm-pxa.c | 1 -
drivers/pwm/pwm-raspberrypi-poe.c | 1 -
drivers/pwm/pwm-rcar.c| 1 -
drivers/pwm/pwm-renesas-tpu.c | 1 -
drivers/pwm/pwm-rockchip.c| 1 -
drivers/pwm/pwm-rz-mtu3.c | 1 -
drivers/pwm/pwm-samsung.c | 1 -
drivers/pwm/pwm-sifive.c | 1 -
drivers/pwm/pwm-sl28cpld.c| 1 -
drivers/pwm/pwm-spear.c | 1 -
drivers/pwm/pwm-sprd.c| 1 -
drivers/pwm/pwm-sti.c | 1 -
drivers/pwm/pwm-stm32-lp.c| 1 -
drivers/pwm/pwm-stm32.c | 1 -
drivers/pwm/pwm-stmpe.c | 1 -
drivers/pwm/pwm-sun4i.c | 1 -
drivers/pwm/pwm-sunplus.c | 1 -
drivers/pwm/pwm-tegra.c | 1 -
drivers/pwm/pwm-tiecap.c | 1 -
drivers/pwm/pwm-tiehrpwm.c| 1 -
drivers/pwm/pwm-twl-led.c | 2 --
drivers/pwm/pwm-twl.c | 2 --
drivers/pwm/pwm-visconti.c| 1 -
drivers/pwm/pwm-vt8500.c | 1 -
drivers/pwm/pwm-xilinx.c | 1 -
drivers/staging/greybus/pwm.c | 1 -
include/linux/pwm.h | 10 ++
68 files changed, 20 insertions(+), 82 deletions(-)
diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index a68f682aec01..b2e6b54e2559 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -756,7 +756,6 @@ static const struct pwm_ops mvebu_pwm_ops = {
.free = mvebu_pwm_free,
.get_state = mvebu_pwm_get_state,
.apply = mvebu_pwm_apply,
- .owner = THIS_MODULE,
};
static void __maybe_unused mvebu_pwm_suspend(struct mvebu_gpio_chip *mvchip)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index c499a14d0b98..53d133d18c18 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -1571,7 +1571,6 @@ static const struct pwm_ops ti_sn_pwm_ops = {
.free = ti_sn_pwm_free,
.apply = ti_sn_pwm_apply,
.get_state = ti_sn_pwm_get_state,
- .owner = THIS_MODULE,
};
static int ti_sn_pwm_probe(struct auxiliary_device *adev,
diff --git a/drivers/leds/rgb/leds-qcom-lpg.c b/drivers/leds/rgb/leds-qcom-lpg.c
index 59581b3e25ca..d7ae30ebb34a 100644
--- a/drivers/leds/rgb/leds-qcom-lpg.c
+++ b/drivers/leds/rgb/leds-qcom-lpg.c
@@ -1086,7 +1086,6 @@ static const struct pwm_ops lpg_pwm_ops = {
.request =
[PATCH v2 0/2] pwm: Manage owner assignment implicitly for drivers
Hello, (implicit) v1 of this series can be found at https://lore.kernel.org/linux-pwm/20230803140633.138165-1-u.kleine-koe...@pengutronix.de . Changes since then only affect documentation that I missed to adapt before. Thanks to Laurent for catching that Best regards Uwe Uwe Kleine-König (2): pwm: Manage owner assignment implicitly for drivers pwm: crc: Allow compilation as module and with COMPILE_TEST drivers/gpio/gpio-mvebu.c | 1 - drivers/gpu/drm/bridge/ti-sn65dsi86.c | 1 - drivers/leds/rgb/leds-qcom-lpg.c | 1 - drivers/pwm/Kconfig | 4 ++-- drivers/pwm/core.c| 24 ++-- drivers/pwm/pwm-ab8500.c | 1 - drivers/pwm/pwm-apple.c | 1 - drivers/pwm/pwm-atmel-hlcdc.c | 1 - drivers/pwm/pwm-atmel-tcb.c | 1 - drivers/pwm/pwm-atmel.c | 1 - drivers/pwm/pwm-bcm-iproc.c | 1 - drivers/pwm/pwm-bcm-kona.c| 1 - drivers/pwm/pwm-bcm2835.c | 1 - drivers/pwm/pwm-berlin.c | 1 - drivers/pwm/pwm-brcmstb.c | 1 - drivers/pwm/pwm-clk.c | 1 - drivers/pwm/pwm-clps711x.c| 1 - drivers/pwm/pwm-crc.c | 5 - drivers/pwm/pwm-cros-ec.c | 1 - drivers/pwm/pwm-dwc.c | 1 - drivers/pwm/pwm-ep93xx.c | 1 - drivers/pwm/pwm-fsl-ftm.c | 1 - drivers/pwm/pwm-hibvt.c | 1 - drivers/pwm/pwm-img.c | 1 - drivers/pwm/pwm-imx-tpm.c | 1 - drivers/pwm/pwm-imx1.c| 1 - drivers/pwm/pwm-imx27.c | 1 - drivers/pwm/pwm-intel-lgm.c | 1 - drivers/pwm/pwm-iqs620a.c | 1 - drivers/pwm/pwm-jz4740.c | 1 - drivers/pwm/pwm-keembay.c | 1 - drivers/pwm/pwm-lp3943.c | 1 - drivers/pwm/pwm-lpc18xx-sct.c | 1 - drivers/pwm/pwm-lpc32xx.c | 1 - drivers/pwm/pwm-lpss.c| 1 - drivers/pwm/pwm-mediatek.c| 1 - drivers/pwm/pwm-meson.c | 1 - drivers/pwm/pwm-microchip-core.c | 1 - drivers/pwm/pwm-mtk-disp.c| 1 - drivers/pwm/pwm-mxs.c | 1 - drivers/pwm/pwm-ntxec.c | 1 - drivers/pwm/pwm-omap-dmtimer.c| 1 - drivers/pwm/pwm-pca9685.c | 1 - drivers/pwm/pwm-pxa.c | 1 - drivers/pwm/pwm-raspberrypi-poe.c | 1 - drivers/pwm/pwm-rcar.c| 1 - drivers/pwm/pwm-renesas-tpu.c | 1 - drivers/pwm/pwm-rockchip.c| 1 - drivers/pwm/pwm-rz-mtu3.c | 1 - drivers/pwm/pwm-samsung.c | 1 - drivers/pwm/pwm-sifive.c | 1 - drivers/pwm/pwm-sl28cpld.c| 1 - drivers/pwm/pwm-spear.c | 1 - drivers/pwm/pwm-sprd.c| 1 - drivers/pwm/pwm-sti.c | 1 - drivers/pwm/pwm-stm32-lp.c| 1 - drivers/pwm/pwm-stm32.c | 1 - drivers/pwm/pwm-stmpe.c | 1 - drivers/pwm/pwm-sun4i.c | 1 - drivers/pwm/pwm-sunplus.c | 1 - drivers/pwm/pwm-tegra.c | 1 - drivers/pwm/pwm-tiecap.c | 1 - drivers/pwm/pwm-tiehrpwm.c| 1 - drivers/pwm/pwm-twl-led.c | 2 -- drivers/pwm/pwm-twl.c | 2 -- drivers/pwm/pwm-visconti.c| 1 - drivers/pwm/pwm-vt8500.c | 1 - drivers/pwm/pwm-xilinx.c | 1 - drivers/staging/greybus/pwm.c | 1 - include/linux/pwm.h | 10 ++ 70 files changed, 26 insertions(+), 85 deletions(-) base-commit: 3ccb179aa40d931eb00ef8910d7b812a95659563 -- 2.40.1
Re: [PATCH 4/8] drm/sched: Add generic scheduler message interface
On Fri, Aug 04, 2023 at 10:50:36AM +0200, Daniel Vetter wrote: > On Thu, Aug 03, 2023 at 11:35:30AM +0200, Christian König wrote: > > Am 03.08.23 um 10:58 schrieb Daniel Vetter: > > > On Thu, 3 Aug 2023 at 10:53, Christian König > > > wrote: > > > > Am 01.08.23 um 22:50 schrieb Matthew Brost: > > > > > Add generic schedule message interface which sends messages to backend > > > > > from the drm_gpu_scheduler main submission thread. The idea is some of > > > > > these messages modify some state in drm_sched_entity which is also > > > > > modified during submission. By scheduling these messages and > > > > > submission > > > > > in the same thread their is not race changing states in > > > > > drm_sched_entity. > > > > > > > > > > This interface will be used in XE, new Intel GPU driver, to cleanup, > > > > > suspend, resume, and change scheduling properties of a > > > > > drm_sched_entity. > > > > > > > > > > The interface is designed to be generic and extendable with only the > > > > > backend understanding the messages. Christian / Daniel - I've read both of you comments and having a hard time parsing them. I do not really understand the issue with this patch or exactly what is being suggested instead. Let's try to work through this. > > > > I'm still extremely frowned on this. > > > > > > > > If you need this functionality then let the drivers decide which > > > > runqueue the scheduler should use. What do you mean by runqueue here? Do you mean 'struct workqueue_struct'? The scheduler in this context is 'struct drm_gpu_scheduler', right? Yes, we have added this functionality iin the first patch. > > > > > > > > When you then create a single threaded runqueue you can just submit work > > > > to it and serialize this with the scheduler work. > > > > We don't want to use a single threaded workqueue_struct in Xe, we want to use a system_wq as run_job() can be executed in parallel across multiple entites (or drm_gpu_scheduler as in Xe we have 1 to 1 relationship between entity and scheduler). What we want is on per entity / scheduler granularity to be able to communicate into the backend a message synchronously (run_job / free_job not executing, scheduler execution not paused for a reset). If I'm underatanding what you suggesting in Xe we'd create an ordered workqueue_struct per drm_gpu_scheduler and the queue messages on the ordered workqueue_struct? This seems pretty messy to me as now we have open coded a solution bypassing the scheduler, every drm_gpu_scheduler creates its own workqueue_struct, and we'd also have to open code the pausing of these messages for resets too. IMO this is pretty clean solution that follows the pattern of cleanup jobs already in place. > > > > This way we wouldn't duplicate this core kernel function inside the > > > > scheduler. > > > Yeah that's essentially the design we picked for the tdr workers, > > > where some drivers have requirements that all tdr work must be done on > > > the same thread (because of cross-engine coordination issues). But > > > that would require that we rework the scheduler as a pile of > > > self-submitting work items, and I'm not sure that actually fits all > > > that well into the core workqueue interfaces either. This is the ordering between TDRs firing between different drm_gpu_scheduler and larger external resets (GT in Xe) an ordered workqueue_struct makes sense for this. Here we are talking about ordering jobs and messages within a single drm_gpu_scheduler. Using the main execution thread to do ordering makes sense in my opinion. > > > > There were already patches floating around which did exactly that. > > > > Last time I checked those were actually looking pretty good. > > Link to patches for reference. > > Additional to message passing advantage the real big issue with the > > scheduler and 1 to 1 mapping is that we create a kernel thread for each > > instance, which results in tons on overhead. First patch in the series switches from kthread to work queue, that is still a good idea. > > > > Just using a work item which is submitted to a work queue completely avoids > > that. > > Hm I should have read the entire series first, since that does the > conversion still. Apologies for the confusion, and yeah we should be able > to just submit other work to the same wq with the first patch? And so > hand-rolling this infra here isn't needed at all? > I wouldn't call this hand rolling, rather it following patten already in place. Matt > Or what am I missing? > > > Regards, > > Christian. > > > > > > > > Worst case I think this isn't a dead-end and can be refactored to > > > internally use the workqueue services, with the new functions here > > > just being dumb wrappers until everyone is converted over. So it > > > doesn't look like an expensive mistake, if it turns out to be a > > > mistake. > > > -Daniel > > > > > > > > > > Regards, > > > > Christian. > > > > > > > > > Signed-off-by: Matthew Brost > > > > >
Re: [PATCH 2/2] drm/framebuffer: Fix use of uninitialized variable
On Fri, Aug 04, 2023 at 01:57:40PM +0300, Tomi Valkeinen wrote: > smatch reports: > > drivers/gpu/drm/drm_framebuffer.c:654 drm_mode_getfb2_ioctl() error: > uninitialized symbol 'ret'. > > 'ret' is possibly not set when there are no errors, causing the error > above. I can't say if that ever happens in real-life, but in any case I > think it is good to initialize 'ret' to 0. I don't think it can happen in practice, but tools have no way to know that. Reviewed-by: Laurent Pinchart > Signed-off-by: Tomi Valkeinen > --- > drivers/gpu/drm/drm_framebuffer.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_framebuffer.c > b/drivers/gpu/drm/drm_framebuffer.c > index aff3746dedfb..1955eaeba0ab 100644 > --- a/drivers/gpu/drm/drm_framebuffer.c > +++ b/drivers/gpu/drm/drm_framebuffer.c > @@ -570,7 +570,7 @@ int drm_mode_getfb2_ioctl(struct drm_device *dev, > struct drm_mode_fb_cmd2 *r = data; > struct drm_framebuffer *fb; > unsigned int i; > - int ret; > + int ret = 0; > > if (!drm_core_check_feature(dev, DRIVER_MODESET)) > return -EINVAL; > -- Regards, Laurent Pinchart
Re: [PATCH] drm: Drop select FRAMEBUFFER_CONSOLE for DRM_FBDEV_EMULATION
"Arnd Bergmann" writes:
> On Fri, Aug 4, 2023, at 15:07, Daniel Vetter wrote:
>> On Fri, 4 Aug 2023 at 14:52, Javier Martinez Canillas
>> wrote:
>>>
>>> The commit c242f48433e7 ("drm: Make FB_CORE to be selected if DRM fbdev
>>> emulation is enabled") changed DRM_FBDEV_EMULATION from 'depends on FB'
>>> to an effective 'select FB_CORE', so any config that previously had DRM=y
>>> and FB=n now has FB_CORE=y and FRAMEBUFFER_CONSOLE=y.
>>>
>>> This leads to unmet direct dependencies detected for FRAMEBUFFER_CONSOLE
>>> as reported by Arthur Grillo, e.g:
>>>
>>> WARNING: unmet direct dependencies detected for FRAMEBUFFER_CONSOLE
>>> Depends on [n]: VT [=n] && FB_CORE [=y] && !UML [=y]
>>> Selected by [y]:
>>> - DRM_FBDEV_EMULATION [=y] && HAS_IOMEM [=y] && DRM [=y] && !EXPERT [=n]
>>>
>>> Arnd Bergmann suggests to drop the select FRAMEBUFFER_CONSOLE for the
>>> DRM_FBDEV_EMULATION Kconfig symbol, since a possible use case could
>>> be to enable DRM fbdev emulation but without a framebuffer console.
>>>
>>> Fixes: c242f48433e7 ("drm: Make FB_CORE to be selected if DRM fbdev
>>> emulation is enabled")
>>> Reported-by: Arthur Grillo
>>> Closes:
>>> https://lore.kernel.org/dri-devel/20230726220325.278976-1-arthurgri...@riseup.net
>>> Suggested-by: Arnd Bergmann
>>> Signed-off-by: Javier Martinez Canillas
>>
>> Yeah originally this was just to help people not misconfigure their
>> kernels and end up with a black screen. But select is really not a
>> nice way to do that, imo we could drop the FB_CORE select too :-)
>
> Droping the 'FB_CORE' select only works if we make FB_CORE user
> visible and add a 'depends on' for it instead. Not sure this
> is any better since this would only ever be used when either
> CONFIG_FB or CONFIG_DRM_FBDEV_EMULATION is enabled.
>
Agreed.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Re: [PATCH] drm/mgag200: Increase bandwidth for G200se A rev1
Javier Martinez Canillas writes: > Thomas Zimmermann writes: > [...] >> The reasoning is that userspace should always be in control of the >> format (sans that one exception). If userspace wants packed 24-bits it >> can support RGB888 explicitly. For the color-format transformation, >> it's better to do that in userspace with SSE-like instructions than in >> the kernel. >> >> I wasn't super-happy with this, but I think it's a clear statement with >> simple rules to follow. I'd prefer that over relaxed rules where each >> driver does its own thing. >> > > I wasn't super happy either, but if I remember correctly we were the only > two that had this point of view and everyone else there thought that the > drivers shouldn't expose a format that don't support (other than XR24) ?. > I think that this unwritten rule must be documented somewhere so that we could know what the rule really is instead of people making assumptions. Because my understanding from the discussion was that user-space has no way to know if a format is "native" or "fake" and it shouldn't pay for the performance penalty of doing these format conversions in the drivers. But the irony here is that enforcing such a rule in this particular case would prevent to have a performance gain. So it seems to me as if it's the opposite to what such a rule wanted to achieve. My proposal is to write a doc patch explicitly stating that drivers must only expose a "virtual" XRGB format for compatibility and that it is allowed to drop the alpha channel in the driver if that would improve the performance for a particular device (e.g: slow DMA as is the case here). That way, the spirit of the rule would be to make the driver/device as performant as possible. What do you think ? Does this make sense to you ? -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH RFC v5 02/10] drm: Introduce solid fill DRM plane property
On Fri, 4 Aug 2023 at 16:44, Sebastian Wick wrote:
>
> On Fri, Aug 4, 2023 at 3:27 PM Dmitry Baryshkov
> wrote:
> >
> > On Fri, 28 Jul 2023 at 20:03, Jessica Zhang
> > wrote:
> > >
> > > Document and add support for solid_fill property to drm_plane. In
> > > addition, add support for setting and getting the values for solid_fill.
> > >
> > > To enable solid fill planes, userspace must assign a property blob to
> > > the "solid_fill" plane property containing the following information:
> > >
> > > struct drm_mode_solid_fill {
> > > u32 version;
> > > u32 r, g, b;
> > > };
> > >
> > > Signed-off-by: Jessica Zhang
> > > ---
> > > drivers/gpu/drm/drm_atomic_state_helper.c | 9 +
> > > drivers/gpu/drm/drm_atomic_uapi.c | 55
> > > +++
> > > drivers/gpu/drm/drm_blend.c | 30 +
> > > include/drm/drm_blend.h | 1 +
> > > include/drm/drm_plane.h | 35
> > > include/uapi/drm/drm_mode.h | 24 ++
> > > 6 files changed, 154 insertions(+)
> > >
> >
> > [skipped most of the patch]
> >
> > > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > > index 43691058d28f..53c8efa5ad7f 100644
> > > --- a/include/uapi/drm/drm_mode.h
> > > +++ b/include/uapi/drm/drm_mode.h
> > > @@ -259,6 +259,30 @@ struct drm_mode_modeinfo {
> > > char name[DRM_DISPLAY_MODE_LEN];
> > > };
> > >
> > > +/**
> > > + * struct drm_mode_solid_fill - User info for solid fill planes
> > > + *
> > > + * This is the userspace API solid fill information structure.
> > > + *
> > > + * Userspace can enable solid fill planes by assigning the plane
> > > "solid_fill"
> > > + * property to a blob containing a single drm_mode_solid_fill struct
> > > populated with an RGB323232
> > > + * color and setting the pixel source to "SOLID_FILL".
> > > + *
> > > + * For information on the plane property, see
> > > drm_plane_create_solid_fill_property()
> > > + *
> > > + * @version: Version of the blob. Currently, there is only support for
> > > version == 1
> > > + * @r: Red color value of single pixel
> > > + * @g: Green color value of single pixel
> > > + * @b: Blue color value of single pixel
> > > + */
> > > +struct drm_mode_solid_fill {
> > > + __u32 version;
> > > + __u32 r;
> > > + __u32 g;
> > > + __u32 b;
> >
> > Another thought about the drm_mode_solid_fill uABI. I still think we
> > should add alpha here. The reason is the following:
> >
> > It is true that we have drm_plane_state::alpha and the plane's
> > "alpha" property. However it is documented as "the plane-wide opacity
> > [...] It can be combined with pixel alpha. The pixel values in the
> > framebuffers are expected to not be pre-multiplied by the global alpha
> > associated to the plane.".
> >
> > I can imagine a use case, when a user might want to enable plane-wide
> > opacity, set "pixel blend mode" to "Coverage" and then switch between
> > partially opaque framebuffer and partially opaque solid-fill without
> > touching the plane's alpha value.
>
> The only reason I see against this is that there might be some
> hardware which supports only RGB but not alpha on planes and they
> could then not use this property.
Fair enough.
> Maybe another COLOR_FILL enum value
> with alpha might be better? Maybe just doing the alpha via the alpha
> property is good enough.
One of our customers has a use case for setting the opaque solid fill,
while keeping the plane's alpha intact.
--
With best wishes
Dmitry
Re: [PATCH] drm: Drop select FRAMEBUFFER_CONSOLE for DRM_FBDEV_EMULATION
On Fri, Aug 4, 2023, at 15:07, Daniel Vetter wrote:
> On Fri, 4 Aug 2023 at 14:52, Javier Martinez Canillas
> wrote:
>>
>> The commit c242f48433e7 ("drm: Make FB_CORE to be selected if DRM fbdev
>> emulation is enabled") changed DRM_FBDEV_EMULATION from 'depends on FB'
>> to an effective 'select FB_CORE', so any config that previously had DRM=y
>> and FB=n now has FB_CORE=y and FRAMEBUFFER_CONSOLE=y.
>>
>> This leads to unmet direct dependencies detected for FRAMEBUFFER_CONSOLE
>> as reported by Arthur Grillo, e.g:
>>
>> WARNING: unmet direct dependencies detected for FRAMEBUFFER_CONSOLE
>> Depends on [n]: VT [=n] && FB_CORE [=y] && !UML [=y]
>> Selected by [y]:
>> - DRM_FBDEV_EMULATION [=y] && HAS_IOMEM [=y] && DRM [=y] && !EXPERT [=n]
>>
>> Arnd Bergmann suggests to drop the select FRAMEBUFFER_CONSOLE for the
>> DRM_FBDEV_EMULATION Kconfig symbol, since a possible use case could
>> be to enable DRM fbdev emulation but without a framebuffer console.
>>
>> Fixes: c242f48433e7 ("drm: Make FB_CORE to be selected if DRM fbdev
>> emulation is enabled")
>> Reported-by: Arthur Grillo
>> Closes:
>> https://lore.kernel.org/dri-devel/20230726220325.278976-1-arthurgri...@riseup.net
>> Suggested-by: Arnd Bergmann
>> Signed-off-by: Javier Martinez Canillas
>
> Yeah originally this was just to help people not misconfigure their
> kernels and end up with a black screen. But select is really not a
> nice way to do that, imo we could drop the FB_CORE select too :-)
Droping the 'FB_CORE' select only works if we make FB_CORE user
visible and add a 'depends on' for it instead. Not sure this
is any better since this would only ever be used when either
CONFIG_FB or CONFIG_DRM_FBDEV_EMULATION is enabled.
Arnd
Re: [PATCH 1/2] drm/drm_file: fix use of uninitialized variable
On Fri, Aug 04, 2023 at 01:57:39PM +0300, Tomi Valkeinen wrote:
> smatch reports:
>
> drivers/gpu/drm/drm_file.c:967 drm_show_memory_stats() error: uninitialized
> symbol 'supported_status'.
>
> 'supported_status' is only set in one code path. I'm not familiar with
> the code to say if that path will always be ran in real life, but
> whether that is the case or not, I think it is good to initialize
> 'supported_status' to 0 to silence the warning (and possibly fix a bug).
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_file.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 883d83bc0e3d..cc06e1836bf5 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -924,7 +924,7 @@ void drm_show_memory_stats(struct drm_printer *p, struct
> drm_file *file)
> {
> struct drm_gem_object *obj;
> struct drm_memory_stats status = {};
> - enum drm_gem_object_status supported_status;
> + enum drm_gem_object_status supported_status = 0;
> int id;
>
> spin_lock(>table_lock);
>
--
Regards,
Laurent Pinchart
Re: Bug#1042753: nouveau bug in linux/6.1.38-2
On Friday, 4 August 2023 15:11:46 CEST Olaf Skibbe wrote: > (On the occasion a maybe silly question: am I right assuming that the > kernel has to be build on the machine we want to reproduce the bug on? > Otherwise it could use much faster hardware (running also bookworm).) If that is also an amd64 machine running Debian kernel 6.1.38-2, it should be fine to build the kernel on the faster machine. signature.asc Description: This is a digitally signed message part.
[Bug 217664] Laptop doesnt wake up from suspend mode.
https://bugzilla.kernel.org/show_bug.cgi?id=217664 Jose Roberto (colombo...@gmail.com) changed: What|Removed |Added CC||colombo...@gmail.com --- Comment #8 from Jose Roberto (colombo...@gmail.com) --- Hi, I am having the same problem. My laptop is Thinkpad T480 with intel gpu. I discovered that it suspends and wake-up properly with AC pluged. But it fails to wake-up in battery mode. OpenSuse Leap and Tumbleweed -> dead Debian 12-> dead Gentoo with kernel 6 -> dead I will try with gentoo kernel 5. Any ideas of how to debug this? -- 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 RFC v5 02/10] drm: Introduce solid fill DRM plane property
On Fri, Aug 4, 2023 at 3:27 PM Dmitry Baryshkov
wrote:
>
> On Fri, 28 Jul 2023 at 20:03, Jessica Zhang wrote:
> >
> > Document and add support for solid_fill property to drm_plane. In
> > addition, add support for setting and getting the values for solid_fill.
> >
> > To enable solid fill planes, userspace must assign a property blob to
> > the "solid_fill" plane property containing the following information:
> >
> > struct drm_mode_solid_fill {
> > u32 version;
> > u32 r, g, b;
> > };
> >
> > Signed-off-by: Jessica Zhang
> > ---
> > drivers/gpu/drm/drm_atomic_state_helper.c | 9 +
> > drivers/gpu/drm/drm_atomic_uapi.c | 55
> > +++
> > drivers/gpu/drm/drm_blend.c | 30 +
> > include/drm/drm_blend.h | 1 +
> > include/drm/drm_plane.h | 35
> > include/uapi/drm/drm_mode.h | 24 ++
> > 6 files changed, 154 insertions(+)
> >
>
> [skipped most of the patch]
>
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 43691058d28f..53c8efa5ad7f 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -259,6 +259,30 @@ struct drm_mode_modeinfo {
> > char name[DRM_DISPLAY_MODE_LEN];
> > };
> >
> > +/**
> > + * struct drm_mode_solid_fill - User info for solid fill planes
> > + *
> > + * This is the userspace API solid fill information structure.
> > + *
> > + * Userspace can enable solid fill planes by assigning the plane
> > "solid_fill"
> > + * property to a blob containing a single drm_mode_solid_fill struct
> > populated with an RGB323232
> > + * color and setting the pixel source to "SOLID_FILL".
> > + *
> > + * For information on the plane property, see
> > drm_plane_create_solid_fill_property()
> > + *
> > + * @version: Version of the blob. Currently, there is only support for
> > version == 1
> > + * @r: Red color value of single pixel
> > + * @g: Green color value of single pixel
> > + * @b: Blue color value of single pixel
> > + */
> > +struct drm_mode_solid_fill {
> > + __u32 version;
> > + __u32 r;
> > + __u32 g;
> > + __u32 b;
>
> Another thought about the drm_mode_solid_fill uABI. I still think we
> should add alpha here. The reason is the following:
>
> It is true that we have drm_plane_state::alpha and the plane's
> "alpha" property. However it is documented as "the plane-wide opacity
> [...] It can be combined with pixel alpha. The pixel values in the
> framebuffers are expected to not be pre-multiplied by the global alpha
> associated to the plane.".
>
> I can imagine a use case, when a user might want to enable plane-wide
> opacity, set "pixel blend mode" to "Coverage" and then switch between
> partially opaque framebuffer and partially opaque solid-fill without
> touching the plane's alpha value.
The only reason I see against this is that there might be some
hardware which supports only RGB but not alpha on planes and they
could then not use this property. Maybe another COLOR_FILL enum value
with alpha might be better? Maybe just doing the alpha via the alpha
property is good enough.
>
> --
> With best wishes
> Dmitry
>
Re: [PATCH RFC v5 02/10] drm: Introduce solid fill DRM plane property
On Mon, Jul 31, 2023 at 6:01 AM Dmitry Baryshkov
wrote:
>
> On 28/07/2023 20:02, Jessica Zhang wrote:
> > Document and add support for solid_fill property to drm_plane. In
> > addition, add support for setting and getting the values for solid_fill.
> >
> > To enable solid fill planes, userspace must assign a property blob to
> > the "solid_fill" plane property containing the following information:
> >
> > struct drm_mode_solid_fill {
> > u32 version;
> > u32 r, g, b;
> > };
> >
> > Signed-off-by: Jessica Zhang
> > ---
> > drivers/gpu/drm/drm_atomic_state_helper.c | 9 +
> > drivers/gpu/drm/drm_atomic_uapi.c | 55
> > +++
> > drivers/gpu/drm/drm_blend.c | 30 +
> > include/drm/drm_blend.h | 1 +
> > include/drm/drm_plane.h | 35
> > include/uapi/drm/drm_mode.h | 24 ++
> > 6 files changed, 154 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> > b/drivers/gpu/drm/drm_atomic_state_helper.c
> > index 01638c51ce0a..86fb876efbe6 100644
> > --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> > @@ -254,6 +254,11 @@ void __drm_atomic_helper_plane_state_reset(struct
> > drm_plane_state *plane_state,
> > plane_state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
> > plane_state->pixel_source = DRM_PLANE_PIXEL_SOURCE_FB;
> >
> > + if (plane_state->solid_fill_blob) {
> > + drm_property_blob_put(plane_state->solid_fill_blob);
> > + plane_state->solid_fill_blob = NULL;
> > + }
> > +
> > if (plane->color_encoding_property) {
> > if (!drm_object_property_get_default_value(>base,
> >
> > plane->color_encoding_property,
> > @@ -336,6 +341,9 @@ void __drm_atomic_helper_plane_duplicate_state(struct
> > drm_plane *plane,
> > if (state->fb)
> > drm_framebuffer_get(state->fb);
> >
> > + if (state->solid_fill_blob)
> > + drm_property_blob_get(state->solid_fill_blob);
> > +
> > state->fence = NULL;
> > state->commit = NULL;
> > state->fb_damage_clips = NULL;
> > @@ -385,6 +393,7 @@ void __drm_atomic_helper_plane_destroy_state(struct
> > drm_plane_state *state)
> > drm_crtc_commit_put(state->commit);
> >
> > drm_property_blob_put(state->fb_damage_clips);
> > + drm_property_blob_put(state->solid_fill_blob);
> > }
> > EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 454f980e16c9..039686c78c2a 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -316,6 +316,51 @@ drm_atomic_set_crtc_for_connector(struct
> > drm_connector_state *conn_state,
> > }
> > EXPORT_SYMBOL(drm_atomic_set_crtc_for_connector);
> >
> > +static int drm_atomic_set_solid_fill_prop(struct drm_plane_state *state,
> > + struct drm_property_blob *blob)
> > +{
> > + int blob_version;
> > +
> > + if (blob == state->solid_fill_blob)
> > + return 0;
> > +
> > + if (blob) {
> > + struct drm_mode_solid_fill *user_info = (struct
> > drm_mode_solid_fill *)blob->data;
> > +
> > + if (blob->length != sizeof(struct drm_mode_solid_fill)) {
> > + drm_dbg_atomic(state->plane->dev,
> > +"[PLANE:%d:%s] bad solid fill blob
> > length: %zu\n",
> > +state->plane->base.id,
> > state->plane->name,
> > +blob->length);
> > + return -EINVAL;
> > + }
> > +
> > + blob_version = user_info->version;
>
> I remember that we had versioning for quite some time. However it stroke
> me while reviewing that we do not a way to negotiate supported
> SOLID_FILL versions. However as we now have support for different
> pixel_source properties, maybe we can drop version completely. If at
> some point a driver needs to support different kind of SOLID_FILL
> property (consider v2), we can add new pixel source to the enum.
Agreed. Let's drop the versioning.
>
> > +
> > + /* Add more versions if necessary */
> > + if (blob_version == 1) {
> > + state->solid_fill.r = user_info->r;
> > + state->solid_fill.g = user_info->g;
> > + state->solid_fill.b = user_info->b;
> > + } else {
> > + drm_dbg_atomic(state->plane->dev,
> > +"[PLANE:%d:%s] unsupported solid fill
> > version (version=%d)\n",
> > +state->plane->base.id,
> > state->plane->name,
> > +
Re: [PATCH v2 3/4] drm/panel: sitronix-st7789v: add support for partial mode
On Fri, Aug 04, 2023 at 03:02:34PM +0200, Michael Riesch wrote:
> The ST7789V controller features support for the partial mode. Here,
> the area to be displayed can be restricted in one direction (by default,
> in vertical direction). This is useful for panels that are partially
> occluded by design. Add support for the partial mode.
>
> Signed-off-by: Michael Riesch
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7789v.c | 43
> --
> 1 file changed, 41 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
> index 0ded72ed2fcd..ebc9a3bd6db3 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
> @@ -118,6 +118,9 @@ struct st7789_panel_info {
> u32 bus_format;
> u32 bus_flags;
> bool invert_mode;
> + bool partial_mode;
> + u16 partial_start;
> + u16 partial_end;
> };
>
> struct st7789v {
> @@ -345,9 +348,14 @@ static enum drm_panel_orientation
> st7789v_get_orientation(struct drm_panel *p)
> static int st7789v_prepare(struct drm_panel *panel)
> {
> struct st7789v *ctx = panel_to_st7789v(panel);
> - u8 pixel_fmt, polarity;
> + u8 mode, pixel_fmt, polarity;
> int ret;
>
> + if (!ctx->info->partial_mode)
> + mode = ST7789V_RGBCTRL_WO;
> + else
> + mode = 0;
> +
> switch (ctx->info->bus_format) {
> case MEDIA_BUS_FMT_RGB666_1X18:
> pixel_fmt = MIPI_DCS_PIXEL_FMT_18BIT;
> @@ -487,6 +495,37 @@ static int st7789v_prepare(struct drm_panel *panel)
> MIPI_DCS_EXIT_INVERT_MODE));
> }
>
> + if (ctx->info->partial_mode) {
> + u8 area_data[4] = {
> + (ctx->info->partial_start >> 8) & 0xff,
> + (ctx->info->partial_start >> 0) & 0xff,
> + ((ctx->info->partial_end - 1) >> 8) & 0xff,
> + ((ctx->info->partial_end - 1) >> 0) & 0xff,
> + };
> +
> + /* Caution: if userspace ever pushes a mode different from the
> + * expected one (i.e., the one advertised by get_modes), we'll
> + * add margins.
> + */
The comment format is incorrect. Since Neil applied the patches already,
please send a patch to fix it.
Looks good to me otherwise, thanks for sticking up with this :)
Maxime
signature.asc
Description: PGP signature
[PATCH] drm/amdkfd: fix build failure without CONFIG_DYNAMIC_DEBUG
From: Arnd Bergmann
When CONFIG_DYNAMIC_DEBUG is disabled altogether, calling
_dynamic_func_call_no_desc() does not work:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c: In function
'svm_range_set_attr':
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:52:9: error: implicit
declaration of function '_dynamic_func_call_no_desc'
[-Werror=implicit-function-declaration]
52 | _dynamic_func_call_no_desc("svm_range_dump",
svm_range_debug_dump, svms)
| ^~
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:3564:9: note: in expansion of
macro 'dynamic_svm_range_dump'
3564 | dynamic_svm_range_dump(svms);
| ^~
Add a compile-time conditional in addition to the runtime check.
Fixes: 8923137dbe4b2 ("drm/amdkfd: avoid svm dump when dynamic debug disabled")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
index 308384dbc502d..44e710821b6d9 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
@@ -23,6 +23,7 @@
#include
#include
+#include
#include
#include
@@ -48,8 +49,13 @@
* page table is updated.
*/
#define AMDGPU_SVM_RANGE_RETRY_FAULT_PENDING (2UL * NSEC_PER_MSEC)
+#if IS_ENABLED(CONFIG_DYNAMIC_DEBUG)
#define dynamic_svm_range_dump(svms) \
_dynamic_func_call_no_desc("svm_range_dump", svm_range_debug_dump, svms)
+#else
+#define dynamic_svm_range_dump(svms) \
+ do { if (0) svm_range_debug_dump(svms); } while (0)
+#endif
/* Giant svm range split into smaller ranges based on this, it is decided using
* minimum of all dGPU/APU 1/32 VRAM size, between 2MB to 1GB and alignment to
--
2.39.2
Re: [PATCH v2 0/4] drm/panel: sitronix-st7789v: add support for partial mode
Hi, On Fri, 04 Aug 2023 15:02:31 +0200, Michael Riesch wrote: > This series adds support for the partial display mode to the Sitronix > ST7789V panel driver. This is useful for panels that are partially > occluded by design, such as the Jasonic JT240MHQS-HWT-EK-E3. Support > for this particular panel is added as well. > > Looking forward to your comments! > > [...] Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git (drm-misc-next) [1/4] dt-bindings: vendor-prefixes: add jasonic https://cgit.freedesktop.org/drm/drm-misc/commit/?id=c1e98bb9e69f49e16c34c1cb48bcb5b0f0cb064a [2/4] dt-bindings: display: st7789v: add jasonic jt240mhqs-hwt-ek-e3 display https://cgit.freedesktop.org/drm/drm-misc/commit/?id=a5382e358e56f3bef13aae3432bec906130b2074 [3/4] drm/panel: sitronix-st7789v: add support for partial mode https://cgit.freedesktop.org/drm/drm-misc/commit/?id=a82db60440c552b1def32ab33b642454490d850e [4/4] drm/panel: sitronix-st7789v: add jasonic jt240mhqs-hwt-ek-e3 support https://cgit.freedesktop.org/drm/drm-misc/commit/?id=0fbbe96bfa089c3758a7d1969ff34036d3f03d68 -- Neil
Re: [PATCH RFC v5 02/10] drm: Introduce solid fill DRM plane property
On Fri, 28 Jul 2023 at 20:03, Jessica Zhang wrote:
>
> Document and add support for solid_fill property to drm_plane. In
> addition, add support for setting and getting the values for solid_fill.
>
> To enable solid fill planes, userspace must assign a property blob to
> the "solid_fill" plane property containing the following information:
>
> struct drm_mode_solid_fill {
> u32 version;
> u32 r, g, b;
> };
>
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 9 +
> drivers/gpu/drm/drm_atomic_uapi.c | 55
> +++
> drivers/gpu/drm/drm_blend.c | 30 +
> include/drm/drm_blend.h | 1 +
> include/drm/drm_plane.h | 35
> include/uapi/drm/drm_mode.h | 24 ++
> 6 files changed, 154 insertions(+)
>
[skipped most of the patch]
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 43691058d28f..53c8efa5ad7f 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -259,6 +259,30 @@ struct drm_mode_modeinfo {
> char name[DRM_DISPLAY_MODE_LEN];
> };
>
> +/**
> + * struct drm_mode_solid_fill - User info for solid fill planes
> + *
> + * This is the userspace API solid fill information structure.
> + *
> + * Userspace can enable solid fill planes by assigning the plane "solid_fill"
> + * property to a blob containing a single drm_mode_solid_fill struct
> populated with an RGB323232
> + * color and setting the pixel source to "SOLID_FILL".
> + *
> + * For information on the plane property, see
> drm_plane_create_solid_fill_property()
> + *
> + * @version: Version of the blob. Currently, there is only support for
> version == 1
> + * @r: Red color value of single pixel
> + * @g: Green color value of single pixel
> + * @b: Blue color value of single pixel
> + */
> +struct drm_mode_solid_fill {
> + __u32 version;
> + __u32 r;
> + __u32 g;
> + __u32 b;
Another thought about the drm_mode_solid_fill uABI. I still think we
should add alpha here. The reason is the following:
It is true that we have drm_plane_state::alpha and the plane's
"alpha" property. However it is documented as "the plane-wide opacity
[...] It can be combined with pixel alpha. The pixel values in the
framebuffers are expected to not be pre-multiplied by the global alpha
associated to the plane.".
I can imagine a use case, when a user might want to enable plane-wide
opacity, set "pixel blend mode" to "Coverage" and then switch between
partially opaque framebuffer and partially opaque solid-fill without
touching the plane's alpha value.
--
With best wishes
Dmitry
Re: [PATCH] drm/msm/dpu: clean up some inconsistent indenting
On Fri, 4 Aug 2023 at 10:57, Jiapeng Chong wrote: > > No functional modification involved. > > drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c:183 dpu_core_perf_crtc_check() > warn: inconsistent indenting. > > Reported-by: Abaci Robot > Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=6096 > Signed-off-by: Jiapeng Chong > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH RFC v5 01/10] drm: Introduce pixel_source DRM plane property
On Fri, Jul 28, 2023 at 7:03 PM Jessica Zhang wrote:
>
> Add support for pixel_source property to drm_plane and related
> documentation. In addition, force pixel_source to
> DRM_PLANE_PIXEL_SOURCE_FB in DRM_IOCTL_MODE_SETPLANE as to not break
> legacy userspace.
>
> This enum property will allow user to specify a pixel source for the
> plane. Possible pixel sources will be defined in the
> drm_plane_pixel_source enum.
>
> The current possible pixel sources are DRM_PLANE_PIXEL_SOURCE_NONE and
> DRM_PLANE_PIXEL_SOURCE_FB with *_PIXEL_SOURCE_FB being the default value.
>
> Signed-off-by: Jessica Zhang
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 1 +
> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
> drivers/gpu/drm/drm_blend.c | 85
> +++
> drivers/gpu/drm/drm_plane.c | 3 ++
> include/drm/drm_blend.h | 2 +
> include/drm/drm_plane.h | 21
> 6 files changed, 116 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 784e63d70a42..01638c51ce0a 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -252,6 +252,7 @@ void __drm_atomic_helper_plane_state_reset(struct
> drm_plane_state *plane_state,
>
> plane_state->alpha = DRM_BLEND_ALPHA_OPAQUE;
> plane_state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
> + plane_state->pixel_source = DRM_PLANE_PIXEL_SOURCE_FB;
>
> if (plane->color_encoding_property) {
> if (!drm_object_property_get_default_value(>base,
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index d867e7f9f2cd..454f980e16c9 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -544,6 +544,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
> *plane,
> state->src_w = val;
> } else if (property == config->prop_src_h) {
> state->src_h = val;
> + } else if (property == plane->pixel_source_property) {
> + state->pixel_source = val;
> } else if (property == plane->alpha_property) {
> state->alpha = val;
> } else if (property == plane->blend_mode_property) {
> @@ -616,6 +618,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> *val = state->src_w;
> } else if (property == config->prop_src_h) {
> *val = state->src_h;
> + } else if (property == plane->pixel_source_property) {
> + *val = state->pixel_source;
> } else if (property == plane->alpha_property) {
> *val = state->alpha;
> } else if (property == plane->blend_mode_property) {
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index 6e74de833466..c500310a3d09 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -185,6 +185,21 @@
> * plane does not expose the "alpha" property, then this is
> * assumed to be 1.0
> *
> + * pixel_source:
> + * pixel_source is set up with drm_plane_create_pixel_source_property().
> + * It is used to toggle the active source of pixel data for the plane.
> + * The plane will only display data from the set pixel_source -- any
> + * data from other sources will be ignored.
> + *
> + * Possible values:
> + *
> + * "NONE":
> + * No active pixel source.
> + * Committing with a NONE pixel source will disable the plane.
> + *
> + * "FB":
> + * Framebuffer source set by the "FB_ID" property.
> + *
> * Note that all the property extensions described here apply either to the
> * plane or the CRTC (e.g. for the background color, which currently is not
> * exposed and assumed to be black).
> @@ -615,3 +630,73 @@ int drm_plane_create_blend_mode_property(struct
> drm_plane *plane,
> return 0;
> }
> EXPORT_SYMBOL(drm_plane_create_blend_mode_property);
> +
> +/**
> + * drm_plane_create_pixel_source_property - create a new pixel source
> property
> + * @plane: DRM plane
> + * @extra_sources: Bitmask of additional supported pixel_sources for the
> driver.
> + *DRM_PLANE_PIXEL_SOURCE_FB always be enabled as a supported
> + *source.
> + *
> + * This creates a new property describing the current source of pixel data
> for the
> + * plane. The pixel_source will be initialized as DRM_PLANE_PIXEL_SOURCE_FB
> by default.
> + *
> + * Drivers can set a custom default source by overriding the pixel_source
> value in
> + * drm_plane_funcs.reset()
> + *
> + * The property is exposed to userspace as an enumeration property called
> + * "pixel_source" and has the following enumeration values:
> + *
> + * "NONE":
> + * No active pixel source
> + *
> + * "FB":
> + * Framebuffer
Re: [PATCH v2] drm/msm/dpu: Drop encoder vsync_event
On Wed, 2 Aug 2023 at 20:01, Jessica Zhang wrote: > > Drop vsync_event and vsync_event_work handlers as they are unnecessary. > In addition drop the dpu_enc_ktime_template event class as it will be > unused after the vsync_event handlers are dropped. > > Signed-off-by: Jessica Zhang > --- > Changes in v2: > - Dropped dpu_enc_early_kickoff event and dpu_enc_ktime_template event class > - Link to v1: > https://lore.kernel.org/r/20230801-encoder-cleanup-v1-1-f9e37fe27...@quicinc.com > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 65 > + > drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 23 -- > 2 files changed, 1 insertion(+), 87 deletions(-) Reviewed-by: Dmitry Baryshkov -- With best wishes Dmitry
Re: [PATCH v2 4/4] drm/panel: sitronix-st7789v: add jasonic jt240mhqs-hwt-ek-e3 support
On 04/08/2023 15:02, Michael Riesch wrote:
The Jasonic JT240MHQS-HWT-EK-E3 is a custom panel using the Sitronix
ST7789V controller. While the controller features a resolution of
320x240, only an area of 280x240 is visible by design.
Signed-off-by: Michael Riesch
---
drivers/gpu/drm/panel/panel-sitronix-st7789v.c | 29 ++
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
index ebc9a3bd6db3..88e80fe98112 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
@@ -279,6 +279,21 @@ static const struct drm_display_mode et028013dma_mode = {
.flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
};
+static const struct drm_display_mode jt240mhqs_hwt_ek_e3_mode = {
+ .clock = 6000,
+ .hdisplay = 240,
+ .hsync_start = 240 + 28,
+ .hsync_end = 240 + 28 + 10,
+ .htotal = 240 + 28 + 10 + 10,
+ .vdisplay = 280,
+ .vsync_start = 280 + 8,
+ .vsync_end = 280 + 8 + 4,
+ .vtotal = 280 + 8 + 4 + 4,
+ .width_mm = 43,
+ .height_mm = 37,
+ .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
+};
+
static const struct st7789_panel_info default_panel = {
.mode = _mode,
.invert_mode = true,
@@ -303,6 +318,17 @@ static const struct st7789_panel_info et028013dma_panel = {
DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
};
+static const struct st7789_panel_info jt240mhqs_hwt_ek_e3_panel = {
+ .mode = _hwt_ek_e3_mode,
+ .invert_mode = true,
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH |
+DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
+ .partial_mode = true,
+ .partial_start = 38,
+ .partial_end = 318,
+};
+
static int st7789v_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
{
@@ -635,6 +661,7 @@ static const struct spi_device_id st7789v_spi_id[] = {
{ "st7789v", (unsigned long) _panel },
{ "t28cp45tn89-v17", (unsigned long) _panel },
{ "et028013dma", (unsigned long) _panel },
+ { "jt240mhqs-hwt-ek-e3", (unsigned long) _hwt_ek_e3_panel },
{ }
};
MODULE_DEVICE_TABLE(spi, st7789v_spi_id);
@@ -643,6 +670,8 @@ static const struct of_device_id st7789v_of_match[] = {
{ .compatible = "sitronix,st7789v", .data = _panel },
{ .compatible = "inanbo,t28cp45tn89-v17", .data = _panel },
{ .compatible = "edt,et028013dma", .data = _panel },
+ { .compatible = "jasonic,jt240mhqs-hwt-ek-e3",
+ .data = _hwt_ek_e3_panel },
{ }
};
MODULE_DEVICE_TABLE(of, st7789v_of_match);
Reviewed-by: Neil Armstrong
Re: [PATCH] drm: Drop select FRAMEBUFFER_CONSOLE for DRM_FBDEV_EMULATION
On Fri, 4 Aug 2023 at 14:52, Javier Martinez Canillas
wrote:
>
> The commit c242f48433e7 ("drm: Make FB_CORE to be selected if DRM fbdev
> emulation is enabled") changed DRM_FBDEV_EMULATION from 'depends on FB'
> to an effective 'select FB_CORE', so any config that previously had DRM=y
> and FB=n now has FB_CORE=y and FRAMEBUFFER_CONSOLE=y.
>
> This leads to unmet direct dependencies detected for FRAMEBUFFER_CONSOLE
> as reported by Arthur Grillo, e.g:
>
> WARNING: unmet direct dependencies detected for FRAMEBUFFER_CONSOLE
> Depends on [n]: VT [=n] && FB_CORE [=y] && !UML [=y]
> Selected by [y]:
> - DRM_FBDEV_EMULATION [=y] && HAS_IOMEM [=y] && DRM [=y] && !EXPERT [=n]
>
> Arnd Bergmann suggests to drop the select FRAMEBUFFER_CONSOLE for the
> DRM_FBDEV_EMULATION Kconfig symbol, since a possible use case could
> be to enable DRM fbdev emulation but without a framebuffer console.
>
> Fixes: c242f48433e7 ("drm: Make FB_CORE to be selected if DRM fbdev emulation
> is enabled")
> Reported-by: Arthur Grillo
> Closes:
> https://lore.kernel.org/dri-devel/20230726220325.278976-1-arthurgri...@riseup.net
> Suggested-by: Arnd Bergmann
> Signed-off-by: Javier Martinez Canillas
Yeah originally this was just to help people not misconfigure their
kernels and end up with a black screen. But select is really not a
nice way to do that, imo we could drop the FB_CORE select too :-)
Acked-by: Daniel Vetter
Cheers, Sima
> ---
>
> drivers/gpu/drm/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index b51c6a141dfa..2a44b9419d4d 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -135,7 +135,6 @@ config DRM_DEBUG_MODESET_LOCK
> config DRM_FBDEV_EMULATION
> bool "Enable legacy fbdev support for your modesetting driver"
> depends on DRM
> - select FRAMEBUFFER_CONSOLE if !EXPERT
> select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
> default y
> help
> --
> 2.41.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v2 3/4] drm/panel: sitronix-st7789v: add support for partial mode
On 04/08/2023 15:02, Michael Riesch wrote:
The ST7789V controller features support for the partial mode. Here,
the area to be displayed can be restricted in one direction (by default,
in vertical direction). This is useful for panels that are partially
occluded by design. Add support for the partial mode.
Signed-off-by: Michael Riesch
---
drivers/gpu/drm/panel/panel-sitronix-st7789v.c | 43 --
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
index 0ded72ed2fcd..ebc9a3bd6db3 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c
@@ -118,6 +118,9 @@ struct st7789_panel_info {
u32 bus_format;
u32 bus_flags;
bool invert_mode;
+ bool partial_mode;
+ u16 partial_start;
+ u16 partial_end;
};
struct st7789v {
@@ -345,9 +348,14 @@ static enum drm_panel_orientation
st7789v_get_orientation(struct drm_panel *p)
static int st7789v_prepare(struct drm_panel *panel)
{
struct st7789v *ctx = panel_to_st7789v(panel);
- u8 pixel_fmt, polarity;
+ u8 mode, pixel_fmt, polarity;
int ret;
+ if (!ctx->info->partial_mode)
+ mode = ST7789V_RGBCTRL_WO;
+ else
+ mode = 0;
+
switch (ctx->info->bus_format) {
case MEDIA_BUS_FMT_RGB666_1X18:
pixel_fmt = MIPI_DCS_PIXEL_FMT_18BIT;
@@ -487,6 +495,37 @@ static int st7789v_prepare(struct drm_panel *panel)
MIPI_DCS_EXIT_INVERT_MODE));
}
+ if (ctx->info->partial_mode) {
+ u8 area_data[4] = {
+ (ctx->info->partial_start >> 8) & 0xff,
+ (ctx->info->partial_start >> 0) & 0xff,
+ ((ctx->info->partial_end - 1) >> 8) & 0xff,
+ ((ctx->info->partial_end - 1) >> 0) & 0xff,
+ };
+
+ /* Caution: if userspace ever pushes a mode different from the
+* expected one (i.e., the one advertised by get_modes), we'll
+* add margins.
+*/
+
+ ST7789V_TEST(ret, st7789v_write_command(
+ ctx, MIPI_DCS_ENTER_PARTIAL_MODE));
+
+ ST7789V_TEST(ret, st7789v_write_command(
+ ctx, MIPI_DCS_SET_PAGE_ADDRESS));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, area_data[0]));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, area_data[1]));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, area_data[2]));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, area_data[3]));
+
+ ST7789V_TEST(ret, st7789v_write_command(
+ ctx, MIPI_DCS_SET_PARTIAL_ROWS));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, area_data[0]));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, area_data[1]));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, area_data[2]));
+ ST7789V_TEST(ret, st7789v_write_data(ctx, area_data[3]));
+ }
+
ST7789V_TEST(ret, st7789v_write_command(ctx, ST7789V_RAMCTRL_CMD));
ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_RAMCTRL_DM_RGB |
ST7789V_RAMCTRL_RM_RGB));
@@ -494,7 +533,7 @@ static int st7789v_prepare(struct drm_panel *panel)
ST7789V_RAMCTRL_MAGIC));
ST7789V_TEST(ret, st7789v_write_command(ctx, ST7789V_RGBCTRL_CMD));
- ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_RGBCTRL_WO |
+ ST7789V_TEST(ret, st7789v_write_data(ctx, mode |
ST7789V_RGBCTRL_RCM(2) |
polarity));
ST7789V_TEST(ret, st7789v_write_data(ctx, ST7789V_RGBCTRL_VBP(8)));
Reviewed-by: Neil Armstrong
Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations
On Tue, Jun 27, 2023 at 10:23:23AM -0300, André Almeida wrote: > Create a section that specifies how to deal with DRM device resets for > kernel and userspace drivers. > > Acked-by: Pekka Paalanen > Signed-off-by: André Almeida > --- > > v4: > https://lore.kernel.org/lkml/20230626183347.55118-1-andrealm...@igalia.com/ > > Changes: > - Grammar fixes (Randy) > > Documentation/gpu/drm-uapi.rst | 68 ++ > 1 file changed, 68 insertions(+) > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst > index 65fb3036a580..3cbffa25ed93 100644 > --- a/Documentation/gpu/drm-uapi.rst > +++ b/Documentation/gpu/drm-uapi.rst > @@ -285,6 +285,74 @@ for GPU1 and GPU2 from different vendors, and a third > handler for > mmapped regular files. Threads cause additional pain with signal > handling as well. > > +Device reset > + > + > +The GPU stack is really complex and is prone to errors, from hardware bugs, > +faulty applications and everything in between the many layers. Some errors > +require resetting the device in order to make the device usable again. This > +sections describes the expectations for DRM and usermode drivers when a > +device resets and how to propagate the reset status. > + > +Kernel Mode Driver > +-- > + > +The KMD is responsible for checking if the device needs a reset, and to > perform > +it as needed. Usually a hang is detected when a job gets stuck executing. KMD > +should keep track of resets, because userspace can query any time about the > +reset stats for an specific context. This is needed to propagate to the rest > of > +the stack that a reset has happened. Currently, this is implemented by each > +driver separately, with no common DRM interface. > + > +User Mode Driver > + > + > +The UMD should check before submitting new commands to the KMD if the device > has > +been reset, and this can be checked more often if the UMD requires it. After > +detecting a reset, UMD will then proceed to report it to the application > using > +the appropriate API error code, as explained in the section below about > +robustness. > + > +Robustness > +-- > + > +The only way to try to keep an application working after a reset is if it > +complies with the robustness aspects of the graphical API that it is using. > + > +Graphical APIs provide ways to applications to deal with device resets. > However, > +there is no guarantee that the app will use such features correctly, and the > +UMD can implement policies to close the app if it is a repeating offender, Not sure whether this one here is due to my input, but s/UMD/KMD. Repeat offender killing is more a policy where the kernel enforces policy, and no longer up to userspace to dtrt (because very clearly userspace is not really doing the right thing anymore when it's just hanging the gpu in an endless loop). Also maybe tune it down further to something like "the kernel driver may implemnent ..." In my opinion the umd shouldn't implement these kind of magic guesses, the entire point of robustness apis is to delegate responsibility for correctly recovering to the application. And the kernel is left with enforcing fair resource usage policies (which eventually might be a cgroups limit on how much gpu time you're allowed to waste with gpu resets). > +likely in a broken loop. This is done to ensure that it does not keep > blocking > +the user interface from being correctly displayed. This should be done even > if > +the app is correct but happens to trigger some bug in the hardware/driver. > + > +OpenGL > +~~ > + > +Apps using OpenGL should use the available robust interfaces, like the > +extension ``GL_ARB_robustness`` (or ``GL_EXT_robustness`` for OpenGL ES). > This > +interface tells if a reset has happened, and if so, all the context state is > +considered lost and the app proceeds by creating new ones. If it is possible > to > +determine that robustness is not in use, the UMD will terminate the app when > a > +reset is detected, giving that the contexts are lost and the app won't be > able > +to figure this out and recreate the contexts. > + > +Vulkan > +~~ > + > +Apps using Vulkan should check for ``VK_ERROR_DEVICE_LOST`` for submissions. > +This error code means, among other things, that a device reset has happened > and > +it needs to recreate the contexts to keep going. > + > +Reporting causes of resets > +-- > + > +Apart from propagating the reset through the stack so apps can recover, it's > +really useful for driver developers to learn more about what caused the > reset in > +first place. DRM devices should make use of devcoredump to store relevant > +information about the reset, so this information can be added to user bug > +reports. Since we do not seem to have a solid consensus in the community about non-robust userspace, maybe we could just document that lack of consensus to unblock this
[PATCH v2 2/4] dt-bindings: display: st7789v: add jasonic jt240mhqs-hwt-ek-e3 display
Add compatible for the Jasonic Technology Ltd. JT240MHQS-HWT-EK-E3 display. Acked-by: Conor Dooley Signed-off-by: Michael Riesch --- Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml index 0da4c7e05097..ef162b51d010 100644 --- a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml @@ -18,6 +18,7 @@ properties: enum: - edt,et028013dma - inanbo,t28cp45tn89-v17 + - jasonic,jt240mhqs-hwt-ek-e3 - sitronix,st7789v reg: true -- 2.37.2
