RE: [PATCH] drm/bridge: Add 200ms delay to wait FW HPD status stable
Hi Jani Nikula, thanks for reviewing, I'll use msleep instead, thanks! Xin > -Original Message- > From: Jani Nikula > Sent: Thursday, September 21, 2023 8:09 PM > To: Xin Ji ; Andrzej Hajda ; > Neil Armstrong ; Robert Foss ; > Laurent Pinchart ; Jonas Karlman > ; Jernej Skrabec ; David Airlie > ; Daniel Vetter > Cc: Qilin Wen ; linux-ker...@vger.kernel.org; dri- > de...@lists.freedesktop.org; hsi...@chromium.org; Bernie Liang > ; Xin Ji > Subject: Re: [PATCH] drm/bridge: Add 200ms delay to wait FW HPD status stable > > On Thu, 21 Sep 2023, Xin Ji wrote: > > For the none-interrupt design(sink device is panel, polling HPD status > > when chip power on), anx7625 FW has more than 200ms HPD de-bounce time > > in FW, for the safety to get HPD status, driver better to wait 200ms > > before HPD detection after OS resume back. > > > > Signed-off-by: Xin Ji > > --- > > drivers/gpu/drm/bridge/analogix/anx7625.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c > > b/drivers/gpu/drm/bridge/analogix/anx7625.c > > index 51abe42c639e..833d6d50a03d 100644 > > --- a/drivers/gpu/drm/bridge/analogix/anx7625.c > > +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c > > @@ -1464,6 +1464,9 @@ static int _anx7625_hpd_polling(struct > anx7625_data *ctx, > > if (ctx->pdata.intp_irq) > > return 0; > > > > + /* Delay 200ms for FW HPD de-bounce */ > > + usleep_range(20, 201000); > > If you need to sleep for 200 ms, maybe use msleep instead? OK > > BR, > Jani. > > > + > > ret = readx_poll_timeout(anx7625_read_hpd_status_p0, > > ctx, val, > > ((val & HPD_STATUS) || (val < 0)), > > -- > Jani Nikula, Intel
Re: [PATCH v5 04/11] PM / QoS: Decouple request alloc from dev_pm_qos_mtx
c/consumer/drivers/base/power/qos.c:936) The kernel config and materials to reproduce are available at: https://download.01.org/0day-ci/archive/20230922/202309221426.fb0fe750-oliver.s...@intel.com -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
Re: [PATCH] fbdev: sh7760fb: require FB=y to build cleanly
Hi Randy,
On Thu, Sep 21, 2023 at 10:43 PM Randy Dunlap wrote:
> Fix build errors when CONFIG_FB=m and CONFIG_FB_SH7760=y:
>
> sh2-linux-ld: drivers/video/fbdev/sh7760fb.o: in function `sh7760fb_probe':
> sh7760fb.c:(.text+0x374): undefined reference to `framebuffer_alloc'
> sh2-linux-ld: sh7760fb.c:(.text+0x394): undefined reference to
> `fb_videomode_to_var'
> sh2-linux-ld: sh7760fb.c:(.text+0x3a0): undefined reference to `fb_alloc_cmap'
> sh2-linux-ld: sh7760fb.c:(.text+0x3a4): undefined reference to
> `register_framebuffer'
> sh2-linux-ld: sh7760fb.c:(.text+0x3ac): undefined reference to
> `fb_dealloc_cmap'
> sh2-linux-ld: sh7760fb.c:(.text+0x434): undefined reference to
> `framebuffer_release'
> sh2-linux-ld: drivers/video/fbdev/sh7760fb.o: in function `sh7760fb_remove':
> sh7760fb.c:(.text+0x800): undefined reference to `unregister_framebuffer'
> sh2-linux-ld: sh7760fb.c:(.text+0x804): undefined reference to
> `fb_dealloc_cmap'
> sh2-linux-ld: sh7760fb.c:(.text+0x814): undefined reference to
> `framebuffer_release'
> sh2-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0xc): undefined
> reference to `fb_io_read'
> sh2-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x10): undefined
> reference to `fb_io_write'
> sh2-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x2c): undefined
> reference to `cfb_fillrect'
> sh2-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x30): undefined
> reference to `cfb_copyarea'
> sh2-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x34): undefined
> reference to `cfb_imageblit'
>
> Fixes: 4a25e41831ee ("video: sh7760fb: SH7760/SH7763 LCDC framebuffer driver")
> Signed-off-by: Randy Dunlap
Thanks for your patch!
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -1762,7 +1762,7 @@ config FB_COBALT
>
> config FB_SH7760
> bool "SH7760/SH7763/SH7720/SH7721 LCDC support"
> - depends on FB && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
> + depends on FB=y && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
> || CPU_SUBTYPE_SH7720 || CPU_SUBTYPE_SH7721)
> select FB_IOMEM_HELPERS
> help
Any reason this can't become tristate instead?
drivers/video/fbdev/sh7760fb.c uses module_platform_driver(), and
already has all needed MODULE_*().
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 v2] drm: renesas: rcar-du: use proper naming for R-Car
On Fri, Sep 22, 2023 at 2:58 AM Wolfram Sang
wrote:
> Not RCAR, but R-Car.
>
> Signed-off-by: Wolfram Sang
> Reviewed-by: Kieran Bingham
> ---
>
> Changes since v1:
> * rebased to 6.6-rc2
> * added tag from Kieran (Thanks!)
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH] drm: tilcdc: don't use devm_pinctrl_get_select_default() in probe
Since commit ab78029ecc34 ("drivers/pinctrl: grab default handles from
device core"), we can rely on device core for setting the default pins.
Signed-off-by: Wolfram Sang
---
drivers/gpu/drm/tilcdc/tilcdc_panel.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
index 9aefd010acde..68093d6b6b16 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_panel.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_panel.c
@@ -6,7 +6,6 @@
#include
#include
-#include
#include
#include
@@ -308,7 +307,6 @@ static int panel_probe(struct platform_device *pdev)
struct backlight_device *backlight;
struct panel_module *panel_mod;
struct tilcdc_module *mod;
- struct pinctrl *pinctrl;
int ret;
/* bail out early if no DT data: */
@@ -342,10 +340,6 @@ static int panel_probe(struct platform_device *pdev)
tilcdc_module_init(mod, "panel", &panel_module_ops);
- pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
- if (IS_ERR(pinctrl))
- dev_warn(&pdev->dev, "pins are not configured\n");
-
panel_mod->timings = of_get_display_timings(node);
if (!panel_mod->timings) {
dev_err(&pdev->dev, "could not get panel timings\n");
--
2.30.2
Re: [PATCH v4 1/5] fbdev: Avoid file argument in fb_pgprotect()
Hi Javier
Am 20.09.23 um 10:01 schrieb Javier Martinez Canillas:
Thomas Zimmermann writes:
Hello Thomas,
Only PowerPC's fb_pgprotect() needs the file argument, although
the implementation does not use it. Pass NULL to the internal
Can you please mention the function that's the implementation for
Sure
PowerPC ? If I'm looking at the code correctly, that function is
phys_mem_access_prot() defined in the arch/powerpc/mm/mem.c file:
pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
unsigned long size, pgprot_t vma_prot)
{
if (ppc_md.phys_mem_access_prot)
return ppc_md.phys_mem_access_prot(file, pfn, size, vma_prot);
if (!page_is_ram(pfn))
vma_prot = pgprot_noncached(vma_prot);
return vma_prot;
}
and if set, ppc_md.phys_mem_access_prot is pci_phys_mem_access_prot()
that is defined in the arch/powerpc/kernel/pci-common.c source file:
https://elixir.bootlin.com/linux/v6.6-rc2/source/arch/powerpc/kernel/pci-common.c#L524
Yes, that's correct. The only value for that function pointer appears to
be pci_phys_mem_access_prot()
That function indeed doesn't use the file argument. So your patch looks
correct to me.
Reviewed-by: Javier Martinez Canillas
Thanks
Best regards
Thomas
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [RFT PATCH v2 01/12] drm/imx/dcss: Call drm_atomic_helper_shutdown() at shutdown time
Hi,
On Thu, Sep 21, 2023 at 12:26:44PM -0700, Douglas Anderson wrote:
> Based on grepping through the source code this driver appears to be
> missing a call to drm_atomic_helper_shutdown() at system shutdown
> time. Among other things, this means that if a panel is in use that it
> won't be cleanly powered off at system shutdown time.
>
> The fact that we should call drm_atomic_helper_shutdown() in the case
> of OS shutdown/restart comes straight out of the kernel doc "driver
> instance overview" in drm_drv.c.
>
> Suggested-by: Maxime Ripard
> Reviewed-by: Maxime Ripard
> Signed-off-by: Douglas Anderson
No issues found on i.MX8MQ.
Tested-by: Laurentiu Palcu
Reviewed-by: Laurentiu Palcu
Thanks,
Laurentiu
> ---
> This commit is only compile-time tested.
>
> (no changes since v1)
>
> drivers/gpu/drm/imx/dcss/dcss-drv.c | 8
> drivers/gpu/drm/imx/dcss/dcss-kms.c | 7 +++
> drivers/gpu/drm/imx/dcss/dcss-kms.h | 1 +
> 3 files changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/imx/dcss/dcss-drv.c
> b/drivers/gpu/drm/imx/dcss/dcss-drv.c
> index c68b0d93ae9e..b61cec0cc79d 100644
> --- a/drivers/gpu/drm/imx/dcss/dcss-drv.c
> +++ b/drivers/gpu/drm/imx/dcss/dcss-drv.c
> @@ -92,6 +92,13 @@ static int dcss_drv_platform_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +static void dcss_drv_platform_shutdown(struct platform_device *pdev)
> +{
> + struct dcss_drv *mdrv = dev_get_drvdata(&pdev->dev);
> +
> + dcss_kms_shutdown(mdrv->kms);
> +}
> +
> static struct dcss_type_data dcss_types[] = {
> [DCSS_IMX8MQ] = {
> .name = "DCSS_IMX8MQ",
> @@ -114,6 +121,7 @@ MODULE_DEVICE_TABLE(of, dcss_of_match);
> static struct platform_driver dcss_platform_driver = {
> .probe = dcss_drv_platform_probe,
> .remove = dcss_drv_platform_remove,
> + .shutdown = dcss_drv_platform_shutdown,
> .driver = {
> .name = "imx-dcss",
> .of_match_table = dcss_of_match,
> diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c
> b/drivers/gpu/drm/imx/dcss/dcss-kms.c
> index 896de946f8df..d0ea4e97cded 100644
> --- a/drivers/gpu/drm/imx/dcss/dcss-kms.c
> +++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c
> @@ -172,3 +172,10 @@ void dcss_kms_detach(struct dcss_kms_dev *kms)
> dcss_crtc_deinit(&kms->crtc, drm);
> drm->dev_private = NULL;
> }
> +
> +void dcss_kms_shutdown(struct dcss_kms_dev *kms)
> +{
> + struct drm_device *drm = &kms->base;
> +
> + drm_atomic_helper_shutdown(drm);
> +}
> diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.h
> b/drivers/gpu/drm/imx/dcss/dcss-kms.h
> index dfe5dd99eea3..62521c1fd6d2 100644
> --- a/drivers/gpu/drm/imx/dcss/dcss-kms.h
> +++ b/drivers/gpu/drm/imx/dcss/dcss-kms.h
> @@ -34,6 +34,7 @@ struct dcss_kms_dev {
>
> struct dcss_kms_dev *dcss_kms_attach(struct dcss_dev *dcss);
> void dcss_kms_detach(struct dcss_kms_dev *kms);
> +void dcss_kms_shutdown(struct dcss_kms_dev *kms);
> int dcss_crtc_init(struct dcss_crtc *crtc, struct drm_device *drm);
> void dcss_crtc_deinit(struct dcss_crtc *crtc, struct drm_device *drm);
> struct dcss_plane *dcss_plane_init(struct drm_device *drm,
> --
> 2.42.0.515.g380fc7ccd1-goog
>
Re: [PATCH 2/3] kunit: Add kunit_move_action_to_top_or_reset() to reorder actions
On Wed, 20 Sept 2023 at 14:12, Arthur Grillo wrote:
>
> On Kunit, if we allocate a resource A and B on this order, with its
> deferred actions to free them. The resource stack would be something
> like this:
>
> +-+
> | free(B) |
> +-+
> | ... |
> +-+
> | free(A) |
> +-+
>
> If the deferred action of A accesses B, this would cause a
> use-after-free bug. To solve that, we need a way to change the order
> of actions.
>
> Create a function to move an action to the top of the resource stack,
> as shown in the diagram below.
>
> +-++-+
> | free(B) || free(A) |
> +-++-+
> | ... | -> | free(B) |
> +-++-+
> | free(A) || ... |
> +-++-+
>
> Signed-off-by: Arthur Grillo
> ---
Thanks. This is a really interesting patch: my hope was that something
like this wouldn't be necessary, as in most cases freeing things in
the reverse order to which they were created is the right thing to do.
It looks like, from the comments on patch 3, this may no longer be
necessary? Is that so?
Otherwise, if you have a real use case for it, I've no objection to
KUnit adding this as a feature (though I'd probably add some
documentation suggesting that it's best avoided if you can order your
allocations / calls better).
Cheers,
-- David
> include/kunit/resource.h | 17 +
> lib/kunit/resource.c | 19 +++
> 2 files changed, 36 insertions(+)
>
> diff --git a/include/kunit/resource.h b/include/kunit/resource.h
> index c7383e90f5c9..c598b23680e3 100644
> --- a/include/kunit/resource.h
> +++ b/include/kunit/resource.h
> @@ -479,4 +479,21 @@ void kunit_remove_action(struct kunit *test,
> void kunit_release_action(struct kunit *test,
> kunit_action_t *action,
> void *ctx);
> +
> +/**
> + * kunit_move_action_to_top_or_reset - Move a previously added action to the
> top
> + *of the order of actions calls.
> + * @test: Test case to associate the action with.
> + * @action: The function to run on test exit
> + * @ctx: Data passed into @func
> + *
> + * Reorder the action stack, by moving the desired action to the top.
> + *
> + * Returns:
> + * 0 on success, an error if the action could not be inserted on the top.
> + */
> +int kunit_move_action_to_top_or_reset(struct kunit *test,
> + kunit_action_t *action,
> + void *ctx);
> +
> #endif /* _KUNIT_RESOURCE_H */
> diff --git a/lib/kunit/resource.c b/lib/kunit/resource.c
> index f0209252b179..fe40a34b62a6 100644
> --- a/lib/kunit/resource.c
> +++ b/lib/kunit/resource.c
> @@ -176,3 +176,22 @@ void kunit_release_action(struct kunit *test,
> }
> }
> EXPORT_SYMBOL_GPL(kunit_release_action);
> +
> +int kunit_move_action_to_top_or_reset(struct kunit *test,
> + kunit_action_t *action,
> + void *ctx)
> +{
> + struct kunit_action_ctx match_ctx;
> + struct kunit_resource *res;
> +
> + match_ctx.func = action;
> + match_ctx.ctx = ctx;
> + res = kunit_find_resource(test, __kunit_action_match, &match_ctx);
> + if (res) {
> + kunit_remove_action(test, action, ctx);
> + return kunit_add_action_or_reset(test, action, ctx);
> + }
> +
if (!res), this doesn't call the action, so the _or_reset() part of
this doesn't quite make sense.
As I understand it, there are three cases handled here:
1. The action already existed, and we were able to recreate it at the top.
2. The action already existed, but we were unable to recreate it.
3. The action did not previously exist.
In this case, for (1), the action is successfully moved to the top.
This is the "good case".
For (2), we run the action immediately (the idea being that it's
better to not leak memory).
For (3), we do nothing, the action is never run.
My guess, from the name ending in _or_reset, (3) should:
- Try to defer the action. If deferring it fails, run the action immediately.
Or possibly, always run the action immediately in case (3).
Whatever we want, we need to decide on what happens here and document them.
And of course, we can get some of those behaviours without needing to
call kunit_find_resource() at all, just by calling
kunit_remove_action(...)
kunit_add_action_or_reset()
unconditionally.
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(kunit_move_action_to_top_or_reset);
>
> --
> 2.41.0
>
smime.p7s
Description: S/MIME Cryptographic Signature
[PATCH v5 1/5] fbdev: Avoid file argument in fb_pgprotect()
Only PowerPC's fb_pgprotect() needs the file argument, although
the implementation in either phys_mem_access_prot() or
pci_phys_mem_access_prot() does not use it. Pass NULL to the internal
helper in preparation of further updates. A later patch will remove
the file parameter from fb_pgprotect().
While at it, replace the shift operation with PHYS_PFN().
v5:
* state function names in commit description (Javier)
Suggested-by: Christophe Leroy
Signed-off-by: Thomas Zimmermann
Reviewed-by: Arnd Bergmann
Reviewed-by: Javier Martinez Canillas
---
arch/powerpc/include/asm/fb.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/fb.h b/arch/powerpc/include/asm/fb.h
index 5f1a2e5f76548..61e3b8806db69 100644
--- a/arch/powerpc/include/asm/fb.h
+++ b/arch/powerpc/include/asm/fb.h
@@ -9,7 +9,12 @@
static inline void fb_pgprotect(struct file *file, struct vm_area_struct *vma,
unsigned long off)
{
- vma->vm_page_prot = phys_mem_access_prot(file, off >> PAGE_SHIFT,
+ /*
+* PowerPC's implementation of phys_mem_access_prot() does
+* not use the file argument. Set it to NULL in preparation
+* of later updates to the interface.
+*/
+ vma->vm_page_prot = phys_mem_access_prot(NULL, PHYS_PFN(off),
vma->vm_end - vma->vm_start,
vma->vm_page_prot);
}
--
2.42.0
[PATCH v5 0/5] ppc, fbdev: Clean up fbdev mmap helper
Clean up and rename fb_pgprotect() to work without struct file. Then refactor the implementation for PowerPC. This change has been discussed at [1] in the context of refactoring fbdev's mmap code. The first two patches update fbdev and replace fbdev's fb_pgprotect() with pgprot_framebuffer() on all architectures. The new helper's stream- lined interface enables more refactoring within fbdev's mmap implementation. Patches 3 to 5 adapt PowerPC's internal interfaces to provide phys_mem_access_prot() that works without struct file. Neither the architecture code or fbdev helpers need the parameter. v5: * improve commit descriptions (Javier) * add missing tags (Geert) v4: * fix commit message (Christophe) v3: * rename fb_pgrotect() to pgprot_framebuffer() (Arnd) v2: * reorder patches to simplify merging (Michael) [1] https://lore.kernel.org/linuxppc-dev/5501ba80-bdb0-6344-16b0-0466a950f...@suse.com/ Thomas Zimmermann (5): fbdev: Avoid file argument in fb_pgprotect() fbdev: Replace fb_pgprotect() with pgprot_framebuffer() arch/powerpc: Remove trailing whitespaces arch/powerpc: Remove file parameter from phys_mem_access_prot code arch/powerpc: Call internal __phys_mem_access_prot() in fbdev code arch/ia64/include/asm/fb.h| 15 +++ arch/m68k/include/asm/fb.h| 19 ++- arch/mips/include/asm/fb.h| 11 +-- arch/powerpc/include/asm/book3s/pgtable.h | 10 -- arch/powerpc/include/asm/fb.h | 13 + arch/powerpc/include/asm/machdep.h| 13 ++--- arch/powerpc/include/asm/nohash/pgtable.h | 10 -- arch/powerpc/include/asm/pci.h| 4 +--- arch/powerpc/kernel/pci-common.c | 3 +-- arch/powerpc/mm/mem.c | 8 arch/sparc/include/asm/fb.h | 15 +-- arch/x86/include/asm/fb.h | 10 ++ arch/x86/video/fbdev.c| 15 --- drivers/video/fbdev/core/fb_chrdev.c | 3 ++- include/asm-generic/fb.h | 12 ++-- 15 files changed, 86 insertions(+), 75 deletions(-) base-commit: f8d21cb17a99b75862196036bb4bb93ee9637b74 -- 2.42.0
[PATCH v5 2/5] fbdev: Replace fb_pgprotect() with pgprot_framebuffer()
Rename the fbdev mmap helper fb_pgprotect() to pgprot_framebuffer().
The helper sets VMA page-access flags for framebuffers in device I/O
memory.
Also clean up the helper's parameters and return value. Instead of
the VMA instance, pass the individial parameters separately: existing
page-access flags, the VMAs start and end addresses and the offset
in the underlying device memory rsp file. Return the new page-access
flags. These changes align pgprot_framebuffer() with other pgprot_()
functions.
v4:
* fix commit message (Christophe)
v3:
* rename fb_pgprotect() to pgprot_framebuffer() (Arnd)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Arnd Bergmann
Acked-by: Geert Uytterhoeven # m68k
---
arch/ia64/include/asm/fb.h | 15 +++
arch/m68k/include/asm/fb.h | 19 ++-
arch/mips/include/asm/fb.h | 11 +--
arch/powerpc/include/asm/fb.h| 13 +
arch/sparc/include/asm/fb.h | 15 +--
arch/x86/include/asm/fb.h| 10 ++
arch/x86/video/fbdev.c | 15 ---
drivers/video/fbdev/core/fb_chrdev.c | 3 ++-
include/asm-generic/fb.h | 12 ++--
9 files changed, 58 insertions(+), 55 deletions(-)
diff --git a/arch/ia64/include/asm/fb.h b/arch/ia64/include/asm/fb.h
index 1717b26fd423f..7fce0d5423590 100644
--- a/arch/ia64/include/asm/fb.h
+++ b/arch/ia64/include/asm/fb.h
@@ -8,17 +8,16 @@
#include
-struct file;
-
-static inline void fb_pgprotect(struct file *file, struct vm_area_struct *vma,
- unsigned long off)
+static inline pgprot_t pgprot_framebuffer(pgprot_t prot,
+ unsigned long vm_start, unsigned long
vm_end,
+ unsigned long offset)
{
- if (efi_range_is_wc(vma->vm_start, vma->vm_end - vma->vm_start))
- vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
+ if (efi_range_is_wc(vm_start, vm_end - vm_start))
+ return pgprot_writecombine(prot);
else
- vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+ return pgprot_noncached(prot);
}
-#define fb_pgprotect fb_pgprotect
+#define pgprot_framebuffer pgprot_framebuffer
static inline void fb_memcpy_fromio(void *to, const volatile void __iomem
*from, size_t n)
{
diff --git a/arch/m68k/include/asm/fb.h b/arch/m68k/include/asm/fb.h
index 24273fc7ad917..9941b7434b696 100644
--- a/arch/m68k/include/asm/fb.h
+++ b/arch/m68k/include/asm/fb.h
@@ -5,26 +5,27 @@
#include
#include
-struct file;
-
-static inline void fb_pgprotect(struct file *file, struct vm_area_struct *vma,
- unsigned long off)
+static inline pgprot_t pgprot_framebuffer(pgprot_t prot,
+ unsigned long vm_start, unsigned long
vm_end,
+ unsigned long offset)
{
#ifdef CONFIG_MMU
#ifdef CONFIG_SUN3
- pgprot_val(vma->vm_page_prot) |= SUN3_PAGE_NOCACHE;
+ pgprot_val(prot) |= SUN3_PAGE_NOCACHE;
#else
if (CPU_IS_020_OR_030)
- pgprot_val(vma->vm_page_prot) |= _PAGE_NOCACHE030;
+ pgprot_val(prot) |= _PAGE_NOCACHE030;
if (CPU_IS_040_OR_060) {
- pgprot_val(vma->vm_page_prot) &= _CACHEMASK040;
+ pgprot_val(prot) &= _CACHEMASK040;
/* Use no-cache mode, serialized */
- pgprot_val(vma->vm_page_prot) |= _PAGE_NOCACHE_S;
+ pgprot_val(prot) |= _PAGE_NOCACHE_S;
}
#endif /* CONFIG_SUN3 */
#endif /* CONFIG_MMU */
+
+ return prot;
}
-#define fb_pgprotect fb_pgprotect
+#define pgprot_framebuffer pgprot_framebuffer
#include
diff --git a/arch/mips/include/asm/fb.h b/arch/mips/include/asm/fb.h
index 18b7226403bad..d98d6681d64ec 100644
--- a/arch/mips/include/asm/fb.h
+++ b/arch/mips/include/asm/fb.h
@@ -3,14 +3,13 @@
#include
-struct file;
-
-static inline void fb_pgprotect(struct file *file, struct vm_area_struct *vma,
- unsigned long off)
+static inline pgprot_t pgprot_framebuffer(pgprot_t prot,
+ unsigned long vm_start, unsigned long
vm_end,
+ unsigned long offset)
{
- vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+ return pgprot_noncached(prot);
}
-#define fb_pgprotect fb_pgprotect
+#define pgprot_framebuffer pgprot_framebuffer
/*
* MIPS doesn't define __raw_ I/O macros, so the helpers
diff --git a/arch/powerpc/include/asm/fb.h b/arch/powerpc/include/asm/fb.h
index 61e3b8806db69..3cecf14d51de8 100644
--- a/arch/powerpc/include/asm/fb.h
+++ b/arch/powerpc/include/asm/fb.h
@@ -2,23 +2,20 @@
#ifndef _ASM_FB_H_
#define _ASM_FB_H_
-#include
-
#include
-static inline void fb_pgprotect(struct file *file, struct vm_area_struct *vma,
-
[PATCH v5 3/5] arch/powerpc: Remove trailing whitespaces
Fix coding style. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Arnd Bergmann
Reviewed-by: Philippe Mathieu-Daudé
---
arch/powerpc/include/asm/machdep.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/machdep.h
b/arch/powerpc/include/asm/machdep.h
index 4f6e7d7ee3883..933465ed4c432 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -10,7 +10,7 @@
#include
struct pt_regs;
-struct pci_bus;
+struct pci_bus;
struct device_node;
struct iommu_table;
struct rtc_time;
@@ -78,8 +78,8 @@ struct machdep_calls {
unsigned char (*nvram_read_val)(int addr);
void(*nvram_write_val)(int addr, unsigned char val);
ssize_t (*nvram_write)(char *buf, size_t count, loff_t *index);
- ssize_t (*nvram_read)(char *buf, size_t count, loff_t *index);
- ssize_t (*nvram_size)(void);
+ ssize_t (*nvram_read)(char *buf, size_t count, loff_t *index);
+ ssize_t (*nvram_size)(void);
void(*nvram_sync)(void);
/* Exception handlers */
@@ -102,9 +102,9 @@ struct machdep_calls {
*/
long(*feature_call)(unsigned int feature, ...);
- /* Get legacy PCI/IDE interrupt mapping */
+ /* Get legacy PCI/IDE interrupt mapping */
int (*pci_get_legacy_ide_irq)(struct pci_dev *dev, int
channel);
-
+
/* Get access protection for /dev/mem */
pgprot_t(*phys_mem_access_prot)(struct file *file,
unsigned long pfn,
--
2.42.0
[PATCH v5 4/5] arch/powerpc: Remove file parameter from phys_mem_access_prot code
Remove 'file' parameter from struct machdep_calls.phys_mem_access_prot
and its implementation in pci_phys_mem_access_prot(). The file is not
used on PowerPC. By removing it, a later patch can simplify fbdev's
mmap code, which uses phys_mem_access_prot() on PowerPC.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Arnd Bergmann
---
arch/powerpc/include/asm/book3s/pgtable.h | 10 --
arch/powerpc/include/asm/machdep.h| 3 +--
arch/powerpc/include/asm/nohash/pgtable.h | 10 --
arch/powerpc/include/asm/pci.h| 4 +---
arch/powerpc/kernel/pci-common.c | 3 +--
arch/powerpc/mm/mem.c | 8
6 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/pgtable.h
b/arch/powerpc/include/asm/book3s/pgtable.h
index d18b748ea3ae0..84e36a5726417 100644
--- a/arch/powerpc/include/asm/book3s/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/pgtable.h
@@ -20,9 +20,15 @@ extern void set_pte_at(struct mm_struct *mm, unsigned long
addr, pte_t *ptep,
extern int ptep_set_access_flags(struct vm_area_struct *vma, unsigned long
address,
pte_t *ptep, pte_t entry, int dirty);
+extern pgprot_t __phys_mem_access_prot(unsigned long pfn, unsigned long size,
+ pgprot_t vma_prot);
+
struct file;
-extern pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
-unsigned long size, pgprot_t vma_prot);
+static inline pgprot_t phys_mem_access_prot(struct file *file, unsigned long
pfn,
+ unsigned long size, pgprot_t
vma_prot)
+{
+ return __phys_mem_access_prot(pfn, size, vma_prot);
+}
#define __HAVE_PHYS_MEM_ACCESS_PROT
void __update_mmu_cache(struct vm_area_struct *vma, unsigned long address,
pte_t *ptep);
diff --git a/arch/powerpc/include/asm/machdep.h
b/arch/powerpc/include/asm/machdep.h
index 933465ed4c432..d31a5ec1550d4 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -106,8 +106,7 @@ struct machdep_calls {
int (*pci_get_legacy_ide_irq)(struct pci_dev *dev, int
channel);
/* Get access protection for /dev/mem */
- pgprot_t(*phys_mem_access_prot)(struct file *file,
- unsigned long pfn,
+ pgprot_t(*phys_mem_access_prot)(unsigned long pfn,
unsigned long size,
pgprot_t vma_prot);
diff --git a/arch/powerpc/include/asm/nohash/pgtable.h
b/arch/powerpc/include/asm/nohash/pgtable.h
index a6cb6f922..90366b0b3ad9a 100644
--- a/arch/powerpc/include/asm/nohash/pgtable.h
+++ b/arch/powerpc/include/asm/nohash/pgtable.h
@@ -246,9 +246,15 @@ extern int ptep_set_access_flags(struct vm_area_struct
*vma, unsigned long addre
#define pgprot_writecombine pgprot_noncached_wc
+extern pgprot_t __phys_mem_access_prot(unsigned long pfn, unsigned long size,
+ pgprot_t vma_prot);
+
struct file;
-extern pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
-unsigned long size, pgprot_t vma_prot);
+static inline pgprot_t phys_mem_access_prot(struct file *file, unsigned long
pfn,
+ unsigned long size, pgprot_t
vma_prot)
+{
+ return __phys_mem_access_prot(pfn, size, vma_prot);
+}
#define __HAVE_PHYS_MEM_ACCESS_PROT
#ifdef CONFIG_HUGETLB_PAGE
diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index 289f1ec85bc54..34ed4d51c546b 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -104,9 +104,7 @@ extern void of_scan_pci_bridge(struct pci_dev *dev);
extern void of_scan_bus(struct device_node *node, struct pci_bus *bus);
extern void of_rescan_bus(struct device_node *node, struct pci_bus *bus);
-struct file;
-extern pgprot_tpci_phys_mem_access_prot(struct file *file,
-unsigned long pfn,
+extern pgprot_tpci_phys_mem_access_prot(unsigned long pfn,
unsigned long size,
pgprot_t prot);
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index e88d7c9feeec3..73f12a17e572e 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -521,8 +521,7 @@ int pci_iobar_pfn(struct pci_dev *pdev, int bar, struct
vm_area_struct *vma)
* PCI device, it tries to find the PCI device first and calls the
* above routine
*/
-pgprot_t pci_phys_mem_access_prot(struct file *file,
- unsigned long pfn,
+pgprot_t pci_phys_mem_access_prot(unsigned long pfn,
unsigned long size,
[PATCH v5 5/5] arch/powerpc: Call internal __phys_mem_access_prot() in fbdev code
Call __phys_mem_access_prot() from the fbdev mmap helper
pgprot_framebuffer(). Allows to avoid the file argument of NULL.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Arnd Bergmann
---
arch/powerpc/include/asm/fb.h | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/fb.h b/arch/powerpc/include/asm/fb.h
index 3cecf14d51de8..c0c5d1df7ad1e 100644
--- a/arch/powerpc/include/asm/fb.h
+++ b/arch/powerpc/include/asm/fb.h
@@ -8,12 +8,7 @@ static inline pgprot_t pgprot_framebuffer(pgprot_t prot,
unsigned long vm_start, unsigned long
vm_end,
unsigned long offset)
{
- /*
-* PowerPC's implementation of phys_mem_access_prot() does
-* not use the file argument. Set it to NULL in preparation
-* of later updates to the interface.
-*/
- return phys_mem_access_prot(NULL, PHYS_PFN(offset), vm_end - vm_start,
prot);
+ return __phys_mem_access_prot(PHYS_PFN(offset), vm_end - vm_start,
prot);
}
#define pgprot_framebuffer pgprot_framebuffer
--
2.42.0
WARNING in amdgpu_sync_keep_later / dma_fence_is_later should be rate limited
Hi,
backporting commit 187916e6ed9d ("drm/amdgpu: install stub fence into
potential unused fence pointers") to stable kernels resulted in lots
of WARNINGs on some devices. In my case I was getting 3 WARNINGs per
second (~150 lines logged every second). Commit ended up being
reverted for stable but it exposed a potential problem. My messages
log size was reaching gigabytes and was running my /tmp/ out of space.
Could someone take a look at amdgpu_sync_keep_later /
dma_fence_is_later and make sure its logging is rate limited to avoid
such situations in the future, please?
Revert in linux-5.15.x:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.15.y&id=fae2d591f3cb31f722c7f065acf586830eab8c2a
openSUSE bug report:
https://bugzilla.opensuse.org/show_bug.cgi?id=1215523
--
Rafał
[PATCH] drm/gem: avoid potential dereference of error pointers
The return value of drm_atomic_get_crtc_state() needs to be checked. To avoid use of error pointer 'crtc_state' in case of the failure. Signed-off-by: Ma Ke --- drivers/gpu/drm/sti/sti_gdp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c index 43c72c2604a0..054ce8455478 100644 --- a/drivers/gpu/drm/sti/sti_gdp.c +++ b/drivers/gpu/drm/sti/sti_gdp.c @@ -638,6 +638,8 @@ static int sti_gdp_atomic_check(struct drm_plane *drm_plane, mixer = to_sti_mixer(crtc); crtc_state = drm_atomic_get_crtc_state(state, crtc); + if (IS_ERR(crtc_state)) + return PTR_ERR(crtc_state); mode = &crtc_state->mode; dst_x = new_plane_state->crtc_x; dst_y = new_plane_state->crtc_y; -- 2.37.2
[PATCH] drm/sti: avoid potential dereference of error pointers
The return value of drm_atomic_get_crtc_state() needs to be checked. To avoid use of error pointer 'crtc_state' in case of the failure. Signed-off-by: Ma Ke --- drivers/gpu/drm/sti/sti_cursor.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/sti/sti_cursor.c b/drivers/gpu/drm/sti/sti_cursor.c index db0a1eb53532..e460f5ba2d87 100644 --- a/drivers/gpu/drm/sti/sti_cursor.c +++ b/drivers/gpu/drm/sti/sti_cursor.c @@ -200,6 +200,8 @@ static int sti_cursor_atomic_check(struct drm_plane *drm_plane, return 0; crtc_state = drm_atomic_get_crtc_state(state, crtc); + if (IS_ERR(crtc_state)) + return PTR_ERR(crtc_state); mode = &crtc_state->mode; dst_x = new_plane_state->crtc_x; dst_y = new_plane_state->crtc_y; -- 2.37.2
Re: WARNING in amdgpu_sync_keep_later / dma_fence_is_later should be rate limited
On 21.09.2023 21:52, Deucher, Alexander wrote:
backporting commit 187916e6ed9d ("drm/amdgpu: install stub fence into
potential unused fence pointers") to stable kernels resulted in lots of
WARNINGs on some devices. In my case I was getting 3 WARNINGs per
second (~150 lines logged every second). Commit ended up being reverted for
stable but it exposed a potential problem. My messages log size was reaching
gigabytes and was running my /tmp/ out of space.
Could someone take a look at amdgpu_sync_keep_later / dma_fence_is_later
and make sure its logging is rate limited to avoid such situations in the
future,
please?
Revert in linux-5.15.x:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=li
nux-5.15.y&id=fae2d591f3cb31f722c7f065acf586830eab8c2a
openSUSE bug report:
https://bugzilla.opensuse.org/show_bug.cgi?id=1215523
These patches were never intended for stable. They were picked up by Sasha's
stable autoselect tools and automatically applied to stable kernels.
Are you saying massive WARNINGs in dma_fence_is_later() can't happen
in any other case? I understand it was an incorrect backport action but
I thought we may learn from it and still add some rate limit.
Re: [PATCH v5 2/5] fbdev: Replace fb_pgprotect() with pgprot_framebuffer()
Thomas Zimmermann writes: > Rename the fbdev mmap helper fb_pgprotect() to pgprot_framebuffer(). > The helper sets VMA page-access flags for framebuffers in device I/O > memory. > > Also clean up the helper's parameters and return value. Instead of > the VMA instance, pass the individial parameters separately: existing > page-access flags, the VMAs start and end addresses and the offset > in the underlying device memory rsp file. Return the new page-access > flags. These changes align pgprot_framebuffer() with other pgprot_() > functions. > > v4: > * fix commit message (Christophe) > v3: > * rename fb_pgprotect() to pgprot_framebuffer() (Arnd) > > Signed-off-by: Thomas Zimmermann > Reviewed-by: Arnd Bergmann > Acked-by: Geert Uytterhoeven # m68k > --- Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
Re: [PATCH 5/5] drm/i915: Implement fdinfo memory stats printing
On 21-09-2023 17:18, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Use the newly added drm_print_memory_stats helper to show memory
> utilisation of our objects in drm/driver specific fdinfo output.
>
> To collect the stats we walk the per memory regions object lists
> and accumulate object size into the respective drm_memory_stats
> categories.
>
> Objects with multiple possible placements are reported in multiple
> regions for total and shared sizes, while other categories are
I guess you forgot to correct this.
> counted only for the currently active region.
>
> v2:
> * Only account against the active region.
> * Use DMA_RESV_USAGE_BOOKKEEP when testing for active. (Tejas)
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Aravind Iddamsetty
> Cc: Rob Clark
> Cc: Andi Shyti
> Cc: Tejas Upadhyay
> Reviewed-by: Andi Shyti # v1
> ---
> drivers/gpu/drm/i915/i915_drm_client.c | 64 ++
> 1 file changed, 64 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
> b/drivers/gpu/drm/i915/i915_drm_client.c
> index a61356012df8..94abc2fb2ea6 100644
> --- a/drivers/gpu/drm/i915/i915_drm_client.c
> +++ b/drivers/gpu/drm/i915/i915_drm_client.c
> @@ -45,6 +45,68 @@ void __i915_drm_client_free(struct kref *kref)
> }
>
> #ifdef CONFIG_PROC_FS
> +static void
> +obj_meminfo(struct drm_i915_gem_object *obj,
> + struct drm_memory_stats stats[INTEL_REGION_UNKNOWN])
> +{
> + const enum intel_region_id id = obj->mm.region ?
> + obj->mm.region->id : INTEL_REGION_SMEM;
> + const u64 sz = obj->base.size;
> +
> + if (obj->base.handle_count > 1)
> + stats[id].shared += sz;
> + else
> + stats[id].private += sz;
> +
> + if (i915_gem_object_has_pages(obj)) {
> + stats[id].resident += sz;
> +
> + if (!dma_resv_test_signaled(obj->base.resv,
> + DMA_RESV_USAGE_BOOKKEEP))
> + stats[id].active += sz;
> + else if (i915_gem_object_is_shrinkable(obj) &&
> + obj->mm.madv == I915_MADV_DONTNEED)
> + stats[id].purgeable += sz;
> + }
> +}
> +
> +static void show_meminfo(struct drm_printer *p, struct drm_file *file)
> +{
> + struct drm_memory_stats stats[INTEL_REGION_UNKNOWN] = {};
> + struct drm_i915_file_private *fpriv = file->driver_priv;
> + struct i915_drm_client *client = fpriv->client;
> + struct drm_i915_private *i915 = fpriv->i915;
> + struct drm_i915_gem_object *obj;
> + struct intel_memory_region *mr;
> + struct list_head *pos;
> + unsigned int id;
> +
> + /* Public objects. */
> + spin_lock(&file->table_lock);
> + idr_for_each_entry(&file->object_idr, obj, id)
> + obj_meminfo(obj, stats);
> + spin_unlock(&file->table_lock);
> +
> + /* Internal objects. */
> + rcu_read_lock();
> + list_for_each_rcu(pos, &client->objects_list) {
> + obj = i915_gem_object_get_rcu(list_entry(pos, typeof(*obj),
> + client_link));
> + if (!obj)
> + continue;
> + obj_meminfo(obj, stats);
> + i915_gem_object_put(obj);
> + }
> + rcu_read_unlock();
> +
> + for_each_memory_region(mr, i915, id)
> + drm_print_memory_stats(p,
> +&stats[id],
> +DRM_GEM_OBJECT_RESIDENT |
> +DRM_GEM_OBJECT_PURGEABLE,
> +mr->name);
> +}
> +
> static const char * const uabi_class_names[] = {
> [I915_ENGINE_CLASS_RENDER] = "render",
> [I915_ENGINE_CLASS_COPY] = "copy",
> @@ -106,6 +168,8 @@ void i915_drm_client_fdinfo(struct drm_printer *p, struct
> drm_file *file)
>* **
>*/
>
> + show_meminfo(p, file);
> +
> if (GRAPHICS_VER(i915) < 8)
> return;
>
Reviewed-by: Aravind Iddamsetty
Thanks,
Aravind.
[PATCH v2] drm/bridge: Add 200ms delay to wait FW HPD status stable
For the no-interrupt design (sink device is panel, polling HPD status when chip power on), anx7625 FW has more than 200ms HPD de-bounce time in FW, for the safety to get HPD status, driver better to wait 200ms before HPD detection after OS resume back. Signed-off-by: Xin Ji --- drivers/gpu/drm/bridge/analogix/anx7625.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c b/drivers/gpu/drm/bridge/analogix/anx7625.c index 51abe42c639e..8f740154707d 100644 --- a/drivers/gpu/drm/bridge/analogix/anx7625.c +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c @@ -1464,6 +1464,9 @@ static int _anx7625_hpd_polling(struct anx7625_data *ctx, if (ctx->pdata.intp_irq) return 0; + /* Delay 200ms for FW HPD de-bounce */ + msleep(200); + ret = readx_poll_timeout(anx7625_read_hpd_status_p0, ctx, val, ((val & HPD_STATUS) || (val < 0)), -- 2.25.1
Re: [PATCH] drm/mediatek/dp: fix memory leak on ->get_edid callback audio detection
On Tue, 19 Sep 2023, Chen-Yu Tsai wrote:
> On Tue, Sep 19, 2023 at 7:02 PM Jani Nikula wrote:
>>
>> On Fri, 15 Sep 2023, Chen-Yu Tsai wrote:
>> > On Thu, Sep 14, 2023 at 11:53 PM Jani Nikula wrote:
>> >>
>> >> The sads returned by drm_edid_to_sad() needs to be freed.
>> >>
>> >> Fixes: e71a8ebbe086 ("drm/mediatek: dp: Audio support for MT8195")
>> >> Cc: Guillaume Ranquet
>> >> Cc: Bo-Chen Chen
>> >> Cc: AngeloGioacchino Del Regno
>> >> Cc: Dmitry Osipenko
>> >> Cc: Chun-Kuang Hu
>> >> Cc: Philipp Zabel
>> >> Cc: Matthias Brugger
>> >> Cc: dri-devel@lists.freedesktop.org
>> >> Cc: linux-media...@lists.infradead.org
>> >> Cc: linux-ker...@vger.kernel.org
>> >> Cc: linux-arm-ker...@lists.infradead.org
>> >> Cc: # v6.1+
>> >> Signed-off-by: Jani Nikula
>> >
>> > Looks correct to me.
>> >
>> > Reviewed-by: Chen-Yu Tsai
>>
>> Thanks for the reviews Chen-Yu and Guillaume. Will you push this to
>> drm-misc-next or shall I?
>
> Patches for the MediaTek drm driver go through their own separate tree,
> maintained by CK (Chun-Kuang).
Chun-Kuang, can you confirm picking up these two patches, please?
MAINTAINERS does not list a separate git repository for MediaTek drm
drivers, so I don't know where that would be. It should probably be
added to MAINTAINERS.
Thanks,
Jani.
>
> ChenYu
--
Jani Nikula, Intel
Re: [PATCH] drm/ssd130x: Drop _helper prefix from struct drm_*_helper_funcs callbacks
"Maxime Ripard" writes: > On Thu, 14 Sep 2023 21:51:24 +0200, Javier Martinez Canillas wrote: >> The driver uses a naming convention where functions for struct drm_*_funcs >> callbacks are named ssd130x_$object_$operation, while the callbacks for >> struct drm_*_helper_funcs are named ssd130x_$object_helper_$operation. >> >> The idea is that this helper_ prefix in the function names denote that are >> >> [ ... ] > > Reviewed-by: Maxime Ripard > Pushed to drm-misc (drm-misc-next). Thanks! -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
RE: [PATCH v2 3/6] drm: lcdif: rework runtime PM handling in the atomic commit
On Friday, September 22, 2023 4:03 AM Lucas Stach
wrote:
> drm_atomic_helper_commit_tail_rpm makes it hard for drivers to follow
> the documented encoder/bridge enable flow, as it commits all CRTC enables
> before the planes are fully set up, so drivers that can't enable the
> display link without valid plane setup either need to do the plane setup
> in the CRTC enable or violate the flow by enabling the display link after
> the planes have been set up. Neither of those options seem like a good
> idea.
>
> For devices that only do coarse-grained runtime PM for the whole display
> controller and not per CRTC, like the i.MX LCDIF, we can handle hardware
> wakeup and suspend in the atomic_commit_tail. Add a commit tail which
> follows the more conventional atomic commit flow of first diabling any
> unused CRTCs, setting up all the active plane state, then enable all
> active display pipes and also handles the device runtime PM at the
> appropriate times.
>
> Signed-off-by: Lucas Stach
> ---
> v2: new patch
> ---
> drivers/gpu/drm/mxsfb/lcdif_drv.c | 22 +-
> drivers/gpu/drm/mxsfb/lcdif_kms.c | 12 ++--
> 2 files changed, 31 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c
> b/drivers/gpu/drm/mxsfb/lcdif_drv.c
> index 18de2f17e249..205f6855fb1b 100644
> --- a/drivers/gpu/drm/mxsfb/lcdif_drv.c
> +++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
> @@ -36,8 +36,28 @@ static const struct drm_mode_config_funcs
> lcdif_mode_config_funcs = {
> .atomic_commit = drm_atomic_helper_commit,
> };
>
> +void lcdif_commit_tail(struct drm_atomic_state *old_state)
> +{
> + struct drm_device *drm = old_state->dev;
> +
> + pm_runtime_get_sync(drm->dev);
Here, pixel clock lcdif->clk is enabled via lcdif_rpm_resume(), and then ...
> +
> + drm_atomic_helper_commit_modeset_disables(drm, old_state);
> + drm_atomic_helper_commit_planes(drm, old_state,
> +
> DRM_PLANE_COMMIT_ACTIVE_ONLY);
> + drm_atomic_helper_commit_modeset_enables(drm, old_state);
... here, clk_set_rate() is called for lcdif->clk via
lcdif_crtc_atomic_enable().
Set rate with clock enabled?
Another concern is lcdif_reset_block() is called via lcdif_crtc_mode_set_nofb()
here, while plane is already set up, which means plane settings are potentially
reset.
With this patch series, display shows constant color by running modetest to
change fb pixel format. However, doing page flip with "-v" option seems fine.
Also, seems the issue doesn't reproduce without fbdev emulation.
Regards,
Liu Ying
> +
> + drm_atomic_helper_fake_vblank(old_state);
> + drm_atomic_helper_commit_hw_done(old_state);
> + drm_atomic_helper_wait_for_vblanks(drm, old_state);
> +
> + pm_runtime_put(drm->dev);
> +
> + drm_atomic_helper_cleanup_planes(drm, old_state);
> +}
> +
> static const struct drm_mode_config_helper_funcs
> lcdif_mode_config_helpers = {
> - .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
> + .atomic_commit_tail = lcdif_commit_tail,
> };
>
> static const struct drm_encoder_funcs lcdif_encoder_funcs = {
> diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> index e277592e5fa5..ccee5e28f236 100644
> --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> @@ -540,7 +540,11 @@ static void lcdif_crtc_atomic_enable(struct drm_crtc
> *crtc,
>
> clk_set_rate(lcdif->clk, m->crtc_clock * 1000);
>
> - pm_runtime_get_sync(drm->dev);
> + /*
> + * Update the RPM usage count, actual resume already happened in
> + * lcdif_commit_tail wrapping all the atomic update.
> + */
> + pm_runtime_get_noresume(drm->dev);
>
> lcdif_crtc_mode_set_nofb(new_cstate, new_pstate);
>
> @@ -576,7 +580,11 @@ static void lcdif_crtc_atomic_disable(struct drm_crtc
> *crtc,
> }
> spin_unlock_irq(&drm->event_lock);
>
> - pm_runtime_put_sync(drm->dev);
> + /*
> + * Update the RPM usage count, actual suspend happens in
> + * lcdif_commit_tail wrapping all the atomic update.
> + */
> + pm_runtime_put(drm->dev);
> }
>
> static void lcdif_crtc_atomic_destroy_state(struct drm_crtc *crtc,
> --
> 2.39.2
Re: Decrypting tt maps in ttm
Am 21.09.23 um 09:12 schrieb Thomas Hellström: On 9/21/23 05:51, Zack Rusin wrote: On Wed, 2023-09-20 at 21:22 +0200, Thomas Hellström wrote: !! External Email On 9/20/23 20:24, Zack Rusin wrote: On Wed, 2023-09-20 at 19:17 +0200, Thomas Hellström wrote: !! External Email Hi, Zack On 9/20/23 18:39, Zack Rusin wrote: On Wed, 2023-09-20 at 12:48 +0200, Christian König wrote: !! External Email Am 20.09.23 um 09:36 schrieb Thomas Hellström: Hi, Zack, On 9/20/23 05:43, Zack Rusin wrote: On Tue, 2023-09-19 at 09:47 +0200, Christian König wrote: !! External Email Am 19.09.23 um 08:56 schrieb Thomas Hellström: On 9/19/23 07:39, Christian König wrote: Am 19.09.23 um 03:26 schrieb Zack Rusin: On Mon, 2023-09-18 at 16:21 -0400, Alex Deucher wrote: !! External Email On Mon, Sep 18, 2023 at 3:06 PM Thomas Hellström wrote: On 9/18/23 17:52, Zack Rusin wrote: On Mon, 2023-09-18 at 17:13 +0200, Thomas Hellström wrote: Hi, On 9/18/23 16:56, Thomas Hellström wrote: Hi Zack, Christian On 9/18/23 13:36, Christian König wrote: Hi Zack, adding Thomas and Daniel. I briefly remember that I talked with Thomas and some other people about that quite a while ago as well, but I don't fully remember the outcome. Found one old thread, but didn't read it: https://lists.freedesktop.org/archives/dri-devel/2019-September/234100.html /Thomas Ugh. Now starting to read that thread I have a vague recollection it all ended with not supporting mapping any device pages whatsoever when SEV was enabled, but rather resorting to llvmpipe and VM- local bos. Hi, Thomas. Thanks for finding this! I'd (of course) like to solve it properly and get vmwgfx running with 3d support with SEV-ES active instead of essentially disabling the driver when SEV-ES is active. I think there are two separate discussions there, the non-controversial one and the controversial one: 1) The non-controversial: is there a case where drivers would want encrypted memory for TT pages but not for io mem mappings? Because if not then as Christian pointed out we could just add pgprot_decrypted to ttm_io_prot and be essentially done. The current method of decrypting io mem but leaving sys mem mappings encrypted is a bit weird anyway. If the answer to that question is "yes, some driver does want the TT mappings to be encrypted" then your "[PATCH v2 3/4] drm/ttm, drm/vmwgfx: Correctly support support AMD memory encryption" solves that. I think getting one of those two in makes sense regardless of everything else, agreed? Well, there is more to it I think. IIRC, the AMD SME encryption mode has a way for a device to have the memory controller (?) encrypt / decrypt device traffic by using an address range alias, so in theory it supports encrypted TT pages, and the dma-layer may indeed hand encrypted DMA pages to TTM on such systems depending on the device's DMA mask. That's why I think that force_dma_unencrypted() export was needed, and If the amdgpu driver accesses TT memory in SME mode *without* pgprot_decrypted() and it still works, then I think that mode is actually used. How could it otherwise work? For SME, as long as the encrypted bit is set in the physical address used for DMA, the memory controller will handle the encrypt/decrypt for the device. For devices with a limited dma mask, you need to use the IOMMU so that the encrypted bit is retained when the address hits the memory controller. How does that work on systems with swiotlb, e.g. swiotlb=force, or i.e. what would decrypt the ttm tt mappings when copying between system and vram when iommu is disabled/absent? SME makes it mandatory that all devices can handle the physical address used for DMA, either native or with the help of IOMMU. Hacks like SWIOTLB are not directly supported as far as I know. Maybe somehow SWIOTLB manually decrypts the data while copying it or something like this, but I'm not 100% sure if that is actually implemented. Regards, Christian. A bold guess after looking at various code and patches: 1) Devices under SME that don't support the encryption bit and SEV: a) Coherent memory is unencrypted. b) Streaming DMA under IOMMU: The IOMMU sets the encrypted bit. c) Streaming DMA with SWIOTLB: The bounce buffer is unencrypted. Copying to/from bounce-buffer decrypts/encrypts. 2) Devices under SME that do support the encryption bit (which I believe is most graphics devices in general on SME systems, not just amdgpu; it "just works") *) Coherent memory is encrypted. The DMA layer sets dma addresses and pgprot accordingly. *) Streaming DMA is encrypted. So the bug in TTM would then be it's not handling 1a) and 1b) correctly. Remedy: 1b) Shouldn't be used with encryption. 1a) This is what we should try to fix. Exporting dma_force_unencrypted() didn't seem to be a way forward. Properly fixing this would, I guess, mean implement the missing functionality in the dma layer: For vmap / kmap we could simply reuse the virtual addresses we get back fro
Re: [PATCH v6 2/6] drm/panfrost: Add fdinfo support GPU load metrics
On 20.09.2023 16:40, Tvrtko Ursulin wrote:
>On 20/09/2023 00:34, Adrián Larumbe wrote:
>> The drm-stats fdinfo tags made available to user space are drm-engine,
>> drm-cycles, drm-max-freq and drm-curfreq, one per job slot.
>>
>> This deviates from standard practice in other DRM drivers, where a single
>> set of key:value pairs is provided for the whole render engine. However,
>> Panfrost has separate queues for fragment and vertex/tiler jobs, so a
>> decision was made to calculate bus cycles and workload times separately.
>>
>> Maximum operating frequency is calculated at devfreq initialisation time.
>> Current frequency is made available to user space because nvtop uses it
>> when performing engine usage calculations.
>>
>> It is important to bear in mind that both GPU cycle and kernel time numbers
>> provided are at best rough estimations, and always reported in excess from
>> the actual figure because of two reasons:
>> - Excess time because of the delay between the end of a job processing,
>> the subsequent job IRQ and the actual time of the sample.
>> - Time spent in the engine queue waiting for the GPU to pick up the next
>> job.
>>
>> To avoid race conditions during enablement/disabling, a reference counting
>> mechanism was introduced, and a job flag that tells us whether a given job
>> increased the refcount. This is necessary, because user space can toggle
>> cycle counting through a debugfs file, and a given job might have been in
>> flight by the time cycle counting was disabled.
>>
>> The main goal of the debugfs cycle counter knob is letting tools like nvtop
>> or IGT's gputop switch it at any time, to avoid power waste in case no
>> engine usage measuring is necessary.
>>
>> Signed-off-by: Adrián Larumbe
>> Reviewed-by: Boris Brezillon
>> Reviewed-by: Steven Price
>> ---
>> drivers/gpu/drm/panfrost/Makefile | 2 +
>> drivers/gpu/drm/panfrost/panfrost_debugfs.c | 20
>> drivers/gpu/drm/panfrost/panfrost_debugfs.h | 13 +
>> drivers/gpu/drm/panfrost/panfrost_devfreq.c | 8 +++
>> drivers/gpu/drm/panfrost/panfrost_devfreq.h | 3 ++
>> drivers/gpu/drm/panfrost/panfrost_device.c | 2 +
>> drivers/gpu/drm/panfrost/panfrost_device.h | 13 +
>> drivers/gpu/drm/panfrost/panfrost_drv.c | 57 -
>> drivers/gpu/drm/panfrost/panfrost_gpu.c | 41 +++
>> drivers/gpu/drm/panfrost/panfrost_gpu.h | 4 ++
>> drivers/gpu/drm/panfrost/panfrost_job.c | 24 +
>> drivers/gpu/drm/panfrost/panfrost_job.h | 5 ++
>> 12 files changed, 191 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/gpu/drm/panfrost/panfrost_debugfs.c
>> create mode 100644 drivers/gpu/drm/panfrost/panfrost_debugfs.h
>>
>> diff --git a/drivers/gpu/drm/panfrost/Makefile
>> b/drivers/gpu/drm/panfrost/Makefile
>> index 7da2b3f02ed9..2c01c1e7523e 100644
>> --- a/drivers/gpu/drm/panfrost/Makefile
>> +++ b/drivers/gpu/drm/panfrost/Makefile
>> @@ -12,4 +12,6 @@ panfrost-y := \
>> panfrost_perfcnt.o \
>> panfrost_dump.o
>> +panfrost-$(CONFIG_DEBUG_FS) += panfrost_debugfs.o
>> +
>> obj-$(CONFIG_DRM_PANFROST) += panfrost.o
>> diff --git a/drivers/gpu/drm/panfrost/panfrost_debugfs.c
>> b/drivers/gpu/drm/panfrost/panfrost_debugfs.c
>> new file mode 100644
>> index ..cc14eccba206
>> --- /dev/null
>> +++ b/drivers/gpu/drm/panfrost/panfrost_debugfs.c
>> @@ -0,0 +1,20 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/* Copyright 2023 Collabora ltd. */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "panfrost_device.h"
>> +#include "panfrost_gpu.h"
>> +#include "panfrost_debugfs.h"
>> +
>> +void panfrost_debugfs_init(struct drm_minor *minor)
>> +{
>> +struct drm_device *dev = minor->dev;
>> +struct panfrost_device *pfdev =
>> platform_get_drvdata(to_platform_device(dev->dev));
>> +
>> +debugfs_create_atomic_t("profile", 0600, minor->debugfs_root,
>> &pfdev->profile_mode);
>> +}
>> diff --git a/drivers/gpu/drm/panfrost/panfrost_debugfs.h
>> b/drivers/gpu/drm/panfrost/panfrost_debugfs.h
>> new file mode 100644
>> index ..db1c158bcf2f
>> --- /dev/null
>> +++ b/drivers/gpu/drm/panfrost/panfrost_debugfs.h
>> @@ -0,0 +1,13 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * Copyright 2023 Collabora ltd.
>> + */
>> +
>> +#ifndef PANFROST_DEBUGFS_H
>> +#define PANFROST_DEBUGFS_H
>> +
>> +#ifdef CONFIG_DEBUG_FS
>> +void panfrost_debugfs_init(struct drm_minor *minor);
>> +#endif
>> +
>> +#endif /* PANFROST_DEBUGFS_H */
>> diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
>> b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
>> index 58dfb15a8757..28caffc689e2 100644
>> --- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
>> +++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
>> @@ -58,6 +58,7 @@ static int panfrost_devfreq_get_dev_status(struct device
>> *dev,
>> spin_lock_irqsave(&pfdevfreq->lock, irqflags);
>> panfrost_
Re: [PATCH 5/5] drm/i915: Implement fdinfo memory stats printing
On 22/09/2023 09:48, Iddamsetty, Aravind wrote:
On 21-09-2023 17:18, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Use the newly added drm_print_memory_stats helper to show memory
utilisation of our objects in drm/driver specific fdinfo output.
To collect the stats we walk the per memory regions object lists
and accumulate object size into the respective drm_memory_stats
categories.
Objects with multiple possible placements are reported in multiple
regions for total and shared sizes, while other categories are
I guess you forgot to correct this.
Ah yes, will fix.
counted only for the currently active region.
v2:
* Only account against the active region.
* Use DMA_RESV_USAGE_BOOKKEEP when testing for active. (Tejas)
Signed-off-by: Tvrtko Ursulin
Cc: Aravind Iddamsetty
Cc: Rob Clark
Cc: Andi Shyti
Cc: Tejas Upadhyay
Reviewed-by: Andi Shyti # v1
---
drivers/gpu/drm/i915/i915_drm_client.c | 64 ++
1 file changed, 64 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index a61356012df8..94abc2fb2ea6 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -45,6 +45,68 @@ void __i915_drm_client_free(struct kref *kref)
}
#ifdef CONFIG_PROC_FS
+static void
+obj_meminfo(struct drm_i915_gem_object *obj,
+ struct drm_memory_stats stats[INTEL_REGION_UNKNOWN])
+{
+ const enum intel_region_id id = obj->mm.region ?
+ obj->mm.region->id : INTEL_REGION_SMEM;
+ const u64 sz = obj->base.size;
+
+ if (obj->base.handle_count > 1)
+ stats[id].shared += sz;
+ else
+ stats[id].private += sz;
+
+ if (i915_gem_object_has_pages(obj)) {
+ stats[id].resident += sz;
+
+ if (!dma_resv_test_signaled(obj->base.resv,
+ DMA_RESV_USAGE_BOOKKEEP))
+ stats[id].active += sz;
+ else if (i915_gem_object_is_shrinkable(obj) &&
+obj->mm.madv == I915_MADV_DONTNEED)
+ stats[id].purgeable += sz;
+ }
+}
+
+static void show_meminfo(struct drm_printer *p, struct drm_file *file)
+{
+ struct drm_memory_stats stats[INTEL_REGION_UNKNOWN] = {};
+ struct drm_i915_file_private *fpriv = file->driver_priv;
+ struct i915_drm_client *client = fpriv->client;
+ struct drm_i915_private *i915 = fpriv->i915;
+ struct drm_i915_gem_object *obj;
+ struct intel_memory_region *mr;
+ struct list_head *pos;
+ unsigned int id;
+
+ /* Public objects. */
+ spin_lock(&file->table_lock);
+ idr_for_each_entry(&file->object_idr, obj, id)
+ obj_meminfo(obj, stats);
+ spin_unlock(&file->table_lock);
+
+ /* Internal objects. */
+ rcu_read_lock();
+ list_for_each_rcu(pos, &client->objects_list) {
+ obj = i915_gem_object_get_rcu(list_entry(pos, typeof(*obj),
+client_link));
+ if (!obj)
+ continue;
+ obj_meminfo(obj, stats);
+ i915_gem_object_put(obj);
+ }
+ rcu_read_unlock();
+
+ for_each_memory_region(mr, i915, id)
+ drm_print_memory_stats(p,
+ &stats[id],
+ DRM_GEM_OBJECT_RESIDENT |
+ DRM_GEM_OBJECT_PURGEABLE,
+ mr->name);
+}
+
static const char * const uabi_class_names[] = {
[I915_ENGINE_CLASS_RENDER] = "render",
[I915_ENGINE_CLASS_COPY] = "copy",
@@ -106,6 +168,8 @@ void i915_drm_client_fdinfo(struct drm_printer *p, struct
drm_file *file)
* **
*/
+ show_meminfo(p, file);
+
if (GRAPHICS_VER(i915) < 8)
return;
Reviewed-by: Aravind Iddamsetty
Thank you! Would you be able to also look at the IGTs I posted yesterday?
Regards,
Tvrtko
Re: [PATCH v6 4/6] drm/drm_file: Add DRM obj's RSS reporting function for fdinfo
On 20.09.2023 16:53, Tvrtko Ursulin wrote:
>
>On 20/09/2023 00:34, Adrián Larumbe wrote:
>> Some BO's might be mapped onto physical memory chunkwise and on demand,
>> like Panfrost's tiler heap. In this case, even though the
>> drm_gem_shmem_object page array might already be allocated, only a very
>> small fraction of the BO is currently backed by system memory, but
>> drm_show_memory_stats will then proceed to add its entire virtual size to
>> the file's total resident size regardless.
>>
>> This led to very unrealistic RSS sizes being reckoned for Panfrost, where
>> said tiler heap buffer is initially allocated with a virtual size of 128
>> MiB, but only a small part of it will eventually be backed by system memory
>> after successive GPU page faults.
>>
>> Provide a new DRM object generic function that would allow drivers to
>> return a more accurate RSS size for their BOs.
>>
>> Signed-off-by: Adrián Larumbe
>> Reviewed-by: Boris Brezillon
>> Reviewed-by: Steven Price
>> ---
>> drivers/gpu/drm/drm_file.c | 5 -
>> include/drm/drm_gem.h | 9 +
>> 2 files changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
>> index 883d83bc0e3d..762965e3d503 100644
>> --- a/drivers/gpu/drm/drm_file.c
>> +++ b/drivers/gpu/drm/drm_file.c
>> @@ -944,7 +944,10 @@ void drm_show_memory_stats(struct drm_printer *p,
>> struct drm_file *file)
>> }
>> if (s & DRM_GEM_OBJECT_RESIDENT) {
>> -status.resident += obj->size;
>> +if (obj->funcs && obj->funcs->rss)
>> +status.resident += obj->funcs->rss(obj);
>> +else
>> +status.resident += obj->size;
>
>Presumably you'd want the same smaller size in both active and purgeable? Or
>you can end up with more in those two than in rss which would look odd.
I didn't think of this. I guess when an object is both resident and purgeable,
then its RSS and purgeable sizes should be the same.
>Also, alternative to adding a new callback could be adding multiple output
>parameters to the existing obj->func->status() which maybe ends up simpler due
>fewer callbacks?
>
>Like:
>
> s = obj->funcs->status(obj, &supported_status, &rss)
>
>And adjust the code flow to pick up the rss if driver signaled it supports
>reporting it.
I personally find having a separate object callback more readable in this case.
There's also the question of what output parameter value would be used as a
token
that the relevant BO doesn't have an RSS different from its virtual
size. I guess '0' would be alright, but this is on the assumption that this
could never be a legitimate BO virtual size across all DRM drivers. I guess
most of them round the size up to the nearest page multiple at BO creation
time.
>
>Regards,
>
>Tvrtko
>
>> } else {
>> /* If already purged or not yet backed by pages, don't
>> * count it as purgeable:
>> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
>> index bc9f6aa2f3fe..16364487fde9 100644
>> --- a/include/drm/drm_gem.h
>> +++ b/include/drm/drm_gem.h
>> @@ -208,6 +208,15 @@ struct drm_gem_object_funcs {
>> */
>> enum drm_gem_object_status (*status)(struct drm_gem_object *obj);
>> +/**
>> + * @rss:
>> + *
>> + * Return resident size of the object in physical memory.
>> + *
>> + * Called by drm_show_memory_stats().
>> + */
>> +size_t (*rss)(struct drm_gem_object *obj);
>> +
>> /**
>> * @vm_ops:
>> *
Re: [PATCH 5/5] drm/i915: Implement fdinfo memory stats printing
Hi Tvrtko,
On Thu, Sep 21, 2023 at 12:48:52PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Use the newly added drm_print_memory_stats helper to show memory
> utilisation of our objects in drm/driver specific fdinfo output.
>
> To collect the stats we walk the per memory regions object lists
> and accumulate object size into the respective drm_memory_stats
> categories.
>
> Objects with multiple possible placements are reported in multiple
> regions for total and shared sizes, while other categories are
> counted only for the currently active region.
>
> v2:
> * Only account against the active region.
> * Use DMA_RESV_USAGE_BOOKKEEP when testing for active. (Tejas)
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Aravind Iddamsetty
> Cc: Rob Clark
> Cc: Andi Shyti
> Cc: Tejas Upadhyay
> Reviewed-by: Andi Shyti # v1
Reiewed also this version :)
Thanks,
Andi
> ---
> drivers/gpu/drm/i915/i915_drm_client.c | 64 ++
> 1 file changed, 64 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
> b/drivers/gpu/drm/i915/i915_drm_client.c
> index a61356012df8..94abc2fb2ea6 100644
> --- a/drivers/gpu/drm/i915/i915_drm_client.c
> +++ b/drivers/gpu/drm/i915/i915_drm_client.c
> @@ -45,6 +45,68 @@ void __i915_drm_client_free(struct kref *kref)
> }
>
> #ifdef CONFIG_PROC_FS
> +static void
> +obj_meminfo(struct drm_i915_gem_object *obj,
> + struct drm_memory_stats stats[INTEL_REGION_UNKNOWN])
> +{
> + const enum intel_region_id id = obj->mm.region ?
> + obj->mm.region->id : INTEL_REGION_SMEM;
> + const u64 sz = obj->base.size;
> +
> + if (obj->base.handle_count > 1)
> + stats[id].shared += sz;
> + else
> + stats[id].private += sz;
> +
> + if (i915_gem_object_has_pages(obj)) {
> + stats[id].resident += sz;
> +
> + if (!dma_resv_test_signaled(obj->base.resv,
> + DMA_RESV_USAGE_BOOKKEEP))
> + stats[id].active += sz;
> + else if (i915_gem_object_is_shrinkable(obj) &&
> + obj->mm.madv == I915_MADV_DONTNEED)
> + stats[id].purgeable += sz;
> + }
> +}
> +
> +static void show_meminfo(struct drm_printer *p, struct drm_file *file)
> +{
> + struct drm_memory_stats stats[INTEL_REGION_UNKNOWN] = {};
> + struct drm_i915_file_private *fpriv = file->driver_priv;
> + struct i915_drm_client *client = fpriv->client;
> + struct drm_i915_private *i915 = fpriv->i915;
> + struct drm_i915_gem_object *obj;
> + struct intel_memory_region *mr;
> + struct list_head *pos;
> + unsigned int id;
> +
> + /* Public objects. */
> + spin_lock(&file->table_lock);
> + idr_for_each_entry(&file->object_idr, obj, id)
> + obj_meminfo(obj, stats);
> + spin_unlock(&file->table_lock);
> +
> + /* Internal objects. */
> + rcu_read_lock();
> + list_for_each_rcu(pos, &client->objects_list) {
> + obj = i915_gem_object_get_rcu(list_entry(pos, typeof(*obj),
> + client_link));
> + if (!obj)
> + continue;
> + obj_meminfo(obj, stats);
> + i915_gem_object_put(obj);
> + }
> + rcu_read_unlock();
> +
> + for_each_memory_region(mr, i915, id)
> + drm_print_memory_stats(p,
> +&stats[id],
> +DRM_GEM_OBJECT_RESIDENT |
> +DRM_GEM_OBJECT_PURGEABLE,
> +mr->name);
> +}
> +
> static const char * const uabi_class_names[] = {
> [I915_ENGINE_CLASS_RENDER] = "render",
> [I915_ENGINE_CLASS_COPY] = "copy",
> @@ -106,6 +168,8 @@ void i915_drm_client_fdinfo(struct drm_printer *p, struct
> drm_file *file)
>* **
>*/
>
> + show_meminfo(p, file);
> +
> if (GRAPHICS_VER(i915) < 8)
> return;
>
> --
> 2.39.2
Re: [PATCH v6 6/6] drm/drm-file: Show finer-grained BO sizes in drm_show_memory_stats
On 20.09.2023 16:32, Tvrtko Ursulin wrote:
>
>On 20/09/2023 00:34, Adrián Larumbe wrote:
>> The current implementation will try to pick the highest available size
>> display unit as soon as the BO size exceeds that of the previous
>> multiplier. That can lead to loss of precision in contexts of low memory
>> usage.
>>
>> The new selection criteria try to preserve precision, whilst also
>> increasing the display unit selection threshold to render more accurate
>> values.
>>
>> Signed-off-by: Adrián Larumbe
>> Reviewed-by: Boris Brezillon
>> Reviewed-by: Steven Price
>> ---
>> drivers/gpu/drm/drm_file.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
>> index 762965e3d503..34cfa128ffe5 100644
>> --- a/drivers/gpu/drm/drm_file.c
>> +++ b/drivers/gpu/drm/drm_file.c
>> @@ -872,6 +872,8 @@ void drm_send_event(struct drm_device *dev, struct
>> drm_pending_event *e)
>> }
>> EXPORT_SYMBOL(drm_send_event);
>> +#define UPPER_UNIT_THRESHOLD 100
>> +
>> static void print_size(struct drm_printer *p, const char *stat,
>> const char *region, u64 sz)
>> {
>> @@ -879,7 +881,8 @@ static void print_size(struct drm_printer *p, const char
>> *stat,
>> unsigned u;
>> for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
>> -if (sz < SZ_1K)
>> +if ((sz & (SZ_1K - 1)) &&
>
>IS_ALIGNED worth it at all?
This could look better, yeah.
>> +sz < UPPER_UNIT_THRESHOLD * SZ_1K)
>> break;
>
>Excuse me for a late comment (I was away). I did not get what what is special
>about a ~10% threshold? Sounds to me just going with the lower unit, when size
>is not aligned to the higher one, would be better than sometimes
>precision-sometimes-not.
We had a bit of a debate over this in previous revisions of the patch. It all
began
when a Panfrost user complained that for relatively small BOs, they were losing
precision in the fdinfo file because the sum of the sizes of all BOs for a drm
file
was in the order of MiBs, but not big enough to warrant losing accuracy when
plotting them on nvtop or gputop.
At first I thought of letting drivers pick their own preferred unit, but this
would
lead to inconsistency in the units presented in the fdinfo file across different
DRM devices. Rob then suggested imposing a unit multiple threshold, while Boris
made the suggestion of checking for unit size alignment to lessen precision
loss.
In the end Rob thought that minding both constraints was a good solution of
compromise.
The unit threshold was picked sort of arbitrarily, and suggested by Rob
himself. The
point of having it is avoiding huge number representations for BO size tallies
that
aren't aligned to the next unit, and also because BO size sums are scaled when
plotting them on a Y axis, so complete accuracy isn't a requirement.
>Regards,
>
>Tvrtko
>
>> sz = div_u64(sz, SZ_1K);
>> }
Adrian Larumbe
Re: [PATCH v6 6/6] drm/drm-file: Show finer-grained BO sizes in drm_show_memory_stats
On 21.09.2023 11:14, Tvrtko Ursulin wrote:
>
>On 20/09/2023 16:32, Tvrtko Ursulin wrote:
>>
>> On 20/09/2023 00:34, Adrián Larumbe wrote:
>> > The current implementation will try to pick the highest available size
>> > display unit as soon as the BO size exceeds that of the previous
>> > multiplier. That can lead to loss of precision in contexts of low memory
>> > usage.
>> >
>> > The new selection criteria try to preserve precision, whilst also
>> > increasing the display unit selection threshold to render more accurate
>> > values.
>> >
>> > Signed-off-by: Adrián Larumbe
>> > Reviewed-by: Boris Brezillon
>> > Reviewed-by: Steven Price
>> > ---
>> > drivers/gpu/drm/drm_file.c | 5 -
>> > 1 file changed, 4 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
>> > index 762965e3d503..34cfa128ffe5 100644
>> > --- a/drivers/gpu/drm/drm_file.c
>> > +++ b/drivers/gpu/drm/drm_file.c
>> > @@ -872,6 +872,8 @@ void drm_send_event(struct drm_device *dev, struct
>> > drm_pending_event *e)
>> > }
>> > EXPORT_SYMBOL(drm_send_event);
>> > +#define UPPER_UNIT_THRESHOLD 100
>> > +
>> > static void print_size(struct drm_printer *p, const char *stat,
>> > const char *region, u64 sz)
>> > {
>> > @@ -879,7 +881,8 @@ static void print_size(struct drm_printer *p,
>> > const char *stat,
>> > unsigned u;
>> > for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
>> > - if (sz < SZ_1K)
>> > + if ((sz & (SZ_1K - 1)) &&
>>
>> IS_ALIGNED worth it at all?
>>
>> > + sz < UPPER_UNIT_THRESHOLD * SZ_1K)
>> > break;
>>
>> Excuse me for a late comment (I was away). I did not get what what is
>> special about a ~10% threshold? Sounds to me just going with the lower
>> unit, when size is not aligned to the higher one, would be better than
>> sometimes precision-sometimes-not.
>
>FWIW both current and the threshold option make testing the feature very
>annoying.
How so?
>So I'd really propose we simply use smaller unit when unaligned.
Like I said in the previous reply, for drm files whose overall BO size sum is
enormous
but not a multiple of a MiB, this would render huge number representations in
KiB.
I don't find this particularly comfortable to read, and then this extra
precision
would mean nothing to nvtop or gputop, which would have to scale the size to
their
available screen dimensions when plotting them.
>Regards,
>
>Tvrtko
Re: [PATCH drm-misc-next v4 6/8] drm/gpuvm: add drm_gpuvm_flags to drm_gpuvm
On Wed, 20 Sep 2023 16:42:39 +0200 Danilo Krummrich wrote: > void drm_gpuvm_init(struct drm_gpuvm *gpuvm, struct drm_device *drm, > - const char *name, > + const char *name, enum drm_gpuva_flags flags, s/drm_gpuva_flags/drm_gpuvm_flags/gc
Re: [PATCH drm-misc-next v4 7/8] drm/gpuvm: generalize dma_resv/extobj handling and GEM validation
On Wed, 20 Sep 2023 16:42:40 +0200 Danilo Krummrich wrote: > + /** > + * @DRM_GPUVM_RESV_PROTECTED: GPUVM is protected externally by the > + * GPUVM's &dma_resv lock I think we need to be more specific, and list the fields/operations that need to be externally protected when DRM_GPUVM_RESV_PROTECTED is set. > + */ > + DRM_GPUVM_RESV_PROTECTED = (1 << 0),
Re: [PATCH] drm/mipi-dsi: Fix detach call without attach
Hi, I have tested this on an OMAP5 Pyra. > Am 21.09.2023 um 12:50 schrieb Tomi Valkeinen > : > > It's been reported that DSI host driver's detach can be called without > the attach ever happening: > > https://lore.kernel.org/all/20230412073954.20601-1-t...@atomide.com/ > This patch works equally well as my proposal and is indeed a better solution (solving the issue and not just suppressing a warning). Tested-by: H. Nikolaus Schaller BR and thanks, Nikolaus
Re: [PATCH drm-misc-next v4 6/8] drm/gpuvm: add drm_gpuvm_flags to drm_gpuvm
On Wed, 20 Sep 2023 16:42:39 +0200
Danilo Krummrich wrote:
> +/**
> + * enum drm_gpuvm_flags - flags for struct drm_gpuvm
> + */
> +enum drm_gpuvm_flags {
> + /**
> + * @DRM_GPUVM_USERBITS: user defined bits
> + */
> + DRM_GPUVM_USERBITS = (1 << 0),
Nit: I tried declaring driver-specific flags, and I find this
counter-intuitive. You basically end up with something like:
enum my_gpuvm_flags {
MY_FLAG_X = DRM_GPUVM_USERBITS,
MY_FLAG_Y = DRM_GPUVM_USERBITS << 1,
};
instead of the usual
enum my_gpuvm_flags {
MY_FLAG_X = BIT(0),
MY_FLAG_Y = BIT(1),
};
pattern.
Another issue I see coming is if we end up adding more core flags and
drivers start falling short of bits for their own flags. This makes me
wonder if we shouldn't kill this notion of USER flags and let drivers
store their flags in some dedicated field, given they're likely to
derive drm_gpuvm and drm_gpuva with their own object anyway.
> +};
> +
Re: [PATCH 1/8] drm/display/dp: Add helper function to get DSC bpp prescision
On Thu, Sep 21, 2023 at 10:41:43AM +0300, Jani Nikula wrote: > On Wed, 13 Sep 2023, Mitul Golani > wrote: > > From: Ankit Nautiyal > > > > Add helper to get the DSC bits_per_pixel precision for the DP sink. > > > > Signed-off-by: Ankit Nautiyal > > Maarten, Maxime, Thomas, ack for merging this via drm-intel please? That's fine by me :) Maxime signature.asc Description: PGP signature
Re: [PATCH 7/8] drm/i915/dsc: Add debugfs entry to validate DSC fractional bpp
On Thu, 21 Sep 2023, "Sharma, Swati2" wrote:
> On 21-Sep-23 5:44 PM, Jani Nikula wrote:
>> On Thu, 21 Sep 2023, "Sharma, Swati2" wrote:
>>> On 21-Sep-23 1:30 PM, Jani Nikula wrote:
On Wed, 13 Sep 2023, Mitul Golani
wrote:
> From: Swati Sharma
>
> DSC_Sink_BPP_Precision entry is added to i915_dsc_fec_support_show
> to depict sink's precision.
> Also, new debugfs entry is created to enforce fractional bpp.
> If Force_DSC_Fractional_BPP_en is set then while iterating over
> output bpp with fractional step size we will continue if output_bpp is
> computed as integer. With this approach, we will be able to validate
> DSC with fractional bpp.
>
> v2:
> Add drm_modeset_unlock to new line(Suraj)
>
> Signed-off-by: Swati Sharma
> Signed-off-by: Ankit Nautiyal
> Signed-off-by: Mitul Golani
> Reviewed-by: Suraj Kandpal
> ---
>.../drm/i915/display/intel_display_debugfs.c | 83 +++
>.../drm/i915/display/intel_display_types.h| 1 +
>2 files changed, 84 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index f05b52381a83..776ab96def1f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -1244,6 +1244,8 @@ static int i915_dsc_fec_support_show(struct
> seq_file *m, void *data)
>
> DP_DSC_YCbCr420_Native)),
>
> str_yes_no(drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd,
>
> DP_DSC_YCbCr444)));
> + seq_printf(m, "DSC_Sink_BPP_Precision: %d\n",
> +drm_dp_dsc_sink_bpp_incr(intel_dp->dsc_dpcd));
> seq_printf(m, "Force_DSC_Enable: %s\n",
> str_yes_no(intel_dp->force_dsc_en));
> if (!intel_dp_is_edp(intel_dp))
> @@ -1436,6 +1438,84 @@ static const struct file_operations
> i915_dsc_output_format_fops = {
> .write = i915_dsc_output_format_write
>};
>
> +static int i915_dsc_fractional_bpp_show(struct seq_file *m, void *data)
> +{
> + struct drm_connector *connector = m->private;
> + struct drm_device *dev = connector->dev;
> + struct drm_crtc *crtc;
> + struct intel_dp *intel_dp;
> + struct intel_encoder *encoder =
> intel_attached_encoder(to_intel_connector(connector));
> + int ret;
> +
> + if (!encoder)
> + return -ENODEV;
> +
> + ret =
> drm_modeset_lock_single_interruptible(&dev->mode_config.connection_mutex);
> + if (ret)
> + return ret;
> +
> + crtc = connector->state->crtc;
> + if (connector->status != connector_status_connected || !crtc) {
> + ret = -ENODEV;
> + goto out;
> + }
> +
> + intel_dp = intel_attached_dp(to_intel_connector(connector));
> + seq_printf(m, "Force_DSC_Fractional_BPP_Enable: %s\n",
> +str_yes_no(intel_dp->force_dsc_fractional_bpp_en));
Why "Force_DSC_Fractional_BPP_Enable" in the output?
Usually debugfs files, like sysfs files, for stuff like this should be
attributes, one thing per file. Why print a long name for it, if the
name of the debugfs file is the name of the attribute?
And even if you print it for humans, why the underscores?
>>>
>>> Hi Jani,
>>> Followed same strategy as we are doing for other dsc scenarios like
>>> force_dsc.
>>> Even naming convention followed same as other dsc stuff like
>>> Force_DSC_Enable, etc.
>>> All DSC related enteries have underscores in its naming convention.
>>
>> There's value in that, though maybe my comment highlights I'm not fond
>> of the existing stuff. ;)
>
> Sure, I can work on cleanup part later.
>
>>
>>> May be i can consolidate other dsc debugfs enteries into
>>> one as a cleanup task later. But it will impact IGT aswell. And i'm not
>>> sure if we can break compatibility but since IGT (intel as only vendor)
>>> is the only consumer, may be we change at both places and clean it up.
>>
>> We can do what we want with debugfs, as long as we change both the
>> driver and igt.
>
> Sure, will make corresponding changes in both IGT and KMD.
>
>>
>>>
> +
> +out:
> + drm_modeset_unlock(&dev->mode_config.connection_mutex);
> +
> + return ret;
> +}
> +
> +static ssize_t i915_dsc_fractional_bpp_write(struct file *file,
> + const char __user *ubuf,
> + size_t len, loff_t *offp)
> +{
> + struct drm_connector *connector =
> + ((struct seq_file *)file->
Re: [PATCH 5/5] drm/i915: Implement fdinfo memory stats printing
On 22-09-2023 16:27, Tvrtko Ursulin wrote:
>
> On 22/09/2023 09:48, Iddamsetty, Aravind wrote:
>>
>>
>> On 21-09-2023 17:18, Tvrtko Ursulin wrote:
>>> From: Tvrtko Ursulin
>>>
>>> Use the newly added drm_print_memory_stats helper to show memory
>>> utilisation of our objects in drm/driver specific fdinfo output.
>>>
>>> To collect the stats we walk the per memory regions object lists
>>> and accumulate object size into the respective drm_memory_stats
>>> categories.
>>>
>>> Objects with multiple possible placements are reported in multiple
>>> regions for total and shared sizes, while other categories are
>>
>> I guess you forgot to correct this.
>
> Ah yes, will fix.
>
>>
>>> counted only for the currently active region.
>>>
>>> v2:
>>> * Only account against the active region.
>>> * Use DMA_RESV_USAGE_BOOKKEEP when testing for active. (Tejas)
>>>
>>> Signed-off-by: Tvrtko Ursulin
>>> Cc: Aravind Iddamsetty
>>> Cc: Rob Clark
>>> Cc: Andi Shyti
>>> Cc: Tejas Upadhyay
>>> Reviewed-by: Andi Shyti # v1
>>> ---
>>> drivers/gpu/drm/i915/i915_drm_client.c | 64 ++
>>> 1 file changed, 64 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
>>> b/drivers/gpu/drm/i915/i915_drm_client.c
>>> index a61356012df8..94abc2fb2ea6 100644
>>> --- a/drivers/gpu/drm/i915/i915_drm_client.c
>>> +++ b/drivers/gpu/drm/i915/i915_drm_client.c
>>> @@ -45,6 +45,68 @@ void __i915_drm_client_free(struct kref *kref)
>>> }
>>> #ifdef CONFIG_PROC_FS
>>> +static void
>>> +obj_meminfo(struct drm_i915_gem_object *obj,
>>> + struct drm_memory_stats stats[INTEL_REGION_UNKNOWN])
>>> +{
>>> + const enum intel_region_id id = obj->mm.region ?
>>> + obj->mm.region->id : INTEL_REGION_SMEM;
>>> + const u64 sz = obj->base.size;
>>> +
>>> + if (obj->base.handle_count > 1)
>>> + stats[id].shared += sz;
>>> + else
>>> + stats[id].private += sz;
>>> +
>>> + if (i915_gem_object_has_pages(obj)) {
>>> + stats[id].resident += sz;
>>> +
>>> + if (!dma_resv_test_signaled(obj->base.resv,
>>> + DMA_RESV_USAGE_BOOKKEEP))
>>> + stats[id].active += sz;
>>> + else if (i915_gem_object_is_shrinkable(obj) &&
>>> + obj->mm.madv == I915_MADV_DONTNEED)
>>> + stats[id].purgeable += sz;
>>> + }
>>> +}
>>> +
>>> +static void show_meminfo(struct drm_printer *p, struct drm_file *file)
>>> +{
>>> + struct drm_memory_stats stats[INTEL_REGION_UNKNOWN] = {};
>>> + struct drm_i915_file_private *fpriv = file->driver_priv;
>>> + struct i915_drm_client *client = fpriv->client;
>>> + struct drm_i915_private *i915 = fpriv->i915;
>>> + struct drm_i915_gem_object *obj;
>>> + struct intel_memory_region *mr;
>>> + struct list_head *pos;
>>> + unsigned int id;
>>> +
>>> + /* Public objects. */
>>> + spin_lock(&file->table_lock);
>>> + idr_for_each_entry(&file->object_idr, obj, id)
>>> + obj_meminfo(obj, stats);
>>> + spin_unlock(&file->table_lock);
>>> +
>>> + /* Internal objects. */
>>> + rcu_read_lock();
>>> + list_for_each_rcu(pos, &client->objects_list) {
>>> + obj = i915_gem_object_get_rcu(list_entry(pos, typeof(*obj),
>>> + client_link));
>>> + if (!obj)
>>> + continue;
>>> + obj_meminfo(obj, stats);
>>> + i915_gem_object_put(obj);
>>> + }
>>> + rcu_read_unlock();
>>> +
>>> + for_each_memory_region(mr, i915, id)
>>> + drm_print_memory_stats(p,
>>> + &stats[id],
>>> + DRM_GEM_OBJECT_RESIDENT |
>>> + DRM_GEM_OBJECT_PURGEABLE,
>>> + mr->name);
>>> +}
>>> +
>>> static const char * const uabi_class_names[] = {
>>> [I915_ENGINE_CLASS_RENDER] = "render",
>>> [I915_ENGINE_CLASS_COPY] = "copy",
>>> @@ -106,6 +168,8 @@ void i915_drm_client_fdinfo(struct drm_printer
>>> *p, struct drm_file *file)
>>> *
>>> **
>>> */
>>> + show_meminfo(p, file);
>>> +
>>> if (GRAPHICS_VER(i915) < 8)
>>> return;
>>>
>>
>> Reviewed-by: Aravind Iddamsetty
>
> Thank you! Would you be able to also look at the IGTs I posted yesterday?
Ya sure will take a look.
Thanks,
Aravind.
>
> Regards,
>
> Tvrtko
[PATCH] drm/i915/gem: Make i915_gem_shrinker multi-gt aware
From: Jonathan Cavitt
Where applicable, use for_each_gt instead of to_gt in the
i915_gem_shrinker functions to make them apply to more than just the
primary GT. Specifically, this ensure i915_gem_shrink_all retires all
requests across all GTs, and this makes i915_gem_shrinker_vmap unmap
VMAs from all GTs.
Signed-off-by: Jonathan Cavitt
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 44
1 file changed, 26 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index 214763942aa2..3ef1fd32f80a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -14,6 +14,7 @@
#include
#include "gt/intel_gt_requests.h"
+#include "gt/intel_gt.h"
#include "i915_trace.h"
@@ -119,7 +120,8 @@ i915_gem_shrink(struct i915_gem_ww_ctx *ww,
intel_wakeref_t wakeref = 0;
unsigned long count = 0;
unsigned long scanned = 0;
- int err = 0;
+ int err = 0, i = 0;
+ struct intel_gt *gt;
/* CHV + VTD workaround use stop_machine(); need to trylock vm->mutex */
bool trylock_vm = !ww && intel_vm_no_concurrent_access_wa(i915);
@@ -147,9 +149,11 @@ i915_gem_shrink(struct i915_gem_ww_ctx *ww,
* what we can do is give them a kick so that we do not keep idle
* contexts around longer than is necessary.
*/
- if (shrink & I915_SHRINK_ACTIVE)
- /* Retire requests to unpin all idle contexts */
- intel_gt_retire_requests(to_gt(i915));
+ if (shrink & I915_SHRINK_ACTIVE) {
+ for_each_gt(gt, i915, i)
+ /* Retire requests to unpin all idle contexts */
+ intel_gt_retire_requests(to_gt(i915));
+ }
/*
* As we may completely rewrite the (un)bound list whilst unbinding
@@ -389,6 +393,8 @@ i915_gem_shrinker_vmap(struct notifier_block *nb, unsigned
long event, void *ptr
struct i915_vma *vma, *next;
unsigned long freed_pages = 0;
intel_wakeref_t wakeref;
+ struct intel_gt *gt;
+ int i;
with_intel_runtime_pm(&i915->runtime_pm, wakeref)
freed_pages += i915_gem_shrink(NULL, i915, -1UL, NULL,
@@ -397,24 +403,26 @@ i915_gem_shrinker_vmap(struct notifier_block *nb,
unsigned long event, void *ptr
I915_SHRINK_VMAPS);
/* We also want to clear any cached iomaps as they wrap vmap */
- mutex_lock(&to_gt(i915)->ggtt->vm.mutex);
- list_for_each_entry_safe(vma, next,
-&to_gt(i915)->ggtt->vm.bound_list, vm_link) {
- unsigned long count = i915_vma_size(vma) >> PAGE_SHIFT;
- struct drm_i915_gem_object *obj = vma->obj;
-
- if (!vma->iomap || i915_vma_is_active(vma))
- continue;
+ for_each_gt(gt, i915, i) {
+ mutex_lock(>->ggtt->vm.mutex);
+ list_for_each_entry_safe(vma, next,
+>->ggtt->vm.bound_list, vm_link) {
+ unsigned long count = i915_vma_size(vma) >> PAGE_SHIFT;
+ struct drm_i915_gem_object *obj = vma->obj;
+
+ if (!vma->iomap || i915_vma_is_active(vma))
+ continue;
- if (!i915_gem_object_trylock(obj, NULL))
- continue;
+ if (!i915_gem_object_trylock(obj, NULL))
+ continue;
- if (__i915_vma_unbind(vma) == 0)
- freed_pages += count;
+ if (__i915_vma_unbind(vma) == 0)
+ freed_pages += count;
- i915_gem_object_unlock(obj);
+ i915_gem_object_unlock(obj);
+ }
+ mutex_unlock(>->ggtt->vm.mutex);
}
- mutex_unlock(&to_gt(i915)->ggtt->vm.mutex);
*(unsigned long *)ptr += freed_pages;
return NOTIFY_DONE;
--
2.41.0
Re: [Intel-gfx] [PATCH 0/8] Add DSC fractional bpp support
On Wed, Sep 13, 2023 at 11:35:58AM +0530, Mitul Golani wrote: > his patch series adds support for DSC fractional compressed bpp > for MTL+. The series starts with some fixes, followed by patches that > lay groundwork to iterate over valid compressed bpps to select the > 'best' compressed bpp with optimal link configuration (taken from > upstream series: https://patchwork.freedesktop.org/series/105200/). > > The later patches, add changes to accommodate compressed bpp with > fractional part, including changes to QP calculations. > To get the 'best' compressed bpp, we iterate over the valid compressed > bpp values, but with fractional step size 1/16, 1/8, 1/4 or 1/2 as per > sink support. > > The last 2 patches add support to depict DSC sink's fractional support, > and debugfs to enforce use of fractional bpp, while choosing an > appropriate compressed bpp. MST/DSC is at the moment broken, so I'd prefer merging this patchset only after it's fixed. This would mean merging https://lore.kernel.org/all/20230921195159.2646027-1-imre.d...@intel.com first, followed by the DSC parts from https://lore.kernel.org/all/20230914192659.757475-1-imre.d...@intel.com which would also need a rebase for this patchset. > Ankit Nautiyal (5): > drm/display/dp: Add helper function to get DSC bpp prescision > drm/i915/display: Store compressed bpp in U6.4 format > drm/i915/display: Consider fractional vdsc bpp while computing m_n > values > drm/i915/audio : Consider fractional vdsc bpp while computing tu_data > drm/i915/dp: Iterate over output bpp with fractional step size > > Swati Sharma (2): > drm/i915/dsc: Add debugfs entry to validate DSC fractional bpp > drm/i915/dsc: Allow DSC only with fractional bpp when forced from > debugfs > > Vandita Kulkarni (1): > drm/i915/dsc/mtl: Add support for fractional bpp > > drivers/gpu/drm/display/drm_dp_helper.c | 27 ++ > drivers/gpu/drm/i915/display/icl_dsi.c| 11 +-- > drivers/gpu/drm/i915/display/intel_audio.c| 17 ++-- > drivers/gpu/drm/i915/display/intel_bios.c | 6 +- > drivers/gpu/drm/i915/display/intel_cdclk.c| 6 +- > drivers/gpu/drm/i915/display/intel_display.c | 8 +- > drivers/gpu/drm/i915/display/intel_display.h | 2 +- > .../drm/i915/display/intel_display_debugfs.c | 83 +++ > .../drm/i915/display/intel_display_types.h| 4 +- > drivers/gpu/drm/i915/display/intel_dp.c | 81 +++--- > drivers/gpu/drm/i915/display/intel_dp_mst.c | 32 --- > drivers/gpu/drm/i915/display/intel_fdi.c | 2 +- > .../i915/display/intel_fractional_helper.h| 36 > .../gpu/drm/i915/display/intel_qp_tables.c| 3 - > drivers/gpu/drm/i915/display/intel_vdsc.c | 30 +-- > include/drm/display/drm_dp_helper.h | 1 + > 16 files changed, 275 insertions(+), 74 deletions(-) > create mode 100644 drivers/gpu/drm/i915/display/intel_fractional_helper.h > > -- > 2.25.1 >
[PATCH] accel/ivpu: Add Arrow Lake pci id
Enable VPU on Arrow Lake CPUs.
Reviewed-by: Krystian Pradzynski
Reviewed-by: Karol Wachowski
Signed-off-by: Stanislaw Gruszka
---
drivers/accel/ivpu/ivpu_drv.c | 1 +
drivers/accel/ivpu/ivpu_drv.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
index ba79f397c9e8..aa7314fdbc0f 100644
--- a/drivers/accel/ivpu/ivpu_drv.c
+++ b/drivers/accel/ivpu/ivpu_drv.c
@@ -634,6 +634,7 @@ static void ivpu_dev_fini(struct ivpu_device *vdev)
static struct pci_device_id ivpu_pci_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_MTL) },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_ARL) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_LNL) },
{ }
};
diff --git a/drivers/accel/ivpu/ivpu_drv.h b/drivers/accel/ivpu/ivpu_drv.h
index 9e8c075fe9ef..03b3d6532fb6 100644
--- a/drivers/accel/ivpu/ivpu_drv.h
+++ b/drivers/accel/ivpu/ivpu_drv.h
@@ -23,6 +23,7 @@
#define DRIVER_DATE "20230117"
#define PCI_DEVICE_ID_MTL 0x7d1d
+#define PCI_DEVICE_ID_ARL 0xad1d
#define PCI_DEVICE_ID_LNL 0x643e
#define IVPU_HW_37XX 37
@@ -165,6 +166,7 @@ static inline int ivpu_hw_gen(struct ivpu_device *vdev)
{
switch (ivpu_device_id(vdev)) {
case PCI_DEVICE_ID_MTL:
+ case PCI_DEVICE_ID_ARL:
return IVPU_HW_37XX;
case PCI_DEVICE_ID_LNL:
return IVPU_HW_40XX;
--
2.25.1
[PATCH v7 0/6] fdinfo memory stats
From: Tvrtko Ursulin A short series to enable fdinfo memory stats for i915. I added tracking of most classes of objects (user objects, page tables, context state, ring buffers) which contribute to client's memory footprint and am accouting their memory use along the similar lines as in Rob's msm code, just that with i915 specific code we can show a memory region breakdown and so support discrete and multi-tile GPUs properly. And also reflect that our objects can have multiple allowed backing stores. The existing helper Rob added is then used to dump the per memory region stats to fdinfo. The basic objects-per-client infrastructure can later be extended to cover all objects and so avoid needing to walk the IDR under the client's file table lock, which would further avoid distburbing the running clients by parallel fdinfo readers. Example fdinfo format: # cat /proc/1383/fdinfo/8 pos:0 flags: 0212 mnt_id: 21 ino:397 drm-driver: i915 drm-client-id: 18 drm-pdev: :00:02.0 drm-total-system: 125 MiB drm-shared-system: 16 MiB drm-active-system: 110 MiB drm-resident-system:125 MiB drm-purgeable-system: 2 MiB drm-total-stolen-system:0 drm-shared-stolen-system: 0 drm-active-stolen-system: 0 drm-resident-stolen-system: 0 drm-purgeable-stolen-system:0 drm-engine-render: 25662044495 ns drm-engine-copy:0 ns drm-engine-video: 0 ns drm-engine-video-enhance: 0 ns Example gputop output: DRM minor 0 PID SMEM SMEMRSS render copy videoNAME 1233 124M 124M |||||||| neverball 1130 59M 59M |█▌ ||||||| Xorg 1207 12M 12M |||||||| xfwm4 Or with Wayland: DRM minor 0 PID MEM RSSrendercopy videovideo-enhance NAME 2093 191M 191M |▊ || || || | gnome-shell DRM minor 128 PID MEM RSSrendercopy videovideo-enhance NAME 2551 71M 71M |██▉|| || || | neverball 2553 50M 50M | || || || | Xwayland Example intel_gpu_top output, aggregated mode: intel-gpu-top: Intel Dg1 (Gen12) @ /dev/dri/card1 - 21/ 577 MHz; 71% RC6 8 irqs/s ENGINES BUSY MI_SEMA MI_WAIT Render/3D2.80% |▉ | 0% 0% Blitter0.01% |▏ | 0% 0% Video0.00% | | 0% 0% VideoEnhance0.00% | | 0% 0% PID MEM RSS Render/3D BlitterVideoNAME 50783 109M 107M |▎ ||||||| neverball Region breakdown mode (needs more width for best experience): intel-gpu-top: Intel Dg1 (Gen12) @ /dev/dri/card1 - 18/ 555 MHz; 65% RC6 8 irqs/s ENGINES BUSY MI_SEMA MI_WAIT Render/3D2.52% |▉ | 0% 0% Blitter0.00% | | 0% 0% Video0.00% | | 0% 0% VideoEnhance0.00% | | 0% 0% PID RAM RSS VRAM VRSS Video NAME 50783 34M 32M 75M 75M |▏ || || || | neverball v2: * Now actually per client. v3: * Track imported dma-buf objects. v4: * Rely on DRM GEM handles for tracking user objects. * Fix internal object accounting (no placements). v5: * Fixed brain fart of overwriting the loop cursor. * Fixed object destruction racing with fdinfo reads. * Take reference to GEM context while using it. v6: * Rebase, cover letter update. v7: * New patch in series for making region names consistent and stable. Test-with: 20230922134437.234888-1-tvrtko.ursu...@linux.intel.com Tvrtko Ursulin (6): drm/i915: Add ability for tracking buffer objects per client drm/i915: Record which client owns a VM drm/i915: Track page table backing store usage drm/i915: Account ring buffer and context state storage drm/i915: Add stable memory region names drm/i915: Implement fdinfo memory stats printing drivers/gpu/drm/i915/gem/i915_gem_context.c | 11 +- .../gpu/drm/i915/gem/i915_gem_context_types.h | 3 + drivers/gpu/drm/i915/gem/i915_gem_object.c| 13 ++- .../gpu/drm/i915/gem/i915_gem_object_types.h | 12 ++ .../gpu/drm/i915/gem/selftests/mock_context.c | 4 +- drivers/gpu/drm/i915/gt/intel_context.c | 14 +++ drivers/gpu/drm/i915/gt/intel_gtt.c | 6 + drivers/gpu/drm/i915/gt/intel_gtt.h | 1 + drivers/gpu/drm/i915/i915_drm_client.c| 110 ++ drivers/gpu/drm/i915/i915_drm_client.h
[PATCH 4/6] drm/i915: Account ring buffer and context state storage
From: Tvrtko Ursulin
Account ring buffers and logical context space against the owning client
memory usage stats.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamsetty
---
drivers/gpu/drm/i915/gt/intel_context.c | 14 ++
drivers/gpu/drm/i915/i915_drm_client.c | 10 ++
drivers/gpu/drm/i915/i915_drm_client.h | 9 +
3 files changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index a53b26178f0a..a2f1245741bb 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -6,6 +6,7 @@
#include "gem/i915_gem_context.h"
#include "gem/i915_gem_pm.h"
+#include "i915_drm_client.h"
#include "i915_drv.h"
#include "i915_trace.h"
@@ -50,6 +51,7 @@ intel_context_create(struct intel_engine_cs *engine)
int intel_context_alloc_state(struct intel_context *ce)
{
+ struct i915_gem_context *ctx;
int err = 0;
if (mutex_lock_interruptible(&ce->pin_mutex))
@@ -66,6 +68,18 @@ int intel_context_alloc_state(struct intel_context *ce)
goto unlock;
set_bit(CONTEXT_ALLOC_BIT, &ce->flags);
+
+ rcu_read_lock();
+ ctx = rcu_dereference(ce->gem_context);
+ if (ctx && !kref_get_unless_zero(&ctx->ref))
+ ctx = NULL;
+ rcu_read_unlock();
+ if (ctx) {
+ if (ctx->client)
+ i915_drm_client_add_context_objects(ctx->client,
+ ce);
+ i915_gem_context_put(ctx);
+ }
}
unlock:
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index 2e5e69edc0f9..a61356012df8 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -144,4 +144,14 @@ bool i915_drm_client_remove_object(struct
drm_i915_gem_object *obj)
return true;
}
+
+void i915_drm_client_add_context_objects(struct i915_drm_client *client,
+struct intel_context *ce)
+{
+ if (ce->state)
+ i915_drm_client_add_object(client, ce->state->obj);
+
+ if (ce->ring != ce->engine->legacy.ring && ce->ring->vma)
+ i915_drm_client_add_object(client, ce->ring->vma->obj);
+}
#endif
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
b/drivers/gpu/drm/i915/i915_drm_client.h
index 5f58fdf7dcb8..69cedfcd3d69 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -14,6 +14,7 @@
#include "i915_file_private.h"
#include "gem/i915_gem_object_types.h"
+#include "gt/intel_context_types.h"
#define I915_LAST_UABI_ENGINE_CLASS I915_ENGINE_CLASS_COMPUTE
@@ -70,6 +71,8 @@ void i915_drm_client_fdinfo(struct drm_printer *p, struct
drm_file *file);
void i915_drm_client_add_object(struct i915_drm_client *client,
struct drm_i915_gem_object *obj);
bool i915_drm_client_remove_object(struct drm_i915_gem_object *obj);
+void i915_drm_client_add_context_objects(struct i915_drm_client *client,
+struct intel_context *ce);
#else
static inline void i915_drm_client_add_object(struct i915_drm_client *client,
struct drm_i915_gem_object *obj)
@@ -79,6 +82,12 @@ static inline void i915_drm_client_add_object(struct
i915_drm_client *client,
static inline bool i915_drm_client_remove_object(struct drm_i915_gem_object
*obj)
{
}
+
+static inline void
+i915_drm_client_add_context_objects(struct i915_drm_client *client,
+ struct intel_context *ce)
+{
+}
#endif
#endif /* !__I915_DRM_CLIENT_H__ */
--
2.39.2
[PATCH 1/6] drm/i915: Add ability for tracking buffer objects per client
From: Tvrtko Ursulin
In order to show per client memory usage lets add some infrastructure
which enables tracking buffer objects owned by clients.
We add a per client list protected by a new per client lock and to support
delayed destruction (post client exit) we make tracked objects hold
references to the owning client.
Also, object memory region teardown is moved to the existing RCU free
callback to allow safe dereference from the fdinfo RCU read section.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamsetty
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 13 +--
.../gpu/drm/i915/gem/i915_gem_object_types.h | 12 +++
drivers/gpu/drm/i915/i915_drm_client.c| 36 +++
drivers/gpu/drm/i915/i915_drm_client.h| 32 +
4 files changed, 90 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index c26d87555825..25eeeb863209 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -106,6 +106,10 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
INIT_LIST_HEAD(&obj->mm.link);
+#ifdef CONFIG_PROC_FS
+ INIT_LIST_HEAD(&obj->client_link);
+#endif
+
INIT_LIST_HEAD(&obj->lut_list);
spin_lock_init(&obj->lut_lock);
@@ -293,6 +297,10 @@ void __i915_gem_free_object_rcu(struct rcu_head *head)
container_of(head, typeof(*obj), rcu);
struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ /* We need to keep this alive for RCU read access from fdinfo. */
+ if (obj->mm.n_placements > 1)
+ kfree(obj->mm.placements);
+
i915_gem_object_free(obj);
GEM_BUG_ON(!atomic_read(&i915->mm.free_count));
@@ -389,9 +397,6 @@ void __i915_gem_free_object(struct drm_i915_gem_object *obj)
if (obj->ops->release)
obj->ops->release(obj);
- if (obj->mm.n_placements > 1)
- kfree(obj->mm.placements);
-
if (obj->shares_resv_from)
i915_vm_resv_put(obj->shares_resv_from);
@@ -442,6 +447,8 @@ static void i915_gem_free_object(struct drm_gem_object
*gem_obj)
GEM_BUG_ON(i915_gem_object_is_framebuffer(obj));
+ i915_drm_client_remove_object(obj);
+
/*
* Before we free the object, make sure any pure RCU-only
* read-side critical sections are complete, e.g.
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 2292404007c8..0c5cdab278b6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -302,6 +302,18 @@ struct drm_i915_gem_object {
*/
struct i915_address_space *shares_resv_from;
+#ifdef CONFIG_PROC_FS
+ /**
+* @client: @i915_drm_client which created the object
+*/
+ struct i915_drm_client *client;
+
+ /**
+* @client_link: Link into @i915_drm_client.objects_list
+*/
+ struct list_head client_link;
+#endif
+
union {
struct rcu_head rcu;
struct llist_node freed;
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index 2a44b3876cb5..2e5e69edc0f9 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -28,6 +28,10 @@ struct i915_drm_client *i915_drm_client_alloc(void)
kref_init(&client->kref);
spin_lock_init(&client->ctx_lock);
INIT_LIST_HEAD(&client->ctx_list);
+#ifdef CONFIG_PROC_FS
+ spin_lock_init(&client->objects_lock);
+ INIT_LIST_HEAD(&client->objects_list);
+#endif
return client;
}
@@ -108,4 +112,36 @@ void i915_drm_client_fdinfo(struct drm_printer *p, struct
drm_file *file)
for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++)
show_client_class(p, i915, file_priv->client, i);
}
+
+void i915_drm_client_add_object(struct i915_drm_client *client,
+ struct drm_i915_gem_object *obj)
+{
+ unsigned long flags;
+
+ GEM_WARN_ON(obj->client);
+ GEM_WARN_ON(!list_empty(&obj->client_link));
+
+ spin_lock_irqsave(&client->objects_lock, flags);
+ obj->client = i915_drm_client_get(client);
+ list_add_tail_rcu(&obj->client_link, &client->objects_list);
+ spin_unlock_irqrestore(&client->objects_lock, flags);
+}
+
+bool i915_drm_client_remove_object(struct drm_i915_gem_object *obj)
+{
+ struct i915_drm_client *client = fetch_and_zero(&obj->client);
+ unsigned long flags;
+
+ /* Object may not be associated with a client. */
+ if (!client)
+ return false;
+
+ spin_lock_irqsave(&client->objects_lock, flags);
+ list_del_rcu(&obj->client_link);
+ spin_unlock_irqrestore(&client->objects_lock, flags);
+
+ i915_drm_clien
[PATCH 3/6] drm/i915: Track page table backing store usage
From: Tvrtko Ursulin
Account page table backing store against the owning client memory usage
stats.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamsetty
---
drivers/gpu/drm/i915/gt/intel_gtt.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 13944a14ea2d..c3f2b379 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -58,6 +58,9 @@ struct drm_i915_gem_object *alloc_pt_lmem(struct
i915_address_space *vm, int sz)
if (!IS_ERR(obj)) {
obj->base.resv = i915_vm_resv_get(vm);
obj->shares_resv_from = vm;
+
+ if (vm->fpriv)
+ i915_drm_client_add_object(vm->fpriv->client, obj);
}
return obj;
@@ -79,6 +82,9 @@ struct drm_i915_gem_object *alloc_pt_dma(struct
i915_address_space *vm, int sz)
if (!IS_ERR(obj)) {
obj->base.resv = i915_vm_resv_get(vm);
obj->shares_resv_from = vm;
+
+ if (vm->fpriv)
+ i915_drm_client_add_object(vm->fpriv->client, obj);
}
return obj;
--
2.39.2
[PATCH 5/6] drm/i915: Add stable memory region names
From: Tvrtko Ursulin
At the moment memory region names are a bit too varied and too
inconsistent to be used for ABI purposes, like for upcoming fdinfo
memory stats.
System memory can be either system or system-ttm. Local memory has the
instance number appended, others do not. Not only incosistent but thi
kind of implementation detail is uninteresting for intended users of
fdinfo memory stats.
Add a stable name always formed as $type$instance. Could have chosen a
different stable scheme, but I think any consistent and stable scheme
should do just fine.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_memory_region.c | 19 +++
drivers/gpu/drm/i915/intel_memory_region.h | 1 +
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_memory_region.c
b/drivers/gpu/drm/i915/intel_memory_region.c
index 3d1fdea9811d..60a03340bbd4 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/intel_memory_region.c
@@ -216,6 +216,22 @@ static int intel_memory_region_memtest(struct
intel_memory_region *mem,
return err;
}
+static const char *region_type_str(u16 type)
+{
+ switch (type) {
+ case INTEL_MEMORY_SYSTEM:
+ return "system";
+ case INTEL_MEMORY_LOCAL:
+ return "local";
+ case INTEL_MEMORY_STOLEN_LOCAL:
+ return "stolen-local";
+ case INTEL_MEMORY_STOLEN_SYSTEM:
+ return "stolen-system";
+ default:
+ return "unknown";
+ }
+}
+
struct intel_memory_region *
intel_memory_region_create(struct drm_i915_private *i915,
resource_size_t start,
@@ -244,6 +260,9 @@ intel_memory_region_create(struct drm_i915_private *i915,
mem->type = type;
mem->instance = instance;
+ snprintf(mem->uabi_name, sizeof(mem->uabi_name), "%s%u",
+region_type_str(type), instance);
+
mutex_init(&mem->objects.lock);
INIT_LIST_HEAD(&mem->objects.list);
diff --git a/drivers/gpu/drm/i915/intel_memory_region.h
b/drivers/gpu/drm/i915/intel_memory_region.h
index 2953ed5c3248..9ba36454e51b 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.h
+++ b/drivers/gpu/drm/i915/intel_memory_region.h
@@ -80,6 +80,7 @@ struct intel_memory_region {
u16 instance;
enum intel_region_id id;
char name[16];
+ char uabi_name[16];
bool private; /* not for userspace */
struct {
--
2.39.2
[PATCH 2/6] drm/i915: Record which client owns a VM
From: Tvrtko Ursulin
To enable accounting of indirect client memory usage (such as page tables)
in the following patch, lets start recording the creator of each PPGTT.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamsetty
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 11 ---
drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 3 +++
drivers/gpu/drm/i915/gem/selftests/mock_context.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_gtt.h | 1 +
4 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 9a9ff84c90d7..35cf6608180e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -279,7 +279,8 @@ static int proto_context_set_protected(struct
drm_i915_private *i915,
}
static struct i915_gem_proto_context *
-proto_context_create(struct drm_i915_private *i915, unsigned int flags)
+proto_context_create(struct drm_i915_file_private *fpriv,
+struct drm_i915_private *i915, unsigned int flags)
{
struct i915_gem_proto_context *pc, *err;
@@ -287,6 +288,7 @@ proto_context_create(struct drm_i915_private *i915,
unsigned int flags)
if (!pc)
return ERR_PTR(-ENOMEM);
+ pc->fpriv = fpriv;
pc->num_user_engines = -1;
pc->user_engines = NULL;
pc->user_flags = BIT(UCONTEXT_BANNABLE) |
@@ -1621,6 +1623,7 @@ i915_gem_create_context(struct drm_i915_private *i915,
err = PTR_ERR(ppgtt);
goto err_ctx;
}
+ ppgtt->vm.fpriv = pc->fpriv;
vm = &ppgtt->vm;
}
if (vm)
@@ -1740,7 +1743,7 @@ int i915_gem_context_open(struct drm_i915_private *i915,
/* 0 reserved for invalid/unassigned ppgtt */
xa_init_flags(&file_priv->vm_xa, XA_FLAGS_ALLOC1);
- pc = proto_context_create(i915, 0);
+ pc = proto_context_create(file_priv, i915, 0);
if (IS_ERR(pc)) {
err = PTR_ERR(pc);
goto err;
@@ -1822,6 +1825,7 @@ int i915_gem_vm_create_ioctl(struct drm_device *dev, void
*data,
GEM_BUG_ON(id == 0); /* reserved for invalid/unassigned ppgtt */
args->vm_id = id;
+ ppgtt->vm.fpriv = file_priv;
return 0;
err_put:
@@ -2284,7 +2288,8 @@ int i915_gem_context_create_ioctl(struct drm_device *dev,
void *data,
return -EIO;
}
- ext_data.pc = proto_context_create(i915, args->flags);
+ ext_data.pc = proto_context_create(file->driver_priv, i915,
+ args->flags);
if (IS_ERR(ext_data.pc))
return PTR_ERR(ext_data.pc);
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 cb78214a7dcd..c573c067779f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -188,6 +188,9 @@ struct i915_gem_proto_engine {
* CONTEXT_CREATE_SET_PARAM during GEM_CONTEXT_CREATE.
*/
struct i915_gem_proto_context {
+ /** @fpriv: Client which creates the context */
+ struct drm_i915_file_private *fpriv;
+
/** @vm: See &i915_gem_context.vm */
struct i915_address_space *vm;
diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_context.c
b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
index 8ac6726ec16b..125584ada282 100644
--- a/drivers/gpu/drm/i915/gem/selftests/mock_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/mock_context.c
@@ -83,7 +83,7 @@ live_context(struct drm_i915_private *i915, struct file *file)
int err;
u32 id;
- pc = proto_context_create(i915, 0);
+ pc = proto_context_create(fpriv, i915, 0);
if (IS_ERR(pc))
return ERR_CAST(pc);
@@ -152,7 +152,7 @@ kernel_context(struct drm_i915_private *i915,
struct i915_gem_context *ctx;
struct i915_gem_proto_context *pc;
- pc = proto_context_create(i915, 0);
+ pc = proto_context_create(NULL, i915, 0);
if (IS_ERR(pc))
return ERR_CAST(pc);
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index 346ec8ec2edd..8cf62f5134a9 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -248,6 +248,7 @@ struct i915_address_space {
struct drm_mm mm;
struct intel_gt *gt;
struct drm_i915_private *i915;
+ struct drm_i915_file_private *fpriv;
struct device *dma;
u64 total; /* size addr space maps (ex. 2GB for ggtt) */
u64 reserved; /* size addr space reserved */
--
2.39.2
[PATCH 6/6] drm/i915: Implement fdinfo memory stats printing
From: Tvrtko Ursulin
Use the newly added drm_print_memory_stats helper to show memory
utilisation of our objects in drm/driver specific fdinfo output.
To collect the stats we walk the per memory regions object lists
and accumulate object size into the respective drm_memory_stats
categories.
v2:
* Only account against the active region.
* Use DMA_RESV_USAGE_BOOKKEEP when testing for active. (Tejas)
v3:
* Update commit text. (Aravind)
* Update to use memory regions uabi names.
Signed-off-by: Tvrtko Ursulin
Cc: Aravind Iddamsetty
Cc: Rob Clark
Cc: Andi Shyti
Cc: Tejas Upadhyay
Reviewed-by: Andi Shyti # v1
Reviewed-by: Aravind Iddamsetty # v2
---
drivers/gpu/drm/i915/i915_drm_client.c | 64 ++
1 file changed, 64 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index a61356012df8..7efffdaa508d 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -45,6 +45,68 @@ void __i915_drm_client_free(struct kref *kref)
}
#ifdef CONFIG_PROC_FS
+static void
+obj_meminfo(struct drm_i915_gem_object *obj,
+ struct drm_memory_stats stats[INTEL_REGION_UNKNOWN])
+{
+ const enum intel_region_id id = obj->mm.region ?
+ obj->mm.region->id : INTEL_REGION_SMEM;
+ const u64 sz = obj->base.size;
+
+ if (obj->base.handle_count > 1)
+ stats[id].shared += sz;
+ else
+ stats[id].private += sz;
+
+ if (i915_gem_object_has_pages(obj)) {
+ stats[id].resident += sz;
+
+ if (!dma_resv_test_signaled(obj->base.resv,
+ DMA_RESV_USAGE_BOOKKEEP))
+ stats[id].active += sz;
+ else if (i915_gem_object_is_shrinkable(obj) &&
+obj->mm.madv == I915_MADV_DONTNEED)
+ stats[id].purgeable += sz;
+ }
+}
+
+static void show_meminfo(struct drm_printer *p, struct drm_file *file)
+{
+ struct drm_memory_stats stats[INTEL_REGION_UNKNOWN] = {};
+ struct drm_i915_file_private *fpriv = file->driver_priv;
+ struct i915_drm_client *client = fpriv->client;
+ struct drm_i915_private *i915 = fpriv->i915;
+ struct drm_i915_gem_object *obj;
+ struct intel_memory_region *mr;
+ struct list_head *pos;
+ unsigned int id;
+
+ /* Public objects. */
+ spin_lock(&file->table_lock);
+ idr_for_each_entry(&file->object_idr, obj, id)
+ obj_meminfo(obj, stats);
+ spin_unlock(&file->table_lock);
+
+ /* Internal objects. */
+ rcu_read_lock();
+ list_for_each_rcu(pos, &client->objects_list) {
+ obj = i915_gem_object_get_rcu(list_entry(pos, typeof(*obj),
+client_link));
+ if (!obj)
+ continue;
+ obj_meminfo(obj, stats);
+ i915_gem_object_put(obj);
+ }
+ rcu_read_unlock();
+
+ for_each_memory_region(mr, i915, id)
+ drm_print_memory_stats(p,
+ &stats[id],
+ DRM_GEM_OBJECT_RESIDENT |
+ DRM_GEM_OBJECT_PURGEABLE,
+ mr->uabi_name);
+}
+
static const char * const uabi_class_names[] = {
[I915_ENGINE_CLASS_RENDER] = "render",
[I915_ENGINE_CLASS_COPY] = "copy",
@@ -106,6 +168,8 @@ void i915_drm_client_fdinfo(struct drm_printer *p, struct
drm_file *file)
* **
*/
+ show_meminfo(p, file);
+
if (GRAPHICS_VER(i915) < 8)
return;
--
2.39.2
Re: [PATCH v6 2/6] drm/panfrost: Add fdinfo support GPU load metrics
On 22/09/2023 11:57, Adrián Larumbe wrote:
On 20.09.2023 16:40, Tvrtko Ursulin wrote:
On 20/09/2023 00:34, Adrián Larumbe wrote:
The drm-stats fdinfo tags made available to user space are drm-engine,
drm-cycles, drm-max-freq and drm-curfreq, one per job slot.
This deviates from standard practice in other DRM drivers, where a single
set of key:value pairs is provided for the whole render engine. However,
Panfrost has separate queues for fragment and vertex/tiler jobs, so a
decision was made to calculate bus cycles and workload times separately.
Maximum operating frequency is calculated at devfreq initialisation time.
Current frequency is made available to user space because nvtop uses it
when performing engine usage calculations.
It is important to bear in mind that both GPU cycle and kernel time numbers
provided are at best rough estimations, and always reported in excess from
the actual figure because of two reasons:
- Excess time because of the delay between the end of a job processing,
the subsequent job IRQ and the actual time of the sample.
- Time spent in the engine queue waiting for the GPU to pick up the next
job.
To avoid race conditions during enablement/disabling, a reference counting
mechanism was introduced, and a job flag that tells us whether a given job
increased the refcount. This is necessary, because user space can toggle
cycle counting through a debugfs file, and a given job might have been in
flight by the time cycle counting was disabled.
The main goal of the debugfs cycle counter knob is letting tools like nvtop
or IGT's gputop switch it at any time, to avoid power waste in case no
engine usage measuring is necessary.
Signed-off-by: Adrián Larumbe
Reviewed-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/Makefile | 2 +
drivers/gpu/drm/panfrost/panfrost_debugfs.c | 20
drivers/gpu/drm/panfrost/panfrost_debugfs.h | 13 +
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 8 +++
drivers/gpu/drm/panfrost/panfrost_devfreq.h | 3 ++
drivers/gpu/drm/panfrost/panfrost_device.c | 2 +
drivers/gpu/drm/panfrost/panfrost_device.h | 13 +
drivers/gpu/drm/panfrost/panfrost_drv.c | 57 -
drivers/gpu/drm/panfrost/panfrost_gpu.c | 41 +++
drivers/gpu/drm/panfrost/panfrost_gpu.h | 4 ++
drivers/gpu/drm/panfrost/panfrost_job.c | 24 +
drivers/gpu/drm/panfrost/panfrost_job.h | 5 ++
12 files changed, 191 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/panfrost/panfrost_debugfs.c
create mode 100644 drivers/gpu/drm/panfrost/panfrost_debugfs.h
diff --git a/drivers/gpu/drm/panfrost/Makefile
b/drivers/gpu/drm/panfrost/Makefile
index 7da2b3f02ed9..2c01c1e7523e 100644
--- a/drivers/gpu/drm/panfrost/Makefile
+++ b/drivers/gpu/drm/panfrost/Makefile
@@ -12,4 +12,6 @@ panfrost-y := \
panfrost_perfcnt.o \
panfrost_dump.o
+panfrost-$(CONFIG_DEBUG_FS) += panfrost_debugfs.o
+
obj-$(CONFIG_DRM_PANFROST) += panfrost.o
diff --git a/drivers/gpu/drm/panfrost/panfrost_debugfs.c
b/drivers/gpu/drm/panfrost/panfrost_debugfs.c
new file mode 100644
index ..cc14eccba206
--- /dev/null
+++ b/drivers/gpu/drm/panfrost/panfrost_debugfs.c
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright 2023 Collabora ltd. */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "panfrost_device.h"
+#include "panfrost_gpu.h"
+#include "panfrost_debugfs.h"
+
+void panfrost_debugfs_init(struct drm_minor *minor)
+{
+ struct drm_device *dev = minor->dev;
+ struct panfrost_device *pfdev =
platform_get_drvdata(to_platform_device(dev->dev));
+
+ debugfs_create_atomic_t("profile", 0600, minor->debugfs_root,
&pfdev->profile_mode);
+}
diff --git a/drivers/gpu/drm/panfrost/panfrost_debugfs.h
b/drivers/gpu/drm/panfrost/panfrost_debugfs.h
new file mode 100644
index ..db1c158bcf2f
--- /dev/null
+++ b/drivers/gpu/drm/panfrost/panfrost_debugfs.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright 2023 Collabora ltd.
+ */
+
+#ifndef PANFROST_DEBUGFS_H
+#define PANFROST_DEBUGFS_H
+
+#ifdef CONFIG_DEBUG_FS
+void panfrost_debugfs_init(struct drm_minor *minor);
+#endif
+
+#endif /* PANFROST_DEBUGFS_H */
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 58dfb15a8757..28caffc689e2 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -58,6 +58,7 @@ static int panfrost_devfreq_get_dev_status(struct device *dev,
spin_lock_irqsave(&pfdevfreq->lock, irqflags);
panfrost_devfreq_update_utilization(pfdevfreq);
+ pfdevfreq->current_frequency = status->current_frequency;
status->total_time = ktime_to_ns(ktime_add(pfdevfreq->busy_time,
pfdevfreq->idle_time));
@@ -117,6 +118,7
Re: [PATCH v4 0/7] drm: ci: fixes
On 14/09/2023 05:54, Vignesh Raman wrote: The patch series contains improvements, enabling new ci jobs which enables testing for Mediatek MT8173, Qualcomm APQ 8016 and VirtIO GPU, fixing issues with the ci jobs and updating the expectation files. This series is intended for drm branch drm-next. v2: - Use fdtoverlay command to merge overlay dtbo with the base dtb instead of modifying the kernel sources - Reworded the commit message for enabling jobs - Added a new patch in the series to use scripts/config to enable/disable configs v3: - New patch in the series to add device tree overlay in arch/arm64/boot/dts/qcom - drm-ci scripts to use device tree overlay from arch/arm64/boot/dts/qcom and compile base device tree with overlay support - New patch in the series to enable CONFIG_REGULATOR_DA9211 in defconfig - Remove CONFIG_RTC_DRV_MT6397=y as it is already enabled in defconfig v4: - Drop 'enable CONFIG_REGULATOR_DA9211 in defconfig' patch as it is sent upstream as a seperate patch - Use apq8016-sbc-usb-host.dtb which allows the USB controllers to work in host mode. This patch depends on https://lore.kernel.org/lkml/20230911161518.650726-1-vignesh.ra...@collabora.com/ Jfyi, this patch got applied, see https://lore.kernel.org/lkml/169539077994.4014786.12440074307606036817.b4...@kernel.org/ Regards, Helen Vignesh Raman (7): drm: ci: igt_runner: Remove todo drm: ci: Force db410c to host mode drm: ci: virtio: Update ci variables drm: ci: Enable regulator drm: ci: Update xfails drm: ci: Enable new jobs drm: ci: Use scripts/config to enable/disable configs drivers/gpu/drm/ci/arm64.config | 1 + drivers/gpu/drm/ci/build.sh | 16 drivers/gpu/drm/ci/igt_runner.sh | 1 - drivers/gpu/drm/ci/test.yml | 16 +--- .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt| 1 - drivers/gpu/drm/ci/xfails/i915-cml-fails.txt | 1 - drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt| 2 ++ drivers/gpu/drm/ci/xfails/i915-glk-flakes.txt| 1 + .../gpu/drm/ci/xfails/mediatek-mt8173-fails.txt | 2 -- .../gpu/drm/ci/xfails/mediatek-mt8173-flakes.txt | 16 drivers/gpu/drm/ci/xfails/msm-apq8016-flakes.txt | 2 ++ .../gpu/drm/ci/xfails/rockchip-rk3288-flakes.txt | 1 + .../gpu/drm/ci/xfails/rockchip-rk3399-fails.txt | 4 ++-- .../gpu/drm/ci/xfails/rockchip-rk3399-flakes.txt | 3 +++ 14 files changed, 41 insertions(+), 26 deletions(-)
Re: [PATCH v6 6/6] drm/drm-file: Show finer-grained BO sizes in drm_show_memory_stats
On 22/09/2023 12:03, Adrián Larumbe wrote:
On 21.09.2023 11:14, Tvrtko Ursulin wrote:
On 20/09/2023 16:32, Tvrtko Ursulin wrote:
On 20/09/2023 00:34, Adrián Larumbe wrote:
The current implementation will try to pick the highest available size
display unit as soon as the BO size exceeds that of the previous
multiplier. That can lead to loss of precision in contexts of low memory
usage.
The new selection criteria try to preserve precision, whilst also
increasing the display unit selection threshold to render more accurate
values.
Signed-off-by: Adrián Larumbe
Reviewed-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/drm_file.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 762965e3d503..34cfa128ffe5 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -872,6 +872,8 @@ void drm_send_event(struct drm_device *dev, struct
drm_pending_event *e)
}
EXPORT_SYMBOL(drm_send_event);
+#define UPPER_UNIT_THRESHOLD 100
+
static void print_size(struct drm_printer *p, const char *stat,
const char *region, u64 sz)
{
@@ -879,7 +881,8 @@ static void print_size(struct drm_printer *p,
const char *stat,
unsigned u;
for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
- if (sz < SZ_1K)
+ if ((sz & (SZ_1K - 1)) &&
IS_ALIGNED worth it at all?
+ sz < UPPER_UNIT_THRESHOLD * SZ_1K)
break;
Excuse me for a late comment (I was away). I did not get what what is
special about a ~10% threshold? Sounds to me just going with the lower
unit, when size is not aligned to the higher one, would be better than
sometimes precision-sometimes-not.
FWIW both current and the threshold option make testing the feature very
annoying.
How so?
I have to build in the knowledge of implementation details of
print_size() into my IGT in order to use the right size BOs, so test is
able to verify stats move as expected. It just feels wrong.
So I'd really propose we simply use smaller unit when unaligned.
Like I said in the previous reply, for drm files whose overall BO size sum is
enormous
but not a multiple of a MiB, this would render huge number representations in
KiB.
I don't find this particularly comfortable to read, and then this extra
precision
would mean nothing to nvtop or gputop, which would have to scale the size to
their
available screen dimensions when plotting them.
I don't think numbers in KiB are so huge.
And I don't think people will end up reading them manually a lot anyway,
since you have to hunt the pid, and fd, etc.. It is much more realistic
that some tool like gputop will be used.
And I don't think consistency of units across drivers or whatever
matters. Even better to keep userspace parser on their toes and make
then follow drm-usage-stats.rst and not any implementations, at some
point in time.
Regards,
Tvrtko
[PATCH v6 03/16] dt-bindings: media: mediatek: mdp3: include common properties
To minimize duplication and standardize the document style, include the common properties for MT8183 RDMA. Signed-off-by: Moudy Ho --- .../bindings/media/mediatek,mdp3-rdma.yaml| 43 ++- 1 file changed, 4 insertions(+), 39 deletions(-) diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml index 3e128733ef53..0539badc9821 100644 --- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/media/mediatek,mdp3-rdma.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: MediaTek Read Direct Memory Access +title: MediaTek MT8183 Read Direct Memory Access maintainers: - Matthias Brugger @@ -18,62 +18,27 @@ description: | Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml for details. +allOf: + - $ref: mediatek,mdp3-rdma-common.yaml# + properties: compatible: items: - const: mediatek,mt8183-mdp3-rdma - reg: -maxItems: 1 - - mediatek,gce-client-reg: -$ref: /schemas/types.yaml#/definitions/phandle-array -items: - items: -- description: phandle of GCE -- description: GCE subsys id -- description: register offset -- description: register size -description: The register of client driver can be configured by gce with - 4 arguments defined in this property. Each GCE subsys id is mapping to - a client defined in the header include/dt-bindings/gce/-gce.h. - - mediatek,gce-events: -description: - The event id which is mapping to the specific hardware event signal - to gce. The event id is defined in the gce header - include/dt-bindings/gce/-gce.h of each chips. -$ref: /schemas/types.yaml#/definitions/uint32-array - - power-domains: -maxItems: 1 - clocks: items: - description: RDMA clock - description: RSZ clock - iommus: -maxItems: 1 - mboxes: items: - description: used for 1st data pipe from RDMA - description: used for 2nd data pipe from RDMA - '#dma-cells': -const: 1 - required: - compatible - - reg - - mediatek,gce-client-reg - - mediatek,gce-events - - power-domains - - clocks - - iommus - mboxes - - '#dma-cells' additionalProperties: false -- 2.18.0
[PATCH v6 00/16] introduce more MDP3 components in MT8195
Changes since v5:
- Rebase on v6.6-rc2.
- Dependent dtsi files:
https://patchwork.kernel.org/project/linux-mediatek/list/?series=786511
- Depends on:
Message ID = 20230911074233.31556-5-shawn.s...@mediatek.com
- Split out common propertis for RDMA.
- Split each component into independent patches.
Changes since v4:
- Rebase on v6.6-rc1
- Organize identical hardware components into their respective files.
Hi,
The purpose of this patch is to separate the MDP3-related bindings from
the original mailing list mentioned below:
https://lore.kernel.org/all/20230208092209.19472-1-moudy...@mediatek.com/
Those binding files describe additional components that
are present in the mt8195.
Moudy Ho (16):
dt-bindings: media: mediatek: mdp3: correct RDMA and WROT node with
generic names
dt-bindings: media: mediatek: mdp3: split out general properties
dt-bindings: media: mediatek: mdp3: include common properties
dt-bindings: media: mediatek: mdp3: rename to MT8183 RDMA
dt-bindings: media: mediatek: mdp3: add support MT8195 RDMA
dt-bindings: media: mediatek: mdp3: add component FG for MT8195
dt-bindings: media: mediatek: mdp3: add component HDR for MT8195
dt-bindings: media: mediatek: mdp3: add component STITCH for MT8195
dt-bindings: media: mediatek: mdp3: add component STITCH for MT8195
dt-bindings: media: mediatek: mdp3: add component TDSHP for MT8195
dt-bindings: display: mediatek: aal: add compatible for MT8195
dt-bindings: display: mediatek: color: add compatible for MT8195
dt-bindings: display: mediatek: merge: add compatible for MT8195
dt-bindings: display: mediatek: ovl: add compatible for MT8195
dt-bindings: display: mediatek: split: add compatible for MT8195
dt-bindings: display: mediatek: padding: add compatible for MT8195
.../display/mediatek/mediatek,aal.yaml| 1 +
.../display/mediatek/mediatek,color.yaml | 1 +
.../display/mediatek/mediatek,merge.yaml | 1 +
.../display/mediatek/mediatek,ovl.yaml| 1 +
.../display/mediatek/mediatek,padding.yaml| 4 +-
.../display/mediatek/mediatek,split.yaml | 1 +
.../bindings/media/mediatek,mdp3-fg.yaml | 61 +
.../bindings/media/mediatek,mdp3-hdr.yaml | 60 +
.../media/mediatek,mdp3-rdma-8183.yaml| 65 +++
.../media/mediatek,mdp3-rdma-8195.yaml| 64 ++
...ma.yaml => mediatek,mdp3-rdma-common.yaml} | 49 --
.../bindings/media/mediatek,mdp3-stitch.yaml | 61 +
.../bindings/media/mediatek,mdp3-tcc.yaml | 60 +
.../bindings/media/mediatek,mdp3-tdshp.yaml | 61 +
.../bindings/media/mediatek,mdp3-wrot.yaml| 23 ---
15 files changed, 467 insertions(+), 46 deletions(-)
create mode 100644
Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml
create mode 100644
Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml
create mode 100644
Documentation/devicetree/bindings/media/mediatek,mdp3-rdma-8183.yaml
create mode 100644
Documentation/devicetree/bindings/media/mediatek,mdp3-rdma-8195.yaml
rename Documentation/devicetree/bindings/media/{mediatek,mdp3-rdma.yaml =>
mediatek,mdp3-rdma-common.yaml} (57%)
create mode 100644
Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml
create mode 100644
Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml
create mode 100644
Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml
--
2.18.0
[PATCH v6 10/16] dt-bindings: media: mediatek: mdp3: add component TDSHP for MT8195
Add the fundamental hardware configuration of component TDSHP,
which is controlled by MDP3 on MT8195.
Signed-off-by: Moudy Ho
---
.../bindings/media/mediatek,mdp3-tdshp.yaml | 61 +++
1 file changed, 61 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml
b/Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml
new file mode 100644
index ..0ac904cbc2c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-tdshp.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-tdshp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Media Data Path 3 TDSHP
+
+maintainers:
+ - Matthias Brugger
+ - Moudy Ho
+
+description:
+ One of Media Data Path 3 (MDP3) components used to improve image
+ sharpness and contrast.
+
+properties:
+ compatible:
+enum:
+ - mediatek,mt8195-mdp3-tdshp
+
+ reg:
+maxItems: 1
+
+ mediatek,gce-client-reg:
+description:
+ The register of display function block to be set by gce. There are 4
arguments,
+ such as gce node, subsys id, offset and register size. The subsys id
that is
+ mapping to the register of display function blocks is defined in the gce
header
+ include/dt-bindings/gce/-gce.h of each chips.
+$ref: /schemas/types.yaml#/definitions/phandle-array
+items:
+ items:
+- description: phandle of GCE
+- description: GCE subsys id
+- description: register offset
+- description: register size
+maxItems: 1
+
+ clocks:
+minItems: 1
+
+required:
+ - compatible
+ - reg
+ - mediatek,gce-client-reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+display@14007000 {
+compatible = "mediatek,mt8195-mdp3-tdshp";
+reg = <0x14007000 0x1000>;
+mediatek,gce-client-reg = <&gce1 SUBSYS_1400 0x7000 0x1000>;
+clocks = <&vppsys0 CLK_VPP0_MDP_TDSHP>;
+};
--
2.18.0
[PATCH v6 08/16] dt-bindings: media: mediatek: mdp3: add component STITCH for MT8195
Add the fundamental hardware configuration of component STITCH,
which is controlled by MDP3 on MT8195.
Signed-off-by: Moudy Ho
---
.../bindings/media/mediatek,mdp3-stitch.yaml | 61 +++
1 file changed, 61 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml
b/Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml
new file mode 100644
index ..45a9d6ac171a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-stitch.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-stitch.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Media Data Path 3 STITCH
+
+maintainers:
+ - Matthias Brugger
+ - Moudy Ho
+
+description:
+ One of Media Data Path 3 (MDP3) components used to combine multiple video
frame
+ with overlapping fields of view to produce a segmented panorame.
+
+properties:
+ compatible:
+enum:
+ - mediatek,mt8195-mdp3-stitch
+
+ reg:
+maxItems: 1
+
+ mediatek,gce-client-reg:
+description:
+ The register of display function block to be set by gce. There are 4
arguments,
+ such as gce node, subsys id, offset and register size. The subsys id
that is
+ mapping to the register of display function blocks is defined in the gce
header
+ include/dt-bindings/gce/-gce.h of each chips.
+$ref: /schemas/types.yaml#/definitions/phandle-array
+items:
+ items:
+- description: phandle of GCE
+- description: GCE subsys id
+- description: register offset
+- description: register size
+maxItems: 1
+
+ clocks:
+minItems: 1
+
+required:
+ - compatible
+ - reg
+ - mediatek,gce-client-reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+display@14003000 {
+compatible = "mediatek,mt8195-mdp3-stitch";
+reg = <0x14003000 0x1000>;
+mediatek,gce-client-reg = <&gce1 SUBSYS_1400 0x3000 0x1000>;
+clocks = <&vppsys0 CLK_VPP0_STITCH>;
+};
--
2.18.0
[PATCH v6 11/16] dt-bindings: display: mediatek: aal: add compatible for MT8195
Add a compatible string for the AAL block in MediaTek MT8195 that is controlled by MDP3. Signed-off-by: Moudy Ho --- .../devicetree/bindings/display/mediatek/mediatek,aal.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml index 7fd42c8fdc32..b4c28e96dd55 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml @@ -24,6 +24,7 @@ properties: - enum: - mediatek,mt8173-disp-aal - mediatek,mt8183-disp-aal + - mediatek,mt8195-mdp3-aal - items: - enum: - mediatek,mt2712-disp-aal -- 2.18.0
[PATCH v6 01/16] dt-bindings: media: mediatek: mdp3: correct RDMA and WROT node with generic names
The DMA-related nodes RDMA/WROT in MDP3 should be changed to generic names.
In addition, fix improper space indent in example.
Fixes: 4ad7b39623ab ("media: dt-binding: mediatek: add bindings for MediaTek
MDP3 components")
Signed-off-by: Moudy Ho
Acked-by: Rob Herring
---
.../bindings/media/mediatek,mdp3-rdma.yaml| 29 +++
.../bindings/media/mediatek,mdp3-wrot.yaml| 23 +--
2 files changed, 31 insertions(+), 21 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
index 7032c7e15039..3e128733ef53 100644
--- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
@@ -61,6 +61,9 @@ properties:
- description: used for 1st data pipe from RDMA
- description: used for 2nd data pipe from RDMA
+ '#dma-cells':
+const: 1
+
required:
- compatible
- reg
@@ -70,6 +73,7 @@ required:
- clocks
- iommus
- mboxes
+ - '#dma-cells'
additionalProperties: false
@@ -80,16 +84,17 @@ examples:
#include
#include
-mdp3_rdma0: mdp3-rdma0@14001000 {
- compatible = "mediatek,mt8183-mdp3-rdma";
- reg = <0x14001000 0x1000>;
- mediatek,gce-client-reg = <&gce SUBSYS_1400 0x1000 0x1000>;
- mediatek,gce-events = ,
-;
- power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
- clocks = <&mmsys CLK_MM_MDP_RDMA0>,
- <&mmsys CLK_MM_MDP_RSZ1>;
- iommus = <&iommu>;
- mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST>,
- <&gce 21 CMDQ_THR_PRIO_LOWEST>;
+dma-controller@14001000 {
+compatible = "mediatek,mt8183-mdp3-rdma";
+reg = <0x14001000 0x1000>;
+mediatek,gce-client-reg = <&gce SUBSYS_1400 0x1000 0x1000>;
+mediatek,gce-events = ,
+ ;
+power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
+clocks = <&mmsys CLK_MM_MDP_RDMA0>,
+ <&mmsys CLK_MM_MDP_RSZ1>;
+iommus = <&iommu>;
+mboxes = <&gce 20 CMDQ_THR_PRIO_LOWEST>,
+ <&gce 21 CMDQ_THR_PRIO_LOWEST>;
+#dma-cells = <1>;
};
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
b/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
index 0baa77198fa2..64ea98aa0592 100644
--- a/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-wrot.yaml
@@ -50,6 +50,9 @@ properties:
iommus:
maxItems: 1
+ '#dma-cells':
+const: 1
+
required:
- compatible
- reg
@@ -58,6 +61,7 @@ required:
- power-domains
- clocks
- iommus
+ - '#dma-cells'
additionalProperties: false
@@ -68,13 +72,14 @@ examples:
#include
#include
-mdp3_wrot0: mdp3-wrot0@14005000 {
- compatible = "mediatek,mt8183-mdp3-wrot";
- reg = <0x14005000 0x1000>;
- mediatek,gce-client-reg = <&gce SUBSYS_1400 0x5000 0x1000>;
- mediatek,gce-events = ,
-;
- power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
- clocks = <&mmsys CLK_MM_MDP_WROT0>;
- iommus = <&iommu>;
+dma-controller@14005000 {
+compatible = "mediatek,mt8183-mdp3-wrot";
+reg = <0x14005000 0x1000>;
+mediatek,gce-client-reg = <&gce SUBSYS_1400 0x5000 0x1000>;
+mediatek,gce-events = ,
+ ;
+power-domains = <&spm MT8183_POWER_DOMAIN_DISP>;
+clocks = <&mmsys CLK_MM_MDP_WROT0>;
+iommus = <&iommu>;
+#dma-cells = <1>;
};
--
2.18.0
[PATCH v6 06/16] dt-bindings: media: mediatek: mdp3: add component FG for MT8195
Add the fundamental hardware configuration of component FG,
which is controlled by MDP3 on MT8195.
Signed-off-by: Moudy Ho
---
.../bindings/media/mediatek,mdp3-fg.yaml | 61 +++
1 file changed, 61 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml
b/Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml
new file mode 100644
index ..71fd449de8b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-fg.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-fg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Media Data Path 3 FG
+
+maintainers:
+ - Matthias Brugger
+ - Moudy Ho
+
+description:
+ One of Media Data Path 3 (MDP3) components used to add film grain
+ according to AV1 spec.
+
+properties:
+ compatible:
+enum:
+ - mediatek,mt8195-mdp3-fg
+
+ reg:
+maxItems: 1
+
+ mediatek,gce-client-reg:
+description:
+ The register of display function block to be set by gce. There are 4
arguments,
+ such as gce node, subsys id, offset and register size. The subsys id
that is
+ mapping to the register of display function blocks is defined in the gce
header
+ include/dt-bindings/gce/-gce.h of each chips.
+$ref: /schemas/types.yaml#/definitions/phandle-array
+items:
+ items:
+- description: phandle of GCE
+- description: GCE subsys id
+- description: register offset
+- description: register size
+maxItems: 1
+
+ clocks:
+minItems: 1
+
+required:
+ - compatible
+ - reg
+ - mediatek,gce-client-reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+display@14002000 {
+compatible = "mediatek,mt8195-mdp3-fg";
+reg = <0x14002000 0x1000>;
+mediatek,gce-client-reg = <&gce1 SUBSYS_1400 0x2000 0x1000>;
+clocks = <&vppsys0 CLK_VPP0_MDP_FG>;
+};
--
2.18.0
RE: [PATCH v1] drm/dp/mst: fix missing modeset unlock for MST port detect
Gentle Reminder. Please review the commit. -Original Message- From: Ramya SR (QUIC) Sent: Friday, September 15, 2023 10:25 AM To: David Airlie ; Daniel Vetter ; Lyude Paul ; Wayne Lin ; Jani Nikula ; Imre Deak ; Alex Deucher ; Jeff Layton ; dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org Cc: Ramya SR (QUIC) Subject: [PATCH v1] drm/dp/mst: fix missing modeset unlock for MST port detect Modeset mutex unlock is missing in drm_dp_mst_detect_port function. This will lead to deadlock if calling the function multiple times in an atomic operation, for example, getting imultiple MST ports status for a DP MST bonding scenario. Signed-off-by: Ramya SR --- drivers/gpu/drm/display/drm_dp_mst_topology.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c b/drivers/gpu/drm/display/drm_dp_mst_topology.c index ed96cfc..d6512c4 100644 --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c @@ -4154,7 +4154,7 @@ drm_dp_mst_detect_port(struct drm_connector *connector, ret = drm_modeset_lock(&mgr->base.lock, ctx); if (ret) - goto out; + goto fail; ret = connector_status_disconnected; @@ -4181,6 +4181,8 @@ drm_dp_mst_detect_port(struct drm_connector *connector, break; } out: + drm_modeset_unlock(&mgr->base.lock); +fail: drm_dp_mst_topology_put_port(port); return ret; } -- 2.7.4
[PATCH v6 13/16] dt-bindings: display: mediatek: merge: add compatible for MT8195
Add a compatible string for the MERGE block in MediaTek MT8195 that is controlled by MDP3. Signed-off-by: Moudy Ho --- .../devicetree/bindings/display/mediatek/mediatek,merge.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml index eead5cb8636e..401498523404 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml @@ -24,6 +24,7 @@ properties: - enum: - mediatek,mt8173-disp-merge - mediatek,mt8195-disp-merge + - mediatek,mt8195-mdp3-merge - items: - const: mediatek,mt6795-disp-merge - const: mediatek,mt8173-disp-merge -- 2.18.0
[PATCH v6 12/16] dt-bindings: display: mediatek: color: add compatible for MT8195
Add a compatible string for the COLOR block in MediaTek MT8195 that is controlled by MDP3. Signed-off-by: Moudy Ho --- .../devicetree/bindings/display/mediatek/mediatek,color.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml index f21e44092043..b886ca0d89ea 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml @@ -26,6 +26,7 @@ properties: - mediatek,mt2701-disp-color - mediatek,mt8167-disp-color - mediatek,mt8173-disp-color + - mediatek,mt8195-mdp3-color - items: - enum: - mediatek,mt7623-disp-color -- 2.18.0
[PATCH v6 04/16] dt-bindings: media: mediatek: mdp3: rename to MT8183 RDMA
The file was renamed to support future scalability in response to
the changes in general properties separation.
Signed-off-by: Moudy Ho
---
.../{mediatek,mdp3-rdma.yaml => mediatek,mdp3-rdma-8183.yaml} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename Documentation/devicetree/bindings/media/{mediatek,mdp3-rdma.yaml =>
mediatek,mdp3-rdma-8183.yaml} (96%)
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma-8183.yaml
similarity index 96%
rename from Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
rename to Documentation/devicetree/bindings/media/mediatek,mdp3-rdma-8183.yaml
index 0539badc9821..74a1eebf668d 100644
--- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma-8183.yaml
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: http://devicetree.org/schemas/media/mediatek,mdp3-rdma.yaml#
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-rdma-8183.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek MT8183 Read Direct Memory Access
--
2.18.0
[PATCH v6 15/16] dt-bindings: display: mediatek: split: add compatible for MT8195
Add a compatible string for the SPLIT block in MediaTek MT8195 that is controlled by MDP3. Signed-off-by: Moudy Ho --- .../devicetree/bindings/display/mediatek/mediatek,split.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml index a8a5c9608598..a96b271e3240 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml @@ -23,6 +23,7 @@ properties: oneOf: - enum: - mediatek,mt8173-disp-split + - mediatek,mt8195-mdp3-split - items: - const: mediatek,mt6795-disp-split - const: mediatek,mt8173-disp-split -- 2.18.0
[PATCH v6 16/16] dt-bindings: display: mediatek: padding: add compatible for MT8195
Add a compatible string for the PAD block in MediaTek MT8195 that is controlled by MDP3. Signed-off-by: Moudy Ho --- .../bindings/display/mediatek/mediatek,padding.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml index db24801ebc48..636b69133acc 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,padding.yaml @@ -20,7 +20,9 @@ description: properties: compatible: -const: mediatek,mt8188-padding +enum: + - mediatek,mt8188-padding + - mediatek,mt8195-mdp3-pad reg: maxItems: 1 -- 2.18.0
[PATCH v6 05/16] dt-bindings: media: mediatek: mdp3: add support MT8195 RDMA
Support for MT8195 RDMA has been added, allowing for
the configuration of multiple MDP3 pipes.
Furthermore, this particular device does not require
sharing SRAM with RSZ.
Signed-off-by: Moudy Ho
---
.../media/mediatek,mdp3-rdma-8195.yaml| 64 +++
1 file changed, 64 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/mediatek,mdp3-rdma-8195.yaml
diff --git
a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma-8195.yaml
b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma-8195.yaml
new file mode 100644
index ..f10139aec3c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma-8195.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-rdma-8195.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT8195 Read Direct Memory Access
+
+maintainers:
+ - Matthias Brugger
+ - Moudy Ho
+
+description: |
+ MediaTek Read Direct Memory Access(RDMA) component used to do read DMA.
+ This type of component is configured when there are multiple MDP3 pipelines
+ that belong to different MMSYS subsystems.
+ It contains one line buffer to store the sufficient pixel data, and
+ must be siblings to the central MMSYS_CONFIG node.
+ For a description of the MMSYS_CONFIG binding, see
+ Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
+ for details.
+
+allOf:
+ - $ref: mediatek,mdp3-rdma-common.yaml#
+
+properties:
+ compatible:
+items:
+ - const: mediatek,mt8195-mdp3-rdma
+
+ clocks:
+maxItems: 1
+
+ mboxes:
+maxItems: 5
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+#include
+
+dma-controller@14001000 {
+compatible = "mediatek,mt8195-mdp3-rdma";
+reg = <0x14001000 0x1000>;
+mediatek,gce-client-reg = <&gce1 SUBSYS_1400 0x1000 0x1000>;
+mediatek,gce-events = ,
+ ;
+power-domains = <&spm MT8195_POWER_DOMAIN_VPPSYS0>;
+iommus = <&iommu_vpp M4U_PORT_L4_MDP_RDMA>;
+clocks = <&vppsys0 CLK_VPP0_MDP_RDMA>;
+mboxes = <&gce1 12 CMDQ_THR_PRIO_1>,
+ <&gce1 13 CMDQ_THR_PRIO_1>,
+ <&gce1 14 CMDQ_THR_PRIO_1>,
+ <&gce1 21 CMDQ_THR_PRIO_1>,
+ <&gce1 22 CMDQ_THR_PRIO_1>;
+#dma-cells = <1>;
+};
--
2.18.0
[PATCH v6 09/16] dt-bindings: media: mediatek: mdp3: add component STITCH for MT8195
Add the fundamental hardware configuration of component STITCH,
which is controlled by MDP3 on MT8195.
Signed-off-by: Moudy Ho
---
.../bindings/media/mediatek,mdp3-tcc.yaml | 60 +++
1 file changed, 60 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml
b/Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml
new file mode 100644
index ..245e2134c74a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-tcc.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-tcc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Media Data Path 3 TCC
+
+maintainers:
+ - Matthias Brugger
+
+description:
+ One of Media Data Path 3 (MDP3) components used to support
+ HDR gamma curve conversion HDR displays.
+
+properties:
+ compatible:
+enum:
+ - mediatek,mt8195-mdp3-tcc
+
+ reg:
+maxItems: 1
+
+ mediatek,gce-client-reg:
+description:
+ The register of display function block to be set by gce. There are 4
arguments,
+ such as gce node, subsys id, offset and register size. The subsys id
that is
+ mapping to the register of display function blocks is defined in the gce
header
+ include/dt-bindings/gce/-gce.h of each chips.
+$ref: /schemas/types.yaml#/definitions/phandle-array
+items:
+ items:
+- description: phandle of GCE
+- description: GCE subsys id
+- description: register offset
+- description: register size
+maxItems: 1
+
+ clocks:
+minItems: 1
+
+required:
+ - compatible
+ - reg
+ - mediatek,gce-client-reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+display@1400b000 {
+compatible = "mediatek,mt8195-mdp3-tcc";
+reg = <0x1400b000 0x1000>;
+mediatek,gce-client-reg = <&gce1 SUBSYS_1400 0xb000 0x1000>;
+clocks = <&vppsys0 CLK_VPP0_MDP_TCC>;
+};
--
2.18.0
[PATCH v6 02/16] dt-bindings: media: mediatek: mdp3: split out general properties
In order to minimize duplication and standardize the document style, it is necessary to separate the general properties specific to MediaTek MDP3 RDMA. Signed-off-by: Moudy Ho --- .../media/mediatek,mdp3-rdma-common.yaml | 72 +++ 1 file changed, 72 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/mediatek,mdp3-rdma-common.yaml diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma-common.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma-common.yaml new file mode 100644 index ..8d2085f67d43 --- /dev/null +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma-common.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/mediatek,mdp3-rdma-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek Read Direct Memory Access + +maintainers: + - Matthias Brugger + - Moudy Ho + +description: | + MediaTek Read Direct Memory Access(RDMA) component used to do read DMA. + It contains one line buffer to store the sufficient pixel data, and + must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + reg: +maxItems: 1 + + mediatek,gce-client-reg: +$ref: /schemas/types.yaml#/definitions/phandle-array +items: + items: +- description: phandle of GCE +- description: GCE subsys id +- description: register offset +- description: register size +description: The register of client driver can be configured by gce with + 4 arguments defined in this property. Each GCE subsys id is mapping to + a client defined in the header include/dt-bindings/gce/-gce.h. +maxItems: 1 + + mediatek,gce-events: +description: + The event id which is mapping to the specific hardware event signal + to gce. The event id is defined in the gce header + include/dt-bindings/gce/-gce.h of each chips. +$ref: /schemas/types.yaml#/definitions/uint32-array +minItems: 1 +maxItems: 2 + + power-domains: +maxItems: 1 + + clocks: +minItems: 1 +maxItems: 2 + + iommus: +maxItems: 1 + + mboxes: +minItems: 1 +maxItems: 5 + + '#dma-cells': +const: 1 + +required: + - reg + - mediatek,gce-client-reg + - power-domains + - clocks + - iommus + - '#dma-cells' + +additionalProperties: true -- 2.18.0
[PATCH v6 14/16] dt-bindings: display: mediatek: ovl: add compatible for MT8195
Add a compatible string for the OVL block in MediaTek MT8195 that is controlled by MDP3. Signed-off-by: Moudy Ho --- .../devicetree/bindings/display/mediatek/mediatek,ovl.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml index 3e1069b00b56..c471a181d125 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml @@ -26,6 +26,7 @@ properties: - mediatek,mt8173-disp-ovl - mediatek,mt8183-disp-ovl - mediatek,mt8192-disp-ovl + - mediatek,mt8195-mdp3-ovl - items: - enum: - mediatek,mt7623-disp-ovl -- 2.18.0
[PATCH v6 07/16] dt-bindings: media: mediatek: mdp3: add component HDR for MT8195
Add the fundamental hardware configuration of component HDR,
which is controlled by MDP3 on MT8195.
Signed-off-by: Moudy Ho
---
.../bindings/media/mediatek,mdp3-hdr.yaml | 60 +++
1 file changed, 60 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml
b/Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml
new file mode 100644
index ..fb1bb5a9e57f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-hdr.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/mediatek,mdp3-hdr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Media Data Path 3 HDR
+
+maintainers:
+ - Matthias Brugger
+ - Moudy Ho
+
+description:
+ One of Media Data Path 3 (MDP3) components used to perform HDR to SDR
+
+properties:
+ compatible:
+enum:
+ - mediatek,mt8195-mdp3-hdr
+
+ reg:
+maxItems: 1
+
+ mediatek,gce-client-reg:
+description:
+ The register of display function block to be set by gce. There are 4
arguments,
+ such as gce node, subsys id, offset and register size. The subsys id
that is
+ mapping to the register of display function blocks is defined in the gce
header
+ include/dt-bindings/gce/-gce.h of each chips.
+$ref: /schemas/types.yaml#/definitions/phandle-array
+items:
+ items:
+- description: phandle of GCE
+- description: GCE subsys id
+- description: register offset
+- description: register size
+maxItems: 1
+
+ clocks:
+minItems: 1
+
+required:
+ - compatible
+ - reg
+ - mediatek,gce-client-reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+display@14004000 {
+compatible = "mediatek,mt8195-mdp3-hdr";
+reg = <0x14004000 0x1000>;
+mediatek,gce-client-reg = <&gce1 SUBSYS_1400 0x4000 0x1000>;
+clocks = <&vppsys0 CLK_VPP0_MDP_HDR>;
+};
--
2.18.0
Re: [PATCH v2 3/6] drm: lcdif: rework runtime PM handling in the atomic commit
Am Freitag, dem 22.09.2023 um 09:51 + schrieb Ying Liu:
> On Friday, September 22, 2023 4:03 AM Lucas Stach
> wrote:
> > drm_atomic_helper_commit_tail_rpm makes it hard for drivers to follow
> > the documented encoder/bridge enable flow, as it commits all CRTC enables
> > before the planes are fully set up, so drivers that can't enable the
> > display link without valid plane setup either need to do the plane setup
> > in the CRTC enable or violate the flow by enabling the display link after
> > the planes have been set up. Neither of those options seem like a good
> > idea.
> >
> > For devices that only do coarse-grained runtime PM for the whole display
> > controller and not per CRTC, like the i.MX LCDIF, we can handle hardware
> > wakeup and suspend in the atomic_commit_tail. Add a commit tail which
> > follows the more conventional atomic commit flow of first diabling any
> > unused CRTCs, setting up all the active plane state, then enable all
> > active display pipes and also handles the device runtime PM at the
> > appropriate times.
> >
> > Signed-off-by: Lucas Stach
> > ---
> > v2: new patch
> > ---
> > drivers/gpu/drm/mxsfb/lcdif_drv.c | 22 +-
> > drivers/gpu/drm/mxsfb/lcdif_kms.c | 12 ++--
> > 2 files changed, 31 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c
> > b/drivers/gpu/drm/mxsfb/lcdif_drv.c
> > index 18de2f17e249..205f6855fb1b 100644
> > --- a/drivers/gpu/drm/mxsfb/lcdif_drv.c
> > +++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
> > @@ -36,8 +36,28 @@ static const struct drm_mode_config_funcs
> > lcdif_mode_config_funcs = {
> > .atomic_commit = drm_atomic_helper_commit,
> > };
> >
> > +void lcdif_commit_tail(struct drm_atomic_state *old_state)
> > +{
> > + struct drm_device *drm = old_state->dev;
> > +
> > + pm_runtime_get_sync(drm->dev);
>
> Here, pixel clock lcdif->clk is enabled via lcdif_rpm_resume(), and then ...
>
> > +
> > + drm_atomic_helper_commit_modeset_disables(drm, old_state);
> > + drm_atomic_helper_commit_planes(drm, old_state,
> > +
> > DRM_PLANE_COMMIT_ACTIVE_ONLY);
> > + drm_atomic_helper_commit_modeset_enables(drm, old_state);
>
> ... here, clk_set_rate() is called for lcdif->clk via
> lcdif_crtc_atomic_enable().
> Set rate with clock enabled?
>
Yea, I don't like the pixel clock enable/disable in the runtime PM
handling, but wanted to minimize the changes for now and I don't think
there is any issue with changing the rate of a already enabled clock.
Might be better to move the pixel clock enable/disable in the
atomic_enable/disable to clear any doubt.
> Another concern is lcdif_reset_block() is called via
> lcdif_crtc_mode_set_nofb()
> here, while plane is already set up, which means plane settings are
> potentially
> reset.
>
I thought so as well, but the documentation states that only internal
state is reset, not the user visible registers. My testing seemed to
indicate that the plane state is unaffected by the reset, but...
> With this patch series, display shows constant color by running modetest to
> change fb pixel format. However, doing page flip with "-v" option seems fine.
> Also, seems the issue doesn't reproduce without fbdev emulation.
>
... this seems to contradict this. I'll dig some more into this. I
don't even know if this reset is required at all at this point, as it
seems this is a leftover from the mxsfb code. I can't find any
mandatory reset in the i.MX8MP reference manual.
Regards,
Lucas
> Regards,
> Liu Ying
>
> > +
> > + drm_atomic_helper_fake_vblank(old_state);
> > + drm_atomic_helper_commit_hw_done(old_state);
> > + drm_atomic_helper_wait_for_vblanks(drm, old_state);
> > +
> > + pm_runtime_put(drm->dev);
> > +
> > + drm_atomic_helper_cleanup_planes(drm, old_state);
> > +}
> > +
> > static const struct drm_mode_config_helper_funcs
> > lcdif_mode_config_helpers = {
> > - .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
> > + .atomic_commit_tail = lcdif_commit_tail,
> > };
> >
> > static const struct drm_encoder_funcs lcdif_encoder_funcs = {
> > diff --git a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > index e277592e5fa5..ccee5e28f236 100644
> > --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> > @@ -540,7 +540,11 @@ static void lcdif_crtc_atomic_enable(struct drm_crtc
> > *crtc,
> >
> > clk_set_rate(lcdif->clk, m->crtc_clock * 1000);
> >
> > - pm_runtime_get_sync(drm->dev);
> > + /*
> > +* Update the RPM usage count, actual resume already happened in
> > +* lcdif_commit_tail wrapping all the atomic update.
> > +*/
> > + pm_runtime_get_noresume(drm->dev);
> >
> > lcdif_crtc_mode_set_nofb(new_cstate, new_pstate);
> >
> > @@ -576,7 +580,11 @@ static void lcdif_crtc_atomic_disable(struct drm_crtc
> > *crtc,
> > }
> > spin_unlock_irq(&drm->event_lock);
> >
> > - pm_runtime_put_sync(drm->dev);
> > + /*
> >
Re: [1/8] drm/display/dp: Add helper function to get DSC bpp prescision
Hi,
The word 'prescision' in the commit title is a typo,
perhaps it's more better correct it as 'precision' when merge.
On 2023/9/13 14:05, Mitul Golani wrote:
From: Ankit Nautiyal
Add helper to get the DSC bits_per_pixel precision for the DP sink.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Suraj Kandpal
---
drivers/gpu/drm/display/drm_dp_helper.c | 27 +
include/drm/display/drm_dp_helper.h | 1 +
2 files changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index 8a1b64c57dfd..5c23d5b8fc50 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2323,6 +2323,33 @@ int drm_dp_read_desc(struct drm_dp_aux *aux, struct
drm_dp_desc *desc,
}
EXPORT_SYMBOL(drm_dp_read_desc);
+/**
+ * drm_dp_dsc_sink_bpp_incr() - Get bits per pixel increment
+ * @dsc_dpcd: DSC capabilities from DPCD
+ *
+ * Returns the bpp precision supported by the DP sink.
+ */
+u8 drm_dp_dsc_sink_bpp_incr(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
+{
+ u8 bpp_increment_dpcd = dsc_dpcd[DP_DSC_BITS_PER_PIXEL_INC -
DP_DSC_SUPPORT];
+
+ switch (bpp_increment_dpcd) {
+ case DP_DSC_BITS_PER_PIXEL_1_16:
+ return 16;
+ case DP_DSC_BITS_PER_PIXEL_1_8:
+ return 8;
+ case DP_DSC_BITS_PER_PIXEL_1_4:
+ return 4;
+ case DP_DSC_BITS_PER_PIXEL_1_2:
+ return 2;
+ case DP_DSC_BITS_PER_PIXEL_1_1:
+ return 1;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_dsc_sink_bpp_incr);
+
/**
* drm_dp_dsc_sink_max_slice_count() - Get the max slice count
* supported by the DSC sink.
diff --git a/include/drm/display/drm_dp_helper.h
b/include/drm/display/drm_dp_helper.h
index 3369104e2d25..6968d4d87931 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -164,6 +164,7 @@ drm_dp_is_branch(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
}
/* DP/eDP DSC support */
+u8 drm_dp_dsc_sink_bpp_incr(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE]);
u8 drm_dp_dsc_sink_max_slice_count(const u8
dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
bool is_edp);
u8 drm_dp_dsc_sink_line_buf_depth(const u8
dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE]);
Re: [PATCH 6/7] accel/qaic: Create a function to initialize BO
On 9/17/2023 2:48 AM, Stanislaw Gruszka wrote:
On Fri, Sep 01, 2023 at 11:22:46AM -0600, Jeffrey Hugo wrote:
From: Pranjal Ramajor Asha Kanojiya
This makes sure that we have a single place to initialize and
re-initialize BO.
Use this new API to cleanup release_dbc()
We will need this for next patch to detach slicing to a BO.
Signed-off-by: Pranjal Ramajor Asha Kanojiya
Reviewed-by: Jeffrey Hugo
Signed-off-by: Jeffrey Hugo
---
drivers/accel/qaic/qaic_data.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/accel/qaic/qaic_data.c b/drivers/accel/qaic/qaic_data.c
index 6e44e00937af..2acb9dbac88b 100644
--- a/drivers/accel/qaic/qaic_data.c
+++ b/drivers/accel/qaic/qaic_data.c
@@ -635,6 +635,18 @@ static const struct drm_gem_object_funcs qaic_gem_funcs = {
.vm_ops = &drm_vm_ops,
};
+static void qaic_init_bo(struct qaic_bo *bo, bool reinit)
+{
+ if (reinit) {
+ bo->sliced = false;
+ reinit_completion(&bo->xfer_done);
+ } else {
+ init_completion(&bo->xfer_done);
+ }
+ complete_all(&bo->xfer_done);
Why do you need complete_all() here ?
This is moved from qaic_alloc_init_bo().
This puts the BO in a state where the wait_exec ioctl will fall through
and return if userspace immediately calls it after allocating the BO,
prior to submitting the BO to hardware. Otherwise we need a special,
one off check to see that the BO was never submitted to the hardware and
handle that edge case.
-Jeff
Re: [3/8] drm/i915/display: Consider fractional vdsc bpp while computing m_n values
Hi,
On 2023/9/13 14:06, Mitul Golani wrote:
From: Ankit Nautiyal
MTL+ supports fractional compressed bits_per_pixel, with precision of
1/16. This compressed bpp is stored in U6.4 format.
Accommodate this precision while computing m_n values.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +-
drivers/gpu/drm/i915/display/intel_display.h | 2 +-
drivers/gpu/drm/i915/display/intel_dp.c | 5 +++--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 6 --
drivers/gpu/drm/i915/display/intel_fdi.c | 2 +-
5 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index afcbdd4f105a..b37aeac961f4 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2380,10 +2380,14 @@ void
intel_link_compute_m_n(u16 bits_per_pixel, int nlanes,
int pixel_clock, int link_clock,
struct intel_link_m_n *m_n,
- bool fec_enable)
+ bool fec_enable,
+ bool is_dsc_fractional_bpp)
{
u32 data_clock = bits_per_pixel * pixel_clock;
+ if (is_dsc_fractional_bpp)
+ data_clock = DIV_ROUND_UP(bits_per_pixel * pixel_clock, 16);
+
The 'bits_per_pixel * pixel_clock' has already been computed
and its result is stored in the 'data_clock' local variable.
can we change it as "data_clock = DIV_ROUND_UP(data_clock, 16)" here ?
if (fec_enable)
data_clock = intel_dp_mode_to_fec_clock(data_clock);
diff --git a/drivers/gpu/drm/i915/display/intel_display.h b/drivers/gpu/drm/i915/display/intel_display.h
index 49ac8473b988..a4c4ca3cad65 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -398,7 +398,7 @@ u8 intel_calc_active_pipes(struct intel_atomic_state *state,
void intel_link_compute_m_n(u16 bpp, int nlanes,
int pixel_clock, int link_clock,
struct intel_link_m_n *m_n,
- bool fec_enable);
+ bool fec_enable, bool is_dsc_fractional_bpp);
u32 intel_plane_fb_max_stride(struct drm_i915_private *dev_priv,
u32 pixel_format, u64 modifier);
enum drm_mode_status
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index cb647bb38b12..6e09e21909a1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2562,7 +2562,7 @@ intel_dp_drrs_compute_config(struct intel_connector
*connector,
intel_link_compute_m_n(link_bpp, pipe_config->lane_count, pixel_clock,
pipe_config->port_clock, &pipe_config->dp_m2_n2,
- pipe_config->fec_enable);
+ pipe_config->fec_enable, false);
/* FIXME: abstract this better */
if (pipe_config->splitter.enable)
@@ -2741,7 +2741,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
adjusted_mode->crtc_clock,
pipe_config->port_clock,
&pipe_config->dp_m_n,
- pipe_config->fec_enable);
+ pipe_config->fec_enable,
+ pipe_config->dsc.compression_enable);
/* FIXME: abstract this better */
if (pipe_config->splitter.enable)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 7bf0b6e4ac0b..8f6bd54532cb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -172,7 +172,8 @@ static int intel_dp_mst_compute_link_config(struct
intel_encoder *encoder,
adjusted_mode->crtc_clock,
crtc_state->port_clock,
&crtc_state->dp_m_n,
- crtc_state->fec_enable);
+ crtc_state->fec_enable,
+ false);
crtc_state->dp_m_n.tu = slots;
return 0;
@@ -269,7 +270,8 @@ static int intel_dp_dsc_mst_compute_link_config(struct
intel_encoder *encoder,
adjusted_mode->crtc_clock,
crtc_state->port_clock,
&crtc_state->dp_m_n,
- crtc_state->fec_enable);
+ crtc_state->fec_enable,
+ crtc_state->dsc.compression_enable);
crtc_state->dp_m_n.tu = slots;
return 0;
diff --git a/drivers/gpu/drm/i915/display/intel_fdi.c
b/drivers/gpu/drm/i915/display/intel_fdi.c
index e12b46a84fa1..15fddabf7c2e 100644
--- a/driver
Re: [PATCH 7/7] accel/qaic: Add QAIC_DETACH_SLICE_BO IOCTL
On 9/17/2023 2:56 AM, Stanislaw Gruszka wrote:
On Fri, Sep 01, 2023 at 11:22:47AM -0600, Jeffrey Hugo wrote:
From: Pranjal Ramajor Asha Kanojiya
Once a BO is attached with slicing configuration that BO can only be used
for that particular setting. With this new feature user can detach slicing
configuration off an already sliced BO and attach new slicing configuration
using QAIC_ATTACH_SLICE_BO.
This will support BO recycling.
detach_slice_bo() detaches slicing configuration from a BO. This new
helper function can also be used in release_dbc() as we are doing the
exact same thing.
Signed-off-by: Pranjal Ramajor Asha Kanojiya
Reviewed-by: Jeffrey Hugo
[jhugo: add documentation for new ioctl]
Signed-off-by: Jeffrey Hugo
+ /* Check if BO is committed to H/W for DMA */
+ spin_lock_irqsave(&dbc->xfer_lock, flags);
+ if (bo->queued) {
+ spin_unlock_irqrestore(&dbc->xfer_lock, flags);
+ ret = -EBUSY;
+ goto unlock_ch_srcu;
+ }
+ spin_unlock_irqrestore(&dbc->xfer_lock, flags);
This looks like race condition. If some other thread will take the xfer_lock
and set bo->queued (HERE just after _unlock()) we will not return -EBUSY.
Something seems to be missing here or xfer_lock is not needed to protect
bo->queued.
The other thread would also need to take the bo->lock, which is held
here and not released until after detach_slice_bo(). xfer_lock actually
protects xfer_list, but bo->queued is a quick check to see if the bo is
in the list, rather than iterating the list. I can see how this is
misleading. I will ponder how to improve it.
-Jeff
Re: [PATCH 0/7] accel/qaic: Extend uAPI to support undoing ATTACH_SLICE_BO
On 9/17/2023 2:58 AM, Stanislaw Gruszka wrote: On Fri, Sep 01, 2023 at 11:22:40AM -0600, Jeffrey Hugo wrote: A BO for a QAIC device has two states - 1. Allocated 2. Sliced A BO can be allocated at any time, and is initialized in the allocated state. A BO can transition to the sliced state via ATTACH_SLICE_BO. This prepares the BO for use with an active workload. Currently a BO in the sliced state can only be used with a single workload, and will only transition back to the allocated state once the workload is deactivated. Userspace would like the ability to trigger a BO transition from the sliced state to the allocated state. This would support the usecase of a userspace client that has two active workloads, where the output of the first workload becomes the input of the second workload. Currently, the client would need two BOs, once for each workload, and copy from one BO to the other. To support this usecase, we create the detach slice concept which is the inverse operation of ATTACH_SLICE_BO. We extend the uAPI with a new DETACH_SLICE_BO ioctl that allows userspace to perform this operation. Since ATTACH_SLICE_BO and DETACH_SLICE_BO are related operations, they share a decent amount of code. This series starts with restructuring the common code for use in both ioctls before finally adding the DETACH_SLICE_BO. Pranjal Ramajor Asha Kanojiya (7): accel/qaic: Remove ->size field from struct qaic_bo accel/qaic: Update BO metadata in a central location accel/qaic: Declare BO 'sliced' after all the operations are complete accel/qaic: Undo slicing setup done in qaic_attach_slicing_bo() accel/qaic: Clean up BO during flushing of transfer list accel/qaic: Create a function to initialize BO accel/qaic: Add QAIC_DETACH_SLICE_BO IOCTL Documentation/accel/qaic/qaic.rst | 10 ++ drivers/accel/qaic/qaic.h | 6 +- drivers/accel/qaic/qaic_data.c| 187 +++--- drivers/accel/qaic/qaic_drv.c | 1 + include/uapi/drm/qaic_accel.h | 24 +++- 5 files changed, 175 insertions(+), 53 deletions(-) Do not see any serious issues with the set. Reviewed-by: Stanislaw Gruszka for the whole series. Thanks! -Jeff
Re: [RFC 1/4] accel/ivpu: Allocate vpu_addr in gem->open() callback
On 9/19/2023 3:24 AM, Stanislaw Gruszka wrote: On Mon, Sep 11, 2023 at 09:19:03AM -0600, Jeffrey Hugo wrote: On 9/1/2023 10:48 AM, Stanislaw Gruszka wrote: From: Jacek Lawrynowicz gem->open() is called during handle creation for a gem object. It is called during prime import and in BO_CREATE ioctl. I feel like the "why" is missing. This appears to start to explain how gem->open() might be useful for the driver, but does not seem to complete explaining the connection to the driver. From the code changes, it looks like using gem->open() simplifies the code by allocating the vpu_addr in one place for all BOs. If that is the goal, I feel that it should be mentioned here. I'm going to change to: Use gem->open() callback to simplify the code and prepare for gem_shmem conversion. It is called during handle creation for a gem object - during prime import and in BO_CREATE ioctl. Hence can be used for vpu_addr allocation. On the way remove unused bo->user_ptr field. Seems good to me. With that Reviewed-by: Jeffrey Hugo
Re: [RFC 3/4] accel/ivpu: Remove support for uncached buffers
On 9/19/2023 3:49 AM, Stanislaw Gruszka wrote:
On Mon, Sep 11, 2023 at 09:24:42AM -0600, Jeffrey Hugo wrote:
On 9/1/2023 10:48 AM, Stanislaw Gruszka wrote:
From: Jacek Lawrynowicz
Usages of DRM_IVPU_BO_UNCACHED should be replaced by DRM_IVPU_BO_WC.
There is no functional benefit from DRM_IVPU_BO_UNCACHED if these
buffers are never mapped to host VM.
This allows to cut the buffer handling code in the kernel driver
by half.
Signed-off-by: Jacek Lawrynowicz
Signed-off-by: Stanislaw Gruszka
---
drivers/accel/ivpu/ivpu_fw.c | 2 +-
drivers/accel/ivpu/ivpu_gem.c | 3 ---
include/uapi/drm/ivpu_accel.h | 2 +-
3 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/accel/ivpu/ivpu_fw.c b/drivers/accel/ivpu/ivpu_fw.c
index 2fef9fe154aa..8ab0f3225205 100644
--- a/drivers/accel/ivpu/ivpu_fw.c
+++ b/drivers/accel/ivpu/ivpu_fw.c
@@ -248,7 +248,7 @@ static int ivpu_fw_mem_init(struct ivpu_device *vdev)
if (fw->shave_nn_size) {
fw->mem_shave_nn = ivpu_bo_alloc_internal(vdev,
vdev->hw->ranges.shave.start,
- fw->shave_nn_size,
DRM_IVPU_BO_UNCACHED);
+ fw->shave_nn_size,
DRM_IVPU_BO_WC);
if (!fw->mem_shave_nn) {
ivpu_err(vdev, "Failed to allocate shavenn buffer\n");
ret = -ENOMEM;
diff --git a/drivers/accel/ivpu/ivpu_gem.c b/drivers/accel/ivpu/ivpu_gem.c
index 915c53d7bb97..2a91eb1e3627 100644
--- a/drivers/accel/ivpu/ivpu_gem.c
+++ b/drivers/accel/ivpu/ivpu_gem.c
@@ -89,8 +89,6 @@ static int __must_check shmem_alloc_pages_locked(struct
ivpu_bo *bo)
if (bo->flags & DRM_IVPU_BO_WC)
set_pages_array_wc(pages, npages);
- else if (bo->flags & DRM_IVPU_BO_UNCACHED)
- set_pages_array_uc(pages, npages);
bo->pages = pages;
return 0;
@@ -366,7 +364,6 @@ ivpu_bo_alloc(struct ivpu_device *vdev, u64 size, u32
flags, const struct ivpu_b
switch (flags & DRM_IVPU_BO_CACHE_MASK) {
case DRM_IVPU_BO_CACHED:
- case DRM_IVPU_BO_UNCACHED:
case DRM_IVPU_BO_WC:
break;
default:
diff --git a/include/uapi/drm/ivpu_accel.h b/include/uapi/drm/ivpu_accel.h
index 262db0c3beee..de1944e42c65 100644
--- a/include/uapi/drm/ivpu_accel.h
+++ b/include/uapi/drm/ivpu_accel.h
@@ -196,7 +196,7 @@ struct drm_ivpu_bo_create {
*
* %DRM_IVPU_BO_UNCACHED:
*
-* Allocated BO will not be cached on host side nor snooped on the VPU
side.
+* Not supported. Use DRM_IVPU_BO_WC instead.
*
* %DRM_IVPU_BO_WC:
*
Feels like this will break existing userspace. You could see if userspace
specified UNCACHED and change it to WC before processing the request. Maybe
also use WARN_ONCE to indicate that userspace should be updated.
Or is it the case that userspace never actually used this?
Usage of those buffers was removed some time ago:
https://github.com/intel/linux-vpu-driver/commit/c473c9826cb28fa3dcf8883fc804b1e84c6b5fb1
And will not be part of first user-mode driver release. I think we can
safely do the change.
Fair enough. Thanks for the clarification.
Reviewed-by: Jeffrey Hugo
Re: [PATCH v6 2/6] drm/panfrost: Add fdinfo support GPU load metrics
On 22/09/2023 14:53, Tvrtko Ursulin wrote:
>
> On 22/09/2023 11:57, Adrián Larumbe wrote:
>> On 20.09.2023 16:40, Tvrtko Ursulin wrote:
>>> On 20/09/2023 00:34, Adrián Larumbe wrote:
The drm-stats fdinfo tags made available to user space are drm-engine,
drm-cycles, drm-max-freq and drm-curfreq, one per job slot.
This deviates from standard practice in other DRM drivers, where a
single
set of key:value pairs is provided for the whole render engine.
However,
Panfrost has separate queues for fragment and vertex/tiler jobs, so a
decision was made to calculate bus cycles and workload times
separately.
Maximum operating frequency is calculated at devfreq initialisation
time.
Current frequency is made available to user space because nvtop uses it
when performing engine usage calculations.
It is important to bear in mind that both GPU cycle and kernel time
numbers
provided are at best rough estimations, and always reported in
excess from
the actual figure because of two reasons:
- Excess time because of the delay between the end of a job
processing,
the subsequent job IRQ and the actual time of the sample.
- Time spent in the engine queue waiting for the GPU to pick up
the next
job.
To avoid race conditions during enablement/disabling, a reference
counting
mechanism was introduced, and a job flag that tells us whether a
given job
increased the refcount. This is necessary, because user space can
toggle
cycle counting through a debugfs file, and a given job might have
been in
flight by the time cycle counting was disabled.
The main goal of the debugfs cycle counter knob is letting tools
like nvtop
or IGT's gputop switch it at any time, to avoid power waste in case no
engine usage measuring is necessary.
Signed-off-by: Adrián Larumbe
Reviewed-by: Boris Brezillon
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/Makefile | 2 +
drivers/gpu/drm/panfrost/panfrost_debugfs.c | 20
drivers/gpu/drm/panfrost/panfrost_debugfs.h | 13 +
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 8 +++
drivers/gpu/drm/panfrost/panfrost_devfreq.h | 3 ++
drivers/gpu/drm/panfrost/panfrost_device.c | 2 +
drivers/gpu/drm/panfrost/panfrost_device.h | 13 +
drivers/gpu/drm/panfrost/panfrost_drv.c | 57
-
drivers/gpu/drm/panfrost/panfrost_gpu.c | 41 +++
drivers/gpu/drm/panfrost/panfrost_gpu.h | 4 ++
drivers/gpu/drm/panfrost/panfrost_job.c | 24 +
drivers/gpu/drm/panfrost/panfrost_job.h | 5 ++
12 files changed, 191 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/panfrost/panfrost_debugfs.c
create mode 100644 drivers/gpu/drm/panfrost/panfrost_debugfs.h
diff --git a/drivers/gpu/drm/panfrost/Makefile
b/drivers/gpu/drm/panfrost/Makefile
index 7da2b3f02ed9..2c01c1e7523e 100644
--- a/drivers/gpu/drm/panfrost/Makefile
+++ b/drivers/gpu/drm/panfrost/Makefile
@@ -12,4 +12,6 @@ panfrost-y := \
panfrost_perfcnt.o \
panfrost_dump.o
+panfrost-$(CONFIG_DEBUG_FS) += panfrost_debugfs.o
+
obj-$(CONFIG_DRM_PANFROST) += panfrost.o
diff --git a/drivers/gpu/drm/panfrost/panfrost_debugfs.c
b/drivers/gpu/drm/panfrost/panfrost_debugfs.c
new file mode 100644
index ..cc14eccba206
--- /dev/null
+++ b/drivers/gpu/drm/panfrost/panfrost_debugfs.c
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright 2023 Collabora ltd. */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "panfrost_device.h"
+#include "panfrost_gpu.h"
+#include "panfrost_debugfs.h"
+
+void panfrost_debugfs_init(struct drm_minor *minor)
+{
+ struct drm_device *dev = minor->dev;
+ struct panfrost_device *pfdev =
platform_get_drvdata(to_platform_device(dev->dev));
+
+ debugfs_create_atomic_t("profile", 0600, minor->debugfs_root,
&pfdev->profile_mode);
+}
diff --git a/drivers/gpu/drm/panfrost/panfrost_debugfs.h
b/drivers/gpu/drm/panfrost/panfrost_debugfs.h
new file mode 100644
index ..db1c158bcf2f
--- /dev/null
+++ b/drivers/gpu/drm/panfrost/panfrost_debugfs.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright 2023 Collabora ltd.
+ */
+
+#ifndef PANFROST_DEBUGFS_H
+#define PANFROST_DEBUGFS_H
+
+#ifdef CONFIG_DEBUG_FS
+void panfrost_debugfs_init(struct drm_minor *minor);
+#endif
+
+#endif /* PANFROST_DEBUGFS_H */
diff --git a/dr
Re: [PATCH] accel/ivpu: Add Arrow Lake pci id
On 9/22/2023 7:22 AM, Stanislaw Gruszka wrote:
Enable VPU on Arrow Lake CPUs.
Reviewed-by: Krystian Pradzynski
Reviewed-by: Karol Wachowski
Signed-off-by: Stanislaw Gruszka
---
drivers/accel/ivpu/ivpu_drv.c | 1 +
drivers/accel/ivpu/ivpu_drv.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
index ba79f397c9e8..aa7314fdbc0f 100644
--- a/drivers/accel/ivpu/ivpu_drv.c
+++ b/drivers/accel/ivpu/ivpu_drv.c
@@ -634,6 +634,7 @@ static void ivpu_dev_fini(struct ivpu_device *vdev)
static struct pci_device_id ivpu_pci_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_MTL) },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_ARL) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_LNL) },
{ }
};
diff --git a/drivers/accel/ivpu/ivpu_drv.h b/drivers/accel/ivpu/ivpu_drv.h
index 9e8c075fe9ef..03b3d6532fb6 100644
--- a/drivers/accel/ivpu/ivpu_drv.h
+++ b/drivers/accel/ivpu/ivpu_drv.h
@@ -23,6 +23,7 @@
#define DRIVER_DATE "20230117"
#define PCI_DEVICE_ID_MTL 0x7d1d
+#define PCI_DEVICE_ID_ARL 0xad1d
#define PCI_DEVICE_ID_LNL 0x643e
I'm curious, how are these ordered? Release date? Doesn't seem like it
is alphabetical nor numerical by DID.
Not a problem, just something I'd like to know.
Reviewed-by: Jeffrey Hugo
Re: [PATCH V2 1/2] dt-bindings: display: newvision,nv3051d: Add Anbernic 351V Support
On Fri, Aug 11, 2023 at 09:41:48AM -0500, Chris Morgan wrote: > On Thu, Aug 10, 2023 at 05:24:09PM -0600, Rob Herring wrote: > > On Wed, Aug 09, 2023 at 10:39:40AM -0500, Chris Morgan wrote: > > > From: Chris Morgan > > > > > > Document the Anbernic RG351V panel, which appears to be identical to > > > the panel used in their 353 series except for in inclusion of an > > > additional DSI format flag. > > > > > > Signed-off-by: Chris Morgan > > > --- > > > .../display/panel/newvision,nv3051d.yaml | 18 ++ > > > 1 file changed, 10 insertions(+), 8 deletions(-) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml > > > b/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml > > > index 116c1b6030a2..576f3640cb33 100644 > > > --- > > > a/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml > > > +++ > > > b/Documentation/devicetree/bindings/display/panel/newvision,nv3051d.yaml > > > @@ -7,9 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# > > > title: NewVision NV3051D based LCD panel > > > > > > description: | > > > - The NewVision NV3051D is a driver chip used to drive DSI panels. For > > > now, > > > - this driver only supports the 640x480 panels found in the Anbernic > > > RG353 > > > - based devices. > > > + The NewVision NV3051D is a driver chip used to drive DSI panels. > > > > > > maintainers: > > >- Chris Morgan > > > @@ -19,11 +17,15 @@ allOf: > > > > > > properties: > > >compatible: > > > -items: > > > - - enum: > > > - - anbernic,rg353p-panel > > > - - anbernic,rg353v-panel > > > - - const: newvision,nv3051d > > > +oneOf: > > > + - items: > > > + - enum: > > > + - anbernic,rg353p-panel > > > + - anbernic,rg353v-panel > > > + - const: newvision,nv3051d > > > + > > > + - items: > > > + - const: anbernic,rg351v-panel > > > > I don't understand. Is this panel not based on newvision,nv3051d? If > > not, then it probably should be a different binding. Lot's of panel > > bindings have similar properties. > > It appears to be the same panel (or extremely similar, honestly I don't > know because there are no external markings on it). However, this > specific implementation seems to require MIPI_DSI_CLOCK_NON_CONTINUOUS, > not using it prevents the panel from working. As for the existing panel > MIPI_DSI_CLOCK_NON_CONTINUOUS stops it from working. The different > binding essentially determines whether or not that flag is present, but > otherwise everything else is identical. > > Chris I don't want to lose sight of this, but I am not sure how to proceed. What I can do instead is change the compatible string inside the driver from newvision,nv3051d to either anbernic,rg353p-panel or anbernic,rg351v-panel. Then, I can remove anbernic,rg353v-panel as an enum and replace it with anbernic,rg351v-panel. The gist of this is that we have a Newvision NV3051D panel that will still be supported by this driver in 2 different configurations, the 353P (which is identical to the 353V) and the 351V (which has different mode flags but is otherwise identical). So long story short would it work if I did this, and modified the driver and all in-use devicetrees accordingly? To my knowledge this panel is only in use on boards that I submitted so I can update all those and test them. - enum: - anbernic,rg351v-panel - anbernic,rg353p-panel - const: newvision,nv3051d Thank you, Chris. > > > > > Rob
Re: [PATCH v6 03/16] dt-bindings: media: mediatek: mdp3: include common properties
On Fri, Sep 22, 2023 at 03:21:03PM +0800, Moudy Ho wrote: > To minimize duplication and standardize the document style, > include the common properties for MT8183 RDMA. Duplication that you created in the previous patch? Why not combine patches 2 & 3? Cheers, Conor. > > Signed-off-by: Moudy Ho > --- > .../bindings/media/mediatek,mdp3-rdma.yaml| 43 ++- > 1 file changed, 4 insertions(+), 39 deletions(-) > > diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml > b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml > index 3e128733ef53..0539badc9821 100644 > --- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml > +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml > @@ -4,7 +4,7 @@ > $id: http://devicetree.org/schemas/media/mediatek,mdp3-rdma.yaml# > $schema: http://devicetree.org/meta-schemas/core.yaml# > > -title: MediaTek Read Direct Memory Access > +title: MediaTek MT8183 Read Direct Memory Access > > maintainers: >- Matthias Brugger > @@ -18,62 +18,27 @@ description: | >Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml >for details. > > +allOf: > + - $ref: mediatek,mdp3-rdma-common.yaml# > + > properties: >compatible: > items: >- const: mediatek,mt8183-mdp3-rdma > > - reg: > -maxItems: 1 > - > - mediatek,gce-client-reg: > -$ref: /schemas/types.yaml#/definitions/phandle-array > -items: > - items: > -- description: phandle of GCE > -- description: GCE subsys id > -- description: register offset > -- description: register size > -description: The register of client driver can be configured by gce with > - 4 arguments defined in this property. Each GCE subsys id is mapping to > - a client defined in the header include/dt-bindings/gce/-gce.h. > - > - mediatek,gce-events: > -description: > - The event id which is mapping to the specific hardware event signal > - to gce. The event id is defined in the gce header > - include/dt-bindings/gce/-gce.h of each chips. > -$ref: /schemas/types.yaml#/definitions/uint32-array > - > - power-domains: > -maxItems: 1 > - >clocks: > items: >- description: RDMA clock >- description: RSZ clock > > - iommus: > -maxItems: 1 > - >mboxes: > items: >- description: used for 1st data pipe from RDMA >- description: used for 2nd data pipe from RDMA > > - '#dma-cells': > -const: 1 > - > required: >- compatible > - - reg > - - mediatek,gce-client-reg > - - mediatek,gce-events > - - power-domains > - - clocks > - - iommus >- mboxes > - - '#dma-cells' > > additionalProperties: false > > -- > 2.18.0 > signature.asc Description: PGP signature
Re: [PATCH v6 04/16] dt-bindings: media: mediatek: mdp3: rename to MT8183 RDMA
On Fri, Sep 22, 2023 at 03:21:04PM +0800, Moudy Ho wrote:
> The file was renamed to support future scalability in response to
> the changes in general properties separation.
>
> Signed-off-by: Moudy Ho
Same with this, not all too sure why this is a commit of its own.
> ---
> .../{mediatek,mdp3-rdma.yaml => mediatek,mdp3-rdma-8183.yaml} | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> rename Documentation/devicetree/bindings/media/{mediatek,mdp3-rdma.yaml =>
> mediatek,mdp3-rdma-8183.yaml} (96%)
>
> diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
> b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma-8183.yaml
> similarity index 96%
> rename from Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
> rename to Documentation/devicetree/bindings/media/mediatek,mdp3-rdma-8183.yaml
> index 0539badc9821..74a1eebf668d 100644
> --- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
> +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma-8183.yaml
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> %YAML 1.2
> ---
> -$id: http://devicetree.org/schemas/media/mediatek,mdp3-rdma.yaml#
> +$id: http://devicetree.org/schemas/media/mediatek,mdp3-rdma-8183.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> title: MediaTek MT8183 Read Direct Memory Access
> --
> 2.18.0
>
signature.asc
Description: PGP signature
Re: [RFT PATCH v2 01/12] drm/imx/dcss: Call drm_atomic_helper_shutdown() at shutdown time
Hi,
On Fri, Sep 22, 2023 at 12:56 AM Laurentiu Palcu
wrote:
>
> Hi,
>
> On Thu, Sep 21, 2023 at 12:26:44PM -0700, Douglas Anderson wrote:
> > Based on grepping through the source code this driver appears to be
> > missing a call to drm_atomic_helper_shutdown() at system shutdown
> > time. Among other things, this means that if a panel is in use that it
> > won't be cleanly powered off at system shutdown time.
> >
> > The fact that we should call drm_atomic_helper_shutdown() in the case
> > of OS shutdown/restart comes straight out of the kernel doc "driver
> > instance overview" in drm_drv.c.
> >
> > Suggested-by: Maxime Ripard
> > Reviewed-by: Maxime Ripard
> > Signed-off-by: Douglas Anderson
>
> No issues found on i.MX8MQ.
>
> Tested-by: Laurentiu Palcu
> Reviewed-by: Laurentiu Palcu
Thanks! Would you expect this patch to land through drm-misc? If so,
I'm happy to commit it there with your tags. If patches to this driver
normally flow through drm-misc, I'm also happy to post a patch to
MAINTAINERS (or review a patch you post) adding this to the entry for
"NXP i.MX 8MQ DCSS DRIVER":
T: git git://anongit.freedesktop.org/drm/drm-misc
...which would make it obvious in the future that things should land
through drm-misc. This is similar to what I did for commit
92e62478b62c ("MAINTAINERS: Update DRM DRIVERS FOR FREESCALE IMX
entry"). :-)
-Doug
Re: [PATCH v6 05/16] dt-bindings: media: mediatek: mdp3: add support MT8195 RDMA
On Fri, Sep 22, 2023 at 03:21:05PM +0800, Moudy Ho wrote:
> Support for MT8195 RDMA has been added, allowing for
> the configuration of multiple MDP3 pipes.
> Furthermore, this particular device does not require
> sharing SRAM with RSZ.
I'm sorry if I am going over past arguments, if this is 90% the same as
the 8193 rdma, why the extraction + mostly duplicate file, rather than
covering whatever clocks/mboxes differences with an if/then/else in a
single file?
Thanks,
Conor.
>
> Signed-off-by: Moudy Ho
> ---
> .../media/mediatek,mdp3-rdma-8195.yaml| 64 +++
> 1 file changed, 64 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/media/mediatek,mdp3-rdma-8195.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma-8195.yaml
> b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma-8195.yaml
> new file mode 100644
> index ..f10139aec3c5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma-8195.yaml
> @@ -0,0 +1,64 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/mediatek,mdp3-rdma-8195.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek MT8195 Read Direct Memory Access
> +
> +maintainers:
> + - Matthias Brugger
> + - Moudy Ho
> +
> +description: |
> + MediaTek Read Direct Memory Access(RDMA) component used to do read DMA.
> + This type of component is configured when there are multiple MDP3 pipelines
> + that belong to different MMSYS subsystems.
> + It contains one line buffer to store the sufficient pixel data, and
> + must be siblings to the central MMSYS_CONFIG node.
> + For a description of the MMSYS_CONFIG binding, see
> + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
> + for details.
> +
> +allOf:
> + - $ref: mediatek,mdp3-rdma-common.yaml#
> +
> +properties:
> + compatible:
> +items:
> + - const: mediatek,mt8195-mdp3-rdma
> +
> + clocks:
> +maxItems: 1
> +
> + mboxes:
> +maxItems: 5
> +
> +required:
> + - compatible
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +#include
> +#include
> +
> +dma-controller@14001000 {
> +compatible = "mediatek,mt8195-mdp3-rdma";
> +reg = <0x14001000 0x1000>;
> +mediatek,gce-client-reg = <&gce1 SUBSYS_1400 0x1000 0x1000>;
> +mediatek,gce-events = ,
> + ;
> +power-domains = <&spm MT8195_POWER_DOMAIN_VPPSYS0>;
> +iommus = <&iommu_vpp M4U_PORT_L4_MDP_RDMA>;
> +clocks = <&vppsys0 CLK_VPP0_MDP_RDMA>;
> +mboxes = <&gce1 12 CMDQ_THR_PRIO_1>,
> + <&gce1 13 CMDQ_THR_PRIO_1>,
> + <&gce1 14 CMDQ_THR_PRIO_1>,
> + <&gce1 21 CMDQ_THR_PRIO_1>,
> + <&gce1 22 CMDQ_THR_PRIO_1>;
> +#dma-cells = <1>;
> +};
> --
> 2.18.0
>
signature.asc
Description: PGP signature
Re: [PATCH v6 11/16] dt-bindings: display: mediatek: aal: add compatible for MT8195
On Fri, Sep 22, 2023 at 03:21:11PM +0800, Moudy Ho wrote: > Add a compatible string for the AAL block in MediaTek MT8195 that > is controlled by MDP3. > > Signed-off-by: Moudy Ho Acked-by: Conor Dooley Thanks, Conor. > --- > .../devicetree/bindings/display/mediatek/mediatek,aal.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git > a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml > b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml > index 7fd42c8fdc32..b4c28e96dd55 100644 > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml > @@ -24,6 +24,7 @@ properties: >- enum: >- mediatek,mt8173-disp-aal >- mediatek,mt8183-disp-aal > + - mediatek,mt8195-mdp3-aal >- items: >- enum: >- mediatek,mt2712-disp-aal > -- > 2.18.0 > signature.asc Description: PGP signature
Re: [PATCH v6 12/16] dt-bindings: display: mediatek: color: add compatible for MT8195
On Fri, Sep 22, 2023 at 03:21:12PM +0800, Moudy Ho wrote: > Add a compatible string for the COLOR block in MediaTek MT8195 that > is controlled by MDP3. > > Signed-off-by: Moudy Ho > --- > .../devicetree/bindings/display/mediatek/mediatek,color.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git > a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml > b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml > index f21e44092043..b886ca0d89ea 100644 > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml > @@ -26,6 +26,7 @@ properties: >- mediatek,mt2701-disp-color >- mediatek,mt8167-disp-color >- mediatek,mt8173-disp-color > + - mediatek,mt8195-mdp3-color How come this one is a "mdp3" not a "disp"? >- items: >- enum: >- mediatek,mt7623-disp-color > -- > 2.18.0 > signature.asc Description: PGP signature
Re: [PATCH v6 12/16] dt-bindings: display: mediatek: color: add compatible for MT8195
On Fri, Sep 22, 2023 at 04:49:14PM +0100, Conor Dooley wrote: > On Fri, Sep 22, 2023 at 03:21:12PM +0800, Moudy Ho wrote: > > Add a compatible string for the COLOR block in MediaTek MT8195 that > > is controlled by MDP3. > > > > Signed-off-by: Moudy Ho > > --- > > .../devicetree/bindings/display/mediatek/mediatek,color.yaml | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git > > a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml > > b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml > > index f21e44092043..b886ca0d89ea 100644 > > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml > > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml > > @@ -26,6 +26,7 @@ properties: > >- mediatek,mt2701-disp-color > >- mediatek,mt8167-disp-color > >- mediatek,mt8173-disp-color > > + - mediatek,mt8195-mdp3-color > > How come this one is a "mdp3" not a "disp"? I don't know what mdp3 means & googling gives me no answers. What's the "disp" one controlled by, since it isn't controlled by mdp3? > > >- items: > >- enum: > >- mediatek,mt7623-disp-color > > -- > > 2.18.0 > > signature.asc Description: PGP signature
Re: [2/8] drm/i915/display: Store compressed bpp in U6.4 format
Hi,
On 2023/9/13 14:06, Mitul Golani wrote:
From: Ankit Nautiyal
DSC parameter bits_per_pixel is stored in U6.4 format.
The 4 bits represent the fractional part of the bpp.
Currently we use compressed_bpp member of dsc structure to store
only the integral part of the bits_per_pixel.
To store the full bits_per_pixel along with the fractional part,
compressed_bpp is changed to store bpp in U6.4 formats. Intergral
part is retrieved by simply right shifting the member compressed_bpp by 4.
v2:
-Use to_bpp_int, to_bpp_frac_dec, to_bpp_x16 helpers while dealing
with compressed bpp. (Suraj)
-Fix comment styling. (Suraj)
v3:
-Add separate file for 6.4 fixed point helper(Jani, Nikula)
-Add comment for magic values(Suraj)
v4:
-Fix checkpatch caused due to renaming(Suraj)
In this statement, is the 'caused' and the 'due to' duplicated here.
Fix checkpatch warnings due to renaming(Suraj)
Or
Fix checkpatch warnings caused by renaming(Suraj)
Or
Fix checkpatch warnings created due to renaming(Suraj)
Signed-off-by: Ankit Nautiyal
Signed-off-by: Mitul Golani
Reviewed-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/icl_dsi.c| 11 +++---
drivers/gpu/drm/i915/display/intel_audio.c| 3 +-
drivers/gpu/drm/i915/display/intel_bios.c | 6 ++--
drivers/gpu/drm/i915/display/intel_cdclk.c| 6 ++--
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
.../drm/i915/display/intel_display_types.h| 3 +-
drivers/gpu/drm/i915/display/intel_dp.c | 33 ++---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 26 --
.../i915/display/intel_fractional_helper.h| 36 +++
drivers/gpu/drm/i915/display/intel_vdsc.c | 5 +--
10 files changed, 93 insertions(+), 38 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_fractional_helper.h
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index ad6488e9c2b2..0f7594b6aa1f 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -43,6 +43,7 @@
#include "intel_de.h"
#include "intel_dsi.h"
#include "intel_dsi_vbt.h"
+#include "intel_fractional_helper.h"
#include "intel_panel.h"
#include "intel_vdsc.h"
#include "intel_vdsc_regs.h"
@@ -330,7 +331,7 @@ static int afe_clk(struct intel_encoder *encoder,
int bpp;
if (crtc_state->dsc.compression_enable)
- bpp = crtc_state->dsc.compressed_bpp;
+ bpp =
intel_fractional_bpp_from_x16(crtc_state->dsc.compressed_bpp_x16);
else
bpp = mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
@@ -860,7 +861,7 @@ gen11_dsi_set_transcoder_timings(struct intel_encoder *encoder,
* compressed and non-compressed bpp.
*/
if (crtc_state->dsc.compression_enable) {
- mul = crtc_state->dsc.compressed_bpp;
+ mul =
intel_fractional_bpp_from_x16(crtc_state->dsc.compressed_bpp_x16);
div = mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
}
@@ -884,7 +885,7 @@ gen11_dsi_set_transcoder_timings(struct intel_encoder *encoder,
int bpp, line_time_us, byte_clk_period_ns;
if (crtc_state->dsc.compression_enable)
- bpp = crtc_state->dsc.compressed_bpp;
+ bpp =
intel_fractional_bpp_from_x16(crtc_state->dsc.compressed_bpp_x16);
else
bpp =
mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
@@ -1451,8 +1452,8 @@ static void gen11_dsi_get_timings(struct intel_encoder *encoder,
struct drm_display_mode *adjusted_mode =
&pipe_config->hw.adjusted_mode;
- if (pipe_config->dsc.compressed_bpp) {
- int div = pipe_config->dsc.compressed_bpp;
+ if (pipe_config->dsc.compressed_bpp_x16) {
+ int div =
intel_fractional_bpp_from_x16(pipe_config->dsc.compressed_bpp_x16);
int mul = mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
adjusted_mode->crtc_htotal =
diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
b/drivers/gpu/drm/i915/display/intel_audio.c
index 19605264a35c..4f1db1581316 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -35,6 +35,7 @@
#include "intel_crtc.h"
#include "intel_de.h"
#include "intel_display_types.h"
+#include "intel_fractional_helper.h"
#include "intel_lpe_audio.h"
/**
@@ -528,7 +529,7 @@ static unsigned int calc_hblank_early_prog(struct
intel_encoder *encoder,
h_active = crtc_state->hw.adjusted_mode.crtc_hdisplay;
h_total = crtc_state->hw.adjusted_mode.crtc_htotal;
pixel_clk = crtc_state->hw.adjusted_mode.crtc_clock;
- vdsc_bpp = crtc_state->dsc.compressed_bpp;
+ vdsc_bpp =
intel_fractional_bpp_from_x16(crtc_state->dsc.compressed_bpp_x16);
cdclk = i915->displ
Re: [7/8] drm/i915/dsc: Add debugfs entry to validate DSC fractional bpp
Hi,
On 2023/9/13 14:06, Mitul Golani wrote:
From: Swati Sharma
DSC_Sink_BPP_Precision entry is added to i915_dsc_fec_support_show
to depict sink's precision.
Also, new debugfs entry is created to enforce fractional bpp.
If Force_DSC_Fractional_BPP_en is set then while iterating over
output bpp with fractional step size we will continue if output_bpp is
computed as integer. With this approach, we will be able to validate
DSC with fractional bpp.
v2:
Add drm_modeset_unlock to new line(Suraj)
Signed-off-by: Swati Sharma
Signed-off-by: Ankit Nautiyal
Signed-off-by: Mitul Golani
Reviewed-by: Suraj Kandpal
---
.../drm/i915/display/intel_display_debugfs.c | 83 +++
.../drm/i915/display/intel_display_types.h| 1 +
2 files changed, 84 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index f05b52381a83..776ab96def1f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -1244,6 +1244,8 @@ static int i915_dsc_fec_support_show(struct seq_file *m,
void *data)
DP_DSC_YCbCr420_Native)),
str_yes_no(drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd,
DP_DSC_YCbCr444)));
+ seq_printf(m, "DSC_Sink_BPP_Precision: %d\n",
+ drm_dp_dsc_sink_bpp_incr(intel_dp->dsc_dpcd));
seq_printf(m, "Force_DSC_Enable: %s\n",
str_yes_no(intel_dp->force_dsc_en));
if (!intel_dp_is_edp(intel_dp))
@@ -1436,6 +1438,84 @@ static const struct file_operations
i915_dsc_output_format_fops = {
.write = i915_dsc_output_format_write
};
+static int i915_dsc_fractional_bpp_show(struct seq_file *m, void *data)
+{
+ struct drm_connector *connector = m->private;
+ struct drm_device *dev = connector->dev;
+ struct drm_crtc *crtc;
+ struct intel_dp *intel_dp;
+ struct intel_encoder *encoder =
intel_attached_encoder(to_intel_connector(connector));
The 'to_intel_connector()' inline function get used twice in this function,
if it were me, I will cache it with a local variable to prevent over long in
horizontal.
struct intel_connector *intel_connector = to_intel_connector(connector);
struct intel_encoder *encoder = intel_attached_encoder(intel_connector);
+ int ret;
+
+ if (!encoder)
+ return -ENODEV;
+
+ ret =
drm_modeset_lock_single_interruptible(&dev->mode_config.connection_mutex);
+ if (ret)
+ return ret;
+
+ crtc = connector->state->crtc;
+ if (connector->status != connector_status_connected || !crtc) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ intel_dp = intel_attached_dp(to_intel_connector(connector));
intel_dp = intel_attached_dp(intel_connector);
But this patch is OK, I just give a suggestion.
Re: [PATCH 0/7] accel/qaic: Extend uAPI to support undoing ATTACH_SLICE_BO
On 9/1/2023 11:22 AM, Jeffrey Hugo wrote: A BO for a QAIC device has two states - 1. Allocated 2. Sliced A BO can be allocated at any time, and is initialized in the allocated state. A BO can transition to the sliced state via ATTACH_SLICE_BO. This prepares the BO for use with an active workload. Currently a BO in the sliced state can only be used with a single workload, and will only transition back to the allocated state once the workload is deactivated. Userspace would like the ability to trigger a BO transition from the sliced state to the allocated state. This would support the usecase of a userspace client that has two active workloads, where the output of the first workload becomes the input of the second workload. Currently, the client would need two BOs, once for each workload, and copy from one BO to the other. To support this usecase, we create the detach slice concept which is the inverse operation of ATTACH_SLICE_BO. We extend the uAPI with a new DETACH_SLICE_BO ioctl that allows userspace to perform this operation. Since ATTACH_SLICE_BO and DETACH_SLICE_BO are related operations, they share a decent amount of code. This series starts with restructuring the common code for use in both ioctls before finally adding the DETACH_SLICE_BO. Pranjal Ramajor Asha Kanojiya (7): accel/qaic: Remove ->size field from struct qaic_bo accel/qaic: Update BO metadata in a central location accel/qaic: Declare BO 'sliced' after all the operations are complete accel/qaic: Undo slicing setup done in qaic_attach_slicing_bo() accel/qaic: Clean up BO during flushing of transfer list accel/qaic: Create a function to initialize BO accel/qaic: Add QAIC_DETACH_SLICE_BO IOCTL Documentation/accel/qaic/qaic.rst | 10 ++ drivers/accel/qaic/qaic.h | 6 +- drivers/accel/qaic/qaic_data.c| 187 +++--- drivers/accel/qaic/qaic_drv.c | 1 + include/uapi/drm/qaic_accel.h | 24 +++- 5 files changed, 175 insertions(+), 53 deletions(-) Pushed to drm-misc-next -Jeff
Re: [PATCH v4 5/7] drm: ci: Update xfails
Hi o/ On 14/09/2023 05:54, Vignesh Raman wrote: Update amdgpu-stoney-fails, mediatek-mt8173-flakes, mediatek-mt8173-fails, rockchip-rk3399-fails, rockchip-rk3399-flakes, rockchip-rk3288-flakes, i915-cml-fails, i915-cml-flakes, msm-apq8016-flakes files. Add tests that fail sometimes into the *-flakes file and tests that are failing into the *-fails file. Signed-off-by: Helen Koike Signed-off-by: Vignesh Raman --- v2: - No changes v3: - No changes v4: - No changes --- .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt| 1 - drivers/gpu/drm/ci/xfails/i915-cml-fails.txt | 1 - drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt| 2 ++ drivers/gpu/drm/ci/xfails/i915-glk-flakes.txt| 1 + .../gpu/drm/ci/xfails/mediatek-mt8173-fails.txt | 2 -- .../gpu/drm/ci/xfails/mediatek-mt8173-flakes.txt | 16 drivers/gpu/drm/ci/xfails/msm-apq8016-flakes.txt | 2 ++ .../gpu/drm/ci/xfails/rockchip-rk3288-flakes.txt | 1 + .../gpu/drm/ci/xfails/rockchip-rk3399-fails.txt | 4 ++-- .../gpu/drm/ci/xfails/rockchip-rk3399-flakes.txt | 3 +++ 10 files changed, 27 insertions(+), 6 deletions(-) I found an error in the script that updates the flakes from a pipeline, it was adding errors in *-flakes.txt instead of *-fails.txt even when it was consistently failing. I have a partial fix where it works if -flakes.txt is empty (otherwise it duplicates flakes and fails) https://gitlab.freedesktop.org/-/snippets/7655 Could you please regenerate these files with this new version of the script? Btw, I'm improving the script and I'll submit a RFC proposing to include it as a handy tool in ci folder. Thanks, Helen diff --git a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt index bd9392536e7c..58bfded8a3fc 100644 --- a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt +++ b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt @@ -1,7 +1,6 @@ kms_addfb_basic@bad-pitch-65536,Fail kms_addfb_basic@bo-too-small,Fail kms_async_flips@invalid-async-flip,Fail -kms_atomic@plane-immutable-zpos,Fail kms_atomic_transition@plane-toggle-modeset-transition,Fail kms_bw@linear-tiling-1-displays-2560x1440p,Fail kms_bw@linear-tiling-1-displays-3840x2160p,Fail diff --git a/drivers/gpu/drm/ci/xfails/i915-cml-fails.txt b/drivers/gpu/drm/ci/xfails/i915-cml-fails.txt index 6139b410e767..5f513c638beb 100644 --- a/drivers/gpu/drm/ci/xfails/i915-cml-fails.txt +++ b/drivers/gpu/drm/ci/xfails/i915-cml-fails.txt @@ -1,4 +1,3 @@ -kms_color@ctm-0-25,Fail kms_flip_scaled_crc@flip-32bpp-linear-to-64bpp-linear-downscaling,Fail kms_flip_scaled_crc@flip-32bpp-linear-to-64bpp-linear-upscaling,Fail kms_flip_scaled_crc@flip-32bpp-xtile-to-64bpp-xtile-downscaling,Fail diff --git a/drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt b/drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt index 0514a7b3fdb0..f06f1a5b16f9 100644 --- a/drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt +++ b/drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt @@ -7,6 +7,8 @@ kms_bw@linear-tiling-3-displays-3840x2160p kms_bw@linear-tiling-4-displays-1920x1080p kms_bw@linear-tiling-4-displays-2560x1440p kms_bw@linear-tiling-4-displays-3840x2160p +kms_color@ctm-0-25 +kms_cursor_legacy@torture-move kms_draw_crc@draw-method-xrgb-render-xtiled kms_flip@flip-vs-suspend kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-downscaling diff --git a/drivers/gpu/drm/ci/xfails/i915-glk-flakes.txt b/drivers/gpu/drm/ci/xfails/i915-glk-flakes.txt index fc41d13a2d56..3aee1f11ee90 100644 --- a/drivers/gpu/drm/ci/xfails/i915-glk-flakes.txt +++ b/drivers/gpu/drm/ci/xfails/i915-glk-flakes.txt @@ -8,6 +8,7 @@ kms_bw@linear-tiling-3-displays-3840x2160p kms_bw@linear-tiling-4-displays-1920x1080p kms_bw@linear-tiling-4-displays-2560x1440p kms_bw@linear-tiling-4-displays-3840x2160p +kms_cursor_legacy@torture-bo kms_flip@blocking-wf_vblank kms_flip@wf_vblank-ts-check kms_flip@wf_vblank-ts-check-interruptible diff --git a/drivers/gpu/drm/ci/xfails/mediatek-mt8173-fails.txt b/drivers/gpu/drm/ci/xfails/mediatek-mt8173-fails.txt index 671916067dba..c8e64bbfd480 100644 --- a/drivers/gpu/drm/ci/xfails/mediatek-mt8173-fails.txt +++ b/drivers/gpu/drm/ci/xfails/mediatek-mt8173-fails.txt @@ -1,5 +1,4 @@ kms_3d,Fail -kms_addfb_basic@addfb25-bad-modifier,Fail kms_bw@linear-tiling-1-displays-1920x1080p,Fail kms_bw@linear-tiling-1-displays-2560x1440p,Fail kms_bw@linear-tiling-1-displays-3840x2160p,Fail @@ -11,7 +10,6 @@ kms_bw@linear-tiling-3-displays-2560x1440p,Fail kms_bw@linear-tiling-3-displays-3840x2160p,Fail kms_color@pipe-A-invalid-gamma-lut-sizes,Fail kms_color@pipe-B-invalid-gamma-lut-sizes,Fail -kms_force_connector_basic@force-connector-state,Fail kms_force_connector_basic@force-edid,Fail kms_force_connector_basic@force-load-detect,Fail kms_force_connector_basic@prune-stale-modes,Fail diff --git a/drivers/gpu/drm/ci/xfails/mediatek-mt8173-flakes.txt b/drivers/gpu/
Re: [git pull] drm fixes for 6.6-rc3
The pull request you sent on Fri, 22 Sep 2023 16:14:46 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-09-22 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/b41b28366d3b176c8297961de4f095f2e392402d Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[PATCH v2 0/2] drm/ci: Update Mesa and Introduce VKMS Support
This patchset offers two enhancements to drm/ci: 1. Mesa Version Update. drm/ci re-uses components from Mesa project. A recent bug in MesaCI was fixed. The first patch updates drm/ci Mesa's version, re-allowing containers rebuilds when uncached, essencial for new runs. 2. VKMS Driver Testing, together with the -skips.txt and -fails.txt list that were found during the tests. See pipeline https://gitlab.freedesktop.org/helen.fornazier/linux/-/pipelines/992263 (there is a vgem job on top but it shouldn't affect the result) v2: - mesauprev: point to upstream mesa/mesa (solved the TODO and removed RFC tag) - vkms jov: do not mv modules to /lib/modules in the job definition, leave it to crosvm-runner.sh Helen Koike (2): drm/ci: uprev mesa version - fix container build drm/ci: add tests on vkms MAINTAINERS | 1 + drivers/gpu/drm/ci/build.sh | 1 - drivers/gpu/drm/ci/gitlab-ci.yml | 16 +- drivers/gpu/drm/ci/igt_runner.sh | 6 ++-- drivers/gpu/drm/ci/image-tags.yml | 2 +- drivers/gpu/drm/ci/lava-submit.sh | 2 +- drivers/gpu/drm/ci/test.yml | 23 ++- drivers/gpu/drm/ci/x86_64.config | 1 + .../drm/ci/xfails/virtio_gpu-none-flakes.txt | 0 drivers/gpu/drm/ci/xfails/vkms-none-fails.txt | 29 +++ drivers/gpu/drm/ci/xfails/vkms-none-skips.txt | 10 +++ 11 files changed, 83 insertions(+), 8 deletions(-) delete mode 100644 drivers/gpu/drm/ci/xfails/virtio_gpu-none-flakes.txt create mode 100644 drivers/gpu/drm/ci/xfails/vkms-none-fails.txt create mode 100644 drivers/gpu/drm/ci/xfails/vkms-none-skips.txt -- 2.34.1
[PATCH v2 1/2] drm/ci: uprev mesa version - fix container build
When building containers, some rust packages were installed without
locking the dependencies version, which got updated and started giving
errors like:
error: failed to compile `bindgen-cli v0.62.0`, intermediate artifacts can be
found at `/tmp/cargo-installkNKRwf`
Caused by:
package `rustix v0.38.13` cannot be built because it requires rustc 1.63 or
newer, while the currently active rustc version is 1.60.0
A patch to Mesa was recently added fixing this error, so update it.
Signed-off-by: Helen Koike
---
v2:
- point to upstream mesa/mesa (solved the TODO and removed RFC tag)
---
drivers/gpu/drm/ci/gitlab-ci.yml | 15 ++-
drivers/gpu/drm/ci/lava-submit.sh | 2 +-
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml b/drivers/gpu/drm/ci/gitlab-ci.yml
index 2c4df53f5dfe..522f83db1a07 100644
--- a/drivers/gpu/drm/ci/gitlab-ci.yml
+++ b/drivers/gpu/drm/ci/gitlab-ci.yml
@@ -1,6 +1,6 @@
variables:
DRM_CI_PROJECT_PATH: &drm-ci-project-path mesa/mesa
- DRM_CI_COMMIT_SHA: &drm-ci-commit-sha
0dc961645c4f0241f8512cb0ec3ad59635842072
+ DRM_CI_COMMIT_SHA: &drm-ci-commit-sha
1cdc4be14b66108ae0e8069686ac3efe52bef3cb
UPSTREAM_REPO: git://anongit.freedesktop.org/drm/drm
TARGET_BRANCH: drm-next
@@ -24,6 +24,8 @@ variables:
PIPELINE_ARTIFACTS_BASE:
${S3_HOST}/artifacts/${CI_PROJECT_PATH}/${CI_PIPELINE_ID}
# per-job artifact storage on MinIO
JOB_ARTIFACTS_BASE: ${PIPELINE_ARTIFACTS_BASE}/${CI_JOB_ID}
+ # default kernel for rootfs before injecting the current kernel tree
+ KERNEL_IMAGE_BASE:
https://${S3_HOST}/mesa-lava/gfx-ci/linux/v6.4.12-for-mesa-ci-f6b4ad45f48d
LAVA_JOB_PRIORITY: 30
@@ -86,6 +88,17 @@ include:
- '/.gitlab-ci/container/gitlab-ci.yml'
- '/.gitlab-ci/test/gitlab-ci.yml'
- '/.gitlab-ci/lava/lava-gitlab-ci.yml'
+ - '/src/microsoft/ci/gitlab-ci-inc.yml'
+ - '/src/gallium/drivers/zink/ci/gitlab-ci-inc.yml'
+ - '/src/gallium/drivers/crocus/ci/gitlab-ci-inc.yml'
+ - '/src/gallium/drivers/softpipe/ci/gitlab-ci-inc.yml'
+ - '/src/gallium/drivers/llvmpipe/ci/gitlab-ci-inc.yml'
+ - '/src/gallium/drivers/virgl/ci/gitlab-ci-inc.yml'
+ - '/src/gallium/drivers/nouveau/ci/gitlab-ci-inc.yml'
+ - '/src/gallium/frontends/lavapipe/ci/gitlab-ci-inc.yml'
+ - '/src/intel/ci/gitlab-ci-inc.yml'
+ - '/src/freedreno/ci/gitlab-ci-inc.yml'
+ - '/src/amd/ci/gitlab-ci-inc.yml'
- drivers/gpu/drm/ci/image-tags.yml
- drivers/gpu/drm/ci/container.yml
- drivers/gpu/drm/ci/static-checks.yml
diff --git a/drivers/gpu/drm/ci/lava-submit.sh
b/drivers/gpu/drm/ci/lava-submit.sh
index 0c4456b21b0f..379f26ea87cc 100755
--- a/drivers/gpu/drm/ci/lava-submit.sh
+++ b/drivers/gpu/drm/ci/lava-submit.sh
@@ -22,7 +22,7 @@ cp "$SCRIPTS_DIR"/setup-test-env.sh
results/job-rootfs-overlay/
# Prepare env vars for upload.
section_start variables "Variables passed through:"
-KERNEL_IMAGE_BASE_URL="https://${BASE_SYSTEM_HOST_PATH}"; \
+KERNEL_IMAGE_BASE="https://${BASE_SYSTEM_HOST_PATH}"; \
artifacts/ci-common/generate-env.sh | tee
results/job-rootfs-overlay/set-job-env-vars.sh
section_end variables
--
2.34.1
[PATCH v2 2/2] drm/ci: add tests on vkms
Add job that runs igt on top of vkms.
Signed-off-by: Helen Koike
---
See pipeline:
https://gitlab.freedesktop.org/helen.fornazier/linux/-/pipelines/990494
v2:
- do not mv modules to /lib/modules in the job definition, leave it to
crosvm-runner.sh
---
MAINTAINERS | 1 +
drivers/gpu/drm/ci/build.sh | 1 -
drivers/gpu/drm/ci/gitlab-ci.yml | 1 +
drivers/gpu/drm/ci/igt_runner.sh | 6 ++--
drivers/gpu/drm/ci/image-tags.yml | 2 +-
drivers/gpu/drm/ci/test.yml | 23 ++-
drivers/gpu/drm/ci/x86_64.config | 1 +
.../drm/ci/xfails/virtio_gpu-none-flakes.txt | 0
drivers/gpu/drm/ci/xfails/vkms-none-fails.txt | 29 +++
drivers/gpu/drm/ci/xfails/vkms-none-skips.txt | 10 +++
10 files changed, 68 insertions(+), 6 deletions(-)
delete mode 100644 drivers/gpu/drm/ci/xfails/virtio_gpu-none-flakes.txt
create mode 100644 drivers/gpu/drm/ci/xfails/vkms-none-fails.txt
create mode 100644 drivers/gpu/drm/ci/xfails/vkms-none-skips.txt
diff --git a/MAINTAINERS b/MAINTAINERS
index 740a2ce2689c..e47dbe31d221 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6813,6 +6813,7 @@ L:dri-devel@lists.freedesktop.org
S: Maintained
T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/gpu/vkms.rst
+F: drivers/gpu/drm/ci/xfails/vkms*
F: drivers/gpu/drm/vkms/
DRM DRIVER FOR VIRTUALBOX VIRTUAL GPU
diff --git a/drivers/gpu/drm/ci/build.sh b/drivers/gpu/drm/ci/build.sh
index 7b014287a041..9e510e77098b 100644
--- a/drivers/gpu/drm/ci/build.sh
+++ b/drivers/gpu/drm/ci/build.sh
@@ -146,7 +146,6 @@ fi
mkdir -p artifacts/install/lib
mv install/* artifacts/install/.
-rm -rf artifacts/install/modules
ln -s common artifacts/install/ci-common
for image in ${KERNEL_IMAGE_NAME}; do
diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml b/drivers/gpu/drm/ci/gitlab-ci.yml
index 522f83db1a07..c86ee5a51012 100644
--- a/drivers/gpu/drm/ci/gitlab-ci.yml
+++ b/drivers/gpu/drm/ci/gitlab-ci.yml
@@ -120,6 +120,7 @@ stages:
- rockchip
- virtio-gpu
- lint
+ - software-driver
# YAML anchors for rule conditions
#
diff --git a/drivers/gpu/drm/ci/igt_runner.sh b/drivers/gpu/drm/ci/igt_runner.sh
index 2bb759165063..c7f83d1b72e9 100755
--- a/drivers/gpu/drm/ci/igt_runner.sh
+++ b/drivers/gpu/drm/ci/igt_runner.sh
@@ -21,9 +21,9 @@ cat /sys/kernel/debug/dri/*/state
set -e
# Cannot use HWCI_KERNEL_MODULES as at that point we don't have the module in
/lib
-if [ "$IGT_FORCE_DRIVER" = "amdgpu" ]; then
-mv /install/modules/lib/modules/* /lib/modules/.
-modprobe amdgpu
+if [ "$IGT_FORCE_DRIVER" = "amdgpu" || "$IGT_FORCE_DRIVER" = "vkms" ]; then
+mv /install/modules/lib/modules/* /lib/modules/. || true
+modprobe --first-time "$IGT_FORCE_DRIVER"
fi
if [ -e "/install/xfails/$DRIVER_NAME-$GPU_VERSION-skips.txt" ]; then
diff --git a/drivers/gpu/drm/ci/image-tags.yml
b/drivers/gpu/drm/ci/image-tags.yml
index f051b6c547c5..e05077ee29d2 100644
--- a/drivers/gpu/drm/ci/image-tags.yml
+++ b/drivers/gpu/drm/ci/image-tags.yml
@@ -4,7 +4,7 @@ variables:
DEBIAN_BASE_TAG: "${CONTAINER_TAG}"
DEBIAN_X86_64_BUILD_IMAGE_PATH: "debian/x86_64_build"
- DEBIAN_BUILD_TAG: "${CONTAINER_TAG}"
+ DEBIAN_BUILD_TAG: "2023-09-20-vkms-module-2"
KERNEL_ROOTFS_TAG: "${CONTAINER_TAG}"
diff --git a/drivers/gpu/drm/ci/test.yml b/drivers/gpu/drm/ci/test.yml
index 6473cddaa7a9..69a5337fd989 100644
--- a/drivers/gpu/drm/ci/test.yml
+++ b/drivers/gpu/drm/ci/test.yml
@@ -332,4 +332,25 @@ virtio_gpu:none:
- igt:x86_64
rules:
# TODO: current issue: malloc(): corrupted top size. Fix and remove this
rule.
-- when: never
\ No newline at end of file
+- when: never
+
+vkms:none:
+ stage: software-driver
+ variables:
+DRIVER_NAME: vkms
+GPU_VERSION: none
+ extends:
+- .test-gl
+ tags:
+- kvm
+ script:
+- ln -sf $CI_PROJECT_DIR/install /install
+- mv install/bzImage /lava-files/bzImage
+- mkdir -p /lib/modules
+- mkdir -p $CI_PROJECT_DIR/results
+- ln -sf $CI_PROJECT_DIR/results /results
+- ./install/crosvm-runner.sh ./install/igt_runner.sh
+ needs:
+- debian/x86_64_test-gl
+- testing:x86_64
+- igt:x86_64
\ No newline at end of file
diff --git a/drivers/gpu/drm/ci/x86_64.config b/drivers/gpu/drm/ci/x86_64.config
index 1cbd49a5b23a..8eaba388b141 100644
--- a/drivers/gpu/drm/ci/x86_64.config
+++ b/drivers/gpu/drm/ci/x86_64.config
@@ -24,6 +24,7 @@ CONFIG_DRM=y
CONFIG_DRM_PANEL_SIMPLE=y
CONFIG_PWM_CROS_EC=y
CONFIG_BACKLIGHT_PWM=y
+CONFIG_DRM_VKMS=m
# Strip out some stuff we don't need for graphics testing, to reduce
# the build.
diff --git a/drivers/gpu/drm/ci/xfails/virtio_gpu-none-flakes.txt
b/drivers/gpu/drm/ci/xfails/virtio_gpu-none-flakes.txt
deleted file mode 100644
index e69de29bb2d1..
diff --git a/drivers/gpu/drm/ci/xfails/vk
[PATCH 1/9] drm/amd/pm: Annotate struct smu10_voltage_dependency_table with __counted_by
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct
smu10_voltage_dependency_table.
[1]
https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Cc: Evan Quan
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Xiaojian Du
Cc: Huang Rui
Cc: Kevin Wang
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Kees Cook
---
drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.h
b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.h
index 808e0ecbe1f0..42adc2a3dcbc 100644
--- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.h
+++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.h
@@ -192,7 +192,7 @@ struct smu10_clock_voltage_dependency_record {
struct smu10_voltage_dependency_table {
uint32_t count;
- struct smu10_clock_voltage_dependency_record entries[];
+ struct smu10_clock_voltage_dependency_record entries[]
__counted_by(count);
};
struct smu10_clock_voltage_information {
--
2.34.1
[PATCH 0/9] drm: Annotate structs with __counted_by
Hi, This is a batch of patches touching drm for preparing for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by to structs that would benefit from the annotation. Since the element count member must be set before accessing the annotated flexible array member, some patches also move the member's initialization earlier. (These are noted in the individual patches.) -Kees [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Kees Cook (9): drm/amd/pm: Annotate struct smu10_voltage_dependency_table with __counted_by drm/amdgpu/discovery: Annotate struct ip_hw_instance with __counted_by drm/i915/selftests: Annotate struct perf_series with __counted_by drm/msm/dpu: Annotate struct dpu_hw_intr with __counted_by drm/nouveau/pm: Annotate struct nvkm_perfdom with __counted_by drm/vc4: Annotate struct vc4_perfmon with __counted_by drm/virtio: Annotate struct virtio_gpu_object_array with __counted_by drm/vmwgfx: Annotate struct vmw_surface_dirty with __counted_by drm/v3d: Annotate struct v3d_perfmon with __counted_by drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c| 2 +- drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.h | 2 +- drivers/gpu/drm/i915/selftests/i915_request.c| 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h| 2 +- drivers/gpu/drm/nouveau/nvkm/engine/pm/priv.h| 2 +- drivers/gpu/drm/v3d/v3d_drv.h| 2 +- drivers/gpu/drm/vc4/vc4_drv.h| 2 +- drivers/gpu/drm/virtio/virtgpu_drv.h | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 2 +- 9 files changed, 9 insertions(+), 9 deletions(-) -- 2.34.1
[PATCH 3/9] drm/i915/selftests: Annotate struct perf_series with __counted_by
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct perf_series.
[1]
https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: David Airlie
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: John Harrison
Cc: Andi Shyti
Cc: Matthew Brost
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Kees Cook
---
drivers/gpu/drm/i915/selftests/i915_request.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
b/drivers/gpu/drm/i915/selftests/i915_request.c
index a9b79888c193..acae30a04a94 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -1924,7 +1924,7 @@ struct perf_stats {
struct perf_series {
struct drm_i915_private *i915;
unsigned int nengines;
- struct intel_context *ce[];
+ struct intel_context *ce[] __counted_by(nengines);
};
static int cmp_u32(const void *A, const void *B)
--
2.34.1
[PATCH 4/9] drm/msm/dpu: Annotate struct dpu_hw_intr with __counted_by
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct dpu_hw_intr.
[1]
https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Sean Paul
Cc: Marijn Suijten
Cc: David Airlie
Cc: Daniel Vetter
Cc: Bjorn Andersson
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Kees Cook
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h
index dab761e54863..50cf9523d367 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h
@@ -61,7 +61,7 @@ struct dpu_hw_intr {
void (*cb)(void *arg, int irq_idx);
void *arg;
atomic_t count;
- } irq_tbl[];
+ } irq_tbl[] __counted_by(total_irqs);
};
/**
--
2.34.1
[PATCH 7/9] drm/virtio: Annotate struct virtio_gpu_object_array with __counted_by
Prepare for the coming implementation by GCC and Clang of the __counted_by
attribute. Flexible array members annotated with __counted_by can have
their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
(for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family
functions).
As found with Coccinelle[1], add __counted_by for struct
virtio_gpu_object_array.
[1]
https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci
Cc: David Airlie
Cc: Gerd Hoffmann
Cc: Gurchetan Singh
Cc: Chia-I Wu
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Kees Cook
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 8513b671f871..96365a772f77 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -119,7 +119,7 @@ struct virtio_gpu_object_array {
struct ww_acquire_ctx ticket;
struct list_head next;
u32 nents, total;
- struct drm_gem_object *objs[];
+ struct drm_gem_object *objs[] __counted_by(total);
};
struct virtio_gpu_vbuffer;
--
2.34.1
