Re: [v11 3/7] iio: core: Add new DMABUF interface infrastructure
On 20-06-24, 18:05, Lee Jones wrote: > On Thu, 20 Jun 2024, Vinod Koul wrote: > > > On 20-06-24, 12:45, Markus Elfring wrote: > > > … > > > > All errors (new ones prefixed by >>): > > > > > > > >>> drivers/iio/industrialio-buffer.c:1715:3: error: cannot jump from > > > >>> this goto statement to its label > > > > 1715 | goto err_dmabuf_unmap_attachment; > > > … > > > > > > Which software design options would you like to try out next > > > so that such a questionable compilation error message will be avoided > > > finally? > > > > The one where all emails from Markus go to dev/null > > Play nice please. Would love to... but Markus has been repeat offender Sadly, I am yet to see a constructive approach or even better a helpful patch which improve something, rather than vague suggestions on the list -- ~Vinod
[PATCH] drm/qxl: Add check for drm_cvt_mode
Add check for the return value of drm_cvt_mode() and return the error if
it fails in order to avoid NULL pointer dereference.
Fixes: 1b043677d4be ("drm/qxl: add qxl_add_mode helper function")
Signed-off-by: Chen Ni
---
drivers/gpu/drm/qxl/qxl_display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index c6d35c33d5d6..86a5dea710c0 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -236,6 +236,9 @@ static int qxl_add_mode(struct drm_connector *connector,
return 0;
mode = drm_cvt_mode(dev, width, height, 60, false, false, false);
+ if (!mode)
+ return 0;
+
if (preferred)
mode->type |= DRM_MODE_TYPE_PREFERRED;
mode->hdisplay = width;
--
2.25.1
Re: [v11 3/7] iio: core: Add new DMABUF interface infrastructure
On Fri, 2024-06-21 at 12:39 +0530, Vinod Koul wrote: > On 20-06-24, 18:05, Lee Jones wrote: > > On Thu, 20 Jun 2024, Vinod Koul wrote: > > > > > On 20-06-24, 12:45, Markus Elfring wrote: > > > > … > > > > > All errors (new ones prefixed by >>): > > > > > > > > > > > > drivers/iio/industrialio-buffer.c:1715:3: error: cannot jump from > > > > > > > this goto statement to its label > > > > > 1715 | goto err_dmabuf_unmap_attachment; > > > > … > > > > > > > > Which software design options would you like to try out next > > > > so that such a questionable compilation error message will be avoided > > > > finally? > > > > > > The one where all emails from Markus go to dev/null > > > > Play nice please. > > Would love to... but Markus has been repeat offender > > Sadly, I am yet to see a constructive approach or even better a helpful > patch which improve something, rather than vague suggestions on the list > Yeah, just look at how many automatic replies he get's from Greg pretty much saying to ignore his comments. - Nuno Sá
[PATCH v1 1/1] drm/xe/bo: Fix fixed placement ggtt pinning code
When calling xe_bo_create_pin_map_at, use the correct
starting offset provided by caller at xe_ggtt_insert_bo_at.
Fixes: 44e694958b95 ("drm/xe/display: Implement display support")
Signed-off-by: Alan Previn
---
drivers/gpu/drm/xe/xe_bo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
index 74294f1b05bc..cc6101b49c08 100644
--- a/drivers/gpu/drm/xe/xe_bo.c
+++ b/drivers/gpu/drm/xe/xe_bo.c
@@ -1436,7 +1436,7 @@ __xe_bo_create_locked(struct xe_device *xe,
if (flags & XE_BO_FLAG_FIXED_PLACEMENT) {
err = xe_ggtt_insert_bo_at(tile->mem.ggtt, bo,
- start + bo->size, U64_MAX);
+ start, end);
} else {
err = xe_ggtt_insert_bo(tile->mem.ggtt, bo);
}
base-commit: cffd77865f476994680892601e09bc2164179907
--
2.34.1
[PATCH v1 1/1] drm/xe/bo: Fix fixed placement ggtt pinning code
When calling xe_bo_create_pin_map_at, use the correct
starting offset provided by caller at xe_ggtt_insert_bo_at.
Fixes: 44e694958b95 ("drm/xe/display: Implement display support")
Signed-off-by: Alan Previn
---
drivers/gpu/drm/xe/xe_bo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
index 74294f1b05bc..cc6101b49c08 100644
--- a/drivers/gpu/drm/xe/xe_bo.c
+++ b/drivers/gpu/drm/xe/xe_bo.c
@@ -1436,7 +1436,7 @@ __xe_bo_create_locked(struct xe_device *xe,
if (flags & XE_BO_FLAG_FIXED_PLACEMENT) {
err = xe_ggtt_insert_bo_at(tile->mem.ggtt, bo,
- start + bo->size, U64_MAX);
+ start, end);
} else {
err = xe_ggtt_insert_bo(tile->mem.ggtt, bo);
}
base-commit: cffd77865f476994680892601e09bc2164179907
--
2.34.1
Re: [PATCH] drm/radeon: remove load callback
Hi Am 20.06.24 um 16:30 schrieb Hoi Pok Wu: Dear Thomas, Thank you for testing my patch. The dev->dev_private is indeed the problem. However, most of the functions that uses dev->dev_private is passing drm_device as parameter, and then uses dev->dev_private to retrieve radeon_device, contradicting what the patch intended. It should use radeon_device directly. Should I send a follow up patch with the updated patch? Simply assign the radeon_device to dev_private as before and you'll be fine. Reworking all function calls would be a patchset of its own. Best regards Thomas Thank you. Best Regards Wu On Wed, Jun 19, 2024 at 10:28 AM Thomas Zimmermann wrote: Hi Am 07.06.24 um 03:14 schrieb wu hoi pok: this patch is to remove the load callback from the kms_driver, following closly to amdgpu, radeon_driver_load_kms and devm_drm_dev_alloc are used, most of the changes here are rdev->ddev to rdev_to_drm, which maps to adev_to_drm in amdgpu. however this patch is not tested on hardware, so if you are free and have a gcn1 gcn2 card please do so. Signed-off-by: wu hoi pok I volunteer for testing. The test device is 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Turks PRO [Radeon HD 6570/7570/8550 / R5 230] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited / Sapphire Technology Device e193 Flags: bus master, fast devsel, latency 0, IRQ 147 Memory at c000 (64-bit, prefetchable) [size=256M] Memory at dfe2 (64-bit, non-prefetchable) [size=128K] I/O ports at e000 [size=256] Expansion ROM at 000c [disabled] [size=128K] Capabilities: Kernel driver in use: radeon Kernel modules: radeon, amdgpu With the current patch, the driver crashes upon booting. Here is your backtrace: [ 24.013524] Console: switching to colour dummy device 80x25 [ 24.021093] radeon :01:00.0: vgaarb: deactivate vga console [ 24.031806] [drm] initializing kernel modesetting (TURKS 0x1002:0x6759 0x174B:0xE193 0x00). [ 24.041066] ATOM BIOS: YODA [ 24.043930] == [ 24.051195] BUG: KASAN: user-memory-access in radeon_atom_initialize_bios_scratch_regs+0x33/0x110 [radeon] [ 24.061287] Read of size 4 at addr 1058 by task (udev-worker)/349 [ 24.061292] [ 24.061295] CPU: 3 PID: 349 Comm: (udev-worker) Tainted: G U E 6.10.0-rc4-1-default+ #2977 [ 24.061301] Hardware name: System manufacturer System Product Name/Z170-A, BIOS 3802 03/15/2018 [ 24.061305] Call Trace: [ OK 24.061308] [ 24.061313] dump_stack_lvl+0x68/0x90 [ 24.061322] ? radeon_atom_initialize_bios_scratch_regs+0x33/0x110 [radeon] 0m] Finished24.105026] kasan_report+0xcf/0x1a0 [ 24.105039] ? radeon_atom_initialize_bios_scratch_regs+0x33/0x110 [radeon] ;1;39mCreate Vol[ 24.117055] ? __pfx_cail_ioreg_read+0x10/0x10 [radeon] atile Files and [ 24.123698] radeon_atom_initialize_bios_scratch_regs+0x33/0x110 [radeon] Directories.[ 24.131933] radeon_atombios_init+0x192/0x220 [radeon] [ 24.138506] evergreen_init+0x57/0x400 [radeon] [ 24.143473] radeon_device_init+0x8f2/0x1040 [radeon] [ 24.148897] ? down_read_failed+0x7/0x410 [ 24.152936] ? ksm_might_need_to_copy+0x10/0x280 [ 24.157594] radeon_driver_load_kms+0xe3/0x330 [radeon] [ 24.163198] radeon_pci_probe+0x117/0x180 [radeon] [ 24.168431] ? __pfx_radeon_pci_probe+0x10/0x10 [radeon] [ 24.174161] local_pci_probe+0x74/0xc0 [ 24.177945] pci_call_probe+0xc6/0x260 [ 24.181727] ? __pfx_pci_call_probe+0x10/0x10 [ 24.186118] ? do_raw_spin_trylock+0xb0/0xf0 [ 24.190439] ? pci_match_device+0x1c5/0x240 [ 24.194651] ? pci_match_id+0x102/0x150 [ 24.198522] ? pci_match_device+0x1dd/0x240 [ 24.202752] pci_device_probe+0x9d/0x150 [ 24.206705] ? driver_sysfs_add+0xb0/0x130 [ 24.210838] really_probe+0x13b/0x490 [ 24.214547] __driver_probe_device+0xca/0x1b0 [ 24.218943] driver_probe_device+0x4a/0xf0 [ 24.223073] __driver_attach+0x136/0x290 [ 24.227032] ? __pfx___driver_attach+0x10/0x10 [ 24.231508] bus_for_each_dev+0xc0/0x110 [ 24.235465] ? __pfx_bus_for_each_dev+0x10/0x10 [ 24.240032] ? bus_add_driver+0x17a/0x2b0 [ 24.244079] bus_add_driver+0x19a/0x2b0 [ 24.247950] driver_register+0xc5/0x140 [ 24.251817] ? __pfx_radeon_module_init+0x10/0x10 [radeon] [ 24.257674] do_one_initcall+0xbc/0x390 [ 24.261542] ? __pfx_do_one_initcall+0x10/0x10 [ 24.266022] ? kasan_unpoison+0x40/0x70 [ 24.269891] ? rcu_is_watching+0x34/0x60 [ 24.273849] ? kmalloc_trace_noprof+0x286/0x320 [ 24.278415] ? do_init_module+0x38/0x3a0 [ 24.282387] ? kasan_unpoison+0x40/0x70 [ 24.286264] do_init_module+0x13a/0x3a0 [ 24.290133] init_module_from_file+0xc0/0x100 [ 24.294523] ? __pfx_init_module_from_file+0x10/0x10 [ 24.299522] ? __lock_release.isra.0+0x132/0x4f0 [ 24.304185] ? do_raw_spin_unlock+0x83/0xe0 [
Re: [PATCH v8 14/16] drm/mediatek: Support CRC in display driver
Re: [v11 3/7] iio: core: Add new DMABUF interface infrastructure
> Sadly, I am yet to see a constructive approach or even better a helpful > patch which improve something, rather than vague suggestions on the list Can you get any more constructive impressions from another data representation? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=author&q=Elfring Are you aware how many change suggestions (also from my selection) are still in various waiting queues? Regards, Markus
Re: [PATCH] drm/radeon: remove load callback
Am 21.06.24 um 09:16 schrieb Thomas Zimmermann: Hi Am 20.06.24 um 16:30 schrieb Hoi Pok Wu: Dear Thomas, Thank you for testing my patch. The dev->dev_private is indeed the problem. However, most of the functions that uses dev->dev_private is passing drm_device as parameter, and then uses dev->dev_private to retrieve radeon_device, contradicting what the patch intended. It should use radeon_device directly. Should I send a follow up patch with the updated patch? Simply assign the radeon_device to dev_private as before and you'll be fine. Reworking all function calls would be a patchset of its own. Yeah, completely agree. Try to keep it as simply and stupid as possible for now, more extensive cleanups can come later. And thanks a lot for looking into this and testing the stuff. Regards, Christian. Best regards Thomas Thank you. Best Regards Wu On Wed, Jun 19, 2024 at 10:28 AM Thomas Zimmermann wrote: Hi Am 07.06.24 um 03:14 schrieb wu hoi pok: this patch is to remove the load callback from the kms_driver, following closly to amdgpu, radeon_driver_load_kms and devm_drm_dev_alloc are used, most of the changes here are rdev->ddev to rdev_to_drm, which maps to adev_to_drm in amdgpu. however this patch is not tested on hardware, so if you are free and have a gcn1 gcn2 card please do so. Signed-off-by: wu hoi pok I volunteer for testing. The test device is 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Turks PRO [Radeon HD 6570/7570/8550 / R5 230] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited / Sapphire Technology Device e193 Flags: bus master, fast devsel, latency 0, IRQ 147 Memory at c000 (64-bit, prefetchable) [size=256M] Memory at dfe2 (64-bit, non-prefetchable) [size=128K] I/O ports at e000 [size=256] Expansion ROM at 000c [disabled] [size=128K] Capabilities: Kernel driver in use: radeon Kernel modules: radeon, amdgpu With the current patch, the driver crashes upon booting. Here is your backtrace: [ 24.013524] Console: switching to colour dummy device 80x25 [ 24.021093] radeon :01:00.0: vgaarb: deactivate vga console [ 24.031806] [drm] initializing kernel modesetting (TURKS 0x1002:0x6759 0x174B:0xE193 0x00). [ 24.041066] ATOM BIOS: YODA [ 24.043930] == [ 24.051195] BUG: KASAN: user-memory-access in radeon_atom_initialize_bios_scratch_regs+0x33/0x110 [radeon] [ 24.061287] Read of size 4 at addr 1058 by task (udev-worker)/349 [ 24.061292] [ 24.061295] CPU: 3 PID: 349 Comm: (udev-worker) Tainted: G U E 6.10.0-rc4-1-default+ #2977 [ 24.061301] Hardware name: System manufacturer System Product Name/Z170-A, BIOS 3802 03/15/2018 [ 24.061305] Call Trace: [ OK 24.061308] [ 24.061313] dump_stack_lvl+0x68/0x90 [ 24.061322] ? radeon_atom_initialize_bios_scratch_regs+0x33/0x110 [radeon] 0m] Finished 24.105026] kasan_report+0xcf/0x1a0 [ 24.105039] ? radeon_atom_initialize_bios_scratch_regs+0x33/0x110 [radeon] ;1;39mCreate Vol[ 24.117055] ? __pfx_cail_ioreg_read+0x10/0x10 [radeon] atile Files and [ 24.123698] radeon_atom_initialize_bios_scratch_regs+0x33/0x110 [radeon] Directories.[ 24.131933] radeon_atombios_init+0x192/0x220 [radeon] [ 24.138506] evergreen_init+0x57/0x400 [radeon] [ 24.143473] radeon_device_init+0x8f2/0x1040 [radeon] [ 24.148897] ? down_read_failed+0x7/0x410 [ 24.152936] ? ksm_might_need_to_copy+0x10/0x280 [ 24.157594] radeon_driver_load_kms+0xe3/0x330 [radeon] [ 24.163198] radeon_pci_probe+0x117/0x180 [radeon] [ 24.168431] ? __pfx_radeon_pci_probe+0x10/0x10 [radeon] [ 24.174161] local_pci_probe+0x74/0xc0 [ 24.177945] pci_call_probe+0xc6/0x260 [ 24.181727] ? __pfx_pci_call_probe+0x10/0x10 [ 24.186118] ? do_raw_spin_trylock+0xb0/0xf0 [ 24.190439] ? pci_match_device+0x1c5/0x240 [ 24.194651] ? pci_match_id+0x102/0x150 [ 24.198522] ? pci_match_device+0x1dd/0x240 [ 24.202752] pci_device_probe+0x9d/0x150 [ 24.206705] ? driver_sysfs_add+0xb0/0x130 [ 24.210838] really_probe+0x13b/0x490 [ 24.214547] __driver_probe_device+0xca/0x1b0 [ 24.218943] driver_probe_device+0x4a/0xf0 [ 24.223073] __driver_attach+0x136/0x290 [ 24.227032] ? __pfx___driver_attach+0x10/0x10 [ 24.231508] bus_for_each_dev+0xc0/0x110 [ 24.235465] ? __pfx_bus_for_each_dev+0x10/0x10 [ 24.240032] ? bus_add_driver+0x17a/0x2b0 [ 24.244079] bus_add_driver+0x19a/0x2b0 [ 24.247950] driver_register+0xc5/0x140 [ 24.251817] ? __pfx_radeon_module_init+0x10/0x10 [radeon] [ 24.257674] do_one_initcall+0xbc/0x390 [ 24.261542] ? __pfx_do_one_initcall+0x10/0x10 [ 24.266022] ? kasan_unpoison+0x40/0x70 [ 24.269891] ? rcu_is_watching+0x34/0x60 [ 24.273849] ? kmalloc_trace_noprof+0x286/0x320 [ 24.278415] ? do_init_module+0x38/0x3a0 [ 24.282387] ?
Re: [PATCH 1/2] drm/amdgpu: Unmap BO memory before calling amdgpu_bo_unref()
Hi
Am 20.06.24 um 17:50 schrieb Christian König:
Am 20.06.24 um 16:44 schrieb Thomas Zimmermann:
Prepares for using ttm_bo_vmap() and ttm_bo_vunmap() in amdgpu. Both
require the caller to hold the GEM reservation lock, which is not the
case while releasing a buffer object. Hence, push a possible call to
unmap out from the buffer-object release code. Warn if a buffer object
with mapped pages is supposed to be released.
Yeah, I've looked into this a while ago as well and that unfortunately
won't work like this.
Amdgpu also uses ttm_bo_kmap() on user allocations, so the
amdgpu_bo_kunmap() in amdgpu_bo_destroy() is a must have.
Is there a testcase (igt-gpu-tools ?) that runs this code? I've tested
these patches by booting and running a 3d game under X11. But I didn't
expect that to fully cover all cases.
Best regards
Thomas
On the other hand I'm pretty sure that calling ttm_bo_vunmap() without
holding the reservation lock is ok in this situation.
After all it's guaranteed that nobody else is having a reference to
the BO any more.
Regards,
Christian.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index a1b7438c43dc8..d58b11ea0ead5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -58,7 +58,12 @@ static void amdgpu_bo_destroy(struct
ttm_buffer_object *tbo)
{
struct amdgpu_bo *bo = ttm_to_amdgpu_bo(tbo);
- amdgpu_bo_kunmap(bo);
+ /*
+ * BO memory pages should be unmapped at this point. Call
+ * amdgpu_bo_kunmap() before releasing the BO.
+ */
+ if (drm_WARN_ON_ONCE(bo->tbo.base.dev, bo->kmap.bo))
+ amdgpu_bo_kunmap(bo);
if (bo->tbo.base.import_attach)
drm_prime_gem_destroy(&bo->tbo.base, bo->tbo.sg);
@@ -450,9 +455,7 @@ void amdgpu_bo_free_kernel(struct amdgpu_bo **bo,
u64 *gpu_addr,
WARN_ON(amdgpu_ttm_adev((*bo)->tbo.bdev)->in_suspend);
if (likely(amdgpu_bo_reserve(*bo, true) == 0)) {
- if (cpu_addr)
- amdgpu_bo_kunmap(*bo);
-
+ amdgpu_bo_kunmap(*bo);
amdgpu_bo_unpin(*bo);
amdgpu_bo_unreserve(*bo);
}
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
Re: [v11 3/7] iio: core: Add new DMABUF interface infrastructure
> Yeah, just look at how many automatic replies he get's from Greg pretty much > saying to ignore his comments. Does your feedback just indicate recurring communication difficulties? Regards, Markus
Re: [v11 3/7] iio: core: Add new DMABUF interface infrastructure
On Fri, 21 Jun 2024, Nuno Sá wrote: > On Fri, 2024-06-21 at 12:39 +0530, Vinod Koul wrote: > > On 20-06-24, 18:05, Lee Jones wrote: > > > On Thu, 20 Jun 2024, Vinod Koul wrote: > > > > > > > On 20-06-24, 12:45, Markus Elfring wrote: > > > > > … > > > > > > All errors (new ones prefixed by >>): > > > > > > > > > > > > > > drivers/iio/industrialio-buffer.c:1715:3: error: cannot jump > > > > > > > > from > > > > > > > > this goto statement to its label > > > > > > 1715 | goto err_dmabuf_unmap_attachment; > > > > > … > > > > > > > > > > Which software design options would you like to try out next > > > > > so that such a questionable compilation error message will be avoided > > > > > finally? > > > > > > > > The one where all emails from Markus go to dev/null > > > > > > Play nice please. > > > > Would love to... but Markus has been repeat offender > > > > Sadly, I am yet to see a constructive approach or even better a helpful > > patch which improve something, rather than vague suggestions on the list Right, there are communication issues. Doesn't mean we have to lower our own standards. > Yeah, just look at how many automatic replies he get's from Greg pretty much > saying to ignore his comments. Yes, Greg is also grumpy about it, but at least he remains polite. -- Lee Jones [李琼斯]
Re: [v11 3/7] iio: core: Add new DMABUF interface infrastructure
On Fri, 21 Jun 2024, Markus Elfring wrote: > > Sadly, I am yet to see a constructive approach or even better a helpful > > patch which improve something, rather than vague suggestions on the list > > Can you get any more constructive impressions from another data > representation? > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=author&q=Elfring > > Are you aware how many change suggestions (also from my selection) are still > in various waiting queues? No one is doubting your overall contributions Markus. The issue is one of communication and the way reviews are conducted. Reviewing other people's work is challenging and requires a certain skill-set, of which _excellent_ communication skills are non-negotiable. Why not concentrate on more complex submissions for a while and grow your repertoire of common review points, rather than repeating the same few over and over? Reading other, more experienced maintainer's reviews would also be a good use of your time. -- Lee Jones [李琼斯]
Re: 6.10/bisected/regression - commits bc87d666c05 and 6d4279cb99ac cause appearing green flashing bar on top of screen on Radeon 6900XT and 120Hz
On 09.06.24 23:19, Mikhail Gavrilov wrote: > On Fri, Jun 7, 2024 at 6:39 PM Alex Deucher wrote: >> >> --- a/drivers/gpu/drm/amd/display/dc/optc/dcn10/dcn10_optc.c >> +++ b/drivers/gpu/drm/amd/display/dc/optc/dcn10/dcn10_optc.c >> @@ -944,7 +944,7 @@ void optc1_set_drr( >> OTG_V_TOTAL_MAX_SEL, 1, >> OTG_FORCE_LOCK_ON_EVENT, 0, >> OTG_SET_V_TOTAL_MIN_MASK_EN, 0, >> - OTG_SET_V_TOTAL_MIN_MASK, 0); >> + OTG_SET_V_TOTAL_MIN_MASK, (1 << 1)); /* >> TRIGA */ >> >> // Setup manual flow control for EOF via TRIG_A >> optc->funcs->setup_manual_trigger(optc); > > Thanks, Alex. > I applied this patch on top of 771ed66105de and unfortunately the > issue is not fixed. > I saw a green flashing bar on top of the screen again. Hmmm, I might have missed something, but it looks like nothing happened here since then. What's the status? Is the issue still happening? Any solution in sight? Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page. #regzbot poke
Re: [RFC] Patch review challenges
> The issue is one of communication and the way reviews are conducted. > > Reviewing other people's work is challenging and requires a certain > skill-set, of which _excellent_ communication skills are non-negotiable. Patch feedback and change tolerance can vary also according to involved communities. > Why not concentrate on more complex submissions for a while and grow > your repertoire of common review points, Further collateral evolution can be considered there depending on corresponding development resources. > rather than repeating the same few over and over? Some factors are probably known also according to corresponding statistics. Several contributors are stumbling on recurring improvement possibilities in published information. > Reading other, more experienced maintainer's reviews would also be a good use > of your time. I am trying to influence adjustments in desirable directions for a while. Regards, Markus
Re: [RFC] Patch review challenges
On Fri, 21 Jun 2024, Markus Elfring wrote: > > The issue is one of communication and the way reviews are conducted. > > > > Reviewing other people's work is challenging and requires a certain > > skill-set, of which _excellent_ communication skills are non-negotiable. > > Patch feedback and change tolerance can vary also according to involved > communities. Agreed. For this community, I suggest you build your skills for a while longer. > > Why not concentrate on more complex submissions for a while and grow > > your repertoire of common review points, > > Further collateral evolution can be considered there depending on > corresponding development resources. > > > rather than repeating the same few over and over? > > Some factors are probably known also according to corresponding statistics. > Several contributors are stumbling on recurring improvement possibilities > in published information. Right, this will always be true, however the few you've picked up on are not important enough to keep reiterating. By doing so, you're receiving undesirable attention. > > Reading other, more experienced maintainer's reviews would also be a good > > use > > of your time. > > I am trying to influence adjustments in desirable directions for a while. Never stop trying to improve. These are only my opinions of course. Take the advice or leave it. There's no need to reply to this. -- Lee Jones [李琼斯]
Re: [PATCH 1/2] drm/amdgpu: Unmap BO memory before calling amdgpu_bo_unref()
Am 21.06.24 um 09:32 schrieb Thomas Zimmermann:
Hi
Am 20.06.24 um 17:50 schrieb Christian König:
Am 20.06.24 um 16:44 schrieb Thomas Zimmermann:
Prepares for using ttm_bo_vmap() and ttm_bo_vunmap() in amdgpu. Both
require the caller to hold the GEM reservation lock, which is not the
case while releasing a buffer object. Hence, push a possible call to
unmap out from the buffer-object release code. Warn if a buffer object
with mapped pages is supposed to be released.
Yeah, I've looked into this a while ago as well and that
unfortunately won't work like this.
Amdgpu also uses ttm_bo_kmap() on user allocations, so the
amdgpu_bo_kunmap() in amdgpu_bo_destroy() is a must have.
Is there a testcase (igt-gpu-tools ?) that runs this code? I've
tested these patches by booting and running a 3d game under X11. But I
didn't expect that to fully cover all cases.
You need a hardware generation and use case which needs patching or
inspection of IBs.
Video decoding on old SI or CIK hardware generation should probably do
the trick.
Regards,
Christian.
Best regards
Thomas
On the other hand I'm pretty sure that calling ttm_bo_vunmap()
without holding the reservation lock is ok in this situation.
After all it's guaranteed that nobody else is having a reference to
the BO any more.
Regards,
Christian.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index a1b7438c43dc8..d58b11ea0ead5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -58,7 +58,12 @@ static void amdgpu_bo_destroy(struct
ttm_buffer_object *tbo)
{
struct amdgpu_bo *bo = ttm_to_amdgpu_bo(tbo);
- amdgpu_bo_kunmap(bo);
+ /*
+ * BO memory pages should be unmapped at this point. Call
+ * amdgpu_bo_kunmap() before releasing the BO.
+ */
+ if (drm_WARN_ON_ONCE(bo->tbo.base.dev, bo->kmap.bo))
+ amdgpu_bo_kunmap(bo);
if (bo->tbo.base.import_attach)
drm_prime_gem_destroy(&bo->tbo.base, bo->tbo.sg);
@@ -450,9 +455,7 @@ void amdgpu_bo_free_kernel(struct amdgpu_bo
**bo, u64 *gpu_addr,
WARN_ON(amdgpu_ttm_adev((*bo)->tbo.bdev)->in_suspend);
if (likely(amdgpu_bo_reserve(*bo, true) == 0)) {
- if (cpu_addr)
- amdgpu_bo_kunmap(*bo);
-
+ amdgpu_bo_kunmap(*bo);
amdgpu_bo_unpin(*bo);
amdgpu_bo_unreserve(*bo);
}
Re: [PATCH 1/2] MAINTAINERS: drm : vc4: Add Raspberry Pi as maintainers
On Thu, Jun 20, 2024 at 03:06:11PM GMT, Dave Stevenson wrote: > On Thu, 20 Jun 2024 at 14:52, Maxime Ripard wrote: > > > > On Thu, Jun 20, 2024 at 12:14:00PM GMT, Dave Stevenson wrote: > > > Add myself and our kernel maintenance list as maintainers for > > > VC4 alongside Maxime. > > > > > > Signed-off-by: Dave Stevenson > > > --- > > > MAINTAINERS | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > index d1566c647a50..b6dd628d5bc6 100644 > > > --- a/MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -7520,6 +7520,8 @@ F: include/uapi/drm/v3d_drm.h > > > > > > DRM DRIVERS FOR VC4 > > > M: Maxime Ripard > > > +M: Dave Stevenson > > > +M: Raspberry Pi Kernel Maintenance > > > > I don't think we can put a list as maintainer, maintainers (and > > reviewers) should be explicit. We can definitely put the list as Cc with > > L: though :) > > It's been accepted for Unicam > https://github.com/torvalds/linux/blob/master/MAINTAINERS#L4178-L4183 I think it's somewhat different in the case of v4l2, you're the one taking the patches and sending a PR iirc. In drm-misc, there's a significant chance someone else will apply it. > bcm-kernel-feedback-l...@broadcom.com is listed as reviewer for a fair > number of entries. It's also a matter of signalling to the rest of the kernel community how important a review is: if I get a review of someone on a patch that isn't listed in MAINTAINERS, then it's valid but not enough for me to merge it. If it's from a reviewer, then it carries more weight, and if it's from a maintainer, then it's pretty much the final word. That only works if we explicitly put names in MAINTAINERS. But I also don't care how many maintainers or reviewers you want to put in MAINTAINERS, so it's not gatekeeping. It's mostly just around documenting what the situation will be :) Maxime signature.asc Description: PGP signature
Re: [PATCH v2 8/8] drm/amdgpu: Call drm_atomic_helper_shutdown() at shutdown time
On Thu, Jun 20, 2024 at 09:00:23AM GMT, Alex Deucher wrote: > On Thu, Jun 20, 2024 at 3:10 AM Maxime Ripard wrote: > > > > Hi, > > > > On Wed, Jun 19, 2024 at 09:53:12AM GMT, Alex Deucher wrote: > > > On Wed, Jun 19, 2024 at 9:50 AM Alex Deucher > > > wrote: > > > > > > > > On Tue, Jun 18, 2024 at 7:53 PM Doug Anderson > > > > wrote: > > > > > > > > > > Hi, > > > > > > > > > > On Tue, Jun 18, 2024 at 3:00 PM Alex Deucher > > > > > wrote: > > > > > > > > > > > > On Tue, Jun 18, 2024 at 5:40 PM Doug Anderson > > > > > > wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > On Mon, Jun 17, 2024 at 8:01 AM Alex Deucher > > > > > > > wrote: > > > > > > > > > > > > > > > > On Wed, Jun 12, 2024 at 6:37 PM Douglas Anderson > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Based on grepping through the source code this driver appears > > > > > > > > > to be > > > > > > > > > missing a call to drm_atomic_helper_shutdown() at system > > > > > > > > > shutdown > > > > > > > > > time. Among other things, this means that if a panel is in > > > > > > > > > use that it > > > > > > > > > won't be cleanly powered off at system shutdown time. > > > > > > > > > > > > > > > > > > The fact that we should call drm_atomic_helper_shutdown() in > > > > > > > > > the case > > > > > > > > > of OS shutdown/restart comes straight out of the kernel doc > > > > > > > > > "driver > > > > > > > > > instance overview" in drm_drv.c. > > > > > > > > > > > > > > > > > > Suggested-by: Maxime Ripard > > > > > > > > > Cc: Alex Deucher > > > > > > > > > Cc: Christian König > > > > > > > > > Cc: Xinhui Pan > > > > > > > > > Signed-off-by: Douglas Anderson > > > > > > > > > --- > > > > > > > > > This commit is only compile-time tested. > > > > > > > > > > > > > > > > > > ...and further, I'd say that this patch is more of a plea for > > > > > > > > > help > > > > > > > > > than a patch I think is actually right. I'm _fairly_ certain > > > > > > > > > that > > > > > > > > > drm/amdgpu needs this call at shutdown time but the logic is > > > > > > > > > a bit > > > > > > > > > hard for me to follow. I'd appreciate if anyone who actually > > > > > > > > > knows > > > > > > > > > what this should look like could illuminate me, or perhaps > > > > > > > > > even just > > > > > > > > > post a patch themselves! > > > > > > > > > > > > > > > > I'm not sure this patch makes sense or not. The driver doesn't > > > > > > > > really > > > > > > > > do a formal tear down in its shutdown routine, it just quiesces > > > > > > > > the > > > > > > > > hardware. What are the actual requirements of the shutdown > > > > > > > > function? > > > > > > > > In the past when we did a full driver tear down in shutdown, it > > > > > > > > delayed the shutdown sequence and users complained. > > > > > > > > > > > > > > The "inspiration" for this patch is to handle panels properly. > > > > > > > Specifically, panels often have several power/enable signals > > > > > > > going to > > > > > > > them and often have requirements that these signals are powered > > > > > > > off in > > > > > > > the proper order with the proper delays between them. While we > > > > > > > can't > > > > > > > always do so when the system crashes / reboots in an uncontrolled > > > > > > > way, > > > > > > > panel manufacturers / HW Engineers get upset if we don't power > > > > > > > things > > > > > > > off properly during an orderly shutdown/reboot. When panels are > > > > > > > powered off badly it can cause garbage on the screen and, so I've > > > > > > > been > > > > > > > told, can even cause long term damage to the panels over time. > > > > > > > > > > > > > > In Linux, some panel drivers have tried to ensure a proper > > > > > > > poweroff of > > > > > > > the panel by handling the shutdown() call themselves. However, > > > > > > > this is > > > > > > > ugly and panel maintainers want panel drivers to stop doing it. We > > > > > > > have removed the code doing this from most panels now [1]. > > > > > > > Instead the > > > > > > > assumption is that the DRM modeset drivers should be calling > > > > > > > drm_atomic_helper_shutdown() which will make sure panels get an > > > > > > > orderly shutdown. > > > > > > > > > > > > > > For a lot more details, see the cover letter [2] which then > > > > > > > contains > > > > > > > links to even more discussions about the topic. > > > > > > > > > > > > > > [1] > > > > > > > https://lore.kernel.org/r/20240605002401.2848541-1-diand...@chromium.org > > > > > > > [2] > > > > > > > https://lore.kernel.org/r/2024061435.3188234-1-diand...@chromium.org > > > > > > > > > > > > I don't think it's an issue. We quiesce the hardware as if we were > > > > > > about to suspend the system (e.g., S3). For the display hardware we > > > > > > call drm_atomic_helper_suspend() as part of that sequence. > > > > > > > > > > OK. It's no skin off my teeth and we can drop this patch if you're > > > > > c
Re: [PATCH v2] drm/mediatek: Log errors in probe with dev_err_probe()
Re: [PATCH] drm/qxl: Add check for drm_cvt_mode
在 2024/6/21 下午3:10, Chen Ni 写道:
Add check for the return value of drm_cvt_mode() and return the error if
it fails in order to avoid NULL pointer dereference.
Fixes: 1b043677d4be ("drm/qxl: add qxl_add_mode helper function")
Signed-off-by: Chen Ni
---
drivers/gpu/drm/qxl/qxl_display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index c6d35c33d5d6..86a5dea710c0 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -236,6 +236,9 @@ static int qxl_add_mode(struct drm_connector *connector,
return 0;
mode = drm_cvt_mode(dev, width, height, 60, false, false, false);
+ if (!mode)
+ return 0;
+
if (preferred)
mode->type |= DRM_MODE_TYPE_PREFERRED;
mode->hdisplay = width;
Reviewed-by: Heng Qi
Thanks.
Re: [PATCH 00/31] Preparatory patches for BCM2712 (Pi5) support
Hi Dave, Thanks for taking the time to send this. I've gone through most of the patches and it looks pretty good already, but I have a few general remarks: - We merged in drm-misc-next the new HDMI infrastructure recently and it will heavily conflict with some of these patches, so you need to rebase against either linux-next or drm-misc-next. - The author and SoB fields for my patches don't match anymore, possibly due to mailmap doing its magic. You can fix this by using, for the SoB: git filter-branch --msg-filter 'sed -i s/max...@cerno.tech/mrip...@kernel.org/' drm-misc-next.. And for the authorship: git commit --amend --author="Maxime Ripard " for each commit. - All of the fixes need Fixes that are currently missing on most tags - And the commit prefix isn't consistent, especially for vc4_plane.c, the upstream convention so far has been drm/vc4: plane, instead of drm/vc4_plane. Maxime On Thu, Jun 20, 2024 at 04:46:01PM GMT, Dave Stevenson wrote: > Hi > > This set is a number of minor fixes that we've had downstream for a while, > and then lays down the some infrastructure changes to facilitate adding > support > of BCM2712. I'm just finalising those patches so they should follow on fairly > soon. > > Thanks > Dave > > Dave Stevenson (8): > drm/vc4: Force trigger of dlist update on margins change > drm/vc4: Set AXI panic modes for the HVS > drm/vc4: Limit max_bpc to 8 on Pi0-3 > drm/vc4: Don't write gamma luts on 2711 > drm/vc4: UV planes vertical scaling must always be enabled > drm/vc4: Fix dlist debug not resetting the next entry pointer > drm/vc4: Remove incorrect limit from hvs_dlist debugfs function > drm/vc4: Move the buffer offset out of the vc4_plane_state > > Dom Cobley (7): > drm/vc4: vc4_plane: Keep fractional source coords inside state > drm/vc4: Handle fractional coordinates using the phase field > drm/vc4: hdmi: Avoid log spam for audio start failure > drm/vc4_plane: Add support for YUV444 formats > drm/vc4: hdmi: Increase audio MAI fifo dreq threshold > drm/vc4: hdmi: Avoid hang with debug registers when suspended > drm/vc4: hvs: Remove ABORT_ON_EMPTY flag > > Maxime Ripard (15): > drm/vc4: hdmi: Warn if writing to an unknown HDMI register > drm/vc4: hvs: More logging for dlist generation > drm/vc4: hvs: Print error if we fail an allocation > drm/vc4: plane: Add more debugging for LBM allocation > drm/vc4: plane: Use return variable in atomic_check > drm/vc4: crtc: Move assigned_channel to a variable > drm/vc4: Introduce generation number enum > drm/vc4: Make v3d paths unavailable on any generation newer than vc4 > drm/vc4: hvs: Use switch statement to simplify > vc4_hvs_get_fifo_from_output > drm/vc4: hvs: Create hw_init function > drm/vc4: hvs: Create cob_init function > drm/vc4: hvs: Rename hvs_regs list > drm/vc4: plane: Change ptr0_offset to an array > drm/vc4: hvs: Rework LBM alignment > drm/vc4: hvs: Change prototype of __vc4_hvs_alloc to pass registers > > Tim Gover (1): > drm/vc4: Enable SCALER_CONTROL early in HVS init > > drivers/gpu/drm/vc4/tests/vc4_mock.c | 14 +- > drivers/gpu/drm/vc4/vc4_bo.c | 28 +- > drivers/gpu/drm/vc4/vc4_crtc.c | 35 ++- > drivers/gpu/drm/vc4/vc4_drv.c | 22 +- > drivers/gpu/drm/vc4/vc4_drv.h | 29 +- > drivers/gpu/drm/vc4/vc4_gem.c | 24 +- > drivers/gpu/drm/vc4/vc4_hdmi.c | 30 +- > drivers/gpu/drm/vc4/vc4_hdmi_regs.h| 5 +- > drivers/gpu/drm/vc4/vc4_hvs.c | 343 + > drivers/gpu/drm/vc4/vc4_irq.c | 10 +- > drivers/gpu/drm/vc4/vc4_kms.c | 14 +- > drivers/gpu/drm/vc4/vc4_perfmon.c | 20 +- > drivers/gpu/drm/vc4/vc4_plane.c| 281 +++-- > drivers/gpu/drm/vc4/vc4_regs.h | 1 + > drivers/gpu/drm/vc4/vc4_render_cl.c| 2 +- > drivers/gpu/drm/vc4/vc4_v3d.c | 10 +- > drivers/gpu/drm/vc4/vc4_validate.c | 8 +- > drivers/gpu/drm/vc4/vc4_validate_shaders.c | 2 +- > 18 files changed, 540 insertions(+), 338 deletions(-) > > -- > 2.34.1 > signature.asc Description: PGP signature
Re: [PATCH v2 0/7] drm/panic: Fixes and graphical logo
Hi, I want to push at least the first patch that is an important fix. But if there are no objections, I can push the whole series except patch 5 "drm/panic: Convert to drm_fb_clip_offset()" which causes some build issue. Best regards, -- Jocelyn On 13/06/2024 21:17, Geert Uytterhoeven wrote: Hi all, If drm/panic is enabled, a user-friendly message is shown on screen when a kernel panic occurs, together with an ASCII art penguin logo. Of course we can do better ;-) Hence this patch series extends drm/panic to draw the monochrome graphical boot logo, when available, preceded by the customary fixes. Changes compared to v1: - Rebase against today's drm-misc-next, where drm_panic is broken on all current drivers due to an uninitialized pointer dereference. Presumably this was only tested with an out-of-tree driver change? - New fixes [1/7], [3/7], and [4/7], - New cleanup [5/7], - Inline trivial draw_logo_mono(). This has been tested with rcar-du. Thanks for your comments! Geert Uytterhoeven (7): drm/panic: Fix uninitialized drm_scanout_buffer.set_pixel() crash drm/panic: Fix off-by-one logo size checks lib/fonts: Fix visiblity of SUN12x22 and TER16x32 if DRM_PANIC drm/panic: Spelling s/formater/formatter/ drm/panic: Convert to drm_fb_clip_offset() drm/panic: Rename logo to logo_ascii drm/panic: Add support for drawing a monochrome graphical logo drivers/gpu/drm/Kconfig | 2 +- drivers/gpu/drm/drm_panic.c | 74 +++-- drivers/video/logo/Kconfig | 2 + lib/fonts/Kconfig | 6 ++- 4 files changed, 70 insertions(+), 14 deletions(-)
Re: [PATCH 05/31] drm/vc4_plane: Add support for YUV444 formats
Hi, On Thu, Jun 20, 2024 at 04:46:06PM GMT, Dave Stevenson wrote: > From: Dom Cobley > > Support displaying DRM_FORMAT_YUV444 and DRM_FORMAT_YVU444 formats. > Tested with kmstest and kodi. e.g. > > kmstest -r 1920x1080@60 -f 400x300-YU24 > > Note: without the shift of width, only half the chroma is fetched, > resulting in correct left half of image and corrupt colours on right half. > > The increase in width shouldn't affect fetching of Y data, > as the hardware will clamp at dest width. > > Signed-off-by: Dom Cobley Also, this is missing your Signed-off-by. It needs to be there for all the patches you send on someone's behalf. Maxime signature.asc Description: PGP signature
Re: [PATCH v6 0/7] Add mediate-drm secure flow for SVP
Hi,
On Tue, Jun 11, 2024 at 09:13:03AM GMT, Jason-JH Lin (林睿祥) wrote:
> Hi Maxime,
>
> [snip]
>
> > > > > > ---
> > > > > > TODO:
> > > > > > 1) Drop MTK_DRM_IOCTL_GEM_CREATE and use DMA_HEAP_IOCTL_ALLOC
> > > > > > in
> > > > > > userspace
> > > > > > 2) DRM driver use secure mailbox channel to handle normal and
> > > > > > secure flow
> > > > > > 3) Implement setting mmsys routing table in the secure world
> > > > > > series
> > > > >
> > > > > I'm not sure what you mean here. Why are you trying to upstream
> > > > > something that still needs to be removed from your patch
> > > > > series?
> > > > >
> > > >
> > > > Because their is too much patches need to be fixed in this
> > > > series,
> > > > so I
> > > > list down the remaining TODO items and send to review for the
> > > > other
> > > > patches.
> > > >
> > > > Sorry for the bothering, I'll drop this at the next version.
> > >
> > > If you don't intend to use it, we just shouldn't add it. Removing
> > > the
> > > TODO item doesn't make sense, even more so if heaps should be the
> > > way
> > > you handle this.
> > >
> >
> > Sorry for this misunderstanding.
> >
> > I mean I'll remove the DRM_IOCTL_GEM_CREATE patch and then change
> > user
> > space calling DMA_HEAP_IOCTL_ALLOC to allocate buffer from secure
> > heap.
> >
>
> I have changed user space to use DMA_HEAP_IOCTL_ALLOC to allocate
> secure buffer, but I still encounter the problem of determining whether
> the buffer is secure in mediatek-drm driver to add some secure
> configure for hardware.
>
>
> As the comment in [1], dma driver won't provide API for use.
> [1]:
> https://patchwork.kernel.org/project/linux-mediatek/patch/20240515112308.10171-3-yong...@mediatek.com/#25857255
>
>
> So I use name checking at [PATCH v6 3/7] like this currently:
>
> struct drm_gem_object *mtk_gem_prime_import_sg_table(struct drm_device
> *dev,
> struct dma_buf_attachment *attach, struct sg_table *sg)
> {
> struct mtk_gem_obj *mtk_gem;
>
> /* check if the entries in the sg_table are contiguous */
> if (drm_prime_get_contiguous_size(sg) < attach->dmabuf->size) {
> DRM_ERROR("sg_table is not contiguous");
> return ERR_PTR(-EINVAL);
> }
>
> mtk_gem = mtk_gem_init(dev, attach->dmabuf->size);
> if (IS_ERR(mtk_gem))
> return ERR_CAST(mtk_gem);
>
> + mtk_gem->secure = (!strncmp(attach->dmabuf->exp_name, "restricted",
> 10));
> mtk_gem->dma_addr = sg_dma_address(sg->sgl);
> + mtk_gem->size = attach->dmabuf->size;
> mtk_gem->sg = sg;
>
> return &mtk_gem->base;
> }
>
> But I want to change this name checking to the information brought from
> user space.
> I tried to use arg->flags to append the secure flag in user space and
> call drmPrimeHandleToFD() to pass it to DRM driver, but it will be
> blocked by at the beginning of the drm_prime_handle_to_fd_ioctl().
I agree with you, it's something to discuss mostly with the dma-buf
maintainers but it would be better to just set a flag on the dma-buf,
and use that flag whenever necessary.
It might be related to the recent work I did to introduce allocation
flags too:
https://lore.kernel.org/linux-media/20240515-dma-buf-ecc-heap-v1-0-54cbbd049...@kernel.org/
Maxime
signature.asc
Description: PGP signature
Re: [PATCH RFC 1/5] drm/bridge: lt9611: use HDMI Connector helper to set InfoFrames
On Sat, 15 Jun 2024 20:53:30 +0300, Dmitry Baryshkov wrote: > Use new HDMI Connector helpers in the Lontium LT9611 bridge driver. > Program InfoFrames using the helper's callbacks. Also use TMDS char rate > validation callback to filter out modes, instead of hardcoding 4k@30. > > The Audio InfoFrame isn't yet handled by these helpers, it requires > > [ ... ] Reviewed-by: Maxime Ripard Thanks! Maxime
[PATCH] drm/xe/lnl: Offload system clear page activity to GPU
On LNL because of flat CCS, driver will create a migrate job to clear
CCS meta data. Extend that to also clear pages using GPU with new
ttm pool flag which allows offloading page clear activity to GPU.
Cc: Matthew Auld
Cc: Michal Mrozek
Cc: "Thomas Hellström"
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/xe/xe_bo.c | 4
drivers/gpu/drm/xe/xe_device.c | 7 +++
drivers/gpu/drm/xe/xe_device_types.h | 2 ++
drivers/gpu/drm/xe/xe_migrate.c | 5 +++--
4 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
index 65c696966e96..10ec02412dc4 100644
--- a/drivers/gpu/drm/xe/xe_bo.c
+++ b/drivers/gpu/drm/xe/xe_bo.c
@@ -387,6 +387,10 @@ static struct ttm_tt *xe_ttm_tt_create(struct
ttm_buffer_object *ttm_bo,
caching = ttm_uncached;
}
+ /* Clear TTM_TT_FLAG_ZERO_ALLOC when GPU is set to clear pages */
+ if (xe->mem.gpu_page_clear)
+ page_flags &= ~TTM_TT_FLAG_ZERO_ALLOC;
+
err = ttm_tt_init(&tt->ttm, &bo->ttm, page_flags, caching, extra_pages);
if (err) {
kfree(tt);
diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
index 0d57eea8f083..20548a5d3eff 100644
--- a/drivers/gpu/drm/xe/xe_device.c
+++ b/drivers/gpu/drm/xe/xe_device.c
@@ -636,6 +636,13 @@ int xe_device_probe(struct xe_device *xe)
if (err)
goto err_irq_shutdown;
+ /**
+* On iGFX device with flat CCS we clear CCS metadata, let's extend that
+* and use GPU to clear pages as well.
+*/
+ if (xe_device_has_flat_ccs(xe) && !IS_DGFX(xe))
+ xe->mem.gpu_page_clear = true;
+
err = xe_vram_probe(xe);
if (err)
goto err_irq_shutdown;
diff --git a/drivers/gpu/drm/xe/xe_device_types.h
b/drivers/gpu/drm/xe/xe_device_types.h
index c37be471d11c..ece68c6f3668 100644
--- a/drivers/gpu/drm/xe/xe_device_types.h
+++ b/drivers/gpu/drm/xe/xe_device_types.h
@@ -325,6 +325,8 @@ struct xe_device {
struct xe_mem_region vram;
/** @mem.sys_mgr: system TTM manager */
struct ttm_resource_manager sys_mgr;
+ /** @gpu_page_clear: clear pages offloaded to GPU */
+ bool gpu_page_clear;
} mem;
/** @sriov: device level virtualization data */
diff --git a/drivers/gpu/drm/xe/xe_migrate.c b/drivers/gpu/drm/xe/xe_migrate.c
index 05f933787860..90c5a2e35075 100644
--- a/drivers/gpu/drm/xe/xe_migrate.c
+++ b/drivers/gpu/drm/xe/xe_migrate.c
@@ -1003,6 +1003,7 @@ struct dma_fence *xe_migrate_clear(struct xe_migrate *m,
struct xe_gt *gt = m->tile->primary_gt;
struct xe_device *xe = gt_to_xe(gt);
bool clear_system_ccs = (xe_bo_needs_ccs_pages(bo) && !IS_DGFX(xe)) ?
true : false;
+ bool clear_on_create = xe->mem.gpu_page_clear;
struct dma_fence *fence = NULL;
u64 size = bo->size;
struct xe_res_cursor src_it;
@@ -1032,7 +1033,7 @@ struct dma_fence *xe_migrate_clear(struct xe_migrate *m,
batch_size = 2 +
pte_update_size(m, clear_vram, src, &src_it,
&clear_L0, &clear_L0_ofs, &clear_L0_pt,
- clear_system_ccs ? 0 :
emit_clear_cmd_len(gt), 0,
+ !clear_on_create ? 0 :
emit_clear_cmd_len(gt), 0,
avail_pts);
if (xe_device_has_flat_ccs(xe))
@@ -1060,7 +1061,7 @@ struct dma_fence *xe_migrate_clear(struct xe_migrate *m,
bb->cs[bb->len++] = MI_BATCH_BUFFER_END;
update_idx = bb->len;
- if (!clear_system_ccs)
+ if (clear_on_create)
emit_clear(gt, bb, clear_L0_ofs, clear_L0,
XE_PAGE_SIZE, clear_vram);
if (xe_device_has_flat_ccs(xe)) {
--
2.42.0
Re: [PATCH v1 1/1] drm/xe/bo: Fix fixed placement ggtt pinning code
On 21/06/2024 08:15, Alan Previn wrote:
When calling xe_bo_create_pin_map_at, use the correct
starting offset provided by caller at xe_ggtt_insert_bo_at.
Fixes: 44e694958b95 ("drm/xe/display: Implement display support")
Signed-off-by: Alan Previn
---
drivers/gpu/drm/xe/xe_bo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
index 74294f1b05bc..cc6101b49c08 100644
--- a/drivers/gpu/drm/xe/xe_bo.c
+++ b/drivers/gpu/drm/xe/xe_bo.c
@@ -1436,7 +1436,7 @@ __xe_bo_create_locked(struct xe_device *xe,
if (flags & XE_BO_FLAG_FIXED_PLACEMENT) {
err = xe_ggtt_insert_bo_at(tile->mem.ggtt, bo,
- start + bo->size, U64_MAX);
+ start, end);
I think this is just about controlling the ggtt bias range. i.e please
allocate bo->size somewhere within [start + bo->size, U64_MAX]. There
was a reason for the + bo->size, I think something odd like initial fb
using low ggtt address (pre-programmed by bios), and wanting to use that
for guc or something instead so we effectively move it with the above.
I think we also only need such an interface for funky stuff like initial
fb, which is either in stolen or vram. The actual allocate backing pages
part of the api should respect start, like for vram and stolen, which is
the main point of FIXED_PLACEMENT. Trying to do that for system memory
is not really possible AFAIK.
If we just want something with specific ggtt alignment we could plumb
that through to the mm interface. For example, put this anywhere within
ggtt but ensure address is aligned to 256M. We then only pass FLAG_GGTT
and not FIXED_PLACEMENT.
} else {
err = xe_ggtt_insert_bo(tile->mem.ggtt, bo);
}
base-commit: cffd77865f476994680892601e09bc2164179907
Re: [PATCH RFC 3/5] drm/connector: implement generic HDMI codec helpers
Hi,
Sorry for taking some time to review this series.
On Sat, Jun 15, 2024 at 08:53:32PM GMT, Dmitry Baryshkov wrote:
> Several DRM drivers implement HDMI codec support (despite its name it
> applies to both HDMI and DisplayPort drivers). Implement generic
> framework to be used by these drivers. This removes a requirement to
> implement get_eld() callback and provides default implementation for
> codec's plug handling.
>
> The framework is integrated with the DRM HDMI Connector framework, but
> can be used by DisplayPort drivers.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/drm_connector.c| 8 ++
> drivers/gpu/drm/drm_connector_hdmi_codec.c | 157
> +
> include/drm/drm_connector.h| 33 ++
> 4 files changed, 199 insertions(+)
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 68cc9258ffc4..e113a6eade23 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -45,6 +45,7 @@ drm-y := \
> drm_client_modeset.o \
> drm_color_mgmt.o \
> drm_connector.o \
> + drm_connector_hdmi_codec.o \
> drm_crtc.o \
> drm_displayid.o \
> drm_drv.o \
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 3d73a981004c..66d6e9487339 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -279,6 +279,7 @@ static int __drm_connector_init(struct drm_device *dev,
> mutex_init(&connector->mutex);
> mutex_init(&connector->edid_override_mutex);
> mutex_init(&connector->hdmi.infoframes.lock);
> + mutex_init(&connector->hdmi_codec.lock);
> connector->edid_blob_ptr = NULL;
> connector->epoch_counter = 0;
> connector->tile_blob_ptr = NULL;
> @@ -529,6 +530,12 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
>
> connector->hdmi.funcs = hdmi_funcs;
>
> + if (connector->hdmi_codec.i2s || connector->hdmi_codec.spdif) {
> + ret = drmm_connector_hdmi_codec_alloc(dev, connector,
> hdmi_funcs->codec_ops);
> + if (ret)
> + return ret;
> + }
> +
> return 0;
> }
> EXPORT_SYMBOL(drmm_connector_hdmi_init);
> @@ -665,6 +672,7 @@ void drm_connector_cleanup(struct drm_connector
> *connector)
> connector->funcs->atomic_destroy_state(connector,
> connector->state);
>
> + mutex_destroy(&connector->hdmi_codec.lock);
> mutex_destroy(&connector->hdmi.infoframes.lock);
> mutex_destroy(&connector->mutex);
>
> diff --git a/drivers/gpu/drm/drm_connector_hdmi_codec.c
> b/drivers/gpu/drm/drm_connector_hdmi_codec.c
> new file mode 100644
> index ..a3a7ad117f6f
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_connector_hdmi_codec.c
> @@ -0,0 +1,157 @@
> +/*
> + * Copyright (c) 2024 Linaro Ltd
> + *
> + * Permission to use, copy, modify, distribute, and sell this software and
> its
> + * documentation for any purpose is hereby granted without fee, provided that
> + * the above copyright notice appear in all copies and that both that
> copyright
> + * notice and this permission notice appear in supporting documentation, and
> + * that the name of the copyright holders not be used in advertising or
> + * publicity pertaining to distribution of the software without specific,
> + * written prior permission. The copyright holders make no representations
> + * about the suitability of this software for any purpose. It is provided
> "as
> + * is" without express or implied warranty.
> + *
> + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
> SOFTWARE,
> + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
> + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
> + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF
> USE,
> + * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
> + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
> PERFORMANCE
> + * OF THIS SOFTWARE.
> + */
> +
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include
> +
> +static int drm_connector_hdmi_codec_get_eld(struct device *dev, void *data,
> + uint8_t *buf, size_t len)
> +{
> + struct drm_connector *connector = data;
> +
> + // FIXME: locking against drm_edid_to_eld ?
> + memcpy(buf, connector->eld, min(sizeof(connector->eld), len));
> +
> + return 0;
> +}
> +
> +static int drm_connector_hdmi_codec_hook_plugged_cb(struct device *dev,
> + void *data,
> + hdmi_codec_plugged_cb fn,
> + struct device *codec_dev)
> +{
> + struct drm_connector *connector = data
Re: [PATCH RFC 4/5] drm/bridge: connector: add support for HDMI codec framework
On Sat, Jun 15, 2024 at 08:53:33PM GMT, Dmitry Baryshkov wrote:
> Add necessary glue code to be able to use new HDMI codec framework from
> the DRM bridge drivers. The drm_bridge implements a limited set of the
> hdmi_codec_ops interface, with the functions accepting both
> drm_connector and drm_bridge instead of just a generic void pointer.
>
> This framework is integrated with the DRM HDMI Connector framework, but
> can also be used for DisplayPort connectors.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/drm_bridge_connector.c | 130
> -
> include/drm/drm_bridge.h | 46
> 2 files changed, 174 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_bridge_connector.c
> b/drivers/gpu/drm/drm_bridge_connector.c
> index 0869b663f17e..71d6fdc2391f 100644
> --- a/drivers/gpu/drm/drm_bridge_connector.c
> +++ b/drivers/gpu/drm/drm_bridge_connector.c
> @@ -20,6 +20,8 @@
> #include
> #include
>
> +#include
> +
> /**
> * DOC: overview
> *
> @@ -95,6 +97,14 @@ struct drm_bridge_connector {
>* HDMI connector infrastructure, if any (see &DRM_BRIDGE_OP_HDMI).
>*/
> struct drm_bridge *bridge_hdmi;
> + /**
> + * @bridge_hdmi_codec:
> + *
> + * The bridge in the chain that implements necessary support for the
> + * HDMI Audio Codec infrastructure, if any (see
> + * &DRM_BRIDGE_OP_HDMI_CODEC).
> + */
> + struct drm_bridge *bridge_hdmi_codec;
Can we have a setup where one bridge would support the video stream and
another one the audio?
I think for now I'd rather make them both provided by the same bridge,
and we can always change that later on if we need to.
> };
>
> #define to_drm_bridge_connector(x) \
> @@ -343,10 +353,104 @@ static int drm_bridge_connector_write_infoframe(struct
> drm_connector *connector,
> return bridge->funcs->hdmi_write_infoframe(bridge, type, buffer, len);
> }
>
> +static int drm_bridge_connector_audio_startup(struct device *dev, void *data)
> +{
> + struct drm_connector *connector = data;
> + struct drm_bridge_connector *bridge_connector =
> + to_drm_bridge_connector(connector);
> + struct drm_bridge *bridge;
> +
> + bridge = bridge_connector->bridge_hdmi_codec;
> + if (!bridge)
> + return -EINVAL;
> +
> + if (bridge->funcs->hdmi_codec_audio_startup)
> + return bridge->funcs->hdmi_codec_audio_startup(dev, connector,
> bridge);
> + else
> + return 0;
> +}
> +
> +static int drm_bridge_connector_prepare(struct device *dev, void *data,
> + struct hdmi_codec_daifmt *fmt,
> + struct hdmi_codec_params *hparms)
> +{
> + struct drm_connector *connector = data;
> + struct drm_bridge_connector *bridge_connector =
> + to_drm_bridge_connector(connector);
> + struct drm_bridge *bridge;
> +
> + bridge = bridge_connector->bridge_hdmi_codec;
> + if (!bridge)
> + return -EINVAL;
> +
> + return bridge->funcs->hdmi_codec_prepare(dev, connector, bridge, fmt,
> hparms);
> +}
> +
> +static void drm_bridge_connector_audio_shutdown(struct device *dev, void
> *data)
> +{
> + struct drm_connector *connector = data;
> + struct drm_bridge_connector *bridge_connector =
> + to_drm_bridge_connector(connector);
> + struct drm_bridge *bridge;
> +
> + bridge = bridge_connector->bridge_hdmi_codec;
> + if (!bridge)
> + return;
> +
> + bridge->funcs->hdmi_codec_audio_shutdown(dev, connector, bridge);
> +}
> +
> +static int drm_bridge_connector_mute_stream(struct device *dev, void *data,
> + bool enable, int direction)
> +{
> + struct drm_connector *connector = data;
> + struct drm_bridge_connector *bridge_connector =
> + to_drm_bridge_connector(connector);
> + struct drm_bridge *bridge;
> +
> + bridge = bridge_connector->bridge_hdmi_codec;
> + if (!bridge)
> + return -EINVAL;
> +
> + if (bridge->funcs->hdmi_codec_mute_stream)
> + return bridge->funcs->hdmi_codec_mute_stream(dev, connector,
> bridge,
> + enable, direction);
> + else
> + return -ENOTSUPP;
> +}
> +
> +static int drm_bridge_connector_get_dai_id(struct snd_soc_component *comment,
> +struct device_node *endpoint,
> +void *data)
> +{
> + struct drm_connector *connector = data;
> + struct drm_bridge_connector *bridge_connector =
> + to_drm_bridge_connector(connector);
> + struct drm_bridge *bridge;
> +
> + bridge = bridge_connector->bridge_hdmi_codec;
> + if (!bridge)
> + return -EINVAL;
> +
> + if (bridge->funcs->hdmi_codec_get_dai_id)
> + return
Re: "firmware/sysfb: Set firmware-framebuffer parent device" breaks lightdm on Ubuntu 22.04 using amdgpu
Hi Marek
Am 13.06.24 um 07:59 schrieb Marek Olšák:
Hi Thomas,
Commit 9eac534db0013aff9b9124985dab114600df9081 as per the title
breaks (crashes?) lightdm (login screen) such that all I get is the
terminal. It's also reproducible with tag v6.9 where the commit is
present.
I still cannot reproduce the problem reliably. But I've found a
ref-counting bug on the parent device that was introduced by that
commit. This needs to be fixed anyway. A patch is attached if you want
to test.
Best regards
Thomas
Reverting the commit fixes lightdm. A workaround is to bypass lightdm
by triggering auto-login. This is a bug report.
(For AMD folks: It's also reproducible with amd-staging-drm-next.)
Marek
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
From 5ca700a36fc06e1ec5b3c2c9a383c2d0011c0d83 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Tue, 18 Jun 2024 17:37:11 +0200
Subject: [PATCH] firmware: sysfb: Fix reference count of syfb parent device
Retrieving the system framebuffer's parent device in sysfb_init()
increments the parent device's reference count. Hence release the
reference before leaving the init function.
Adding the sysfb platform device acquires and additional reference
for the parent. This keeps the parent device around while the system
framebuffer is in use.
Signed-off-by: Thomas Zimmermann
Fixes: 9eac534db001 ("firmware/sysfb: Set firmware-framebuffer parent device")
Cc: Thomas Zimmermann
Cc: Javier Martinez Canillas
Cc: Helge Deller
Cc: Jani Nikula
Cc: Dan Carpenter
Cc: Arnd Bergmann
Cc: Sui Jingfeng
Cc: # v6.9+
---
drivers/firmware/sysfb.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/sysfb.c b/drivers/firmware/sysfb.c
index 880ffcb500887..a316bd92dfed2 100644
--- a/drivers/firmware/sysfb.c
+++ b/drivers/firmware/sysfb.c
@@ -137,7 +137,7 @@ static __init int sysfb_init(void)
if (compatible) {
pd = sysfb_create_simplefb(si, &mode, parent);
if (!IS_ERR(pd))
- goto unlock_mutex;
+ goto put_device;
}
/* if the FB is incompatible, create a legacy framebuffer device */
@@ -155,7 +155,7 @@ static __init int sysfb_init(void)
pd = platform_device_alloc(name, 0);
if (!pd) {
ret = -ENOMEM;
- goto unlock_mutex;
+ goto put_device;
}
pd->dev.parent = parent;
@@ -170,9 +170,12 @@ static __init int sysfb_init(void)
if (ret)
goto err;
- goto unlock_mutex;
+
+ goto put_device;
err:
platform_device_put(pd);
+put_device:
+ put_device(parent);
unlock_mutex:
mutex_unlock(&disable_lock);
return ret;
--
2.45.2
Re: [PATCH 05/31] drm/vc4_plane: Add support for YUV444 formats
On Fri, 21 Jun 2024 at 09:57, Maxime Ripard wrote: > > Hi, > > On Thu, Jun 20, 2024 at 04:46:06PM GMT, Dave Stevenson wrote: > > From: Dom Cobley > > > > Support displaying DRM_FORMAT_YUV444 and DRM_FORMAT_YVU444 formats. > > Tested with kmstest and kodi. e.g. > > > > kmstest -r 1920x1080@60 -f 400x300-YU24 > > > > Note: without the shift of width, only half the chroma is fetched, > > resulting in correct left half of image and corrupt colours on right half. > > > > The increase in width shouldn't affect fetching of Y data, > > as the hardware will clamp at dest width. > > > > Signed-off-by: Dom Cobley > > Also, this is missing your Signed-off-by. It needs to be there for all > the patches you send on someone's behalf. Drat. I went through checking and adding my Sob, and obviously missed this one. Will add in v2. > Maxime
Re: [PATCH v8 15/16] drm/mediatek: Support CRC in OVL
Re: (subset) [PATCH v12 0/7] iio: new DMABUF based API v12
On Thu, 20 Jun 2024 14:27:19 +0200, Paul Cercueil wrote: > Here's the v12 of my patchset that introduces DMABUF support to IIO. > > Apart from a small documentation fix, it reverts to using > mutex_lock/mutex_unlock in one particular place, which used cleanup > GOTOs (which don't play well with scope-managed cleanups). > > Changelog: > - [3/7]: > - Revert to mutex_lock/mutex_unlock in iio_buffer_attach_dmabuf(), > as it uses cleanup GOTOs > - [6/7]: > - "obtained using..." -> "which can be obtained using..." > > [...] Applied, thanks! [1/7] dmaengine: Add API function dmaengine_prep_peripheral_dma_vec() commit: 5878853fc9389e7d0988d4b465a415cf96fd14fa [2/7] dmaengine: dma-axi-dmac: Implement device_prep_peripheral_dma_vec commit: 74609e5686701ed8e8adc3082d15f009e327286d [7/7] Documentation: dmaengine: Document new dma_vec API commit: 380afccc2a55e8015adae4266e8beff96ab620be Best regards, -- Vinod Koul
Re: [PATCH v12 0/7] iio: new DMABUF based API v12
On 20-06-24, 20:11, Jonathan Cameron wrote: > On Thu, 20 Jun 2024 21:50:41 +0530 > Vinod Koul wrote: > > > On 20-06-24, 14:27, Paul Cercueil wrote: > > > Hi Jonathan, > > > > Hey Jonathan, > > > > Assuming we are fine with this series, how would you like to proceed. > > Would you be fine with me picking the dmaengine bits and providing a > > signed tag for you to pull? > > > > Hi Vinod, > > Yes. That will work nicely. > From my side it all looks good. Great, here it is: The following changes since commit 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0: Linux 6.10-rc1 (2024-05-26 15:20:12 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git topic/dma_vec_api for you to fetch changes up to 380afccc2a55e8015adae4266e8beff96ab620be: Documentation: dmaengine: Document new dma_vec API (2024-06-21 15:31:57 +0530) Paul Cercueil (3): dmaengine: Add API function dmaengine_prep_peripheral_dma_vec() dmaengine: dma-axi-dmac: Implement device_prep_peripheral_dma_vec Documentation: dmaengine: Document new dma_vec API Documentation/driver-api/dmaengine/client.rst | 9 ++ Documentation/driver-api/dmaengine/provider.rst | 10 +++ drivers/dma/dma-axi-dmac.c | 40 + include/linux/dmaengine.h | 33 4 files changed, 92 insertions(+) Thanks -- ~Vinod signature.asc Description: PGP signature
Re: [PATCH v12 0/7] iio: new DMABUF based API v12
On 21-06-24, 15:38, Vinod Koul wrote: > On 20-06-24, 20:11, Jonathan Cameron wrote: > > On Thu, 20 Jun 2024 21:50:41 +0530 > > Vinod Koul wrote: > > > > > On 20-06-24, 14:27, Paul Cercueil wrote: > > > > Hi Jonathan, > > > > > > Hey Jonathan, > > > > > > Assuming we are fine with this series, how would you like to proceed. > > > Would you be fine with me picking the dmaengine bits and providing a > > > signed tag for you to pull? > > > > > > > Hi Vinod, > > > > Yes. That will work nicely. > > From my side it all looks good. > > Great, here it is: > > The following changes since commit 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0: > > Linux 6.10-rc1 (2024-05-26 15:20:12 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git > topic/dma_vec_api Sorry, sent branch instead of signed tag: here is the signed tag git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git dmaengine_topic_dma_vec > for you to fetch changes up to 380afccc2a55e8015adae4266e8beff96ab620be: > > Documentation: dmaengine: Document new dma_vec API (2024-06-21 15:31:57 > +0530) > > > Paul Cercueil (3): > dmaengine: Add API function dmaengine_prep_peripheral_dma_vec() > dmaengine: dma-axi-dmac: Implement device_prep_peripheral_dma_vec > Documentation: dmaengine: Document new dma_vec API > > Documentation/driver-api/dmaengine/client.rst | 9 ++ > Documentation/driver-api/dmaengine/provider.rst | 10 +++ > drivers/dma/dma-axi-dmac.c | 40 > + > include/linux/dmaengine.h | 33 > 4 files changed, 92 insertions(+) > > > Thanks > -- > ~Vinod -- ~Vinod
Re: [PATCH 00/31] Preparatory patches for BCM2712 (Pi5) support
Morning Maxime On Fri, 21 Jun 2024 at 09:55, Maxime Ripard wrote: > > Hi Dave, > > Thanks for taking the time to send this. > > I've gone through most of the patches and it looks pretty good already, > but I have a few general remarks: > > - We merged in drm-misc-next the new HDMI infrastructure recently and > it will heavily conflict with some of these patches, so you need to > rebase against either linux-next or drm-misc-next. Unless I've really messed up, this is already against drm-misc-next - sorry for not stating that. I've just pulled and rebased again, but I believe the top commit from the tree I created the patches against was c1391205754f drm/tests: add drm_hdmi_state_helper_test MODULE_DESCRIPTION() merged yesterday. I certainly had my VEC patches in the tree. > - The author and SoB fields for my patches don't match anymore, > possibly due to mailmap doing its magic. Too much magic in git :-( I went through and updated all your SoB fields, but mailmap appears to mean that the author shown by git log is not the same as the patches created by git format-patch. Never believe what you see. (That feels like a bug in git format-patch). > You can fix this by using, for the SoB: > git filter-branch --msg-filter 'sed -i > s/max...@cerno.tech/mrip...@kernel.org/' drm-misc-next.. > > And for the authorship: > git commit --amend --author="Maxime Ripard " > for each commit. > > - All of the fixes need Fixes that are currently missing on most tags Just as long as no one tries pulling them all back to stable. The number of dependencies would be huge in many cases. > - And the commit prefix isn't consistent, especially for vc4_plane.c, > the upstream convention so far has been drm/vc4: plane, instead of > drm/vc4_plane. Done. Dave > Maxime > > On Thu, Jun 20, 2024 at 04:46:01PM GMT, Dave Stevenson wrote: > > Hi > > > > This set is a number of minor fixes that we've had downstream for a while, > > and then lays down the some infrastructure changes to facilitate adding > > support > > of BCM2712. I'm just finalising those patches so they should follow on > > fairly > > soon. > > > > Thanks > > Dave > > > > Dave Stevenson (8): > > drm/vc4: Force trigger of dlist update on margins change > > drm/vc4: Set AXI panic modes for the HVS > > drm/vc4: Limit max_bpc to 8 on Pi0-3 > > drm/vc4: Don't write gamma luts on 2711 > > drm/vc4: UV planes vertical scaling must always be enabled > > drm/vc4: Fix dlist debug not resetting the next entry pointer > > drm/vc4: Remove incorrect limit from hvs_dlist debugfs function > > drm/vc4: Move the buffer offset out of the vc4_plane_state > > > > Dom Cobley (7): > > drm/vc4: vc4_plane: Keep fractional source coords inside state > > drm/vc4: Handle fractional coordinates using the phase field > > drm/vc4: hdmi: Avoid log spam for audio start failure > > drm/vc4_plane: Add support for YUV444 formats > > drm/vc4: hdmi: Increase audio MAI fifo dreq threshold > > drm/vc4: hdmi: Avoid hang with debug registers when suspended > > drm/vc4: hvs: Remove ABORT_ON_EMPTY flag > > > > Maxime Ripard (15): > > drm/vc4: hdmi: Warn if writing to an unknown HDMI register > > drm/vc4: hvs: More logging for dlist generation > > drm/vc4: hvs: Print error if we fail an allocation > > drm/vc4: plane: Add more debugging for LBM allocation > > drm/vc4: plane: Use return variable in atomic_check > > drm/vc4: crtc: Move assigned_channel to a variable > > drm/vc4: Introduce generation number enum > > drm/vc4: Make v3d paths unavailable on any generation newer than vc4 > > drm/vc4: hvs: Use switch statement to simplify > > vc4_hvs_get_fifo_from_output > > drm/vc4: hvs: Create hw_init function > > drm/vc4: hvs: Create cob_init function > > drm/vc4: hvs: Rename hvs_regs list > > drm/vc4: plane: Change ptr0_offset to an array > > drm/vc4: hvs: Rework LBM alignment > > drm/vc4: hvs: Change prototype of __vc4_hvs_alloc to pass registers > > > > Tim Gover (1): > > drm/vc4: Enable SCALER_CONTROL early in HVS init > > > > drivers/gpu/drm/vc4/tests/vc4_mock.c | 14 +- > > drivers/gpu/drm/vc4/vc4_bo.c | 28 +- > > drivers/gpu/drm/vc4/vc4_crtc.c | 35 ++- > > drivers/gpu/drm/vc4/vc4_drv.c | 22 +- > > drivers/gpu/drm/vc4/vc4_drv.h | 29 +- > > drivers/gpu/drm/vc4/vc4_gem.c | 24 +- > > drivers/gpu/drm/vc4/vc4_hdmi.c | 30 +- > > drivers/gpu/drm/vc4/vc4_hdmi_regs.h| 5 +- > > drivers/gpu/drm/vc4/vc4_hvs.c | 343 + > > drivers/gpu/drm/vc4/vc4_irq.c | 10 +- > > drivers/gpu/drm/vc4/vc4_kms.c | 14 +- > > drivers/gpu/drm/vc4/vc4_perfmon.c | 20 +- > > drivers/gpu/drm/vc4/vc4_plane.c| 281 +++-- > > drivers/gpu/drm/vc4/vc4_regs.h | 1 + > > drivers/gpu/drm/vc4/vc4_render_cl.c| 2 +- >
Re: [PATCH 06/15] net: hbl_cn: debugfs support
On 6/19/24 21:35, Sunil Kovvuri Goutham wrote: > [Some people who received this message don't often get email from > sgout...@marvell.com. Learn why this is important at > https://aka.ms/LearnAboutSenderIdentification ] > >> + >> +What: /sys/kernel/debug/habanalabs_cn/hbl_cn/nic_disable_decap >> +What: /sys/kernel/debug/habanalabs_cn/hbl_cn/nic_inject_rx_err >> +What: /sys/kernel/debug/habanalabs_cn/hbl_cn/nic_mac_lane_remap > > Don't think debugfs is the correct interface for all this configuration. > Debugfs should ideally be used for dumping runtime device state info for > debug purposes. > I see other vendors have debugfs entries for debug configurations or settings, not just for dumping debug info. >> +What: /sys/kernel/debug/habanalabs_cn/hbl_cn/nic_mac_loopback > > Why not use ethtool ? > We have an ethtool option for that, but we have also internal NIC ports that are not exposed as netdevices and for them the ethtool path is irrelevant. Hence we need this debugfs option as well. >> + >> +What: /sys/kernel/debug/habanalabs_cn/hbl_cn/nic_mmu_bypass > > How does this work ? > When this option is enabled the RDMA data buffers the user allocated on the host memory are being accessed directly i.e. without MMU. But now after you brought this up I see that it is not fully supported anymore so I'll remove in the next version. > Thanks, > Sunil.
Re: [PATCH 13/15] accel/habanalabs: network scaling support
On 6/19/24 21:41, Sunil Kovvuri Goutham wrote: > [Some people who received this message don't often get email from > sgout...@marvell.com. Learn why this is important at > https://aka.ms/LearnAboutSenderIdentification ] > >> >> Add common support for AI scaling over the network. Initialize the hbl_cn >> driver via >> auxiliary bus and serve as its adapter for accessing the device. > > A 1200 line patch deserves a bit more of info in the commit msg. > Can you please elaborate what network scaling support is being added in this > patch. > > Thanks, > Sunil. > Ok, I'll add more details regarding what exactly is added in the next patch set version.
RE: [PATCH 06/15] net: hbl_cn: debugfs support
>>> + >>> +What: /sys/kernel/debug/habanalabs_cn/hbl_cn/nic_disable_decap >>> +What: /sys/kernel/debug/habanalabs_cn/hbl_cn/nic_inject_rx_err >>> +What: >/sys/kernel/debug/habanalabs_cn/hbl_cn/nic_mac_lane_remap >> >> Don't think debugfs is the correct interface for all this configuration. >> Debugfs should ideally be used for dumping runtime device state info for >> debug >purposes. >> > >I see other vendors have debugfs entries for debug configurations or settings, >not >just for dumping debug info. > But disable_decap / mac_lane_remap seems configuration related which changes the way pkts are processed not debug. Configurations are supported via devlink. Thanks, Sunil.
Re: [PATCH 2/6] drm/bridge: tc358767: Use tc_pxl_pll_calc() to correct adjusted_mode clock
Hi Marek, Am Freitag, 21. Juni 2024, 05:30:26 CEST schrieb Marek Vasut: > On 6/11/24 6:45 PM, Marek Vasut wrote: > > On 6/6/24 12:10 PM, Alexander Stein wrote: > >> Hi Marek, > > > > Hello Alexander, > > > > sorry for the delay. > > > >> At least for 148.5MHz (1080p) apparently it is not possible to that > >> exact clock anyway. > > > > Right, which sucks, but the TC9595 datasheet explicitly states that > > the > > FRMSYNC mode should always be enabled (and is apparently force-enabled > > on newer bridge chips with no option to disable it) unless the Pixel > > clock are sourced from DSI clock (which is never the case with this > > driver). That's what the [1] patch does. > > > > But messing with the HFP isn't really working for all resolutions, so > > this patch instead adjusts the input pixel clock to fit the Pixel PLL > > limits, which avoids the VFIFO issues altogether. And that makes the > > FRMSYNC mode work for all kinds of resolutions. > > I can't tell if VFIFO issue arise here, because I'm currently trying to > get a reliable and stable output for DP. > >>> > >>> What kind of problem do you observe on your side exactly ? (I think the > >>> answer to this is at the end). I've spent quite a while on this, so > >>> maybe I ran into that before. > >> > >> DP output either works as expected or not at all. The monitor stays in > >> sleep mode then. I only notice that VFUEN is not cleared in this case. > > > > Let's continue this one at the end of this thread. > > > The documentation is somewhat > limited, but FRAMSYNC seems almost necessary in any case, unless you > utilize DSI bus 100% for this device to get the correct display timings > using DSI packets. > >>> > >>> That's not quite what it says. > >>> > >>> I don't know what kind of datasheet you have and for which exact bridge, > >>> but look at Section 4, block diagram. > >> > >> I have the datasheet 0.1 and 1.1 for TC9595 available. Also the > >> TC358767A_867XBG v37 spreadsheet. > > > > I have rev. 0.1 and rev. 1.3 datasheets for TC9595 . > > I also have TC9595 DSI-to-DPI timing spreadsheet. > > > >>> The FRMSYNC operates on the LS_Clk domain side, right of V_FiFo . It > >>> reads lines from the VFIFO and sends them out of the DP as DP packets. > >>> As long as the input into the VFIFO delivers the lines such that the > >>> VFIFO does not overflow or underflow, everything is fine. > >>> > >>> The DSI side starts to write line into the VFIFO on HSS (Hsync start), > >>> see "DSI Packets for Video Transmission". HSE (Hsync end) packet is > >>> ignored, see "Video Transmission" . Two consecutive HSS must be sent > >>> with the same time between the two as time between two lines configured > >>> into FRMSYNC timing generator. > >>> > >>> However, I _think_ (*) if the time between two HSS is slightly longer > >>> than what the FRMSYNC expects, the FRMSYNC stretches the HFP slightly > >>> for each frame and we won't run into any problems (see 4.12 Clocks and > >>> search for keyword "approximated", they talk about close approximation > >>> there). > >> > >> Which datasheet do you have available? It might just be a typo, but the > >> Clocks section is 4.13 in my case. > > > > Here I used the rev. 1.3 from 20230727 . Definitely section 4.12 in this > > datasheet, maybe they removed a chapter since ? Here is section 4 list: > > > > - MIPI DSI Rx > > - MIPI DPI Rx > > - I2S Audio Rx > > - DisplayPortTM Tx > > - Parallel Output Mode > > - GPIO Interface > > - I2C Slave Interface > > - Interrupt Interface > > - Internal Test Pattern (Color Bar) Generator > > - Reset > > - Boot-Strap & State of TC9595XBG chip after Reset > > - Clocks > > > > You might be wondering why not source pixel clock from DSI HS clock > > and > > disable FRMSYNC. For one thing, this would limit the ability to pick > > faster DSI HS clock and make good use of the DSI burst mode (the DSI > > link can go into LP state after transmitting entire line of pixel data > > for longer with faster DSI HS clock). The other thing is, to drive the > > Pixel PLL (not to be confused with pixel clock) from DSI HS clock, the > > DSI HS clock have to be set to specific clock rates (13*4*7=364 MHz > > and > > 13*4*9=468 MHz), which is really limiting. > >>> > >>> btw. those 13 MHz match one of RefClk input options, the *4 is from > >>> HSBY4 divider and 7 and 9 come from MODE[1] strap option dividers. > >>> > This is not mentioned in the datasheet at all, but just in a small note > in the calculation sheet, without any description. On a different > platform > DSI HS clock running at 445.5MHz seems also possible, even if > unsupported. > >>> > >>> You can use arbitrary DSI HS clock as long as you don't derive RefClk > >>> from DSI HS clock (and RefClk feeds Pixel PLL). > >> > >> Yes, that's what I would expect as well, but that other plat
Re: [PATCH] backlight: Drop explicit initialization of struct i2c_device_id::driver_data to 0
On Wed, Jun 19, 2024 at 09:35:57PM +0200, Uwe Kleine-König wrote: > These drivers don't use the driver_data member of struct i2c_device_id, > so don't explicitly initialize this member. > > This prepares putting driver_data in an anonymous union which requires > either no initialization or named designators. But it's also a nice > cleanup on its own. > > While add it, also remove commas after the sentinel entries. > > Signed-off-by: Uwe Kleine-König Reviewed-by: Daniel Thompson Daniel.
Re: 6.10/bisected/regression - commits bc87d666c05 and 6d4279cb99ac cause appearing green flashing bar on top of screen on Radeon 6900XT and 120Hz
On Fri, Jun 21, 2024 at 12:56 PM Linux regression tracking (Thorsten Leemhuis) wrote: > Hmmm, I might have missed something, but it looks like nothing happened > here since then. What's the status? Is the issue still happening? Yes. Tested on e5b3efbe1ab1. I spotted that the problem disappears after forcing the TV to sleep (activate screensaver + ) and then wake it up by pressing any button and entering a password. Hope this information can't help figure out how to fix it. -- Best Regards, Mike Gavrilov.
Re: [PATCH v1 1/3] dt-bindings: display: st7701: Add Anbernic RG28XX panel
Hello Krzysztof,
Thank you for your reply!
On Tue, Jun 18, 2024 at 6:17 PM Krzysztof Kozlowski wrote:
>
> On 18/06/2024 10:15, Hironori KIKUCHI wrote:
> > The RG28XX panel is a panel specific to the Anbernic RG28XX.
> > It is 2.8 inches in size (diagonally) with a resolution of 480x640.
> >
> > Signed-off-by: Hironori KIKUCHI
> > ---
> > .../display/panel/sitronix,st7701.yaml| 36 +--
> > 1 file changed, 34 insertions(+), 2 deletions(-)
>
> Nothing explains in the commit msg why rg28xx is actually st7701.
> Changing interface to SPI suggests it is not.
Thanks, I'll explain like this;
---
dt-bindings: display: st7701: Add Anbernic RG28XX panel
The RG28XX panel is a panel specific to the Anbernic RG28XX
handheld device. It is 2.8 inches in size (diagonally) with a
resolution of 480x640.
This panel is driven by a variant of ST7701 driver IC internally,
confirmed by dumping and analyzing its BSP initialization sequence
by using a logic analyzer. It is very similar to the existing
densitron,dmt028vghmcmi-1a panel, but differs in some unknown
register values, so add a new entry for the panel to distinguish them.
Additionally, it is connected over SPI, instead of MIPI DSI. So
add and modify for SPI as well.
---
>
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml
> > b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml
> > index b348f5bf0a9..04f6751ccca 100644
> > --- a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml
> > +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml
> > @@ -22,19 +22,21 @@ description: |
> >
> > allOf:
> >- $ref: panel-common.yaml#
> > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> >
> > properties:
> >compatible:
> > items:
> >- enum:
> >- anbernic,rg-arc-panel
> > + - anbernic,rg28xx-panel
>
> What is xx? Wildcards are not allowed, in general.
>
> Can it be anything else than panel? If not, then drop "-panel".
It's supprising but it actually is a product name of the handheld device...
The panel comes with the device, and part# is completely unknown.
>
>
> >- densitron,dmt028vghmcmi-1a
> >- elida,kd50t048a
> >- techstar,ts8550b
> >- const: sitronix,st7701
> >
> >reg:
> > -description: DSI virtual channel used by that screen
> > +description: DSI / SPI channel used by that screen
> > maxItems: 1
> >
> >VCC-supply:
> > @@ -43,6 +45,13 @@ properties:
> >IOVCC-supply:
> > description: I/O system regulator
> >
> > + dc-gpios:
> > +maxItems: 1
> > +description: |
>
> Do not need '|' unless you need to preserve formatting.
Thanks, I'll remove it.
>
> > + Controller data/command selection (D/CX) in 4-line SPI mode.
> > + If not set, the controller is in 3-line SPI mode.
> > + No effect for DSI.
>
> Which devices can be connected over SPI? It seems not all, so this
> should be disallowed (": false" in allOf:if:then:; move the allOf to
> bottom like in example-schema) for them.
Hmm... That's a difficult question...
There are 3 types of connection that trying to support:
DSI, SPI with D/CX pin, and SPI without D/CX pin.
The dc-gpios is required for SPI with D/CX pin, but not for others.
DSI:
- anbernic,rg-arc-panel
- densitron,dmt028vghmcmi-1a
- elida,kd50t048a
- techstar,ts8550b
SPI without D/CX pin:
- anbernic,rg28xx-panel
But, there are no panels with D/CX pin so far.
How should I deal with this? just disallow all, perhaps?
BTW, does panel's compatible string consider to include it's interface?
ie, what if two panels use the exact same commands and timings, but
over different interface,
... are they "compatible" or not?
>
> Best regards,
> Krzysztof
>
Best regards,
kikuchan.
Missing signoffs in the drm-next tree
In today's drm tree commits
824a450c0d90a ("accel/habanalabs: gradual sleep in polling memory macro")
fb0e9ebb93aa9 ("accel/habanalabs: move heartbeat work initialization to early
init")
ee6350c6c3300 ("accel/habanalabs: print timestamp of last PQ heartbeat on EQ
heartbeat failure")
99484a0eadea5 ("accel/habanalabs: dump the EQ entries headers on EQ heartbeat
failure")
aa2b8e98611ed ("accel/habanalabs: revise print on EQ heartbeat failure")
b80d69de0fecd ("accel/habanalabs: add more info upon cpu pkt timeout")
0411d494c6642 ("accel/habanalabs: additional print in device-in-use info")
6d4a9ef47352b ("MAINTAINERS: Change habanalabs maintainer and git repo path")
e8307804e2e10 ("accel/habanalabs: disable EQ interrupt after disabling pci")
5855baed03cf9 ("accel/habanalabs: change the heartbeat scheduling point")
03387d163cdc9 ("accel/habanalabs/gaudi2: unsecure edma max outstanding
register")
920fabafea4bc ("accel/habanalabs: add cpld ts cpld_timestamp cpucp")
30f183a3669cb ("accel/habanalabs: add a common handler for clock change
events")
4ce27da0bd6e7 ("accel/habanalabs: use device-name directory in
debugfs-driver-habanalabs")
65c6b847a8319 ("accel/habanalabs/gaudi2: add GAUDI2D revision support")
6f6323040e650 ("accel/habanalabs: move hl_eq_heartbeat_event_handle() to
common code")
...skipping...
824a450c0d90a ("accel/habanalabs: gradual sleep in polling memory macro")
fb0e9ebb93aa9 ("accel/habanalabs: move heartbeat work initialization to early
init")
ee6350c6c3300 ("accel/habanalabs: print timestamp of last PQ heartbeat on EQ h
eartbeat failure")
99484a0eadea5 ("accel/habanalabs: dump the EQ entries headers on EQ heartbeat
failure")
aa2b8e98611ed ("accel/habanalabs: revise print on EQ heartbeat failure")
b80d69de0fecd ("accel/habanalabs: add more info upon cpu pkt timeout")
0411d494c6642 ("accel/habanalabs: additional print in device-in-use info")
6d4a9ef47352b ("MAINTAINERS: Change habanalabs maintainer and git repo path")
e8307804e2e10 ("accel/habanalabs: disable EQ interrupt after disabling pci")
5855baed03cf9 ("accel/habanalabs: change the heartbeat scheduling point")
03387d163cdc9 ("accel/habanalabs/gaudi2: unsecure edma max outstanding registe
r")
920fabafea4bc ("accel/habanalabs: add cpld ts cpld_timestamp cpucp")
30f183a3669cb ("accel/habanalabs: add a common handler for clock change
events")
4ce27da0bd6e7 ("accel/habanalabs: use device-name directory in
debugfs-driver-habanalabs")
65c6b847a8319 ("accel/habanalabs/gaudi2: add GAUDI2D revision support")
6f6323040e650 ("accel/habanalabs: move hl_eq_heartbeat_event_handle() to
common code")
are missing a Signed-off-by from their committers.
signature.asc
Description: PGP signature
Re: [PATCH 0/8] drm: bridge: dw_hdmi: Misc enable/disable, CEC and EDID cleanup
> On 11 Jun 2024, at 7:50 PM, Jonas Karlman wrote: > > This series ensure poweron/poweroff and CEC phys addr invalidation is > happening under drm mode_config mutex lock, and also ensure EDID is > updated (when the dw-hdmi connector is used) after a hotplug pulse. > > These changes has mainly been tested on Rockchip devices together with a > forthcoming series that add HDMI 2.0 4K@60Hz support to RK3228, RK3328, > RK3399 and RK3568. > > Rockchip use the dw-hdmi connector so this should also be validated with > a driver that use the bridge connector. I’m not sure my level of kernel fiddling counts as proper validation (Neil would be a more authoritative tester) but FWIW, I picked the series to my 6.10-rc4 dev branch (for Amlogic devices supported by the LibreELEC distro) and AFAICT everything is still working. Tested with Amlogic GXBB, GXL and G12B boards. Tested-by: Christian Hewitt > Jonas Karlman (8): > drm: bridge: dw_hdmi: Call poweron/poweroff from atomic enable/disable > drm: bridge: dw_hdmi: Use passed mode instead of stored previous_mode > drm: bridge: dw_hdmi: Fold poweron and setup functions > drm: bridge: dw_hdmi: Remove previous_mode and mode_set > drm: bridge: dw_hdmi: Invalidate CEC phys addr from connector detect > drm: bridge: dw_hdmi: Remove cec_notifier_mutex > drm: bridge: dw_hdmi: Update EDID during hotplug processing > drm: bridge: dw_hdmi: Use display_info is_hdmi and has_audio > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 145 ++ > 1 file changed, 39 insertions(+), 106 deletions(-)
Re: [PATCH RFC 3/5] drm/connector: implement generic HDMI codec helpers
On Fri, 21 Jun 2024 at 12:27, Maxime Ripard wrote:
>
> Hi,
>
> Sorry for taking some time to review this series.
No problem, that's not long.
>
> On Sat, Jun 15, 2024 at 08:53:32PM GMT, Dmitry Baryshkov wrote:
> > Several DRM drivers implement HDMI codec support (despite its name it
> > applies to both HDMI and DisplayPort drivers). Implement generic
> > framework to be used by these drivers. This removes a requirement to
> > implement get_eld() callback and provides default implementation for
> > codec's plug handling.
> >
> > The framework is integrated with the DRM HDMI Connector framework, but
> > can be used by DisplayPort drivers.
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/gpu/drm/Makefile | 1 +
> > drivers/gpu/drm/drm_connector.c| 8 ++
> > drivers/gpu/drm/drm_connector_hdmi_codec.c | 157
> > +
> > include/drm/drm_connector.h| 33 ++
> > 4 files changed, 199 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index 68cc9258ffc4..e113a6eade23 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -45,6 +45,7 @@ drm-y := \
> > drm_client_modeset.o \
> > drm_color_mgmt.o \
> > drm_connector.o \
> > + drm_connector_hdmi_codec.o \
> > drm_crtc.o \
> > drm_displayid.o \
> > drm_drv.o \
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > index 3d73a981004c..66d6e9487339 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -279,6 +279,7 @@ static int __drm_connector_init(struct drm_device *dev,
> > mutex_init(&connector->mutex);
> > mutex_init(&connector->edid_override_mutex);
> > mutex_init(&connector->hdmi.infoframes.lock);
> > + mutex_init(&connector->hdmi_codec.lock);
> > connector->edid_blob_ptr = NULL;
> > connector->epoch_counter = 0;
> > connector->tile_blob_ptr = NULL;
> > @@ -529,6 +530,12 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
> >
> > connector->hdmi.funcs = hdmi_funcs;
> >
> > + if (connector->hdmi_codec.i2s || connector->hdmi_codec.spdif) {
> > + ret = drmm_connector_hdmi_codec_alloc(dev, connector,
> > hdmi_funcs->codec_ops);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > return 0;
> > }
> > EXPORT_SYMBOL(drmm_connector_hdmi_init);
> > @@ -665,6 +672,7 @@ void drm_connector_cleanup(struct drm_connector
> > *connector)
> > connector->funcs->atomic_destroy_state(connector,
> > connector->state);
> >
> > + mutex_destroy(&connector->hdmi_codec.lock);
> > mutex_destroy(&connector->hdmi.infoframes.lock);
> > mutex_destroy(&connector->mutex);
> >
> > diff --git a/drivers/gpu/drm/drm_connector_hdmi_codec.c
> > b/drivers/gpu/drm/drm_connector_hdmi_codec.c
> > new file mode 100644
> > index ..a3a7ad117f6f
> > --- /dev/null
> > +++ b/drivers/gpu/drm/drm_connector_hdmi_codec.c
> > @@ -0,0 +1,157 @@
> > +/*
> > + * Copyright (c) 2024 Linaro Ltd
> > + *
> > + * Permission to use, copy, modify, distribute, and sell this software and
> > its
> > + * documentation for any purpose is hereby granted without fee, provided
> > that
> > + * the above copyright notice appear in all copies and that both that
> > copyright
> > + * notice and this permission notice appear in supporting documentation,
> > and
> > + * that the name of the copyright holders not be used in advertising or
> > + * publicity pertaining to distribution of the software without specific,
> > + * written prior permission. The copyright holders make no representations
> > + * about the suitability of this software for any purpose. It is provided
> > "as
> > + * is" without express or implied warranty.
> > + *
> > + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
> > SOFTWARE,
> > + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
> > + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
> > + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF
> > USE,
> > + * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
> > + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
> > PERFORMANCE
> > + * OF THIS SOFTWARE.
> > + */
> > +
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +static int drm_connector_hdmi_codec_get_eld(struct device *dev, void *data,
> > + uint8_t *buf, size_t len)
> > +{
> > + struct drm_connector *connector = data;
> > +
> > + // FIXME: locking against drm_edid_to_eld ?
> > + memcpy(buf, connector->eld, min(sizeof(connector->eld), len));
> > +
> > + return 0;
> > +}
> > +
> > +static
Re: [PATCH RFC 4/5] drm/bridge: connector: add support for HDMI codec framework
On Fri, 21 Jun 2024 at 12:30, Maxime Ripard wrote:
>
> On Sat, Jun 15, 2024 at 08:53:33PM GMT, Dmitry Baryshkov wrote:
> > Add necessary glue code to be able to use new HDMI codec framework from
> > the DRM bridge drivers. The drm_bridge implements a limited set of the
> > hdmi_codec_ops interface, with the functions accepting both
> > drm_connector and drm_bridge instead of just a generic void pointer.
> >
> > This framework is integrated with the DRM HDMI Connector framework, but
> > can also be used for DisplayPort connectors.
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/gpu/drm/drm_bridge_connector.c | 130
> > -
> > include/drm/drm_bridge.h | 46
> > 2 files changed, 174 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_bridge_connector.c
> > b/drivers/gpu/drm/drm_bridge_connector.c
> > index 0869b663f17e..71d6fdc2391f 100644
> > --- a/drivers/gpu/drm/drm_bridge_connector.c
> > +++ b/drivers/gpu/drm/drm_bridge_connector.c
> > @@ -20,6 +20,8 @@
> > #include
> > #include
> >
> > +#include
> > +
> > /**
> > * DOC: overview
> > *
> > @@ -95,6 +97,14 @@ struct drm_bridge_connector {
> >* HDMI connector infrastructure, if any (see &DRM_BRIDGE_OP_HDMI).
> >*/
> > struct drm_bridge *bridge_hdmi;
> > + /**
> > + * @bridge_hdmi_codec:
> > + *
> > + * The bridge in the chain that implements necessary support for the
> > + * HDMI Audio Codec infrastructure, if any (see
> > + * &DRM_BRIDGE_OP_HDMI_CODEC).
> > + */
> > + struct drm_bridge *bridge_hdmi_codec;
>
> Can we have a setup where one bridge would support the video stream and
> another one the audio?
>
> I think for now I'd rather make them both provided by the same bridge,
> and we can always change that later on if we need to.
The same point here (and for your second comment): DisplayPort audio support.
--
With best wishes
Dmitry
Re: [PATCH v1] misc: fastrpc: Move fastrpc driver to misc/fastrpc/
On Fri, 21 Jun 2024 at 09:19, Bjorn Andersson wrote:
>
> On Wed, Jun 12, 2024 at 09:28:39PM GMT, Dmitry Baryshkov wrote:
> > On Wed, Jun 12, 2024 at 12:17:28PM +0530, Ekansh Gupta wrote:
> > > Move fastrpc.c from misc/ to misc/fastrpc/. New C files are planned
> > > to be added for PD notifications and other missing features. Adding
> > > and maintaining new files from within fastrpc directory would be easy.
> > >
> > > Example of feature that is being planned to be introduced in a new C
> > > file:
> > > https://lore.kernel.org/all/20240606165939.12950-6-quic_ekang...@quicinc.com/
> > >
> > > Signed-off-by: Ekansh Gupta
> > > ---
> > > MAINTAINERS | 2 +-
> > > drivers/misc/Kconfig | 13 +
> > > drivers/misc/Makefile| 2 +-
> > > drivers/misc/fastrpc/Kconfig | 16
> > > drivers/misc/fastrpc/Makefile| 2 ++
> > > drivers/misc/{ => fastrpc}/fastrpc.c | 0
> > > 6 files changed, 21 insertions(+), 14 deletions(-)
> > > create mode 100644 drivers/misc/fastrpc/Kconfig
> > > create mode 100644 drivers/misc/fastrpc/Makefile
> > > rename drivers/misc/{ => fastrpc}/fastrpc.c (100%)
> >
> > Please consider whether it makes sense to move to drivers/accel instead
> > (and possibly writing a better Kconfig entry, specifying that the driver
> > is to be used to offload execution to the DSP).
> >
>
> Wouldn't this come with the expectation of following the ABIs of
> drivers/accel and thereby breaking userspace?
As I wrote earlier, that depends on the accel/ maintainers decision,
whether it's acceptable to have non-DRM_ACCEL code underneath.
But at least I'd try doing that on the grounds of keeping the code at
the proper place in the drivers/ tree, raising awareness of the
FastRPC, etc.
For example current fastrpc driver bypasses dri-devel reviews, while
if I remember correctly, at some point it was suggested that all
dma-buf-handling drivers should also notify the dri-devel ML.
Also having the driver under drivers/accels makes it possible and
logical to implement DRM_ACCEL uAPI at some point. In the ideal world
we should be able to declare existing FastRPC uAPI as legacy /
deprecated / backwards compatibility only and migrate to the
recommended uAPI approach, which is DRM_ACCEL.
--
With best wishes
Dmitry
Re: [PATCH] drm/xe/lnl: Offload system clear page activity to GPU
On 20-06-2024 19:16, Nirmoy Das wrote:
On LNL because flat CCS, driver will create a migrate job to clear
CCS meta data. Extend that to also clear pages using GPU with new
ttm pool flag which allows offloading page clear activity to GP
This gives very nice improvement for large buffer:
Without the patch:
~/igt-gpu-tools/build/tests/xe_exec_store --run basic-store-benchmark
IGT-Version: 1.28-g2ed908c0b (x86_64) (Linux: 6.9.0-xe+ x86_64)
Using IGT_SRANDOM=1718889799 for randomisation
Opened device: /dev/dri/card0
Starting subtest: basic-store-benchmark
Starting dynamic subtest: WC
Dynamic subtest WC: SUCCESS (0.000s)
Time taken for size SZ_4K: 4882 us
Time taken for size SZ_2M: 3679 us
Time taken for size SZ_64M: 13367 us
Time taken for size SZ_128M: 21034 us
Time taken for size SZ_256M: 32940 us
Time taken for size SZ_1G: 116261 us
Starting dynamic subtest: WB
Dynamic subtest WB: SUCCESS (0.000s)
Time taken for size SZ_4K: 5417 us
Time taken for size SZ_2M: 5711 us
Time taken for size SZ_64M: 15718 us
Time taken for size SZ_128M: 26170 us
Time taken for size SZ_256M: 50529 us
Time taken for size SZ_1G: 177933 us
Subtest basic-store-benchmark: SUCCESS (0.504s)
With the patch:
sudo ~/igt-gpu-tools/build/tests/xe_exec_store --run basic-store-benchmark
IGT-Version: 1.28-g2ed908c0b (x86_64) (Linux: 6.9.0-xe+ x86_64)
Using IGT_SRANDOM=1718889593 for randomisation
Opened device: /dev/dri/card0
Starting subtest: basic-store-benchmark
Starting dynamic subtest: WC
Dynamic subtest WC: SUCCESS (0.000s)
Time taken for size SZ_4K: 4479 us
Time taken for size SZ_2M: 3291 us
Time taken for size SZ_64M: 6595 us
Time taken for size SZ_128M: 9069 us
Time taken for size SZ_256M: 12681 us
Time taken for size SZ_1G: 41806 us
Starting dynamic subtest: WB
Dynamic subtest WB: SUCCESS (0.000s)
Time taken for size SZ_4K: 3317 us
Time taken for size SZ_2M: 6458 us
Time taken for size SZ_64M: 12802 us
Time taken for size SZ_128M: 19579 us
Time taken for size SZ_256M: 38768 us
Time taken for size SZ_1G: 143250 us
Subtest basic-store-benchmark: SUCCESS (0.328s)
Cc: Christian Koenig
Cc: "Thomas Hellström"
Cc: Matthew Auld
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/xe/xe_bo.c | 4
drivers/gpu/drm/xe/xe_device.c | 36 +---
drivers/gpu/drm/xe/xe_device_types.h | 2 ++
drivers/gpu/drm/xe/xe_migrate.c | 6 ++---
4 files changed, 37 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
index 65c696966e96..10ec02412dc4 100644
--- a/drivers/gpu/drm/xe/xe_bo.c
+++ b/drivers/gpu/drm/xe/xe_bo.c
@@ -387,6 +387,10 @@ static struct ttm_tt *xe_ttm_tt_create(struct
ttm_buffer_object *ttm_bo,
caching = ttm_uncached;
}
+ /* Clear TTM_TT_FLAG_ZERO_ALLOC when GPU is set to clear pages */
+ if (xe->mem.gpu_page_clear)
+ page_flags &= ~TTM_TT_FLAG_ZERO_ALLOC;
+
err = ttm_tt_init(&tt->ttm, &bo->ttm, page_flags, caching, extra_pages);
if (err) {
kfree(tt);
diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
index 75d4c8ae9234..8e8d54c59aae 100644
--- a/drivers/gpu/drm/xe/xe_device.c
+++ b/drivers/gpu/drm/xe/xe_device.c
@@ -240,8 +240,6 @@ static void xe_device_destroy(struct drm_device *dev, void
*dummy)
if (xe->unordered_wq)
destroy_workqueue(xe->unordered_wq);
-
- ttm_device_fini(&xe->ttm);
}
struct xe_device *xe_device_create(struct pci_dev *pdev,
@@ -260,12 +258,6 @@ struct xe_device *xe_device_create(struct pci_dev *pdev,
if (IS_ERR(xe))
return xe;
- err = ttm_device_init(&xe->ttm, &xe_ttm_funcs, xe->drm.dev,
- xe->drm.anon_inode->i_mapping,
- xe->drm.vma_offset_manager, false, false);
- if (WARN_ON(err))
- goto err;
-
err = drmm_add_action_or_reset(&xe->drm, xe_device_destroy, NULL);
if (err)
goto err;
@@ -543,6 +535,13 @@ static int xe_device_set_has_flat_ccs(struct xe_device
*xe)
return xe_force_wake_put(gt_to_fw(gt), XE_FW_GT);
}
+static void xe_device_destroy_ttm_device(struct drm_device *dev, void *dummy)
+{
+ struct xe_device *xe = to_xe_device(dev);
+
+ ttm_device_fini(&xe->ttm);
+}
+
int xe_device_probe(struct xe_device *xe)
{
struct xe_tile *tile;
@@ -550,6 +549,7 @@ int xe_device_probe(struct xe_device *xe)
int err;
u8 last_gt;
u8 id;
+ unsigned int ttm_pool_flags = 0;
xe_pat_init_early(xe);
@@ -572,6 +572,26 @@ int xe_device_probe(struct xe_device *xe)
xe_ttm_sys_mgr_init(xe);
+ /* On iGFX device with flat CCS we clear CCS metadata, let's extend that
+* and use GPU to clear pages as well.
+*/
+ if (xe_device_has_flat_ccs(xe) && !IS_DGFX(xe)) {
+ ttm_pool_flags = TTM_POOL_FLAG_SKIP_CLEAR_ON_FREE;
+ xe->mem.gpu_pa
Re: [PATCH] drm/xe/lnl: Offload system clear page activity to GPU
On 6/21/2024 2:08 PM, Ghimiray, Himal Prasad wrote:
On 20-06-2024 19:16, Nirmoy Das wrote:
On LNL because flat CCS, driver will create a migrate job to clear
CCS meta data. Extend that to also clear pages using GPU with new
ttm pool flag which allows offloading page clear activity to GP
This gives very nice improvement for large buffer:
Without the patch:
~/igt-gpu-tools/build/tests/xe_exec_store --run basic-store-benchmark
IGT-Version: 1.28-g2ed908c0b (x86_64) (Linux: 6.9.0-xe+ x86_64)
Using IGT_SRANDOM=1718889799 for randomisation
Opened device: /dev/dri/card0
Starting subtest: basic-store-benchmark
Starting dynamic subtest: WC
Dynamic subtest WC: SUCCESS (0.000s)
Time taken for size SZ_4K: 4882 us
Time taken for size SZ_2M: 3679 us
Time taken for size SZ_64M: 13367 us
Time taken for size SZ_128M: 21034 us
Time taken for size SZ_256M: 32940 us
Time taken for size SZ_1G: 116261 us
Starting dynamic subtest: WB
Dynamic subtest WB: SUCCESS (0.000s)
Time taken for size SZ_4K: 5417 us
Time taken for size SZ_2M: 5711 us
Time taken for size SZ_64M: 15718 us
Time taken for size SZ_128M: 26170 us
Time taken for size SZ_256M: 50529 us
Time taken for size SZ_1G: 177933 us
Subtest basic-store-benchmark: SUCCESS (0.504s)
With the patch:
sudo ~/igt-gpu-tools/build/tests/xe_exec_store --run
basic-store-benchmark
IGT-Version: 1.28-g2ed908c0b (x86_64) (Linux: 6.9.0-xe+ x86_64)
Using IGT_SRANDOM=1718889593 for randomisation
Opened device: /dev/dri/card0
Starting subtest: basic-store-benchmark
Starting dynamic subtest: WC
Dynamic subtest WC: SUCCESS (0.000s)
Time taken for size SZ_4K: 4479 us
Time taken for size SZ_2M: 3291 us
Time taken for size SZ_64M: 6595 us
Time taken for size SZ_128M: 9069 us
Time taken for size SZ_256M: 12681 us
Time taken for size SZ_1G: 41806 us
Starting dynamic subtest: WB
Dynamic subtest WB: SUCCESS (0.000s)
Time taken for size SZ_4K: 3317 us
Time taken for size SZ_2M: 6458 us
Time taken for size SZ_64M: 12802 us
Time taken for size SZ_128M: 19579 us
Time taken for size SZ_256M: 38768 us
Time taken for size SZ_1G: 143250 us
Subtest basic-store-benchmark: SUCCESS (0.328s)
Cc: Christian Koenig
Cc: "Thomas Hellström"
Cc: Matthew Auld
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/xe/xe_bo.c | 4
drivers/gpu/drm/xe/xe_device.c | 36 +---
drivers/gpu/drm/xe/xe_device_types.h | 2 ++
drivers/gpu/drm/xe/xe_migrate.c | 6 ++---
4 files changed, 37 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
index 65c696966e96..10ec02412dc4 100644
--- a/drivers/gpu/drm/xe/xe_bo.c
+++ b/drivers/gpu/drm/xe/xe_bo.c
@@ -387,6 +387,10 @@ static struct ttm_tt *xe_ttm_tt_create(struct
ttm_buffer_object *ttm_bo,
caching = ttm_uncached;
}
+ /* Clear TTM_TT_FLAG_ZERO_ALLOC when GPU is set to clear pages */
+ if (xe->mem.gpu_page_clear)
+ page_flags &= ~TTM_TT_FLAG_ZERO_ALLOC;
+
err = ttm_tt_init(&tt->ttm, &bo->ttm, page_flags, caching,
extra_pages);
if (err) {
kfree(tt);
diff --git a/drivers/gpu/drm/xe/xe_device.c
b/drivers/gpu/drm/xe/xe_device.c
index 75d4c8ae9234..8e8d54c59aae 100644
--- a/drivers/gpu/drm/xe/xe_device.c
+++ b/drivers/gpu/drm/xe/xe_device.c
@@ -240,8 +240,6 @@ static void xe_device_destroy(struct drm_device
*dev, void *dummy)
if (xe->unordered_wq)
destroy_workqueue(xe->unordered_wq);
-
- ttm_device_fini(&xe->ttm);
}
struct xe_device *xe_device_create(struct pci_dev *pdev,
@@ -260,12 +258,6 @@ struct xe_device *xe_device_create(struct
pci_dev *pdev,
if (IS_ERR(xe))
return xe;
- err = ttm_device_init(&xe->ttm, &xe_ttm_funcs, xe->drm.dev,
- xe->drm.anon_inode->i_mapping,
- xe->drm.vma_offset_manager, false, false);
- if (WARN_ON(err))
- goto err;
-
err = drmm_add_action_or_reset(&xe->drm, xe_device_destroy, NULL);
if (err)
goto err;
@@ -543,6 +535,13 @@ static int xe_device_set_has_flat_ccs(struct
xe_device *xe)
return xe_force_wake_put(gt_to_fw(gt), XE_FW_GT);
}
+static void xe_device_destroy_ttm_device(struct drm_device *dev,
void *dummy)
+{
+ struct xe_device *xe = to_xe_device(dev);
+
+ ttm_device_fini(&xe->ttm);
+}
+
int xe_device_probe(struct xe_device *xe)
{
struct xe_tile *tile;
@@ -550,6 +549,7 @@ int xe_device_probe(struct xe_device *xe)
int err;
u8 last_gt;
u8 id;
+ unsigned int ttm_pool_flags = 0;
xe_pat_init_early(xe);
@@ -572,6 +572,26 @@ int xe_device_probe(struct xe_device *xe)
xe_ttm_sys_mgr_init(xe);
+ /* On iGFX device with flat CCS we clear CCS metadata, let's
extend that
+ * and use GPU to clear pages as well.
+ */
+ if (xe_device_has_flat_ccs(xe) && !IS_DGFX(xe)) {
+ ttm_pool_flags = TTM_POOL_FLAG_SKIP_CLEAR_ON_FREE;
+ xe->mem.gpu_page_clear = true;
+ }
+
+ err = ttm_device_init_with
Re: [PATCH v6 12/16] ASoC: codecs: add MT6357 support
On Wed, Jun 19, 2024 at 04:46:48PM +0200, amerg...@baylibre.com wrote:
> + /* gain default values*/
> + regmap_update_bits(priv->regmap, MT6357_AUDENC_ANA_CON0,
> MT6357_AUDPREAMPLGAIN_MASK,
> +UL_GAIN_0DB << MT6357_AUDPREAMPLGAIN_SFT);
> + regmap_update_bits(priv->regmap, MT6357_AUDENC_ANA_CON1,
> MT6357_AUDPREAMPRGAIN_MASK,
> +UL_GAIN_0DB << MT6357_AUDPREAMPRGAIN_SFT);
> +
> + regmap_update_bits(priv->regmap, MT6357_ZCD_CON1,
> +MT6357_AUD_LOL_GAIN_MASK |
> +MT6357_AUD_LOR_GAIN_MASK,
> +DL_GAIN_0DB << MT6357_AUD_LOL_GAIN_SFT |
> +DL_GAIN_0DB << MT6357_AUD_LOR_GAIN_SFT);
> +
> + regmap_update_bits(priv->regmap, MT6357_ZCD_CON2,
> +MT6357_AUD_HPL_GAIN_MASK |
> +MT6357_AUD_HPR_GAIN_MASK,
> +DL_GAIN_0DB << MT6357_AUD_HPL_GAIN_SFT |
> +DL_GAIN_0DB << MT6357_AUD_HPR_GAIN_SFT);
> +
> + regmap_update_bits(priv->regmap, MT6357_ZCD_CON3,
> +MT6357_AUD_HS_GAIN_MASK, DL_GAIN_0DB);
We generally leave everything at chip defaults, why is this different?
> +static int mt6357_codec_probe(struct snd_soc_component *codec)
> +{
> + struct mt6357_priv *priv = snd_soc_component_get_drvdata(codec);
> +
> + mt6357_codec_init(priv);
> + return 0;
> +}
Why not just inline mt6357_codec_init() into the one user?
> +static unsigned int mt6357_read(struct snd_soc_component *codec, unsigned
> int reg)
> +{
> + struct mt6357_priv *priv = snd_soc_component_get_drvdata(codec);
> + unsigned int val;
> +
> + regmap_read(priv->regmap, reg, &val);
> + return val;
> +}
> +
> +static int mt6357_write(struct snd_soc_component *codec, unsigned int reg,
> unsigned int value)
> +{
> + struct mt6357_priv *priv = snd_soc_component_get_drvdata(codec);
> +
> + return regmap_update_bits(priv->regmap, reg, 0x, value);
> +}
Why open code these, the core has standard adaptors for regmap?
> +static const u32 micbias_values[MT6357_MICBIAS_ARRAY_SIZE] = {
> + 170, 180, 190, 200,
> + 210, 250, 260, 270
> +};
Just use ARRAY_SIZE() for the size then the number can't be out of sync.
signature.asc
Description: PGP signature
[PATCH v2] drm/xe/lnl: Offload system clear page activity to GPU
On LNL because of flat CCS, driver creates a migrate job to clear
CCS meta data. Extend that to also clear system pages using GPU.
Inform TTM to allocate pages without __GFP_ZERO to avoid double page
clearing by clearing out TTM_TT_FLAG_ZERO_ALLOC flag.
v2: Handle regression on dgfx(Himal)
Update commit message as no ttm API changes needed.
Cc: Himal Prasad Ghimiray
Cc: Matthew Auld
Cc: "Thomas Hellström"
Signed-off-by: Nirmoy Das
O
---
drivers/gpu/drm/xe/xe_bo.c | 4
drivers/gpu/drm/xe/xe_device.c | 7 +++
drivers/gpu/drm/xe/xe_device_types.h | 2 ++
drivers/gpu/drm/xe/xe_migrate.c | 5 +++--
4 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
index 65c696966e96..10ec02412dc4 100644
--- a/drivers/gpu/drm/xe/xe_bo.c
+++ b/drivers/gpu/drm/xe/xe_bo.c
@@ -387,6 +387,10 @@ static struct ttm_tt *xe_ttm_tt_create(struct
ttm_buffer_object *ttm_bo,
caching = ttm_uncached;
}
+ /* Clear TTM_TT_FLAG_ZERO_ALLOC when GPU is set to clear pages */
+ if (xe->mem.gpu_page_clear)
+ page_flags &= ~TTM_TT_FLAG_ZERO_ALLOC;
+
err = ttm_tt_init(&tt->ttm, &bo->ttm, page_flags, caching, extra_pages);
if (err) {
kfree(tt);
diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
index 0d57eea8f083..b9ed30c84418 100644
--- a/drivers/gpu/drm/xe/xe_device.c
+++ b/drivers/gpu/drm/xe/xe_device.c
@@ -636,6 +636,13 @@ int xe_device_probe(struct xe_device *xe)
if (err)
goto err_irq_shutdown;
+ /**
+* On iGFX device with flat CCS, we clear CCS metadata, let's extend
that
+* and use GPU to clear pages as well.
+*/
+ if (xe_device_has_flat_ccs(xe) && !IS_DGFX(xe))
+ xe->mem.gpu_page_clear = true;
+
err = xe_vram_probe(xe);
if (err)
goto err_irq_shutdown;
diff --git a/drivers/gpu/drm/xe/xe_device_types.h
b/drivers/gpu/drm/xe/xe_device_types.h
index c37be471d11c..ece68c6f3668 100644
--- a/drivers/gpu/drm/xe/xe_device_types.h
+++ b/drivers/gpu/drm/xe/xe_device_types.h
@@ -325,6 +325,8 @@ struct xe_device {
struct xe_mem_region vram;
/** @mem.sys_mgr: system TTM manager */
struct ttm_resource_manager sys_mgr;
+ /** @gpu_page_clear: clear pages offloaded to GPU */
+ bool gpu_page_clear;
} mem;
/** @sriov: device level virtualization data */
diff --git a/drivers/gpu/drm/xe/xe_migrate.c b/drivers/gpu/drm/xe/xe_migrate.c
index 05f933787860..7acf471a1a40 100644
--- a/drivers/gpu/drm/xe/xe_migrate.c
+++ b/drivers/gpu/drm/xe/xe_migrate.c
@@ -1003,6 +1003,7 @@ struct dma_fence *xe_migrate_clear(struct xe_migrate *m,
struct xe_gt *gt = m->tile->primary_gt;
struct xe_device *xe = gt_to_xe(gt);
bool clear_system_ccs = (xe_bo_needs_ccs_pages(bo) && !IS_DGFX(xe)) ?
true : false;
+ bool clear_on_create = xe->mem.gpu_page_clear || clear_vram;
struct dma_fence *fence = NULL;
u64 size = bo->size;
struct xe_res_cursor src_it;
@@ -1032,7 +1033,7 @@ struct dma_fence *xe_migrate_clear(struct xe_migrate *m,
batch_size = 2 +
pte_update_size(m, clear_vram, src, &src_it,
&clear_L0, &clear_L0_ofs, &clear_L0_pt,
- clear_system_ccs ? 0 :
emit_clear_cmd_len(gt), 0,
+ !clear_on_create ? 0 :
emit_clear_cmd_len(gt), 0,
avail_pts);
if (xe_device_has_flat_ccs(xe))
@@ -1060,7 +1061,7 @@ struct dma_fence *xe_migrate_clear(struct xe_migrate *m,
bb->cs[bb->len++] = MI_BATCH_BUFFER_END;
update_idx = bb->len;
- if (!clear_system_ccs)
+ if (clear_on_create)
emit_clear(gt, bb, clear_L0_ofs, clear_L0,
XE_PAGE_SIZE, clear_vram);
if (xe_device_has_flat_ccs(xe)) {
--
2.42.0
Re: [PATCH] drm/ssd130x: Add drm_panic support
On 21/06/2024 00:22, Javier Martinez Canillas wrote:
Add support for the drm_panic infrastructure, which allows to display
a user friendly message on the screen when a Linux kernel panic occurs.
The display controller doesn't scanout the framebuffer, but instead the
pixels are sent to the device using a transport bus. For this reason, a
.panic_flush handler is needed to flush the panic image to the display.
Thanks for this patch, that's really cool that drm_panic can work on
this device too.
Signed-off-by: Javier Martinez Canillas
---
drivers/gpu/drm/solomon/ssd130x.c | 64 +++
1 file changed, 64 insertions(+)
diff --git a/drivers/gpu/drm/solomon/ssd130x.c
b/drivers/gpu/drm/solomon/ssd130x.c
index 6f51bcf774e2..0bac97bd39b9 100644
--- a/drivers/gpu/drm/solomon/ssd130x.c
+++ b/drivers/gpu/drm/solomon/ssd130x.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include "ssd130x.h"
@@ -1386,6 +1387,63 @@ static void ssd133x_primary_plane_atomic_disable(struct
drm_plane *plane,
drm_dev_exit(idx);
}
+static int ssd130x_primary_plane_helper_get_scanout_buffer(struct drm_plane *plane,
+ struct
drm_scanout_buffer *sb)
+{
+ struct drm_plane_state *plane_state = plane->state;
+ struct drm_shadow_plane_state *shadow_plane_state;
+
+ if (!plane_state || !plane_state->fb || !plane_state->crtc)
+ return -EINVAL;
+
+ shadow_plane_state = to_drm_shadow_plane_state(plane_state);
+
+ sb->format = plane->state->fb->format;
+ sb->width = plane->state->fb->width;
+ sb->height = plane->state->fb->height;
+ sb->pitch[0] = plane->state->fb->pitches[0];
+ sb->map[0] = shadow_plane_state->data[0];
+
+ return 0;
+}
+
+static void ssd130x_primary_plane_helper_panic_flush(struct drm_plane *plane)
+{
+ struct drm_plane_state *plane_state = plane->state;
+ struct ssd130x_plane_state *ssd130x_plane_state =
to_ssd130x_plane_state(plane_state);
+ struct drm_shadow_plane_state *shadow_plane_state =
to_drm_shadow_plane_state(plane_state);
+ struct drm_crtc *crtc = plane_state->crtc;
+ struct ssd130x_crtc_state *ssd130x_crtc_state =
to_ssd130x_crtc_state(crtc->state);
+
+ ssd130x_fb_blit_rect(plane_state->fb, &shadow_plane_state->data[0],
&plane_state->dst,
+ssd130x_plane_state->buffer,
ssd130x_crtc_state->data_array,
+&shadow_plane_state->fmtcnv_state);
ssd130x_fb_blit_rect() will call regmap->write(), which involve mutex
and might sleep. And if the mutex is taken when the panic occurs, it
might deadlock the panic handling.
One solution would be to configure the regmap with config->fast_io and
config->use_raw_spinlock, and check that the lock is available with
try_lock(map->raw_spin_lock)
But that means it will waste cpu cycle with busy waiting for normal
operation, which is not good.
So for this particular device, I think it's ok, because it's unlikely
you'll run kdump or other kernel panic handlers.
But I would like to know what others think about it, and if it's
acceptable or not.
--
Jocelyn
+}
+
+static void ssd132x_primary_plane_helper_panic_flush(struct drm_plane *plane)
+{
+ struct drm_plane_state *plane_state = plane->state;
+ struct ssd130x_plane_state *ssd130x_plane_state =
to_ssd130x_plane_state(plane_state);
+ struct drm_shadow_plane_state *shadow_plane_state =
to_drm_shadow_plane_state(plane_state);
+ struct drm_crtc *crtc = plane_state->crtc;
+ struct ssd130x_crtc_state *ssd130x_crtc_state =
to_ssd130x_crtc_state(crtc->state);
+
+ ssd132x_fb_blit_rect(plane_state->fb, &shadow_plane_state->data[0],
&plane_state->dst,
+ssd130x_plane_state->buffer,
ssd130x_crtc_state->data_array,
+&shadow_plane_state->fmtcnv_state);
+}
+
+static void ssd133x_primary_plane_helper_panic_flush(struct drm_plane *plane)
+{
+ struct drm_plane_state *plane_state = plane->state;
+ struct drm_shadow_plane_state *shadow_plane_state =
to_drm_shadow_plane_state(plane_state);
+ struct drm_crtc *crtc = plane_state->crtc;
+ struct ssd130x_crtc_state *ssd130x_crtc_state =
to_ssd130x_crtc_state(crtc->state);
+
+ ssd133x_fb_blit_rect(plane_state->fb, &shadow_plane_state->data[0],
&plane_state->dst,
+ssd130x_crtc_state->data_array,
&shadow_plane_state->fmtcnv_state);
+}
+
/* Called during init to allocate the plane's atomic state. */
static void ssd130x_primary_plane_reset(struct drm_plane *plane)
{
@@ -1442,18 +1500,24 @@ static const struct drm_plane_helper_funcs
ssd130x_primary_plane_helper_funcs[]
.atomic_check = ssd130x_primary_plane_atomic_check,
.atomic_update = ssd130x_primary_plane_atomic_update,
.atomic_disabl
[PATCH] drm/panel: asus-z00t-tm5p5-n35596: transition to mipi_dsi wrapped functions
Use functions introduced in commit 966e397e4f60 ("drm/mipi-dsi:
Introduce mipi_dsi_*_write_seq_multi()") and commit f79d6d28d8fe
("drm/mipi-dsi: wrap more functions for streamline handling") for the
asus-z00t-tm5p5-n35596 panel.
Signed-off-by: Tejas Vipin
---
.../drm/panel/panel-asus-z00t-tm5p5-n35596.c | 140 --
1 file changed, 59 insertions(+), 81 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 bcaa63d1955f..b05a663c134c 100644
--- a/drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c
+++ b/drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c
@@ -33,119 +33,97 @@ static void tm5p5_nt35596_reset(struct tm5p5_nt35596 *ctx)
usleep_range(15000, 16000);
}
-static int tm5p5_nt35596_on(struct tm5p5_nt35596 *ctx)
+static void tm5p5_nt35596_on(struct mipi_dsi_multi_context *dsi_ctx)
{
- struct mipi_dsi_device *dsi = ctx->dsi;
-
- mipi_dsi_generic_write_seq(dsi, 0xff, 0x05);
- mipi_dsi_generic_write_seq(dsi, 0xfb, 0x01);
- mipi_dsi_generic_write_seq(dsi, 0xc5, 0x31);
- mipi_dsi_generic_write_seq(dsi, 0xff, 0x04);
- mipi_dsi_generic_write_seq(dsi, 0x01, 0x84);
- mipi_dsi_generic_write_seq(dsi, 0x05, 0x25);
- mipi_dsi_generic_write_seq(dsi, 0x06, 0x01);
- mipi_dsi_generic_write_seq(dsi, 0x07, 0x20);
- mipi_dsi_generic_write_seq(dsi, 0x08, 0x06);
- mipi_dsi_generic_write_seq(dsi, 0x09, 0x08);
- mipi_dsi_generic_write_seq(dsi, 0x0a, 0x10);
- mipi_dsi_generic_write_seq(dsi, 0x0b, 0x10);
- mipi_dsi_generic_write_seq(dsi, 0x0c, 0x10);
- mipi_dsi_generic_write_seq(dsi, 0x0d, 0x14);
- mipi_dsi_generic_write_seq(dsi, 0x0e, 0x14);
- mipi_dsi_generic_write_seq(dsi, 0x0f, 0x14);
- mipi_dsi_generic_write_seq(dsi, 0x10, 0x14);
- mipi_dsi_generic_write_seq(dsi, 0x11, 0x14);
- mipi_dsi_generic_write_seq(dsi, 0x12, 0x14);
- mipi_dsi_generic_write_seq(dsi, 0x17, 0xf3);
- mipi_dsi_generic_write_seq(dsi, 0x18, 0xc0);
- mipi_dsi_generic_write_seq(dsi, 0x19, 0xc0);
- mipi_dsi_generic_write_seq(dsi, 0x1a, 0xc0);
- mipi_dsi_generic_write_seq(dsi, 0x1b, 0xb3);
- mipi_dsi_generic_write_seq(dsi, 0x1c, 0xb3);
- mipi_dsi_generic_write_seq(dsi, 0x1d, 0xb3);
- mipi_dsi_generic_write_seq(dsi, 0x1e, 0xb3);
- mipi_dsi_generic_write_seq(dsi, 0x1f, 0xb3);
- mipi_dsi_generic_write_seq(dsi, 0x20, 0xb3);
- mipi_dsi_generic_write_seq(dsi, 0xfb, 0x01);
- mipi_dsi_generic_write_seq(dsi, 0xff, 0x00);
- mipi_dsi_generic_write_seq(dsi, 0xfb, 0x01);
- mipi_dsi_generic_write_seq(dsi, 0x35, 0x01);
- mipi_dsi_generic_write_seq(dsi, 0xd3, 0x06);
- mipi_dsi_generic_write_seq(dsi, 0xd4, 0x04);
- mipi_dsi_generic_write_seq(dsi, 0x5e, 0x0d);
- mipi_dsi_generic_write_seq(dsi, 0x11, 0x00);
- msleep(100);
- mipi_dsi_generic_write_seq(dsi, 0x29, 0x00);
- mipi_dsi_generic_write_seq(dsi, 0x53, 0x24);
-
- return 0;
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0xff, 0x05);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0xfb, 0x01);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0xc5, 0x31);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0xff, 0x04);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0x01, 0x84);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0x05, 0x25);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0x06, 0x01);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0x07, 0x20);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0x08, 0x06);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0x09, 0x08);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0x0a, 0x10);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0x0b, 0x10);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0x0c, 0x10);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0x0d, 0x14);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0x0e, 0x14);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0x0f, 0x14);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0x10, 0x14);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0x11, 0x14);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0x12, 0x14);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0x17, 0xf3);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0x18, 0xc0);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0x19, 0xc0);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0x1a, 0xc0);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0x1b, 0xb3);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0x1c, 0xb3);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0x1d, 0xb3);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0x1e, 0xb3);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0x1f, 0xb3);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0x20, 0xb3);
+ mipi_dsi_generic_write_seq_multi(dsi_ctx, 0xfb, 0x01);
+ mipi_dsi_generic_write_seq_
[PATCH v2 1/2] MAINTAINERS: drm: vc4: Add Raspberry Pi as maintainers
Add myself as maintainer for VC4 alongside Maxime, and our internal review list as reviewer. Signed-off-by: Dave Stevenson --- v1->v2 Changed the internal list from M to R. MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index d1566c647a50..8dabcb16d29f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7520,6 +7520,8 @@ F:include/uapi/drm/v3d_drm.h DRM DRIVERS FOR VC4 M: Maxime Ripard +M: Dave Stevenson +R: Raspberry Pi Kernel Maintenance S: Supported T: git git://github.com/anholt/linux T: git https://gitlab.freedesktop.org/drm/misc/kernel.git -- 2.34.1
[PATCH v2 2/2] MAINTAINERS: drm: vc4: Drop Emma's tree
Emma stepped back from VC4 maintenance a while ago, and all patches are now merged through drm-misc. Drop Emma's tree from MAINTAINERS. Signed-off-by: Dave Stevenson --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 8dabcb16d29f..3fb03de446c3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7523,7 +7523,6 @@ M:Maxime Ripard M: Dave Stevenson R: Raspberry Pi Kernel Maintenance S: Supported -T: git git://github.com/anholt/linux T: git https://gitlab.freedesktop.org/drm/misc/kernel.git F: Documentation/devicetree/bindings/display/brcm,bcm2835-*.yaml F: drivers/gpu/drm/vc4/ -- 2.34.1
linux-next: manual merge of the drm tree with the drm-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_init.c
between commit:
c03d770c0b014 ("drm/amd/display: Attempt to avoid empty TUs when endpoint is
DPIA")
from the drm-fixes tree and commits:
47745acc5e8dd ("drm/amd/display: Add trigger FIFO resync path for DCN35")
0127f0445f7c1 ("drm/amd/display: Refactor input mode programming for DIG
FIFO")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_init.c
b/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_init.c
index 199781233fd5f..30e6a63988391 100644
--- a/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_init.c
+++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn35/dcn35_init.c
@@ -157,8 +160,8 @@ static const struct hwseq_private_funcs dcn35_private_funcs
= {
.set_mcm_luts = dcn32_set_mcm_luts,
.setup_hpo_hw_control = dcn35_setup_hpo_hw_control,
.calculate_dccg_k1_k2_values = dcn32_calculate_dccg_k1_k2_values,
- .set_pixels_per_cycle = dcn32_set_pixels_per_cycle,
- .is_dp_dig_pixel_rate_div_policy =
dcn35_is_dp_dig_pixel_rate_div_policy,
+ .resync_fifo_dccg_dio = dcn314_resync_fifo_dccg_dio,
+ .is_dp_dig_pixel_rate_div_policy =
dcn32_is_dp_dig_pixel_rate_div_policy,
.dsc_pg_control = dcn35_dsc_pg_control,
.dsc_pg_status = dcn32_dsc_pg_status,
.enable_plane = dcn35_enable_plane,
signature.asc
Description: PGP signature
Re: [PATCH RESEND v3 3/3] drm/stm: dsi: expose DSI PHY internal clock
Hi Raphael,
thanks for the patch.
Acked-by: Yannick Fertre
Tested-by: Yannick Fertre
BR
Le 29/01/2024 à 11:41, Raphael Gallais-Pou a écrit :
DSISRC __
__\_
|\
pll4_p_ck ->| 1 |dsi_k
ck_dsi_phy ->| 0 |
|/
A DSI clock is missing in the clock framework. Looking at the
clk_summary, it appears that 'ck_dsi_phy' is not implemented. Since the
DSI kernel clock is based on the internal DSI pll. The common clock
driver can not directly expose this 'ck_dsi_phy' clock because it does
not contain any common registers with the DSI. Thus it needs to be done
directly within the DSI phy driver.
Signed-off-by: Raphael Gallais-Pou
---
Changes in v3:
- Fix smatch warning:
.../dw_mipi_dsi-stm.c:719 dw_mipi_dsi_stm_probe() warn: 'dsi->pclk'
from clk_prepare_enable() not released on lines: 719.
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 247 ++
1 file changed, 216 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index 82fff9e84345..b20123854c4a 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -7,7 +7,9 @@
*/
#include
+#include
#include
+#include
#include
#include
#include
@@ -77,9 +79,12 @@ enum dsi_color {
struct dw_mipi_dsi_stm {
void __iomem *base;
+ struct device *dev;
struct clk *pllref_clk;
struct clk *pclk;
+ struct clk_hw txbyte_clk;
struct dw_mipi_dsi *dsi;
+ struct dw_mipi_dsi_plat_data pdata;
u32 hw_version;
int lane_min_kbps;
int lane_max_kbps;
@@ -196,29 +201,198 @@ static int dsi_pll_get_params(struct dw_mipi_dsi_stm
*dsi,
return 0;
}
-static int dw_mipi_dsi_phy_init(void *priv_data)
+#define clk_to_dw_mipi_dsi_stm(clk) \
+ container_of(clk, struct dw_mipi_dsi_stm, txbyte_clk)
+
+static void dw_mipi_dsi_clk_disable(struct clk_hw *clk)
{
- struct dw_mipi_dsi_stm *dsi = priv_data;
+ struct dw_mipi_dsi_stm *dsi = clk_to_dw_mipi_dsi_stm(clk);
+
+ DRM_DEBUG_DRIVER("\n");
+
+ /* Disable the DSI PLL */
+ dsi_clear(dsi, DSI_WRPCR, WRPCR_PLLEN);
+
+ /* Disable the regulator */
+ dsi_clear(dsi, DSI_WRPCR, WRPCR_REGEN | WRPCR_BGREN);
+}
+
+static int dw_mipi_dsi_clk_enable(struct clk_hw *clk)
+{
+ struct dw_mipi_dsi_stm *dsi = clk_to_dw_mipi_dsi_stm(clk);
u32 val;
int ret;
+ DRM_DEBUG_DRIVER("\n");
+
/* Enable the regulator */
dsi_set(dsi, DSI_WRPCR, WRPCR_REGEN | WRPCR_BGREN);
- ret = readl_poll_timeout(dsi->base + DSI_WISR, val, val & WISR_RRS,
-SLEEP_US, TIMEOUT_US);
+ ret = readl_poll_timeout_atomic(dsi->base + DSI_WISR, val, val &
WISR_RRS,
+ SLEEP_US, TIMEOUT_US);
if (ret)
DRM_DEBUG_DRIVER("!TIMEOUT! waiting REGU, let's continue\n");
/* Enable the DSI PLL & wait for its lock */
dsi_set(dsi, DSI_WRPCR, WRPCR_PLLEN);
- ret = readl_poll_timeout(dsi->base + DSI_WISR, val, val & WISR_PLLLS,
-SLEEP_US, TIMEOUT_US);
+ ret = readl_poll_timeout_atomic(dsi->base + DSI_WISR, val, val &
WISR_PLLLS,
+ SLEEP_US, TIMEOUT_US);
if (ret)
DRM_DEBUG_DRIVER("!TIMEOUT! waiting PLL, let's continue\n");
return 0;
}
+static int dw_mipi_dsi_clk_is_enabled(struct clk_hw *hw)
+{
+ struct dw_mipi_dsi_stm *dsi = clk_to_dw_mipi_dsi_stm(hw);
+
+ return dsi_read(dsi, DSI_WRPCR) & WRPCR_PLLEN;
+}
+
+static unsigned long dw_mipi_dsi_clk_recalc_rate(struct clk_hw *hw,
+unsigned long parent_rate)
+{
+ struct dw_mipi_dsi_stm *dsi = clk_to_dw_mipi_dsi_stm(hw);
+ unsigned int idf, ndiv, odf, pll_in_khz, pll_out_khz;
+ u32 val;
+
+ DRM_DEBUG_DRIVER("\n");
+
+ pll_in_khz = (unsigned int)(parent_rate / 1000);
+
+ val = dsi_read(dsi, DSI_WRPCR);
+
+ idf = (val & WRPCR_IDF) >> 11;
+ if (!idf)
+ idf = 1;
+ ndiv = (val & WRPCR_NDIV) >> 2;
+ odf = int_pow(2, (val & WRPCR_ODF) >> 16);
+
+ /* Get the adjusted pll out value */
+ pll_out_khz = dsi_pll_get_clkout_khz(pll_in_khz, idf, ndiv, odf);
+
+ return (unsigned long)pll_out_khz * 1000;
+}
+
+static long dw_mipi_dsi_clk_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *parent_rate)
+{
+ struct dw_mipi_dsi_stm *dsi = clk_to_dw_mipi_dsi_stm(hw);
+ unsigned int idf, ndiv, odf, pll_in_khz, pll_out_khz;
+ int ret;
+
+ DRM_DEBUG_DRIVER("\n");
+
+ pll_in_khz = (unsigned int)(*parent_rate / 1000);
+
+ /* Compute best pll parameters */
+
Re: TR: [PATCH v4] drm/stm: Avoid use-after-free issues with crtc and plane
Hi Katya, thanks for the patch. Tested-by: Yannick Fertre BR Le 19/03/2024 à 14:47, Philippe CORNU - foss a écrit : zut, déjà un acked-by de RGA... tu confirmes que je prends? Philippe De : Raphael GALLAIS-POU - foss Envoyé : lundi 26 février 2024 14:50 À : Katya Orlova Cc : Yannick FERTRE - foss; Philippe CORNU - foss; David Airlie; Daniel Vetter; Maxime Coquelin; Alexandre TORGUE - foss; Philipp Zabel; dri-devel@lists.freedesktop.org; linux-st...@st-md-mailman.stormreply.com; linux-arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org; lvc-proj...@linuxtesting.org Objet : Re: [PATCH v4] drm/stm: Avoid use-after-free issues with crtc and plane On 2/16/24 13:50, Katya Orlova wrote: ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1]. Use allocations managed by the DRM framework. Found by Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/ Signed-off-by: Katya Orlova Hi Katya, Thanks for this submission. Acked-by: Raphaël Gallais-Pou Regards, Raphaël
Re: [PATCH v2 1/2] MAINTAINERS: drm: vc4: Add Raspberry Pi as maintainers
Hi Dave, On Fri, 21 Jun 2024 at 14:19, Dave Stevenson wrote: > Add myself as maintainer for VC4 alongside Maxime, and > our internal review list as reviewer. Both patches are: Acked-by: Daniel Stone Cheers, Daniel
Re: [PATCH RESEND v3 2/3] drm/stm: dsi: add pm runtime ops
Hi Raphael,
thanks for the patch.
Acked-by: Yannick Fertre
Tested-by: Yannick Fertre
BR
Le 29/01/2024 à 11:41, Raphael Gallais-Pou a écrit :
From: Yannick Fertre
Update control of clocks and supply thanks to the PM runtime
mechanism to avoid kernel crash during a system suspend.
Signed-off-by: Yannick Fertre
Signed-off-by: Raphael Gallais-Pou
---
Changes in v2:
- Changed SET_RUNTIME_PM_OPS to RUNTIME_PM_OPS and removed
__maybe_unused
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index b1aee43d51e9..82fff9e84345 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
@@ -77,6 +78,7 @@ enum dsi_color {
struct dw_mipi_dsi_stm {
void __iomem *base;
struct clk *pllref_clk;
+ struct clk *pclk;
struct dw_mipi_dsi *dsi;
u32 hw_version;
int lane_min_kbps;
@@ -443,7 +445,6 @@ static int dw_mipi_dsi_stm_probe(struct platform_device
*pdev)
{
struct device *dev = &pdev->dev;
struct dw_mipi_dsi_stm *dsi;
- struct clk *pclk;
int ret;
dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
@@ -483,21 +484,21 @@ static int dw_mipi_dsi_stm_probe(struct platform_device
*pdev)
goto err_clk_get;
}
- pclk = devm_clk_get(dev, "pclk");
- if (IS_ERR(pclk)) {
- ret = PTR_ERR(pclk);
+ dsi->pclk = devm_clk_get(dev, "pclk");
+ if (IS_ERR(dsi->pclk)) {
+ ret = PTR_ERR(dsi->pclk);
DRM_ERROR("Unable to get peripheral clock: %d\n", ret);
goto err_dsi_probe;
}
- ret = clk_prepare_enable(pclk);
+ ret = clk_prepare_enable(dsi->pclk);
if (ret) {
DRM_ERROR("%s: Failed to enable peripheral clk\n", __func__);
goto err_dsi_probe;
}
dsi->hw_version = dsi_read(dsi, DSI_VERSION) & VERSION;
- clk_disable_unprepare(pclk);
+ clk_disable_unprepare(dsi->pclk);
if (dsi->hw_version != HWVER_130 && dsi->hw_version != HWVER_131) {
ret = -ENODEV;
@@ -551,6 +552,7 @@ static int dw_mipi_dsi_stm_suspend(struct device *dev)
DRM_DEBUG_DRIVER("\n");
clk_disable_unprepare(dsi->pllref_clk);
+ clk_disable_unprepare(dsi->pclk);
regulator_disable(dsi->vdd_supply);
return 0;
@@ -569,8 +571,16 @@ static int dw_mipi_dsi_stm_resume(struct device *dev)
return ret;
}
+ ret = clk_prepare_enable(dsi->pclk);
+ if (ret) {
+ regulator_disable(dsi->vdd_supply);
+ DRM_ERROR("Failed to enable pclk: %d\n", ret);
+ return ret;
+ }
+
ret = clk_prepare_enable(dsi->pllref_clk);
if (ret) {
+ clk_disable_unprepare(dsi->pclk);
regulator_disable(dsi->vdd_supply);
DRM_ERROR("Failed to enable pllref_clk: %d\n", ret);
return ret;
@@ -582,6 +592,8 @@ static int dw_mipi_dsi_stm_resume(struct device *dev)
static const struct dev_pm_ops dw_mipi_dsi_stm_pm_ops = {
SYSTEM_SLEEP_PM_OPS(dw_mipi_dsi_stm_suspend,
dw_mipi_dsi_stm_resume)
+ RUNTIME_PM_OPS(dw_mipi_dsi_stm_suspend,
+ dw_mipi_dsi_stm_resume, NULL)
};
static struct platform_driver dw_mipi_dsi_stm_driver = {
Re: [PATCH RESEND v3 1/3] drm/stm: dsi: use new SYSTEM_SLEEP_PM_OPS() macro
Hi Raphael,
thanks for the patch.
Acked-by: Yannick Fertre
Tested-by: Yannick Fertre
BR
Le 29/01/2024 à 11:41, Raphael Gallais-Pou a écrit :
Use RUNTIME_PM_OPS() instead of the old SET_SYSTEM_SLEEP_PM_OPS().
This means we don't need __maybe_unused on the functions.
Signed-off-by: Raphael Gallais-Pou
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index d5f8c923d7bc..b1aee43d51e9 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -544,7 +544,7 @@ static void dw_mipi_dsi_stm_remove(struct platform_device
*pdev)
regulator_disable(dsi->vdd_supply);
}
-static int __maybe_unused dw_mipi_dsi_stm_suspend(struct device *dev)
+static int dw_mipi_dsi_stm_suspend(struct device *dev)
{
struct dw_mipi_dsi_stm *dsi = dw_mipi_dsi_stm_plat_data.priv_data;
@@ -556,7 +556,7 @@ static int __maybe_unused dw_mipi_dsi_stm_suspend(struct device *dev)
return 0;
}
-static int __maybe_unused dw_mipi_dsi_stm_resume(struct device *dev)
+static int dw_mipi_dsi_stm_resume(struct device *dev)
{
struct dw_mipi_dsi_stm *dsi = dw_mipi_dsi_stm_plat_data.priv_data;
int ret;
@@ -580,8 +580,8 @@ static int __maybe_unused dw_mipi_dsi_stm_resume(struct
device *dev)
}
static const struct dev_pm_ops dw_mipi_dsi_stm_pm_ops = {
- SET_SYSTEM_SLEEP_PM_OPS(dw_mipi_dsi_stm_suspend,
- dw_mipi_dsi_stm_resume)
+ SYSTEM_SLEEP_PM_OPS(dw_mipi_dsi_stm_suspend,
+ dw_mipi_dsi_stm_resume)
};
static struct platform_driver dw_mipi_dsi_stm_driver = {
Re: [PATCH v3 06/11] mm/util: Deduplicate code in {kstrdup,kstrndup,kmemdup_nul}
On Fri, Jun 21, 2024 at 10:29:54AM +0800, Yafang Shao wrote:
> These three functions follow the same pattern. To deduplicate the code,
> let's introduce a common help __kstrndup().
>
> Suggested-by: Andrew Morton
> Signed-off-by: Yafang Shao
Hi Yafang Shao,
Some minor nits from my side.
> ---
> mm/internal.h | 24
> mm/util.c | 27 ---
> 2 files changed, 28 insertions(+), 23 deletions(-)
>
> diff --git a/mm/internal.h b/mm/internal.h
> index b2c75b12014e..fd87f685739b 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -1521,4 +1521,28 @@ static inline void shrinker_debugfs_remove(struct
> dentry *debugfs_entry,
> void workingset_update_node(struct xa_node *node);
> extern struct list_lru shadow_nodes;
>
> +/**
> + * __kstrndup - Create a NUL-terminated string from @s, which might be
> unterminated.
> + * @s: The data to stringify
> + * @len: The size of the data, including the null terminator
> + * @gfp: the GFP mask used in the kmalloc() call when allocating memory
> + *
> + * Return: newly allocated copy of @s with NUL-termination or %NULL in
> + * case of error
> + */
> +static __always_inline char *__kstrndup(const char *s, size_t len, gfp_t gfp)
> +{
> + char *buf;
> +
> + buf = kmalloc_track_caller(len, gfp);
> + if (!buf)
> + return NULL;
> +
> + memcpy(buf, s, len);
> + /* Ensure the buf is always NUL-terminated, regardless of @s. */
> + buf[len - 1] = '\0';
> + return buf;
> +}
> +
> +
nit: One blank line is enough.
> #endif /* __MM_INTERNAL_H */
> diff --git a/mm/util.c b/mm/util.c
> index 41c7875572ed..d9135c5fdf7f 100644
> --- a/mm/util.c
> +++ b/mm/util.c
> @@ -58,17 +58,8 @@ char *kstrdup(const char *s, gfp_t gfp)
> if (!s)
> return NULL;
>
> - len = strlen(s) + 1;
> - buf = kmalloc_track_caller(len, gfp);
> - if (buf) {
> - memcpy(buf, s, len);
> - /* During memcpy(), the string might be updated to a new value,
> - * which could be longer than the string when strlen() is
> - * called. Therefore, we need to add a null termimator.
> - */
> - buf[len - 1] = '\0';
> - }
> - return buf;
nit: The local variable buf is now unused, and should be removed from kstrdup().
Likewise for kstrndup() and kmemdup_nul()
Flagged by W=1 builds with gcc-13 and clang-18, and Smatch.
> + len = strlen(s);
> + return __kstrndup(s, len + 1, gfp);
> }
> EXPORT_SYMBOL(kstrdup);
>
> @@ -111,12 +102,7 @@ char *kstrndup(const char *s, size_t max, gfp_t gfp)
> return NULL;
>
> len = strnlen(s, max);
> - buf = kmalloc_track_caller(len+1, gfp);
> - if (buf) {
> - memcpy(buf, s, len);
> - buf[len] = '\0';
> - }
> - return buf;
> + return __kstrndup(s, len + 1, gfp);
> }
> EXPORT_SYMBOL(kstrndup);
>
> @@ -195,12 +181,7 @@ char *kmemdup_nul(const char *s, size_t len, gfp_t gfp)
> if (!s)
> return NULL;
>
> - buf = kmalloc_track_caller(len + 1, gfp);
> - if (buf) {
> - memcpy(buf, s, len);
> - buf[len] = '\0';
> - }
> - return buf;
> + return __kstrndup(s, len + 1, gfp);
> }
> EXPORT_SYMBOL(kmemdup_nul);
>
> --
> 2.39.1
>
>
Re: [PATCH v3 06/11] mm/util: Deduplicate code in {kstrdup,kstrndup,kmemdup_nul}
On Fri, Jun 21, 2024 at 10:29:54AM +0800, Yafang Shao wrote: > +++ b/mm/internal.h Why are you putting __kstrndup in a header file when it's only used in util.c? Also, I think this function is actually __kmemdup_nul(), not __kstrndup().
[PATCH v2 1/7] drm/radeon: remove load callback
This is "drm/radeon: remove load callback" v2, the only changes
were made are adding "ddev->dev_private = rdev;", right after
the allocation of "struct radeon_device". Patch v2 2-7 mostly
describes simple "rdev->ddev" to "rdev_to_drm(rdev)" to suit
Patch v2 1/7.
Please be aware that these 7 patches depends on each other.
Thank you.
Signed-off-by: Wu Hoi Pok
---
drivers/gpu/drm/radeon/radeon.h | 11 ---
drivers/gpu/drm/radeon/radeon_drv.c | 27 ++-
drivers/gpu/drm/radeon/radeon_drv.h | 1 -
drivers/gpu/drm/radeon/radeon_kms.c | 18 ++
4 files changed, 32 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 0999c8eaae94..69bb30ced189 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2297,7 +2297,7 @@ typedef void (*radeon_wreg_t)(struct radeon_device*,
uint32_t, uint32_t);
struct radeon_device {
struct device *dev;
- struct drm_device *ddev;
+ struct drm_device ddev;
struct pci_dev *pdev;
#ifdef __alpha__
struct pci_controller *hose;
@@ -2440,10 +2440,13 @@ struct radeon_device {
u64 gart_pin_size;
};
+static inline struct drm_device *rdev_to_drm(struct radeon_device *rdev)
+{
+ return &rdev->ddev;
+}
+
bool radeon_is_px(struct drm_device *dev);
int radeon_device_init(struct radeon_device *rdev,
- struct drm_device *ddev,
- struct pci_dev *pdev,
uint32_t flags);
void radeon_device_fini(struct radeon_device *rdev);
int radeon_gpu_wait_for_idle(struct radeon_device *rdev);
@@ -2818,6 +2821,8 @@ struct radeon_device *radeon_get_rdev(struct ttm_device
*bdev);
/* KMS */
+int radeon_driver_load_kms(struct radeon_device *dev, unsigned long flags);
+
u32 radeon_get_vblank_counter_kms(struct drm_crtc *crtc);
int radeon_enable_vblank_kms(struct drm_crtc *crtc);
void radeon_disable_vblank_kms(struct drm_crtc *crtc);
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index 7bf08164140e..ae9cadceba83 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -259,7 +259,8 @@ static int radeon_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
unsigned long flags = 0;
- struct drm_device *dev;
+ struct drm_device *ddev;
+ struct radeon_device *rdev;
int ret;
if (!ent)
@@ -300,28 +301,37 @@ static int radeon_pci_probe(struct pci_dev *pdev,
if (ret)
return ret;
- dev = drm_dev_alloc(&kms_driver, &pdev->dev);
- if (IS_ERR(dev))
- return PTR_ERR(dev);
+ rdev = devm_drm_dev_alloc(&pdev->dev, &kms_driver, typeof(*rdev), ddev);
+ if (IS_ERR(rdev))
+ return PTR_ERR(rdev);
+
+ rdev->dev = &pdev->dev;
+ rdev->pdev = pdev;
+ ddev = rdev_to_drm(rdev);
+ ddev->dev_private = rdev;
ret = pci_enable_device(pdev);
if (ret)
goto err_free;
- pci_set_drvdata(pdev, dev);
+ pci_set_drvdata(pdev, ddev);
+
+ ret = radeon_driver_load_kms(rdev, flags);
+ if (ret)
+ goto err_agp;
- ret = drm_dev_register(dev, ent->driver_data);
+ ret = drm_dev_register(ddev, flags);
if (ret)
goto err_agp;
- radeon_fbdev_setup(dev->dev_private);
+ radeon_fbdev_setup(ddev->dev_private);
return 0;
err_agp:
pci_disable_device(pdev);
err_free:
- drm_dev_put(dev);
+ drm_dev_put(ddev);
return ret;
}
@@ -569,7 +579,6 @@ static const struct drm_ioctl_desc radeon_ioctls_kms[] = {
static const struct drm_driver kms_driver = {
.driver_features =
DRIVER_GEM | DRIVER_RENDER | DRIVER_MODESET,
- .load = radeon_driver_load_kms,
.open = radeon_driver_open_kms,
.postclose = radeon_driver_postclose_kms,
.unload = radeon_driver_unload_kms,
diff --git a/drivers/gpu/drm/radeon/radeon_drv.h
b/drivers/gpu/drm/radeon/radeon_drv.h
index 02a65971d140..6c1eb75a951b 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.h
+++ b/drivers/gpu/drm/radeon/radeon_drv.h
@@ -117,7 +117,6 @@
long radeon_drm_ioctl(struct file *filp,
unsigned int cmd, unsigned long arg);
-int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
void radeon_driver_unload_kms(struct drm_device *dev);
int radeon_driver_open_kms(struct drm_device *dev, struct drm_file *file_priv);
void radeon_driver_postclose_kms(struct drm_device *dev,
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index a16590c6247f..d2df194393af 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -91,
[PATCH v2 2/7] drm/radeon: rdev->ddev to rdev_to_drm(rdev) 1
Please see Patch v2 1/7 for details.
Signed-off-by: Wu Hoi Pok
---
drivers/gpu/drm/radeon/atombios_encoders.c | 2 +-
drivers/gpu/drm/radeon/cik.c | 14 ++---
drivers/gpu/drm/radeon/dce6_afmt.c | 2 +-
drivers/gpu/drm/radeon/evergreen.c | 12 +--
drivers/gpu/drm/radeon/ni.c| 2 +-
drivers/gpu/drm/radeon/r100.c | 24 +++---
6 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 03e6871b3065..c82e0fbc49b4 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -2179,7 +2179,7 @@ int radeon_atom_pick_dig_encoder(struct drm_encoder
*encoder, int fe_idx)
void
radeon_atom_encoder_init(struct radeon_device *rdev)
{
- struct drm_device *dev = rdev->ddev;
+ struct drm_device *dev = rdev_to_drm(rdev);
struct drm_encoder *encoder;
list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index b5e96a8fc2c1..11a492f21157 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -7585,7 +7585,7 @@ int cik_irq_process(struct radeon_device *rdev)
DRM_DEBUG("IH: IH event w/o asserted
irq bit?\n");
if (rdev->irq.crtc_vblank_int[0]) {
- drm_handle_vblank(rdev->ddev, 0);
+ drm_handle_vblank(rdev_to_drm(rdev), 0);
rdev->pm.vblank_sync = true;
wake_up(&rdev->irq.vblank_queue);
}
@@ -7615,7 +7615,7 @@ int cik_irq_process(struct radeon_device *rdev)
DRM_DEBUG("IH: IH event w/o asserted
irq bit?\n");
if (rdev->irq.crtc_vblank_int[1]) {
- drm_handle_vblank(rdev->ddev, 1);
+ drm_handle_vblank(rdev_to_drm(rdev), 1);
rdev->pm.vblank_sync = true;
wake_up(&rdev->irq.vblank_queue);
}
@@ -7645,7 +7645,7 @@ int cik_irq_process(struct radeon_device *rdev)
DRM_DEBUG("IH: IH event w/o asserted
irq bit?\n");
if (rdev->irq.crtc_vblank_int[2]) {
- drm_handle_vblank(rdev->ddev, 2);
+ drm_handle_vblank(rdev_to_drm(rdev), 2);
rdev->pm.vblank_sync = true;
wake_up(&rdev->irq.vblank_queue);
}
@@ -7675,7 +7675,7 @@ int cik_irq_process(struct radeon_device *rdev)
DRM_DEBUG("IH: IH event w/o asserted
irq bit?\n");
if (rdev->irq.crtc_vblank_int[3]) {
- drm_handle_vblank(rdev->ddev, 3);
+ drm_handle_vblank(rdev_to_drm(rdev), 3);
rdev->pm.vblank_sync = true;
wake_up(&rdev->irq.vblank_queue);
}
@@ -7705,7 +7705,7 @@ int cik_irq_process(struct radeon_device *rdev)
DRM_DEBUG("IH: IH event w/o asserted
irq bit?\n");
if (rdev->irq.crtc_vblank_int[4]) {
- drm_handle_vblank(rdev->ddev, 4);
+ drm_handle_vblank(rdev_to_drm(rdev), 4);
rdev->pm.vblank_sync = true;
wake_up(&rdev->irq.vblank_queue);
}
@@ -7735,7 +7735,7 @@ int cik_irq_process(struct radeon_device *rdev)
DRM_DEBUG("IH: IH event w/o asserted
irq bit?\n");
if (rdev->irq.crtc_vblank_int[5]) {
- drm_handle_vblank(rdev->ddev, 5);
+ drm_handle_vblank(rdev_to_drm(rdev), 5);
rdev->pm.vblank_sync = true;
wake_up(&rdev->irq.vblank_queue);
}
@@ -8581,7 +8581,7 @@ int cik_init(struct radeon_device *rdev)
/* Initialize surface registers */
radeon_surface_init(rdev);
/* Initialize clocks */
- radeon_get_clock_info(rdev->ddev);
+ radeon_get_clock_info(rdev_to_drm(rdev));
/* Fence driver */
radeon_fence_driver_init(rdev);
diff --git
[PATCH v2 3/7] drm/radeon: rdev->ddev to rdev_to_drm(rdev) 2
Please see Patch v2 1/7 for details.
Signed-off-by: Wu Hoi Pok
---
drivers/gpu/drm/radeon/r300.c | 6 +++---
drivers/gpu/drm/radeon/r420.c | 6 +++---
drivers/gpu/drm/radeon/r520.c | 2 +-
drivers/gpu/drm/radeon/r600.c | 12 ++--
drivers/gpu/drm/radeon/r600_cs.c | 2 +-
drivers/gpu/drm/radeon/r600_dpm.c | 4 ++--
6 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 1620f534f55f..05c13102a8cb 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -616,7 +616,7 @@ DEFINE_SHOW_ATTRIBUTE(rv370_debugfs_pcie_gart_info);
static void rv370_debugfs_pcie_gart_info_init(struct radeon_device *rdev)
{
#if defined(CONFIG_DEBUG_FS)
- struct dentry *root = rdev->ddev->primary->debugfs_root;
+ struct dentry *root = rdev_to_drm(rdev)->primary->debugfs_root;
debugfs_create_file("rv370_pcie_gart_info", 0444, root, rdev,
&rv370_debugfs_pcie_gart_info_fops);
@@ -1452,7 +1452,7 @@ int r300_resume(struct radeon_device *rdev)
RREG32(R_0007C0_CP_STAT));
}
/* post */
- radeon_combios_asic_init(rdev->ddev);
+ radeon_combios_asic_init(rdev_to_drm(rdev));
/* Resume clock after posting */
r300_clock_startup(rdev);
/* Initialize surface registers */
@@ -1538,7 +1538,7 @@ int r300_init(struct radeon_device *rdev)
/* Set asic errata */
r300_errata(rdev);
/* Initialize clocks */
- radeon_get_clock_info(rdev->ddev);
+ radeon_get_clock_info(rdev_to_drm(rdev));
/* initialize AGP */
if (rdev->flags & RADEON_IS_AGP) {
r = radeon_agp_init(rdev);
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index a979662eaa73..9a31cdec6415 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -322,7 +322,7 @@ int r420_resume(struct radeon_device *rdev)
if (rdev->is_atom_bios) {
atom_asic_init(rdev->mode_info.atom_context);
} else {
- radeon_combios_asic_init(rdev->ddev);
+ radeon_combios_asic_init(rdev_to_drm(rdev));
}
/* Resume clock after posting */
r420_clock_resume(rdev);
@@ -414,7 +414,7 @@ int r420_init(struct radeon_device *rdev)
return -EINVAL;
/* Initialize clocks */
- radeon_get_clock_info(rdev->ddev);
+ radeon_get_clock_info(rdev_to_drm(rdev));
/* initialize AGP */
if (rdev->flags & RADEON_IS_AGP) {
r = radeon_agp_init(rdev);
@@ -493,7 +493,7 @@ DEFINE_SHOW_ATTRIBUTE(r420_debugfs_pipes_info);
void r420_debugfs_pipes_info_init(struct radeon_device *rdev)
{
#if defined(CONFIG_DEBUG_FS)
- struct dentry *root = rdev->ddev->primary->debugfs_root;
+ struct dentry *root = rdev_to_drm(rdev)->primary->debugfs_root;
debugfs_create_file("r420_pipes_info", 0444, root, rdev,
&r420_debugfs_pipes_info_fops);
diff --git a/drivers/gpu/drm/radeon/r520.c b/drivers/gpu/drm/radeon/r520.c
index 6cbcaa845192..08e127b3249a 100644
--- a/drivers/gpu/drm/radeon/r520.c
+++ b/drivers/gpu/drm/radeon/r520.c
@@ -287,7 +287,7 @@ int r520_init(struct radeon_device *rdev)
atom_asic_init(rdev->mode_info.atom_context);
}
/* Initialize clocks */
- radeon_get_clock_info(rdev->ddev);
+ radeon_get_clock_info(rdev_to_drm(rdev));
/* initialize AGP */
if (rdev->flags & RADEON_IS_AGP) {
r = radeon_agp_init(rdev);
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 087d41e370fd..8b62f7faa5b9 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -950,7 +950,7 @@ void r600_hpd_set_polarity(struct radeon_device *rdev,
void r600_hpd_init(struct radeon_device *rdev)
{
- struct drm_device *dev = rdev->ddev;
+ struct drm_device *dev = rdev_to_drm(rdev);
struct drm_connector *connector;
unsigned enable = 0;
@@ -1017,7 +1017,7 @@ void r600_hpd_init(struct radeon_device *rdev)
void r600_hpd_fini(struct radeon_device *rdev)
{
- struct drm_device *dev = rdev->ddev;
+ struct drm_device *dev = rdev_to_drm(rdev);
struct drm_connector *connector;
unsigned disable = 0;
@@ -3280,7 +3280,7 @@ int r600_init(struct radeon_device *rdev)
/* Initialize surface registers */
radeon_surface_init(rdev);
/* Initialize clocks */
- radeon_get_clock_info(rdev->ddev);
+ radeon_get_clock_info(rdev_to_drm(rdev));
/* Fence driver */
radeon_fence_driver_init(rdev);
if (rdev->flags & RADEON_IS_AGP) {
@@ -4136,7 +4136,7 @@ int r600_irq_process(struct radeon_device *rdev)
DRM_DEBUG("IH: D1 vblank - IH event w/o
asserted irq bit?\n");
[PATCH v2 4/7] drm/radeon: rdev->ddev to rdev_to_drm(rdev) 3
Please see Patch v2 1/7 for details.
Signed-off-by: Wu Hoi Pok
---
drivers/gpu/drm/radeon/r600_hdmi.c | 2 +-
drivers/gpu/drm/radeon/radeon_acpi.c | 10 +-
drivers/gpu/drm/radeon/radeon_agp.c | 2 +-
drivers/gpu/drm/radeon/radeon_atombios.c | 2 +-
drivers/gpu/drm/radeon/radeon_audio.c| 4 ++--
drivers/gpu/drm/radeon/radeon_combios.c | 12 ++--
6 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
b/drivers/gpu/drm/radeon/r600_hdmi.c
index f3551ebaa2f0..661f374f5f27 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -116,7 +116,7 @@ void r600_audio_update_hdmi(struct work_struct *work)
{
struct radeon_device *rdev = container_of(work, struct radeon_device,
audio_work);
- struct drm_device *dev = rdev->ddev;
+ struct drm_device *dev = rdev_to_drm(rdev);
struct r600_audio_pin audio_status = r600_audio_status(rdev);
struct drm_encoder *encoder;
bool changed = false;
diff --git a/drivers/gpu/drm/radeon/radeon_acpi.c
b/drivers/gpu/drm/radeon/radeon_acpi.c
index 603a78e41ba5..22ce61bdfc06 100644
--- a/drivers/gpu/drm/radeon/radeon_acpi.c
+++ b/drivers/gpu/drm/radeon/radeon_acpi.c
@@ -405,11 +405,11 @@ static int radeon_atif_handler(struct radeon_device *rdev,
if (req.pending & ATIF_DGPU_DISPLAY_EVENT) {
if ((rdev->flags & RADEON_IS_PX) &&
radeon_atpx_dgpu_req_power_for_displays()) {
- pm_runtime_get_sync(rdev->ddev->dev);
+ pm_runtime_get_sync(rdev_to_drm(rdev)->dev);
/* Just fire off a uevent and let userspace tell us
what to do */
- drm_helper_hpd_irq_event(rdev->ddev);
- pm_runtime_mark_last_busy(rdev->ddev->dev);
- pm_runtime_put_autosuspend(rdev->ddev->dev);
+ drm_helper_hpd_irq_event(rdev_to_drm(rdev));
+ pm_runtime_mark_last_busy(rdev_to_drm(rdev)->dev);
+ pm_runtime_put_autosuspend(rdev_to_drm(rdev)->dev);
}
}
/* TODO: check other events */
@@ -736,7 +736,7 @@ int radeon_acpi_init(struct radeon_device *rdev)
struct radeon_encoder *target = NULL;
/* Find the encoder controlling the brightness */
- list_for_each_entry(tmp, &rdev->ddev->mode_config.encoder_list,
+ list_for_each_entry(tmp,
&rdev_to_drm(rdev)->mode_config.encoder_list,
head) {
struct radeon_encoder *enc = to_radeon_encoder(tmp);
diff --git a/drivers/gpu/drm/radeon/radeon_agp.c
b/drivers/gpu/drm/radeon/radeon_agp.c
index a3d749e350f9..89d7b0e9e79f 100644
--- a/drivers/gpu/drm/radeon/radeon_agp.c
+++ b/drivers/gpu/drm/radeon/radeon_agp.c
@@ -161,7 +161,7 @@ struct radeon_agp_head *radeon_agp_head_init(struct
drm_device *dev)
static int radeon_agp_head_acquire(struct radeon_device *rdev)
{
- struct drm_device *dev = rdev->ddev;
+ struct drm_device *dev = rdev_to_drm(rdev);
struct pci_dev *pdev = to_pci_dev(dev->dev);
if (!rdev->agp)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 10793a433bf5..97c4e10d0550 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -187,7 +187,7 @@ void radeon_atombios_i2c_init(struct radeon_device *rdev)
if (i2c.valid) {
sprintf(stmp, "0x%x", i2c.i2c_id);
- rdev->i2c_bus[i] =
radeon_i2c_create(rdev->ddev, &i2c, stmp);
+ rdev->i2c_bus[i] =
radeon_i2c_create(rdev_to_drm(rdev), &i2c, stmp);
}
gpio = (ATOM_GPIO_I2C_ASSIGMENT *)
((u8 *)gpio + sizeof(ATOM_GPIO_I2C_ASSIGMENT));
diff --git a/drivers/gpu/drm/radeon/radeon_audio.c
b/drivers/gpu/drm/radeon/radeon_audio.c
index 0bcd767b9f47..47aa06a9a942 100644
--- a/drivers/gpu/drm/radeon/radeon_audio.c
+++ b/drivers/gpu/drm/radeon/radeon_audio.c
@@ -196,7 +196,7 @@ static void radeon_audio_enable(struct radeon_device *rdev,
return;
if (rdev->mode_info.mode_config_initialized) {
- list_for_each_entry(encoder,
&rdev->ddev->mode_config.encoder_list, head) {
+ list_for_each_entry(encoder,
&rdev_to_drm(rdev)->mode_config.encoder_list, head) {
if (radeon_encoder_is_digital(encoder)) {
radeon_encoder = to_radeon_encoder(encoder);
dig = radeon_encoder->enc_priv;
@@ -760,7 +760,7 @@ static int radeon_audio_component_get_eld(struct device
*kdev, int port,
if (!rdev->audio.enabled || !rde
[PATCH v2 5/7] drm/radeon: rdev->ddev to rdev_to_drm(rdev) 4
Please see Patch v2 1/7 for details.
Signed-off-by: Wu Hoi Pok
---
drivers/gpu/drm/radeon/radeon_device.c | 19 +++
drivers/gpu/drm/radeon/radeon_display.c | 74 -
drivers/gpu/drm/radeon/radeon_fbdev.c | 26 -
drivers/gpu/drm/radeon/radeon_fence.c | 8 +--
drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
drivers/gpu/drm/radeon/radeon_i2c.c | 2 +-
6 files changed, 63 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index afbb3a80c0c6..127d8fd7f7cd 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -760,7 +760,7 @@ bool radeon_boot_test_post_card(struct radeon_device *rdev)
if (rdev->is_atom_bios)
atom_asic_init(rdev->mode_info.atom_context);
else
- radeon_combios_asic_init(rdev->ddev);
+ radeon_combios_asic_init(rdev_to_drm(rdev));
return true;
} else {
dev_err(rdev->dev, "Card not posted and no BIOS - ignoring\n");
@@ -980,7 +980,7 @@ int radeon_atombios_init(struct radeon_device *rdev)
return -ENOMEM;
rdev->mode_info.atom_card_info = atom_card_info;
- atom_card_info->dev = rdev->ddev;
+ atom_card_info->dev = rdev_to_drm(rdev);
atom_card_info->reg_read = cail_reg_read;
atom_card_info->reg_write = cail_reg_write;
/* needed for iio ops */
@@ -1005,7 +1005,7 @@ int radeon_atombios_init(struct radeon_device *rdev)
mutex_init(&rdev->mode_info.atom_context->mutex);
mutex_init(&rdev->mode_info.atom_context->scratch_mutex);
- radeon_atom_initialize_bios_scratch_regs(rdev->ddev);
+ radeon_atom_initialize_bios_scratch_regs(rdev_to_drm(rdev));
atom_allocate_fb_scratch(rdev->mode_info.atom_context);
return 0;
}
@@ -1049,7 +1049,7 @@ void radeon_atombios_fini(struct radeon_device *rdev)
*/
int radeon_combios_init(struct radeon_device *rdev)
{
- radeon_combios_initialize_bios_scratch_regs(rdev->ddev);
+ radeon_combios_initialize_bios_scratch_regs(rdev_to_drm(rdev));
return 0;
}
@@ -1267,8 +1267,6 @@ static const struct vga_switcheroo_client_ops
radeon_switcheroo_ops = {
* radeon_device_init - initialize the driver
*
* @rdev: radeon_device pointer
- * @ddev: drm dev pointer
- * @pdev: pci dev pointer
* @flags: driver flags
*
* Initializes the driver info and hw (all asics).
@@ -1276,18 +1274,15 @@ static const struct vga_switcheroo_client_ops
radeon_switcheroo_ops = {
* Called at driver startup.
*/
int radeon_device_init(struct radeon_device *rdev,
- struct drm_device *ddev,
- struct pci_dev *pdev,
uint32_t flags)
{
+ struct pci_dev *pdev = rdev->pdev;
+ struct drm_device *ddev = rdev_to_drm(rdev);
int r, i;
int dma_bits;
bool runtime = false;
rdev->shutdown = false;
- rdev->dev = &pdev->dev;
- rdev->ddev = ddev;
- rdev->pdev = pdev;
rdev->flags = flags;
rdev->family = flags & RADEON_FAMILY_MASK;
rdev->is_atom_bios = false;
@@ -1847,7 +1842,7 @@ int radeon_gpu_reset(struct radeon_device *rdev)
downgrade_write(&rdev->exclusive_lock);
- drm_helper_resume_force_mode(rdev->ddev);
+ drm_helper_resume_force_mode(rdev_to_drm(rdev));
/* set the power state here in case we are a PX system or headless */
if ((rdev->pm.pm_method == PM_METHOD_DPM) && rdev->pm.dpm_enabled)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 843383f7237f..10fd58f400bc 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -302,13 +302,13 @@ void radeon_crtc_handle_vblank(struct radeon_device
*rdev, int crtc_id)
if ((radeon_use_pflipirq == 2) && ASIC_IS_DCE4(rdev))
return;
- spin_lock_irqsave(&rdev->ddev->event_lock, flags);
+ spin_lock_irqsave(&rdev_to_drm(rdev)->event_lock, flags);
if (radeon_crtc->flip_status != RADEON_FLIP_SUBMITTED) {
DRM_DEBUG_DRIVER("radeon_crtc->flip_status = %d != "
"RADEON_FLIP_SUBMITTED(%d)\n",
radeon_crtc->flip_status,
RADEON_FLIP_SUBMITTED);
- spin_unlock_irqrestore(&rdev->ddev->event_lock, flags);
+ spin_unlock_irqrestore(&rdev_to_drm(rdev)->event_lock, flags);
return;
}
@@ -334,7 +334,7 @@ void radeon_crtc_handle_vblank(struct radeon_device *rdev,
int crtc_id)
*/
if (update_pending &&
(DRM_SCANOUTPOS_VALID &
-radeon_get_crtc_scanoutpos(rdev->ddev, crtc_id,
+radeon_get_crtc_scanoutpos(rdev_to_drm(rdev), crt
[PATCH v2 6/7] drm/radeon: rdev->ddev to rdev_to_drm(rdev) 5
Please see Patch v2 1/7 for details.
Signed-off-by: Wu Hoi Pok
---
drivers/gpu/drm/radeon/radeon_ib.c | 2 +-
drivers/gpu/drm/radeon/radeon_irq_kms.c | 12 ++--
drivers/gpu/drm/radeon/radeon_object.c | 2 +-
drivers/gpu/drm/radeon/radeon_pm.c | 20 ++--
drivers/gpu/drm/radeon/radeon_ring.c| 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 6 +++---
6 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ib.c
b/drivers/gpu/drm/radeon/radeon_ib.c
index 63d914f3414d..1aa41cc3f991 100644
--- a/drivers/gpu/drm/radeon/radeon_ib.c
+++ b/drivers/gpu/drm/radeon/radeon_ib.c
@@ -309,7 +309,7 @@ DEFINE_SHOW_ATTRIBUTE(radeon_debugfs_sa_info);
static void radeon_debugfs_sa_init(struct radeon_device *rdev)
{
#if defined(CONFIG_DEBUG_FS)
- struct dentry *root = rdev->ddev->primary->debugfs_root;
+ struct dentry *root = rdev_to_drm(rdev)->primary->debugfs_root;
debugfs_create_file("radeon_sa_info", 0444, root, rdev,
&radeon_debugfs_sa_info_fops);
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c
b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index c4dda908666c..9961251b44ba 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -80,7 +80,7 @@ static void radeon_hotplug_work_func(struct work_struct *work)
{
struct radeon_device *rdev = container_of(work, struct radeon_device,
hotplug_work.work);
- struct drm_device *dev = rdev->ddev;
+ struct drm_device *dev = rdev_to_drm(rdev);
struct drm_mode_config *mode_config = &dev->mode_config;
struct drm_connector *connector;
@@ -101,7 +101,7 @@ static void radeon_dp_work_func(struct work_struct *work)
{
struct radeon_device *rdev = container_of(work, struct radeon_device,
dp_work);
- struct drm_device *dev = rdev->ddev;
+ struct drm_device *dev = rdev_to_drm(rdev);
struct drm_mode_config *mode_config = &dev->mode_config;
struct drm_connector *connector;
@@ -197,7 +197,7 @@ static void radeon_driver_irq_uninstall_kms(struct
drm_device *dev)
static int radeon_irq_install(struct radeon_device *rdev, int irq)
{
- struct drm_device *dev = rdev->ddev;
+ struct drm_device *dev = rdev_to_drm(rdev);
int ret;
if (irq == IRQ_NOTCONNECTED)
@@ -218,7 +218,7 @@ static int radeon_irq_install(struct radeon_device *rdev,
int irq)
static void radeon_irq_uninstall(struct radeon_device *rdev)
{
- struct drm_device *dev = rdev->ddev;
+ struct drm_device *dev = rdev_to_drm(rdev);
struct pci_dev *pdev = to_pci_dev(dev->dev);
radeon_driver_irq_uninstall_kms(dev);
@@ -322,9 +322,9 @@ int radeon_irq_kms_init(struct radeon_device *rdev)
spin_lock_init(&rdev->irq.lock);
/* Disable vblank irqs aggressively for power-saving */
- rdev->ddev->vblank_disable_immediate = true;
+ rdev_to_drm(rdev)->vblank_disable_immediate = true;
- r = drm_vblank_init(rdev->ddev, rdev->num_crtc);
+ r = drm_vblank_init(rdev_to_drm(rdev), rdev->num_crtc);
if (r) {
return r;
}
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index a955f8a2f7fe..450ff7daa46c 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -150,7 +150,7 @@ int radeon_bo_create(struct radeon_device *rdev,
bo = kzalloc(sizeof(struct radeon_bo), GFP_KERNEL);
if (bo == NULL)
return -ENOMEM;
- drm_gem_private_object_init(rdev->ddev, &bo->tbo.base, size);
+ drm_gem_private_object_init(rdev_to_drm(rdev), &bo->tbo.base, size);
bo->rdev = rdev;
bo->surface_reg = -1;
INIT_LIST_HEAD(&bo->list);
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 2d9d9f46f243..b4fb7e70320b 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -282,7 +282,7 @@ static void radeon_pm_set_clocks(struct radeon_device *rdev)
if (rdev->irq.installed) {
i = 0;
- drm_for_each_crtc(crtc, rdev->ddev) {
+ drm_for_each_crtc(crtc, rdev_to_drm(rdev)) {
if (rdev->pm.active_crtcs & (1 << i)) {
/* This can fail if a modeset is in progress */
if (drm_crtc_vblank_get(crtc) == 0)
@@ -299,7 +299,7 @@ static void radeon_pm_set_clocks(struct radeon_device *rdev)
if (rdev->irq.installed) {
i = 0;
- drm_for_each_crtc(crtc, rdev->ddev) {
+ drm_for_each_crtc(crtc, rdev_to_drm(rdev)) {
if (rdev->pm.req_vblank & (1 << i)) {
rdev->pm.req_vblank
[PATCH v2 7/7] drm/radeon: rdev->ddev to rdev_to_drm(rdev) 6
Please see Patch v2 1/7 for details.
Signed-off-by: Wu Hoi Pok
---
drivers/gpu/drm/radeon/rs400.c | 6 +++---
drivers/gpu/drm/radeon/rs600.c | 14 +++---
drivers/gpu/drm/radeon/rs690.c | 2 +-
drivers/gpu/drm/radeon/rv515.c | 4 ++--
drivers/gpu/drm/radeon/rv770.c | 2 +-
drivers/gpu/drm/radeon/si.c| 4 ++--
6 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/radeon/rs400.c b/drivers/gpu/drm/radeon/rs400.c
index d4d1501e6576..d6c18fd740ec 100644
--- a/drivers/gpu/drm/radeon/rs400.c
+++ b/drivers/gpu/drm/radeon/rs400.c
@@ -379,7 +379,7 @@ DEFINE_SHOW_ATTRIBUTE(rs400_debugfs_gart_info);
static void rs400_debugfs_pcie_gart_info_init(struct radeon_device *rdev)
{
#if defined(CONFIG_DEBUG_FS)
- struct dentry *root = rdev->ddev->primary->debugfs_root;
+ struct dentry *root = rdev_to_drm(rdev)->primary->debugfs_root;
debugfs_create_file("rs400_gart_info", 0444, root, rdev,
&rs400_debugfs_gart_info_fops);
@@ -474,7 +474,7 @@ int rs400_resume(struct radeon_device *rdev)
RREG32(R_0007C0_CP_STAT));
}
/* post */
- radeon_combios_asic_init(rdev->ddev);
+ radeon_combios_asic_init(rdev_to_drm(rdev));
/* Resume clock after posting */
r300_clock_startup(rdev);
/* Initialize surface registers */
@@ -552,7 +552,7 @@ int rs400_init(struct radeon_device *rdev)
return -EINVAL;
/* Initialize clocks */
- radeon_get_clock_info(rdev->ddev);
+ radeon_get_clock_info(rdev_to_drm(rdev));
/* initialize memory controller */
rs400_mc_init(rdev);
/* Fence driver */
diff --git a/drivers/gpu/drm/radeon/rs600.c b/drivers/gpu/drm/radeon/rs600.c
index 5c162778899b..88c8e91ea651 100644
--- a/drivers/gpu/drm/radeon/rs600.c
+++ b/drivers/gpu/drm/radeon/rs600.c
@@ -321,7 +321,7 @@ void rs600_pm_misc(struct radeon_device *rdev)
void rs600_pm_prepare(struct radeon_device *rdev)
{
- struct drm_device *ddev = rdev->ddev;
+ struct drm_device *ddev = rdev_to_drm(rdev);
struct drm_crtc *crtc;
struct radeon_crtc *radeon_crtc;
u32 tmp;
@@ -339,7 +339,7 @@ void rs600_pm_prepare(struct radeon_device *rdev)
void rs600_pm_finish(struct radeon_device *rdev)
{
- struct drm_device *ddev = rdev->ddev;
+ struct drm_device *ddev = rdev_to_drm(rdev);
struct drm_crtc *crtc;
struct radeon_crtc *radeon_crtc;
u32 tmp;
@@ -408,7 +408,7 @@ void rs600_hpd_set_polarity(struct radeon_device *rdev,
void rs600_hpd_init(struct radeon_device *rdev)
{
- struct drm_device *dev = rdev->ddev;
+ struct drm_device *dev = rdev_to_drm(rdev);
struct drm_connector *connector;
unsigned enable = 0;
@@ -435,7 +435,7 @@ void rs600_hpd_init(struct radeon_device *rdev)
void rs600_hpd_fini(struct radeon_device *rdev)
{
- struct drm_device *dev = rdev->ddev;
+ struct drm_device *dev = rdev_to_drm(rdev);
struct drm_connector *connector;
unsigned disable = 0;
@@ -797,7 +797,7 @@ int rs600_irq_process(struct radeon_device *rdev)
/* Vertical blank interrupts */
if
(G_007EDC_LB_D1_VBLANK_INTERRUPT(rdev->irq.stat_regs.r500.disp_int)) {
if (rdev->irq.crtc_vblank_int[0]) {
- drm_handle_vblank(rdev->ddev, 0);
+ drm_handle_vblank(rdev_to_drm(rdev), 0);
rdev->pm.vblank_sync = true;
wake_up(&rdev->irq.vblank_queue);
}
@@ -806,7 +806,7 @@ int rs600_irq_process(struct radeon_device *rdev)
}
if
(G_007EDC_LB_D2_VBLANK_INTERRUPT(rdev->irq.stat_regs.r500.disp_int)) {
if (rdev->irq.crtc_vblank_int[1]) {
- drm_handle_vblank(rdev->ddev, 1);
+ drm_handle_vblank(rdev_to_drm(rdev), 1);
rdev->pm.vblank_sync = true;
wake_up(&rdev->irq.vblank_queue);
}
@@ -1133,7 +1133,7 @@ int rs600_init(struct radeon_device *rdev)
return -EINVAL;
/* Initialize clocks */
- radeon_get_clock_info(rdev->ddev);
+ radeon_get_clock_info(rdev_to_drm(rdev));
/* initialize memory controller */
rs600_mc_init(rdev);
r100_debugfs_rbbm_init(rdev);
diff --git a/drivers/gpu/drm/radeon/rs690.c b/drivers/gpu/drm/radeon/rs690.c
index 14fb0819b8c1..016eb4992803 100644
--- a/drivers/gpu/drm/radeon/rs690.c
+++ b/drivers/gpu/drm/radeon/rs690.c
@@ -845,7 +845,7 @@ int rs690_init(struct radeon_device *rdev)
return -EINVAL;
/* Initialize clocks */
- radeon_get_clock_info(rdev->ddev);
+ radeon_get_clock_info(rdev_to_drm(rdev));
/* initialize memory controller */
rs690_m
Re: [PATCH] drm/ssd130x: Add drm_panic support
Jocelyn Falempe writes:
Hello Jocelyn, thanks for your feedback!
> On 21/06/2024 00:22, Javier Martinez Canillas wrote:
>> Add support for the drm_panic infrastructure, which allows to display
>> a user friendly message on the screen when a Linux kernel panic occurs.
>>
>> The display controller doesn't scanout the framebuffer, but instead the
>> pixels are sent to the device using a transport bus. For this reason, a
>> .panic_flush handler is needed to flush the panic image to the display.
>
> Thanks for this patch, that's really cool that drm_panic can work on
> this device too.
>
Indeed, that's why I did it. Just to see if it could work :)
[...]
>> +static void ssd130x_primary_plane_helper_panic_flush(struct drm_plane
>> *plane)
>> +{
>> +struct drm_plane_state *plane_state = plane->state;
>> +struct ssd130x_plane_state *ssd130x_plane_state =
>> to_ssd130x_plane_state(plane_state);
>> +struct drm_shadow_plane_state *shadow_plane_state =
>> to_drm_shadow_plane_state(plane_state);
>> +struct drm_crtc *crtc = plane_state->crtc;
>> +struct ssd130x_crtc_state *ssd130x_crtc_state =
>> to_ssd130x_crtc_state(crtc->state);
>> +
>> +ssd130x_fb_blit_rect(plane_state->fb, &shadow_plane_state->data[0],
>> &plane_state->dst,
>> + ssd130x_plane_state->buffer,
>> ssd130x_crtc_state->data_array,
>> + &shadow_plane_state->fmtcnv_state);
>
> ssd130x_fb_blit_rect() will call regmap->write(), which involve mutex
> and might sleep. And if the mutex is taken when the panic occurs, it
> might deadlock the panic handling.
That's a good point and I something haven't considered...
> One solution would be to configure the regmap with config->fast_io and
> config->use_raw_spinlock, and check that the lock is available with
> try_lock(map->raw_spin_lock)
> But that means it will waste cpu cycle with busy waiting for normal
> operation, which is not good.
>
Yeah, I would prefer to not change the driver for normal operation.
> So for this particular device, I think it's ok, because it's unlikely
> you'll run kdump or other kernel panic handlers.
> But I would like to know what others think about it, and if it's
> acceptable or not.
>
I don't know either. I guess that after a panic everything is best effort
anyways so it may be acceptable? But let's see what others think about it.
> --
>
> Jocelyn
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Re: [PATCH v1 1/1] drm/xe/bo: Fix fixed placement ggtt pinning code
On Fri, Jun 21, 2024 at 12:15:06AM -0700, Alan Previn wrote:
> When calling xe_bo_create_pin_map_at, use the correct
> starting offset provided by caller at xe_ggtt_insert_bo_at.
>
> Fixes: 44e694958b95 ("drm/xe/display: Implement display support")
> Signed-off-by: Alan Previn
> ---
> drivers/gpu/drm/xe/xe_bo.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
> index 74294f1b05bc..cc6101b49c08 100644
> --- a/drivers/gpu/drm/xe/xe_bo.c
> +++ b/drivers/gpu/drm/xe/xe_bo.c
> @@ -1436,7 +1436,7 @@ __xe_bo_create_locked(struct xe_device *xe,
>
> if (flags & XE_BO_FLAG_FIXED_PLACEMENT) {
> err = xe_ggtt_insert_bo_at(tile->mem.ggtt, bo,
> -start + bo->size, U64_MAX);
> +start, end);
interesting! o.O
looking up to the initial_plane_bo and down to the drm_mm_insert node
I don't believe this ever worked, right?! We were never reusing the
plane and just getting the blank screen on the start until it got
recreated?
is there any link to any open issue or history?
Reviewed-by: Rodrigo Vivi
> } else {
> err = xe_ggtt_insert_bo(tile->mem.ggtt, bo);
> }
>
> base-commit: cffd77865f476994680892601e09bc2164179907
> --
> 2.34.1
>
Re: [PATCH] drm/ttm/pool: Revert to clear-on-alloc to honor TTM_TT_FLAG_ZERO_ALLOC
Am 20.06.24 um 18:01 schrieb Nirmoy Das:
Currently ttm pool is not honoring TTM_TT_FLAG_ZERO_ALLOC flag and
clearing pages on free. It does help with allocation latency but clearing
happens even if drm driver doesn't passes the flag. If clear on free
is needed then a new flag can be added for that purpose.
Mhm, thinking more about it that will most likely get push back from
others as well.
How about the attached patch? We just skip clearing pages when the
driver set the ZERO_ALLOC flag again before freeing them.
Maybe rename the flag or add a new one for that, but in general that
looks like the option with the least impact.
Regards,
Christian.
Cc: Christian Koenig
Cc: "Thomas Hellström"
Cc: Matthew Auld
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/ttm/ttm_pool.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 6e1fd6985ffc..cbbd722185ee 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -224,15 +224,6 @@ static void ttm_pool_unmap(struct ttm_pool *pool,
dma_addr_t dma_addr,
/* Give pages into a specific pool_type */
static void ttm_pool_type_give(struct ttm_pool_type *pt, struct page *p)
{
- unsigned int i, num_pages = 1 << pt->order;
-
- for (i = 0; i < num_pages; ++i) {
- if (PageHighMem(p))
- clear_highpage(p + i);
- else
- clear_page(page_address(p + i));
- }
-
spin_lock(&pt->lock);
list_add(&p->lru, &pt->pages);
spin_unlock(&pt->lock);
@@ -240,15 +231,26 @@ static void ttm_pool_type_give(struct ttm_pool_type *pt,
struct page *p)
}
/* Take pages from a specific pool_type, return NULL when nothing available */
-static struct page *ttm_pool_type_take(struct ttm_pool_type *pt)
+static struct page *ttm_pool_type_take(struct ttm_pool_type *pt, bool clear)
{
struct page *p;
spin_lock(&pt->lock);
p = list_first_entry_or_null(&pt->pages, typeof(*p), lru);
if (p) {
+ unsigned int i, num_pages = 1 << pt->order;
+
atomic_long_sub(1 << pt->order, &allocated_pages);
list_del(&p->lru);
+ if (clear) {
+ for (i = 0; i < num_pages; ++i) {
+ if (PageHighMem(p))
+ clear_highpage(p + i);
+ else
+ clear_page(page_address(p + i));
+ }
+ }
+
}
spin_unlock(&pt->lock);
@@ -279,7 +281,7 @@ static void ttm_pool_type_fini(struct ttm_pool_type *pt)
list_del(&pt->shrinker_list);
spin_unlock(&shrinker_lock);
- while ((p = ttm_pool_type_take(pt)))
+ while ((p = ttm_pool_type_take(pt, false)))
ttm_pool_free_page(pt->pool, pt->caching, pt->order, p);
}
@@ -330,7 +332,7 @@ static unsigned int ttm_pool_shrink(void)
list_move_tail(&pt->shrinker_list, &shrinker_list);
spin_unlock(&shrinker_lock);
- p = ttm_pool_type_take(pt);
+ p = ttm_pool_type_take(pt, false);
if (p) {
ttm_pool_free_page(pt->pool, pt->caching, pt->order, p);
num_pages = 1 << pt->order;
@@ -457,10 +459,11 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt
*tt,
num_pages;
order = min_t(unsigned int, order, __fls(num_pages))) {
struct ttm_pool_type *pt;
+ bool clear = tt->page_flags & TTM_TT_FLAG_ZERO_ALLOC;
page_caching = tt->caching;
pt = ttm_pool_select_type(pool, tt->caching, order);
- p = pt ? ttm_pool_type_take(pt) : NULL;
+ p = pt ? ttm_pool_type_take(pt, clear) : NULL;
if (p) {
r = ttm_pool_apply_caching(caching, pages,
tt->caching);
@@ -480,7 +483,7 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt *tt,
if (num_pages < (1 << order))
break;
-p = ttm_pool_type_take(pt);
+ p = ttm_pool_type_take(pt, clear);
} while (p);
}
From 466b7b315af74bae635b9245a1d9e6619a3da171 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?=
Date: Fri, 21 Jun 2024 16:50:59 +0200
Subject: [PATCH] drm/ttm: skip page clear if ZERO_ALLOC flag is set on free
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This allows the driver to clear the pages using some DMA instead of the
CPU.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_
Re: [PATCH v6 3/3] drm/stm: ltdc: add lvds pixel clock
Hi Raphaël,
Thanks for your patch, it will not merged due to a new clock management.
Philippe,
this patch will be replaced by another which manages all clocks that the
display controller
will need (pixel clock, bus clock reference clock).
Best regards
Le 26/02/2024 à 11:48, Raphael Gallais-Pou a écrit :
The STM32MP25x display subsystem presents a mux which feeds the loopback
pixel clock of the current bridge in use into the LTDC. This mux is only
accessible through sysconfig registers which is not yet available in the
STM32MP25x common clock framework.
While waiting for a complete update of the clock framework, this would
allow to use the LVDS.
Signed-off-by: Raphael Gallais-Pou
Signed-off-by: Yannick Fertre
---
Changes in v2:
- Fixed my address
- Fixed smatch warning
---
drivers/gpu/drm/stm/ltdc.c | 19 +++
drivers/gpu/drm/stm/ltdc.h | 1 +
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 5576fdae4962..23011a8913bd 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -838,6 +838,12 @@ ltdc_crtc_mode_valid(struct drm_crtc *crtc,
int target_max = target + CLK_TOLERANCE_HZ;
int result;
+ if (ldev->lvds_clk) {
+ result = clk_round_rate(ldev->lvds_clk, target);
+ DRM_DEBUG_DRIVER("lvds pixclk rate target %d, available %d\n",
+target, result);
+ }
+
result = clk_round_rate(ldev->pixel_clk, target);
DRM_DEBUG_DRIVER("clk rate target %d, available %d\n", target, result);
@@ -1896,6 +1902,8 @@ void ltdc_suspend(struct drm_device *ddev)
DRM_DEBUG_DRIVER("\n");
clk_disable_unprepare(ldev->pixel_clk);
+ if (ldev->lvds_clk)
+ clk_disable_unprepare(ldev->lvds_clk);
}
int ltdc_resume(struct drm_device *ddev)
@@ -1910,6 +1918,13 @@ int ltdc_resume(struct drm_device *ddev)
DRM_ERROR("failed to enable pixel clock (%d)\n", ret);
return ret;
}
+ if (ldev->lvds_clk) {
+ if (clk_prepare_enable(ldev->lvds_clk)) {
+ clk_disable_unprepare(ldev->pixel_clk);
+ DRM_ERROR("Unable to prepare lvds clock\n");
+ return -ENODEV;
+ }
+ }
return 0;
}
@@ -1981,6 +1996,10 @@ int ltdc_load(struct drm_device *ddev)
}
}
+ ldev->lvds_clk = devm_clk_get(dev, "lvds");
+ if (IS_ERR(ldev->lvds_clk))
+ ldev->lvds_clk = NULL;
+
rstc = devm_reset_control_get_exclusive(dev, NULL);
mutex_init(&ldev->err_lock);
diff --git a/drivers/gpu/drm/stm/ltdc.h b/drivers/gpu/drm/stm/ltdc.h
index 9d488043ffdb..4a60ce5b610c 100644
--- a/drivers/gpu/drm/stm/ltdc.h
+++ b/drivers/gpu/drm/stm/ltdc.h
@@ -44,6 +44,7 @@ struct ltdc_device {
void __iomem *regs;
struct regmap *regmap;
struct clk *pixel_clk; /* lcd pixel clock */
+ struct clk *lvds_clk; /* lvds pixel clock */
struct mutex err_lock; /* protecting error_status */
struct ltdc_caps caps;
u32 irq_status;
Re: [PATCH v6 12/16] ASoC: codecs: add MT6357 support
On Wed, Jun 19, 2024 at 04:46:48PM +0200, amerg...@baylibre.com wrote: > From: Nicolas Belin > > Add the support of MT6357 PMIC audio codec. This breaks an x86 allmodconfig build: /build/stage/linux/sound/soc/codecs/mt6357.c: In function ‘mt_delay_250_event’: /build/stage/linux/sound/soc/codecs/mt6357.c:993:29: error: unused variable ‘pri v’ [-Werror=unused-variable] 993 | struct mt6357_priv *priv = snd_soc_component_get_drvdata(cmpnt); | ^~~~ /build/stage/linux/sound/soc/codecs/mt6357.c: In function ‘mt6357_platform_drive r_probe’: /build/stage/linux/sound/soc/codecs/mt6357.c:1867:55: error: too many arguments for format [-Werror=format-extra-args] 1867 | return dev_err_probe(&pdev->dev, ret, "Failed to parse d ts\n", __func__); | ^~ ~ cc1: all warnings being treated as errors signature.asc Description: PGP signature
Re: [PATCH v6 03/16] dt-bindings: mfd: mediatek: Add codec property for MT6357 PMIC
On 19/06/2024 16:46, Alexandre Mergnat wrote: > Add the audio codec sub-device. This sub-device is used to set the > optional voltage values according to the hardware. > The properties are: > - Setup of microphone bias voltage. > - Setup of the speaker pin pull-down. > > Also, add the audio power supply property which is dedicated for > the audio codec sub-device. > > Signed-off-by: Alexandre Mergnat > --- > .../devicetree/bindings/mfd/mediatek,mt6357.yaml | 33 > ++ > 1 file changed, 33 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml > b/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml > index 37423c2e0fdf..d95307393e75 100644 > --- a/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml > +++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml > @@ -37,6 +37,32 @@ properties: >"#interrupt-cells": > const: 2 > > + vaud28-supply: > +description: 2.8 volt supply phandle for the audio codec > + > + audio-codec: > +type: object Still not much improved. You do not have any resources there, so these should go to the parent node. Best regards, Krzysztof
Re: [PATCH v4 06/15] dt-bindings: display: mediatek: dpi: add power-domains property
Hi, Alexandre:
於 2024年5月23日 週四 下午8:49寫道：
>
> From: Fabien Parent
>
> DPI is part of the display / multimedia block in MediaTek SoCs, and
> always have a power-domain (at least in the upstream device-trees).
> Add the power-domains property to the binding documentation.
I've tired to apply this patch but has conflict. Please rebase this
patch onto latest mainline kernel.
Other binding patches in this series is applied to mediatek-drm-next [1].
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
>
> Fixes: 9273cf7d3942 ("dt-bindings: display: mediatek: convert the dpi
> bindings to yaml")
> Signed-off-by: Fabien Parent
> Reviewed-by: AngeloGioacchino Del Regno
>
> Acked-by: Rob Herring (Arm)
> Signed-off-by: Alexandre Mergnat
> ---
> Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml | 5
> +
> 1 file changed, 5 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
> index 6607cb1c6e0a..169d054d81ff 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
> @@ -80,6 +80,9 @@ properties:
>- port@0
>- port@1
>
> + power-domains:
> +maxItems: 1
> +
> required:
>- compatible
>- reg
> @@ -99,11 +102,13 @@ examples:
>- |
> #include
> #include
> +#include
>
> dpi: dpi@1401d000 {
> compatible = "mediatek,mt8173-dpi";
> reg = <0x1401d000 0x1000>;
> interrupts = ;
> +power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
> clocks = <&mmsys CLK_MM_DPI_PIXEL>,
> <&mmsys CLK_MM_DPI_ENGINE>,
> <&apmixedsys CLK_APMIXED_TVDPLL>;
>
> --
> 2.25.1
>
Re: [PATCH v1 1/3] dt-bindings: display: st7701: Add Anbernic RG28XX panel
On 21/06/2024 12:59, Hironori KIKUCHI wrote:
> Hello Krzysztof,
>
> Thank you for your reply!
>
> On Tue, Jun 18, 2024 at 6:17 PM Krzysztof Kozlowski wrote:
>>
>> On 18/06/2024 10:15, Hironori KIKUCHI wrote:
>>> The RG28XX panel is a panel specific to the Anbernic RG28XX.
>>> It is 2.8 inches in size (diagonally) with a resolution of 480x640.
>>>
>>> Signed-off-by: Hironori KIKUCHI
>>> ---
>>> .../display/panel/sitronix,st7701.yaml| 36 +--
>>> 1 file changed, 34 insertions(+), 2 deletions(-)
>>
>> Nothing explains in the commit msg why rg28xx is actually st7701.
>> Changing interface to SPI suggests it is not.
>
> Thanks, I'll explain like this;
> ---
> dt-bindings: display: st7701: Add Anbernic RG28XX panel
>
> The RG28XX panel is a panel specific to the Anbernic RG28XX
> handheld device. It is 2.8 inches in size (diagonally) with a
> resolution of 480x640.
>
> This panel is driven by a variant of ST7701 driver IC internally,
> confirmed by dumping and analyzing its BSP initialization sequence
> by using a logic analyzer. It is very similar to the existing
> densitron,dmt028vghmcmi-1a panel, but differs in some unknown
> register values, so add a new entry for the panel to distinguish them.
>
> Additionally, it is connected over SPI, instead of MIPI DSI. So
> add and modify for SPI as well.
> ---
OK.
>
>>
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml
>>> b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml
>>> index b348f5bf0a9..04f6751ccca 100644
>>> --- a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml
>>> +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml
>>> @@ -22,19 +22,21 @@ description: |
>>>
>>> allOf:
>>>- $ref: panel-common.yaml#
>>> + - $ref: /schemas/spi/spi-peripheral-props.yaml#
>>>
>>> properties:
>>>compatible:
>>> items:
>>>- enum:
>>>- anbernic,rg-arc-panel
>>> + - anbernic,rg28xx-panel
>>
>> What is xx? Wildcards are not allowed, in general.
>>
>> Can it be anything else than panel? If not, then drop "-panel".
>
> It's supprising but it actually is a product name of the handheld device...
> The panel comes with the device, and part# is completely unknown.
OK
>
>>
>>
>>>- densitron,dmt028vghmcmi-1a
>>>- elida,kd50t048a
>>>- techstar,ts8550b
>>>- const: sitronix,st7701
>>>
>>>reg:
>>> -description: DSI virtual channel used by that screen
>>> +description: DSI / SPI channel used by that screen
>>> maxItems: 1
>>>
>>>VCC-supply:
>>> @@ -43,6 +45,13 @@ properties:
>>>IOVCC-supply:
>>> description: I/O system regulator
>>>
>>> + dc-gpios:
>>> +maxItems: 1
>>> +description: |
>>
>> Do not need '|' unless you need to preserve formatting.
>
> Thanks, I'll remove it.
>
>>
>>> + Controller data/command selection (D/CX) in 4-line SPI mode.
>>> + If not set, the controller is in 3-line SPI mode.
>>> + No effect for DSI.
>>
>> Which devices can be connected over SPI? It seems not all, so this
>> should be disallowed (": false" in allOf:if:then:; move the allOf to
>> bottom like in example-schema) for them.
>
> Hmm... That's a difficult question...
>
> There are 3 types of connection that trying to support:
> DSI, SPI with D/CX pin, and SPI without D/CX pin.
>
> The dc-gpios is required for SPI with D/CX pin, but not for others.
>
> DSI:
> - anbernic,rg-arc-panel
> - densitron,dmt028vghmcmi-1a
> - elida,kd50t048a
> - techstar,ts8550b
>
> SPI without D/CX pin:
> - anbernic,rg28xx-panel
>
> But, there are no panels with D/CX pin so far.
> How should I deal with this? just disallow all, perhaps?
You can disallow for all existing panels, if you are unsure.
>
>
> BTW, does panel's compatible string consider to include it's interface?
No, the compatible defines the device, not its wiring (bus). The parent
node defines which bus is needed.
> ie, what if two panels use the exact same commands and timings, but
> over different interface,
> ... are they "compatible" or not?
Best regards,
Krzysztof
[PATCH v2 00/31] Preparatory patches for BCM2712 (Pi5) support
Hi This set is a number of minor fixes that we've had downstream for a while, and then lays down the some infrastructure changes to facilitate adding support of BCM2712. I'm just finalising those patches so they should follow on fairly soon. Thanks Dave --- v1 -> v2 - Sorted Maxime's email address (git log hid the old address due to mailmap) - Added my missed SoB to Dom's patch - Extended commit subjects to standardise and include what part of vc4 was being updated. - Added Fixes tags to all appropriate patches - Dropped "Limit max_bpc to 8 on Pi0-3" as that is already fixed by b47a72f30768f - Added "drm/vc4: hvs: Correct logic on stopping an HVS channel" as it is a pre-2712 fix that I found as I was then adding the 2712 stuff on top. Dave Stevenson (8): drm/vc4: crtc: Force trigger of dlist update on margins change drm/vc4: hvs: Set AXI panic modes for the HVS drm/vc4: hvs: Don't write gamma luts on 2711 drm/vc4: plane: YUV planes require vertical scaling to always be enabled drm/vc4: hvs: Fix dlist debug not resetting the next entry pointer drm/vc4: hvs: Remove incorrect limit from hvs_dlist debugfs function drm/vc4: plane: Move the buffer offset out of the vc4_plane_state drm/vc4: hvs: Correct logic on stopping an HVS channel Dom Cobley (7): drm/vc4: plane: Keep fractional source coords inside state drm/vc4: plane: Handle fractional coordinates using the phase field drm/vc4: hdmi: Avoid log spam for audio start failure drm/vc4: plane: Add support for YUV444 formats drm/vc4: hdmi: Increase audio MAI fifo dreq threshold drm/vc4: hdmi: Avoid hang with debug registers when suspended drm/vc4: hvs: Remove ABORT_ON_EMPTY flag Maxime Ripard (15): drm/vc4: hdmi: Warn if writing to an unknown HDMI register drm/vc4: hvs: More logging for dlist generation drm/vc4: hvs: Print error if we fail an allocation drm/vc4: plane: Add more debugging for LBM allocation drm/vc4: plane: Use return variable in atomic_check drm/vc4: crtc: Move assigned_channel to a variable drm/vc4: Introduce generation number enum drm/vc4: Make v3d paths unavailable on any generation newer than vc4 drm/vc4: hvs: Use switch statement to simplify vc4_hvs_get_fifo_from_output drm/vc4: hvs: Create hw_init function drm/vc4: hvs: Create cob_init function drm/vc4: hvs: Rename hvs_regs list drm/vc4: plane: Change ptr0_offset to an array drm/vc4: hvs: Rework LBM alignment drm/vc4: hvs: Change prototype of __vc4_hvs_alloc to pass registers Tim Gover (1): drm/vc4: hvs: Enable SCALER_CONTROL early in HVS init drivers/gpu/drm/vc4/tests/vc4_mock.c | 14 +- drivers/gpu/drm/vc4/vc4_bo.c | 28 +- drivers/gpu/drm/vc4/vc4_crtc.c | 35 +- drivers/gpu/drm/vc4/vc4_drv.c | 22 +- drivers/gpu/drm/vc4/vc4_drv.h | 29 +- drivers/gpu/drm/vc4/vc4_gem.c | 24 +- drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +- drivers/gpu/drm/vc4/vc4_hdmi_regs.h| 5 +- drivers/gpu/drm/vc4/vc4_hvs.c | 351 + drivers/gpu/drm/vc4/vc4_irq.c | 10 +- drivers/gpu/drm/vc4/vc4_kms.c | 14 +- drivers/gpu/drm/vc4/vc4_perfmon.c | 20 +- drivers/gpu/drm/vc4/vc4_plane.c| 281 +++-- drivers/gpu/drm/vc4/vc4_regs.h | 1 + drivers/gpu/drm/vc4/vc4_render_cl.c| 2 +- drivers/gpu/drm/vc4/vc4_v3d.c | 10 +- drivers/gpu/drm/vc4/vc4_validate.c | 8 +- drivers/gpu/drm/vc4/vc4_validate_shaders.c | 2 +- 18 files changed, 538 insertions(+), 343 deletions(-) -- 2.34.1
[PATCH v2 01/31] drm/vc4: plane: Keep fractional source coords inside state
From: Dom Cobley
Fractional source co-ordinates can be used to setup the scaling
filters, so retain the information.
Signed-off-by: Dom Cobley
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_drv.h | 2 +-
drivers/gpu/drm/vc4/vc4_plane.c | 68 -
2 files changed, 34 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 08e29fa82563..697e9b7c9d0e 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -404,7 +404,7 @@ struct vc4_plane_state {
/* Clipped coordinates of the plane on the display. */
int crtc_x, crtc_y, crtc_w, crtc_h;
- /* Clipped area being scanned from in the FB. */
+ /* Clipped area being scanned from in the FB in u16.16 format */
u32 src_x, src_y;
u32 src_w[2], src_h[2];
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 07caf2a47c6c..e0df210bedcb 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -251,9 +251,9 @@ static const struct hvs_format *vc4_get_hvs_format(u32
drm_format)
static enum vc4_scaling_mode vc4_get_scaling_mode(u32 src, u32 dst)
{
- if (dst == src)
+ if (dst == src >> 16)
return VC4_SCALING_NONE;
- if (3 * dst >= 2 * src)
+ if (3 * dst >= 2 * (src >> 16))
return VC4_SCALING_PPF;
else
return VC4_SCALING_TPZ;
@@ -462,15 +462,10 @@ static int vc4_plane_setup_clipping_and_scaling(struct
drm_plane_state *state)
vc4_state->offsets[i] = bo->dma_addr + fb->offsets[i];
}
- /*
-* We don't support subpixel source positioning for scaling,
-* but fractional coordinates can be generated by clipping
-* so just round for now
-*/
- vc4_state->src_x = DIV_ROUND_CLOSEST(state->src.x1, 1 << 16);
- vc4_state->src_y = DIV_ROUND_CLOSEST(state->src.y1, 1 << 16);
- vc4_state->src_w[0] = DIV_ROUND_CLOSEST(state->src.x2, 1 << 16) -
vc4_state->src_x;
- vc4_state->src_h[0] = DIV_ROUND_CLOSEST(state->src.y2, 1 << 16) -
vc4_state->src_y;
+ vc4_state->src_x = state->src.x1;
+ vc4_state->src_y = state->src.y1;
+ vc4_state->src_w[0] = state->src.x2 - vc4_state->src_x;
+ vc4_state->src_h[0] = state->src.y2 - vc4_state->src_y;
vc4_state->crtc_x = state->dst.x1;
vc4_state->crtc_y = state->dst.y1;
@@ -523,7 +518,7 @@ static void vc4_write_tpz(struct vc4_plane_state
*vc4_state, u32 src, u32 dst)
{
u32 scale, recip;
- scale = (1 << 16) * src / dst;
+ scale = src / dst;
/* The specs note that while the reciprocal would be defined
* as (1<<32)/scale, ~0 is close enough.
@@ -569,7 +564,7 @@ static u32 vc4_lbm_size(struct drm_plane_state *state)
if (vc4_state->x_scaling[0] == VC4_SCALING_TPZ)
pix_per_line = vc4_state->crtc_w;
else
- pix_per_line = vc4_state->src_w[0];
+ pix_per_line = vc4_state->src_w[0] >> 16;
if (!vc4_state->is_yuv) {
if (vc4_state->y_scaling[0] == VC4_SCALING_TPZ)
@@ -660,7 +655,8 @@ static void vc4_plane_calc_load(struct drm_plane_state
*state)
for (i = 0; i < fb->format->num_planes; i++) {
/* Even if the bandwidth/plane required for a single frame is
*
-* vc4_state->src_w[i] * vc4_state->src_h[i] * cpp * vrefresh
+* (vc4_state->src_w[i] >> 16) * (vc4_state->src_h[i] >> 16) *
+* cpp * vrefresh
*
* when downscaling, we have to read more pixels per line in
* the time frame reserved for a single line, so the bandwidth
@@ -669,11 +665,11 @@ static void vc4_plane_calc_load(struct drm_plane_state
*state)
* load by this number. We're likely over-estimating the read
* demand, but that's better than under-estimating it.
*/
- vscale_factor = DIV_ROUND_UP(vc4_state->src_h[i],
+ vscale_factor = DIV_ROUND_UP(vc4_state->src_h[i] >> 16,
vc4_state->crtc_h);
- vc4_state->membus_load += vc4_state->src_w[i] *
- vc4_state->src_h[i] * vscale_factor *
- fb->format->cpp[i];
+ vc4_state->membus_load += (vc4_state->src_w[i] >> 16) *
+ (vc4_state->src_h[i] >> 16) *
+ vscale_factor * fb->format->cpp[i];
vc4_state->hvs_load += vc4_state->crtc_h * vc4_state->crtc_w;
}
@@ -826,7 +822,8 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
bool mix_plane_alpha;
bool covers_screen;
u32 scl0, scl1, pitch0;
- u32 tiling, src_y;
+
[PATCH v2 02/31] drm/vc4: plane: Handle fractional coordinates using the phase field
From: Dom Cobley
Apply fractional source co-ordinates into the scaling filters.
Signed-off-by: Dom Cobley
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_plane.c | 87 -
1 file changed, 76 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index e0df210bedcb..b8c68d4688c8 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -532,14 +532,61 @@ static void vc4_write_tpz(struct vc4_plane_state
*vc4_state, u32 src, u32 dst)
VC4_SET_FIELD(recip, SCALER_TPZ1_RECIP));
}
-static void vc4_write_ppf(struct vc4_plane_state *vc4_state, u32 src, u32 dst)
+/* phase magnitude bits */
+#define PHASE_BITS 6
+
+static void vc4_write_ppf(struct vc4_plane_state *vc4_state, u32 src, u32 dst,
+ u32 xy, int channel)
{
- u32 scale = (1 << 16) * src / dst;
+ u32 scale = src / dst;
+ s32 offset, offset2;
+ s32 phase;
+
+ /*
+* Start the phase at 1/2 pixel from the 1st pixel at src_x.
+* 1/4 pixel for YUV.
+*/
+ if (channel) {
+ /*
+* The phase is relative to scale_src->x, so shift it for
+* display list's x value
+*/
+ offset = (xy & 0x1) >> (16 - PHASE_BITS) >> 1;
+ offset += -(1 << PHASE_BITS >> 2);
+ } else {
+ /*
+* The phase is relative to scale_src->x, so shift it for
+* display list's x value
+*/
+ offset = (xy & 0x) >> (16 - PHASE_BITS);
+ offset += -(1 << PHASE_BITS >> 1);
+
+ /*
+* This is a kludge to make sure the scaling factors are
+* consistent with YUV's luma scaling. We lose 1-bit precision
+* because of this.
+*/
+ scale &= ~1;
+ }
+
+ /*
+* There may be a also small error introduced by precision of scale.
+* Add half of that as a compromise
+*/
+ offset2 = src - dst * scale;
+ offset2 >>= 16 - PHASE_BITS;
+ phase = offset + (offset2 >> 1);
+
+ /* Ensure +ve values don't touch the sign bit, then truncate negative
values */
+ if (phase >= 1 << PHASE_BITS)
+ phase = (1 << PHASE_BITS) - 1;
+
+ phase &= SCALER_PPF_IPHASE_MASK;
vc4_dlist_write(vc4_state,
SCALER_PPF_AGC |
VC4_SET_FIELD(scale, SCALER_PPF_SCALE) |
- VC4_SET_FIELD(0, SCALER_PPF_IPHASE));
+ VC4_SET_FIELD(phase, SCALER_PPF_IPHASE));
}
static u32 vc4_lbm_size(struct drm_plane_state *state)
@@ -597,27 +644,27 @@ static void vc4_write_scaling_parameters(struct
drm_plane_state *state,
/* Ch0 H-PPF Word 0: Scaling Parameters */
if (vc4_state->x_scaling[channel] == VC4_SCALING_PPF) {
- vc4_write_ppf(vc4_state,
- vc4_state->src_w[channel], vc4_state->crtc_w);
+ vc4_write_ppf(vc4_state, vc4_state->src_w[channel],
+ vc4_state->crtc_w, vc4_state->src_x, channel);
}
/* Ch0 V-PPF Words 0-1: Scaling Parameters, Context */
if (vc4_state->y_scaling[channel] == VC4_SCALING_PPF) {
- vc4_write_ppf(vc4_state,
- vc4_state->src_h[channel], vc4_state->crtc_h);
+ vc4_write_ppf(vc4_state, vc4_state->src_h[channel],
+ vc4_state->crtc_h, vc4_state->src_y, channel);
vc4_dlist_write(vc4_state, 0xc0c0c0c0);
}
/* Ch0 H-TPZ Words 0-1: Scaling Parameters, Recip */
if (vc4_state->x_scaling[channel] == VC4_SCALING_TPZ) {
- vc4_write_tpz(vc4_state,
- vc4_state->src_w[channel], vc4_state->crtc_w);
+ vc4_write_tpz(vc4_state, vc4_state->src_w[channel],
+ vc4_state->crtc_w);
}
/* Ch0 V-TPZ Words 0-2: Scaling Parameters, Recip, Context */
if (vc4_state->y_scaling[channel] == VC4_SCALING_TPZ) {
- vc4_write_tpz(vc4_state,
- vc4_state->src_h[channel], vc4_state->crtc_h);
+ vc4_write_tpz(vc4_state, vc4_state->src_h[channel],
+ vc4_state->crtc_h);
vc4_dlist_write(vc4_state, 0xc0c0c0c0);
}
}
@@ -1052,6 +1099,24 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
return -EINVAL;
}
+ /* fetch an extra pixel if we don't actually line up with the left
edge. */
+ if ((vc4_state->src_x & 0x) && vc4_state->src_x < (state->fb->width
<< 16))
+ width++;
+
+ /* same for the right side */
+ if (((vc4_state->src_x + vc4_state->src_w[0]) & 0x) &&
+
[PATCH v2 10/31] drm/vc4: hvs: Print error if we fail an allocation
From: Maxime Ripard
We need to allocate a few additional structures when checking our
atomic_state, especially related to hardware SRAM that will hold the
plane descriptors (DLIST) and the current line context (LBM) during
composition.
Since those allocation can fail, let's add some error message in that
case to help debug what goes wrong.
Signed-off-by: Maxime Ripard
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_hvs.c | 4 +++-
drivers/gpu/drm/vc4/vc4_plane.c | 7 +--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index 189d00fcf4c2..2c69b74b25a7 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -475,8 +475,10 @@ int vc4_hvs_atomic_check(struct drm_crtc *crtc, struct
drm_atomic_state *state)
ret = drm_mm_insert_node(&vc4->hvs->dlist_mm, &vc4_state->mm,
dlist_count);
spin_unlock_irqrestore(&vc4->hvs->mm_lock, flags);
- if (ret)
+ if (ret) {
+ drm_err(dev, "Failed to allocate DLIST entry: %d\n", ret);
return ret;
+ }
return 0;
}
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 978433554f3d..e4fcef11cf6f 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -739,7 +739,8 @@ static void vc4_plane_calc_load(struct drm_plane_state
*state)
static int vc4_plane_allocate_lbm(struct drm_plane_state *state)
{
- struct vc4_dev *vc4 = to_vc4_dev(state->plane->dev);
+ struct drm_device *drm = state->plane->dev;
+ struct vc4_dev *vc4 = to_vc4_dev(drm);
struct vc4_plane_state *vc4_state = to_vc4_plane_state(state);
unsigned long irqflags;
u32 lbm_size;
@@ -765,8 +766,10 @@ static int vc4_plane_allocate_lbm(struct drm_plane_state
*state)
0, 0);
spin_unlock_irqrestore(&vc4->hvs->mm_lock, irqflags);
- if (ret)
+ if (ret) {
+ drm_err(drm, "Failed to allocate LBM entry: %d\n", ret);
return ret;
+ }
} else {
WARN_ON_ONCE(lbm_size != vc4_state->lbm.size);
}
--
2.34.1
[PATCH v2 03/31] drm/vc4: crtc: Force trigger of dlist update on margins change
When the margins are changed, the dlist needs to be regenerated
with the changed updated dest regions for each of the planes.
Setting the zpos_changed flag is sufficient to trigger that
without doing a full modeset, therefore set it should the
margins be changed.
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_crtc.c | 15 +++
drivers/gpu/drm/vc4/vc4_drv.h | 7 +--
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 8b5a7e5eb146..1d54176cf811 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -735,10 +735,17 @@ int vc4_crtc_atomic_check(struct drm_crtc *crtc,
if (conn_state->crtc != crtc)
continue;
- vc4_state->margins.left = conn_state->tv.margins.left;
- vc4_state->margins.right = conn_state->tv.margins.right;
- vc4_state->margins.top = conn_state->tv.margins.top;
- vc4_state->margins.bottom = conn_state->tv.margins.bottom;
+ if (memcmp(&vc4_state->margins, &conn_state->tv.margins,
+ sizeof(vc4_state->margins))) {
+ memcpy(&vc4_state->margins, &conn_state->tv.margins,
+ sizeof(vc4_state->margins));
+
+ /*
+* Need to force the dlist entries for all planes to be
+* updated so that the dest rectangles are changed.
+*/
+ crtc_state->zpos_changed = true;
+ }
break;
}
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 697e9b7c9d0e..717fd1140561 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -598,12 +598,7 @@ struct vc4_crtc_state {
bool txp_armed;
unsigned int assigned_channel;
- struct {
- unsigned int left;
- unsigned int right;
- unsigned int top;
- unsigned int bottom;
- } margins;
+ struct drm_connector_tv_margins margins;
unsigned long hvs_load;
--
2.34.1
[PATCH v2 09/31] drm/vc4: hvs: More logging for dlist generation
From: Maxime Ripard
DLIST generation can get pretty tricky and there's not a lot of debug in
the driver to help. Let's add a few more to track the generated DLIST
size.
Signed-off-by: Maxime Ripard
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_hvs.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index 267c9fde7362..189d00fcf4c2 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -456,11 +456,21 @@ int vc4_hvs_atomic_check(struct drm_crtc *crtc, struct
drm_atomic_state *state)
if (hweight32(crtc_state->connector_mask) > 1)
return -EINVAL;
- drm_atomic_crtc_state_for_each_plane_state(plane, plane_state,
crtc_state)
- dlist_count += vc4_plane_dlist_size(plane_state);
+ drm_atomic_crtc_state_for_each_plane_state(plane, plane_state,
crtc_state) {
+ u32 plane_dlist_count = vc4_plane_dlist_size(plane_state);
+
+ drm_dbg_driver(dev, "[CRTC:%d:%s] Found [PLANE:%d:%s] with
DLIST size: %u\n",
+ crtc->base.id, crtc->name,
+ plane->base.id, plane->name,
+ plane_dlist_count);
+
+ dlist_count += plane_dlist_count;
+ }
dlist_count++; /* Account for SCALER_CTL0_END. */
+ drm_dbg_driver(dev, "[CRTC:%d:%s] Allocating DLIST block with size:
%u\n",
+ crtc->base.id, crtc->name, dlist_count);
spin_lock_irqsave(&vc4->hvs->mm_lock, flags);
ret = drm_mm_insert_node(&vc4->hvs->dlist_mm, &vc4_state->mm,
dlist_count);
--
2.34.1
[PATCH v2 12/31] drm/vc4: plane: Use return variable in atomic_check
From: Maxime Ripard The vc4_plane_atomic_check() directly returns the result of the final function it calls. Using the already defined ret variable to check its content on error, and a separate return 0 on success, makes it easier to extend. Signed-off-by: Maxime Ripard Signed-off-by: Dave Stevenson --- drivers/gpu/drm/vc4/vc4_plane.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c index 16197c4b4b33..d078a2d21eea 100644 --- a/drivers/gpu/drm/vc4/vc4_plane.c +++ b/drivers/gpu/drm/vc4/vc4_plane.c @@ -1386,7 +1386,11 @@ static int vc4_plane_atomic_check(struct drm_plane *plane, if (ret) return ret; - return vc4_plane_allocate_lbm(new_plane_state); + ret = vc4_plane_allocate_lbm(new_plane_state); + if (ret) + return ret; + + return 0; } static void vc4_plane_atomic_update(struct drm_plane *plane, -- 2.34.1
[PATCH v2 06/31] drm/vc4: hvs: Set AXI panic modes for the HVS
The HVS can change AXI request mode based on how full the COB FIFOs are. Until now the vc4 driver has been relying on the firmware to have set these to sensible values. With HVS channel 2 now being used for live video, change the panic mode for all channels to be explicitly set by the driver, and the same for all channels. Signed-off-by: Dave Stevenson --- drivers/gpu/drm/vc4/vc4_hvs.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c index 04af672caacb..267c9fde7362 100644 --- a/drivers/gpu/drm/vc4/vc4_hvs.c +++ b/drivers/gpu/drm/vc4/vc4_hvs.c @@ -951,6 +951,17 @@ static int vc4_hvs_bind(struct device *dev, struct device *master, void *data) SCALER_DISPCTRL_SCLEIRQ); + /* Set AXI panic mode. +* VC4 panics when < 2 lines in FIFO. +* VC5 panics when less than 1 line in the FIFO. +*/ + dispctrl &= ~(SCALER_DISPCTRL_PANIC0_MASK | + SCALER_DISPCTRL_PANIC1_MASK | + SCALER_DISPCTRL_PANIC2_MASK); + dispctrl |= VC4_SET_FIELD(2, SCALER_DISPCTRL_PANIC0); + dispctrl |= VC4_SET_FIELD(2, SCALER_DISPCTRL_PANIC1); + dispctrl |= VC4_SET_FIELD(2, SCALER_DISPCTRL_PANIC2); + /* Set AXI panic mode. * VC4 panics when < 2 lines in FIFO. * VC5 panics when less than 1 line in the FIFO. -- 2.34.1
[PATCH v2 05/31] drm/vc4: plane: Add support for YUV444 formats
From: Dom Cobley
Support displaying DRM_FORMAT_YUV444 and DRM_FORMAT_YVU444 formats.
Tested with kmstest and kodi. e.g.
kmstest -r 1920x1080@60 -f 400x300-YU24
Note: without the shift of width, only half the chroma is fetched,
resulting in correct left half of image and corrupt colours on right half.
The increase in width shouldn't affect fetching of Y data,
as the hardware will clamp at dest width.
Signed-off-by: Dom Cobley
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_plane.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index b8c68d4688c8..978433554f3d 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -109,6 +109,18 @@ static const struct hvs_format {
.pixel_order = HVS_PIXEL_ORDER_XYCRCB,
.pixel_order_hvs5 = HVS_PIXEL_ORDER_XYCRCB,
},
+ {
+ .drm = DRM_FORMAT_YUV444,
+ .hvs = HVS_PIXEL_FORMAT_YCBCR_YUV422_3PLANE,
+ .pixel_order = HVS_PIXEL_ORDER_XYCBCR,
+ .pixel_order_hvs5 = HVS_PIXEL_ORDER_XYCBCR,
+ },
+ {
+ .drm = DRM_FORMAT_YVU444,
+ .hvs = HVS_PIXEL_FORMAT_YCBCR_YUV422_3PLANE,
+ .pixel_order = HVS_PIXEL_ORDER_XYCRCB,
+ .pixel_order_hvs5 = HVS_PIXEL_ORDER_XYCRCB,
+ },
{
.drm = DRM_FORMAT_YUV420,
.hvs = HVS_PIXEL_FORMAT_YCBCR_YUV420_3PLANE,
@@ -1117,6 +1129,12 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
vc4_state->src_y + vc4_state->src_h[0] < (state->fb->height << 16))
height++;
+ /* For YUV444 the hardware wants double the width, otherwise it doesn't
+* fetch full width of chroma
+*/
+ if (format->drm == DRM_FORMAT_YUV444 || format->drm ==
DRM_FORMAT_YVU444)
+ width <<= 1;
+
/* Don't waste cycles mixing with plane alpha if the set alpha
* is opaque or there is no per-pixel alpha information.
* In any case we use the alpha property value as the fixed alpha.
--
2.34.1
[PATCH v2 11/31] drm/vc4: plane: Add more debugging for LBM allocation
From: Maxime Ripard
LBM allocations need a different size depending on the line length,
format, etc.
This can get tricky, and fail. Let's add some more prints to ease the
debugging when it does.
Signed-off-by: Maxime Ripard
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_plane.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index e4fcef11cf6f..16197c4b4b33 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -741,6 +741,7 @@ static int vc4_plane_allocate_lbm(struct drm_plane_state
*state)
{
struct drm_device *drm = state->plane->dev;
struct vc4_dev *vc4 = to_vc4_dev(drm);
+ struct drm_plane *plane = state->plane;
struct vc4_plane_state *vc4_state = to_vc4_plane_state(state);
unsigned long irqflags;
u32 lbm_size;
@@ -749,6 +750,9 @@ static int vc4_plane_allocate_lbm(struct drm_plane_state
*state)
if (!lbm_size)
return 0;
+ drm_dbg_driver(drm, "[PLANE:%d:%s] LBM Allocation Size: %u\n",
+ plane->base.id, plane->name, lbm_size);
+
if (WARN_ON(!vc4_state->lbm_offset))
return -EINVAL;
--
2.34.1
[PATCH v2 31/31] drm/vc4: hvs: Correct logic on stopping an HVS channel
When factoring out __vc4_hvs_stop_channel, the logic got inverted from
if (condition)
// stop channel
to
if (condition)
goto out
//stop channel
out:
and also changed the exact register writes used to stop the channel.
Correct the logic so that the channel is actually stopped, and revert
to the original register writes.
Fixes: 6d01a106b4c8 ("drm/vc4: crtc: Move HVS init and close to a function")
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_hvs.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index be2173f6c58e..af79b19817d5 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -427,13 +427,11 @@ void vc4_hvs_stop_channel(struct vc4_hvs *hvs, unsigned
int chan)
if (!drm_dev_enter(drm, &idx))
return;
- if (HVS_READ(SCALER_DISPCTRLX(chan)) & SCALER_DISPCTRLX_ENABLE)
+ if (!(HVS_READ(SCALER_DISPCTRLX(chan)) & SCALER_DISPCTRLX_ENABLE))
goto out;
- HVS_WRITE(SCALER_DISPCTRLX(chan),
- HVS_READ(SCALER_DISPCTRLX(chan)) | SCALER_DISPCTRLX_RESET);
- HVS_WRITE(SCALER_DISPCTRLX(chan),
- HVS_READ(SCALER_DISPCTRLX(chan)) & ~SCALER_DISPCTRLX_ENABLE);
+ HVS_WRITE(SCALER_DISPCTRLX(chan), SCALER_DISPCTRLX_RESET);
+ HVS_WRITE(SCALER_DISPCTRLX(chan), 0);
/* Once we leave, the scaler should be disabled and its fifo empty. */
WARN_ON_ONCE(HVS_READ(SCALER_DISPCTRLX(chan)) & SCALER_DISPCTRLX_RESET);
--
2.34.1
[PATCH v2 21/31] drm/vc4: Make v3d paths unavailable on any generation newer than vc4
From: Maxime Ripard
The V3D IP has been separate since BCM2711, so let's make sure we issue
a WARN if we're running not only on BCM2711, but also anything newer.
Signed-off-by: Maxime Ripard
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_bo.c | 28 +++---
drivers/gpu/drm/vc4/vc4_crtc.c | 4 ++--
drivers/gpu/drm/vc4/vc4_drv.c | 8 +++
drivers/gpu/drm/vc4/vc4_gem.c | 24 +--
drivers/gpu/drm/vc4/vc4_irq.c | 10
drivers/gpu/drm/vc4/vc4_kms.c | 2 +-
drivers/gpu/drm/vc4/vc4_perfmon.c | 20
drivers/gpu/drm/vc4/vc4_render_cl.c| 2 +-
drivers/gpu/drm/vc4/vc4_v3d.c | 10
drivers/gpu/drm/vc4/vc4_validate.c | 8 +++
drivers/gpu/drm/vc4/vc4_validate_shaders.c | 2 +-
11 files changed, 59 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 89e427c9ed32..06c791ace2d8 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -251,7 +251,7 @@ void vc4_bo_add_to_purgeable_pool(struct vc4_bo *bo)
{
struct vc4_dev *vc4 = to_vc4_dev(bo->base.base.dev);
- if (WARN_ON_ONCE(vc4->gen == VC4_GEN_5))
+ if (WARN_ON_ONCE(vc4->gen > VC4_GEN_4))
return;
mutex_lock(&vc4->purgeable.lock);
@@ -265,7 +265,7 @@ static void vc4_bo_remove_from_purgeable_pool_locked(struct
vc4_bo *bo)
{
struct vc4_dev *vc4 = to_vc4_dev(bo->base.base.dev);
- if (WARN_ON_ONCE(vc4->gen == VC4_GEN_5))
+ if (WARN_ON_ONCE(vc4->gen > VC4_GEN_4))
return;
/* list_del_init() is used here because the caller might release
@@ -396,7 +396,7 @@ struct drm_gem_object *vc4_create_object(struct drm_device
*dev, size_t size)
struct vc4_dev *vc4 = to_vc4_dev(dev);
struct vc4_bo *bo;
- if (WARN_ON_ONCE(vc4->gen == VC4_GEN_5))
+ if (WARN_ON_ONCE(vc4->gen > VC4_GEN_4))
return ERR_PTR(-ENODEV);
bo = kzalloc(sizeof(*bo), GFP_KERNEL);
@@ -427,7 +427,7 @@ struct vc4_bo *vc4_bo_create(struct drm_device *dev, size_t
unaligned_size,
struct drm_gem_dma_object *dma_obj;
struct vc4_bo *bo;
- if (WARN_ON_ONCE(vc4->gen == VC4_GEN_5))
+ if (WARN_ON_ONCE(vc4->gen > VC4_GEN_4))
return ERR_PTR(-ENODEV);
if (size == 0)
@@ -496,7 +496,7 @@ int vc4_bo_dumb_create(struct drm_file *file_priv,
struct vc4_bo *bo = NULL;
int ret;
- if (WARN_ON_ONCE(vc4->gen == VC4_GEN_5))
+ if (WARN_ON_ONCE(vc4->gen > VC4_GEN_4))
return -ENODEV;
ret = vc4_dumb_fixup_args(args);
@@ -622,7 +622,7 @@ int vc4_bo_inc_usecnt(struct vc4_bo *bo)
struct vc4_dev *vc4 = to_vc4_dev(bo->base.base.dev);
int ret;
- if (WARN_ON_ONCE(vc4->gen == VC4_GEN_5))
+ if (WARN_ON_ONCE(vc4->gen > VC4_GEN_4))
return -ENODEV;
/* Fast path: if the BO is already retained by someone, no need to
@@ -661,7 +661,7 @@ void vc4_bo_dec_usecnt(struct vc4_bo *bo)
{
struct vc4_dev *vc4 = to_vc4_dev(bo->base.base.dev);
- if (WARN_ON_ONCE(vc4->gen == VC4_GEN_5))
+ if (WARN_ON_ONCE(vc4->gen > VC4_GEN_4))
return;
/* Fast path: if the BO is still retained by someone, no need to test
@@ -783,7 +783,7 @@ int vc4_create_bo_ioctl(struct drm_device *dev, void *data,
struct vc4_bo *bo = NULL;
int ret;
- if (WARN_ON_ONCE(vc4->gen == VC4_GEN_5))
+ if (WARN_ON_ONCE(vc4->gen > VC4_GEN_4))
return -ENODEV;
ret = vc4_grab_bin_bo(vc4, vc4file);
@@ -813,7 +813,7 @@ int vc4_mmap_bo_ioctl(struct drm_device *dev, void *data,
struct drm_vc4_mmap_bo *args = data;
struct drm_gem_object *gem_obj;
- if (WARN_ON_ONCE(vc4->gen == VC4_GEN_5))
+ if (WARN_ON_ONCE(vc4->gen > VC4_GEN_4))
return -ENODEV;
gem_obj = drm_gem_object_lookup(file_priv, args->handle);
@@ -839,7 +839,7 @@ vc4_create_shader_bo_ioctl(struct drm_device *dev, void
*data,
struct vc4_bo *bo = NULL;
int ret;
- if (WARN_ON_ONCE(vc4->gen == VC4_GEN_5))
+ if (WARN_ON_ONCE(vc4->gen > VC4_GEN_4))
return -ENODEV;
if (args->size == 0)
@@ -918,7 +918,7 @@ int vc4_set_tiling_ioctl(struct drm_device *dev, void *data,
struct vc4_bo *bo;
bool t_format;
- if (WARN_ON_ONCE(vc4->gen == VC4_GEN_5))
+ if (WARN_ON_ONCE(vc4->gen > VC4_GEN_4))
return -ENODEV;
if (args->flags != 0)
@@ -964,7 +964,7 @@ int vc4_get_tiling_ioctl(struct drm_device *dev, void *data,
struct drm_gem_object *gem_obj;
struct vc4_bo *bo;
- if (WARN_ON_ONCE(vc4->gen == VC4_GEN_5))
+ if (WARN_ON_ONCE(vc4->gen > VC4_GEN_4))
return -ENODEV;
if (args
[PATCH v2 07/31] drm/vc4: hdmi: Increase audio MAI fifo dreq threshold
From: Dom Cobley Now we wait for write responses and have a burst size of 4, we can set the fifo threshold much higher. Set it to 28 (of the 32 entry size) to keep fifo fuller and reduce chance of underflow. Signed-off-by: Dom Cobley Signed-off-by: Dave Stevenson --- drivers/gpu/drm/vc4/vc4_hdmi.c | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c index 04d32dc3e98c..ad88915306f1 100644 --- a/drivers/gpu/drm/vc4/vc4_hdmi.c +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c @@ -2041,6 +2041,7 @@ static int vc4_hdmi_audio_prepare(struct device *dev, void *data, struct vc4_hdmi *vc4_hdmi = dev_get_drvdata(dev); struct drm_device *drm = vc4_hdmi->connector.dev; struct drm_connector *connector = &vc4_hdmi->connector; + struct vc4_dev *vc4 = to_vc4_dev(drm); unsigned int sample_rate = params->sample_rate; unsigned int channels = params->channels; unsigned long flags; @@ -2098,11 +2099,18 @@ static int vc4_hdmi_audio_prepare(struct device *dev, void *data, VC4_HDMI_AUDIO_PACKET_CEA_MASK); /* Set the MAI threshold */ - HDMI_WRITE(HDMI_MAI_THR, - VC4_SET_FIELD(0x08, VC4_HD_MAI_THR_PANICHIGH) | - VC4_SET_FIELD(0x08, VC4_HD_MAI_THR_PANICLOW) | - VC4_SET_FIELD(0x06, VC4_HD_MAI_THR_DREQHIGH) | - VC4_SET_FIELD(0x08, VC4_HD_MAI_THR_DREQLOW)); + if (vc4->is_vc5) + HDMI_WRITE(HDMI_MAI_THR, + VC4_SET_FIELD(0x10, VC4_HD_MAI_THR_PANICHIGH) | + VC4_SET_FIELD(0x10, VC4_HD_MAI_THR_PANICLOW) | + VC4_SET_FIELD(0x1c, VC4_HD_MAI_THR_DREQHIGH) | + VC4_SET_FIELD(0x1c, VC4_HD_MAI_THR_DREQLOW)); + else + HDMI_WRITE(HDMI_MAI_THR, + VC4_SET_FIELD(0x8, VC4_HD_MAI_THR_PANICHIGH) | + VC4_SET_FIELD(0x8, VC4_HD_MAI_THR_PANICLOW) | + VC4_SET_FIELD(0x6, VC4_HD_MAI_THR_DREQHIGH) | + VC4_SET_FIELD(0x8, VC4_HD_MAI_THR_DREQLOW)); HDMI_WRITE(HDMI_MAI_CONFIG, VC4_HDMI_MAI_CONFIG_BIT_REVERSE | -- 2.34.1
[PATCH v2 22/31] drm/vc4: hvs: Use switch statement to simplify vc4_hvs_get_fifo_from_output
From: Maxime Ripard
Since we'll support BCM2712 soon, let's move the logic behind
vc4_hvs_get_fifo_from_output() to a switch to extend it more easily.
Signed-off-by: Maxime Ripard
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_hvs.c | 77 +++
1 file changed, 42 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index 7380a02a69a2..922e5f73f5d9 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -296,53 +296,60 @@ int vc4_hvs_get_fifo_from_output(struct vc4_hvs *hvs,
unsigned int output)
u32 reg;
int ret;
- if (vc4->gen == VC4_GEN_4)
+ switch (vc4->gen) {
+ case VC4_GEN_4:
return output;
- /*
-* NOTE: We should probably use drm_dev_enter()/drm_dev_exit()
-* here, but this function is only used during the DRM device
-* initialization, so we should be fine.
-*/
+ case VC4_GEN_5:
+ /*
+* NOTE: We should probably use
+* drm_dev_enter()/drm_dev_exit() here, but this
+* function is only used during the DRM device
+* initialization, so we should be fine.
+*/
- switch (output) {
- case 0:
- return 0;
+ switch (output) {
+ case 0:
+ return 0;
- case 1:
- return 1;
+ case 1:
+ return 1;
- case 2:
- reg = HVS_READ(SCALER_DISPECTRL);
- ret = FIELD_GET(SCALER_DISPECTRL_DSP2_MUX_MASK, reg);
- if (ret == 0)
- return 2;
+ case 2:
+ reg = HVS_READ(SCALER_DISPECTRL);
+ ret = FIELD_GET(SCALER_DISPECTRL_DSP2_MUX_MASK, reg);
+ if (ret == 0)
+ return 2;
- return 0;
+ return 0;
- case 3:
- reg = HVS_READ(SCALER_DISPCTRL);
- ret = FIELD_GET(SCALER_DISPCTRL_DSP3_MUX_MASK, reg);
- if (ret == 3)
- return -EPIPE;
+ case 3:
+ reg = HVS_READ(SCALER_DISPCTRL);
+ ret = FIELD_GET(SCALER_DISPCTRL_DSP3_MUX_MASK, reg);
+ if (ret == 3)
+ return -EPIPE;
- return ret;
+ return ret;
- case 4:
- reg = HVS_READ(SCALER_DISPEOLN);
- ret = FIELD_GET(SCALER_DISPEOLN_DSP4_MUX_MASK, reg);
- if (ret == 3)
- return -EPIPE;
+ case 4:
+ reg = HVS_READ(SCALER_DISPEOLN);
+ ret = FIELD_GET(SCALER_DISPEOLN_DSP4_MUX_MASK, reg);
+ if (ret == 3)
+ return -EPIPE;
- return ret;
+ return ret;
- case 5:
- reg = HVS_READ(SCALER_DISPDITHER);
- ret = FIELD_GET(SCALER_DISPDITHER_DSP5_MUX_MASK, reg);
- if (ret == 3)
- return -EPIPE;
+ case 5:
+ reg = HVS_READ(SCALER_DISPDITHER);
+ ret = FIELD_GET(SCALER_DISPDITHER_DSP5_MUX_MASK, reg);
+ if (ret == 3)
+ return -EPIPE;
- return ret;
+ return ret;
+
+ default:
+ return -EPIPE;
+ }
default:
return -EPIPE;
--
2.34.1
[PATCH v2 28/31] drm/vc4: hvs: Change prototype of __vc4_hvs_alloc to pass registers
From: Maxime Ripard
The BCM2712 HVS has registers to report the size of the various SRAM the
driver uses, and their size actually differ depending on the stepping.
The initialisation of the memory pools happen in the __vc4_hvs_alloc()
function that also allocates the main HVS structure, that will then hold
the pointer to the memory mapping of the registers.
This creates some kind of circular dependency that we can break by
passing the mapping pointer as an argument for __vc4_hvs_alloc() to use
to query to get the SRAM sizes and initialise the memory pools
accordingly.
Signed-off-by: Maxime Ripard
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/tests/vc4_mock.c | 2 +-
drivers/gpu/drm/vc4/vc4_drv.h| 4 +++-
drivers/gpu/drm/vc4/vc4_hvs.c| 16 ++--
3 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vc4/tests/vc4_mock.c
b/drivers/gpu/drm/vc4/tests/vc4_mock.c
index 922849dd4b47..6527fb1db71e 100644
--- a/drivers/gpu/drm/vc4/tests/vc4_mock.c
+++ b/drivers/gpu/drm/vc4/tests/vc4_mock.c
@@ -175,7 +175,7 @@ static struct vc4_dev *__mock_device(struct kunit *test,
enum vc4_gen gen)
vc4->dev = dev;
vc4->gen = gen;
- vc4->hvs = __vc4_hvs_alloc(vc4, NULL);
+ vc4->hvs = __vc4_hvs_alloc(vc4, NULL, NULL);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, vc4->hvs);
drm = &vc4->base;
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 559118824bf7..7a9faea748e6 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -1004,7 +1004,9 @@ void vc4_irq_reset(struct drm_device *dev);
/* vc4_hvs.c */
extern struct platform_driver vc4_hvs_driver;
-struct vc4_hvs *__vc4_hvs_alloc(struct vc4_dev *vc4, struct platform_device
*pdev);
+struct vc4_hvs *__vc4_hvs_alloc(struct vc4_dev *vc4,
+ void __iomem *regs,
+ struct platform_device *pdev);
void vc4_hvs_stop_channel(struct vc4_hvs *hvs, unsigned int output);
int vc4_hvs_get_fifo_from_output(struct vc4_hvs *hvs, unsigned int output);
u8 vc4_hvs_get_fifo_frame_count(struct vc4_hvs *hvs, unsigned int fifo);
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index 3f323a9d5e9a..fc147aff53c3 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -811,7 +811,9 @@ int vc4_hvs_debugfs_init(struct drm_minor *minor)
return 0;
}
-struct vc4_hvs *__vc4_hvs_alloc(struct vc4_dev *vc4, struct platform_device
*pdev)
+struct vc4_hvs *__vc4_hvs_alloc(struct vc4_dev *vc4,
+ void __iomem *regs,
+ struct platform_device *pdev)
{
struct drm_device *drm = &vc4->base;
struct vc4_hvs *hvs;
@@ -821,6 +823,7 @@ struct vc4_hvs *__vc4_hvs_alloc(struct vc4_dev *vc4, struct
platform_device *pde
return ERR_PTR(-ENOMEM);
hvs->vc4 = vc4;
+ hvs->regs = regs;
hvs->pdev = pdev;
spin_lock_init(&hvs->mm_lock);
@@ -1017,16 +1020,17 @@ static int vc4_hvs_bind(struct device *dev, struct
device *master, void *data)
struct drm_device *drm = dev_get_drvdata(master);
struct vc4_dev *vc4 = to_vc4_dev(drm);
struct vc4_hvs *hvs = NULL;
+ void __iomem *regs;
int ret;
- hvs = __vc4_hvs_alloc(vc4, NULL);
+ regs = vc4_ioremap_regs(pdev, 0);
+ if (IS_ERR(regs))
+ return PTR_ERR(regs);
+
+ hvs = __vc4_hvs_alloc(vc4, regs, pdev);
if (IS_ERR(hvs))
return PTR_ERR(hvs);
- hvs->regs = vc4_ioremap_regs(pdev, 0);
- if (IS_ERR(hvs->regs))
- return PTR_ERR(hvs->regs);
-
hvs->regset.base = hvs->regs;
hvs->regset.regs = vc4_hvs_regs;
hvs->regset.nregs = ARRAY_SIZE(vc4_hvs_regs);
--
2.34.1
[PATCH v2 27/31] drm/vc4: hvs: Rework LBM alignment
From: Maxime Ripard With the introduction of the support for BCM2712, the check of whether we're running on vc5 or not to compute the LBM alignment requirement doesn't work anymore. Moreover, the LBM size will need to be computed in words for the BCM2712, while we've had sizes in bytes so far. Aligning on either 64 or 32 words is thus fairly harmful on BCM2712, so let's just explicitly align the size when needed, and then call drm_mm_insert_node_generic() with an alignment of 1. Signed-off-by: Maxime Ripard Signed-off-by: Dave Stevenson --- drivers/gpu/drm/vc4/vc4_plane.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c index a4965226595d..4c61ef4f4142 100644 --- a/drivers/gpu/drm/vc4/vc4_plane.c +++ b/drivers/gpu/drm/vc4/vc4_plane.c @@ -756,6 +756,11 @@ static int vc4_plane_allocate_lbm(struct drm_plane_state *state) if (!lbm_size) return 0; + if (vc4->gen == VC4_GEN_5) + lbm_size = ALIGN(lbm_size, 64); + else if (vc4->gen == VC4_GEN_4) + lbm_size = ALIGN(lbm_size, 32); + drm_dbg_driver(drm, "[PLANE:%d:%s] LBM Allocation Size: %u\n", plane->base.id, plane->name, lbm_size); @@ -771,8 +776,7 @@ static int vc4_plane_allocate_lbm(struct drm_plane_state *state) spin_lock_irqsave(&vc4->hvs->mm_lock, irqflags); ret = drm_mm_insert_node_generic(&vc4->hvs->lbm_mm, &vc4_state->lbm, -lbm_size, -vc4->gen == VC4_GEN_5 ? 64 : 32, +lbm_size, 1, 0, 0); spin_unlock_irqrestore(&vc4->hvs->mm_lock, irqflags); -- 2.34.1
[PATCH v2 29/31] drm/vc4: plane: Move the buffer offset out of the vc4_plane_state
The offset fields in vc4_plane_state are described as being
the offset for each buffer in the bo, however it is used to
store the complete DMA address that is then written into the
register.
The DMA address including the fb ofset can be retrieved
using drm_fb_dma_get_gem_addr, and the offset adjustment due to
clipping is local to vc4_plane_mode_set.
Drop the offset field from the state, and compute the complete
DMA address in vc4_plane_mode_set.
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_drv.h | 5
drivers/gpu/drm/vc4/vc4_plane.c | 51 +
2 files changed, 20 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 7a9faea748e6..c6be1997f1c7 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -421,11 +421,6 @@ struct vc4_plane_state {
bool is_unity;
bool is_yuv;
- /* Offset to start scanning out from the start of the plane's
-* BO.
-*/
- u32 offsets[3];
-
/* Our allocation in LBM for temporary storage during scaling. */
struct drm_mm_node lbm;
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 4c61ef4f4142..ba6e86d62a77 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -450,12 +450,11 @@ static int vc4_plane_setup_clipping_and_scaling(struct
drm_plane_state *state)
{
struct vc4_plane_state *vc4_state = to_vc4_plane_state(state);
struct drm_framebuffer *fb = state->fb;
- struct drm_gem_dma_object *bo;
int num_planes = fb->format->num_planes;
struct drm_crtc_state *crtc_state;
u32 h_subsample = fb->format->hsub;
u32 v_subsample = fb->format->vsub;
- int i, ret;
+ int ret;
crtc_state = drm_atomic_get_existing_crtc_state(state->state,
state->crtc);
@@ -469,11 +468,6 @@ static int vc4_plane_setup_clipping_and_scaling(struct
drm_plane_state *state)
if (ret)
return ret;
- for (i = 0; i < num_planes; i++) {
- bo = drm_fb_dma_get_gem_obj(fb, i);
- vc4_state->offsets[i] = bo->dma_addr + fb->offsets[i];
- }
-
vc4_state->src_x = state->src.x1;
vc4_state->src_y = state->src.y1;
vc4_state->src_w[0] = state->src.x2 - vc4_state->src_x;
@@ -902,6 +896,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
u32 width, height;
u32 hvs_format = format->hvs;
unsigned int rotation;
+ u32 offsets[3] = { 0 };
int ret, i;
if (vc4_state->dlist_initialized)
@@ -949,13 +944,8 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
* out.
*/
for (i = 0; i < num_planes; i++) {
- vc4_state->offsets[i] += src_y /
-(i ? v_subsample : 1) *
-fb->pitches[i];
-
- vc4_state->offsets[i] += src_x /
-(i ? h_subsample : 1) *
-fb->format->cpp[i];
+ offsets[i] += src_y / (i ? v_subsample : 1) *
fb->pitches[i];
+ offsets[i] += src_x / (i ? h_subsample : 1) *
fb->format->cpp[i];
}
break;
@@ -1010,19 +1000,18 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
VC4_SET_FIELD(y_off, SCALER_PITCH0_TILE_Y_OFFSET) |
VC4_SET_FIELD(tiles_l, SCALER_PITCH0_TILE_WIDTH_L) |
VC4_SET_FIELD(tiles_r, SCALER_PITCH0_TILE_WIDTH_R));
- vc4_state->offsets[0] += tiles_t * (tiles_w << tile_size_shift);
- vc4_state->offsets[0] += subtile_y << 8;
- vc4_state->offsets[0] += utile_y << 4;
+ offsets[0] += tiles_t * (tiles_w << tile_size_shift);
+ offsets[0] += subtile_y << 8;
+ offsets[0] += utile_y << 4;
/* Rows of tiles alternate left-to-right and right-to-left. */
if (tiles_t & 1) {
pitch0 |= SCALER_PITCH0_TILE_INITIAL_LINE_DIR;
- vc4_state->offsets[0] += (tiles_w - tiles_l) <<
-tile_size_shift;
- vc4_state->offsets[0] -= (1 + !tile_y) << 10;
+ offsets[0] += (tiles_w - tiles_l) << tile_size_shift;
+ offsets[0] -= (1 + !tile_y) << 10;
} else {
- vc4_state->offsets[0] += tiles_l << tile_size_shift;
- vc4_state->offsets[0] += tile_y << 10;
+ offsets[0] += tiles_l << tile_size_shift;
+ offsets[0] += tile_y << 10;
[PATCH v2 19/31] drm/vc4: hvs: Remove ABORT_ON_EMPTY flag
From: Dom Cobley
ABORT_ON_EMPTY chooses whether the HVS abandons the current frame
when it experiences an underflow, or attempts to continue.
In theory the frame should be black from the point of underflow,
compared to a shift of sebsequent pixels to the left.
Unfortunately it seems to put the HVS is a bad state where it is not
possible to recover simply. This typically requires a reboot
following the 'flip done timed out message'.
Discussion with Broadcom has suggested we don't use this flag.
All their testing is done with it disabled.
Additionally setting BLANK_INSERT_EN causes the HDMI to output
blank pixels on an underflow which avoids it losing sync.
After this change a 'flip done timed out' due to sdram bandwidth
starvation or too low a clock is recoverable once the situation improves.
Signed-off-by: Dom Cobley
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 1 +
drivers/gpu/drm/vc4/vc4_regs.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 680e40a688a5..fa1f94e29871 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -1592,6 +1592,7 @@ static void vc4_hdmi_encoder_post_crtc_enable(struct
drm_encoder *encoder,
VC4_HD_VID_CTL_CLRRGB |
VC4_HD_VID_CTL_UNDERFLOW_ENABLE |
VC4_HD_VID_CTL_FRAME_COUNTER_RESET |
+ VC4_HD_VID_CTL_BLANK_INSERT_EN |
(vsync_pos ? 0 : VC4_HD_VID_CTL_VSYNC_LOW) |
(hsync_pos ? 0 : VC4_HD_VID_CTL_HSYNC_LOW));
diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_regs.h
index 8ac9515554f8..c55dec383929 100644
--- a/drivers/gpu/drm/vc4/vc4_regs.h
+++ b/drivers/gpu/drm/vc4/vc4_regs.h
@@ -777,6 +777,7 @@ enum {
# define VC4_HD_VID_CTL_CLRSYNCBIT(24)
# define VC4_HD_VID_CTL_CLRRGB BIT(23)
# define VC4_HD_VID_CTL_BLANKPIX BIT(18)
+# define VC4_HD_VID_CTL_BLANK_INSERT_ENBIT(16)
# define VC4_HD_CSC_CTL_ORDER_MASK VC4_MASK(7, 5)
# define VC4_HD_CSC_CTL_ORDER_SHIFT5
--
2.34.1
[PATCH v2 25/31] drm/vc4: hvs: Rename hvs_regs list
From: Maxime Ripard
The HVS register set has been heavily modified in the BCM2712, and we'll
thus need a separate debugfs_reg32 array for it.
The name hvs_regs is thus a bit too generic, so let's rename it to
something more specific.
Signed-off-by: Maxime Ripard
Signed-off-by: Dave Stevenson
---
drivers/gpu/drm/vc4/vc4_hvs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index bd9ae25dbdcf..3f323a9d5e9a 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -33,7 +33,7 @@
#include "vc4_drv.h"
#include "vc4_regs.h"
-static const struct debugfs_reg32 hvs_regs[] = {
+static const struct debugfs_reg32 vc4_hvs_regs[] = {
VC4_REG32(SCALER_DISPCTRL),
VC4_REG32(SCALER_DISPSTAT),
VC4_REG32(SCALER_DISPID),
@@ -1028,8 +1028,8 @@ static int vc4_hvs_bind(struct device *dev, struct device
*master, void *data)
return PTR_ERR(hvs->regs);
hvs->regset.base = hvs->regs;
- hvs->regset.regs = hvs_regs;
- hvs->regset.nregs = ARRAY_SIZE(hvs_regs);
+ hvs->regset.regs = vc4_hvs_regs;
+ hvs->regset.nregs = ARRAY_SIZE(vc4_hvs_regs);
if (vc4->gen == VC4_GEN_5) {
struct rpi_firmware *firmware;
--
2.34.1
[PATCH v2 30/31] drm/vc4: hvs: Enable SCALER_CONTROL early in HVS init
From: Tim Gover Always enable SCALER_CONTROL before attempting other HVS operations. It's safe to write to some parts of the HVS but in general it's dangerous to do this because it can cause bus lockups. Signed-off-by: Tim Gover Signed-off-by: Dave Stevenson --- drivers/gpu/drm/vc4/vc4_hvs.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c index fc147aff53c3..be2173f6c58e 100644 --- a/drivers/gpu/drm/vc4/vc4_hvs.c +++ b/drivers/gpu/drm/vc4/vc4_hvs.c @@ -860,6 +860,10 @@ static int vc4_hvs_hw_init(struct vc4_hvs *hvs) struct vc4_dev *vc4 = hvs->vc4; u32 dispctrl, reg; + dispctrl = HVS_READ(SCALER_DISPCTRL); + dispctrl |= SCALER_DISPCTRL_ENABLE; + HVS_WRITE(SCALER_DISPCTRL, dispctrl); + reg = HVS_READ(SCALER_DISPECTRL); reg &= ~SCALER_DISPECTRL_DSP2_MUX_MASK; HVS_WRITE(SCALER_DISPECTRL, @@ -881,8 +885,6 @@ static int vc4_hvs_hw_init(struct vc4_hvs *hvs) reg | VC4_SET_FIELD(3, SCALER_DISPDITHER_DSP5_MUX)); dispctrl = HVS_READ(SCALER_DISPCTRL); - - dispctrl |= SCALER_DISPCTRL_ENABLE; dispctrl |= SCALER_DISPCTRL_DISPEIRQ(0) | SCALER_DISPCTRL_DISPEIRQ(1) | SCALER_DISPCTRL_DISPEIRQ(2); @@ -1078,6 +1080,10 @@ static int vc4_hvs_bind(struct device *dev, struct device *master, void *data) else hvs->dlist = hvs->regs + SCALER5_DLIST_START; + ret = vc4_hvs_hw_init(hvs); + if (ret) + return ret; + /* Upload filter kernels. We only have the one for now, so we * keep it around for the lifetime of the driver. */ @@ -1087,10 +1093,6 @@ static int vc4_hvs_bind(struct device *dev, struct device *master, void *data) if (ret) return ret; - ret = vc4_hvs_hw_init(hvs); - if (ret) - return ret; - ret = vc4_hvs_cob_init(hvs); if (ret) return ret; -- 2.34.1
