Re: [PATCH] drm/vgem: Restore mmap functionality
Hi
Am 09.07.21 um 16:43 schrieb Daniel Vetter:
On Fri, Jul 9, 2021 at 1:47 PM Thomas Zimmermann wrote:
Commit 375cca1cfeb5 ("drm/vgem: Implement mmap as GEM object function")
accidentally removed the actual mmap functionality from vgem. Restore
the original implementation and VMA flags.
Ah yes that explains things.
Reviewed-by: Daniel Vetter
Apparently, this fix fails a number of other tests. [1] Can we revert
the original patch for now? I'd like to have time to investigate.
Best regards
Thomas
[1]
https://lore.kernel.org/intel-gfx/20210709154256.12005-1-tzimmerm...@suse.de/T/#maa12be2a6d4b6a4ed8cb05e98f00b8955638c518
Fixes access to unmapped memory:
[ 106.591744] BUG: KASAN: vmalloc-out-of-bounds in do_fault+0x38/0x480
[ 106.598154] Read of size 8 at addr c10c44a8 by task vgem_basic/1514
[ 106.605173]
[ 106.606678] CPU: 1 PID: 1514 Comm: vgem_basic Tainted: GE
5.13.0-1-default+ #990
[ 106.615535] Hardware name: Dell Inc. OptiPlex 9020/0N4YC8, BIOS A24
10/24/2018
[ 106.622818] Call Trace:
[ 106.625289] dump_stack+0xa5/0xdc
[ 106.628642] print_address_description.constprop.0+0x18/0x100
[ 106.634439] ? do_fault+0x38/0x480
[ 106.637872] kasan_report.cold+0x7c/0xd8
[ 106.641834] ? do_fault+0x38/0x480
[ 106.645274] do_fault+0x38/0x480
[ 106.648535] __handle_mm_fault+0x935/0xb00
[ 106.652676] ? vm_iomap_memory+0xe0/0xe0
[ 106.656634] ? __lock_release+0x12f/0x4e0
[ 106.660696] ? count_memcg_event_mm.part.0+0xb9/0x190
[ 106.665799] handle_mm_fault+0xd0/0x370
[ 106.669675] do_user_addr_fault+0x2a0/0x8c0
[ 106.673908] exc_page_fault+0x64/0xf0
[ 106.677604] ? asm_exc_page_fault+0x8/0x30
[ 106.681739] asm_exc_page_fault+0x1e/0x30
[ 106.685782] RIP: 0033:0x402e12
...
Signed-off-by: Thomas Zimmermann
Fixes: 375cca1cfeb5 ("drm/vgem: Implement mmap as GEM object function")
Cc: Thomas Zimmermann
Cc: Christian König
Cc: Daniel Vetter
Cc: "Christian König"
Cc: Melissa Wen
Cc: Jason Gunthorpe
Cc: Gerd Hoffmann
Cc: Lee Jones
---
drivers/gpu/drm/vgem/vgem_drv.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index df634aa52638..f50fd10c4fad 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -364,8 +364,17 @@ static void vgem_prime_vunmap(struct drm_gem_object *obj,
struct dma_buf_map *ma
static int vgem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct
*vma)
{
+ int ret;
+
+ if (!obj->filp)
+ return -ENODEV;
+
+ ret = call_mmap(obj->filp, vma);
+ if (ret)
+ return ret;
+
vma_set_file(vma, obj->filp);
- vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
+ vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
vma->vm_page_prot =
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
--
2.32.0
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v4] drm/i915: Invoke another _DSM to enable MUX on HP Workstation laptops
On Thu, May 20, 2021 at 02:58:20PM +0800, Kai-Heng Feng wrote:
> On HP Fury G7 Workstations, graphics output is re-routed from Intel GFX
> to discrete GFX after S3. This is not desirable, because userspace will
> treat connected display as a new one, losing display settings.
>
> The expected behavior is to let discrete GFX drives all external
> displays.
>
> The platform in question uses ACPI method \_SB.PCI0.HGME to enable MUX.
> The method is inside the another _DSM, so add the _DSM and call it
> accordingly.
>
> I also tested some MUX-less and iGPU only laptops with that _DSM, no
> regression was found.
>
> v4:
> - Rebase.
> - Change the DSM name to avoid confusion.
> - Move the function call to intel_opregion.
>
> v3:
> - Remove BXT from names.
> - Change the parameter type.
> - Fold the function into intel_modeset_init_hw().
>
> v2:
> - Forward declare struct pci_dev.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3113
> References:
> https://lore.kernel.org/intel-gfx/1460040732-31417-4-git-send-email-animesh.ma...@intel.com/
> Signed-off-by: Kai-Heng Feng
Thanks. Pushed to drm-intel-next. And sorry for the lag.
> ---
> drivers/gpu/drm/i915/display/intel_acpi.c | 19 +++
> drivers/gpu/drm/i915/display/intel_acpi.h | 3 +++
> drivers/gpu/drm/i915/display/intel_opregion.c | 3 +++
> 3 files changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
> b/drivers/gpu/drm/i915/display/intel_acpi.c
> index 833d0c1be4f1..7cfe91fc05f2 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> @@ -19,6 +19,12 @@ static const guid_t intel_dsm_guid =
> GUID_INIT(0x7ed873d3, 0xc2d0, 0x4e4f,
> 0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c);
>
> +#define INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED 0 /* No args */
> +
> +static const guid_t intel_dsm_guid2 =
> + GUID_INIT(0x3e5b41c6, 0xeb1d, 0x4260,
> + 0x9d, 0x15, 0xc7, 0x1f, 0xba, 0xda, 0xe4, 0x14);
> +
> static char *intel_dsm_port_name(u8 id)
> {
> switch (id) {
> @@ -176,6 +182,19 @@ void intel_unregister_dsm_handler(void)
> {
> }
>
> +void intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915)
> +{
> + struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> + acpi_handle dhandle;
> +
> + dhandle = ACPI_HANDLE(&pdev->dev);
> + if (!dhandle)
> + return;
> +
> + acpi_evaluate_dsm(dhandle, &intel_dsm_guid2, INTEL_DSM_REVISION_ID,
> + INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED, NULL);
> +}
> +
> /*
> * ACPI Specification, Revision 5.0, Appendix B.3.2 _DOD (Enumerate All
> Devices
> * Attached to the Display Adapter).
> diff --git a/drivers/gpu/drm/i915/display/intel_acpi.h
> b/drivers/gpu/drm/i915/display/intel_acpi.h
> index e8b068661d22..9f197401c313 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.h
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.h
> @@ -11,11 +11,14 @@ struct drm_i915_private;
> #ifdef CONFIG_ACPI
> void intel_register_dsm_handler(void);
> void intel_unregister_dsm_handler(void);
> +void intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915);
> void intel_acpi_device_id_update(struct drm_i915_private *i915);
> #else
> static inline void intel_register_dsm_handler(void) { return; }
> static inline void intel_unregister_dsm_handler(void) { return; }
> static inline
> +void intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915)
> { return; }
> +static inline
> void intel_acpi_device_id_update(struct drm_i915_private *i915) { return; }
> #endif /* CONFIG_ACPI */
>
> diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c
> b/drivers/gpu/drm/i915/display/intel_opregion.c
> index dfd724e506b5..3855fba70980 100644
> --- a/drivers/gpu/drm/i915/display/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/display/intel_opregion.c
> @@ -1078,6 +1078,9 @@ void intel_opregion_resume(struct drm_i915_private
> *i915)
> opregion->asle->ardy = ASLE_ARDY_READY;
> }
>
> + /* Some platforms abuse the _DSM to enable MUX */
> + intel_dsm_get_bios_data_funcs_supported(i915);
> +
> intel_opregion_notify_adapter(i915, PCI_D0);
> }
>
> --
> 2.31.1
--
Ville Syrjälä
Intel
[PATCH 5.13 407/800] drm/i915: Merge fix for "drm: Switch to %p4cc format modifier"
From: Stephen Rothwell
[ Upstream commit e3c2f1870af43fc95f6fe141537f5142c5fe4717 ]
Signed-off-by: Stephen Rothwell
Signed-off-by: Thomas Zimmermann
Fixes: 92f1d09ca4ed ("drm: Switch to %p4cc format modifier")
Cc: Sakari Ailus
Cc: Petr Mladek
Cc: Andy Shevchenko
Cc: dri-devel@lists.freedesktop.org
Link:
https://lore.kernel.org/dri-devel/20210514115307.4364a...@canb.auug.org.au/T/#macc61d4e0b17ca0da2b26aae8fbbcbf47324da13
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/display/skl_universal_plane.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 7ffd7b570b54..538682f882b1 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -1082,7 +1082,6 @@ static int skl_plane_check_fb(const struct
intel_crtc_state *crtc_state,
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
const struct drm_framebuffer *fb = plane_state->hw.fb;
unsigned int rotation = plane_state->hw.rotation;
- struct drm_format_name_buf format_name;
if (!fb)
return 0;
@@ -1130,9 +1129,8 @@ static int skl_plane_check_fb(const struct
intel_crtc_state *crtc_state,
case DRM_FORMAT_XVYU12_16161616:
case DRM_FORMAT_XVYU16161616:
drm_dbg_kms(&dev_priv->drm,
- "Unsupported pixel format %s for 90/270!\n",
- drm_get_format_name(fb->format->format,
- &format_name));
+ "Unsupported pixel format %p4cc for
90/270!\n",
+ &fb->format->format);
return -EINVAL;
default:
break;
--
2.30.2
Re: [PATCH 1/2] drm: add crtc background color property
On Fri, 9 Jul 2021 18:23:26 +0200
Raphael Gallais-Pou wrote:
> On 7/9/21 10:04 AM, Pekka Paalanen wrote:
> > On Wed, 7 Jul 2021 08:48:47 +
> > Raphael GALLAIS-POU - foss wrote:
> >
> >> Some display controllers can be programmed to present non-black colors
> >> for pixels not covered by any plane (or pixels covered by the
> >> transparent regions of higher planes). Compositors that want a UI with
> >> a solid color background can potentially save memory bandwidth by
> >> setting the CRTC background property and using smaller planes to display
> >> the rest of the content.
> >>
> >> To avoid confusion between different ways of encoding RGB data, we
> >> define a standard 64-bit format that should be used for this property's
> >> value. Helper functions and macros are provided to generate and dissect
> >> values in this standard format with varying component precision values.
> >>
> >> Signed-off-by: Raphael Gallais-Pou
> >> Signed-off-by: Matt Roper
> >> ---
> >> drivers/gpu/drm/drm_atomic_state_helper.c | 1 +
> >> drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
> >> drivers/gpu/drm/drm_blend.c | 34 +--
> >> drivers/gpu/drm/drm_mode_config.c | 6
> >> include/drm/drm_blend.h | 1 +
> >> include/drm/drm_crtc.h| 12
> >> include/drm/drm_mode_config.h | 5
> >> include/uapi/drm/drm_mode.h | 28 +++
> >> 8 files changed, 89 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> >> b/drivers/gpu/drm/drm_atomic_state_helper.c
> >> index ddcf5c2c8e6a..1b95a4ecdb2b 100644
> >> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> >> @@ -72,6 +72,7 @@ __drm_atomic_helper_crtc_state_reset(struct
> >> drm_crtc_state *crtc_state,
> >> struct drm_crtc *crtc)
> >> {
> >>crtc_state->crtc = crtc;
> >> + crtc_state->bgcolor = drm_argb(16, 0x, 0, 0, 0);
> >> }
> >> EXPORT_SYMBOL(__drm_atomic_helper_crtc_state_reset);
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> >> b/drivers/gpu/drm/drm_atomic_uapi.c
> >> index 438e9585b225..fea68f8f17f8 100644
> >> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> >> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> >> @@ -483,6 +483,8 @@ static int drm_atomic_crtc_set_property(struct
> >> drm_crtc *crtc,
> >>set_out_fence_for_crtc(state->state, crtc, fence_ptr);
> >>} else if (property == crtc->scaling_filter_property) {
> >>state->scaling_filter = val;
> >> + } else if (property == config->bgcolor_property) {
> >> + state->bgcolor = val;
> >>} else if (crtc->funcs->atomic_set_property) {
> >>return crtc->funcs->atomic_set_property(crtc, state, property,
> >> val);
> >>} else {
> >> @@ -520,6 +522,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> >>*val = 0;
> >>else if (property == crtc->scaling_filter_property)
> >>*val = state->scaling_filter;
> >> + else if (property == config->bgcolor_property)
> >> + *val = state->bgcolor;
> >>else if (crtc->funcs->atomic_get_property)
> >>return crtc->funcs->atomic_get_property(crtc, state, property,
> >> val);
> >>else
> >> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> >> index ec37cbfabb50..6692d6a6db22 100644
> >> --- a/drivers/gpu/drm/drm_blend.c
> >> +++ b/drivers/gpu/drm/drm_blend.c
> >> @@ -186,8 +186,7 @@
> >>*assumed to be 1.0
> >>*
> >>* Note that all the property extensions described here apply either to
> >> the
> >> - * plane or the CRTC (e.g. for the background color, which currently is
> >> not
> >> - * exposed and assumed to be black).
> >> + * plane or the CRTC.
> >>*
> >>* SCALING_FILTER:
> >>* Indicates scaling filter to be used for plane scaler
> >> @@ -201,6 +200,21 @@
> >>*
> >>* Drivers can set up this property for a plane by calling
> >>* drm_plane_create_scaling_filter_property
> >> + *
> > Hi,
>
>
> Hi Pekka,
>
>
> Many thanks for your feedback, your comments are taken into account for
> a v2.
>
>
> >
> > I assume the below block is the UAPI documentation of this new property
> > and that it would appear with the other UAPI docs.
> >
> >> + * BACKGROUND_COLOR:
> >> + *Defines the ARGB color of a full-screen layer that exists below
> >> all
> >> + *planes. This color will be used for pixels not covered by any
> >> plane
> >> + *and may also be blended with plane contents as allowed by a
> >> plane's
> >> + *alpha values. The background color defaults to black, and is
> >> assumed
> >> + *to be black for drivers that do not expose this property.
> > All good up to here.
> >
> >> Although
> >> + *background color isn't a plane, it is ass
Aw: Re: Re: Re: BUG: MTK DRM/HDMI broken on 5.13 (mt7623/bpi-r2)
Hi, HDMI is broken again in 5.14-rc1 (of course i have applied my patch [1]) now i've got a NULL pointer dereference [ 21.883641] PC is at mtk_dpi_bridge_atomic_check+0x38/0x78 [ 21.889158] LR is at drm_atomic_bridge_chain_check+0x150/0x30c "dpi" is not set correctly in mtk_dpi_bridge_atomic_check this function is new since commit ec8747c52434b69cea2b18068e72f051e23d3839 drm/mediatek: dpi: Add bus format negotiation i do not see where bridge->driver_private is set, but in other function it is solved like this: bridge_to_dpi(bridge) this fixes the NULL-pointer dereference, and system starts to xserver, but i do not see fbcon...it looks like drm is now initialized later (~ at login prompt on serial console). i stopped lightdm and still do not see loginprompt on hdmi, so it looks like fbcon is broken send out fix for NULL issue, but fbcon ist still unclear...but i see this in dmesg: dmesg | grep -i fbcon [0.00] Kernel command line: root=/dev/mmcblk0p2 rw rootwait earlyprintk console=ttyS0,115200 video=1280x1024 console=tty1 fbcon=map:0 [0.00] Unknown command line parameters: fbcon=map:0 [7.040167] fbcon=map:0 and no framebuffer/fb0 in dmesg regards Frank [1] https://patchwork.kernel.org/project/linux-mediatek/patch/20210710132431.265985-1-li...@fw-web.de/
[PATCH 1/1] fbmem: Do not delete the mode that is still in use
The execution of fb_delete_videomode() is not based on the result of the
previous fbcon_mode_deleted(). As a result, the mode is directly deleted,
regardless of whether it is still in use, which may cause UAF.
==
BUG: KASAN: use-after-free in fb_mode_is_equal+0x36e/0x5e0 \
drivers/video/fbdev/core/modedb.c:924
Read of size 4 at addr 88807e0ddb1c by task syz-executor.0/18962
CPU: 2 PID: 18962 Comm: syz-executor.0 Not tainted 5.10.45-rc1+ #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ...
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x137/0x1be lib/dump_stack.c:118
print_address_description+0x6c/0x640 mm/kasan/report.c:385
__kasan_report mm/kasan/report.c:545 [inline]
kasan_report+0x13d/0x1e0 mm/kasan/report.c:562
fb_mode_is_equal+0x36e/0x5e0 drivers/video/fbdev/core/modedb.c:924
fbcon_mode_deleted+0x16a/0x220 drivers/video/fbdev/core/fbcon.c:2746
fb_set_var+0x1e1/0xdb0 drivers/video/fbdev/core/fbmem.c:975
do_fb_ioctl+0x4d9/0x6e0 drivers/video/fbdev/core/fbmem.c:1108
vfs_ioctl fs/ioctl.c:48 [inline]
__do_sys_ioctl fs/ioctl.c:753 [inline]
__se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Freed by task 18960:
kasan_save_stack mm/kasan/common.c:48 [inline]
kasan_set_track+0x3d/0x70 mm/kasan/common.c:56
kasan_set_free_info+0x17/0x30 mm/kasan/generic.c:355
__kasan_slab_free+0x108/0x140 mm/kasan/common.c:422
slab_free_hook mm/slub.c:1541 [inline]
slab_free_freelist_hook+0xd6/0x1a0 mm/slub.c:1574
slab_free mm/slub.c:3139 [inline]
kfree+0xca/0x3d0 mm/slub.c:4121
fb_delete_videomode+0x56a/0x820 drivers/video/fbdev/core/modedb.c:1104
fb_set_var+0x1f3/0xdb0 drivers/video/fbdev/core/fbmem.c:978
do_fb_ioctl+0x4d9/0x6e0 drivers/video/fbdev/core/fbmem.c:1108
vfs_ioctl fs/ioctl.c:48 [inline]
__do_sys_ioctl fs/ioctl.c:753 [inline]
__se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes: 13ff178ccd6d ("fbcon: Call fbcon_mode_deleted/new_modelist directly")
Signed-off-by: Zhen Lei
---
drivers/video/fbdev/core/fbmem.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 98f193078c05..1c855145711b 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -970,13 +970,11 @@ fb_set_var(struct fb_info *info, struct fb_var_screeninfo
*var)
fb_var_to_videomode(&mode2, &info->var);
/* make sure we don't delete the videomode of current var */
ret = fb_mode_is_equal(&mode1, &mode2);
-
- if (!ret)
- fbcon_mode_deleted(info, &mode1);
-
- if (!ret)
- fb_delete_videomode(&mode1, &info->modelist);
-
+ if (!ret) {
+ ret = fbcon_mode_deleted(info, &mode1);
+ if (!ret)
+ fb_delete_videomode(&mode1, &info->modelist);
+ }
return ret ? -EINVAL : 0;
}
--
2.25.1
Re: [PATCH] drm/bridge: dw-mipi-dsi: Find the possible DSI devices
Reviewed-by: Robert Foss
Re: [PATCH v3 07/20] drm/panfrost: use scheduler dependency tracking
On 08/07/2021 18:37, Daniel Vetter wrote:
> Just deletes some code that's now more shared.
>
> Note that thanks to the split into drm_sched_job_init/arm we can now
> easily pull the _init() part from under the submission lock way ahead
> where we're adding the sync file in-fences as dependencies.
>
> v2: Correctly clean up the partially set up job, now that job_init()
> and job_arm() are apart (Emma).
>
> Reviewed-by: Steven Price (v1)
v2/v3 are also:
Reviewed-by: Steven Price
Thanks,
Steve
> Signed-off-by: Daniel Vetter
> Cc: Rob Herring
> Cc: Tomeu Vizoso
> Cc: Steven Price
> Cc: Alyssa Rosenzweig
> Cc: Sumit Semwal
> Cc: "Christian König"
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 16 ---
> drivers/gpu/drm/panfrost/panfrost_job.c | 37 +++--
> drivers/gpu/drm/panfrost/panfrost_job.h | 5 +---
> 3 files changed, 17 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index 1ffaef5ec5ff..9f53bea07d61 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -218,7 +218,7 @@ panfrost_copy_in_sync(struct drm_device *dev,
> if (ret)
> goto fail;
>
> - ret = drm_gem_fence_array_add(&job->deps, fence);
> + ret = drm_sched_job_await_fence(&job->base, fence);
>
> if (ret)
> goto fail;
> @@ -236,7 +236,7 @@ static int panfrost_ioctl_submit(struct drm_device *dev,
> void *data,
> struct drm_panfrost_submit *args = data;
> struct drm_syncobj *sync_out = NULL;
> struct panfrost_job *job;
> - int ret = 0;
> + int ret = 0, slot;
>
> if (!args->jc)
> return -EINVAL;
> @@ -258,14 +258,20 @@ static int panfrost_ioctl_submit(struct drm_device
> *dev, void *data,
>
> kref_init(&job->refcount);
>
> - xa_init_flags(&job->deps, XA_FLAGS_ALLOC);
> -
> job->pfdev = pfdev;
> job->jc = args->jc;
> job->requirements = args->requirements;
> job->flush_id = panfrost_gpu_get_latest_flush_id(pfdev);
> job->file_priv = file->driver_priv;
>
> + slot = panfrost_job_get_slot(job);
> +
> + ret = drm_sched_job_init(&job->base,
> + &job->file_priv->sched_entity[slot],
> + NULL);
> + if (ret)
> + goto fail_job_put;
> +
> ret = panfrost_copy_in_sync(dev, file, args, job);
> if (ret)
> goto fail_job;
> @@ -283,6 +289,8 @@ static int panfrost_ioctl_submit(struct drm_device *dev,
> void *data,
> drm_syncobj_replace_fence(sync_out, job->render_done_fence);
>
> fail_job:
> + drm_sched_job_cleanup(&job->base);
> +fail_job_put:
> panfrost_job_put(job);
> fail_out_sync:
> if (sync_out)
> diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
> b/drivers/gpu/drm/panfrost/panfrost_job.c
> index 4bc962763e1f..86c843d8822e 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_job.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_job.c
> @@ -102,7 +102,7 @@ static struct dma_fence *panfrost_fence_create(struct
> panfrost_device *pfdev, in
> return &fence->base;
> }
>
> -static int panfrost_job_get_slot(struct panfrost_job *job)
> +int panfrost_job_get_slot(struct panfrost_job *job)
> {
> /* JS0: fragment jobs.
>* JS1: vertex/tiler jobs
> @@ -242,13 +242,13 @@ static void panfrost_job_hw_submit(struct panfrost_job
> *job, int js)
>
> static int panfrost_acquire_object_fences(struct drm_gem_object **bos,
> int bo_count,
> - struct xarray *deps)
> + struct drm_sched_job *job)
> {
> int i, ret;
>
> for (i = 0; i < bo_count; i++) {
> /* panfrost always uses write mode in its current uapi */
> - ret = drm_gem_fence_array_add_implicit(deps, bos[i], true);
> + ret = drm_sched_job_await_implicit(job, bos[i], true);
> if (ret)
> return ret;
> }
> @@ -269,31 +269,21 @@ static void panfrost_attach_object_fences(struct
> drm_gem_object **bos,
> int panfrost_job_push(struct panfrost_job *job)
> {
> struct panfrost_device *pfdev = job->pfdev;
> - int slot = panfrost_job_get_slot(job);
> - struct drm_sched_entity *entity = &job->file_priv->sched_entity[slot];
> struct ww_acquire_ctx acquire_ctx;
> int ret = 0;
>
> -
> ret = drm_gem_lock_reservations(job->bos, job->bo_count,
> &acquire_ctx);
> if (ret)
> return ret;
>
> mutex_lock(&pfdev->sched_lock);
> -
> - ret = drm_sched_job_init(&job->base, entity, NULL);
> - if (ret) {
> - mutex_unlo
Re: [PATCH 2/2] drm/ttm: Fix COW check
Am 10.07.21 um 02:29 schrieb Felix Kuehling:
On 2021-07-09 3:37 p.m., Christian König wrote:
Am 09.07.21 um 21:31 schrieb Felix Kuehling:
On 2021-07-09 2:38 a.m., Christian König wrote:
Am 08.07.21 um 21:36 schrieb Alex Deucher:
From: Felix Kuehling
KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
is_cow_mapping returns true for these mappings. Add a check for
vm_flags & VM_WRITE to avoid mmap failures on private read-only or
PROT_NONE mappings.
I'm pretty sure that this is not working as expected.
Not sure what you mean. Debugger access to the memory through the
PROT_NONE VMAs is definitely working, with both ptrace and
/proc//mem.
Fixes: f91142c62161 ("drm/ttm: nuke VM_MIXEDMAP on BO mappings v3")
Signed-off-by: Felix Kuehling
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index f56be5bc0861..a75e90c7d4aa 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -552,7 +552,7 @@ static const struct vm_operations_struct
ttm_bo_vm_ops = {
int ttm_bo_mmap_obj(struct vm_area_struct *vma, struct
ttm_buffer_object *bo)
{
/* Enforce no COW since would have really strange behavior
with it. */
- if (is_cow_mapping(vma->vm_flags))
+ if (is_cow_mapping(vma->vm_flags) && (vma->vm_flags & VM_WRITE))
is_cow_mapping() already checks for VM_MAYWRITE, so this here
shouldn't be necessary.
AFAICT, VM_MAYWRITE is not based on the PROT_... bits used to create
the VMA, but based on the permissions of the file. So as long as the
render node is writable, VM_MAYWRITE is set for all VMAs that map it.
I would agree that it's probably a bad idea for the Thunk to map
these VMAs with MAP_PRIVATE. We can try changing the Thunk to use
MAP_SHARED for these PROT_NONE mappings. But that doesn't change the
fact that this kernel patch broke existing usermode.
For the record, changing the Thunk to use MAP_SHARED works.
Yeah, but see the discussion around MAP_PRIVATE and COW regarding
this. What Thunk did here was a really bad idea.
Hindsight ... Which part was a bad idea?
* Creating a PROT_NONE VMA? That's necessary to let ptrace or
/proc//mem access the memory. It's a brilliant idea, IMHO
* Making that VMA MAP_PRIVATE? Probably a bad idea in hindsight. The
process itself can't access this memory, let alone write to it. So I
didn't think too much about whether to make it shared or private.
Either way, we are not causing any actual COW on these mappings
because they are not writable, and we never make them writable with
mprotect either
* Introducing a COW check after letting it slide for 15 years? It's a
reasonable check. In this case it catches a false positive. Had this
check been in place 4 or 5 years ago, it would have easily prevented
this mess
A combination of everything.
MAP_PRIVATE would have previously caused very odd behavior and/or a
BUG_ON()/WARN_ON() in the VMA code (depending on platform).
MAP_PRIVATE + PROT_NONE kind of worked because it never faulted a page
so we never actually triggered a COW.
I think we have only two options here:
1. Accept the breakage of thunk.
Really?
Only as last resort, I'm running out of ideas how to fix this cleanly.
2. Add a workaround in amdgpu/amdkfd to force MAP_PRIVATE into
MAP_SHARED in the kernel.
I tried to do this in amdgpu_gem_object_mmap and spent 4 hours
debugging why it doesn't work. It breaks because the
mapping->i_mmap_writable gets unbalanced and causes subsequent
mappings to fail when that atomic counter becomes negative (indicating
DENYWRITE). I could fix it by calling mapping_map_writable. But I
don't think this is intended as driver API. I see no precedent of any
driver calling this. For the record this works, but it feels fragile
and ugly:
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -255,6 +255,20 @@ static int amdgpu_gem_object_mmap(struct
drm_gem_object *obj, struct vm_area_str
if (bo->flags & AMDGPU_GEM_CREATE_NO_CPU_ACCESS)
return -EPERM;
+ /* Workaround for Thunk bug creating PROT_NONE,MAP_PRIVATE mappings
+ * for debugger access to invisible VRAM. Should have used
MAP_SHARED
+ * instead.
+ */
+ if (is_cow_mapping(vma->vm_flags) &&
+ !(vma->vm_flags & (VM_READ | VM_WRITE | VM_EXEC))) {
+ int ret;
+
+ ret = mapping_map_writable(vma->vm_file->f_mapping);
+ if (ret)
+ return ret;
+ vma->vm_flags |= VM_SHARED | VM_MAYSHARE;
+ }
+
Yeah, I'm on another thread where we are discussing
mapping_map_writable() for vma_set_file() as well.
return drm_gem_ttm_mmap(obj, vma);
}
3. Improve my previous workaround by adding a similar check for COW in
ttm_bo_vm_ops.mprotect. I'll send an updated patch.
That has it's own issues,
Re: [PATCH 1/1] drm/ttm: Fix COW check
Am 10.07.21 um 02:28 schrieb Felix Kuehling:
KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
is_cow_mapping returns true for these mappings. Add a check for
vm_flags & VM_WRITE to avoid mmap failures on private read-only or
PROT_NONE mappings.
v2: protect against mprotect making a mapping writable after the fact
Fixes: f91142c62161 ("drm/ttm: nuke VM_MIXEDMAP on BO mappings v3")
Signed-off-by: Felix Kuehling
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index f56be5bc0861..9ad211ede611 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -542,17 +542,28 @@ int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned
long addr,
}
EXPORT_SYMBOL(ttm_bo_vm_access);
+static int ttm_bo_vm_mprotect(struct vm_area_struct *vma, unsigned long start,
+ unsigned long end, unsigned long newflags)
+{
+ /* Enforce no COW since would have really strange behavior with it. */
+ if (is_cow_mapping(newflags) && (newflags & VM_WRITE))
+ return -EINVAL;
+
+ return 0;
+}
+
static const struct vm_operations_struct ttm_bo_vm_ops = {
.fault = ttm_bo_vm_fault,
.open = ttm_bo_vm_open,
.close = ttm_bo_vm_close,
.access = ttm_bo_vm_access,
+ .mprotect = ttm_bo_vm_mprotect,
The problem is most drivers implement their own copy of this structure.
You need to add this to those occasions as well, just search for
references to ttm_bo_vm_open.
Regards,
Christian.
};
int ttm_bo_mmap_obj(struct vm_area_struct *vma, struct ttm_buffer_object *bo)
{
/* Enforce no COW since would have really strange behavior with it. */
- if (is_cow_mapping(vma->vm_flags))
+ if (is_cow_mapping(vma->vm_flags) && (vma->vm_flags & VM_WRITE))
return -EINVAL;
ttm_bo_get(bo);
Re: [v8 1/6] drm/panel: add basic DP AUX backlight support
Am 26.06.21 um 18:51 schrieb Rajeev Nandan:
Some panels support backlight control over DP AUX channel using
VESA's standard backlight control interface.
Using new DRM eDP backlight helpers, add support to create and
register a backlight for those panels in drm_panel to simplify
the panel drivers.
The panel driver with access to "struct drm_dp_aux" can create and
register a backlight device using following code snippet in its
probe() function:
err = drm_panel_dp_aux_backlight(panel, aux);
if (err)
return err;
Then drm_panel will handle backlight_(enable|disable) calls
similar to the case when drm_panel_of_backlight() is used.
Currently, we are not supporting one feature where the source
device can combine the backlight brightness levels set through
DP AUX and the BL_PWM_DIM eDP connector pin. Since it's not
required for the basic backlight controls, it can be added later.
Signed-off-by: Rajeev Nandan
Reviewed-by: Douglas Anderson
Reviewed-by: Lyude Paul
---
Changes in v5:
- New
Changes in v6:
- Fixed ordering of memory allocation (Douglas)
- Updated word wrapping in a comment (Douglas)
Changes in v8:
- Now using backlight_is_blank() to get the backlight blank status (Sam
Ravnborg)
drivers/gpu/drm/drm_panel.c | 108
include/drm/drm_panel.h | 15 --
2 files changed, 119 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index f634371..4fa1e3b 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -26,12 +26,20 @@
#include
#include
+#include
#include
#include
static DEFINE_MUTEX(panel_lock);
static LIST_HEAD(panel_list);
+struct dp_aux_backlight {
+ struct backlight_device *base;
+ struct drm_dp_aux *aux;
+ struct drm_edp_backlight_info info;
+ bool enabled;
+};
+
/**
* DOC: drm panel
*
@@ -342,6 +350,106 @@ int drm_panel_of_backlight(struct drm_panel *panel)
return 0;
}
EXPORT_SYMBOL(drm_panel_of_backlight);
+
+static int dp_aux_backlight_update_status(struct backlight_device *bd)
+{
+ struct dp_aux_backlight *bl = bl_get_data(bd);
+ u16 brightness = backlight_get_brightness(bd);
+ int ret = 0;
+
+ if (!backlight_is_blank(bd)) {
+ if (!bl->enabled) {
+ drm_edp_backlight_enable(bl->aux, &bl->info,
brightness);
+ bl->enabled = true;
+ return 0;
+ }
+ ret = drm_edp_backlight_set_level(bl->aux, &bl->info,
brightness);
+ } else {
+ if (bl->enabled) {
+ drm_edp_backlight_disable(bl->aux, &bl->info);
+ bl->enabled = false;
+ }
+ }
+
+ return ret;
+}
+
+static const struct backlight_ops dp_aux_bl_ops = {
+ .update_status = dp_aux_backlight_update_status,
+};
+
+/**
+ * drm_panel_dp_aux_backlight - create and use DP AUX backlight
+ * @panel: DRM panel
+ * @aux: The DP AUX channel to use
+ *
+ * Use this function to create and handle backlight if your panel
+ * supports backlight control over DP AUX channel using DPCD
+ * registers as per VESA's standard backlight control interface.
+ *
+ * When the panel is enabled backlight will be enabled after a
+ * successful call to &drm_panel_funcs.enable()
+ *
+ * When the panel is disabled backlight will be disabled before the
+ * call to &drm_panel_funcs.disable().
+ *
+ * A typical implementation for a panel driver supporting backlight
+ * control over DP AUX will call this function at probe time.
+ * Backlight will then be handled transparently without requiring
+ * any intervention from the driver.
+ *
+ * drm_panel_dp_aux_backlight() must be called after the call to
drm_panel_init().
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int drm_panel_dp_aux_backlight(struct drm_panel *panel, struct drm_dp_aux *aux)
+{
+ struct dp_aux_backlight *bl;
+ struct backlight_properties props = { 0 };
+ u16 current_level;
+ u8 current_mode;
+ u8 edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE];
+ int ret;
+
+ if (!panel || !panel->dev || !aux)
+ return -EINVAL;
+
+ ret = drm_dp_dpcd_read(aux, DP_EDP_DPCD_REV, edp_dpcd,
+ EDP_DISPLAY_CTL_CAP_SIZE);
This creates a cyclic dependency between drm_kms_helper-ko and drm.ko.
drm_panel.c is in the latter, while drm_dp_dpcd_read() in
drm_dp_helper.c is in the former. Please fix.
Best regards
Thomas
+ if (ret < 0)
+ return ret;
+
+ if (!drm_edp_backlight_supported(edp_dpcd)) {
+ DRM_DEV_INFO(panel->dev, "DP AUX backlight is not supported\n");
+ return 0;
+ }
+
+ bl = devm_kzalloc(panel->dev, sizeof(*bl), GFP_KERNEL);
+ if (!bl)
+ return -ENOMEM;
+
+ bl->aux = aux;
+
+
Re: [PATCH] drm/ingenic: Convert to Linux IRQ interfaces
Hi
Am 10.07.21 um 12:04 schrieb Paul Cercueil:
Hi,
Le sam., juil. 10 2021 at 08:33:47 +0200, Sam Ravnborg
a écrit :
Hi Thomas,
On Tue, Jul 06, 2021 at 09:44:09AM +0200, Thomas Zimmermann wrote:
Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's
IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers
don't benefit from using it.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index c296472164d9..a09b7da21b53 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -33,7 +33,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -799,8 +798,6 @@ static const struct drm_driver
ingenic_drm_driver_data = {
.fops = &ingenic_drm_fops,
.gem_create_object = ingenic_drm_gem_create_object,
DRM_GEM_CMA_DRIVER_OPS,
-
- .irq_handler = ingenic_drm_irq_handler,
};
static const struct drm_plane_funcs ingenic_drm_primary_plane_funcs
= {
@@ -1098,7 +1095,7 @@ static int ingenic_drm_bind(struct device
*dev, bool has_components)
encoder->possible_clones = clone_mask;
}
- ret = drm_irq_install(drm, irq);
+ ret = request_irq(irq, ingenic_drm_irq_handler, 0,
drm->driver->name, drm);
Can't you use the devm variant?
I think so, I just tried to minimize the difference.
Best regards
Thomas
if (ret) {
dev_err(dev, "Unable to install IRQ handler\n");
return ret;
@@ -1192,14 +1189,18 @@ static void ingenic_drm_unbind(struct device
*dev)
{
struct ingenic_drm *priv = dev_get_drvdata(dev);
struct clk *parent_clk = clk_get_parent(priv->pix_clk);
+ struct drm_device *drm = &priv->drm;
+ struct platform_device *pdev = to_platform_device(drm->dev);
+
+ free_irq(platform_get_irq(pdev, 0), drm);
The driver was missing a drm_irq_uninstall() so the above code is
actually a small bug-fix. It should be mentioned in the changelog.
With this fixed:
Reviewed-by: Sam Ravnborg
Note: I expect Paul to review too and apply.
I wasn't Cc'd? :(
-Paul
Sam
clk_notifier_unregister(parent_clk, &priv->clock_nb);
if (priv->lcd_clk)
clk_disable_unprepare(priv->lcd_clk);
clk_disable_unprepare(priv->pix_clk);
- drm_dev_unregister(&priv->drm);
- drm_atomic_helper_shutdown(&priv->drm);
+ drm_dev_unregister(drm);
+ drm_atomic_helper_shutdown(drm);
}
static const struct component_master_ops ingenic_master_ops = {
--
2.32.0
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
Re: [v8 1/6] drm/panel: add basic DP AUX backlight support
Hi
Am 12.07.21 um 11:41 schrieb Thomas Zimmermann:
Am 26.06.21 um 18:51 schrieb Rajeev Nandan:
Some panels support backlight control over DP AUX channel using
VESA's standard backlight control interface.
Using new DRM eDP backlight helpers, add support to create and
register a backlight for those panels in drm_panel to simplify
the panel drivers.
The panel driver with access to "struct drm_dp_aux" can create and
register a backlight device using following code snippet in its
probe() function:
err = drm_panel_dp_aux_backlight(panel, aux);
if (err)
return err;
Then drm_panel will handle backlight_(enable|disable) calls
similar to the case when drm_panel_of_backlight() is used.
Currently, we are not supporting one feature where the source
device can combine the backlight brightness levels set through
DP AUX and the BL_PWM_DIM eDP connector pin. Since it's not
required for the basic backlight controls, it can be added later.
Signed-off-by: Rajeev Nandan
Reviewed-by: Douglas Anderson
Reviewed-by: Lyude Paul
---
Changes in v5:
- New
Changes in v6:
- Fixed ordering of memory allocation (Douglas)
- Updated word wrapping in a comment (Douglas)
Changes in v8:
- Now using backlight_is_blank() to get the backlight blank status
(Sam Ravnborg)
drivers/gpu/drm/drm_panel.c | 108
include/drm/drm_panel.h | 15 --
2 files changed, 119 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index f634371..4fa1e3b 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -26,12 +26,20 @@
#include
#include
+#include
#include
#include
static DEFINE_MUTEX(panel_lock);
static LIST_HEAD(panel_list);
+struct dp_aux_backlight {
+ struct backlight_device *base;
+ struct drm_dp_aux *aux;
+ struct drm_edp_backlight_info info;
+ bool enabled;
+};
+
/**
* DOC: drm panel
*
@@ -342,6 +350,106 @@ int drm_panel_of_backlight(struct drm_panel *panel)
return 0;
}
EXPORT_SYMBOL(drm_panel_of_backlight);
+
+static int dp_aux_backlight_update_status(struct backlight_device *bd)
+{
+ struct dp_aux_backlight *bl = bl_get_data(bd);
+ u16 brightness = backlight_get_brightness(bd);
+ int ret = 0;
+
+ if (!backlight_is_blank(bd)) {
+ if (!bl->enabled) {
+ drm_edp_backlight_enable(bl->aux, &bl->info, brightness);
+ bl->enabled = true;
+ return 0;
+ }
+ ret = drm_edp_backlight_set_level(bl->aux, &bl->info,
brightness);
+ } else {
+ if (bl->enabled) {
+ drm_edp_backlight_disable(bl->aux, &bl->info);
+ bl->enabled = false;
+ }
+ }
+
+ return ret;
+}
+
+static const struct backlight_ops dp_aux_bl_ops = {
+ .update_status = dp_aux_backlight_update_status,
+};
+
+/**
+ * drm_panel_dp_aux_backlight - create and use DP AUX backlight
+ * @panel: DRM panel
+ * @aux: The DP AUX channel to use
+ *
+ * Use this function to create and handle backlight if your panel
+ * supports backlight control over DP AUX channel using DPCD
+ * registers as per VESA's standard backlight control interface.
+ *
+ * When the panel is enabled backlight will be enabled after a
+ * successful call to &drm_panel_funcs.enable()
+ *
+ * When the panel is disabled backlight will be disabled before the
+ * call to &drm_panel_funcs.disable().
+ *
+ * A typical implementation for a panel driver supporting backlight
+ * control over DP AUX will call this function at probe time.
+ * Backlight will then be handled transparently without requiring
+ * any intervention from the driver.
+ *
+ * drm_panel_dp_aux_backlight() must be called after the call to
drm_panel_init().
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int drm_panel_dp_aux_backlight(struct drm_panel *panel, struct
drm_dp_aux *aux)
+{
+ struct dp_aux_backlight *bl;
+ struct backlight_properties props = { 0 };
+ u16 current_level;
+ u8 current_mode;
+ u8 edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE];
+ int ret;
+
+ if (!panel || !panel->dev || !aux)
+ return -EINVAL;
+
+ ret = drm_dp_dpcd_read(aux, DP_EDP_DPCD_REV, edp_dpcd,
+ EDP_DISPLAY_CTL_CAP_SIZE);
This creates a cyclic dependency between drm_kms_helper-ko and drm.ko.
drm_panel.c is in the latter, while drm_dp_dpcd_read() in
drm_dp_helper.c is in the former. Please fix.
FYI, build DRM as modules and the error shows up during make module_install.
Best regards
Thomas
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
[PATCH] drm/mediatek: mtk-dpi: Set out_fmt from config if not the last bridge
atomic_get_output_bus_fmts() is only called when the bridge is the last
element in the bridge chain.
If mtk-dpi is not the last bridge, the format of output_bus_cfg is
MEDIA_BUS_FMT_FIXED, and mtk_dpi_dual_edge() will fail to write correct
value to regs.
Fixes: ec8747c52434 ("drm/mediatek: dpi: Add bus format negotiation")
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index bced555648b01..25c565f9179cc 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -610,6 +610,10 @@ static int mtk_dpi_bridge_atomic_check(struct drm_bridge
*bridge,
out_bus_format = bridge_state->output_bus_cfg.format;
+ if (out_bus_format == MEDIA_BUS_FMT_FIXED)
+ if (dpi->conf->num_output_fmts)
+ out_bus_format = dpi->conf->output_fmts[0];
+
dev_dbg(dpi->dev, "input format 0x%04x, output format 0x%04x\n",
bridge_state->input_bus_cfg.format,
bridge_state->output_bus_cfg.format);
--
2.32.0.93.g670b81a890-goog
Re: [PATCH] include/uapi/drm: fix spelling mistakes in header files
On Sat, Jul 3, 2021 at 11:00 AM Simon Ser wrote: > > Reviewed-by: Simon Ser > > But this this touches a lot of different drivers, not sure we can just > merge this via drm-misc-next? > > In any case, please ping me again in a week if this hasn't been merged > by then. > As long as it doesn't touch code I don't see why not. Just in case: Reviewed-by: Karol Herbst
Re: [PATCH v3] drm/panfrost:fix the exception name always "UNKNOWN"
On 08/07/2021 08:34, ChunyouTang wrote: > From: ChunyouTang > > The exception_code in register is only 8 bits,So if > fault_status in panfrost_gpu_irq_handler() don't > (& 0xFF),it can't get correct exception reason. > > and it's better to show all of the register value > to custom,so it's better fault_status don't (& 0xFF). > > Signed-off-by: ChunyouTang Reviewed-by: Steven Price Boris's change has actually modified panfrost_exception_name() to no longer take pfdev in drm-misc-next. However, I'll just fix this up when I apply it. Thanks, Steve > --- > drivers/gpu/drm/panfrost/panfrost_gpu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c > b/drivers/gpu/drm/panfrost/panfrost_gpu.c > index 1fffb6a0b24f..d2d287bbf4e7 100644 > --- a/drivers/gpu/drm/panfrost/panfrost_gpu.c > +++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c > @@ -33,7 +33,7 @@ static irqreturn_t panfrost_gpu_irq_handler(int irq, void > *data) > address |= gpu_read(pfdev, GPU_FAULT_ADDRESS_LO); > > dev_warn(pfdev->dev, "GPU Fault 0x%08x (%s) at 0x%016llx\n", > - fault_status & 0xFF, panfrost_exception_name(pfdev, > fault_status & 0xFF), > + fault_status, panfrost_exception_name(pfdev, > fault_status & 0xFF), >address); > > if (state & GPU_IRQ_MULTIPLE_FAULT) >
Re: [PATCH] video: backlight: Drop maximum brightness override for brightness zero
On Fri, Jul 09, 2021 at 03:53:16PM +0200, Noralf Trønnes wrote:
>
>
> Den 09.07.2021 15.26, skrev Marek Vasut:
> > The note in c2adda27d202f ("video: backlight: Add of_find_backlight helper
> > in backlight.c") says that gpio-backlight uses brightness as power state.
> > This has been fixed since in ec665b756e6f7 ("backlight: gpio-backlight:
> > Correct initial power state handling") and other backlight drivers do not
> > require this workaround. Drop the workaround.
> >
> > This fixes the case where e.g. pwm-backlight can perfectly well be set to
> > brightness 0 on boot in DT, which without this patch leads to the display
> > brightness to be max instead of off.
> >
> > Fixes: c2adda27d202f ("video: backlight: Add of_find_backlight helper in
> > backlight.c")
>
> I not sure about the rules, but if this is automatically picked up for
> stable, maybe this is needed to avoid changing behaviour on 4.19:
>
>
> of_find_backlight() was added in 4.17 and the gpio fix in 5.4.
>
> Or perhaps there are other ways to signal this dependency.
Agree we need to make sure the Fixes: tag doesn't provoke regressions
in v4.19.
Is this the syntax appropriate?
Cc: # 5.4+
Cc: # 4.19.x: ec665b756e6f7: backlight:
gpio-backlight: Correct initial power state handling
> > Signed-off-by: Marek Vasut
> > Cc: Daniel Thompson
> > Cc: Meghana Madhyastha
> > Cc: Noralf Trønnes
> > Cc: Sean Paul
> > Cc: Thierry Reding
> > ---
>
> Acked-by: Noralf Trønnes
With the above (or something similar to avoid problems with v4.19):
Reviewed-by: Daniel Thompson
Daniel.
Re: [PATCH] fbcon: garbage collect fbdev scrolling acceleration
Hi Hamza,
On Fri, Jul 9, 2021 at 11:28 PM Hamza Mahfooz
wrote:
> On Fri, Jul 9 2021 at 09:49:02 AM +0200, Geert Uytterhoeven
> wrote:
> > Bummer, more code to revert to re-enable acceleration in the _56_
> > fbdev drivers using acceleration (some of them unusable without),
> > despite commit 39aead8373b3 claiming "No other driver supportes
> > accelerated fbcon"...
> Should they be refactored to DRM drivers? (I don't mind looking into it
> if you believe it's worthwhile.)
Probably some of them can be converted.
Others must wait for DRM to gain e.g. more "low color" support
(plus whatever other dead bodies to be found during the conversion).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 2/2] drm/ttm, drm/i915: Update ttm_move_memcpy for async use
Am 28.06.21 um 13:21 schrieb Thomas Hellström:
On 6/24/21 9:30 PM, Thomas Hellström wrote:
The buffer object argument to ttm_move_memcpy was only used to
determine whether the destination memory should be cleared only
or whether we should copy data. Replace it with a "clear" bool, and
update the callers.
The intention here is to be able to use ttm_move_memcpy() async under
a dma-fence as a fallback if an accelerated blit fails in a security-
critical path where data might leak if the blit is not properly
performed. For that purpose the bo is an unsuitable argument since
its relevant members might already have changed at call time.
Finally, update the ttm_move_memcpy kerneldoc that seems to have
ended up with a stale version.
Hmm,
Not sure where the Cc: Christian König ended up, but in any case
Christian if you find this patch ok, Ack to merge through
drm_intel_gt_next?
Please send out the patch once more.
Only nit picks, but I would re-order the parameters for example.
Regards,
Christian.
/Thomas
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo_util.c | 20 ++--
include/drm/ttm/ttm_bo_driver.h | 2 +-
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 4e529adcdfc7..f19847abe856 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -517,7 +517,7 @@ static void __i915_ttm_move(struct
ttm_buffer_object *bo, bool clear,
obj->ttm.cached_io_st,
src_reg->region.start);
- ttm_move_memcpy(bo, dst_mem->num_pages, dst_iter, src_iter);
+ ttm_move_memcpy(clear, dst_mem->num_pages, dst_iter, src_iter);
}
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 2f57f824e6db..e3747f069674 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -75,22 +75,21 @@ void ttm_mem_io_free(struct ttm_device *bdev,
/**
* ttm_move_memcpy - Helper to perform a memcpy ttm move operation.
- * @bo: The struct ttm_buffer_object.
- * @new_mem: The struct ttm_resource we're moving to (copy
destination).
- * @new_iter: A struct ttm_kmap_iter representing the destination
resource.
+ * @clear: Whether to clear rather than copy.
+ * @num_pages: Number of pages of the operation.
+ * @dst_iter: A struct ttm_kmap_iter representing the destination
resource.
* @src_iter: A struct ttm_kmap_iter representing the source resource.
*
* This function is intended to be able to move out async under a
* dma-fence if desired.
*/
-void ttm_move_memcpy(struct ttm_buffer_object *bo,
+void ttm_move_memcpy(bool clear,
u32 num_pages,
struct ttm_kmap_iter *dst_iter,
struct ttm_kmap_iter *src_iter)
{
const struct ttm_kmap_iter_ops *dst_ops = dst_iter->ops;
const struct ttm_kmap_iter_ops *src_ops = src_iter->ops;
- struct ttm_tt *ttm = bo->ttm;
struct dma_buf_map src_map, dst_map;
pgoff_t i;
@@ -99,10 +98,7 @@ void ttm_move_memcpy(struct ttm_buffer_object *bo,
return;
/* Don't move nonexistent data. Clear destination instead. */
- if (src_ops->maps_tt && (!ttm || !ttm_tt_is_populated(ttm))) {
- if (ttm && !(ttm->page_flags & TTM_PAGE_FLAG_ZERO_ALLOC))
- return;
-
+ if (clear) {
for (i = 0; i < num_pages; ++i) {
dst_ops->map_local(dst_iter, &dst_map, i);
if (dst_map.is_iomem)
@@ -146,6 +142,7 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
struct ttm_kmap_iter_linear_io io;
} _dst_iter, _src_iter;
struct ttm_kmap_iter *dst_iter, *src_iter;
+ bool clear;
int ret = 0;
if (ttm && ((ttm->page_flags & TTM_PAGE_FLAG_SWAPPED) ||
@@ -169,7 +166,10 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object
*bo,
goto out_src_iter;
}
- ttm_move_memcpy(bo, dst_mem->num_pages, dst_iter, src_iter);
+ clear = src_iter->ops->maps_tt && (!ttm ||
!ttm_tt_is_populated(ttm));
+ if (!(clear && ttm && !(ttm->page_flags &
TTM_PAGE_FLAG_ZERO_ALLOC)))
+ ttm_move_memcpy(clear, dst_mem->num_pages, dst_iter, src_iter);
+
src_copy = *src_mem;
ttm_bo_move_sync_cleanup(bo, dst_mem);
diff --git a/include/drm/ttm/ttm_bo_driver.h
b/include/drm/ttm/ttm_bo_driver.h
index 68d6069572aa..5f087575194b 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -322,7 +322,7 @@ int ttm_bo_tt_bind(struct ttm_buffer_object *bo,
struct ttm_resource *mem);
*/
void ttm_bo_tt_destroy(struct ttm_buffer_object *bo);
-void ttm_move_memcpy(struct ttm_buffer_object *bo,
+void ttm_move_memcpy(bool clear,
u32 num_pages,
struct ttm_kmap_iter *dst_iter,
Re: [PATCH] dma-buf/sync_file: Don't leak fences on merge failure
Sorry for the vacation and sick leave induced delay.
I've just pushed this to drm-misc-fixes.
Thanks,
Christian.
Am 24.06.21 um 21:43 schrieb Jason Ekstrand:
I don't have drm-misc access. Mind pushing?
On Thu, Jun 24, 2021 at 12:59 PM Christian König
wrote:
Am 24.06.21 um 19:47 schrieb Jason Ekstrand:
Each add_fence() call does a dma_fence_get() on the relevant fence. In
the error path, we weren't calling dma_fence_put() so all those fences
got leaked. Also, in the krealloc_array failure case, we weren't
freeing the fences array. Instead, ensure that i and fences are always
zero-initialized and dma_fence_put() all the fences and kfree(fences) on
every error path.
Signed-off-by: Jason Ekstrand
Fixes: a02b9dc90d84 ("dma-buf/sync_file: refactor fence storage in struct
sync_file")
Cc: Gustavo Padovan
Cc: Christian König
Reviewed-by: Christian König
---
drivers/dma-buf/sync_file.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 20d9bddbb985b..394e6e1e96860 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -211,8 +211,8 @@ static struct sync_file *sync_file_merge(const char *name,
struct sync_file *a,
struct sync_file *b)
{
struct sync_file *sync_file;
- struct dma_fence **fences, **nfences, **a_fences, **b_fences;
- int i, i_a, i_b, num_fences, a_num_fences, b_num_fences;
+ struct dma_fence **fences = NULL, **nfences, **a_fences, **b_fences;
+ int i = 0, i_a, i_b, num_fences, a_num_fences, b_num_fences;
sync_file = sync_file_alloc();
if (!sync_file)
@@ -236,7 +236,7 @@ static struct sync_file *sync_file_merge(const char *name,
struct sync_file *a,
* If a sync_file can only be created with sync_file_merge
* and sync_file_create, this is a reasonable assumption.
*/
- for (i = i_a = i_b = 0; i_a < a_num_fences && i_b < b_num_fences; ) {
+ for (i_a = i_b = 0; i_a < a_num_fences && i_b < b_num_fences; ) {
struct dma_fence *pt_a = a_fences[i_a];
struct dma_fence *pt_b = b_fences[i_b];
@@ -277,15 +277,16 @@ static struct sync_file *sync_file_merge(const char
*name, struct sync_file *a,
fences = nfences;
}
- if (sync_file_set_fence(sync_file, fences, i) < 0) {
- kfree(fences);
+ if (sync_file_set_fence(sync_file, fences, i) < 0)
goto err;
- }
strlcpy(sync_file->user_name, name, sizeof(sync_file->user_name));
return sync_file;
err:
+ while (i)
+ dma_fence_put(fences[--i]);
+ kfree(fences);
fput(sync_file->file);
return NULL;
Re: [PATCH] drm/shmobile: Convert to Linux IRQ interfaces
Hi Thomas,
On Tue, Jul 6, 2021 at 9:49 AM Thomas Zimmermann wrote:
> Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's
> IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers
> don't benefit from using it.
>
> Signed-off-by: Thomas Zimmermann
Thanks for your patch!
> --- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> +++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> @@ -258,7 +256,7 @@ static int shmob_drm_probe(struct platform_device *pdev)
> goto err_modeset_cleanup;
> }
>
> - ret = drm_irq_install(ddev, platform_get_irq(pdev, 0));
> + ret = request_irq(platform_get_irq(pdev, 0), shmob_drm_irq, 0,
> ddev->driver->name, ddev);
platform_get_irq() can return a negative error code.
While drm_irq_install() took a signed irq parameter (and only
considered zero an error, oops), request_irq() takes an unsigned irq.
So you better check for errors before calling request_irq().
> if (ret < 0) {
> dev_err(&pdev->dev, "failed to install IRQ handler\n");
> goto err_modeset_cleanup;
> @@ -275,7 +273,7 @@ static int shmob_drm_probe(struct platform_device *pdev)
> return 0;
>
> err_irq_uninstall:
> - drm_irq_uninstall(ddev);
> + free_irq(platform_get_irq(pdev, 0), ddev);
Similar issue here.
> err_modeset_cleanup:
> drm_kms_helper_poll_fini(ddev);
> err_free_drm_dev:
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] soc: mediatek: mmsys: fix HDMI output on mt7623/bananapi-r2
Hi
On 10.07.21 15:24, Frank Wunderlich wrote:
From: Frank Wunderlich
HDMI output was broken on mt7623/BPI-R2 in 5.13 because function for
special output selection (mtk_mmsys_ddp_sout_sel) was dropped.
This function wrote 3 registers at one time and so it is not compatible
with the array-approach.
I re-added the old function and call this after the default routing table
was applied. This default routing table can still be used as the only
connection handled by mmsys on BPI-R2 is OVL0->RDMA0 and this is already
present in the default routing table
Fixes: 440147639ac7 ("soc: mediatek: mmsys: Use an array for setting the routing
registers")
Signed-off-by: Frank Wunderlich
---
drivers/soc/mediatek/mtk-mmsys.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index 080660ef11bf..f91b7fdd417a 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -57,6 +57,25 @@ struct mtk_mmsys {
const struct mtk_mmsys_driver_data *data;
};
+static void mtk_mmsys_ddp_sout_sel(struct device *dev,
+ enum mtk_ddp_comp_id cur,
+ enum mtk_ddp_comp_id next)
+{
+ struct mtk_mmsys *mmsys = dev_get_drvdata(dev);
+
+ if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) {
+ writel_relaxed(BLS_TO_DSI_RDMA1_TO_DPI1,
+ mmsys->regs + DISP_REG_CONFIG_OUT_SEL);
+ } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
+ writel_relaxed(BLS_TO_DPI_RDMA1_TO_DSI,
+ mmsys->regs + DISP_REG_CONFIG_OUT_SEL);
+ writel_relaxed(DSI_SEL_IN_RDMA,
+ mmsys->regs + DISP_REG_CONFIG_DSI_SEL);
+ writel_relaxed(DPI_SEL_IN_BLS,
+ mmsys->regs + DISP_REG_CONFIG_DPI_SEL);
you can still use the array approach for this like that:
{
DDP_COMPONENT_BLS, DDP_COMPONENT_DSI0,
DISP_REG_CONFIG_OUT_SEL, BLS_TO_DSI_RDMA1_TO_DPI1
}, {
{
DDP_COMPONENT_BLS, DDP_COMPONENT_DPI0,
DISP_REG_CONFIG_OUT_SEL, BLS_TO_DPI_RDMA1_TO_DSI
}, {
{
DDP_COMPONENT_BLS, DDP_COMPONENT_DPI0,
DISP_REG_CONFIG_DSI_SEL, DSI_SEL_IN_RDMA
}, {
{
DDP_COMPONENT_BLS, DDP_COMPONENT_DPI0,
DISP_REG_CONFIG_DPI_SEL, DPI_SEL_IN_BLS
}, {
Thanks,
Dafna
+ }
+}
+
void mtk_mmsys_ddp_connect(struct device *dev,
enum mtk_ddp_comp_id cur,
enum mtk_ddp_comp_id next)
@@ -71,6 +90,8 @@ void mtk_mmsys_ddp_connect(struct device *dev,
reg = readl_relaxed(mmsys->regs + routes[i].addr) |
routes[i].val;
writel_relaxed(reg, mmsys->regs + routes[i].addr);
}
+
+ mtk_mmsys_ddp_sout_sel(dev, cur, next);
}
EXPORT_SYMBOL_GPL(mtk_mmsys_ddp_connect);
Re: [PATCH 0/4] vkms: Switch to shadow-buffered plane state
On Mon, Jul 5, 2021 at 1:16 PM Thomas Zimmermann wrote: > > Vkms copies each plane's framebuffer into the output buffer; essentially > using a shadow buffer. DRM provides struct drm_shadow_plane_state, which > handles the details of mapping/unmapping shadow buffers into memory for > active planes. > > Convert vkms to the helpers. Makes vkms use shared code and gives more > test exposure to shadow-plane helpers. > > Thomas Zimmermann (4): > drm/gem: Export implementation of shadow-plane helpers > drm/vkms: Inherit plane state from struct drm_shadow_plane_state > drm/vkms: Let shadow-plane helpers prepare the plane's FB > drm/vkms: Use dma-buf mapping from shadow-plane state for composing > > drivers/gpu/drm/drm_gem_atomic_helper.c | 55 ++-- > drivers/gpu/drm/vkms/vkms_composer.c| 26 ++- > drivers/gpu/drm/vkms/vkms_drv.h | 6 ++- > drivers/gpu/drm/vkms/vkms_plane.c | 57 ++--- > include/drm/drm_gem_atomic_helper.h | 6 +++ > 5 files changed, 86 insertions(+), 64 deletions(-) > > > base-commit: 3d3b5479895dd6dd133571ded4318adf595708ba > -- > 2.32.0 > Hi, Thanks for the patches. The switch to shadow-plane helpers also solved a bug that was causing a kernel panic during some IGT kms_flip subtests on the vkms virtual hw patch. Tested-by: Sumera Priyadarsini Cheers, Sumera
[PATCH 0/8] Per client engine busyness
From: Tvrtko Ursulin Same old work but now rebased and series ending with some DRM docs proposing the common specification which should enable nice common userspace tools to be written. For the moment I only have intel_gpu_top converted to use this and that seems to work okay. Tvrtko Ursulin (8): drm/i915: Explicitly track DRM clients drm/i915: Update client name on context create drm/i915: Make GEM contexts track DRM clients drm/i915: Track runtime spent in closed and unreachable GEM contexts drm/i915: Track all user contexts per client drm/i915: Track context current active time drm/i915: Expose client engine utilisation via fdinfo drm: Document fdinfo format specification Documentation/gpu/drm-usage-stats.rst | 99 +++ Documentation/gpu/i915.rst| 27 ++ Documentation/gpu/index.rst | 1 + drivers/gpu/drm/i915/Makefile | 5 +- drivers/gpu/drm/i915/gem/i915_gem_context.c | 55 +++- .../gpu/drm/i915/gem/i915_gem_context_types.h | 16 +- drivers/gpu/drm/i915/gt/intel_context.c | 27 +- drivers/gpu/drm/i915/gt/intel_context.h | 15 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 24 +- .../drm/i915/gt/intel_execlists_submission.c | 23 +- .../gpu/drm/i915/gt/intel_gt_clock_utils.c| 4 + drivers/gpu/drm/i915/gt/intel_lrc.c | 27 +- drivers/gpu/drm/i915/gt/intel_lrc.h | 24 ++ drivers/gpu/drm/i915/gt/selftest_lrc.c| 10 +- drivers/gpu/drm/i915/i915_drm_client.c| 243 ++ drivers/gpu/drm/i915/i915_drm_client.h| 107 drivers/gpu/drm/i915/i915_drv.c | 9 + drivers/gpu/drm/i915/i915_drv.h | 5 + drivers/gpu/drm/i915/i915_gem.c | 21 +- drivers/gpu/drm/i915/i915_gpu_error.c | 31 +-- drivers/gpu/drm/i915/i915_gpu_error.h | 2 +- 21 files changed, 696 insertions(+), 79 deletions(-) create mode 100644 Documentation/gpu/drm-usage-stats.rst create mode 100644 drivers/gpu/drm/i915/i915_drm_client.c create mode 100644 drivers/gpu/drm/i915/i915_drm_client.h -- 2.30.2
[PATCH 1/8] drm/i915: Explicitly track DRM clients
From: Tvrtko Ursulin
Tracking DRM clients more explicitly will allow later patches to
accumulate past and current GPU usage in a centralised place and also
consolidate access to owning task pid/name.
Unique client id is also assigned for the purpose of distinguishing/
consolidating between multiple file descriptors owned by the same process.
v2:
Chris Wilson:
* Enclose new members into dedicated structs.
* Protect against failed sysfs registration.
v3:
* sysfs_attr_init.
v4:
* Fix for internal clients.
v5:
* Use cyclic ida for client id. (Chris)
* Do not leak pid reference. (Chris)
* Tidy code with some locals.
v6:
* Use xa_alloc_cyclic to simplify locking. (Chris)
* No need to unregister individial sysfs files. (Chris)
* Rebase on top of fpriv kref.
* Track client closed status and reflect in sysfs.
v7:
* Make drm_client more standalone concept.
v8:
* Simplify sysfs show. (Chris)
* Always track name and pid.
v9:
* Fix cyclic id assignment.
v10:
* No need for a mutex around xa_alloc_cyclic.
* Refactor sysfs into own function.
* Unregister sysfs before freeing pid and name.
* Move clients setup into own function.
v11:
* Call clients init directly from driver init. (Chris)
v12:
* Do not fail client add on id wrap. (Maciej)
v13 (Lucas): Rebase.
v14:
* Dropped sysfs bits.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson # v11
Reviewed-by: Aravind Iddamsetty # v11
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 5 +-
drivers/gpu/drm/i915/i915_drm_client.c | 113 +
drivers/gpu/drm/i915/i915_drm_client.h | 61 +
drivers/gpu/drm/i915/i915_drv.c| 6 ++
drivers/gpu/drm/i915/i915_drv.h| 5 ++
drivers/gpu/drm/i915/i915_gem.c| 21 -
6 files changed, 206 insertions(+), 5 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_drm_client.c
create mode 100644 drivers/gpu/drm/i915/i915_drm_client.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 10b3bb6207ba..784f99ca11fc 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -33,8 +33,9 @@ subdir-ccflags-y += -I$(srctree)/$(src)
# Please keep these build lists sorted!
# core driver code
-i915-y += i915_drv.o \
- i915_config.o \
+i915-y += i915_config.o \
+ i915_drm_client.o \
+ i915_drv.o \
i915_irq.o \
i915_getparam.o \
i915_mitigations.o \
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
new file mode 100644
index ..83080d9836b0
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -0,0 +1,113 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include "i915_drm_client.h"
+#include "i915_gem.h"
+#include "i915_utils.h"
+
+void i915_drm_clients_init(struct i915_drm_clients *clients,
+ struct drm_i915_private *i915)
+{
+ clients->i915 = i915;
+
+ clients->next_id = 0;
+ xa_init_flags(&clients->xarray, XA_FLAGS_ALLOC);
+}
+
+static int
+__i915_drm_client_register(struct i915_drm_client *client,
+ struct task_struct *task)
+{
+ char *name;
+
+ name = kstrdup(task->comm, GFP_KERNEL);
+ if (!name)
+ return -ENOMEM;
+
+ client->pid = get_task_pid(task, PIDTYPE_PID);
+ client->name = name;
+
+ return 0;
+}
+
+static void __i915_drm_client_unregister(struct i915_drm_client *client)
+{
+ put_pid(fetch_and_zero(&client->pid));
+ kfree(fetch_and_zero(&client->name));
+}
+
+static void __rcu_i915_drm_client_free(struct work_struct *wrk)
+{
+ struct i915_drm_client *client =
+ container_of(wrk, typeof(*client), rcu.work);
+
+ xa_erase(&client->clients->xarray, client->id);
+
+ __i915_drm_client_unregister(client);
+
+ kfree(client);
+}
+
+struct i915_drm_client *
+i915_drm_client_add(struct i915_drm_clients *clients, struct task_struct *task)
+{
+ struct i915_drm_client *client;
+ int ret;
+
+ client = kzalloc(sizeof(*client), GFP_KERNEL);
+ if (!client)
+ return ERR_PTR(-ENOMEM);
+
+ kref_init(&client->kref);
+ client->clients = clients;
+ INIT_RCU_WORK(&client->rcu, __rcu_i915_drm_client_free);
+
+ ret = xa_alloc_cyclic(&clients->xarray, &client->id, client,
+ xa_limit_32b, &clients->next_id, GFP_KERNEL);
+ if (ret < 0)
+ goto err_id;
+
+ ret = __i915_drm_client_register(client, task);
+ if (ret)
+ goto err_register;
+
+ return client;
+
+err_register:
+ xa_erase(&clients->xarray, client->id);
+err_id:
+ kfree(client);
+
+ return ERR_PTR(ret);
+}
+
+void __i915_drm_client_free(struct kref *kref)
+{
+ struct i915_drm_client *client =
+ conta
[PATCH 2/8] drm/i915: Update client name on context create
From: Tvrtko Ursulin
Some clients have the DRM fd passed to them over a socket by the X server.
Grab the real client and pid when they create their first context and
update the exposed data for more useful enumeration.
To enable lockless access to client name and pid data from the following
patches, we also make these fields rcu protected. In this way asynchronous
code paths where both contexts which remain after the client exit, and
access to client name and pid as they are getting updated due context
creation running in parallel with name/pid queries.
v2:
* Do not leak the pid reference and borrow context idr_lock. (Chris)
v3:
* More avoiding leaks. (Chris)
v4:
* Move update completely to drm client. (Chris)
* Do not lose previous client data on failure to re-register and simplify
update to only touch what it needs.
v5:
* Reuse ext_data local. (Chris)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Reviewed-by: Aravind Iddamsetty
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 ++
drivers/gpu/drm/i915/i915_drm_client.c | 66 +++--
drivers/gpu/drm/i915/i915_drm_client.h | 34 ++-
3 files changed, 97 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 7d6f52d8a801..ae9d4e087a92 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -78,6 +78,7 @@
#include "gt/intel_gpu_commands.h"
#include "gt/intel_ring.h"
+#include "i915_drm_client.h"
#include "i915_gem_context.h"
#include "i915_globals.h"
#include "i915_trace.h"
@@ -1996,6 +1997,10 @@ int i915_gem_context_create_ioctl(struct drm_device
*dev, void *data,
goto err_pc;
}
+ ret = i915_drm_client_update(ext_data.fpriv->client, current);
+ if (ret)
+ goto err_pc;
+
if (GRAPHICS_VER(i915) > 12) {
struct i915_gem_context *ctx;
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index 83080d9836b0..0b7a70ed61d0 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -7,7 +7,10 @@
#include
#include
+#include
+
#include "i915_drm_client.h"
+#include "i915_drv.h"
#include "i915_gem.h"
#include "i915_utils.h"
@@ -20,26 +23,57 @@ void i915_drm_clients_init(struct i915_drm_clients *clients,
xa_init_flags(&clients->xarray, XA_FLAGS_ALLOC);
}
+static struct i915_drm_client_name *get_name(struct i915_drm_client *client,
+struct task_struct *task)
+{
+ struct i915_drm_client_name *name;
+ int len = strlen(task->comm);
+
+ name = kmalloc(struct_size(name, name, len + 1), GFP_KERNEL);
+ if (!name)
+ return NULL;
+
+ init_rcu_head(&name->rcu);
+ name->client = client;
+ name->pid = get_task_pid(task, PIDTYPE_PID);
+ memcpy(name->name, task->comm, len + 1);
+
+ return name;
+}
+
+static void free_name(struct rcu_head *rcu)
+{
+ struct i915_drm_client_name *name =
+ container_of(rcu, typeof(*name), rcu);
+
+ put_pid(name->pid);
+ kfree(name);
+}
+
static int
__i915_drm_client_register(struct i915_drm_client *client,
struct task_struct *task)
{
- char *name;
+ struct i915_drm_client_name *name;
- name = kstrdup(task->comm, GFP_KERNEL);
+ name = get_name(client, task);
if (!name)
return -ENOMEM;
- client->pid = get_task_pid(task, PIDTYPE_PID);
- client->name = name;
+ RCU_INIT_POINTER(client->name, name);
return 0;
}
static void __i915_drm_client_unregister(struct i915_drm_client *client)
{
- put_pid(fetch_and_zero(&client->pid));
- kfree(fetch_and_zero(&client->name));
+ struct i915_drm_client_name *name;
+
+ mutex_lock(&client->update_lock);
+ name = rcu_replace_pointer(client->name, NULL, true);
+ mutex_unlock(&client->update_lock);
+
+ call_rcu(&name->rcu, free_name);
}
static void __rcu_i915_drm_client_free(struct work_struct *wrk)
@@ -65,6 +99,7 @@ i915_drm_client_add(struct i915_drm_clients *clients, struct
task_struct *task)
return ERR_PTR(-ENOMEM);
kref_init(&client->kref);
+ mutex_init(&client->update_lock);
client->clients = clients;
INIT_RCU_WORK(&client->rcu, __rcu_i915_drm_client_free);
@@ -102,6 +137,25 @@ void i915_drm_client_close(struct i915_drm_client *client)
i915_drm_client_put(client);
}
+int
+i915_drm_client_update(struct i915_drm_client *client,
+ struct task_struct *task)
+{
+ struct i915_drm_client_name *name;
+
+ name = get_name(client, task);
+ if (!name)
+ return -ENOMEM;
+
+ mutex_lock(&client->u
[PATCH 4/8] drm/i915: Track runtime spent in closed and unreachable GEM contexts
From: Tvrtko Ursulin
As contexts are abandoned we want to remember how much GPU time they used
(per class) so later we can used it for smarter purposes.
As GEM contexts are closed we want to have the DRM client remember how
much GPU time they used (per class) so later we can used it for smarter
purposes.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamsetty
Reviewed-by: Chris Wilson
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 25 +++--
drivers/gpu/drm/i915/i915_drm_client.h | 7 ++
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 5a38cb163f04..d0fe05793af7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -842,23 +842,44 @@ static void free_engines_rcu(struct rcu_head *rcu)
free_engines(engines);
}
+static void accumulate_runtime(struct i915_drm_client *client,
+ struct i915_gem_engines *engines)
+{
+ struct i915_gem_engines_iter it;
+ struct intel_context *ce;
+
+ if (!client)
+ return;
+
+ /* Transfer accumulated runtime to the parent GEM context. */
+ for_each_gem_engine(ce, engines, it) {
+ unsigned int class = ce->engine->uabi_class;
+
+ GEM_BUG_ON(class >= ARRAY_SIZE(client->past_runtime));
+ atomic64_add(intel_context_get_total_runtime_ns(ce),
+&client->past_runtime[class]);
+ }
+}
+
static int __i915_sw_fence_call
engines_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state)
{
struct i915_gem_engines *engines =
container_of(fence, typeof(*engines), fence);
+ struct i915_gem_context *ctx = engines->ctx;
switch (state) {
case FENCE_COMPLETE:
if (!list_empty(&engines->link)) {
- struct i915_gem_context *ctx = engines->ctx;
unsigned long flags;
spin_lock_irqsave(&ctx->stale.lock, flags);
list_del(&engines->link);
spin_unlock_irqrestore(&ctx->stale.lock, flags);
}
- i915_gem_context_put(engines->ctx);
+ accumulate_runtime(ctx->client, engines);
+ i915_gem_context_put(ctx);
+
break;
case FENCE_FREE:
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
b/drivers/gpu/drm/i915/i915_drm_client.h
index 6d55f77a08f1..db82180f5859 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -13,6 +13,8 @@
#include
#include
+#include "gt/intel_engine_types.h"
+
struct drm_i915_private;
struct i915_drm_clients {
@@ -41,6 +43,11 @@ struct i915_drm_client {
bool closed;
struct i915_drm_clients *clients;
+
+ /**
+* @past_runtime: Accumulation of pphwsp runtimes from closed contexts.
+*/
+ atomic64_t past_runtime[MAX_ENGINE_CLASS + 1];
};
void i915_drm_clients_init(struct i915_drm_clients *clients,
--
2.30.2
[PATCH 3/8] drm/i915: Make GEM contexts track DRM clients
From: Tvrtko Ursulin
If we make GEM contexts keep a reference to i915_drm_client for the whole
of their lifetime, we can consolidate the current task pid and name usage
by getting it from the client.
v2: Don't bother supporting selftests contexts from debugfs. (Chris)
v3 (Lucas): Finish constructing ctx before adding it to the list
v4 (Ram): Rebase.
v5: Trivial rebase for proto ctx changes.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
Reviewed-by: Aravind Iddamsetty
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 +++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 13 +++
drivers/gpu/drm/i915/i915_gpu_error.c | 22 +++
3 files changed, 25 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ae9d4e087a92..5a38cb163f04 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -989,10 +989,11 @@ void i915_gem_context_release(struct kref *ref)
trace_i915_context_free(ctx);
GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
+ if (ctx->client)
+ i915_drm_client_put(ctx->client);
+
mutex_destroy(&ctx->engines_mutex);
mutex_destroy(&ctx->lut_mutex);
-
- put_pid(ctx->pid);
mutex_destroy(&ctx->mutex);
kfree_rcu(ctx, rcu);
@@ -1436,9 +1437,13 @@ static void gem_context_register(struct i915_gem_context
*ctx,
ctx->file_priv = fpriv;
- ctx->pid = get_task_pid(current, PIDTYPE_PID);
+ ctx->client = i915_drm_client_get(fpriv->client);
+
+ rcu_read_lock();
snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
-current->comm, pid_nr(ctx->pid));
+i915_drm_client_name(ctx->client),
+pid_nr(i915_drm_client_pid(ctx->client)));
+ rcu_read_unlock();
/* And finally expose ourselves to userspace via the idr */
old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 94c03a97cb77..d28678385d16 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -264,19 +264,12 @@ struct i915_gem_context {
*/
struct i915_address_space __rcu *vm;
- /**
-* @pid: process id of creator
-*
-* Note that who created the context may not be the principle user,
-* as the context may be shared across a local socket. However,
-* that should only affect the default context, all contexts created
-* explicitly by the client are expected to be isolated.
-*/
- struct pid *pid;
-
/** @link: place with &drm_i915_private.context_list */
struct list_head link;
+ /** @client: struct i915_drm_client */
+ struct i915_drm_client *client;
+
/**
* @ref: reference count
*
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index a2c58b54a592..b1f17477d0cb 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1235,7 +1235,9 @@ static void record_request(const struct i915_request
*request,
ctx = rcu_dereference(request->context->gem_context);
if (ctx)
- erq->pid = pid_nr(ctx->pid);
+ erq->pid = I915_SELFTEST_ONLY(!ctx->client) ?
+ 0 :
+ pid_nr(i915_drm_client_pid(ctx->client));
}
rcu_read_unlock();
}
@@ -1256,23 +1258,25 @@ static bool record_context(struct
i915_gem_context_coredump *e,
const struct i915_request *rq)
{
struct i915_gem_context *ctx;
- struct task_struct *task;
bool simulated;
rcu_read_lock();
+
ctx = rcu_dereference(rq->context->gem_context);
if (ctx && !kref_get_unless_zero(&ctx->ref))
ctx = NULL;
- rcu_read_unlock();
- if (!ctx)
+ if (!ctx) {
+ rcu_read_unlock();
return true;
+ }
- rcu_read_lock();
- task = pid_task(ctx->pid, PIDTYPE_PID);
- if (task) {
- strcpy(e->comm, task->comm);
- e->pid = task->pid;
+ if (I915_SELFTEST_ONLY(!ctx->client)) {
+ strcpy(e->comm, "[kernel]");
+ } else {
+ strcpy(e->comm, i915_drm_client_name(ctx->client));
+ e->pid = pid_nr(i915_drm_client_pid(ctx->client));
}
+
rcu_read_unlock();
e->sched_attr = ctx->sched;
--
2.30.2
[PATCH 5/8] drm/i915: Track all user contexts per client
From: Tvrtko Ursulin
We soon want to start answering questions like how much GPU time is the
context belonging to a client which exited still using.
To enable this we start tracking all context belonging to a client on a
separate list.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamsetty
Reviewed-by: Chris Wilson
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 12
drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 3 +++
drivers/gpu/drm/i915/i915_drm_client.c| 3 +++
drivers/gpu/drm/i915/i915_drm_client.h| 5 +
4 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index d0fe05793af7..4f14c5193ef7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1214,6 +1214,7 @@ static void set_closed_name(struct i915_gem_context *ctx)
static void context_close(struct i915_gem_context *ctx)
{
+ struct i915_drm_client *client;
struct i915_address_space *vm;
/* Flush any concurrent set_engines() */
@@ -1246,6 +1247,13 @@ static void context_close(struct i915_gem_context *ctx)
list_del(&ctx->link);
spin_unlock(&ctx->i915->gem.contexts.lock);
+ client = ctx->client;
+ if (client) {
+ spin_lock(&client->ctx_lock);
+ list_del_rcu(&ctx->client_link);
+ spin_unlock(&client->ctx_lock);
+ }
+
mutex_unlock(&ctx->mutex);
/*
@@ -1470,6 +1478,10 @@ static void gem_context_register(struct i915_gem_context
*ctx,
old = xa_store(&fpriv->context_xa, id, ctx, GFP_KERNEL);
WARN_ON(old);
+ spin_lock(&ctx->client->ctx_lock);
+ list_add_tail_rcu(&ctx->client_link, &ctx->client->ctx_list);
+ spin_unlock(&ctx->client->ctx_lock);
+
spin_lock(&i915->gem.contexts.lock);
list_add_tail(&ctx->link, &i915->gem.contexts.list);
spin_unlock(&i915->gem.contexts.lock);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index d28678385d16..68ce6d0e8e02 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -270,6 +270,9 @@ struct i915_gem_context {
/** @client: struct i915_drm_client */
struct i915_drm_client *client;
+ /** link: &drm_client.context_list */
+ struct list_head client_link;
+
/**
* @ref: reference count
*
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index 0b7a70ed61d0..1e5db7753276 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -100,6 +100,9 @@ i915_drm_client_add(struct i915_drm_clients *clients,
struct task_struct *task)
kref_init(&client->kref);
mutex_init(&client->update_lock);
+ spin_lock_init(&client->ctx_lock);
+ INIT_LIST_HEAD(&client->ctx_list);
+
client->clients = clients;
INIT_RCU_WORK(&client->rcu, __rcu_i915_drm_client_free);
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
b/drivers/gpu/drm/i915/i915_drm_client.h
index db82180f5859..b2b69d6985e4 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -7,10 +7,12 @@
#define __I915_DRM_CLIENT_H__
#include
+#include
#include
#include
#include
#include
+#include
#include
#include "gt/intel_engine_types.h"
@@ -42,6 +44,9 @@ struct i915_drm_client {
struct i915_drm_client_name __rcu *name;
bool closed;
+ spinlock_t ctx_lock; /* For add/remove from ctx_list. */
+ struct list_head ctx_list; /* List of contexts belonging to client. */
+
struct i915_drm_clients *clients;
/**
--
2.30.2
[RFC 8/8] drm: Document fdinfo format specification
From: Tvrtko Ursulin Proposal to standardise the fdinfo text format as optionally output by DRM drivers. Idea is that a simple but, well defined, spec will enable generic userspace tools to be written while at the same time avoiding a more heavy handed approach of adding a mid-layer to DRM. i915 implements a subset of the spec, everything apart from the memory stats currently, and a matching intel_gpu_top tool exists. Open is to see if AMD can migrate to using the proposed GPU utilisation key-value pairs, or if they are not workable to see whether to go vendor specific, or if a standardised alternative can be found which is workable for both drivers. Same for the memory utilisation key-value pairs proposal. Signed-off-by: Tvrtko Ursulin Cc: David M Nieto Cc: Christian König Cc: Daniel Vetter --- Documentation/gpu/drm-usage-stats.rst | 99 +++ Documentation/gpu/i915.rst| 27 Documentation/gpu/index.rst | 1 + 3 files changed, 127 insertions(+) create mode 100644 Documentation/gpu/drm-usage-stats.rst diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst new file mode 100644 index ..d35e4a01bc5b --- /dev/null +++ b/Documentation/gpu/drm-usage-stats.rst @@ -0,0 +1,99 @@ +.. _drm-client-usage-stats: + +== +DRM client usage stats +== + +DRM drivers can choose to export partly standardised text output via the +`fops->show_fdinfo()` as part of the driver specific file operations registered +in the `struct drm_driver` object registered with the DRM core. + +One purpose of this output is to enable writing as generic as practicaly +feasible `top(1)` like userspace monitoring tools. + +Given the differences between various DRM drivers the specification of the +output is split between common and driver specific parts. Having said that, +wherever possible effort should still be made to standardise as much as +possible. + +File format specification += + +- File shall contain one key value pair per one line of text. +- Colon character (`:`) must be used to delimit keys and values. +- All keys shall be prefixed with `drm-`. +- Whitespace between the delimiter and first non-whitespace character shall be + ignored when parsing. +- Neither keys or values are allowed to contain whitespace characters. +- Numerical key value pairs can end with optional unit string. +- Data type of the value is fixed as defined in the specification. + +Key types +- + +1. Mandatory, fully standardised. +2. Optional, fully standardised. +3. Driver specific. + +Mandatory fully standardised keys +- + +- drm-driver: + +String shall contain a fixed string uniquely identified the driver handling +the device in question. For example name of the respective kernel module. + +Optional fully standardised keys + + +- drm-pdev: + +For PCI devices this should contain the PCI slot address of the device in +question. + +- drm-client-id: + +Unique value relating to the open DRM file descriptor used to distinguish +duplicated and shared file descriptors. Conceptually the value should map 1:1 +to the in kernel representation of `struct drm_file` instances. + +Uniqueness of the value shall be either globally unique, or unique within the +scope of each device, in which case `drm-pdev` shall be present as well. + +Userspace should make sure to not double account any usage statistics by using +the above described criteria in order to associate data to individual clients. + +- drm-client-name: + +Process name of the thread which opened the file. + +- drm-client-pid: + +PID of the thread which opened the file. + +- drm-engine-: ns + +GPUs usually contain multiple execution engines. Each shall be given a stable +and unique string, with possible values documented in the driver specific +specification document. + +Value shall be a monotonically increasing number of nanoseconds the respective +GPU engine spent executing workloads belonging to this client. + +- drm-memory-: [KiB|MiB] + +Each possible memory type which can be used to store buffer objects by the +GPU in question shall be given a stable and unique name to be returned as the +string here. + +Value shall reflect the amount of storage currently consumed by the buffer +object belong to this client, in the respective memory region. + +Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB' +indicating kibi- or mebi-bytes. + +=== +Driver specific implementations +=== + +:ref:`i915-usage-stats` diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 204ebdaadb45..2bfd2441576e 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -701,3 +701,30 @@ The style guide for ``i915_reg.h``. .. kernel-doc:: drivers/gpu/drm/i915/i915_reg.h :doc: The
[PATCH 6/8] drm/i915: Track context current active time
From: Tvrtko Ursulin
Track context active (on hardware) status together with the start
timestamp.
This will be used to provide better granularity of context
runtime reporting in conjunction with already tracked pphwsp accumulated
runtime.
The latter is only updated on context save so does not give us visibility
to any currently executing work.
As part of the patch the existing runtime tracking data is moved under the
new ce->stats member and updated under the seqlock. This provides the
ability to atomically read out accumulated plus active runtime.
v2:
* Rename and make __intel_context_get_active_time unlocked.
v3:
* Use GRAPHICS_VER.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamsetty # v1
Reviewed-by: Chris Wilson
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.c | 27 ++-
drivers/gpu/drm/i915/gt/intel_context.h | 15 ---
drivers/gpu/drm/i915/gt/intel_context_types.h | 24 +++--
.../drm/i915/gt/intel_execlists_submission.c | 23
.../gpu/drm/i915/gt/intel_gt_clock_utils.c| 4 +++
drivers/gpu/drm/i915/gt/intel_lrc.c | 27 ++-
drivers/gpu/drm/i915/gt/intel_lrc.h | 24 +
drivers/gpu/drm/i915/gt/selftest_lrc.c| 10 +++
drivers/gpu/drm/i915/i915_gpu_error.c | 9 +++
drivers/gpu/drm/i915/i915_gpu_error.h | 2 +-
10 files changed, 116 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index bd63813c8a80..06816690ffc7 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -374,7 +374,7 @@ intel_context_init(struct intel_context *ce, struct
intel_engine_cs *engine)
ce->ring = NULL;
ce->ring_size = SZ_4K;
- ewma_runtime_init(&ce->runtime.avg);
+ ewma_runtime_init(&ce->stats.runtime.avg);
ce->vm = i915_vm_get(engine->gt->vm);
@@ -500,6 +500,31 @@ struct i915_request *intel_context_create_request(struct
intel_context *ce)
return rq;
}
+u64 intel_context_get_total_runtime_ns(const struct intel_context *ce)
+{
+ u64 total, active;
+
+ total = ce->stats.runtime.total;
+ if (ce->ops->flags & COPS_RUNTIME_CYCLES)
+ total *= ce->engine->gt->clock_period_ns;
+
+ active = READ_ONCE(ce->stats.active);
+ if (active)
+ active = intel_context_clock() - active;
+
+ return total + active;
+}
+
+u64 intel_context_get_avg_runtime_ns(struct intel_context *ce)
+{
+ u64 avg = ewma_runtime_read(&ce->stats.runtime.avg);
+
+ if (ce->ops->flags & COPS_RUNTIME_CYCLES)
+ avg *= ce->engine->gt->clock_period_ns;
+
+ return avg;
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftest_context.c"
#endif
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index b10cbe8fee99..093e2423e92b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -245,18 +245,13 @@ intel_context_clear_nopreempt(struct intel_context *ce)
clear_bit(CONTEXT_NOPREEMPT, &ce->flags);
}
-static inline u64 intel_context_get_total_runtime_ns(struct intel_context *ce)
-{
- const u32 period = ce->engine->gt->clock_period_ns;
-
- return READ_ONCE(ce->runtime.total) * period;
-}
+u64 intel_context_get_total_runtime_ns(const struct intel_context *ce);
+u64 intel_context_get_avg_runtime_ns(struct intel_context *ce);
-static inline u64 intel_context_get_avg_runtime_ns(struct intel_context *ce)
+static inline u64 intel_context_clock(void)
{
- const u32 period = ce->engine->gt->clock_period_ns;
-
- return mul_u32_u32(ewma_runtime_read(&ce->runtime.avg), period);
+ /* As we mix CS cycles with CPU clocks, use the raw monotonic clock. */
+ return ktime_get_raw_fast_ns();
}
#endif /* __INTEL_CONTEXT_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 90026c177105..9c68fda36c40 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -33,6 +33,9 @@ struct intel_context_ops {
#define COPS_HAS_INFLIGHT_BIT 0
#define COPS_HAS_INFLIGHT BIT(COPS_HAS_INFLIGHT_BIT)
+#define COPS_RUNTIME_CYCLES_BIT 1
+#define COPS_RUNTIME_CYCLES BIT(COPS_RUNTIME_CYCLES_BIT)
+
int (*alloc)(struct intel_context *ce);
int (*pre_pin)(struct intel_context *ce, struct i915_gem_ww_ctx *ww,
void **vaddr);
@@ -111,14 +114,19 @@ struct intel_context {
} lrc;
u32 tag; /* cookie passed to HW to track this context on submission */
- /* Time on GPU as tracked by the hw. */
- struct {
- struct ewma_runtime avg;
- u64 total;
- u32 last;
- I915_SELFTEST_DECLARE(u32 num_underflo
[RFC 7/8] drm/i915: Expose client engine utilisation via fdinfo
From: Tvrtko Ursulin
Similar to AMD commit
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for i915.
Example of the output:
pos:0
flags: 012
mnt_id: 21
drm-driver: i915
drm-pdev: :00:02.0
drm-client-id: 7
drm-engine-render: 9288864723 ns
drm-engine-copy:2035071108 ns
drm-engine-video: 0 ns
drm-engine-video-enhance: 0 ns
Signed-off-by: Tvrtko Ursulin
Cc: David M Nieto
Cc: Christian König
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drm_client.c | 73 ++
drivers/gpu/drm/i915/i915_drm_client.h | 4 ++
drivers/gpu/drm/i915/i915_drv.c| 3 ++
3 files changed, 80 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index 1e5db7753276..a8338ca19748 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -9,6 +9,11 @@
#include
+#include
+
+#include "gem/i915_gem_context.h"
+#include "gt/intel_engine_user.h"
+
#include "i915_drm_client.h"
#include "i915_drv.h"
#include "i915_gem.h"
@@ -168,3 +173,71 @@ void i915_drm_clients_fini(struct i915_drm_clients
*clients)
xa_destroy(&clients->xarray);
}
+
+#ifdef CONFIG_PROC_FS
+static const char * const uabi_class_names[] = {
+ [I915_ENGINE_CLASS_RENDER] = "render",
+ [I915_ENGINE_CLASS_COPY] = "copy",
+ [I915_ENGINE_CLASS_VIDEO] = "video",
+ [I915_ENGINE_CLASS_VIDEO_ENHANCE] = "video-enhance",
+};
+
+static u64 busy_add(struct i915_gem_context *ctx, unsigned int class)
+{
+ struct i915_gem_engines_iter it;
+ struct intel_context *ce;
+ u64 total = 0;
+
+ for_each_gem_engine(ce, rcu_dereference(ctx->engines), it) {
+ if (ce->engine->uabi_class != class)
+ continue;
+
+ total += intel_context_get_total_runtime_ns(ce);
+ }
+
+ return total;
+}
+
+static void
+show_client_class(struct seq_file *m,
+ struct i915_drm_client *client,
+ unsigned int class)
+{
+ const struct list_head *list = &client->ctx_list;
+ u64 total = atomic64_read(&client->past_runtime[class]);
+ struct i915_gem_context *ctx;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(ctx, list, client_link)
+ total += busy_add(ctx, class);
+ rcu_read_unlock();
+
+ return seq_printf(m, "drm-engine-%s:\t%llu ns\n",
+ uabi_class_names[class], total);
+}
+
+void i915_drm_client_fdinfo(struct seq_file *m, struct file *f)
+{
+ struct drm_file *file = f->private_data;
+ struct drm_i915_file_private *file_priv = file->driver_priv;
+ struct drm_i915_private *i915 = file_priv->dev_priv;
+ struct i915_drm_client *client = file_priv->client;
+ struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
+ unsigned int i;
+
+ seq_puts(m, "drm-driver:\ti915\n");
+ seq_printf(m, "drm-pdev:\t%04x:%02x:%02x.%d\n",
+ pci_domain_nr(pdev->bus), pdev->bus->number,
+ PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
+
+ seq_printf(m, "drm-client-id:\t%u\n", client->id);
+ rcu_read_lock();
+ seq_printf(m, "drm-client-name:\t%s\n", i915_drm_client_name(client));
+ seq_printf(m, "drm-client-pid:\t%u\n",
+ pid_nr(i915_drm_client_pid(client)));
+ rcu_read_unlock();
+
+ for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++)
+ show_client_class(m, client, i);
+}
+#endif
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
b/drivers/gpu/drm/i915/i915_drm_client.h
index b2b69d6985e4..9885002433a0 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -98,6 +98,10 @@ i915_drm_client_pid(const struct i915_drm_client *client)
return __i915_drm_client_name(client)->pid;
}
+#ifdef CONFIG_PROC_FS
+void i915_drm_client_fdinfo(struct seq_file *m, struct file *f);
+#endif
+
void i915_drm_clients_fini(struct i915_drm_clients *clients);
#endif /* !__I915_DRM_CLIENT_H__ */
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8247dcc7586e..17712a490378 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1706,6 +1706,9 @@ static const struct file_operations i915_driver_fops = {
.read = drm_read,
.compat_ioctl = i915_ioc32_compat_ioctl,
.llseek = noop_llseek,
+#ifdef CONFIG_PROC_FS
+ .show_fdinfo = i915_drm_client_fdinfo,
+#endif
};
static int
--
2.30.2
[PATCH v2] drm/vgem: Restore mmap functionality
Commit 375cca1cfeb5 ("drm/vgem: Implement mmap as GEM object function")
accidentally removed the actual mmap functionality from vgem. Restore
the original implementation by restoring the vm_pgoff in the mmap code.
Fixes access to unmapped memory:
[ 106.591744] BUG: KASAN: vmalloc-out-of-bounds in do_fault+0x38/0x480
[ 106.598154] Read of size 8 at addr c10c44a8 by task vgem_basic/1514
[ 106.605173]
[ 106.606678] CPU: 1 PID: 1514 Comm: vgem_basic Tainted: GE
5.13.0-1-default+ #990
[ 106.615535] Hardware name: Dell Inc. OptiPlex 9020/0N4YC8, BIOS A24
10/24/2018
[ 106.622818] Call Trace:
[ 106.625289] dump_stack+0xa5/0xdc
[ 106.628642] print_address_description.constprop.0+0x18/0x100
[ 106.634439] ? do_fault+0x38/0x480
[ 106.637872] kasan_report.cold+0x7c/0xd8
[ 106.641834] ? do_fault+0x38/0x480
[ 106.645274] do_fault+0x38/0x480
[ 106.648535] __handle_mm_fault+0x935/0xb00
[ 106.652676] ? vm_iomap_memory+0xe0/0xe0
[ 106.656634] ? __lock_release+0x12f/0x4e0
[ 106.660696] ? count_memcg_event_mm.part.0+0xb9/0x190
[ 106.665799] handle_mm_fault+0xd0/0x370
[ 106.669675] do_user_addr_fault+0x2a0/0x8c0
[ 106.673908] exc_page_fault+0x64/0xf0
[ 106.677604] ? asm_exc_page_fault+0x8/0x30
[ 106.681739] asm_exc_page_fault+0x1e/0x30
[ 106.685782] RIP: 0033:0x402e12
...
v2:
* restore vma.vm_pgoff instead of mapping the pages
Signed-off-by: Thomas Zimmermann
Fixes: 375cca1cfeb5 ("drm/vgem: Implement mmap as GEM object function")
Cc: Thomas Zimmermann
Cc: Christian König
Cc: Daniel Vetter
Cc: "Christian König"
Cc: Melissa Wen
Cc: Jason Gunthorpe
Cc: Gerd Hoffmann
Cc: Lee Jones
---
drivers/gpu/drm/vgem/vgem_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index df634aa52638..e92d1f2e02c4 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -364,8 +364,8 @@ static void vgem_prime_vunmap(struct drm_gem_object *obj,
struct dma_buf_map *ma
static int vgem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct
*vma)
{
- vma_set_file(vma, obj->filp);
- vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
+ vma->vm_pgoff -= drm_vma_node_start(&obj->vma_node);
+ vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
vma->vm_page_prot =
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
--
2.32.0
Aw: Re: [PATCH] soc: mediatek: mmsys: fix HDMI output on mt7623/bananapi-r2
> Gesendet: Montag, 12. Juli 2021 um 13:50 Uhr
> Von: "Dafna Hirschfeld"
> An: "Frank Wunderlich" , linux-media...@lists.infradead.org
> Cc: "Frank Wunderlich" , "Matthias Brugger"
> , "CK Hu" ,
> linux-arm-ker...@lists.infradead.org, linux-ker...@vger.kernel.org, "Enric
> Balletbo Serra" , "David Airlie" ,
> dri-devel@lists.freedesktop.org, "Daniel Vetter"
> Betreff: Re: [PATCH] soc: mediatek: mmsys: fix HDMI output on
> mt7623/bananapi-r2
>
> Hi
>
> On 10.07.21 15:24, Frank Wunderlich wrote:
> > From: Frank Wunderlich
> >
> > HDMI output was broken on mt7623/BPI-R2 in 5.13 because function for
> > special output selection (mtk_mmsys_ddp_sout_sel) was dropped.
> > This function wrote 3 registers at one time and so it is not compatible
> > with the array-approach.
> >
> > I re-added the old function and call this after the default routing table
> > was applied. This default routing table can still be used as the only
> > connection handled by mmsys on BPI-R2 is OVL0->RDMA0 and this is already
> > present in the default routing table
> >
> > Fixes: 440147639ac7 ("soc: mediatek: mmsys: Use an array for setting the
> > routing registers")
> > Signed-off-by: Frank Wunderlich
> > ---
> > drivers/soc/mediatek/mtk-mmsys.c | 21 +
> > 1 file changed, 21 insertions(+)
> >
> > diff --git a/drivers/soc/mediatek/mtk-mmsys.c
> > b/drivers/soc/mediatek/mtk-mmsys.c
> > index 080660ef11bf..f91b7fdd417a 100644
> > --- a/drivers/soc/mediatek/mtk-mmsys.c
> > +++ b/drivers/soc/mediatek/mtk-mmsys.c
> > @@ -57,6 +57,25 @@ struct mtk_mmsys {
> > const struct mtk_mmsys_driver_data *data;
> > };
> >
> > +static void mtk_mmsys_ddp_sout_sel(struct device *dev,
> > + enum mtk_ddp_comp_id cur,
> > + enum mtk_ddp_comp_id next)
> > +{
> > + struct mtk_mmsys *mmsys = dev_get_drvdata(dev);
> > +
> > + if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) {
> > + writel_relaxed(BLS_TO_DSI_RDMA1_TO_DPI1,
> > + mmsys->regs + DISP_REG_CONFIG_OUT_SEL);
> > + } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
> > + writel_relaxed(BLS_TO_DPI_RDMA1_TO_DSI,
> > + mmsys->regs + DISP_REG_CONFIG_OUT_SEL);
> > + writel_relaxed(DSI_SEL_IN_RDMA,
> > + mmsys->regs + DISP_REG_CONFIG_DSI_SEL);
> > + writel_relaxed(DPI_SEL_IN_BLS,
> > + mmsys->regs + DISP_REG_CONFIG_DPI_SEL);
>
> you can still use the array approach for this like that:
>
> {
> DDP_COMPONENT_BLS, DDP_COMPONENT_DSI0,
> DISP_REG_CONFIG_OUT_SEL, BLS_TO_DSI_RDMA1_TO_DPI1
> }, {
> {
> DDP_COMPONENT_BLS, DDP_COMPONENT_DPI0,
> DISP_REG_CONFIG_OUT_SEL, BLS_TO_DPI_RDMA1_TO_DSI
> }, {
> {
> DDP_COMPONENT_BLS, DDP_COMPONENT_DPI0,
> DISP_REG_CONFIG_DSI_SEL, DSI_SEL_IN_RDMA
> }, {
> {
> DDP_COMPONENT_BLS, DDP_COMPONENT_DPI0,
> DISP_REG_CONFIG_DPI_SEL, DPI_SEL_IN_BLS
> }, {
>
>
> Thanks,
> Dafna
these 4 blocks are already there (except your additional brackets) and it does
not work with them (not added in 5.14)
91 static const struct mtk_mmsys_routes mmsys_default_routing_table[] = {
92 {
93 DDP_COMPONENT_BLS, DDP_COMPONENT_DSI0,
94 DISP_REG_CONFIG_OUT_SEL, BLS_TO_DSI_RDMA1_TO_DPI1 //(1)
95 }, {
96 DDP_COMPONENT_BLS, DDP_COMPONENT_DSI0,
97 DISP_REG_CONFIG_DSI_SEL, DSI_SEL_IN_BLS
98 }, {
99 DDP_COMPONENT_BLS, DDP_COMPONENT_DPI0,
100 DISP_REG_CONFIG_OUT_SEL, BLS_TO_DPI_RDMA1_TO_DSI //(2)
101 }, {
102 DDP_COMPONENT_BLS, DDP_COMPONENT_DPI0,
103 DISP_REG_CONFIG_DSI_SEL, DSI_SEL_IN_RDMA //(3)
104 }, {
105 DDP_COMPONENT_BLS, DDP_COMPONENT_DPI0,
106 DISP_REG_CONFIG_DPI_SEL, DPI_SEL_IN_BLS //(4)
107 }, {
and code should apply all matching parts (2-4 for BLS=>dpi), but it does not
work...maybe because new code reads and OR the new value instead of writing it
(old code overwrites current register value with the new value without reading)
69 for (i = 0; i < mmsys->data->num_routes; i++)
70 if (cur == routes[i].from_comp && next == routes[i].to_comp) {
71 reg = readl_relaxed(mmsys->regs + routes[i].addr) |
routes[i].val; //<<<
72 writel_relaxed(reg, mmsys->regs + routes[i].addr);
73 }
regards Frank
Re: [PATCH 0/4] vkms: Switch to shadow-buffered plane state
Hi Am 12.07.21 um 13:56 schrieb Sumera Priyadarsini: On Mon, Jul 5, 2021 at 1:16 PM Thomas Zimmermann wrote: Vkms copies each plane's framebuffer into the output buffer; essentially using a shadow buffer. DRM provides struct drm_shadow_plane_state, which handles the details of mapping/unmapping shadow buffers into memory for active planes. Convert vkms to the helpers. Makes vkms use shared code and gives more test exposure to shadow-plane helpers. Thomas Zimmermann (4): drm/gem: Export implementation of shadow-plane helpers drm/vkms: Inherit plane state from struct drm_shadow_plane_state drm/vkms: Let shadow-plane helpers prepare the plane's FB drm/vkms: Use dma-buf mapping from shadow-plane state for composing drivers/gpu/drm/drm_gem_atomic_helper.c | 55 ++-- drivers/gpu/drm/vkms/vkms_composer.c| 26 ++- drivers/gpu/drm/vkms/vkms_drv.h | 6 ++- drivers/gpu/drm/vkms/vkms_plane.c | 57 ++--- include/drm/drm_gem_atomic_helper.h | 6 +++ 5 files changed, 86 insertions(+), 64 deletions(-) base-commit: 3d3b5479895dd6dd133571ded4318adf595708ba -- 2.32.0 Hi, Thanks for the patches. The switch to shadow-plane helpers also solved a bug that was causing a kernel panic during some IGT kms_flip subtests on the vkms virtual hw patch. Melissa mention something like that as well and I don't really understand. Patch 3 removes an error message from the code, but is the actual bug also gone? There's little difference between vkms' original code and the shared helper; except for the order of operations in prepare_fb. The shared helper synchronizes fences before mapping; vkms mapped first. (Maybe the shared helper should warn about failed vmaps as well. But that's for another patch.) Best regards Thomas Tested-by: Sumera Priyadarsini Cheers, Sumera -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH 01/12] drm/mgag200: Select clock in PLL update functions
Hi
Am 09.07.21 um 20:50 schrieb Sam Ravnborg:
Hi Thomas,
On Mon, Jul 05, 2021 at 02:45:04PM +0200, Thomas Zimmermann wrote:
Put the clock-selection code into each of the PLL-update functions to
make them select the correct pixel clock.
The pixel clock for video output was not actually set before programming
the clock's values. It worked because the device had the correct clock
pre-set.
Signed-off-by: Thomas Zimmermann
Fixes: db05f8d3dc87 ("drm/mgag200: Split MISC register update into PLL selection,
SYNC and I/O")
Cc: Sam Ravnborg
Cc: Emil Velikov
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.9+
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 47 --
1 file changed, 37 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 3b3059f471c2..482843ebb69f 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -130,6 +130,7 @@ static int mgag200_g200_set_plls(struct mga_device *mdev,
long clock)
long ref_clk = mdev->model.g200.ref_clk;
long p_clk_min = mdev->model.g200.pclk_min;
long p_clk_max = mdev->model.g200.pclk_max;
+ u8 misc;
if (clock > p_clk_max) {
drm_err(dev, "Pixel Clock %ld too high\n", clock);
@@ -174,6 +175,11 @@ static int mgag200_g200_set_plls(struct mga_device *mdev,
long clock)
drm_dbg_kms(dev, "clock: %ld vco: %ld m: %d n: %d p: %d s: %d\n",
clock, f_vco, m, n, p, s);
+ misc = RREG8(MGA_MISC_IN);
+ misc &= ~MGAREG_MISC_CLK_SEL_MASK;
+ misc |= MGAREG_MISC_CLK_SEL_MGA_MSK;
+ WREG8(MGA_MISC_OUT, misc);
This chunk is repeated a number of times.
Any good reason why this is not a small helper?
Good point. I'll make a helper from this.
Best regards
Thomas
Sam
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH] dma-buf/sync_file: Don't leak fences on merge failure
No worries. Thanks for pushing!
On Mon, Jul 12, 2021 at 6:37 AM Christian König
wrote:
>
> Sorry for the vacation and sick leave induced delay.
>
> I've just pushed this to drm-misc-fixes.
>
> Thanks,
> Christian.
>
> Am 24.06.21 um 21:43 schrieb Jason Ekstrand:
> > I don't have drm-misc access. Mind pushing?
> >
> > On Thu, Jun 24, 2021 at 12:59 PM Christian König
> > wrote:
> >> Am 24.06.21 um 19:47 schrieb Jason Ekstrand:
> >>> Each add_fence() call does a dma_fence_get() on the relevant fence. In
> >>> the error path, we weren't calling dma_fence_put() so all those fences
> >>> got leaked. Also, in the krealloc_array failure case, we weren't
> >>> freeing the fences array. Instead, ensure that i and fences are always
> >>> zero-initialized and dma_fence_put() all the fences and kfree(fences) on
> >>> every error path.
> >>>
> >>> Signed-off-by: Jason Ekstrand
> >>> Fixes: a02b9dc90d84 ("dma-buf/sync_file: refactor fence storage in struct
> >>> sync_file")
> >>> Cc: Gustavo Padovan
> >>> Cc: Christian König
> >> Reviewed-by: Christian König
> >>
> >>> ---
> >>>drivers/dma-buf/sync_file.c | 13 +++--
> >>>1 file changed, 7 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> >>> index 20d9bddbb985b..394e6e1e96860 100644
> >>> --- a/drivers/dma-buf/sync_file.c
> >>> +++ b/drivers/dma-buf/sync_file.c
> >>> @@ -211,8 +211,8 @@ static struct sync_file *sync_file_merge(const char
> >>> *name, struct sync_file *a,
> >>> struct sync_file *b)
> >>>{
> >>>struct sync_file *sync_file;
> >>> - struct dma_fence **fences, **nfences, **a_fences, **b_fences;
> >>> - int i, i_a, i_b, num_fences, a_num_fences, b_num_fences;
> >>> + struct dma_fence **fences = NULL, **nfences, **a_fences, **b_fences;
> >>> + int i = 0, i_a, i_b, num_fences, a_num_fences, b_num_fences;
> >>>
> >>>sync_file = sync_file_alloc();
> >>>if (!sync_file)
> >>> @@ -236,7 +236,7 @@ static struct sync_file *sync_file_merge(const char
> >>> *name, struct sync_file *a,
> >>> * If a sync_file can only be created with sync_file_merge
> >>> * and sync_file_create, this is a reasonable assumption.
> >>> */
> >>> - for (i = i_a = i_b = 0; i_a < a_num_fences && i_b < b_num_fences; )
> >>> {
> >>> + for (i_a = i_b = 0; i_a < a_num_fences && i_b < b_num_fences; ) {
> >>>struct dma_fence *pt_a = a_fences[i_a];
> >>>struct dma_fence *pt_b = b_fences[i_b];
> >>>
> >>> @@ -277,15 +277,16 @@ static struct sync_file *sync_file_merge(const char
> >>> *name, struct sync_file *a,
> >>>fences = nfences;
> >>>}
> >>>
> >>> - if (sync_file_set_fence(sync_file, fences, i) < 0) {
> >>> - kfree(fences);
> >>> + if (sync_file_set_fence(sync_file, fences, i) < 0)
> >>>goto err;
> >>> - }
> >>>
> >>>strlcpy(sync_file->user_name, name, sizeof(sync_file->user_name));
> >>>return sync_file;
> >>>
> >>>err:
> >>> + while (i)
> >>> + dma_fence_put(fences[--i]);
> >>> + kfree(fences);
> >>>fput(sync_file->file);
> >>>return NULL;
> >>>
>
Re: [v8 1/6] drm/panel: add basic DP AUX backlight support
Hi, On Mon, Jul 12, 2021 at 2:41 AM Thomas Zimmermann wrote: > > > + ret = drm_dp_dpcd_read(aux, DP_EDP_DPCD_REV, edp_dpcd, > > +EDP_DISPLAY_CTL_CAP_SIZE); > > This creates a cyclic dependency between drm_kms_helper-ko and drm.ko. > drm_panel.c is in the latter, while drm_dp_dpcd_read() in > drm_dp_helper.c is in the former. Please fix. Yeah, this was reported Friday and I posted a patch to try to fix it: https://lore.kernel.org/lkml/20210709152909.1.I23eb4cc5a680341e7b3e791632a635566fa5806a@changeid/ I see Rajeev had some feedback on it. Once I've dug out of my weekend email hole I'll take a look at plan to post a v2 ASAP. -Doug
Re: [PATCH 02/12] drm/mgag200: Return errno codes from PLL compute functions
Hi
Am 09.07.21 um 20:53 schrieb Sam Ravnborg:
On Mon, Jul 05, 2021 at 02:45:05PM +0200, Thomas Zimmermann wrote:
Return -EINVAL if there's no PLL configuration for the given pixel
clock.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 482843ebb69f..045a20055515 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -134,7 +134,7 @@ static int mgag200_g200_set_plls(struct mga_device *mdev,
long clock)
if (clock > p_clk_max) {
drm_err(dev, "Pixel Clock %ld too high\n", clock);
- return 1;
+ return -EINVAL;
}
if (clock < p_clk_min >> 3)
@@ -293,7 +293,7 @@ static int mga_g200se_set_plls(struct mga_device *mdev,
long clock)
if (delta > permitteddelta) {
pr_warn("PLL delta too large\n");
- return 1;
+ return -EINVAL;
}
misc = RREG8(MGA_MISC_IN);
The return value is ignored but I assume it makes sense in a later
patch. Should mgag200_crtc_set_plls() return -EINVAL if there was no
match? Today it returns 0 - which is not an error.
Indeed. Patch 12 moves some of this functionality into the atomic check,
where it will be tested for success.
Not handling the type in the switch is actually a driver bug. I'll see
if I can add a rsp error in one of the patches.
Best regards
Thomas
Sam
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
Re: [Intel-gfx] [PATCH v2] drm/i915: Add TTM offset argument to mmap.
On Fri, Jul 9, 2021 at 6:41 AM Maarten Lankhorst
wrote:
>
> This is only used for ttm, and tells userspace that the mapping type is
> ignored. This disables the other type of mmap offsets when discrete
> memory is used, so fix the selftests as well.
>
> Document the struct as well, so it shows up in docbook correctly.
>
> Changes since v1:
> - Add docbook entries.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 17 ++-
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
> .../drm/i915/gem/selftests/i915_gem_mman.c| 27 +-
> include/uapi/drm/i915_drm.h | 51 +++
> 4 files changed, 82 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index a90f796e85c0..b34be9e5d094 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -679,10 +679,16 @@ __assign_mmap_offset(struct drm_i915_gem_object *obj,
> return -ENODEV;
>
> if (obj->ops->mmap_offset) {
> + if (mmap_type != I915_MMAP_TYPE_TTM)
> + return -ENODEV;
> +
> *offset = obj->ops->mmap_offset(obj);
> return 0;
> }
>
> + if (mmap_type == I915_MMAP_TYPE_TTM)
> + return -ENODEV;
> +
> if (mmap_type != I915_MMAP_TYPE_GTT &&
> !i915_gem_object_has_struct_page(obj) &&
> !i915_gem_object_has_iomem(obj))
> @@ -727,7 +733,9 @@ i915_gem_dumb_mmap_offset(struct drm_file *file,
> {
> enum i915_mmap_type mmap_type;
>
> - if (boot_cpu_has(X86_FEATURE_PAT))
> + if (HAS_LMEM(to_i915(dev)))
> + mmap_type = I915_MMAP_TYPE_TTM;
> + else if (boot_cpu_has(X86_FEATURE_PAT))
> mmap_type = I915_MMAP_TYPE_WC;
> else if (!i915_ggtt_has_aperture(&to_i915(dev)->ggtt))
> return -ENODEV;
> @@ -798,6 +806,10 @@ i915_gem_mmap_offset_ioctl(struct drm_device *dev, void
> *data,
> type = I915_MMAP_TYPE_UC;
> break;
>
> + case I915_MMAP_OFFSET_TTM:
> + type = I915_MMAP_TYPE_TTM;
> + break;
> +
> default:
> return -EINVAL;
> }
> @@ -968,6 +980,9 @@ int i915_gem_mmap(struct file *filp, struct
> vm_area_struct *vma)
> vma->vm_ops = &vm_ops_cpu;
> break;
>
> + case I915_MMAP_TYPE_TTM:
> + GEM_WARN_ON(mmo->mmap_type == I915_MMAP_TYPE_TTM);
> + /* fall-through */
> case I915_MMAP_TYPE_WB:
> vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
> vma->vm_ops = &vm_ops_cpu;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> index ef3de2ae9723..d4c42bcdfeb6 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> @@ -105,6 +105,7 @@ enum i915_mmap_type {
> I915_MMAP_TYPE_WC,
> I915_MMAP_TYPE_WB,
> I915_MMAP_TYPE_UC,
> + I915_MMAP_TYPE_TTM,
> };
>
> struct i915_mmap_offset {
> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> index 1da8bd675e54..27a35d88e5f5 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> @@ -573,6 +573,14 @@ static int make_obj_busy(struct drm_i915_gem_object *obj)
> return 0;
> }
>
> +static enum i915_mmap_type default_mapping(struct drm_i915_private *i915)
> +{
> + if (HAS_LMEM(i915))
> + return I915_MMAP_TYPE_TTM;
> +
> + return I915_MMAP_TYPE_GTT;
> +}
> +
> static bool assert_mmap_offset(struct drm_i915_private *i915,
>unsigned long size,
>int expected)
> @@ -585,7 +593,7 @@ static bool assert_mmap_offset(struct drm_i915_private
> *i915,
> if (IS_ERR(obj))
> return expected && expected == PTR_ERR(obj);
>
> - ret = __assign_mmap_offset(obj, I915_MMAP_TYPE_GTT, &offset, NULL);
> + ret = __assign_mmap_offset(obj, default_mapping(i915), &offset, NULL);
> i915_gem_object_put(obj);
>
> return ret == expected;
> @@ -689,7 +697,7 @@ static int igt_mmap_offset_exhaustion(void *arg)
> goto out;
> }
>
> - err = __assign_mmap_offset(obj, I915_MMAP_TYPE_GTT, &offset, NULL);
> + err = __assign_mmap_offset(obj, default_mapping(i915), &offset, NULL);
> if (err) {
> pr_err("Unable to insert object into reclaimed hole\n");
> goto err_obj;
> @@ -831,8 +839,14 @@ static int wc_check(struct drm_i915_gem_object *obj)
>
> static bool can_mmap(struct drm_i915_gem_object *obj, enum i915_mmap_type
> ty
Re: [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
On Tue, Jul 06, 2021 at 12:59:57PM -0400, Konrad Rzeszutek Wilk wrote: > On Tue, Jul 06, 2021 at 05:57:21PM +0100, Will Deacon wrote: > > On Tue, Jul 06, 2021 at 10:46:07AM -0400, Konrad Rzeszutek Wilk wrote: > > > On Tue, Jul 06, 2021 at 04:05:13PM +0200, Christoph Hellwig wrote: > > > > On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote: > > > > > FWIW I was pondering the question of whether to do something along > > > > > those > > > > > lines or just scrap the default assignment entirely, so since I > > > > > hadn't got > > > > > round to saying that I've gone ahead and hacked up the alternative > > > > > (similarly untested) for comparison :) > > > > > > > > > > TBH I'm still not sure which one I prefer... > > > > > > > > Claire did implement something like your suggestion originally, but > > > > I don't really like it as it doesn't scale for adding multiple global > > > > pools, e.g. for the 64-bit addressable one for the various encrypted > > > > secure guest schemes. > > > > > > Couple of things: > > > - I am not pushing to Linus the Claire's patchset until we have a > > >resolution on this. I hope you all agree that is a sensible way > > >forward as much as I hate doing that. > > > > Sure, it's a pity but we could clearly use a bit more time to get these > > just right and we've run out of time for 5.14. > > > > I think the main question I have is how would you like to see patches for > > 5.15? i.e. as patches on top of devel/for-linus-5.14 or something else? > > Yes that would be perfect. If there are any dependencies on the rc1, I > can rebase it on top of that. Yes, please, rebasing would be very helpful. The broader rework of 'io_tlb_default_mem' is going to conflict quite badly otherwise. Cheers, Will
Re: [PATCH 04/12] drm/mgag200: Split PLL setup into compute and update functions
Hi
Am 09.07.21 um 21:12 schrieb Sam Ravnborg:
Ho Thomas,
On Mon, Jul 05, 2021 at 02:45:07PM +0200, Thomas Zimmermann wrote:
The _set_plls() functions compute a pixel clock's PLL values
and program the hardware accordingly. This happens during atomic
commits.
For atomic modesetting, it's better to separate computation and
programming from each other. This will allow to compute the PLL
value during atomic checks and catch unsupported modes early.
Split the PLL setup into a compute and a update functions, and
call them one after the other. Computed PLL values are store in
struct mgag200_pll_values. No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_drv.h | 17 ++
drivers/gpu/drm/mgag200/mgag200_mode.c | 234 +++--
2 files changed, 196 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h
b/drivers/gpu/drm/mgag200/mgag200_drv.h
index f7a0537c0d0a..fca3904fde0c 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.h
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
@@ -110,6 +110,23 @@
#define MGAG200_MAX_FB_HEIGHT 4096
#define MGAG200_MAX_FB_WIDTH 4096
+/*
+ * Stores parameters for programming the PLLs
+ *
+ * Fref: reference frequency (A: 25.175 Mhz, B: 28.361, C: XX Mhz)
+ * Fo: output frequency
+ * Fvco = Fref * (N / M)
+ * Fo = Fvco / P
+ *
+ * S = [0..3]
+ */
+struct mgag200_pll_values {
+ unsigned int m;
Why not u8?
+ unsigned int n;
Why not u8?
+ unsigned int p;
Why not u8?
+ unsigned int s;
+};
First of all, thanks for going through these changes. The current code
is nightmarish. So patch 4 and later is where the fun happens. :)
These fields are supposed to be values as used by the function that
controls the PLL's output frequency; so they are unsigned int. u8 would
be for in-register values; which can be different.
The MGA manual explains how to program this.
https://manualzz.com/viewer_next/web/manual?file=%2F%2Fs3p.manualzz.com%2Fstore%2Fdata%2F024667257.pdf%3Fk%3DEwAAAXqa--YRAAACWCABFrit5RcAiDXxvUVLzg4j6q39p78ki8fJxGpPn7F6&img=%2F%2Fs3.manualzz.com%2Fstore%2Fdata%2F024667257_1-acc0a233d724738660be61a3ba8e1135&ads=true#G10.1092838
Apparently, there's one way of doing this. And still each hardware
revision manages to require it's own code.
+
#define to_mga_connector(x) container_of(x, struct mga_connector, base)
struct mga_i2c_chan {
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index fa06f1994d68..961bd128fea3 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -114,7 +114,8 @@ static inline void mga_wait_busy(struct mga_device *mdev)
* PLL setup
*/
-static int mgag200_g200_set_plls(struct mga_device *mdev, long clock)
+static int mgag200_compute_pixpll_values_g200(struct mga_device *mdev, long
clock,
+ struct mgag200_pll_values
*pixpllc)
{
struct drm_device *dev = &mdev->base;
const int post_div_max = 7;
@@ -130,7 +131,6 @@ static int mgag200_g200_set_plls(struct mga_device *mdev,
long clock)
long ref_clk = mdev->model.g200.ref_clk;
long p_clk_min = mdev->model.g200.pclk_min;
long p_clk_max = mdev->model.g200.pclk_max;
- u8 misc;
if (clock > p_clk_max) {
drm_err(dev, "Pixel Clock %ld too high\n", clock);
@@ -175,19 +175,34 @@ static int mgag200_g200_set_plls(struct mga_device *mdev,
long clock)
drm_dbg_kms(dev, "clock: %ld vco: %ld m: %d n: %d p: %d s: %d\n",
clock, f_vco, m, n, p, s);
+ pixpllc->m = m;
+ pixpllc->n = n;
+ pixpllc->p = p;
+ pixpllc->s = s;
+
+ return 0;
+}
+
+static void mgag200_set_pixpll_g200(struct mga_device *mdev,
+ const struct mgag200_pll_values *pixpllc)
+{
+ u8 misc, xpixpllcm, xpixpllcn, xpixpllcp;
Strange names, but whatever.
Those are the names of the registers; as used in the MGA manual. I try
to use official names wherever possible. Others can then read the code
and grep the register manual for the names.
Note that xpixpllcp stores p and s; so it's not a 1-1 relationship with
the values in struct mageg200_pll_values.
+
misc = RREG8(MGA_MISC_IN);
misc &= ~MGAREG_MISC_CLK_SEL_MASK;
misc |= MGAREG_MISC_CLK_SEL_MGA_MSK;
WREG8(MGA_MISC_OUT, misc);
- WREG_DAC(MGA1064_PIX_PLLC_M, m);
- WREG_DAC(MGA1064_PIX_PLLC_N, n);
- WREG_DAC(MGA1064_PIX_PLLC_P, (p | (s << 3)));
-
- return 0;
+ xpixpllcm = pixpllc->m;
+ xpixpllcn = pixpllc->n;
+ xpixpllcp = pixpllc->p | (pixpllc->s << 3);
+ WREG_DAC(MGA1064_PIX_PLLC_M, xpixpllcm);
+ WREG_DAC(MGA1064_PIX_PLLC_N, xpixpllcn);
+ WREG_DAC(MGA1064_PIX_PLLC_P, xpixpllcp);
I cannot see why this code does not look like this:
WREG_DAC(MGA1064_PIX_PLLC_M, pixpllc->m);
Re: [PATCH v5] Documentation: gpu: Mention the requirements for new properties
On Fri, Jul 09, 2021 at 12:08:14PM +0300, Pekka Paalanen wrote: > On Fri, 9 Jul 2021 10:02:28 +0200 > Daniel Vetter wrote: > > > On Fri, Jul 09, 2021 at 10:24:44AM +0300, Pekka Paalanen wrote: > > > On Tue, 6 Jul 2021 18:12:44 +0200 > > > Maxime Ripard wrote: > > > > > > > New KMS properties come with a bunch of requirements to avoid each > > > > driver from running their own, inconsistent, set of properties, > > > > eventually leading to issues like property conflicts, inconsistencies > > > > between drivers and semantics, etc. > > > > > > > > Let's document what we expect. > > > > > > ... > > > > > > > Changes from v4: > > > > - Changes suggested by Pekka > > > > > > > > Changes from v3: > > > > - Roll back to the v2 > > > > - Add Simon and Pekka in Cc > > > > > > > > Changes from v2: > > > > - Take into account the feedback from Laurent and Lidiu to no longer > > > > force generic properties, but prefix vendor-specific properties with > > > > the vendor name > > > > > > > > Changes from v1: > > > > - Typos and wording reported by Daniel and Alex > > > > --- > > > > Documentation/gpu/drm-kms.rst | 30 ++ > > > > 1 file changed, 30 insertions(+) > > > > > > > > diff --git a/Documentation/gpu/drm-kms.rst > > > > b/Documentation/gpu/drm-kms.rst > > > > index 87e5023e3f55..47994890fd1e 100644 > > > > --- a/Documentation/gpu/drm-kms.rst > > > > +++ b/Documentation/gpu/drm-kms.rst > > > > @@ -463,6 +463,36 @@ KMS Properties > > > > This section of the documentation is primarily aimed at user-space > > > > developers. > > > > For the driver APIs, see the other sections. > > > > > > > > +Requirements > > > > + > > > > + > > > > +KMS drivers might need to add extra properties to support new features. > > > > +Each new property introduced in a driver need to meet a few > > > > +requirements, in addition to the one mentioned above: > > > > + > > > > +* It must be standardized, documenting: > > > > + > > > > + * The full, exact, name string; > > > > + * If the property is an enum, all the valid variants name; > > > > > > Hi, > > > > > > "variant" feels a little off to me, I would have used "value name > > > strings". > > > > > > > + * What values are accepted, and what these values mean; > > > > + * What the property does and how it can be used; > > > > + * How the property might interact with other, existing properties. > > > > + > > > > +* It must provide a generic helper in the core code to register that > > > > + property on the object it attaches to. > > > > + > > > > +* Its content must be decoded by the core and provided in the object's > > > > + associated state structure. That includes anything drivers might want > > > > + to precompute, like :c:type:`struct drm_clip_rect ` > > > > for > > > > + planes. > > > > + > > > > +* Its initial state must match the behavior prior to the property > > > > + introduction. This might be a fixed value matching what the hardware > > > > + does, or it may be inherited from the state the firmware left the > > > > + system in during boot. > > > > > > I'd like to point out that this rule should apply also to > > > properties that already exist in general, but are newly exposed in a > > > driver for hardware that didn't expose the property before. > > > > I think we should just make this a very strong recommendation, and in > > general encourage people to use the tests against their driver? > > > > Otherwise a small "I'll just enable this" thing can become a huge project. > > And in general I think grandfathering existing things in is the pragmatic > > choice. > > > > But maybe that could be a follow-up patch? > > Sure, I don't mind. Just saying now that it came to mind. Drivers do > not arbitrarily change behaviour without exposing more properties > either, right? Yup. Both are covered under the "no regressions" rule, but better to make this explicit. Maybe we should replicate some of the key bits in the property docs for drivers? Also anytime we spot an issue we need to improve the internal helpers to make sure things stay consistent. -Daniel > > > Thanks, > pq > > > > -Daniel > > > > > > > > > + > > > > +* An IGT test must be submitted where reasonable. > > > > + > > > > Property Types and Blob Property Support > > > > > > > > > > > > > > Regardless of my comments above: > > > > > > Reviewed-by: Pekka Paalanen > > > > > > > > > Thanks, > > > pq > > > > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH 06/12] drm/mgag200: Store values (not bits) in struct mgag200_pll_values
Hi
Am 10.07.21 um 09:06 schrieb Sam Ravnborg:
Hi Thomas,
On Mon, Jul 05, 2021 at 02:45:09PM +0200, Thomas Zimmermann wrote:
The fields in struct mgag200_pll_values currently hold the bits of
each register. Store the PLL values instead and let the PLL-update
code figure out the bits for each register.
Signed-off-by: Thomas Zimmermann
I gave up trying to follow the changes in this patch.
I cannot blame you.
Also I was left with the impression that this was no win in readability
at it looks to me like changes with a high risk to introduce a
hard-to-find bug.
Your changelog did not justify why this change is a win, only what is
does. But whatever works better for you I guess..
As I mention, struct mgag200_pll_values should store the PLL values. But
the individual compute and set functions for each hardware revision mess
this up completely. Sometimes they use 'function values' sometimes they
use 'register values'. If you'd try to debug a failed modeset operation
and have to look at the PLL, the stored values would be meaningless,
because there's simply no logic behind it.
The purpose of this patch is to make all compute functions store
function values in the struct and make all update function compute the
register values internally.
Do you think the change would be easier to understand if I change the
original _set_plls() functions *before* splitting them into compute and
update steps?
Best regards
Thomas
Sam
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 153 +++--
1 file changed, 91 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 9f6fe7673674..7d6707bd6c27 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -123,7 +123,7 @@ static int mgag200_compute_pixpll_values_g200(struct
mga_device *mdev, long cloc
const int in_div_max = 6;
const int feed_div_min = 7;
const int feed_div_max = 127;
- u8 testm, testn;
+ u8 testp, testm, testn;
u8 n = 0, m = 0, p, s;
long f_vco;
long computed;
@@ -141,10 +141,11 @@ static int mgag200_compute_pixpll_values_g200(struct
mga_device *mdev, long cloc
clock = p_clk_min >> 3;
f_vco = clock;
- for (p = 0;
-p <= post_div_max && f_vco < p_clk_min;
-p = (p << 1) + 1, f_vco <<= 1)
+ for (testp = 0;
+testp <= post_div_max && f_vco < p_clk_min;
+testp = (testp << 1) + 1, f_vco <<= 1)
;
+ p = testp + 1;
delta = clock;
@@ -157,12 +158,12 @@ static int mgag200_compute_pixpll_values_g200(struct mga_device *mdev, long cloc
tmp_delta = computed - f_vco;
if (tmp_delta < delta) {
delta = tmp_delta;
- m = testm;
- n = testn;
+ m = testm + 1;
+ n = testn + 1;
}
}
}
- f_vco = ref_clk * (n + 1) / (m + 1);
+ f_vco = ref_clk * n / m;
if (f_vco < 10)
s = 0;
else if (f_vco < 14)
@@ -186,6 +187,7 @@ static int mgag200_compute_pixpll_values_g200(struct
mga_device *mdev, long cloc
static void mgag200_set_pixpll_g200(struct mga_device *mdev,
const struct mgag200_pll_values *pixpllc)
{
+ unsigned int pixpllcm, pixpllcn, pixpllcp, pixpllcs;
u8 misc, xpixpllcm, xpixpllcn, xpixpllcp;
misc = RREG8(MGA_MISC_IN);
@@ -193,9 +195,14 @@ static void mgag200_set_pixpll_g200(struct mga_device
*mdev,
misc |= MGAREG_MISC_CLK_SEL_MGA_MSK;
WREG8(MGA_MISC_OUT, misc);
- xpixpllcm = pixpllc->m;
- xpixpllcn = pixpllc->n;
- xpixpllcp = pixpllc->p | (pixpllc->s << 3);
+ pixpllcm = pixpllc->m - 1;
+ pixpllcn = pixpllc->n - 1;
+ pixpllcp = pixpllc->p - 1;
+ pixpllcs = pixpllc->s;
+
+ xpixpllcm = pixpllcm;
+ xpixpllcn = pixpllcn;
+ xpixpllcp = (pixpllcs << 3) | pixpllcp;
WREG_DAC(MGA1064_PIX_PLLC_M, xpixpllcm);
WREG_DAC(MGA1064_PIX_PLLC_N, xpixpllcn);
WREG_DAC(MGA1064_PIX_PLLC_P, xpixpllcp);
@@ -240,9 +247,9 @@ static int mgag200_compute_pixpll_values_g200se(struct
mga_device *mdev, long cl
tmpdelta = clock - computed;
if (tmpdelta < delta) {
delta = tmpdelta;
- m = testm - 1;
- n = testn - 1;
- p = testp - 1;
+ m = testm;
+ n = testn;
+
Re: [Intel-gfx] [PATCH v2] drm/i915: Add TTM offset argument to mmap.
On Mon, Jul 12, 2021 at 08:47:24AM -0500, Jason Ekstrand wrote:
> On Fri, Jul 9, 2021 at 6:41 AM Maarten Lankhorst
> wrote:
> >
> > This is only used for ttm, and tells userspace that the mapping type is
> > ignored. This disables the other type of mmap offsets when discrete
> > memory is used, so fix the selftests as well.
> >
> > Document the struct as well, so it shows up in docbook correctly.
> >
> > Changes since v1:
> > - Add docbook entries.
> >
> > Signed-off-by: Maarten Lankhorst
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 17 ++-
> > .../gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
> > .../drm/i915/gem/selftests/i915_gem_mman.c| 27 +-
> > include/uapi/drm/i915_drm.h | 51 +++
> > 4 files changed, 82 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > index a90f796e85c0..b34be9e5d094 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > @@ -679,10 +679,16 @@ __assign_mmap_offset(struct drm_i915_gem_object *obj,
> > return -ENODEV;
> >
> > if (obj->ops->mmap_offset) {
> > + if (mmap_type != I915_MMAP_TYPE_TTM)
> > + return -ENODEV;
> > +
> > *offset = obj->ops->mmap_offset(obj);
> > return 0;
> > }
> >
> > + if (mmap_type == I915_MMAP_TYPE_TTM)
> > + return -ENODEV;
> > +
> > if (mmap_type != I915_MMAP_TYPE_GTT &&
> > !i915_gem_object_has_struct_page(obj) &&
> > !i915_gem_object_has_iomem(obj))
> > @@ -727,7 +733,9 @@ i915_gem_dumb_mmap_offset(struct drm_file *file,
> > {
> > enum i915_mmap_type mmap_type;
> >
> > - if (boot_cpu_has(X86_FEATURE_PAT))
> > + if (HAS_LMEM(to_i915(dev)))
> > + mmap_type = I915_MMAP_TYPE_TTM;
> > + else if (boot_cpu_has(X86_FEATURE_PAT))
> > mmap_type = I915_MMAP_TYPE_WC;
> > else if (!i915_ggtt_has_aperture(&to_i915(dev)->ggtt))
> > return -ENODEV;
> > @@ -798,6 +806,10 @@ i915_gem_mmap_offset_ioctl(struct drm_device *dev,
> > void *data,
> > type = I915_MMAP_TYPE_UC;
> > break;
> >
> > + case I915_MMAP_OFFSET_TTM:
> > + type = I915_MMAP_TYPE_TTM;
> > + break;
> > +
> > default:
> > return -EINVAL;
> > }
> > @@ -968,6 +980,9 @@ int i915_gem_mmap(struct file *filp, struct
> > vm_area_struct *vma)
> > vma->vm_ops = &vm_ops_cpu;
> > break;
> >
> > + case I915_MMAP_TYPE_TTM:
> > + GEM_WARN_ON(mmo->mmap_type == I915_MMAP_TYPE_TTM);
> > + /* fall-through */
> > case I915_MMAP_TYPE_WB:
> > vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
> > vma->vm_ops = &vm_ops_cpu;
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > index ef3de2ae9723..d4c42bcdfeb6 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > @@ -105,6 +105,7 @@ enum i915_mmap_type {
> > I915_MMAP_TYPE_WC,
> > I915_MMAP_TYPE_WB,
> > I915_MMAP_TYPE_UC,
> > + I915_MMAP_TYPE_TTM,
> > };
> >
> > struct i915_mmap_offset {
> > diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> > b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> > index 1da8bd675e54..27a35d88e5f5 100644
> > --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> > +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> > @@ -573,6 +573,14 @@ static int make_obj_busy(struct drm_i915_gem_object
> > *obj)
> > return 0;
> > }
> >
> > +static enum i915_mmap_type default_mapping(struct drm_i915_private *i915)
> > +{
> > + if (HAS_LMEM(i915))
> > + return I915_MMAP_TYPE_TTM;
> > +
> > + return I915_MMAP_TYPE_GTT;
> > +}
> > +
> > static bool assert_mmap_offset(struct drm_i915_private *i915,
> >unsigned long size,
> >int expected)
> > @@ -585,7 +593,7 @@ static bool assert_mmap_offset(struct drm_i915_private
> > *i915,
> > if (IS_ERR(obj))
> > return expected && expected == PTR_ERR(obj);
> >
> > - ret = __assign_mmap_offset(obj, I915_MMAP_TYPE_GTT, &offset, NULL);
> > + ret = __assign_mmap_offset(obj, default_mapping(i915), &offset,
> > NULL);
> > i915_gem_object_put(obj);
> >
> > return ret == expected;
> > @@ -689,7 +697,7 @@ static int igt_mmap_offset_exhaustion(void *arg)
> > goto out;
> > }
> >
> > - err = __assign_mmap_offset(obj, I915_MMAP_TYPE_GTT, &offset, NULL);
> > + err = __assign_mmap_offset(obj, def
Re: [PATCH] drm/vgem: Restore mmap functionality
On Mon, Jul 12, 2021 at 09:09:24AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 09.07.21 um 16:43 schrieb Daniel Vetter:
> > On Fri, Jul 9, 2021 at 1:47 PM Thomas Zimmermann
> > wrote:
> > >
> > > Commit 375cca1cfeb5 ("drm/vgem: Implement mmap as GEM object function")
> > > accidentally removed the actual mmap functionality from vgem. Restore
> > > the original implementation and VMA flags.
> >
> > Ah yes that explains things.
> >
> > Reviewed-by: Daniel Vetter
>
> Apparently, this fix fails a number of other tests. [1] Can we revert the
> original patch for now? I'd like to have time to investigate.
Uh yes something funny is going on here. I've also beent trying to debug
my conversion of vgem to shmem helpers, and been hitting lots of strange
bugs (but the ones I debugged thus far were all real issues, and resulted
in shmem helper fixes).
So yeah, on the revert:
Reviewed-by: Daniel Vetter
Please include discussions and links to your patch here and CI results in
the commit message, so that we have a better starting point for the next
attempt.
-Daniel
>
> Best regards
> Thomas
>
>
> [1]
> https://lore.kernel.org/intel-gfx/20210709154256.12005-1-tzimmerm...@suse.de/T/#maa12be2a6d4b6a4ed8cb05e98f00b8955638c518
>
> > >
> > > Fixes access to unmapped memory:
> > >
> > > [ 106.591744] BUG: KASAN: vmalloc-out-of-bounds in do_fault+0x38/0x480
> > > [ 106.598154] Read of size 8 at addr c10c44a8 by task
> > > vgem_basic/1514
> > > [ 106.605173]
> > > [ 106.606678] CPU: 1 PID: 1514 Comm: vgem_basic Tainted: GE
> > >5.13.0-1-default+ #990
> > > [ 106.615535] Hardware name: Dell Inc. OptiPlex 9020/0N4YC8, BIOS A24
> > > 10/24/2018
> > > [ 106.622818] Call Trace:
> > > [ 106.625289] dump_stack+0xa5/0xdc
> > > [ 106.628642] print_address_description.constprop.0+0x18/0x100
> > > [ 106.634439] ? do_fault+0x38/0x480
> > > [ 106.637872] kasan_report.cold+0x7c/0xd8
> > > [ 106.641834] ? do_fault+0x38/0x480
> > > [ 106.645274] do_fault+0x38/0x480
> > > [ 106.648535] __handle_mm_fault+0x935/0xb00
> > > [ 106.652676] ? vm_iomap_memory+0xe0/0xe0
> > > [ 106.656634] ? __lock_release+0x12f/0x4e0
> > > [ 106.660696] ? count_memcg_event_mm.part.0+0xb9/0x190
> > > [ 106.665799] handle_mm_fault+0xd0/0x370
> > > [ 106.669675] do_user_addr_fault+0x2a0/0x8c0
> > > [ 106.673908] exc_page_fault+0x64/0xf0
> > > [ 106.677604] ? asm_exc_page_fault+0x8/0x30
> > > [ 106.681739] asm_exc_page_fault+0x1e/0x30
> > > [ 106.685782] RIP: 0033:0x402e12
> > > ...
> > >
> > > Signed-off-by: Thomas Zimmermann
> > > Fixes: 375cca1cfeb5 ("drm/vgem: Implement mmap as GEM object function")
> > > Cc: Thomas Zimmermann
> > > Cc: Christian König
> > > Cc: Daniel Vetter
> > > Cc: "Christian König"
> > > Cc: Melissa Wen
> > > Cc: Jason Gunthorpe
> > > Cc: Gerd Hoffmann
> > > Cc: Lee Jones
> > > ---
> > > drivers/gpu/drm/vgem/vgem_drv.c | 11 ++-
> > > 1 file changed, 10 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c
> > > b/drivers/gpu/drm/vgem/vgem_drv.c
> > > index df634aa52638..f50fd10c4fad 100644
> > > --- a/drivers/gpu/drm/vgem/vgem_drv.c
> > > +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> > > @@ -364,8 +364,17 @@ static void vgem_prime_vunmap(struct drm_gem_object
> > > *obj, struct dma_buf_map *ma
> > >
> > > static int vgem_prime_mmap(struct drm_gem_object *obj, struct
> > > vm_area_struct *vma)
> > > {
> > > + int ret;
> > > +
> > > + if (!obj->filp)
> > > + return -ENODEV;
> > > +
> > > + ret = call_mmap(obj->filp, vma);
> > > + if (ret)
> > > + return ret;
> > > +
> > > vma_set_file(vma, obj->filp);
> > > - vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
> > > + vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
> > > vma->vm_page_prot =
> > > pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
> > > vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
> > >
> > > --
> > > 2.32.0
> > >
> >
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
RE: [PATCH v2] drm/dp: follow DP link CTS spec to read link status back
On Wed, 08 Jul 2021, Lee Shawn C wrote:
>On Wed, 07 Jul 2021, 4:14 p.m, Jani Nikula wrote:
>>On Wed, 07 Jul 2021, Lee Shawn C wrote:
>>> Refer to DP link CTS 1.2/1.4 spec, the following test case request
>>> source read DPCD 200h - 205h to get latest link status from sink.
>>>
>>> (4.3.2.4) Handling of IRQ HPD Pulse with No Error Status Bits Set
>>> (400.3.2.1) Successful Link Re-training After IRQ HPD Pulse
>>> Due to Loss of Symbol Lock: HBR2 Extension
>>> (400.3.2.2) Successful Link Re-training After IRQ HPD Pulse Due
>>> to Loss of Clock Recovery Lock: HBR2 Extension
>>> (400.3.2.3) Successful Link Re-training After IRQ HPD Pulse Due
>>> to Loss of Inter-lane Alignment Lock: HBR2 Extension
>>>
>>> So far, DRM DP driver just read back the link status from 202h to
>>> 207h. DPR-120 would judge source can't pass these cases and shows
>>> below error messages.
>>>
>>> "Test FAILED, Source DUT does not read DPCD registers 200h-205h
>>> within
>>> 100 ms".
>>
>>Acked-by: Jani Nikula
>>
>>for making the test pass iff everything else seems to work.
>>
>>The underlying question is, though, should we look at 0x200-0x201 for some
>>status we don't look at?
>>
>
>Look into 200h. While doing link train with DPRX. In my opinion, sink_count
>and cp_ready status should be constant.
>And sink would trigger HPD to source to notify 201h value was changed. Seems
>source driver don't need this value at link training stage as well. What do
>you think?
>
>Best regards,
>Shawn
>
Hi Simon and all,
Please share your recommendations for this patch to pass DP link layer
compliance test. Thanks!
Best regards,
Shawn
>>
>>>
>>> v2: Use sizeof() to retrieve array size.
>>>
>>> Cc: Jani Nikula
>>> Cc: Ville Syrjälä
>>> Cc: Lyude Paul
>>> Cc: Simon Ser
>>> Cc: Cooper Chiou
>>> Cc: William Tseng
>>> Signed-off-by: Lee Shawn C
>>> ---
>>> drivers/gpu/drm/drm_dp_helper.c | 10 ++
>>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_dp_helper.c
>>> b/drivers/gpu/drm/drm_dp_helper.c index 24bbc710c825..4f03df317d62
>>> 100644
>>> --- a/drivers/gpu/drm/drm_dp_helper.c
>>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>>> @@ -410,17 +410,19 @@ int drm_dp_dpcd_read_phy_link_status(struct
>>> drm_dp_aux *aux,
>>> u8 link_status[DP_LINK_STATUS_SIZE]) {
>>> int ret;
>>> + u8 full_link_stat[DP_LINK_STATUS_SIZE + 2];
>>>
>>> if (dp_phy == DP_PHY_DPRX) {
>>> ret = drm_dp_dpcd_read(aux,
>>> - DP_LANE0_1_STATUS,
>>> - link_status,
>>> - DP_LINK_STATUS_SIZE);
>>> + DP_SINK_COUNT,
>>> + full_link_stat,
>>> + sizeof(full_link_stat));
>>>
>>> if (ret < 0)
>>> return ret;
>>>
>>> - WARN_ON(ret != DP_LINK_STATUS_SIZE);
>>> + memcpy(link_status, full_link_stat + 2, DP_LINK_STATUS_SIZE);
>>> + WARN_ON(ret != DP_LINK_STATUS_SIZE + 2);
>>>
>>> return 0;
>>> }
>>
>>--
>>Jani Nikula, Intel Open Source Graphics Center
>
Re: [PATCH 06/12] drm/mgag200: Store values (not bits) in struct mgag200_pll_values
Hi Thomas, > As I mention, struct mgag200_pll_values should store the PLL values. But the > individual compute and set functions for each hardware revision mess this up > completely. Sometimes they use 'function values' sometimes they use > 'register values'. If you'd try to debug a failed modeset operation and have > to look at the PLL, the stored values would be meaningless, because there's > simply no logic behind it. So this is the reason for this chage - and then it makes perferct sense to do it. Without this explanation is was to my eay useless chrunch, but this explanation makes sense. > > The purpose of this patch is to make all compute functions store function > values in the struct and make all update function compute the register > values internally. > > Do you think the change would be easier to understand if I change the > original _set_plls() functions *before* splitting them into compute and > update steps? Na, this would still be very difficult to track down. The only way I would trust myself doing a proper review would be do code it myself and compare the final result. Alas, I am not going to do this. I will take a look again when you post the next revision, and unless I stumble on something I can ack the code as in I have at least looked at all the code changes. That should be enough to have it committed and the time will tell if there is some fall-out. Sam
Re: [PATCH] drm/of: free the right object
On Fri, Jul 09, 2021 at 10:07:17PM +0200, Julia Lawall wrote:
> There is no need to free a NULL value. Instead, free the object
> that is leaking due to the iterator.
>
> The semantic patch that finds this problem is as follows:
>
> //
> @@
> expression x,e;
> identifier f;
> @@
> x = f(...);
> if (x == NULL) {
> ... when any
> when != x = e
> * of_node_put(x);
> ...
> }
> //
>
> Fixes: 6529007522de ("drm: of: Add drm_of_lvds_get_dual_link_pixel_order")
> Signed-off-by: Julia Lawall
Applied to drm-misc-next, thanks for your patch.
Random rant about this for_each_child_of_node():
- not documented with kerneldoc
- very dangerous since the seemingly correct usage leaks
What we've done here for similar refcounted iterators is a 3 step process:
- iter_init()
- for_each_iter() macro
- iter_fini(), which has to be always called after iter_init and cleans up
the last reference.
Then it's a lot more obvious that you call iter_fini() when you break out
of a loop. Trying to hide that in the for_each macro is a bit much.
Cheers, Daniel
>
> ---
> drivers/gpu/drm/drm_of.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index ca04c34e8251..197c57477344 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -315,7 +315,7 @@ static int drm_of_lvds_get_remote_pixels_type(
>
> remote_port = of_graph_get_remote_port(endpoint);
> if (!remote_port) {
> - of_node_put(remote_port);
> + of_node_put(endpoint);
> return -EPIPE;
> }
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 0/4] vkms: Switch to shadow-buffered plane state
On Mon, Jul 12, 2021 at 6:53 PM Thomas Zimmermann wrote: > > Hi > > Am 12.07.21 um 13:56 schrieb Sumera Priyadarsini: > > On Mon, Jul 5, 2021 at 1:16 PM Thomas Zimmermann > > wrote: > >> > >> Vkms copies each plane's framebuffer into the output buffer; essentially > >> using a shadow buffer. DRM provides struct drm_shadow_plane_state, which > >> handles the details of mapping/unmapping shadow buffers into memory for > >> active planes. > >> > >> Convert vkms to the helpers. Makes vkms use shared code and gives more > >> test exposure to shadow-plane helpers. > >> > >> Thomas Zimmermann (4): > >>drm/gem: Export implementation of shadow-plane helpers > >>drm/vkms: Inherit plane state from struct drm_shadow_plane_state > >>drm/vkms: Let shadow-plane helpers prepare the plane's FB > >>drm/vkms: Use dma-buf mapping from shadow-plane state for composing > >> > >> drivers/gpu/drm/drm_gem_atomic_helper.c | 55 ++-- > >> drivers/gpu/drm/vkms/vkms_composer.c| 26 ++- > >> drivers/gpu/drm/vkms/vkms_drv.h | 6 ++- > >> drivers/gpu/drm/vkms/vkms_plane.c | 57 ++--- > >> include/drm/drm_gem_atomic_helper.h | 6 +++ > >> 5 files changed, 86 insertions(+), 64 deletions(-) > >> > >> > >> base-commit: 3d3b5479895dd6dd133571ded4318adf595708ba > >> -- > >> 2.32.0 > >> > > Hi, > > > > Thanks for the patches. The switch to shadow-plane helpers also solved > > a bug that was causing a kernel > > panic during some IGT kms_flip subtests on the vkms virtual hw patch. > > Melissa mention something like that as well and I don't really > understand. Patch 3 removes an error message from the code, but is the > actual bug also gone? Yes, I think so. Earlier, while testing the vkms virtual hw patch, the tests were not just failing, but the vmap fail also preceeded a page fault which required a whole restart. Check these logs around line 303: https://pastebin.pl/view/03b750be. I could be wrong but I think if the same bug was still present, then the kernel panic would also happen even if the error message was not being returned. Cheers, Sumera > > There's little difference between vkms' original code and the shared > helper; except for the order of operations in prepare_fb. The shared > helper synchronizes fences before mapping; vkms mapped first. > > (Maybe the shared helper should warn about failed vmaps as well. But > that's for another patch.) > > Best regards > Thomas > > > > > Tested-by: Sumera Priyadarsini > > > > Cheers, > > Sumera > > > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer >
Re: [PATCH 1/2] drm/i915: Don't allow setting I915_CONTEXT_PARAM_VM twice
On Sat, Jul 10, 2021 at 04:24:46PM -0500, Jason Ekstrand wrote:
> Allowing setting it multiple times brings no real utility to the API, no
> userspace relies on it, and it does make i915 a tiny bit more
> complicated. Let's disallow it for now unless someone comes up with a
> compelling reason to support it.
Maybe mention this is for symmetry with other proto ctx set_param
operations, like set_engines.
>
> Signed-off-by: Jason Ekstrand
> Cc: Daniel Vetter
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 7d6f52d8a8012..5853737cc79f3 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -319,7 +319,6 @@ static int set_proto_ctx_vm(struct drm_i915_file_private
> *fpriv,
> const struct drm_i915_gem_context_param *args)
> {
> struct drm_i915_private *i915 = fpriv->dev_priv;
> - struct i915_address_space *vm;
>
> if (args->size)
> return -EINVAL;
> @@ -327,17 +326,16 @@ static int set_proto_ctx_vm(struct
> drm_i915_file_private *fpriv,
> if (!HAS_FULL_PPGTT(i915))
> return -ENODEV;
>
> + if (pc->vm)
> + return -EINVAL;
> +
> if (upper_32_bits(args->value))
> return -ENOENT;
>
> - vm = i915_gem_vm_lookup(fpriv, args->value);
> - if (!vm)
> + pc->vm = i915_gem_vm_lookup(fpriv, args->value);
> + if (!pc->vm)
> return -ENOENT;
>
> - if (pc->vm)
> - i915_vm_put(pc->vm);
> - pc->vm = vm;
> -
> return 0;
> }
>
> --
> 2.31.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH v2] drm/i915: Add TTM offset argument to mmap.
On Mon, Jul 12, 2021 at 9:12 AM Daniel Vetter wrote:
>
> On Mon, Jul 12, 2021 at 08:47:24AM -0500, Jason Ekstrand wrote:
> > On Fri, Jul 9, 2021 at 6:41 AM Maarten Lankhorst
> > wrote:
> > >
> > > This is only used for ttm, and tells userspace that the mapping type is
> > > ignored. This disables the other type of mmap offsets when discrete
> > > memory is used, so fix the selftests as well.
> > >
> > > Document the struct as well, so it shows up in docbook correctly.
> > >
> > > Changes since v1:
> > > - Add docbook entries.
> > >
> > > Signed-off-by: Maarten Lankhorst
> > > ---
> > > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 17 ++-
> > > .../gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
> > > .../drm/i915/gem/selftests/i915_gem_mman.c| 27 +-
> > > include/uapi/drm/i915_drm.h | 51 +++
> > > 4 files changed, 82 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > index a90f796e85c0..b34be9e5d094 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > @@ -679,10 +679,16 @@ __assign_mmap_offset(struct drm_i915_gem_object
> > > *obj,
> > > return -ENODEV;
> > >
> > > if (obj->ops->mmap_offset) {
> > > + if (mmap_type != I915_MMAP_TYPE_TTM)
> > > + return -ENODEV;
> > > +
> > > *offset = obj->ops->mmap_offset(obj);
> > > return 0;
> > > }
> > >
> > > + if (mmap_type == I915_MMAP_TYPE_TTM)
> > > + return -ENODEV;
> > > +
> > > if (mmap_type != I915_MMAP_TYPE_GTT &&
> > > !i915_gem_object_has_struct_page(obj) &&
> > > !i915_gem_object_has_iomem(obj))
> > > @@ -727,7 +733,9 @@ i915_gem_dumb_mmap_offset(struct drm_file *file,
> > > {
> > > enum i915_mmap_type mmap_type;
> > >
> > > - if (boot_cpu_has(X86_FEATURE_PAT))
> > > + if (HAS_LMEM(to_i915(dev)))
> > > + mmap_type = I915_MMAP_TYPE_TTM;
> > > + else if (boot_cpu_has(X86_FEATURE_PAT))
> > > mmap_type = I915_MMAP_TYPE_WC;
> > > else if (!i915_ggtt_has_aperture(&to_i915(dev)->ggtt))
> > > return -ENODEV;
> > > @@ -798,6 +806,10 @@ i915_gem_mmap_offset_ioctl(struct drm_device *dev,
> > > void *data,
> > > type = I915_MMAP_TYPE_UC;
> > > break;
> > >
> > > + case I915_MMAP_OFFSET_TTM:
> > > + type = I915_MMAP_TYPE_TTM;
> > > + break;
> > > +
> > > default:
> > > return -EINVAL;
> > > }
> > > @@ -968,6 +980,9 @@ int i915_gem_mmap(struct file *filp, struct
> > > vm_area_struct *vma)
> > > vma->vm_ops = &vm_ops_cpu;
> > > break;
> > >
> > > + case I915_MMAP_TYPE_TTM:
> > > + GEM_WARN_ON(mmo->mmap_type == I915_MMAP_TYPE_TTM);
> > > + /* fall-through */
> > > case I915_MMAP_TYPE_WB:
> > > vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
> > > vma->vm_ops = &vm_ops_cpu;
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > > b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > > index ef3de2ae9723..d4c42bcdfeb6 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > > @@ -105,6 +105,7 @@ enum i915_mmap_type {
> > > I915_MMAP_TYPE_WC,
> > > I915_MMAP_TYPE_WB,
> > > I915_MMAP_TYPE_UC,
> > > + I915_MMAP_TYPE_TTM,
> > > };
> > >
> > > struct i915_mmap_offset {
> > > diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> > > b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> > > index 1da8bd675e54..27a35d88e5f5 100644
> > > --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> > > +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> > > @@ -573,6 +573,14 @@ static int make_obj_busy(struct drm_i915_gem_object
> > > *obj)
> > > return 0;
> > > }
> > >
> > > +static enum i915_mmap_type default_mapping(struct drm_i915_private *i915)
> > > +{
> > > + if (HAS_LMEM(i915))
> > > + return I915_MMAP_TYPE_TTM;
> > > +
> > > + return I915_MMAP_TYPE_GTT;
> > > +}
> > > +
> > > static bool assert_mmap_offset(struct drm_i915_private *i915,
> > >unsigned long size,
> > >int expected)
> > > @@ -585,7 +593,7 @@ static bool assert_mmap_offset(struct
> > > drm_i915_private *i915,
> > > if (IS_ERR(obj))
> > > return expected && expected == PTR_ERR(obj);
> > >
> > > - ret = __assign_mmap_offset(obj, I915_MMAP_TYPE_GTT, &offset,
> > > NULL);
> > > + ret = __assign_mmap_offset(obj, default_mapping(i915), &offset,
> > > NULL);
> > > i915
Re: [PATCH 2/2] drm/i915/uapi: Add docs about immutability of engine sets and VMs
On Sat, Jul 10, 2021 at 04:24:47PM -0500, Jason Ekstrand wrote:
> Signed-off-by: Jason Ekstrand
> Cc: Daniel Vetter
> ---
> include/uapi/drm/i915_drm.h | 39 ++---
> 1 file changed, 28 insertions(+), 11 deletions(-)
>
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index e334a8b14ef2d..b6bfbda1258c8 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -1676,15 +1676,25 @@ struct drm_i915_gem_context_param {
> */
> #define I915_CONTEXT_PARAM_RECOVERABLE 0x8
>
> - /*
> - * The id of the associated virtual memory address space (ppGTT) of
> - * this context. Can be retrieved and passed to another context
> - * (on the same fd) for both to use the same ppGTT and so share
> - * address layouts, and avoid reloading the page tables on context
> - * switches between themselves.
> - *
> - * See DRM_I915_GEM_VM_CREATE and DRM_I915_GEM_VM_DESTROY.
> - */
> +/*
So the annoying thing here is that this way it's not picked up by the
kerneldoc machinery.
I think what Matt has done is included parameters as an item list in the
relevant struct kerneldoc, which seems like the most reasonable thing to
do with them.
That means some mild duplication for get/set parts, but since we've made
the uapi very asymmetric in that, that's probably a feature.
> + * The id of the associated virtual memory address space (ppGTT) of
> + * this context. Can be retrieved and passed to another context
> + * (on the same fd) for both to use the same ppGTT and so share
> + * address layouts, and avoid reloading the page tables on context
> + * switches between themselves.
> + *
> + * The VM id should only be set via I915_CONTEXT_CREATE_EXT_SETPARAM.
> + *
> + * On GPUs with graphics version 12 and earlier, it may also be set via
> + * DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM. However, this is only for
> + * backwards compatibility with old userspace and should be considered
> + * deprecated. Starting with graphics version 13, it can only be set via
> + * I915_CONTEXT_CREATE_EXT_SETPARAM. When using setparam, it may only be
> + * set once for each context and, once the context has been used with any
> + * ioctl other than I915_CONTEXT_CREATE_EXT_SETPARAM, it may not be set.
> + *
> + * See DRM_I915_GEM_VM_CREATE and DRM_I915_GEM_VM_DESTROY.
Again for kerneldoc linking to the struct of the ioctl is probably better,
since then you get a link.
> + */
> #define I915_CONTEXT_PARAM_VM0x9
>
> /*
> @@ -1700,8 +1710,15 @@ struct drm_i915_gem_context_param {
> * to specify a gap in the array that can be filled in later, e.g. by a
> * virtual engine used for load balancing.
> *
> - * Setting the number of engines bound to the context to 0, by passing a zero
> - * sized argument, will revert back to default settings.
> + * The engine set should only be set via I915_CONTEXT_CREATE_EXT_SETPARAM.
> + *
> + * On GPUs with graphics version 12 and earlier, it may also be set via
> + * DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM. However, this is only for
> + * backwards compatibility with old userspace and should be considered
> + * deprecated. Starting with graphics version 13, it can only be set via
> + * I915_CONTEXT_CREATE_EXT_SETPARAM. When using setparam, it may only be
> + * set once for each context and, once the context has been used with any
> + * ioctl other than I915_CONTEXT_CREATE_EXT_SETPARAM, it may not be set.
> *
> * See struct i915_context_param_engines.
Maybe we should push most of the docs for params with structs into the
struct's kerneldoc?
-Daniel
> *
> --
> 2.31.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 1/1] fbmem: Do not delete the mode that is still in use
On Mon, Jul 12, 2021 at 04:55:44PM +0800, Zhen Lei wrote:
> The execution of fb_delete_videomode() is not based on the result of the
> previous fbcon_mode_deleted(). As a result, the mode is directly deleted,
> regardless of whether it is still in use, which may cause UAF.
>
> ==
> BUG: KASAN: use-after-free in fb_mode_is_equal+0x36e/0x5e0 \
> drivers/video/fbdev/core/modedb.c:924
> Read of size 4 at addr 88807e0ddb1c by task syz-executor.0/18962
>
> CPU: 2 PID: 18962 Comm: syz-executor.0 Not tainted 5.10.45-rc1+ #3
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ...
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x137/0x1be lib/dump_stack.c:118
> print_address_description+0x6c/0x640 mm/kasan/report.c:385
> __kasan_report mm/kasan/report.c:545 [inline]
> kasan_report+0x13d/0x1e0 mm/kasan/report.c:562
> fb_mode_is_equal+0x36e/0x5e0 drivers/video/fbdev/core/modedb.c:924
> fbcon_mode_deleted+0x16a/0x220 drivers/video/fbdev/core/fbcon.c:2746
> fb_set_var+0x1e1/0xdb0 drivers/video/fbdev/core/fbmem.c:975
> do_fb_ioctl+0x4d9/0x6e0 drivers/video/fbdev/core/fbmem.c:1108
> vfs_ioctl fs/ioctl.c:48 [inline]
> __do_sys_ioctl fs/ioctl.c:753 [inline]
> __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739
> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Freed by task 18960:
> kasan_save_stack mm/kasan/common.c:48 [inline]
> kasan_set_track+0x3d/0x70 mm/kasan/common.c:56
> kasan_set_free_info+0x17/0x30 mm/kasan/generic.c:355
> __kasan_slab_free+0x108/0x140 mm/kasan/common.c:422
> slab_free_hook mm/slub.c:1541 [inline]
> slab_free_freelist_hook+0xd6/0x1a0 mm/slub.c:1574
> slab_free mm/slub.c:3139 [inline]
> kfree+0xca/0x3d0 mm/slub.c:4121
> fb_delete_videomode+0x56a/0x820 drivers/video/fbdev/core/modedb.c:1104
> fb_set_var+0x1f3/0xdb0 drivers/video/fbdev/core/fbmem.c:978
> do_fb_ioctl+0x4d9/0x6e0 drivers/video/fbdev/core/fbmem.c:1108
> vfs_ioctl fs/ioctl.c:48 [inline]
> __do_sys_ioctl fs/ioctl.c:753 [inline]
> __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739
> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Fixes: 13ff178ccd6d ("fbcon: Call fbcon_mode_deleted/new_modelist directly")
> Signed-off-by: Zhen Lei
Nice catch, that indeed got lost.
Reviewed-by: Daniel Vetter
Cc: # v5.3+
Needs to be applied to drm-misc-fixes, but the tree isn't ready yet.
-Daniel
> ---
> drivers/video/fbdev/core/fbmem.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index 98f193078c05..1c855145711b 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -970,13 +970,11 @@ fb_set_var(struct fb_info *info, struct
> fb_var_screeninfo *var)
> fb_var_to_videomode(&mode2, &info->var);
> /* make sure we don't delete the videomode of current var */
> ret = fb_mode_is_equal(&mode1, &mode2);
> -
> - if (!ret)
> - fbcon_mode_deleted(info, &mode1);
> -
> - if (!ret)
> - fb_delete_videomode(&mode1, &info->modelist);
> -
> + if (!ret) {
> + ret = fbcon_mode_deleted(info, &mode1);
> + if (!ret)
> + fb_delete_videomode(&mode1, &info->modelist);
> + }
>
> return ret ? -EINVAL : 0;
> }
> --
> 2.25.1
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH v2] drm/i915: Add TTM offset argument to mmap.
On Mon, Jul 12, 2021 at 09:31:13AM -0500, Jason Ekstrand wrote:
> On Mon, Jul 12, 2021 at 9:12 AM Daniel Vetter wrote:
> >
> > On Mon, Jul 12, 2021 at 08:47:24AM -0500, Jason Ekstrand wrote:
> > > On Fri, Jul 9, 2021 at 6:41 AM Maarten Lankhorst
> > > wrote:
> > > >
> > > > This is only used for ttm, and tells userspace that the mapping type is
> > > > ignored. This disables the other type of mmap offsets when discrete
> > > > memory is used, so fix the selftests as well.
> > > >
> > > > Document the struct as well, so it shows up in docbook correctly.
> > > >
> > > > Changes since v1:
> > > > - Add docbook entries.
> > > >
> > > > Signed-off-by: Maarten Lankhorst
> > > > ---
> > > > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 17 ++-
> > > > .../gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
> > > > .../drm/i915/gem/selftests/i915_gem_mman.c| 27 +-
> > > > include/uapi/drm/i915_drm.h | 51 +++
> > > > 4 files changed, 82 insertions(+), 14 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > > b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > > index a90f796e85c0..b34be9e5d094 100644
> > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > > @@ -679,10 +679,16 @@ __assign_mmap_offset(struct drm_i915_gem_object
> > > > *obj,
> > > > return -ENODEV;
> > > >
> > > > if (obj->ops->mmap_offset) {
> > > > + if (mmap_type != I915_MMAP_TYPE_TTM)
> > > > + return -ENODEV;
> > > > +
> > > > *offset = obj->ops->mmap_offset(obj);
> > > > return 0;
> > > > }
> > > >
> > > > + if (mmap_type == I915_MMAP_TYPE_TTM)
> > > > + return -ENODEV;
> > > > +
> > > > if (mmap_type != I915_MMAP_TYPE_GTT &&
> > > > !i915_gem_object_has_struct_page(obj) &&
> > > > !i915_gem_object_has_iomem(obj))
> > > > @@ -727,7 +733,9 @@ i915_gem_dumb_mmap_offset(struct drm_file *file,
> > > > {
> > > > enum i915_mmap_type mmap_type;
> > > >
> > > > - if (boot_cpu_has(X86_FEATURE_PAT))
> > > > + if (HAS_LMEM(to_i915(dev)))
> > > > + mmap_type = I915_MMAP_TYPE_TTM;
> > > > + else if (boot_cpu_has(X86_FEATURE_PAT))
> > > > mmap_type = I915_MMAP_TYPE_WC;
> > > > else if (!i915_ggtt_has_aperture(&to_i915(dev)->ggtt))
> > > > return -ENODEV;
> > > > @@ -798,6 +806,10 @@ i915_gem_mmap_offset_ioctl(struct drm_device *dev,
> > > > void *data,
> > > > type = I915_MMAP_TYPE_UC;
> > > > break;
> > > >
> > > > + case I915_MMAP_OFFSET_TTM:
> > > > + type = I915_MMAP_TYPE_TTM;
> > > > + break;
> > > > +
> > > > default:
> > > > return -EINVAL;
> > > > }
> > > > @@ -968,6 +980,9 @@ int i915_gem_mmap(struct file *filp, struct
> > > > vm_area_struct *vma)
> > > > vma->vm_ops = &vm_ops_cpu;
> > > > break;
> > > >
> > > > + case I915_MMAP_TYPE_TTM:
> > > > + GEM_WARN_ON(mmo->mmap_type == I915_MMAP_TYPE_TTM);
> > > > + /* fall-through */
> > > > case I915_MMAP_TYPE_WB:
> > > > vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
> > > > vma->vm_ops = &vm_ops_cpu;
> > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > > > b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > > > index ef3de2ae9723..d4c42bcdfeb6 100644
> > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > > > @@ -105,6 +105,7 @@ enum i915_mmap_type {
> > > > I915_MMAP_TYPE_WC,
> > > > I915_MMAP_TYPE_WB,
> > > > I915_MMAP_TYPE_UC,
> > > > + I915_MMAP_TYPE_TTM,
> > > > };
> > > >
> > > > struct i915_mmap_offset {
> > > > diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> > > > b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> > > > index 1da8bd675e54..27a35d88e5f5 100644
> > > > --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> > > > +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> > > > @@ -573,6 +573,14 @@ static int make_obj_busy(struct
> > > > drm_i915_gem_object *obj)
> > > > return 0;
> > > > }
> > > >
> > > > +static enum i915_mmap_type default_mapping(struct drm_i915_private
> > > > *i915)
> > > > +{
> > > > + if (HAS_LMEM(i915))
> > > > + return I915_MMAP_TYPE_TTM;
> > > > +
> > > > + return I915_MMAP_TYPE_GTT;
> > > > +}
> > > > +
> > > > static bool assert_mmap_offset(struct drm_i915_private *i915,
> > > >unsigned long size,
> > > >int expected)
> > > > @@ -585,7 +593,7 @@ static bool assert_mmap_offset(struct
> > > > drm_i915_private *i915
Re: [PATCH 1/8] drm/i915: Explicitly track DRM clients
On Mon, Jul 12, 2021 at 01:17:12PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Tracking DRM clients more explicitly will allow later patches to
> accumulate past and current GPU usage in a centralised place and also
> consolidate access to owning task pid/name.
>
> Unique client id is also assigned for the purpose of distinguishing/
> consolidating between multiple file descriptors owned by the same process.
>
> v2:
> Chris Wilson:
> * Enclose new members into dedicated structs.
> * Protect against failed sysfs registration.
>
> v3:
> * sysfs_attr_init.
>
> v4:
> * Fix for internal clients.
>
> v5:
> * Use cyclic ida for client id. (Chris)
> * Do not leak pid reference. (Chris)
> * Tidy code with some locals.
>
> v6:
> * Use xa_alloc_cyclic to simplify locking. (Chris)
> * No need to unregister individial sysfs files. (Chris)
> * Rebase on top of fpriv kref.
> * Track client closed status and reflect in sysfs.
>
> v7:
> * Make drm_client more standalone concept.
>
> v8:
> * Simplify sysfs show. (Chris)
> * Always track name and pid.
>
> v9:
> * Fix cyclic id assignment.
>
> v10:
> * No need for a mutex around xa_alloc_cyclic.
> * Refactor sysfs into own function.
> * Unregister sysfs before freeing pid and name.
> * Move clients setup into own function.
>
> v11:
> * Call clients init directly from driver init. (Chris)
>
> v12:
> * Do not fail client add on id wrap. (Maciej)
>
> v13 (Lucas): Rebase.
>
> v14:
> * Dropped sysfs bits.
>
> Signed-off-by: Tvrtko Ursulin
> Reviewed-by: Chris Wilson # v11
> Reviewed-by: Aravind Iddamsetty # v11
> Signed-off-by: Chris Wilson
On the implementation: I'm not clear why this is a separate object. All
that seems to achieve is make the lifetim fun we have in here even more
annoying, for not real gain?
What's the reasons for this separate i915_drm_client struct? The commit
message talks about de-duping these within the same process, but with
fdinfo I'm not seeing the relevance of this anymore.
Also, with the fdinfo approach, why do we still need to even track the
pid? That can be all figured out from proc now, with much cleaner
semantics.
-Daniel
> ---
> drivers/gpu/drm/i915/Makefile | 5 +-
> drivers/gpu/drm/i915/i915_drm_client.c | 113 +
> drivers/gpu/drm/i915/i915_drm_client.h | 61 +
> drivers/gpu/drm/i915/i915_drv.c| 6 ++
> drivers/gpu/drm/i915/i915_drv.h| 5 ++
> drivers/gpu/drm/i915/i915_gem.c| 21 -
> 6 files changed, 206 insertions(+), 5 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/i915_drm_client.c
> create mode 100644 drivers/gpu/drm/i915/i915_drm_client.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 10b3bb6207ba..784f99ca11fc 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -33,8 +33,9 @@ subdir-ccflags-y += -I$(srctree)/$(src)
> # Please keep these build lists sorted!
>
> # core driver code
> -i915-y += i915_drv.o \
> - i915_config.o \
> +i915-y += i915_config.o \
> + i915_drm_client.o \
> + i915_drv.o \
> i915_irq.o \
> i915_getparam.o \
> i915_mitigations.o \
> diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
> b/drivers/gpu/drm/i915/i915_drm_client.c
> new file mode 100644
> index ..83080d9836b0
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/i915_drm_client.c
> @@ -0,0 +1,113 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2020 Intel Corporation
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include "i915_drm_client.h"
> +#include "i915_gem.h"
> +#include "i915_utils.h"
> +
> +void i915_drm_clients_init(struct i915_drm_clients *clients,
> +struct drm_i915_private *i915)
> +{
> + clients->i915 = i915;
> +
> + clients->next_id = 0;
> + xa_init_flags(&clients->xarray, XA_FLAGS_ALLOC);
> +}
> +
> +static int
> +__i915_drm_client_register(struct i915_drm_client *client,
> +struct task_struct *task)
> +{
> + char *name;
> +
> + name = kstrdup(task->comm, GFP_KERNEL);
> + if (!name)
> + return -ENOMEM;
> +
> + client->pid = get_task_pid(task, PIDTYPE_PID);
> + client->name = name;
> +
> + return 0;
> +}
> +
> +static void __i915_drm_client_unregister(struct i915_drm_client *client)
> +{
> + put_pid(fetch_and_zero(&client->pid));
> + kfree(fetch_and_zero(&client->name));
> +}
> +
> +static void __rcu_i915_drm_client_free(struct work_struct *wrk)
> +{
> + struct i915_drm_client *client =
> + container_of(wrk, typeof(*client), rcu.work);
> +
> + xa_erase(&client->clients->xarray, client->id);
> +
> + __i915_drm_client_unregister(client);
> +
> + kfree(client);
> +}
> +
> +struct i915_drm_client *
> +i915_drm_client_add(struct i915_drm_clients *clients, struct task_struct
> *task)
> +{
> + struct i915_drm_client *cli
Re: [PATCH v3] drm/mediatek: adjust rdma fifo threshold calculate formula
Hi, Yongqiang: Yongqiang Niu 於 2021年7月11日 週日 下午2:54寫道： > > the orginal formula will caused rdma fifo threshold config overflow > and no one could come out a solution for all SoC, > set threshold to 70% of max fifo size to make sure it will > not overflow, and 70% is a empirical value Applied to mediatek-drm-next [1], thanks. [1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next Regards, Chun-Kuang. > > Signed-off-by: Yongqiang Niu > --- > drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c > b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c > index f123fc0..f1f6a2e 100644 > --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c > +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c > @@ -164,10 +164,10 @@ void mtk_rdma_config(struct device *dev, unsigned int > width, > /* > * Enable FIFO underflow since DSI and DPI can't be blocked. > * Keep the FIFO pseudo size reset default of 8 KiB. Set the > -* output threshold to 6 microseconds with 7/6 overhead to > -* account for blanking, and with a pixel depth of 4 bytes: > +* output threshold to 70% of max fifo size to make sure the > +* threhold will not overflow > */ > - threshold = width * height * vrefresh * 4 * 7 / 100; > + threshold = rdma_fifo_size * 7 / 10; > reg = RDMA_FIFO_UNDERFLOW_EN | > RDMA_FIFO_PSEUDO_SIZE(rdma_fifo_size) | > RDMA_OUTPUT_VALID_FIFO_THRESHOLD(threshold); > -- > 1.8.1.1.dirty >
[PATCH v2] drm/dp: Move panel DP AUX backlight support to drm_dp_helper
We were getting a depmod error:
depmod: ERROR: Cycle detected: drm_kms_helper -> drm -> drm_kms_helper
It looks like the rule is that drm_kms_helper can call into drm, but
drm can't call into drm_kms_helper. That means we've got to move the
DP AUX backlight support into drm_dp_helper.
NOTE: as part of this, I didn't try to do any renames of the main
registration function. Even though it's in the drm_dp_helper, it still
feels very parallel to drm_panel_of_backlight().
Fixes: 10f7b40e4f30 ("drm/panel: add basic DP AUX backlight support")
Reported-by: Ville Syrjälä
Reported-by: Thomas Zimmermann
Signed-off-by: Douglas Anderson
---
Note that I've compile tested this, but I don't have a device setup
yet that uses this code. Since the code is basically the same as it
was this should be OK, but if Rajeev could confirm that nothing is
broken that'd be nice.
Changes in v2:
- Guard new functions by the proper configs.
drivers/gpu/drm/drm_dp_helper.c | 113
drivers/gpu/drm/drm_panel.c | 108 --
include/drm/drm_dp_helper.h | 16 +
include/drm/drm_panel.h | 8 ---
4 files changed, 129 insertions(+), 116 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 24bbc710c825..e8eec20ab364 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -33,9 +33,17 @@
#include
#include
#include
+#include
#include "drm_crtc_helper_internal.h"
+struct dp_aux_backlight {
+ struct backlight_device *base;
+ struct drm_dp_aux *aux;
+ struct drm_edp_backlight_info info;
+ bool enabled;
+};
+
/**
* DOC: dp helpers
*
@@ -3462,3 +3470,108 @@ drm_edp_backlight_init(struct drm_dp_aux *aux, struct
drm_edp_backlight_info *bl
return 0;
}
EXPORT_SYMBOL(drm_edp_backlight_init);
+
+#if IS_BUILTIN(CONFIG_BACKLIGHT_CLASS_DEVICE) || \
+ (IS_MODULE(CONFIG_DRM_KMS_HELPER) &&
IS_MODULE(CONFIG_BACKLIGHT_CLASS_DEVICE))
+
+static int dp_aux_backlight_update_status(struct backlight_device *bd)
+{
+ struct dp_aux_backlight *bl = bl_get_data(bd);
+ u16 brightness = backlight_get_brightness(bd);
+ int ret = 0;
+
+ if (!backlight_is_blank(bd)) {
+ if (!bl->enabled) {
+ drm_edp_backlight_enable(bl->aux, &bl->info,
brightness);
+ bl->enabled = true;
+ return 0;
+ }
+ ret = drm_edp_backlight_set_level(bl->aux, &bl->info,
brightness);
+ } else {
+ if (bl->enabled) {
+ drm_edp_backlight_disable(bl->aux, &bl->info);
+ bl->enabled = false;
+ }
+ }
+
+ return ret;
+}
+
+static const struct backlight_ops dp_aux_bl_ops = {
+ .update_status = dp_aux_backlight_update_status,
+};
+
+/**
+ * drm_panel_dp_aux_backlight - create and use DP AUX backlight
+ * @panel: DRM panel
+ * @aux: The DP AUX channel to use
+ *
+ * Use this function to create and handle backlight if your panel
+ * supports backlight control over DP AUX channel using DPCD
+ * registers as per VESA's standard backlight control interface.
+ *
+ * When the panel is enabled backlight will be enabled after a
+ * successful call to &drm_panel_funcs.enable()
+ *
+ * When the panel is disabled backlight will be disabled before the
+ * call to &drm_panel_funcs.disable().
+ *
+ * A typical implementation for a panel driver supporting backlight
+ * control over DP AUX will call this function at probe time.
+ * Backlight will then be handled transparently without requiring
+ * any intervention from the driver.
+ *
+ * drm_panel_dp_aux_backlight() must be called after the call to
drm_panel_init().
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int drm_panel_dp_aux_backlight(struct drm_panel *panel, struct drm_dp_aux *aux)
+{
+ struct dp_aux_backlight *bl;
+ struct backlight_properties props = { 0 };
+ u16 current_level;
+ u8 current_mode;
+ u8 edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE];
+ int ret;
+
+ if (!panel || !panel->dev || !aux)
+ return -EINVAL;
+
+ ret = drm_dp_dpcd_read(aux, DP_EDP_DPCD_REV, edp_dpcd,
+ EDP_DISPLAY_CTL_CAP_SIZE);
+ if (ret < 0)
+ return ret;
+
+ if (!drm_edp_backlight_supported(edp_dpcd)) {
+ DRM_DEV_INFO(panel->dev, "DP AUX backlight is not supported\n");
+ return 0;
+ }
+
+ bl = devm_kzalloc(panel->dev, sizeof(*bl), GFP_KERNEL);
+ if (!bl)
+ return -ENOMEM;
+
+ bl->aux = aux;
+
+ ret = drm_edp_backlight_init(aux, &bl->info, 0, edp_dpcd,
+¤t_level, ¤t_mode);
+ if (ret < 0)
+ return ret;
+
+ props.type = BACKLIGHT_RAW;
+ props.brightness = current_level;
+ props.max_bright
Re: [v8 1/6] drm/panel: add basic DP AUX backlight support
Hi, On Mon, Jul 12, 2021 at 6:39 AM Doug Anderson wrote: > > Hi, > > On Mon, Jul 12, 2021 at 2:41 AM Thomas Zimmermann wrote: > > > > > + ret = drm_dp_dpcd_read(aux, DP_EDP_DPCD_REV, edp_dpcd, > > > +EDP_DISPLAY_CTL_CAP_SIZE); > > > > This creates a cyclic dependency between drm_kms_helper-ko and drm.ko. > > drm_panel.c is in the latter, while drm_dp_dpcd_read() in > > drm_dp_helper.c is in the former. Please fix. > > Yeah, this was reported Friday and I posted a patch to try to fix it: > > https://lore.kernel.org/lkml/20210709152909.1.I23eb4cc5a680341e7b3e791632a635566fa5806a@changeid/ > > I see Rajeev had some feedback on it. Once I've dug out of my weekend > email hole I'll take a look at plan to post a v2 ASAP. Breadcrumbs: v2 of the fix is at: https://lore.kernel.org/lkml/20210712075933.v2.1.I23eb4cc5a680341e7b3e791632a635566fa5806a@changeid/ I'm hoping this looks OK so we can get this resolved before it trips too many people up. -Doug
Re: [Intel-gfx] [PATCH v2] drm/i915: Add TTM offset argument to mmap.
On Mon, Jul 12, 2021 at 9:38 AM Daniel Vetter wrote:
>
> On Mon, Jul 12, 2021 at 09:31:13AM -0500, Jason Ekstrand wrote:
> > On Mon, Jul 12, 2021 at 9:12 AM Daniel Vetter wrote:
> > >
> > > On Mon, Jul 12, 2021 at 08:47:24AM -0500, Jason Ekstrand wrote:
> > > > On Fri, Jul 9, 2021 at 6:41 AM Maarten Lankhorst
> > > > wrote:
> > > > >
> > > > > This is only used for ttm, and tells userspace that the mapping type
> > > > > is
> > > > > ignored. This disables the other type of mmap offsets when discrete
> > > > > memory is used, so fix the selftests as well.
> > > > >
> > > > > Document the struct as well, so it shows up in docbook correctly.
> > > > >
> > > > > Changes since v1:
> > > > > - Add docbook entries.
> > > > >
> > > > > Signed-off-by: Maarten Lankhorst
> > > > > ---
> > > > > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 17 ++-
> > > > > .../gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
> > > > > .../drm/i915/gem/selftests/i915_gem_mman.c| 27 +-
> > > > > include/uapi/drm/i915_drm.h | 51
> > > > > +++
> > > > > 4 files changed, 82 insertions(+), 14 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > > > b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > > > index a90f796e85c0..b34be9e5d094 100644
> > > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > > > > @@ -679,10 +679,16 @@ __assign_mmap_offset(struct drm_i915_gem_object
> > > > > *obj,
> > > > > return -ENODEV;
> > > > >
> > > > > if (obj->ops->mmap_offset) {
> > > > > + if (mmap_type != I915_MMAP_TYPE_TTM)
> > > > > + return -ENODEV;
> > > > > +
> > > > > *offset = obj->ops->mmap_offset(obj);
> > > > > return 0;
> > > > > }
> > > > >
> > > > > + if (mmap_type == I915_MMAP_TYPE_TTM)
> > > > > + return -ENODEV;
> > > > > +
> > > > > if (mmap_type != I915_MMAP_TYPE_GTT &&
> > > > > !i915_gem_object_has_struct_page(obj) &&
> > > > > !i915_gem_object_has_iomem(obj))
> > > > > @@ -727,7 +733,9 @@ i915_gem_dumb_mmap_offset(struct drm_file *file,
> > > > > {
> > > > > enum i915_mmap_type mmap_type;
> > > > >
> > > > > - if (boot_cpu_has(X86_FEATURE_PAT))
> > > > > + if (HAS_LMEM(to_i915(dev)))
> > > > > + mmap_type = I915_MMAP_TYPE_TTM;
> > > > > + else if (boot_cpu_has(X86_FEATURE_PAT))
> > > > > mmap_type = I915_MMAP_TYPE_WC;
> > > > > else if (!i915_ggtt_has_aperture(&to_i915(dev)->ggtt))
> > > > > return -ENODEV;
> > > > > @@ -798,6 +806,10 @@ i915_gem_mmap_offset_ioctl(struct drm_device
> > > > > *dev, void *data,
> > > > > type = I915_MMAP_TYPE_UC;
> > > > > break;
> > > > >
> > > > > + case I915_MMAP_OFFSET_TTM:
> > > > > + type = I915_MMAP_TYPE_TTM;
> > > > > + break;
> > > > > +
> > > > > default:
> > > > > return -EINVAL;
> > > > > }
> > > > > @@ -968,6 +980,9 @@ int i915_gem_mmap(struct file *filp, struct
> > > > > vm_area_struct *vma)
> > > > > vma->vm_ops = &vm_ops_cpu;
> > > > > break;
> > > > >
> > > > > + case I915_MMAP_TYPE_TTM:
> > > > > + GEM_WARN_ON(mmo->mmap_type == I915_MMAP_TYPE_TTM);
> > > > > + /* fall-through */
> > > > > case I915_MMAP_TYPE_WB:
> > > > > vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
> > > > > vma->vm_ops = &vm_ops_cpu;
> > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > > > > b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > > > > index ef3de2ae9723..d4c42bcdfeb6 100644
> > > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > > > > @@ -105,6 +105,7 @@ enum i915_mmap_type {
> > > > > I915_MMAP_TYPE_WC,
> > > > > I915_MMAP_TYPE_WB,
> > > > > I915_MMAP_TYPE_UC,
> > > > > + I915_MMAP_TYPE_TTM,
> > > > > };
> > > > >
> > > > > struct i915_mmap_offset {
> > > > > diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> > > > > b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> > > > > index 1da8bd675e54..27a35d88e5f5 100644
> > > > > --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> > > > > +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> > > > > @@ -573,6 +573,14 @@ static int make_obj_busy(struct
> > > > > drm_i915_gem_object *obj)
> > > > > return 0;
> > > > > }
> > > > >
> > > > > +static enum i915_mmap_type default_mapping(struct drm_i915_private
> > > > > *i915)
> > > > > +{
> > > > > + if (HAS_LMEM(i915))
> > > > > + return I915_MMAP_TYPE_TTM;
> > > > > +
> > > > > + return I915_MMAP_TYPE_GTT;
>
Re: [RFC PATCH 08/17] dt-bindings: display: bridge: Add Samsung MIPI DSIM bridge
On Sun, Jul 04, 2021 at 02:32:21PM +0530, Jagan Teki wrote: > Samsing MIPI DSIM bridge can be found on Exynos and NXP's > i.MX8M Mini and Nano SoC's. > > This dt-bindings replaces legacy exynos_dsim.txt. > > Used the example node from latest Exynos SoC instead of > the one used in legacy exynos_dsim.txt. > > Add dt-bingings for it. typo > > Cc: Rob Herring > Signed-off-by: Jagan Teki > --- > .../display/bridge/samsung,mipi-dsim.yaml | 278 ++ > .../bindings/display/exynos/exynos_dsim.txt | 90 -- > MAINTAINERS | 1 + > 3 files changed, 279 insertions(+), 90 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > delete mode 100644 > Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt > > diff --git > a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > new file mode 100644 > index ..b2970734ffd7 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > @@ -0,0 +1,278 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/bridge/samsung,mipi-dsim.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Samsung MIPI DSIM bridge controller > + > +maintainers: > + - Inki Dae > + - Joonyoung Shim > + - Seung-Woo Kim > + - Kyungmin Park > + - Andrzej Hajda > + - Jagan Teki > + > +description: | > + Samsung MIPI DSIM bridge controller can be found it on Exynos > + and i.MX8M Mini and Nano SoC's. > + > +properties: > + compatible: > +enum: > + - samsung,exynos3250-mipi-dsi > + - samsung,exynos4210-mipi-dsi > + - samsung,exynos5410-mipi-dsi > + - samsung,exynos5422-mipi-dsi > + - samsung,exynos5433-mipi-dsi What about i.MX compatibles? > + > + reg: > +maxItems: 1 > + > + interrupts: > +maxItems: 1 > + > + '#address-cells': > +const: 1 > + > + '#size-cells': > +const: 0 > + > + clocks: > +minItems: 2 > +maxItems: 5 > + > + clock-names: > +minItems: 2 > +maxItems: 5 > + > + phys: > +maxItems: 1 > +description: phandle to the phy module representing the DPHY Drop > + > + phy-names: > +items: > + - const: dsim > + > + samsung,phy-type: > +$ref: /schemas/types.yaml#/definitions/uint32 > +description: phandle to the samsung phy-type > + > + power-domains: > +description: phandle to the associated power domain Drop > +maxItems: 1 > + > + samsung,power-domain: > +$ref: /schemas/types.yaml#/definitions/phandle > +description: phandle to the associated samsung power domain > +maxItems: 1 > + > + vddcore-supply: > +description: MIPI DSIM Core voltage supply (e.g. 1.1V) > + > + vddio-supply: > +description: MIPI DSIM I/O and PLL voltage supply (e.g. 1.8V) > + > + samsung,burst-clock-frequency: > +$ref: /schemas/types.yaml#/definitions/uint32 > +description: > + DSIM high speed burst mode frequency. > + > + samsung,esc-clock-frequency: > +$ref: /schemas/types.yaml#/definitions/uint32 > +description: > + DSIM escape mode frequency. > + > + samsung,pll-clock-frequency: > +$ref: /schemas/types.yaml#/definitions/uint32 > +description: > + DSIM oscillator clock frequency. > + > + ports: > +$ref: /schemas/graph.yaml#/properties/ports > + > +properties: > + port@0: > +$ref: /schemas/graph.yaml#/$defs/port-base If there are no extra endpoint properties, then use '/schemas/graph.yaml#/properties/port'. > +description: > + Input port node to receive pixel data from the > + display controller. Exactly one endpoint must be > + specified. > +properties: > + endpoint@0: > +$ref: /schemas/graph.yaml#/properties/endpoint > +description: sub-node describing the input from MIC I'd assume i.MX has a different input than MIC? > + > +unevaluatedProperties: false > + > + port@1: > +$ref: /schemas/graph.yaml#/properties/port > +description: > + DSI output port node to the panel or the next bridge > + in the chain > + > +required: > + - '#address-cells' > + - '#size-cells' > + - clock-names > + - clocks > + - compatible > + - interrupts > + - phy-names > + - phys > + - reg > + - samsung,burst-clock-frequency > + - samsung,esc-clock-frequency > + - samsung,pll-clock-frequency > + > +allOf: > + - $ref: ../dsi-controller.yaml# > + - if: > + properties: > +compatible: > + contains: > +const: samsung,exynos5433-mipi-dsi > + > +then: > + properties: > +clocks: > + minItems: 5 > + > +clock-names: > + items: > +- const: bus_clk > +
Re: [PATCH] drm/dp: Move panel DP AUX backlight support to drm_dp_helper
Hi, On Sat, Jul 10, 2021 at 3:29 AM wrote: > > > @@ -209,18 +208,11 @@ static inline int > > of_drm_get_panel_orientation(const struct device_node *np, > > #if IS_ENABLED(CONFIG_DRM_PANEL) && > > (IS_BUILTIN(CONFIG_BACKLIGHT_CLASS_DEVICE) || \ > > (IS_MODULE(CONFIG_DRM) && IS_MODULE(CONFIG_BACKLIGHT_CLASS_DEVICE))) > > Thanks, for the fix. Changes look good to me. I checked this on Trogdor > Lazor device. > > I have one small doubt, shouldn't we add above (or similar) check around > drm_panel_dp_aux_backlight() in drm_dp_helper source & header files? > This function is using devm_backlight_device_register() that needs > CONFIG_BACKLIGHT_CLASS_DEVICE for compilation. > > If that's not an issue, > Reviewed-by: Rajeev Nandan Indeed you are correct. I tried trying off the CONFIG_BACKLIGHT_CLASS_DEVICE and it was unhappy. I've posted a v2 which I think fixes this [1]. I left your review tag off to give you a chance to confirm I didn't goof anything else up in the v2. Thanks! [1] https://lore.kernel.org/lkml/20210712075933.v2.1.I23eb4cc5a680341e7b3e791632a635566fa5806a@changeid/ -Doug
re: drm/i915/ttm Initialize the ttm device and memory managers
Hi,
Static analysis with Coverity on linux-next has found a potential issue
in drivers/gpu/drm/i915/selftests/intel_memory_region.c in function
igt_mock_fill - the problematic commit is as follows:
commit d148738923fdb5077089e48ec1e6008100d0
Author: Thomas Hellström
Date: Wed Jun 2 10:38:08 2021 +0200
drm/i915/ttm Initialize the ttm device and memory managers
The analysis is as follows:
49 static int igt_mock_fill(void *arg)
50 {
51struct intel_memory_region *mem = arg;
52resource_size_t total = resource_size(&mem->region);
53resource_size_t page_size;
54resource_size_t rem;
55unsigned long max_pages;
56unsigned long page_num;
57LIST_HEAD(objects);
58int err = 0;
59
60page_size = mem->chunk_size;
61rem = total;
62 retry:
value_overwrite: Overwriting previous write to max_pages with value from
div64_u64(rem, page_size).
63max_pages = div64_u64(rem, page_size);
64
65for_each_prime_number_from(page_num, 1, max_pages) {
66resource_size_t size = page_num * page_size;
67struct drm_i915_gem_object *obj;
68
69obj = i915_gem_object_create_region(mem, size, 0);
70if (IS_ERR(obj)) {
71err = PTR_ERR(obj);
72break;
73}
74
75err = i915_gem_object_pin_pages_unlocked(obj);
76if (err) {
77i915_gem_object_put(obj);
78break;
79}
80
81list_add(&obj->st_link, &objects);
82rem -= size;
83}
84
85if (err == -ENOMEM)
86err = 0;
87if (err == -ENXIO) {
88if (page_num * page_size <= rem) {
89if (mem->is_range_manager && max_pages > 1) {
Unused value (UNUSED_VALUE)
assigned_value: Assigning value from max_pages >> 1 to max_pages here,
but that stored value is overwritten before it can be used.
90max_pages >>= 1;
91goto retry;
92}
93
The right shift to max_pages on line 90 is being overwritten on line 64
on the retry.
Colin
Re: [RFC PATCH 08/17] dt-bindings: display: bridge: Add Samsung MIPI DSIM bridge
On Mon, Jul 12, 2021 at 8:43 PM Rob Herring wrote: > > On Sun, Jul 04, 2021 at 02:32:21PM +0530, Jagan Teki wrote: > > Samsing MIPI DSIM bridge can be found on Exynos and NXP's > > i.MX8M Mini and Nano SoC's. > > > > This dt-bindings replaces legacy exynos_dsim.txt. > > > > Used the example node from latest Exynos SoC instead of > > the one used in legacy exynos_dsim.txt. > > > > Add dt-bingings for it. > > typo > > > > > Cc: Rob Herring > > Signed-off-by: Jagan Teki > > --- > > .../display/bridge/samsung,mipi-dsim.yaml | 278 ++ > > .../bindings/display/exynos/exynos_dsim.txt | 90 -- > > MAINTAINERS | 1 + > > 3 files changed, 279 insertions(+), 90 deletions(-) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > > delete mode 100644 > > Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt > > > > diff --git > > a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > > b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > > new file mode 100644 > > index ..b2970734ffd7 > > --- /dev/null > > +++ > > b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml > > @@ -0,0 +1,278 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/display/bridge/samsung,mipi-dsim.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Samsung MIPI DSIM bridge controller > > + > > +maintainers: > > + - Inki Dae > > + - Joonyoung Shim > > + - Seung-Woo Kim > > + - Kyungmin Park > > + - Andrzej Hajda > > + - Jagan Teki > > + > > +description: | > > + Samsung MIPI DSIM bridge controller can be found it on Exynos > > + and i.MX8M Mini and Nano SoC's. > > + > > +properties: > > + compatible: > > +enum: > > + - samsung,exynos3250-mipi-dsi > > + - samsung,exynos4210-mipi-dsi > > + - samsung,exynos5410-mipi-dsi > > + - samsung,exynos5422-mipi-dsi > > + - samsung,exynos5433-mipi-dsi > > What about i.MX compatibles? I have added in the next patch since this is yml conversation for existing .txt bindings. > > > + > > + reg: > > +maxItems: 1 > > + > > + interrupts: > > +maxItems: 1 > > + > > + '#address-cells': > > +const: 1 > > + > > + '#size-cells': > > +const: 0 > > + > > + clocks: > > +minItems: 2 > > +maxItems: 5 > > + > > + clock-names: > > +minItems: 2 > > +maxItems: 5 > > + > > + phys: > > +maxItems: 1 > > +description: phandle to the phy module representing the DPHY > > Drop > > > + > > + phy-names: > > +items: > > + - const: dsim > > + > > + samsung,phy-type: > > +$ref: /schemas/types.yaml#/definitions/uint32 > > +description: phandle to the samsung phy-type > > + > > + power-domains: > > +description: phandle to the associated power domain > > Drop > > > +maxItems: 1 > > + > > + samsung,power-domain: > > +$ref: /schemas/types.yaml#/definitions/phandle > > +description: phandle to the associated samsung power domain > > +maxItems: 1 > > + > > + vddcore-supply: > > +description: MIPI DSIM Core voltage supply (e.g. 1.1V) > > + > > + vddio-supply: > > +description: MIPI DSIM I/O and PLL voltage supply (e.g. 1.8V) > > + > > + samsung,burst-clock-frequency: > > +$ref: /schemas/types.yaml#/definitions/uint32 > > +description: > > + DSIM high speed burst mode frequency. > > + > > + samsung,esc-clock-frequency: > > +$ref: /schemas/types.yaml#/definitions/uint32 > > +description: > > + DSIM escape mode frequency. > > + > > + samsung,pll-clock-frequency: > > +$ref: /schemas/types.yaml#/definitions/uint32 > > +description: > > + DSIM oscillator clock frequency. > > + > > + ports: > > +$ref: /schemas/graph.yaml#/properties/ports > > + > > +properties: > > + port@0: > > +$ref: /schemas/graph.yaml#/$defs/port-base > > If there are no extra endpoint properties, then use > '/schemas/graph.yaml#/properties/port'. Okay. > > > +description: > > + Input port node to receive pixel data from the > > + display controller. Exactly one endpoint must be > > + specified. > > +properties: > > + endpoint@0: > > +$ref: /schemas/graph.yaml#/properties/endpoint > > +description: sub-node describing the input from MIC > > I'd assume i.MX has a different input than MIC? Yes, updated in next patch. Thanks, Jagan.
Re: [PATCH v2, 1/3] drm/mediatek: Separate aal module
Hi, Yongqiang:
Yongqiang Niu 於 2021年7月12日 週一 上午9:03寫道：
>
> mt8183 aal has no gamma function
Applied to mediatek-drm-next [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/Makefile | 3 +-
> drivers/gpu/drm/mediatek/mtk_disp_aal.c | 166
>
> drivers/gpu/drm/mediatek/mtk_disp_drv.h | 9 ++
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 39 +--
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 +-
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 +
> 6 files changed, 184 insertions(+), 40 deletions(-)
> create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_aal.c
>
> diff --git a/drivers/gpu/drm/mediatek/Makefile
> b/drivers/gpu/drm/mediatek/Makefile
> index dc54a7a..29098d7 100644
> --- a/drivers/gpu/drm/mediatek/Makefile
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0
>
> -mediatek-drm-y := mtk_disp_ccorr.o \
> +mediatek-drm-y := mtk_disp_aal.o \
> + mtk_disp_ccorr.o \
> mtk_disp_color.o \
> mtk_disp_gamma.o \
> mtk_disp_ovl.o \
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> new file mode 100644
> index 000..fb212e96
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> @@ -0,0 +1,166 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2021 MediaTek Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "mtk_disp_drv.h"
> +#include "mtk_drm_crtc.h"
> +#include "mtk_drm_ddp_comp.h"
> +
> +#define DISP_AAL_EN0x
> +#define AAL_EN BIT(0)
> +#define DISP_AAL_SIZE 0x0030
> +
> +
> +struct mtk_disp_aal_data {
> + bool has_gamma;
> +};
> +
> +/**
> + * struct mtk_disp_aal - DISP_AAL driver structure
> + * @ddp_comp - structure containing type enum and hardware resources
> + * @crtc - associated crtc to report irq events to
> + */
> +struct mtk_disp_aal {
> + struct clk *clk;
> + void __iomem *regs;
> + struct cmdq_client_reg cmdq_reg;
> + const struct mtk_disp_aal_data *data;
> +};
> +
> +int mtk_aal_clk_enable(struct device *dev)
> +{
> + struct mtk_disp_aal *aal = dev_get_drvdata(dev);
> +
> + return clk_prepare_enable(aal->clk);
> +}
> +
> +void mtk_aal_clk_disable(struct device *dev)
> +{
> + struct mtk_disp_aal *aal = dev_get_drvdata(dev);
> +
> + clk_disable_unprepare(aal->clk);
> +}
> +
> +void mtk_aal_config(struct device *dev, unsigned int w,
> + unsigned int h, unsigned int vrefresh,
> + unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
> +{
> + struct mtk_disp_aal *aal = dev_get_drvdata(dev);
> +
> + mtk_ddp_write(cmdq_pkt, w << 16 | h, &aal->cmdq_reg, aal->regs,
> DISP_AAL_SIZE);
> +}
> +
> +void mtk_aal_gamma_set(struct device *dev, struct drm_crtc_state *state)
> +{
> + struct mtk_disp_aal *aal = dev_get_drvdata(dev);
> +
> + if (aal->data && aal->data->has_gamma)
> + mtk_gamma_set_common(aal->regs, state);
> +}
> +
> +void mtk_aal_start(struct device *dev)
> +{
> + struct mtk_disp_aal *aal = dev_get_drvdata(dev);
> +
> + writel(AAL_EN, aal->regs + DISP_AAL_EN);
> +}
> +
> +void mtk_aal_stop(struct device *dev)
> +{
> + struct mtk_disp_aal *aal = dev_get_drvdata(dev);
> +
> + writel_relaxed(0x0, aal->regs + DISP_AAL_EN);
> +}
> +
> +static int mtk_disp_aal_bind(struct device *dev, struct device *master,
> + void *data)
> +{
> + return 0;
> +}
> +
> +static void mtk_disp_aal_unbind(struct device *dev, struct device *master,
> + void *data)
> +{
> +}
> +
> +static const struct component_ops mtk_disp_aal_component_ops = {
> + .bind = mtk_disp_aal_bind,
> + .unbind = mtk_disp_aal_unbind,
> +};
> +
> +static int mtk_disp_aal_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct mtk_disp_aal *priv;
> + struct resource *res;
> + int ret;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->clk = devm_clk_get(dev, NULL);
> + if (IS_ERR(priv->clk)) {
> + dev_err(dev, "failed to get aal clk\n");
> + return PTR_ERR(priv->clk);
> + }
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + priv->regs = devm_ioremap_resource(dev, res);
> + if (IS_ERR(priv->regs)) {
> + dev_err(dev, "failed to ioremap aal\n");
> + return PTR_ERR(priv->regs);
> +
Re: [PATCH v2, 2/3] drm/mediatek: add mt8183 aal support
Hi, Yongqiang:
Yongqiang Niu 於 2021年7月12日 週一 上午9:03寫道：
>
> This patch add mt8183 private data
Applied to mediatek-drm-next [1], thanks.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_disp_aal.c | 1 +
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> index fb212e96..64b4528 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_aal.c
> @@ -151,6 +151,7 @@ static int mtk_disp_aal_remove(struct platform_device
> *pdev)
> static const struct of_device_id mtk_disp_aal_driver_dt_match[] = {
> { .compatible = "mediatek,mt8173-disp-aal",
> .data = &mt8173_aal_driver_data},
> + { .compatible = "mediatek,mt8183-disp-aal"},
> {},
> };
> MODULE_DEVICE_TABLE(of, mtk_disp_aal_driver_dt_match);
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 67a585e..143ba24 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -420,6 +420,8 @@ static void mtk_drm_unbind(struct device *dev)
> .data = (void *)MTK_DISP_COLOR },
> { .compatible = "mediatek,mt8173-disp-aal",
> .data = (void *)MTK_DISP_AAL},
> + { .compatible = "mediatek,mt8183-disp-aal",
> + .data = (void *)MTK_DISP_AAL},
> { .compatible = "mediatek,mt8173-disp-gamma",
> .data = (void *)MTK_DISP_GAMMA, },
> { .compatible = "mediatek,mt8183-disp-gamma",
> --
> 1.8.1.1.dirty
>
Re: [PATCH 0/2] Add "BACKGROUND_COLOR" drm property
On 7/9/21 11:23 AM, Simon Ser wrote: > On Friday, July 9th, 2021 at 11:09, Raphael Gallais-Pou > wrote: > >> We don't usually test with piglit and igt-gpu-tools. Instead, modetest >> utility of the libdrm is used quite often (as is it the case in order to >> test this property). > Just to make it extra clear: regardless of how you bring up your driver > implementation, without an IGT test and real-world open-source user-space > patches that make use of the new prop, your patches *cannot* be merged. > > If you're planning to add support for the new prop to an open-source KMS > client, please add a link to the patches in your kernel submission. If > you don't have plans to use the new prop in an open-source KMS client, > let us know and we can discuss what the best candidate would be. Hi, Thanks for your feedback :) We do not have any KMS client currently using this property apart from proprietary solutions made by consumers. This property was originally made to display a logo picture when the screen is in idle (low power/low DDR usage). Regards, Raphaël >> I was also thinking about implementing an option into modetest to ease >> the use of this drm property (support of hexadecimal values for properties). > (For the record, modeset doesn't count as a real-world user-space usage: it's > just a toy implementation, just a test tool.) > > Simon
Re: [PATCH 1/8] drm/i915: Explicitly track DRM clients
On 12/07/2021 15:42, Daniel Vetter wrote: On Mon, Jul 12, 2021 at 01:17:12PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Tracking DRM clients more explicitly will allow later patches to accumulate past and current GPU usage in a centralised place and also consolidate access to owning task pid/name. Unique client id is also assigned for the purpose of distinguishing/ consolidating between multiple file descriptors owned by the same process. v2: Chris Wilson: * Enclose new members into dedicated structs. * Protect against failed sysfs registration. v3: * sysfs_attr_init. v4: * Fix for internal clients. v5: * Use cyclic ida for client id. (Chris) * Do not leak pid reference. (Chris) * Tidy code with some locals. v6: * Use xa_alloc_cyclic to simplify locking. (Chris) * No need to unregister individial sysfs files. (Chris) * Rebase on top of fpriv kref. * Track client closed status and reflect in sysfs. v7: * Make drm_client more standalone concept. v8: * Simplify sysfs show. (Chris) * Always track name and pid. v9: * Fix cyclic id assignment. v10: * No need for a mutex around xa_alloc_cyclic. * Refactor sysfs into own function. * Unregister sysfs before freeing pid and name. * Move clients setup into own function. v11: * Call clients init directly from driver init. (Chris) v12: * Do not fail client add on id wrap. (Maciej) v13 (Lucas): Rebase. v14: * Dropped sysfs bits. Signed-off-by: Tvrtko Ursulin Reviewed-by: Chris Wilson # v11 Reviewed-by: Aravind Iddamsetty # v11 Signed-off-by: Chris Wilson On the implementation: I'm not clear why this is a separate object. All that seems to achieve is make the lifetim fun we have in here even more annoying, for not real gain? What's the reasons for this separate i915_drm_client struct? The commit message talks about de-duping these within the same process, but with fdinfo I'm not seeing the relevance of this anymore. AFAIR I started with the new fields directly in file_priv (note file_priv then needed to be freed via RCU due sysfs access to it!), but then the idea there was to consolidate new members into a separate struct. Plan was (and still is in internal) that the concept for DRM client will gain more users/usefulness and would benefit from encapsulation from the start. For instance at patch 3 in the series it does consolidate i915 users of ctx->pid to go via ctx->client (process name as well). Those are async entry points (compared to file_priv lifetime) from error capture and debugfs. Hm no, debugfs is there no more, only error capture remains. As you say since the change of direction to use fdinfo, the asynchronous entry path into those members from sysfs is gone. Hence if they were moved back to file_priv, and assuming ctx->pid/name changes to be undone, then file_priv could remain being immediately freed on file close. Or perhaps we lose easy pid/name update for files passed over sockets. I'd have to think about that a bit deeper. But essentially I think ctx->client is a cleaner design that ctx->pid and given error capture and debugfs can be async to file_priv lifetime that's a benefit for me. With regards to de-duping multiple fdinfo entries via client->id - that is actually the opposite from what you suggest. Whereas with the sysfs approach we had one entry per client, with fdinfo we have duplicates. So client->id is essential for userspace to correctly account per client statistics. Also, with the fdinfo approach, why do we still need to even track the pid? That can be all figured out from proc now, with much cleaner semantics. Not sure what you mean here. As explained above pid is tracked as replacement for current ctx->pid tracking. So for uses inside i915. Also note that even from userspace semantics of getting the pid from procfs is not necessarily clean, since actually three different file descriptors need to be open to get the whole set of data. /proc//fdinfo/ - obviously /proc//fd/ - to filter out non drm fds avoiding text parsing above file /proc//stat - to get the pid Since in the intel_gpu_top conversion I do keep the /proc/ open and do the rest via openat, I am hoping at least that's safe againt pid swaps. For the file descriptor cross check it is more questionable but worst case the drm fd check via stat could be dropped and replaced with more fdinfo text parsing. Having the pid and process name in fdinfo hence makes this easier and potentially safer. Given how we already store ctx->pid I think that should be fine. FWIW I still think the whole approach is bad since number of operations required scales with number of non drm processes (even threads) on the system. Regards, Tvrtko --- drivers/gpu/drm/i915/Makefile | 5 +- drivers/gpu/drm/i915/i915_drm_client.c | 113 + drivers/gpu/drm/i915/i915_drm_client.h | 61 + drivers/gpu/drm/i915/i915_drv.c|
[PATCH] drm/of: free the iterator object on failure
When bailing out due to the sanity check the iterator value needs to be
freed because the early return prevents for_each_child_of_node() from
doing the dereference itself.
Fixes: 4ee48cc5586b ("drm: of: Fix double-free bug")
Signed-off-by: Steven Price
---
drivers/gpu/drm/drm_of.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Daniel's email[1] made me take a look at this function and it appears
that for_each_child_of_node()'s interface had caused a bad bug fix due
to the hidden reference counting in the iterator.
[1] https://lore.kernel.org/r/YOxQ5TbkNrqCGBDJ%40phenom.ffwll.local
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 197c57477344..997b8827fed2 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -331,8 +331,10 @@ static int drm_of_lvds_get_remote_pixels_type(
* configurations by passing the endpoints explicitly to
* drm_of_lvds_get_dual_link_pixel_order().
*/
- if (!current_pt || pixels_type != current_pt)
+ if (!current_pt || pixels_type != current_pt) {
+ of_node_put(endpoint);
return -EINVAL;
+ }
}
return pixels_type;
--
2.20.1
Re: [PATCH 1/8] drm/i915: Explicitly track DRM clients
On Mon, Jul 12, 2021 at 04:51:42PM +0100, Tvrtko Ursulin wrote: > > On 12/07/2021 15:42, Daniel Vetter wrote: > > On Mon, Jul 12, 2021 at 01:17:12PM +0100, Tvrtko Ursulin wrote: > > > From: Tvrtko Ursulin > > > > > > Tracking DRM clients more explicitly will allow later patches to > > > accumulate past and current GPU usage in a centralised place and also > > > consolidate access to owning task pid/name. > > > > > > Unique client id is also assigned for the purpose of distinguishing/ > > > consolidating between multiple file descriptors owned by the same process. > > > > > > v2: > > > Chris Wilson: > > > * Enclose new members into dedicated structs. > > > * Protect against failed sysfs registration. > > > > > > v3: > > > * sysfs_attr_init. > > > > > > v4: > > > * Fix for internal clients. > > > > > > v5: > > > * Use cyclic ida for client id. (Chris) > > > * Do not leak pid reference. (Chris) > > > * Tidy code with some locals. > > > > > > v6: > > > * Use xa_alloc_cyclic to simplify locking. (Chris) > > > * No need to unregister individial sysfs files. (Chris) > > > * Rebase on top of fpriv kref. > > > * Track client closed status and reflect in sysfs. > > > > > > v7: > > > * Make drm_client more standalone concept. > > > > > > v8: > > > * Simplify sysfs show. (Chris) > > > * Always track name and pid. > > > > > > v9: > > > * Fix cyclic id assignment. > > > > > > v10: > > > * No need for a mutex around xa_alloc_cyclic. > > > * Refactor sysfs into own function. > > > * Unregister sysfs before freeing pid and name. > > > * Move clients setup into own function. > > > > > > v11: > > > * Call clients init directly from driver init. (Chris) > > > > > > v12: > > > * Do not fail client add on id wrap. (Maciej) > > > > > > v13 (Lucas): Rebase. > > > > > > v14: > > > * Dropped sysfs bits. > > > > > > Signed-off-by: Tvrtko Ursulin > > > Reviewed-by: Chris Wilson # v11 > > > Reviewed-by: Aravind Iddamsetty # v11 > > > Signed-off-by: Chris Wilson > > > > On the implementation: I'm not clear why this is a separate object. All > > that seems to achieve is make the lifetim fun we have in here even more > > annoying, for not real gain? > > > > What's the reasons for this separate i915_drm_client struct? The commit > > message talks about de-duping these within the same process, but with > > fdinfo I'm not seeing the relevance of this anymore. > > AFAIR I started with the new fields directly in file_priv (note file_priv > then needed to be freed via RCU due sysfs access to it!), but then the idea > there was to consolidate new members into a separate struct. Yeah separate struct makes sense for this stuff, just to encapsulate/document things a bit. It's the entire scaffolding around it that I don't think makes sense anymore with the design switch to fdinfo. > Plan was (and still is in internal) that the concept for DRM client will > gain more users/usefulness and would benefit from encapsulation from the > start. > > For instance at patch 3 in the series it does consolidate i915 users of > ctx->pid to go via ctx->client (process name as well). Those are async entry > points (compared to file_priv lifetime) from error capture and debugfs. Hm > no, debugfs is there no more, only error capture remains. > > As you say since the change of direction to use fdinfo, the asynchronous > entry path into those members from sysfs is gone. Hence if they were moved > back to file_priv, and assuming ctx->pid/name changes to be undone, then > file_priv could remain being immediately freed on file close. Or perhaps we > lose easy pid/name update for files passed over sockets. I'd have to think > about that a bit deeper. > > But essentially I think ctx->client is a cleaner design that ctx->pid and > given error capture and debugfs can be async to file_priv lifetime that's a > benefit for me. >From a quick check it's just for debug printing when a ctx hung/got banned, and for that we do want the pid - users won't have an understanding of a drm_client. I think pid is actually what we want there. > With regards to de-duping multiple fdinfo entries via client->id - that is > actually the opposite from what you suggest. Whereas with the sysfs approach > we had one entry per client, with fdinfo we have duplicates. So client->id > is essential for userspace to correctly account per client statistics. Uh why? Like if you use fdinfo and have a bunch of duplicate drm_file, then your parsing tool can aggregate them all together under the same pid. No need we do that in the kernel. If the problem is that we can't tell apart a dup'ed fd from multiple open() calls, then I think that should be solved by dropping the hash of the drm_file pointer into the fdinfo. > > Also, with the fdinfo approach, why do we still need to even track the > > pid? That can be all figured out from proc now, with much cleaner > > semantics. > > Not sure what you mean here. As explained above pid is t
Re: [PATCH 1/2] drm: add crtc background color property
On 2021-07-12 4:03 a.m., Pekka Paalanen wrote:
> On Fri, 9 Jul 2021 18:23:26 +0200
> Raphael Gallais-Pou wrote:
>
>> On 7/9/21 10:04 AM, Pekka Paalanen wrote:
>>> On Wed, 7 Jul 2021 08:48:47 +
>>> Raphael GALLAIS-POU - foss wrote:
>>>
Some display controllers can be programmed to present non-black colors
for pixels not covered by any plane (or pixels covered by the
transparent regions of higher planes). Compositors that want a UI with
a solid color background can potentially save memory bandwidth by
setting the CRTC background property and using smaller planes to display
the rest of the content.
To avoid confusion between different ways of encoding RGB data, we
define a standard 64-bit format that should be used for this property's
value. Helper functions and macros are provided to generate and dissect
values in this standard format with varying component precision values.
Signed-off-by: Raphael Gallais-Pou
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_atomic_state_helper.c | 1 +
drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
drivers/gpu/drm/drm_blend.c | 34 +--
drivers/gpu/drm/drm_mode_config.c | 6
include/drm/drm_blend.h | 1 +
include/drm/drm_crtc.h| 12
include/drm/drm_mode_config.h | 5
include/uapi/drm/drm_mode.h | 28 +++
8 files changed, 89 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
b/drivers/gpu/drm/drm_atomic_state_helper.c
index ddcf5c2c8e6a..1b95a4ecdb2b 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -72,6 +72,7 @@ __drm_atomic_helper_crtc_state_reset(struct
drm_crtc_state *crtc_state,
struct drm_crtc *crtc)
{
crtc_state->crtc = crtc;
+ crtc_state->bgcolor = drm_argb(16, 0x, 0, 0, 0);
}
EXPORT_SYMBOL(__drm_atomic_helper_crtc_state_reset);
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 438e9585b225..fea68f8f17f8 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -483,6 +483,8 @@ static int drm_atomic_crtc_set_property(struct
drm_crtc *crtc,
set_out_fence_for_crtc(state->state, crtc, fence_ptr);
} else if (property == crtc->scaling_filter_property) {
state->scaling_filter = val;
+ } else if (property == config->bgcolor_property) {
+ state->bgcolor = val;
} else if (crtc->funcs->atomic_set_property) {
return crtc->funcs->atomic_set_property(crtc, state, property,
val);
} else {
@@ -520,6 +522,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = 0;
else if (property == crtc->scaling_filter_property)
*val = state->scaling_filter;
+ else if (property == config->bgcolor_property)
+ *val = state->bgcolor;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property,
val);
else
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index ec37cbfabb50..6692d6a6db22 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -186,8 +186,7 @@
*assumed to be 1.0
*
* Note that all the property extensions described here apply either to
the
- * plane or the CRTC (e.g. for the background color, which currently is
not
- * exposed and assumed to be black).
+ * plane or the CRTC.
*
* SCALING_FILTER:
* Indicates scaling filter to be used for plane scaler
@@ -201,6 +200,21 @@
*
* Drivers can set up this property for a plane by calling
* drm_plane_create_scaling_filter_property
+ *
>>> Hi,
>>
>>
>> Hi Pekka,
>>
>>
>> Many thanks for your feedback, your comments are taken into account for
>> a v2.
>>
>>
>>>
>>> I assume the below block is the UAPI documentation of this new property
>>> and that it would appear with the other UAPI docs.
>>>
+ * BACKGROUND_COLOR:
+ *Defines the ARGB color of a full-screen layer that exists below
all
+ *planes. This color will be used for pixels not covered by any
plane
+ *and may also be blended with plane contents as allowed by a
plane's
+ *alpha values. The background color defaults to black, and is
assumed
+ *to be black for drivers that do not expose this property.
>>> All good up to here.
>>>
Althou
Re: [PATCH] drm/fourcc: Add modifier definitions for Arm Fixed Rate Compression
On Thu, Jul 01, 2021 at 06:07:09PM +0100, Normunds Rieksts wrote: > Arm Fixed Rate Compression (AFRC) is a proprietary fixed rate image > compression protocol and format. > It is designed to provide guaranteed bandwidth and memory footprint > reductions in graphics and media use-cases. > > This patch aims to add modifier definitions for describing > AFRC. > > Signed-off-by: Normunds Rieksts Looks good to me! Reviewed-by: Liviu Dudau Best regards, Liviu > --- > include/uapi/drm/drm_fourcc.h | 109 +- > 1 file changed, 106 insertions(+), 3 deletions(-) > > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h > index f7156322aba5..9f4bb4a6f358 100644 > --- a/include/uapi/drm/drm_fourcc.h > +++ b/include/uapi/drm/drm_fourcc.h > @@ -900,9 +900,9 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier) > > /* > * The top 4 bits (out of the 56 bits alloted for specifying vendor specific > - * modifiers) denote the category for modifiers. Currently we have only two > - * categories of modifiers ie AFBC and MISC. We can have a maximum of sixteen > - * different categories. > + * modifiers) denote the category for modifiers. Currently we have three > + * categories of modifiers ie AFBC, MISC and AFRC. We can have a maximum of > + * sixteen different categories. > */ > #define DRM_FORMAT_MOD_ARM_CODE(__type, __val) \ > fourcc_mod_code(ARM, ((__u64)(__type) << 52) | ((__val) & > 0x000fULL)) > @@ -1017,6 +1017,109 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 > modifier) > */ > #define AFBC_FORMAT_MOD_USM (1ULL << 12) > > +/* > + * Arm Fixed-Rate Compression (AFRC) modifiers > + * > + * AFRC is a proprietary fixed rate image compression protocol and format, > + * designed to provide guaranteed bandwidth and memory footprint > + * reductions in graphics and media use-cases. > + * > + * AFRC buffers consist of one or more planes, with the same components > + * and meaning as an uncompressed buffer using the same pixel format. > + * > + * Within each plane, the pixel/luma/chroma values are grouped into > + * "coding unit" blocks which are individually compressed to a > + * fixed size (in bytes). All coding units within a given plane of a buffer > + * store the same number of values, and have the same compressed size. > + * > + * The coding unit size is configurable, allowing different rates of > compression. > + * > + * The start of each AFRC buffer plane must be aligned to an alignment > granule which > + * depends on the coding unit size. > + * > + * Coding Unit Size Plane Alignment > + * --- > + * 16 bytes 1024 bytes > + * 24 bytes 512 bytes > + * 32 bytes 2048 bytes > + * > + * Coding units are grouped into paging tiles. AFRC buffer dimensions must > be aligned > + * to a multiple of the paging tile dimensions. > + * The dimensions of each paging tile depend on whether the buffer is > optimised for > + * scanline (SCAN layout) or rotated (ROT layout) access. > + * > + * Layout Paging Tile Width Paging Tile Height > + * -- - -- > + * SCAN 16 coding units 4 coding units > + * ROT 8 coding units 8 coding units > + * > + * The dimensions of each coding unit depend on the number of components > + * in the compressed plane and whether the buffer is optimised for > + * scanline (SCAN layout) or rotated (ROT layout) access. > + * > + * Number of Components in Plane Layout Coding Unit Width Coding > Unit Height > + * - - - > -- > + * 1 SCAN16 samples 4 samples > + * Example: 16x4 luma samples in a 'Y' plane > + * 16x4 chroma 'V' values, in the 'V' plane of a fully-planar YUV > buffer > + * - - - > -- > + * 1 ROT 8 samples 8 samples > + * Example: 8x8 luma samples in a 'Y' plane > + * 8x8 chroma 'V' values, in the 'V' plane of a fully-planar YUV > buffer > + * - - - > -- > + * 2 DONT CARE 8 samples 4 samples > + * Example: 8x4 chroma pairs in the 'UV' plane of a semi-planar YUV buffer > + * - - - > -- > + * 3 DONT CARE 4 samples 4 samples > + * Example: 4x4 pixels in an RGB buffer without alpha > + * - - - > -- > + * 4 DONT CARE 4 samples 4 samples > + * Example: 4x4 pixels in an RGB buffer with alpha > + */ > + > +#define DRM_FORMAT_MOD_ARM_TYPE_AFRC 0x02 > + > +#define DRM_FORMAT
Re: [PATCH v2 1/2] dt-bindings: display: rockchip: Add compatible for rk3568 HDMI
On Wed, 07 Jul 2021 14:03:22 +0200, Benjamin Gaignard wrote: > Define a new compatible for rk3568 HDMI. > This version of HDMI hardware block needs two new clocks hclk_vio and hclk > to provide phy reference clocks. > > Signed-off-by: Benjamin Gaignard > --- > version 2: > - Add the clocks needed for the phy. > > .../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring
Re: drm/i915/ttm Initialize the ttm device and memory managers
On Mon, 12 Jul 2021 at 16:17, Colin Ian King wrote:
>
> Hi,
>
> Static analysis with Coverity on linux-next has found a potential issue
> in drivers/gpu/drm/i915/selftests/intel_memory_region.c in function
> igt_mock_fill - the problematic commit is as follows:
>
> commit d148738923fdb5077089e48ec1e6008100d0
> Author: Thomas Hellström
> Date: Wed Jun 2 10:38:08 2021 +0200
>
> drm/i915/ttm Initialize the ttm device and memory managers
>
> The analysis is as follows:
>
>
> 49 static int igt_mock_fill(void *arg)
> 50 {
> 51struct intel_memory_region *mem = arg;
> 52resource_size_t total = resource_size(&mem->region);
> 53resource_size_t page_size;
> 54resource_size_t rem;
> 55unsigned long max_pages;
> 56unsigned long page_num;
> 57LIST_HEAD(objects);
> 58int err = 0;
> 59
> 60page_size = mem->chunk_size;
> 61rem = total;
> 62 retry:
>
> value_overwrite: Overwriting previous write to max_pages with value from
> div64_u64(rem, page_size).
>
> 63max_pages = div64_u64(rem, page_size);
> 64
> 65for_each_prime_number_from(page_num, 1, max_pages) {
> 66resource_size_t size = page_num * page_size;
> 67struct drm_i915_gem_object *obj;
> 68
> 69obj = i915_gem_object_create_region(mem, size, 0);
> 70if (IS_ERR(obj)) {
> 71err = PTR_ERR(obj);
> 72break;
> 73}
> 74
> 75err = i915_gem_object_pin_pages_unlocked(obj);
> 76if (err) {
> 77i915_gem_object_put(obj);
> 78break;
> 79}
> 80
> 81list_add(&obj->st_link, &objects);
> 82rem -= size;
> 83}
> 84
> 85if (err == -ENOMEM)
> 86err = 0;
> 87if (err == -ENXIO) {
> 88if (page_num * page_size <= rem) {
> 89if (mem->is_range_manager && max_pages > 1) {
>
> Unused value (UNUSED_VALUE)
> assigned_value: Assigning value from max_pages >> 1 to max_pages here,
> but that stored value is overwritten before it can be used.
Yeah, that doesn't look good.
AFAIK this should be fixed with d53ec322dc7d ("drm/i915/ttm: switch
over to ttm_buddy_man"), which is in drm-tip, but I guess has not made
its way over to linux-next yet.
Thanks for the report.
>
> 90max_pages >>= 1;
> 91goto retry;
> 92}
> 93
>
> The right shift to max_pages on line 90 is being overwritten on line 64
> on the retry.
>
> Colin
Re: [PATCH] drm/fourcc: Add modifier definitions for Arm Fixed Rate Compression
Thanks a lot for the documentation, I appreciate the effort.
Re: [PATCH] drm/of: free the iterator object on failure
Hi Steven,
Thank you for the patch.
On Mon, Jul 12, 2021 at 04:57:58PM +0100, Steven Price wrote:
> When bailing out due to the sanity check the iterator value needs to be
> freed because the early return prevents for_each_child_of_node() from
> doing the dereference itself.
>
> Fixes: 4ee48cc5586b ("drm: of: Fix double-free bug")
I don't think the Fixes tag is correct, the issue was already present
before 4ee48cc5586b. The fix looks right though.
> Signed-off-by: Steven Price
> ---
> drivers/gpu/drm/drm_of.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> Daniel's email[1] made me take a look at this function and it appears
> that for_each_child_of_node()'s interface had caused a bad bug fix due
> to the hidden reference counting in the iterator.
>
> [1] https://lore.kernel.org/r/YOxQ5TbkNrqCGBDJ%40phenom.ffwll.local
>
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index 197c57477344..997b8827fed2 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -331,8 +331,10 @@ static int drm_of_lvds_get_remote_pixels_type(
>* configurations by passing the endpoints explicitly to
>* drm_of_lvds_get_dual_link_pixel_order().
>*/
> - if (!current_pt || pixels_type != current_pt)
> + if (!current_pt || pixels_type != current_pt) {
> + of_node_put(endpoint);
> return -EINVAL;
> + }
> }
>
> return pixels_type;
--
Regards,
Laurent Pinchart
Aw: Re: [PATCH] soc: mediatek: mmsys: fix HDMI output on mt7623/bananapi-r2
Hi, it turns out that problem is the read+or of the new value i reverted my patch and changed reg = readl_relaxed(mmsys->regs + routes[i].addr) | routes[i].val; writel_relaxed(reg, mmsys->regs + routes[i].addr); to writel_relaxed(routes[i].val, mmsys->regs + routes[i].addr); and it works too, but maybe it breaks other platforms regards Frank
Re: [PATCH 1/2 v3] drm/panel: Add DT bindings for Samsung LMS380KF01
On Thu, 08 Jul 2021 01:43:14 +0200, Linus Walleij wrote: > This adds device tree bindings for the Samsung Mobile Displays > LMS380KF01 RGB DPI display panel. > > Cc: devicet...@vger.kernel.org > Cc: phone-de...@vger.kernel.org > Cc: Douglas Anderson > Cc: Noralf Trønnes > Signed-off-by: Linus Walleij > --- > ChangeLog v2->v3: > - No changes just resending with the series. > ChangeLog v1->v2: > - Expect SPI bindings to be pulled in for the client and state > spi-cpha: true etc. > - Make port a required node. > - Update the example to use a proper SPI controller (spi-gpio) > so we get full validation of the example. > --- > .../display/panel/samsung,lms380kf01.yaml | 97 +++ > 1 file changed, 97 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/samsung,lms380kf01.yaml > Reviewed-by: Rob Herring
Re: Aw: Re: [PATCH] soc: mediatek: mmsys: fix HDMI output on mt7623/bananapi-r2
Hi, On 12.07.21 19:16, Frank Wunderlich wrote: Hi, it turns out that problem is the read+or of the new value i reverted my patch and changed reg = readl_relaxed(mmsys->regs + routes[i].addr) | routes[i].val; writel_relaxed(reg, mmsys->regs + routes[i].addr); to writel_relaxed(routes[i].val, mmsys->regs + routes[i].addr); and it works too, but maybe it breaks other platforms Interesting, I can test if it fix that similar bug on mt8173 when resume from suspend. Thanks, Dafna regards Frank
Re: [PATCH 17/47] drm/i915/guc: Extend deregistration fence to schedule disable
On 7/9/2021 20:36, Matthew Brost wrote:
On Fri, Jul 09, 2021 at 03:59:11PM -0700, John Harrison wrote:
On 6/24/2021 00:04, Matthew Brost wrote:
Extend the deregistration context fence to fence whne a GuC context has
scheduling disable pending.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 37 +++
1 file changed, 30 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 0386ccd5a481..0a6ccdf32316 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -918,7 +918,19 @@ static void guc_context_sched_disable(struct intel_context
*ce)
goto unpin;
spin_lock_irqsave(&ce->guc_state.lock, flags);
+
+ /*
+* We have to check if the context has been pinned again as another pin
+* operation is allowed to pass this function. Checking the pin count
+* here synchronizes this function with guc_request_alloc ensuring a
+* request doesn't slip through the 'context_pending_disable' fence.
+*/
The pin count is an atomic so doesn't need the spinlock. Also the above
How about?
/*
* We have to check if the context has been pinned again as another pin
* operation is allowed to pass this function. Checking the pin count,
* within ce->guc_state.lock, synchronizes this function with
* guc_request_alloc ensuring a request doesn't slip through the
* 'context_pending_disable' fence. Checking within the spin lock (can't
* sleep) ensures another process doesn't pin this context and generate
* a request before we set the 'context_pending_disable' flag here.
*/
Matt
Sounds good. With that added in:
Reviewed-by: John Harrison
comment 'checking the pin count here synchronizes ...' seems wrong. Isn't
the point that acquiring the spinlock is what synchronises with
guc_request_alloc? So the comment should be before the spinlock acquire and
should mention using the spinlock for this purpose?
John.
+ if (unlikely(atomic_add_unless(&ce->pin_count, -2, 2))) {
+ spin_unlock_irqrestore(&ce->guc_state.lock, flags);
+ return;
+ }
guc_id = prep_context_pending_disable(ce);
+
spin_unlock_irqrestore(&ce->guc_state.lock, flags);
with_intel_runtime_pm(runtime_pm, wakeref)
@@ -1123,19 +1135,22 @@ static int guc_request_alloc(struct i915_request *rq)
out:
/*
* We block all requests on this context if a G2H is pending for a
-* context deregistration as the GuC will fail a context registration
-* while this G2H is pending. Once a G2H returns, the fence is released
-* that is blocking these requests (see guc_signal_context_fence).
+* schedule disable or context deregistration as the GuC will fail a
+* schedule enable or context registration if either G2H is pending
+* respectfully. Once a G2H returns, the fence is released that is
+* blocking these requests (see guc_signal_context_fence).
*
-* We can safely check the below field outside of the lock as it isn't
-* possible for this field to transition from being clear to set but
+* We can safely check the below fields outside of the lock as it isn't
+* possible for these fields to transition from being clear to set but
* converse is possible, hence the need for the check within the lock.
*/
- if (likely(!context_wait_for_deregister_to_register(ce)))
+ if (likely(!context_wait_for_deregister_to_register(ce) &&
+ !context_pending_disable(ce)))
return 0;
spin_lock_irqsave(&ce->guc_state.lock, flags);
- if (context_wait_for_deregister_to_register(ce)) {
+ if (context_wait_for_deregister_to_register(ce) ||
+ context_pending_disable(ce)) {
i915_sw_fence_await(&rq->submit);
list_add_tail(&rq->guc_fence_link, &ce->guc_state.fences);
@@ -1484,10 +1499,18 @@ int intel_guc_sched_done_process_msg(struct intel_guc
*guc,
if (context_pending_enable(ce)) {
clr_context_pending_enable(ce);
} else if (context_pending_disable(ce)) {
+ /*
+* Unpin must be done before __guc_signal_context_fence,
+* otherwise a race exists between the requests getting
+* submitted + retired before this unpin completes resulting in
+* the pin_count going to zero and the context still being
+* enabled.
+*/
intel_context_sched_disable_unpin(ce);
spin_lock_irqsave(&ce->guc_state.lock, flags);
clr_context_pending_disable(ce);
+ __guc_signal_context_fence(ce);
spin_unlock_irqrestore(&ce->guc_state.lock
Re: [PATCH 16/47] drm/i915/guc: Disable engine barriers with GuC during unpin
On 7/9/2021 20:00, Matthew Brost wrote:
On Fri, Jul 09, 2021 at 03:53:29PM -0700, John Harrison wrote:
On 6/24/2021 00:04, Matthew Brost wrote:
Disable engine barriers for unpinning with GuC. This feature isn't
needed with the GuC as it disables context scheduling before unpinning
which guarantees the HW will not reference the context. Hence it is
not necessary to defer unpinning until a kernel context request
completes on each engine in the context engine mask.
Cc: John Harrison
Signed-off-by: Matthew Brost
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_context.c| 2 +-
drivers/gpu/drm/i915/gt/intel_context.h| 1 +
drivers/gpu/drm/i915/gt/selftest_context.c | 10 ++
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 1499b8aace2a..7f97753ab164 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -80,7 +80,7 @@ static int intel_context_active_acquire(struct intel_context
*ce)
__i915_active_acquire(&ce->active);
- if (intel_context_is_barrier(ce))
+ if (intel_context_is_barrier(ce) || intel_engine_uses_guc(ce->engine))
return 0;
Would be better to have a scheduler flag to say whether barriers are
required or not. That would prevent polluting front end code with back end
details.
I guess an engine flag is slightly better but I still don't love that
as we have to test if the context is a barrier (kernel context) and then
call a function that is basically backend specific after. IMO we really
need to push all of this to a vfunc. If you really want me to make this
an engine flag I can, but in the end it just seems like that will
trash the code (adding an engine flag just to remove it). I think this
is just a clean up we write down, and figure out a bit later as nothing
is functionally wrong + quite clear that it is something that should be
cleaned up.
Matt
Flag, vfunc, whatever. I just mean that it would be better to abstract
it out in some manner. Maybe a flag/vfunc on the ce object? That way it
would swallow the 'ignore kernel contexts' test as well. But yes,
probably best to add it to the todo list and move on as it is not going
to be a two minute quick fix. I've added a comment to the Jira, so...
Reviewed-by: John Harrison
John.
/* Preallocate tracking nodes */
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 8a7199afbe61..a592a9605dc8 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -16,6 +16,7 @@
#include "intel_engine_types.h"
#include "intel_ring_types.h"
#include "intel_timeline_types.h"
+#include "uc/intel_guc_submission.h"
#define CE_TRACE(ce, fmt, ...) do { \
const struct intel_context *ce__ = (ce);\
diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c
b/drivers/gpu/drm/i915/gt/selftest_context.c
index 26685b927169..fa7b99a671dd 100644
--- a/drivers/gpu/drm/i915/gt/selftest_context.c
+++ b/drivers/gpu/drm/i915/gt/selftest_context.c
@@ -209,7 +209,13 @@ static int __live_active_context(struct intel_engine_cs
*engine)
* This test makes sure that the context is kept alive until a
* subsequent idle-barrier (emitted when the engine wakeref hits 0
* with no more outstanding requests).
+*
+* In GuC submission mode we don't use idle barriers and we instead
+* get a message from the GuC to signal that it is safe to unpin the
+* context from memory.
*/
+ if (intel_engine_uses_guc(engine))
+ return 0;
if (intel_engine_pm_is_awake(engine)) {
pr_err("%s is awake before starting %s!\n",
@@ -357,7 +363,11 @@ static int __live_remote_context(struct intel_engine_cs
*engine)
* on the context image remotely (intel_context_prepare_remote_request),
* which inserts foreign fences into intel_context.active, does not
* clobber the idle-barrier.
+*
+* In GuC submission mode we don't use idle barriers.
*/
+ if (intel_engine_uses_guc(engine))
+ return 0;
if (intel_engine_pm_is_awake(engine)) {
pr_err("%s is awake before starting %s!\n",
Re: [PATCH 0/4] vkms: Switch to shadow-buffered plane state
Hi Am 12.07.21 um 16:26 schrieb Sumera Priyadarsini: On Mon, Jul 12, 2021 at 6:53 PM Thomas Zimmermann wrote: Hi Am 12.07.21 um 13:56 schrieb Sumera Priyadarsini: On Mon, Jul 5, 2021 at 1:16 PM Thomas Zimmermann wrote: Vkms copies each plane's framebuffer into the output buffer; essentially using a shadow buffer. DRM provides struct drm_shadow_plane_state, which handles the details of mapping/unmapping shadow buffers into memory for active planes. Convert vkms to the helpers. Makes vkms use shared code and gives more test exposure to shadow-plane helpers. Thomas Zimmermann (4): drm/gem: Export implementation of shadow-plane helpers drm/vkms: Inherit plane state from struct drm_shadow_plane_state drm/vkms: Let shadow-plane helpers prepare the plane's FB drm/vkms: Use dma-buf mapping from shadow-plane state for composing drivers/gpu/drm/drm_gem_atomic_helper.c | 55 ++-- drivers/gpu/drm/vkms/vkms_composer.c| 26 ++- drivers/gpu/drm/vkms/vkms_drv.h | 6 ++- drivers/gpu/drm/vkms/vkms_plane.c | 57 ++--- include/drm/drm_gem_atomic_helper.h | 6 +++ 5 files changed, 86 insertions(+), 64 deletions(-) base-commit: 3d3b5479895dd6dd133571ded4318adf595708ba -- 2.32.0 Hi, Thanks for the patches. The switch to shadow-plane helpers also solved a bug that was causing a kernel panic during some IGT kms_flip subtests on the vkms virtual hw patch. Melissa mention something like that as well and I don't really understand. Patch 3 removes an error message from the code, but is the actual bug also gone? Yes, I think so. Earlier, while testing the vkms virtual hw patch, the tests were not just failing, but the vmap fail also preceeded a page fault which required a whole restart. Check these logs around line 303: https://pastebin.pl/view/03b750be. With the help of your log, I can see what's happening. The current vkms code reports an error in vmap, but does nothing about it. [1] So later during the commit, it operates with a bogus value for vaddr. The shared helper returns the error into the atomic modesetting machinery, [2] which then aborts the commit. It never gets to the point of using an invalid address. So no kernel panic occurs. I could be wrong but I think if the same bug was still present, then the kernel panic would also happen even if the error message was not being returned. I'm pretty sure the vmap issue is still there. But as the shared code handles it correctly without a notice to the kernel log; and it doesn't crash the kernel any longer. But the vmap problem is caused by some other factor unrelated to vkms. Booting the test kernel with drm.debug=0x1ff on the kernel command line would probably turn up some sort of error message. Best regards Thomas [1] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/vkms/vkms_plane.c#L166 [2] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_gem_atomic_helper.c#L299 Cheers, Sumera There's little difference between vkms' original code and the shared helper; except for the order of operations in prepare_fb. The shared helper synchronizes fences before mapping; vkms mapped first. (Maybe the shared helper should warn about failed vmaps as well. But that's for another patch.) Best regards Thomas Tested-by: Sumera Priyadarsini Cheers, Sumera -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH 23/47] drm/i915/guc: Update GuC debugfs to support new GuC
On 6/24/2021 00:04, Matthew Brost wrote:
Update GuC debugfs to support the new GuC structures.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 22
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 3 ++
.../gpu/drm/i915/gt/uc/intel_guc_debugfs.c| 23 +++-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 52 +++
.../gpu/drm/i915/gt/uc/intel_guc_submission.h | 4 ++
drivers/gpu/drm/i915/i915_debugfs.c | 1 +
6 files changed, 104 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index e0f92e28350c..4ed074df88e5 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -1135,3 +1135,25 @@ void intel_guc_ct_event_handler(struct intel_guc_ct *ct)
ct_try_receive_message(ct);
}
+
+void intel_guc_log_ct_info(struct intel_guc_ct *ct,
+ struct drm_printer *p)
+{
+ if (!ct->enabled) {
+ drm_puts(p, "CT disabled\n");
+ return;
+ }
+
+ drm_printf(p, "H2G Space: %u\n",
+ atomic_read(&ct->ctbs.send.space) * 4);
+ drm_printf(p, "Head: %u\n",
+ ct->ctbs.send.desc->head);
+ drm_printf(p, "Tail: %u\n",
+ ct->ctbs.send.desc->tail);
+ drm_printf(p, "G2H Space: %u\n",
+ atomic_read(&ct->ctbs.recv.space) * 4);
+ drm_printf(p, "Head: %u\n",
+ ct->ctbs.recv.desc->head);
+ drm_printf(p, "Tail: %u\n",
+ ct->ctbs.recv.desc->tail);
+}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
index ab1b79ab960b..f62eb06b32fc 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
@@ -16,6 +16,7 @@
struct i915_vma;
struct intel_guc;
+struct drm_printer;
/**
* DOC: Command Transport (CT).
@@ -106,4 +107,6 @@ int intel_guc_ct_send(struct intel_guc_ct *ct, const u32
*action, u32 len,
u32 *response_buf, u32 response_buf_size, u32 flags);
void intel_guc_ct_event_handler(struct intel_guc_ct *ct);
+void intel_guc_log_ct_info(struct intel_guc_ct *ct, struct drm_printer *p);
+
#endif /* _INTEL_GUC_CT_H_ */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_debugfs.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_debugfs.c
index fe7cb7b29a1e..62b9ce0fafaa 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_debugfs.c
@@ -9,6 +9,8 @@
#include "intel_guc.h"
#include "intel_guc_debugfs.h"
#include "intel_guc_log_debugfs.h"
+#include "gt/uc/intel_guc_ct.h"
+#include "gt/uc/intel_guc_submission.h"
static int guc_info_show(struct seq_file *m, void *data)
{
@@ -22,16 +24,35 @@ static int guc_info_show(struct seq_file *m, void *data)
drm_puts(&p, "\n");
intel_guc_log_info(&guc->log, &p);
- /* Add more as required ... */
+ if (!intel_guc_submission_is_used(guc))
+ return 0;
+
+ intel_guc_log_ct_info(&guc->ct, &p);
+ intel_guc_log_submission_info(guc, &p);
return 0;
}
DEFINE_GT_DEBUGFS_ATTRIBUTE(guc_info);
+static int guc_registered_contexts_show(struct seq_file *m, void *data)
+{
+ struct intel_guc *guc = m->private;
+ struct drm_printer p = drm_seq_file_printer(m);
+
+ if (!intel_guc_submission_is_used(guc))
+ return -ENODEV;
+
+ intel_guc_log_context_info(guc, &p);
+
+ return 0;
+}
+DEFINE_GT_DEBUGFS_ATTRIBUTE(guc_registered_contexts);
+
void intel_guc_debugfs_register(struct intel_guc *guc, struct dentry *root)
{
static const struct debugfs_gt_file files[] = {
{ "guc_info", &guc_info_fops, NULL },
+ { "guc_registered_contexts", &guc_registered_contexts_fops,
NULL },
};
if (!intel_guc_is_supported(guc))
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index d1a28283a9ae..89b3c7e5d15b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1600,3 +1600,55 @@ int intel_guc_sched_done_process_msg(struct intel_guc
*guc,
return 0;
}
+
+void intel_guc_log_submission_info(struct intel_guc *guc,
+ struct drm_printer *p)
+{
+ struct i915_sched_engine *sched_engine = guc->sched_engine;
+ struct rb_node *rb;
+ unsigned long flags;
+
+ drm_printf(p, "GuC Number Outstanding Submission G2H: %u\n",
+ atomic_read(&guc->outstanding_submission_g2h));
+ drm_printf(p, "GuC tasklet count: %u\n\n",
+ atomic_read(&sched_engine->tasklet.count));
Does sched_engine need a null check?
+
+ spin_lock_irqsave(&sched_engine->lock, flag
Re: [PATCH 24/47] drm/i915/guc: Add several request trace points
On 6/24/2021 00:04, Matthew Brost wrote:
Add trace points for request dependencies and GuC submit. Extended
existing request trace points to include submit fence value,, guc_id,
Excessive punctuation. Or maybe should say 'fence value, tail, guc_id'?
With that fixed:
Reviewed-by: John Harrison
and ring tail value.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 ++
drivers/gpu/drm/i915/i915_request.c | 3 ++
drivers/gpu/drm/i915/i915_trace.h | 39 ++-
3 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 89b3c7e5d15b..c2327eebc09c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -422,6 +422,7 @@ static int guc_dequeue_one_context(struct intel_guc *guc)
guc->stalled_request = last;
return false;
}
+ trace_i915_request_guc_submit(last);
}
guc->stalled_request = NULL;
@@ -642,6 +643,8 @@ static int guc_bypass_tasklet_submit(struct intel_guc *guc,
ret = guc_add_request(guc, rq);
if (ret == -EBUSY)
guc->stalled_request = rq;
+ else
+ trace_i915_request_guc_submit(rq);
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index d92c9f25c9f4..7f7aa096e873 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1344,6 +1344,9 @@ __i915_request_await_execution(struct i915_request *to,
return err;
}
+ trace_i915_request_dep_to(to);
+ trace_i915_request_dep_from(from);
+
/* Couple the dependency tree for PI on this exposed to->fence */
if (to->engine->sched_engine->schedule) {
err = i915_sched_node_add_dependency(&to->sched,
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 6778ad2a14a4..b02d04b6c8f6 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -794,22 +794,27 @@ DECLARE_EVENT_CLASS(i915_request,
TP_STRUCT__entry(
__field(u32, dev)
__field(u64, ctx)
+__field(u32, guc_id)
__field(u16, class)
__field(u16, instance)
__field(u32, seqno)
+__field(u32, tail)
),
TP_fast_assign(
__entry->dev = rq->engine->i915->drm.primary->index;
__entry->class = rq->engine->uabi_class;
__entry->instance = rq->engine->uabi_instance;
+ __entry->guc_id = rq->context->guc_id;
__entry->ctx = rq->fence.context;
__entry->seqno = rq->fence.seqno;
+ __entry->tail = rq->tail;
),
- TP_printk("dev=%u, engine=%u:%u, ctx=%llu, seqno=%u",
+ TP_printk("dev=%u, engine=%u:%u, guc_id=%u, ctx=%llu, seqno=%u,
tail=%u",
__entry->dev, __entry->class, __entry->instance,
- __entry->ctx, __entry->seqno)
+ __entry->guc_id, __entry->ctx, __entry->seqno,
+ __entry->tail)
);
DEFINE_EVENT(i915_request, i915_request_add,
@@ -818,6 +823,21 @@ DEFINE_EVENT(i915_request, i915_request_add,
);
#if defined(CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS)
+DEFINE_EVENT(i915_request, i915_request_dep_to,
+TP_PROTO(struct i915_request *rq),
+TP_ARGS(rq)
+);
+
+DEFINE_EVENT(i915_request, i915_request_dep_from,
+TP_PROTO(struct i915_request *rq),
+TP_ARGS(rq)
+);
+
+DEFINE_EVENT(i915_request, i915_request_guc_submit,
+TP_PROTO(struct i915_request *rq),
+TP_ARGS(rq)
+);
+
DEFINE_EVENT(i915_request, i915_request_submit,
TP_PROTO(struct i915_request *rq),
TP_ARGS(rq)
@@ -887,6 +907,21 @@ TRACE_EVENT(i915_request_out,
#else
#if !defined(TRACE_HEADER_MULTI_READ)
+static inline void
+trace_i915_request_dep_to(struct i915_request *rq)
+{
+}
+
+static inline void
+trace_i915_request_dep_from(struct i915_request *rq)
+{
+}
+
+static inline void
+trace_i915_request_guc_submit(struct i915_request *rq)
+{
+}
+
static inline void
trace_i915_request_submit(struct i915_request *rq)
{
Re: [PATCH 25/47] drm/i915: Add intel_context tracing
On 6/24/2021 00:04, Matthew Brost wrote:
Add intel_context tracing. These trace points are particular helpful
when debugging the GuC firmware and can be enabled via
CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS kernel config option.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 6 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 14 ++
drivers/gpu/drm/i915/i915_trace.h | 148 +-
3 files changed, 166 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 7f97753ab164..b24a1b7a3f88 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -8,6 +8,7 @@
#include "i915_drv.h"
#include "i915_globals.h"
+#include "i915_trace.h"
#include "intel_context.h"
#include "intel_engine.h"
@@ -28,6 +29,7 @@ static void rcu_context_free(struct rcu_head *rcu)
{
struct intel_context *ce = container_of(rcu, typeof(*ce), rcu);
+ trace_intel_context_free(ce);
kmem_cache_free(global.slab_ce, ce);
}
@@ -46,6 +48,7 @@ intel_context_create(struct intel_engine_cs *engine)
return ERR_PTR(-ENOMEM);
intel_context_init(ce, engine);
+ trace_intel_context_create(ce);
return ce;
}
@@ -268,6 +271,8 @@ int __intel_context_do_pin_ww(struct intel_context *ce,
GEM_BUG_ON(!intel_context_is_pinned(ce)); /* no overflow! */
+ trace_intel_context_do_pin(ce);
+
err_unlock:
mutex_unlock(&ce->pin_mutex);
err_post_unpin:
@@ -323,6 +328,7 @@ void __intel_context_do_unpin(struct intel_context *ce, int
sub)
*/
intel_context_get(ce);
intel_context_active_release(ce);
+ trace_intel_context_do_unpin(ce);
intel_context_put(ce);
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index c2327eebc09c..d605af0d66e6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -348,6 +348,7 @@ static int guc_add_request(struct intel_guc *guc, struct
i915_request *rq)
err = intel_guc_send_nb(guc, action, len, g2h_len_dw);
if (!enabled && !err) {
+ trace_intel_context_sched_enable(ce);
atomic_inc(&guc->outstanding_submission_g2h);
set_context_enabled(ce);
} else if (!enabled) {
@@ -812,6 +813,8 @@ static int register_context(struct intel_context *ce)
u32 offset = intel_guc_ggtt_offset(guc, guc->lrc_desc_pool) +
ce->guc_id * sizeof(struct guc_lrc_desc);
+ trace_intel_context_register(ce);
+
return __guc_action_register_context(guc, ce->guc_id, offset);
}
@@ -831,6 +834,8 @@ static int deregister_context(struct intel_context *ce, u32 guc_id)
{
struct intel_guc *guc = ce_to_guc(ce);
+ trace_intel_context_deregister(ce);
+
return __guc_action_deregister_context(guc, guc_id);
}
@@ -905,6 +910,7 @@ static int guc_lrc_desc_pin(struct intel_context *ce)
* GuC before registering this context.
*/
if (context_registered) {
+ trace_intel_context_steal_guc_id(ce);
set_context_wait_for_deregister_to_register(ce);
intel_context_get(ce);
@@ -963,6 +969,7 @@ static void __guc_context_sched_disable(struct intel_guc *guc,
GEM_BUG_ON(guc_id == GUC_INVALID_LRC_ID);
+ trace_intel_context_sched_disable(ce);
intel_context_get(ce);
guc_submission_busy_loop(guc, action, ARRAY_SIZE(action),
@@ -1119,6 +1126,9 @@ static void __guc_signal_context_fence(struct
intel_context *ce)
lockdep_assert_held(&ce->guc_state.lock);
+ if (!list_empty(&ce->guc_state.fences))
+ trace_intel_context_fence_release(ce);
+
list_for_each_entry(rq, &ce->guc_state.fences, guc_fence_link)
i915_sw_fence_complete(&rq->submit);
@@ -1529,6 +1539,8 @@ int intel_guc_deregister_done_process_msg(struct intel_guc *guc,
if (unlikely(!ce))
return -EPROTO;
+ trace_intel_context_deregister_done(ce);
+
if (context_wait_for_deregister_to_register(ce)) {
struct intel_runtime_pm *runtime_pm =
&ce->engine->gt->i915->runtime_pm;
@@ -1580,6 +1592,8 @@ int intel_guc_sched_done_process_msg(struct intel_guc
*guc,
return -EPROTO;
}
+ trace_intel_context_sched_done(ce);
+
if (context_pending_enable(ce)) {
clr_context_pending_enable(ce);
} else if (context_pending_disable(ce)) {
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index b02d04b6c8f6..97c2e83984ed 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -818,8 +818,8 @@ DECLARE_EVENT_CLASS(i915_request,
);
DEFI
Re: [Intel-gfx] [PATCH 16/47] drm/i915/guc: Disable engine barriers with GuC during unpin
On Mon, Jul 12, 2021 at 7:57 PM John Harrison wrote:
>
> On 7/9/2021 20:00, Matthew Brost wrote:
> > On Fri, Jul 09, 2021 at 03:53:29PM -0700, John Harrison wrote:
> >> On 6/24/2021 00:04, Matthew Brost wrote:
> >>> Disable engine barriers for unpinning with GuC. This feature isn't
> >>> needed with the GuC as it disables context scheduling before unpinning
> >>> which guarantees the HW will not reference the context. Hence it is
> >>> not necessary to defer unpinning until a kernel context request
> >>> completes on each engine in the context engine mask.
> >>>
> >>> Cc: John Harrison
> >>> Signed-off-by: Matthew Brost
> >>> Signed-off-by: Daniele Ceraolo Spurio
> >>> ---
> >>>drivers/gpu/drm/i915/gt/intel_context.c| 2 +-
> >>>drivers/gpu/drm/i915/gt/intel_context.h| 1 +
> >>>drivers/gpu/drm/i915/gt/selftest_context.c | 10 ++
> >>>3 files changed, 12 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> >>> b/drivers/gpu/drm/i915/gt/intel_context.c
> >>> index 1499b8aace2a..7f97753ab164 100644
> >>> --- a/drivers/gpu/drm/i915/gt/intel_context.c
> >>> +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> >>> @@ -80,7 +80,7 @@ static int intel_context_active_acquire(struct
> >>> intel_context *ce)
> >>> __i915_active_acquire(&ce->active);
> >>> - if (intel_context_is_barrier(ce))
> >>> + if (intel_context_is_barrier(ce) || intel_engine_uses_guc(ce->engine))
> >>> return 0;
> >> Would be better to have a scheduler flag to say whether barriers are
> >> required or not. That would prevent polluting front end code with back end
> >> details.
> >>
> > I guess an engine flag is slightly better but I still don't love that
> > as we have to test if the context is a barrier (kernel context) and then
> > call a function that is basically backend specific after. IMO we really
> > need to push all of this to a vfunc. If you really want me to make this
> > an engine flag I can, but in the end it just seems like that will
> > trash the code (adding an engine flag just to remove it). I think this
> > is just a clean up we write down, and figure out a bit later as nothing
> > is functionally wrong + quite clear that it is something that should be
> > cleaned up.
> >
> > Matt
> Flag, vfunc, whatever. I just mean that it would be better to abstract
> it out in some manner. Maybe a flag/vfunc on the ce object? That way it
> would swallow the 'ignore kernel contexts' test as well. But yes,
> probably best to add it to the todo list and move on as it is not going
> to be a two minute quick fix. I've added a comment to the Jira, so...
The plan is:
- merge guc backend
- convert over to drm/scheduler as a proper interface between higher
levels and the scheduler backend
- shovel as much as reasonable of the execlist specifics into the
execlist backend
Right now our frontend code is essentially designed to assume the
execlist backend is the true way to build a scheduler, and everything
else is a special case. We can't reasonable fix this by sprinkling
lots of vfuns all over the place, and hence we imo shouldn't try, at
least not until the big picture is in much better shape.
-Daniel
> Reviewed-by: John Harrison
>
>
> >
> >> John.
> >>
> >>
> >>> /* Preallocate tracking nodes */
> >>> diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> >>> b/drivers/gpu/drm/i915/gt/intel_context.h
> >>> index 8a7199afbe61..a592a9605dc8 100644
> >>> --- a/drivers/gpu/drm/i915/gt/intel_context.h
> >>> +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> >>> @@ -16,6 +16,7 @@
> >>>#include "intel_engine_types.h"
> >>>#include "intel_ring_types.h"
> >>>#include "intel_timeline_types.h"
> >>> +#include "uc/intel_guc_submission.h"
> >>>#define CE_TRACE(ce, fmt, ...) do {
> >>> \
> >>> const struct intel_context *ce__ = (ce);\
> >>> diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c
> >>> b/drivers/gpu/drm/i915/gt/selftest_context.c
> >>> index 26685b927169..fa7b99a671dd 100644
> >>> --- a/drivers/gpu/drm/i915/gt/selftest_context.c
> >>> +++ b/drivers/gpu/drm/i915/gt/selftest_context.c
> >>> @@ -209,7 +209,13 @@ static int __live_active_context(struct
> >>> intel_engine_cs *engine)
> >>> * This test makes sure that the context is kept alive until a
> >>> * subsequent idle-barrier (emitted when the engine wakeref hits 0
> >>> * with no more outstanding requests).
> >>> +*
> >>> +* In GuC submission mode we don't use idle barriers and we instead
> >>> +* get a message from the GuC to signal that it is safe to unpin the
> >>> +* context from memory.
> >>> */
> >>> + if (intel_engine_uses_guc(engine))
> >>> + return 0;
> >>> if (intel_engine_pm_is_awake(engine)) {
> >>> pr_err("%s is awake before starting %s!\n",
> >>> @@ -357,7 +363,11 @@ static int __live_remote_context(struct
> >>> intel_engine_cs *engine)
Re: [PATCH 27/47] drm/i915: Track 'serial' counts for virtual engines
On 6/24/2021 00:04, Matthew Brost wrote:
From: John Harrison
The serial number tracking of engines happens at the backend of
request submission and was expecting to only be given physical
engines. However, in GuC submission mode, the decomposition of virtual
to physical engines does not happen in i915. Instead, requests are
submitted to their virtual engine mask all the way through to the
hardware (i.e. to GuC). This would mean that the heart beat code
thinks the physical engines are idle due to the serial number not
incrementing.
This patch updates the tracking to decompose virtual engines into
their physical constituents and tracks the request against each. This
is not entirely accurate as the GuC will only be issuing the request
to one physical engine. However, it is the best that i915 can do given
that it has no knowledge of the GuC's scheduling decisions.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Need to pull in the updated subject line and commit description from
Tvrtko in the RFC patch set review.
John.
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 ++
.../gpu/drm/i915/gt/intel_execlists_submission.c | 6 ++
drivers/gpu/drm/i915/gt/intel_ring_submission.c | 6 ++
drivers/gpu/drm/i915/gt/mock_engine.c| 6 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c| 16
drivers/gpu/drm/i915/i915_request.c | 4 +++-
6 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 5b91068ab277..1dc59e6c9a92 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -388,6 +388,8 @@ struct intel_engine_cs {
void(*park)(struct intel_engine_cs *engine);
void(*unpark)(struct intel_engine_cs *engine);
+ void (*bump_serial)(struct intel_engine_cs *engine);
+
void(*set_default_submission)(struct intel_engine_cs
*engine);
const struct intel_context_ops *cops;
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index bd4ced794ff9..9cfb8800a0e6 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -3203,6 +3203,11 @@ static void execlists_release(struct intel_engine_cs
*engine)
lrc_fini_wa_ctx(engine);
}
+static void execlist_bump_serial(struct intel_engine_cs *engine)
+{
+ engine->serial++;
+}
+
static void
logical_ring_default_vfuncs(struct intel_engine_cs *engine)
{
@@ -3212,6 +3217,7 @@ logical_ring_default_vfuncs(struct intel_engine_cs
*engine)
engine->cops = &execlists_context_ops;
engine->request_alloc = execlists_request_alloc;
+ engine->bump_serial = execlist_bump_serial;
engine->reset.prepare = execlists_reset_prepare;
engine->reset.rewind = execlists_reset_rewind;
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 5d42a12ef3d6..e1506b280df1 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -1044,6 +1044,11 @@ static void setup_irq(struct intel_engine_cs *engine)
}
}
+static void ring_bump_serial(struct intel_engine_cs *engine)
+{
+ engine->serial++;
+}
+
static void setup_common(struct intel_engine_cs *engine)
{
struct drm_i915_private *i915 = engine->i915;
@@ -1063,6 +1068,7 @@ static void setup_common(struct intel_engine_cs *engine)
engine->cops = &ring_context_ops;
engine->request_alloc = ring_request_alloc;
+ engine->bump_serial = ring_bump_serial;
/*
* Using a global execution timeline; the previous final breadcrumb is
diff --git a/drivers/gpu/drm/i915/gt/mock_engine.c
b/drivers/gpu/drm/i915/gt/mock_engine.c
index 68970398e4ef..9203c766db80 100644
--- a/drivers/gpu/drm/i915/gt/mock_engine.c
+++ b/drivers/gpu/drm/i915/gt/mock_engine.c
@@ -292,6 +292,11 @@ static void mock_engine_release(struct intel_engine_cs
*engine)
intel_engine_fini_retire(engine);
}
+static void mock_bump_serial(struct intel_engine_cs *engine)
+{
+ engine->serial++;
+}
+
struct intel_engine_cs *mock_engine(struct drm_i915_private *i915,
const char *name,
int id)
@@ -318,6 +323,7 @@ struct intel_engine_cs *mock_engine(struct drm_i915_private
*i915,
engine->base.cops = &mock_context_ops;
engine->base.request_alloc = mock_request_alloc;
+ engine->base.bump_serial = mock_bump_serial;
engine->base.emit_flush = mock_emit_flush;
engine->base.emit_fini_breadcrumb = mock_emit_breadcrumb;
engine->base.submit_request = mock_submit_request;
diff --git a/drivers/gpu/drm/i915/gt/u
[PATCH] drm/mediatek: Test component initialization earlier in the function mtk_drm_crtc_create
The initialization is currently tested in a later stage in
the function for no reason.
In addition, the test '!comp' will never fail since comp is
set with the '&' operator. Instead, test if a comp was not
initialized by testing "!comp->dev".
Signed-off-by: Dafna Hirschfeld
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 474efb844249..06f40e589922 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -755,14 +755,22 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
for (i = 0; i < path_len; i++) {
enum mtk_ddp_comp_id comp_id = path[i];
struct device_node *node;
+ struct mtk_ddp_comp *comp;
node = priv->comp_node[comp_id];
+ comp = &priv->ddp_comp[comp_id];
+
if (!node) {
dev_info(dev,
"Not creating crtc %d because component %d is
disabled or missing\n",
pipe, comp_id);
return 0;
}
+
+ if (!comp->dev) {
+ dev_err(dev, "Component %pOF not initialized\n", node);
+ return -ENODEV;
+ }
}
mtk_crtc = devm_kzalloc(dev, sizeof(*mtk_crtc), GFP_KERNEL);
@@ -787,16 +795,8 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
enum mtk_ddp_comp_id comp_id = path[i];
struct mtk_ddp_comp *comp;
- struct device_node *node;
- node = priv->comp_node[comp_id];
comp = &priv->ddp_comp[comp_id];
- if (!comp) {
- dev_err(dev, "Component %pOF not initialized\n", node);
- ret = -ENODEV;
- return ret;
- }
-
mtk_crtc->ddp_comp[i] = comp;
if (comp->funcs) {
--
2.17.1
Re: [PATCH 28/47] drm/i915: Hold reference to intel_context over life of i915_request
On 6/24/2021 00:04, Matthew Brost wrote:
Hold a reference to the intel_context over life of an i915_request.
Without this an i915_request can exist after the context has been
destroyed (e.g. request retired, context closed, but user space holds a
reference to the request from an out fence). In the case of GuC
submission + virtual engine, the engine that the request references is
also destroyed which can trigger bad pointer dref in fence ops (e.g.
Maybe quickly explain a why this is different for GuC submission vs
execlist? Presumably it is about only decomposing virtual engines to
physical ones in execlist mode?
i915_fence_get_driver_name). We could likely change
i915_fence_get_driver_name to avoid touching the engine but let's just
be safe and hold the intel_context reference.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/i915_request.c | 54 -
1 file changed, 22 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index de9deb95b8b1..dec5a35c9aa2 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -126,39 +126,17 @@ static void i915_fence_release(struct dma_fence *fence)
i915_sw_fence_fini(&rq->semaphore);
/*
-* Keep one request on each engine for reserved use under mempressure
-*
-* We do not hold a reference to the engine here and so have to be
-* very careful in what rq->engine we poke. The virtual engine is
-* referenced via the rq->context and we released that ref during
-* i915_request_retire(), ergo we must not dereference a virtual
-* engine here. Not that we would want to, as the only consumer of
-* the reserved engine->request_pool is the power management parking,
-* which must-not-fail, and that is only run on the physical engines.
-*
-* Since the request must have been executed to be have completed,
-* we know that it will have been processed by the HW and will
-* not be unsubmitted again, so rq->engine and rq->execution_mask
-* at this point is stable. rq->execution_mask will be a single
-* bit if the last and _only_ engine it could execution on was a
-* physical engine, if it's multiple bits then it started on and
-* could still be on a virtual engine. Thus if the mask is not a
-* power-of-two we assume that rq->engine may still be a virtual
-* engine and so a dangling invalid pointer that we cannot dereference
-*
-* For example, consider the flow of a bonded request through a virtual
-* engine. The request is created with a wide engine mask (all engines
-* that we might execute on). On processing the bond, the request mask
-* is reduced to one or more engines. If the request is subsequently
-* bound to a single engine, it will then be constrained to only
-* execute on that engine and never returned to the virtual engine
-* after timeslicing away, see __unwind_incomplete_requests(). Thus we
-* know that if the rq->execution_mask is a single bit, rq->engine
-* can be a physical engine with the exact corresponding mask.
+* Keep one request on each engine for reserved use under mempressure,
+* do not use with virtual engines as this really is only needed for
+* kernel contexts.
*/
- if (is_power_of_2(rq->execution_mask) &&
- !cmpxchg(&rq->engine->request_pool, NULL, rq))
+ if (!intel_engine_is_virtual(rq->engine) &&
+ !cmpxchg(&rq->engine->request_pool, NULL, rq)) {
+ intel_context_put(rq->context);
return;
+ }
+
+ intel_context_put(rq->context);
The put is actually unconditional? So it could be moved before the if?
John.
kmem_cache_free(global.slab_requests, rq);
}
@@ -977,7 +955,18 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp)
}
}
- rq->context = ce;
+ /*
+* Hold a reference to the intel_context over life of an i915_request.
+* Without this an i915_request can exist after the context has been
+* destroyed (e.g. request retired, context closed, but user space holds
+* a reference to the request from an out fence). In the case of GuC
+* submission + virtual engine, the engine that the request references
+* is also destroyed which can trigger bad pointer dref in fence ops
+* (e.g. i915_fence_get_driver_name). We could likely change these
+* functions to avoid touching the engine but let's just be safe and
+* hold the intel_context reference.
+*/
+ rq->context = intel_context_get(ce);
rq->engine = ce->engine;
rq->ring = ce->ring;
rq->execution_mask = ce->engine->mask;
@@ -1054,6 +1043,7 @@ __i915_request_create(struct intel_
Re: [PATCH 29/47] drm/i915/guc: Disable bonding extension with GuC submission
On 6/24/2021 00:04, Matthew Brost wrote:
Update the bonding extension to return -ENODEV when using GuC submission
as this extension fundamentally will not work with the GuC submission
interface.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 8a9293e0ca92..0429aa4172bf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1674,6 +1674,11 @@ set_engines__bond(struct i915_user_extension __user
*base, void *data)
}
virtual = set->engines->engines[idx]->engine;
+ if (intel_engine_uses_guc(virtual)) {
+ DRM_DEBUG("bonding extension not supported with GuC
submission");
+ return -ENODEV;
+ }
+
err = check_user_mbz(&ext->flags);
if (err)
return err;
Re: [PATCH 02/16] drm/i915/guc/slpc: Initial definitions for slpc
On 7/10/2021 7:27 AM, Michal Wajdeczko wrote:
Hi Vinay,
On 10.07.2021 03:20, Vinay Belgaumkar wrote:
Add macros to check for slpc support. This feature is currently supported
for gen12+ and enabled whenever guc submission is enabled/selected.
please try to use consistent names across all patches:
s/slpc/SLPC
s/gen12/Gen12
s/guc/GuC
Signed-off-by: Vinay Belgaumkar
Signed-off-by: Sundaresan Sujaritha
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 21 +++
.../gpu/drm/i915/gt/uc/intel_guc_submission.h | 16 ++
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 --
drivers/gpu/drm/i915/gt/uc/intel_uc.h | 1 +
6 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 979128e28372..b9a809f2d221 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -157,6 +157,7 @@ void intel_guc_init_early(struct intel_guc *guc)
intel_guc_ct_init_early(&guc->ct);
intel_guc_log_init_early(&guc->log);
intel_guc_submission_init_early(guc);
+ intel_guc_slpc_init_early(guc);
mutex_init(&guc->send_mutex);
spin_lock_init(&guc->irq_lock);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 5d94cf482516..e5a456918b88 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -57,6 +57,8 @@ struct intel_guc {
bool submission_supported;
bool submission_selected;
+ bool slpc_supported;
+ bool slpc_selected;
struct i915_vma *ads_vma;
struct __guc_ads_blob *ads_blob;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 9c102bf0c8e3..e2644a05f298 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2351,6 +2351,27 @@ void intel_guc_submission_init_early(struct intel_guc
*guc)
guc->submission_selected = __guc_submission_selected(guc);
}
+static bool __guc_slpc_supported(struct intel_guc *guc)
hmm, easy to confuse with intel_guc_slpc_is_supported, so maybe:
__detect_slpc_supported()
ok.
(yes, I know you were following code above)
+{
+ /* GuC slpc is unavailable for pre-Gen12 */
s/slpc/SLPC
+ return guc->submission_supported &&
+ GRAPHICS_VER(guc_to_gt(guc)->i915) >= 12;
+}
+
+static bool __guc_slpc_selected(struct intel_guc *guc)
+{
+ if (!intel_guc_slpc_is_supported(guc))
+ return false;
+
+ return guc->submission_selected;
+}
+
+void intel_guc_slpc_init_early(struct intel_guc *guc)
+{
+ guc->slpc_supported = __guc_slpc_supported(guc);
+ guc->slpc_selected = __guc_slpc_selected(guc);
+}
in patch 4/16 you are introducing intel_guc_slpc.c|h so to have proper
encapsulation better to define this function as
void intel_guc_slpc_init_early(struct intel_guc_slpc *slpc) { }
the uc_state_checkers force the use of struct intel_guc *guc as the
param. don't think I can change that to refer to slpc instead.
static inline bool intel_guc_slpc_is_supported(struct intel_guc *guc)
{
return guc->slpc_supported;
}
slpc_supported needs to be inside the guc struct.
and move it to intel_guc_slpc.c
+
static inline struct intel_context *
g2h_context_lookup(struct intel_guc *guc, u32 desc_idx)
{
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
index be767eb6ff71..7ae5fd052faf 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
@@ -13,6 +13,7 @@
struct drm_printer;
struct intel_engine_cs;
+void intel_guc_slpc_init_early(struct intel_guc *guc);
it really does not belong to this .h
void intel_guc_submission_init_early(struct intel_guc *guc);
int intel_guc_submission_init(struct intel_guc *guc);
void intel_guc_submission_enable(struct intel_guc *guc);
@@ -50,4 +51,19 @@ static inline bool intel_guc_submission_is_used(struct
intel_guc *guc)
return intel_guc_is_used(guc) && intel_guc_submission_is_wanted(guc);
}
+static inline bool intel_guc_slpc_is_supported(struct intel_guc *guc)
+{
+ return guc->slpc_supported;
+}
+
+static inline bool intel_guc_slpc_is_wanted(struct intel_guc *guc)
+{
+ return guc->slpc_selected;
+}
+
+static inline bool intel_guc_slpc_is_used(struct intel_guc *guc)
+{
+ return intel_guc_submission_is_used(guc) &&
intel_guc_slpc_is_wanted(guc);
+}
did you try to define them in intel_guc_slpc.h ?
note that to avoid circular dependencies you can define slpc struct in
intel_guc_slpc_types.h and then
Re: Linux 5.14-rc1
On Mon, Jul 12, 2021 at 12:08 AM Jon Masters wrote:
>
> I happened to be installing a Fedora 34 (x86) VM for something and did a
> test kernel compile that hung on boot. Setting up a serial console I get
> the below backtrace from ttm but I have not had chance to look at it.
It's a NULL pointer in qxl_bo_delete_mem_notify(), with the code
disassembling to
16: 55push %rbp
17: 48 89 fd mov%rdi,%rbp
1a: e8 a2 02 00 00callq 0x2c1
1f: 84 c0test %al,%al
21: 74 0dje 0x30
23: 48 8b 85 68 01 00 00 mov0x168(%rbp),%rax
2a:* 83 78 10 03 cmpl $0x3,0x10(%rax) <-- trapping instruction
2e: 74 02je 0x32
30: 5dpop%rbp
31: c3retq
and that "cmpl $3" looks exactly like that
if (bo->resource->mem_type == TTM_PL_PRIV
and the bug is almost certainly from commit d3116756a710 ("drm/ttm:
rename bo->mem and make it a pointer"), which did
- if (bo->mem.mem_type == TTM_PL_PRIV ...
+ if (bo->resource->mem_type == TTM_PL_PRIV ...
and claimed "No functional change".
But clearly the "bo->resource" pointer is NULL.
Added guilty parties and dri-devel mailing list.
Christian? Full report at
https://lore.kernel.org/lkml/a9473821-1d53-0037-7590-aeaf8e85e...@jonmasters.org/
but there's not a whole lot else there that is interesting except for
the call trace:
ttm_bo_cleanup_memtype_use+0x22/0x60 [ttm]
ttm_bo_release+0x1a1/0x300 [ttm]
ttm_bo_delayed_delete+0x1be/0x220 [ttm]
ttm_device_delayed_workqueue+0x18/0x40 [ttm]
process_one_work+0x1ec/0x390
worker_thread+0x53/0x3e0
so it's presumably the cleanup phase and perhaps "bo->resource" has
been deallocated and cleared?
Linus
Re: [PATCH 30/47] drm/i915/guc: Direct all breadcrumbs for a class to single breadcrumbs
On 6/24/2021 00:04, Matthew Brost wrote:
With GuC virtual engines the physical engine which a request executes
and completes on isn't known to the i915. Therefore we can't attach a
request to a physical engines breadcrumbs. To work around this we create
a single breadcrumbs per engine class when using GuC submission and
direct all physical engine interrupts to this breadcrumbs.
Signed-off-by: Matthew Brost
CC: John Harrison
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 41 +---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.h | 14 +++-
.../gpu/drm/i915/gt/intel_breadcrumbs_types.h | 7 ++
drivers/gpu/drm/i915/gt/intel_engine.h| 3 +
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 28 +++-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 -
.../drm/i915/gt/intel_execlists_submission.c | 2 +-
drivers/gpu/drm/i915/gt/mock_engine.c | 4 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 67 +--
9 files changed, 131 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 38cc42783dfb..2007dc6f6b99 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -15,28 +15,14 @@
#include "intel_gt_pm.h"
#include "intel_gt_requests.h"
-static bool irq_enable(struct intel_engine_cs *engine)
+static bool irq_enable(struct intel_breadcrumbs *b)
{
- if (!engine->irq_enable)
- return false;
-
- /* Caller disables interrupts */
- spin_lock(&engine->gt->irq_lock);
- engine->irq_enable(engine);
- spin_unlock(&engine->gt->irq_lock);
-
- return true;
+ return intel_engine_irq_enable(b->irq_engine);
}
-static void irq_disable(struct intel_engine_cs *engine)
+static void irq_disable(struct intel_breadcrumbs *b)
{
- if (!engine->irq_disable)
- return;
-
- /* Caller disables interrupts */
- spin_lock(&engine->gt->irq_lock);
- engine->irq_disable(engine);
- spin_unlock(&engine->gt->irq_lock);
+ intel_engine_irq_disable(b->irq_engine);
}
static void __intel_breadcrumbs_arm_irq(struct intel_breadcrumbs *b)
@@ -57,7 +43,7 @@ static void __intel_breadcrumbs_arm_irq(struct
intel_breadcrumbs *b)
WRITE_ONCE(b->irq_armed, true);
/* Requests may have completed before we could enable the interrupt. */
- if (!b->irq_enabled++ && irq_enable(b->irq_engine))
+ if (!b->irq_enabled++ && b->irq_enable(b))
irq_work_queue(&b->irq_work);
}
@@ -76,7 +62,7 @@ static void __intel_breadcrumbs_disarm_irq(struct intel_breadcrumbs *b)
{
GEM_BUG_ON(!b->irq_enabled);
if (!--b->irq_enabled)
- irq_disable(b->irq_engine);
+ b->irq_disable(b);
WRITE_ONCE(b->irq_armed, false);
intel_gt_pm_put_async(b->irq_engine->gt);
@@ -281,7 +267,7 @@ intel_breadcrumbs_create(struct intel_engine_cs *irq_engine)
if (!b)
return NULL;
- b->irq_engine = irq_engine;
+ kref_init(&b->ref);
spin_lock_init(&b->signalers_lock);
INIT_LIST_HEAD(&b->signalers);
@@ -290,6 +276,10 @@ intel_breadcrumbs_create(struct intel_engine_cs
*irq_engine)
spin_lock_init(&b->irq_lock);
init_irq_work(&b->irq_work, signal_irq_work);
+ b->irq_engine = irq_engine;
+ b->irq_enable = irq_enable;
+ b->irq_disable = irq_disable;
+
return b;
}
@@ -303,9 +293,9 @@ void intel_breadcrumbs_reset(struct intel_breadcrumbs *b)
spin_lock_irqsave(&b->irq_lock, flags);
if (b->irq_enabled)
- irq_enable(b->irq_engine);
+ b->irq_enable(b);
else
- irq_disable(b->irq_engine);
+ b->irq_disable(b);
spin_unlock_irqrestore(&b->irq_lock, flags);
}
@@ -325,11 +315,14 @@ void __intel_breadcrumbs_park(struct intel_breadcrumbs *b)
}
}
-void intel_breadcrumbs_free(struct intel_breadcrumbs *b)
+void intel_breadcrumbs_free(struct kref *kref)
{
+ struct intel_breadcrumbs *b = container_of(kref, typeof(*b), ref);
+
irq_work_sync(&b->irq_work);
GEM_BUG_ON(!list_empty(&b->signalers));
GEM_BUG_ON(b->irq_armed);
+
kfree(b);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.h b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.h
index 3ce5ce270b04..72105b74663d 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.h
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.h
@@ -17,7 +17,7 @@ struct intel_breadcrumbs;
struct intel_breadcrumbs *
intel_breadcrumbs_create(struct intel_engine_cs *irq_engine);
-void intel_breadcrumbs_free(struct intel_breadcrumbs *b);
+void intel_breadcrumbs_free(struct kref *kref);
void intel_breadcrumbs_reset(struct intel_breadcrumbs *b);
void __intel_breadcrumbs_park(struct intel_breadcrumbs *b);
@@ -48,4 +48,16 @@ void i915_reque
Re: Linux 5.14-rc1
Hi guys,
Am 12.07.21 um 21:14 schrieb Linus Torvalds:
On Mon, Jul 12, 2021 at 12:08 AM Jon Masters wrote:
I happened to be installing a Fedora 34 (x86) VM for something and did a
test kernel compile that hung on boot. Setting up a serial console I get
the below backtrace from ttm but I have not had chance to look at it.
It's a NULL pointer in qxl_bo_delete_mem_notify(), with the code
disassembling to
16: 55push %rbp
17: 48 89 fd mov%rdi,%rbp
1a: e8 a2 02 00 00callq 0x2c1
1f: 84 c0test %al,%al
21: 74 0dje 0x30
23: 48 8b 85 68 01 00 00 mov0x168(%rbp),%rax
2a:* 83 78 10 03 cmpl $0x3,0x10(%rax) <-- trapping instruction
2e: 74 02je 0x32
30: 5dpop%rbp
31: c3retq
and that "cmpl $3" looks exactly like that
if (bo->resource->mem_type == TTM_PL_PRIV
and the bug is almost certainly from commit d3116756a710 ("drm/ttm:
rename bo->mem and make it a pointer"), which did
- if (bo->mem.mem_type == TTM_PL_PRIV ...
+ if (bo->resource->mem_type == TTM_PL_PRIV ...
and claimed "No functional change".
But clearly the "bo->resource" pointer is NULL.
Added guilty parties and dri-devel mailing list.
Christian? Full report at
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2Fa9473821-1d53-0037-7590-aeaf8e85e72a%40jonmasters.org%2F&data=04%7C01%7Cchristian.koenig%40amd.com%7C06dd885408e84008a9a208d945694d9f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637617140858341274%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UlqsiWTjfJZ4%2FeIJJMh1AeCqs5SeFjNG%2F22UiuVAIII%3D&reserved=0
but there's not a whole lot else there that is interesting except for
the call trace:
ttm_bo_cleanup_memtype_use+0x22/0x60 [ttm]
ttm_bo_release+0x1a1/0x300 [ttm]
ttm_bo_delayed_delete+0x1be/0x220 [ttm]
ttm_device_delayed_workqueue+0x18/0x40 [ttm]
process_one_work+0x1ec/0x390
worker_thread+0x53/0x3e0
so it's presumably the cleanup phase and perhaps "bo->resource" has
been deallocated and cleared?
That's a known issue. Fixed by:
commit 3efe180d5105d367ae1dfadb97892ab93a89a783
Author: Christian König
Date: Tue Jul 6 08:51:25 2021 +0200
drm/qxl: add NULL check for bo->resource
When allocations fails that can be NULL now.
Previously the structure was embedded into the buffer object and when
allocation failed (or never happened in a temporary buffer) the
structure was just zeroed.
Going to double check tomorrow why that hasn't showed up in your tree yet.
Christian.
Linus
[PATCH 0/3] drm/amdgpu: modernize virtual display feature
The amdgpu vkms interface provides a virtual KMS interface for several use cases: devices without display hardware, platforms where the actual display hardware is not useful (e.g., servers), SR-IOV virtual functions, device emulation/simulation, and device bring up prior to display hardware being usable. We previously emulated a legacy KMS interface, but there was a desire to move to the atomic KMS interface. The vkms driver did everything we needed, but we wanted KMS support natively in the driver without buffer sharing and the ability to support an instance of VKMS per device. We first looked at splitting vkms into a stub driver and a helper module that other drivers could use to implement a virtual display, but this strategy ended up being messy due to driver specific callbacks needed for buffer management. Ultimately, it proved easier to import the vkms code as it mostly used core drm helpers anyway. Ryan Taylor (3): drm/amdgpu: create amdgpu_vkms drm/amdgpu: cleanup dce_virtual drm/amdgpu: replace dce_virtual with amdgpu_vkms drivers/gpu/drm/amd/amdgpu/Makefile | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 605 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.h | 26 + drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 780 --- drivers/gpu/drm/amd/amdgpu/dce_virtual.h | 30 - drivers/gpu/drm/amd/amdgpu/nv.c | 20 +- drivers/gpu/drm/amd/amdgpu/soc15.c | 10 +- drivers/gpu/drm/amd/amdgpu/vi.c | 14 +- 11 files changed, 657 insertions(+), 835 deletions(-) create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.h delete mode 100644 drivers/gpu/drm/amd/amdgpu/dce_virtual.c delete mode 100644 drivers/gpu/drm/amd/amdgpu/dce_virtual.h -- 2.32.0
[PATCH 1/3] drm/amdgpu: create amdgpu_vkms
Modify the VKMS driver into an api that dce_virtual can use to create
virtual displays that obey drm's atomic modesetting api.
Signed-off-by: Ryan Taylor
---
drivers/gpu/drm/amd/amdgpu/Makefile | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 410 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.h | 29 ++
drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 23 +-
7 files changed, 457 insertions(+), 11 deletions(-)
create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.h
diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
b/drivers/gpu/drm/amd/amdgpu/Makefile
index 7d292485ca7c..dfcf3b39a2f6 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -119,6 +119,7 @@ amdgpu-y += \
amdgpu-y += \
dce_v10_0.o \
dce_v11_0.o \
+ amdgpu_vkms.o \
dce_virtual.o
# add GFX block
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index d14b4968a026..a0198963fc8a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -912,6 +912,7 @@ struct amdgpu_device {
/* display */
boolenable_virtual_display;
+ struct amdgpu_vkms_output *amdgpu_vkms_output;
struct amdgpu_mode_info mode_info;
/* For pre-DCE11. DCE11 and later are in "struct amdgpu_device->dm" */
struct work_struct hotplug_work;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 179f2d01a082..5c774d6625e4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1222,7 +1222,7 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
int ret, retry = 0;
bool supports_atomic = false;
- if (!amdgpu_virtual_display &&
+ if (amdgpu_virtual_display ||
amdgpu_device_asic_has_dc_support(flags & AMD_ASIC_MASK))
supports_atomic = true;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 09b048647523..5a143ca02cf9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -344,7 +344,7 @@ int amdgpu_fbdev_init(struct amdgpu_device *adev)
}
/* disable all the possible outputs/crtcs before entering KMS mode */
- if (!amdgpu_device_has_dc_support(adev))
+ if (!amdgpu_device_has_dc_support(adev) && !amdgpu_virtual_display)
drm_helper_disable_unused_functions(adev_to_drm(adev));
drm_fb_helper_initial_config(&rfbdev->helper, bpp_sel);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
new file mode 100644
index ..58bd0d7b4602
--- /dev/null
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
@@ -0,0 +1,410 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include
+#include
+#include
+
+#include "amdgpu.h"
+#include "amdgpu_vkms.h"
+#include "amdgpu_display.h"
+
+/**
+ * DOC: amdgpu_vkms
+ *
+ * The amdgpu vkms interface provides a virtual KMS interface for several use
+ * cases: devices without display hardware, platforms where the actual display
+ * hardware is not useful (e.g., servers), SR-IOV virtual functions, device
+ * emulation/simulation, and device bring up prior to display hardware being
+ * usable. We previously emulated a legacy KMS interface, but there was a
desire
+ * to move to the atomic KMS interface. The vkms driver did everything we
+ * needed, but we wanted KMS support natively in the driver without buffer
+ * sharing and the ability to support an instance of VKMS per device. We first
+ * looked at splitting vkms into a stub driver and a helper module that other
+ * drivers could use to implement a virtual display, but this strategy ended up
+ * being messy due to driver specific callbacks needed for buffer management.
+ * Ultimately, it proved easier to import the vkms code as it mostly used core
+ * drm helpers anyway.
+ */
+
+static const u32 amdgpu_vkms_formats[] = {
+ DRM_FORMAT_XRGB,
+};
+
+static enum hrtimer_restart amdgpu_vkms_vblank_simulate(struct hrtimer *timer)
+{
+ struct amdgpu_vkms_output *output = container_of(timer,
+struct
amdgpu_vkms_output,
+vblank_hrtimer);
+ struct drm_crtc *crtc = &output->crtc;
+ u64 ret_overrun;
+ bool ret;
+
+ ret_overrun = hrtimer_forward_now(&output->vblank_hrtimer,
+ output->period_ns);
+ WARN_ON(ret_overrun != 1);
+
+ ret = drm_crtc_handle_vblank(crtc);
+ if (!ret)
+ DRM_ERROR("a
[PATCH 2/3] drm/amdgpu: cleanup dce_virtual
Remove obsolete functions and variables from dce_virtual.
Signed-off-by: Ryan Taylor
---
drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 568 +--
1 file changed, 3 insertions(+), 565 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
index 642c77533157..18369b47eac7 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
@@ -21,15 +21,9 @@
*
*/
-#include
#include
#include "amdgpu.h"
-#include "amdgpu_pm.h"
-#include "amdgpu_i2c.h"
-#include "atom.h"
-#include "amdgpu_pll.h"
-#include "amdgpu_connectors.h"
#ifdef CONFIG_DRM_AMDGPU_SI
#include "dce_v6_0.h"
#endif
@@ -43,339 +37,6 @@
#include "amdgpu_display.h"
#include "amdgpu_vkms.h"
-#define DCE_VIRTUAL_VBLANK_PERIOD 1666
-
-
-static void dce_virtual_set_display_funcs(struct amdgpu_device *adev);
-static void dce_virtual_set_irq_funcs(struct amdgpu_device *adev);
-static int dce_virtual_connector_encoder_init(struct amdgpu_device *adev,
- int index);
-static int dce_virtual_pageflip(struct amdgpu_device *adev,
- unsigned crtc_id);
-static enum hrtimer_restart dce_virtual_vblank_timer_handle(struct hrtimer
*vblank_timer);
-static void dce_virtual_set_crtc_vblank_interrupt_state(struct amdgpu_device
*adev,
- int crtc,
- enum
amdgpu_interrupt_state state);
-
-static u32 dce_virtual_vblank_get_counter(struct amdgpu_device *adev, int crtc)
-{
- return 0;
-}
-
-static void dce_virtual_page_flip(struct amdgpu_device *adev,
- int crtc_id, u64 crtc_base, bool async)
-{
- return;
-}
-
-static int dce_virtual_crtc_get_scanoutpos(struct amdgpu_device *adev, int
crtc,
- u32 *vbl, u32 *position)
-{
- *vbl = 0;
- *position = 0;
-
- return -EINVAL;
-}
-
-static bool dce_virtual_hpd_sense(struct amdgpu_device *adev,
- enum amdgpu_hpd_id hpd)
-{
- return true;
-}
-
-static void dce_virtual_hpd_set_polarity(struct amdgpu_device *adev,
- enum amdgpu_hpd_id hpd)
-{
- return;
-}
-
-static u32 dce_virtual_hpd_get_gpio_reg(struct amdgpu_device *adev)
-{
- return 0;
-}
-
-/**
- * dce_virtual_bandwidth_update - program display watermarks
- *
- * @adev: amdgpu_device pointer
- *
- * Calculate and program the display watermarks and line
- * buffer allocation (CIK).
- */
-static void dce_virtual_bandwidth_update(struct amdgpu_device *adev)
-{
- return;
-}
-
-static int dce_virtual_crtc_gamma_set(struct drm_crtc *crtc, u16 *red,
- u16 *green, u16 *blue, uint32_t size,
- struct drm_modeset_acquire_ctx *ctx)
-{
- return 0;
-}
-
-static void dce_virtual_crtc_destroy(struct drm_crtc *crtc)
-{
- struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
-
- drm_crtc_cleanup(crtc);
- kfree(amdgpu_crtc);
-}
-
-static const struct drm_crtc_funcs dce_virtual_crtc_funcs = {
- .cursor_set2 = NULL,
- .cursor_move = NULL,
- .gamma_set = dce_virtual_crtc_gamma_set,
- .set_config = amdgpu_display_crtc_set_config,
- .destroy = dce_virtual_crtc_destroy,
- .page_flip_target = amdgpu_display_crtc_page_flip_target,
- .get_vblank_counter = amdgpu_get_vblank_counter_kms,
- .enable_vblank = amdgpu_enable_vblank_kms,
- .disable_vblank = amdgpu_disable_vblank_kms,
- .get_vblank_timestamp = drm_crtc_vblank_helper_get_vblank_timestamp,
-};
-
-static void dce_virtual_crtc_dpms(struct drm_crtc *crtc, int mode)
-{
- struct drm_device *dev = crtc->dev;
- struct amdgpu_device *adev = drm_to_adev(dev);
- struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(crtc);
- unsigned type;
-
- switch (mode) {
- case DRM_MODE_DPMS_ON:
- amdgpu_crtc->enabled = true;
- /* Make sure VBLANK interrupts are still enabled */
- type = amdgpu_display_crtc_idx_to_irq_type(adev,
- amdgpu_crtc->crtc_id);
- amdgpu_irq_update(adev, &adev->crtc_irq, type);
- drm_crtc_vblank_on(crtc);
- break;
- case DRM_MODE_DPMS_STANDBY:
- case DRM_MODE_DPMS_SUSPEND:
- case DRM_MODE_DPMS_OFF:
- drm_crtc_vblank_off(crtc);
- amdgpu_crtc->enabled = false;
- break;
- }
-}
-
-
-static void dce_virtual_crtc_prepare(struct drm_crtc *crtc)
-{
- dce_virtual_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
-}
-
-static void dce_virtual_crtc_commit(struct drm_crtc *crtc)
-{
- dce_virtual_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
-}
-
-static void dce_virtual_crtc_disable(struct drm_crtc *crtc)
-{
[PATCH 3/3] drm/amdgpu: replace dce_virtual with amdgpu_vkms
Move dce_virtual into amdgpu_vkms and update all references to
dce_virtual with amdgpu_vkms.
Signed-off-by: Ryan Taylor
---
drivers/gpu/drm/amd/amdgpu/Makefile | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 195
drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.h | 3 -
drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 223 ---
drivers/gpu/drm/amd/amdgpu/dce_virtual.h | 30 ---
drivers/gpu/drm/amd/amdgpu/nv.c | 20 +-
drivers/gpu/drm/amd/amdgpu/soc15.c | 10 +-
drivers/gpu/drm/amd/amdgpu/vi.c | 14 +-
8 files changed, 218 insertions(+), 280 deletions(-)
delete mode 100644 drivers/gpu/drm/amd/amdgpu/dce_virtual.c
delete mode 100644 drivers/gpu/drm/amd/amdgpu/dce_virtual.h
diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
b/drivers/gpu/drm/amd/amdgpu/Makefile
index dfcf3b39a2f6..fd9c06c5d263 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -119,8 +119,7 @@ amdgpu-y += \
amdgpu-y += \
dce_v10_0.o \
dce_v11_0.o \
- amdgpu_vkms.o \
- dce_virtual.o
+ amdgpu_vkms.o
# add GFX block
amdgpu-y += \
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
index 58bd0d7b4602..1301df309aa4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c
@@ -5,6 +5,15 @@
#include
#include "amdgpu.h"
+#ifdef CONFIG_DRM_AMDGPU_SI
+#include "dce_v6_0.h"
+#endif
+#ifdef CONFIG_DRM_AMDGPU_CIK
+#include "dce_v8_0.h"
+#endif
+#include "dce_v10_0.h"
+#include "dce_v11_0.h"
+#include "ivsrcid/ivsrcid_vislands30.h"
#include "amdgpu_vkms.h"
#include "amdgpu_display.h"
@@ -408,3 +417,189 @@ int amdgpu_vkms_output_init(struct drm_device *dev,
return ret;
}
+
+const struct drm_mode_config_funcs amdgpu_vkms_mode_funcs = {
+ .fb_create = amdgpu_display_user_framebuffer_create,
+ .atomic_check = drm_atomic_helper_check,
+ .atomic_commit = drm_atomic_helper_commit,
+};
+
+static int amdgpu_vkms_sw_init(void *handle)
+{
+ int r, i;
+ struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+
+ adev_to_drm(adev)->max_vblank_count = 0;
+
+ adev_to_drm(adev)->mode_config.funcs = &amdgpu_vkms_mode_funcs;
+
+ adev_to_drm(adev)->mode_config.max_width = XRES_MAX;
+ adev_to_drm(adev)->mode_config.max_height = YRES_MAX;
+
+ adev_to_drm(adev)->mode_config.preferred_depth = 24;
+ adev_to_drm(adev)->mode_config.prefer_shadow = 1;
+
+ adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
+
+ r = amdgpu_display_modeset_create_props(adev);
+ if (r)
+ return r;
+
+ adev->amdgpu_vkms_output = kzalloc(sizeof(struct amdgpu_vkms_output) *
adev->mode_info.num_crtc, GFP_KERNEL);
+
+ /* allocate crtcs, encoders, connectors */
+ for (i = 0; i < adev->mode_info.num_crtc; i++) {
+ r = amdgpu_vkms_output_init(adev_to_drm(adev),
&adev->amdgpu_vkms_output[i], i);
+ if (r)
+ return r;
+ }
+
+ drm_kms_helper_poll_init(adev_to_drm(adev));
+
+ adev->mode_info.mode_config_initialized = true;
+ return 0;
+}
+
+static int amdgpu_vkms_sw_fini(void *handle)
+{
+ struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+ int i = 0;
+
+ for (i = 0; i < adev->mode_info.num_crtc; i++)
+ if (adev->mode_info.crtcs[i])
+ hrtimer_cancel(&adev->mode_info.crtcs[i]->vblank_timer);
+
+ kfree(adev->mode_info.bios_hardcoded_edid);
+ kfree(adev->amdgpu_vkms_output);
+
+ drm_kms_helper_poll_fini(adev_to_drm(adev));
+
+ adev->mode_info.mode_config_initialized = false;
+ return 0;
+}
+
+static int amdgpu_vkms_hw_init(void *handle)
+{
+ struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+
+ switch (adev->asic_type) {
+#ifdef CONFIG_DRM_AMDGPU_SI
+ case CHIP_TAHITI:
+ case CHIP_PITCAIRN:
+ case CHIP_VERDE:
+ case CHIP_OLAND:
+ dce_v6_0_disable_dce(adev);
+ break;
+#endif
+#ifdef CONFIG_DRM_AMDGPU_CIK
+ case CHIP_BONAIRE:
+ case CHIP_HAWAII:
+ case CHIP_KAVERI:
+ case CHIP_KABINI:
+ case CHIP_MULLINS:
+ dce_v8_0_disable_dce(adev);
+ break;
+#endif
+ case CHIP_FIJI:
+ case CHIP_TONGA:
+ dce_v10_0_disable_dce(adev);
+ break;
+ case CHIP_CARRIZO:
+ case CHIP_STONEY:
+ case CHIP_POLARIS10:
+ case CHIP_POLARIS11:
+ case CHIP_VEGAM:
+ dce_v11_0_disable_dce(adev);
+ break;
+ case CHIP_TOPAZ:
+#ifdef CONFIG_DRM_AMDGPU_SI
+ case CHIP_HAINAN:
+#endif
+ /* no DCE */
+ break;
+ default:
+ break;
+ }
+ return 0;
+}
+
+static int amdgpu_vkms_hw_fini(void *handle)
+{
+ return 0
Re: [PATCH 1/1] drm: bridge: Mark deprecated operations in drm_bridge_funcs
Hi Laurent,
On Sat, Jul 10, 2021 at 11:46:24PM +0300, Laurent Pinchart wrote:
> Hi Sam,
>
> Thank you for the patch.
>
> On Sat, Jul 10, 2021 at 10:42:40AM +0200, Sam Ravnborg wrote:
> > drm_bridge_funcs includes several duplicated operations as atomic
> > variants has been added over time.
>
> s/has/have/
>
> > New bridge drivers shall use the atomic variants - mark the deprecated
> > operations to try to avoid usage in new bridge drivers.
> >
> > Signed-off-by: Sam Ravnborg
> > Cc: Laurent Pinchart
> > Cc: Andrzej Hajda
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Thomas Zimmermann
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > ---
> > include/drm/drm_bridge.h | 28 ++--
> > 1 file changed, 26 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> > index 2195daa289d2..6805898d70f5 100644
> > --- a/include/drm/drm_bridge.h
> > +++ b/include/drm/drm_bridge.h
> > @@ -171,6 +171,11 @@ struct drm_bridge_funcs {
> > * signals) feeding it is still running when this callback is called.
> > *
> > * The @disable callback is optional.
> > +*
> > +* NOTE:
> > +*
> > +* This is deprecated, do not use!
> > +* New drivers shall use &drm_bridge_funcs.atomic_disable.
> > */
> > void (*disable)(struct drm_bridge *bridge);
> >
> > @@ -190,6 +195,11 @@ struct drm_bridge_funcs {
> > * called.
> > *
> > * The @post_disable callback is optional.
> > +*
> > +* NOTE:
> > +*
> > +* This is deprecated, do not use!
> > +* New drivers shall use &drm_bridge_funcs.atomic_post_disable.
> > */
> > void (*post_disable)(struct drm_bridge *bridge);
> >
> > @@ -213,11 +223,15 @@ struct drm_bridge_funcs {
> > * For atomic drivers the adjusted_mode is the mode stored in
> > * &drm_crtc_state.adjusted_mode.
> > *
> > -* NOTE:
> > -*
> > * If a need arises to store and access modes adjusted for other
> > * locations than the connection between the CRTC and the first bridge,
> > * the DRM framework will have to be extended with DRM bridge states.
>
> The DRM framework *has* been extended with DRM bridge states :-) Should
> this be dropped ?
I dropped this while applying.
>
> Reviewed-by: Laurent Pinchart
Tnanks!
Sam
Re: [PATCH 31/47] drm/i915/guc: Reset implementation for new GuC interface
On 6/24/2021 00:05, Matthew Brost wrote:
Reset implementation for new GuC interface. This is the legacy reset
implementation which is called when the i915 owns the engine hang check.
Future patches will offload the engine hang check to GuC but we will
continue to maintain this legacy path as a fallback and this code path
is also required if the GuC dies.
With the new GuC interface it is not possible to reset individual
engines - it is only possible to reset the GPU entirely. This patch
forces an entire chip reset if any engine hangs.
There seems to be quite a lot more code being changed in the patch than
is described above. Sure, it's all in order to support resets but there
is a lot happening to request/context management, support for GuC
submission enable/disable, etc. It feels like this patch really should
be split into a couple of prep patches followed by the actual reset
support. Plus see couple of minor comments below.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 3 +
drivers/gpu/drm/i915/gt/intel_context_types.h | 7 +
drivers/gpu/drm/i915/gt/intel_engine_types.h | 6 +
.../drm/i915/gt/intel_execlists_submission.c | 40 ++
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 6 +-
drivers/gpu/drm/i915/gt/intel_reset.c | 18 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 22 +
drivers/gpu/drm/i915/gt/mock_engine.c | 31 +
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 13 -
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 8 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 581 ++
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 39 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.h | 3 +
drivers/gpu/drm/i915/i915_request.c | 41 +-
drivers/gpu/drm/i915/i915_request.h | 2 +
15 files changed, 649 insertions(+), 171 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index b24a1b7a3f88..2f01437056a8 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -392,6 +392,9 @@ intel_context_init(struct intel_context *ce, struct
intel_engine_cs *engine)
spin_lock_init(&ce->guc_state.lock);
INIT_LIST_HEAD(&ce->guc_state.fences);
+ spin_lock_init(&ce->guc_active.lock);
+ INIT_LIST_HEAD(&ce->guc_active.requests);
+
ce->guc_id = GUC_INVALID_LRC_ID;
INIT_LIST_HEAD(&ce->guc_id_link);
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 6945963a31ba..b63c8cf7823b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -165,6 +165,13 @@ struct intel_context {
struct list_head fences;
} guc_state;
+ struct {
+ /** lock: protects everything in guc_active */
+ spinlock_t lock;
+ /** requests: active requests on this context */
+ struct list_head requests;
+ } guc_active;
+
/* GuC scheduling state that does not require a lock. */
atomic_t guc_sched_state_no_lock;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index e7cb6a06db9d..f9d264c008e8 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -426,6 +426,12 @@ struct intel_engine_cs {
void (*release)(struct intel_engine_cs *engine);
+ /*
+* Add / remove request from engine active tracking
+*/
+ void(*add_active_request)(struct i915_request *rq);
+ void(*remove_active_request)(struct i915_request *rq);
+
struct intel_engine_execlists execlists;
/*
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index c10ea6080752..c301a2d088b1 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -3118,6 +3118,42 @@ static void execlists_park(struct intel_engine_cs
*engine)
cancel_timer(&engine->execlists.preempt);
}
+static void add_to_engine(struct i915_request *rq)
+{
+ lockdep_assert_held(&rq->engine->sched_engine->lock);
+ list_move_tail(&rq->sched.link, &rq->engine->sched_engine->requests);
+}
+
+static void remove_from_engine(struct i915_request *rq)
+{
+ struct intel_engine_cs *engine, *locked;
+
+ /*
+* Virtual engines complicate acquiring the engine timeline lock,
+* as their rq->engine pointer is not stable until under that
+* engine lock. The simple ploy we use is to take the lock then
+* check that the rq still belongs to the newly locked engine.
+*/
+ locked = READ_ONCE(rq->engine);
+ spin_lock_irq(&locked->sched_engine-
