dri-devel May 2022

dri-devel@lists.freedesktop.org

344 participants
736 discussions

[Bug 172421] New: radeon: allow to set the TMDS frequency by a special kernel parameter
by bugzilla-daemon＠bugzilla.kernel.org 19 Jun '22

19 Jun '22

https://bugzilla.kernel.org/show_bug.cgi?id=172421 Bug ID: 172421 Summary: radeon: allow to set the TMDS frequency by a special kernel parameter Product: Drivers Version: 2.5 Kernel Version: 4.8.0-rc7+ Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: enhancement Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: estellnb(a)elstel.org Regression: No Despite different claims by ATI in 2016 Radeon R5 230 graphics cards featuring HDMI, DVI and VGA had originally been sold as 4K-ready up to the year 2015. The only prove I have for this is a comercial invoice from Nexus Mobile and a packaging card. As far as I know Radeon R5 230 cards currently sold can still be run stable and reliable under UltraHD provided that you apply the right kernel patch (see for the attachement). Unfortunately neither my former merchant nor ATI have responded about my questions concerning this change in trade and marketing policy. My request would now be to integrate the provided patch into the mainline kernel. It does not change the behaviour of the radeon driver unless you specify a nonzero value for the radeon.hdmimhz parameter. If you do I have tested the R5 230 cards I have to run stable and reliably for days. At least the 2GB variant of this card has largely sufficient resources for proficient desktop computing under UltraHD including image manipulation in 3840x2160. While never officially discussed for the radeon driver nouveau is already implementing a similar parameter called nouveau.hdmimhz since kernel 4.5.x. Though it thereby becomes possible to specify a hdmimhz that is far above the cards technical possibilties the nouveau developers I have talked with say that it would rarely be possible to damage any card by overcloking the TMDS. In deed I have successfully been overclocking my GeForce 9600M GT to feature 4K/2160p. Even specifying values considerable higher than 225MHz did not damage my GeForce 9600M GT though the screen stayed black upon the nouveau driver initialization. While the Radeon R5 230 works well at 297MHz (as long as you specify that via radeon.hdmimhz) I have similarly to the GeForce 9600M GT tried to overclock a Radeon R7 240. It did produce stable images at a higher hdmimhz like 330 though the HDMI input of my monitor features no more than 30Hz at 3840x2160 (tested with or without a DP-adapter). While it remains questionable if the provided patch can improve things for newer Radeon cards I would believe it to be beneficial for some elder cards. At least it is known to be beneficial for the R5 230 initially marketed as 4K-ready. The according radeon patch provided with this report has so far already been accepted by the Mageia 6 distribution. Though the attached patch is for application at the current 4.8.0-rcX+ kernels most of my machines that rely on it still run with 4.6.0. -- You are receiving this mail because: You are watching the assignee of the bug.

2 23

[PATCH] drm: hisilicon: depends on MMU
by Randy Dunlap 19 Jun '22

19 Jun '22

Prevent a kconfig warning when MMU is not enabled by making DRM_HISI_HIBMC depend on MMU. WARNING: unmet direct dependencies detected for DRM_TTM Depends on [n]: HAS_IOMEM [=y] && DRM [=m] && MMU [=n] Selected by [m]: - DRM_TTM_HELPER [=m] && HAS_IOMEM [=y] && DRM [=m] - DRM_HISI_HIBMC [=m] && HAS_IOMEM [=y] && DRM [=m] && PCI [=y] && (ARM64 || COMPILE_TEST [=y]) Fixes: 4f7f1973b0c8 ("drm/vram: fix Kconfig") Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Cc: Gerd Hoffmann <kraxel(a)redhat.com> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Xinliang Liu <xinliang.liu(a)linaro.org> Cc: Tian Tao <tiantao6(a)hisilicon.com> Cc: John Stultz <jstultz(a)google.com> Cc: Xinwei Kong <kong.kongxinwei(a)hisilicon.com> Cc: Chen Feng <puck.chen(a)hisilicon.com> Cc: Christian Koenig <christian.koenig(a)amd.com> Cc: Huang Rui <ray.huang(a)amd.com> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> --- drivers/gpu/drm/hisilicon/hibmc/Kconfig | 1 + 1 file changed, 1 insertion(+) --- a/drivers/gpu/drm/hisilicon/hibmc/Kconfig +++ b/drivers/gpu/drm/hisilicon/hibmc/Kconfig @@ -2,6 +2,7 @@ config DRM_HISI_HIBMC tristate "DRM Support for Hisilicon Hibmc" depends on DRM && PCI && (ARM64 || COMPILE_TEST) + depends on MMU select DRM_KMS_HELPER select DRM_VRAM_HELPER select DRM_TTM

2 2

[PATCH 1/2] drm/mediatek: Config orientation property if panel provides it
by Hsin-Yi Wang 17 Jun '22

17 Jun '22

Panel orientation property should be set before drm_dev_register(). Mediatek drm driver calls drm_dev_register() in .bind(). However, most panels sets orientation property relatively late, mostly in .get_modes() callback, since this is when they are able to get the connector and binds the orientation property to it, though the value should be known when the panel is probed. Let the drm driver check if the remote end point is a panel and if it contains the orientation property. If it does, set it before drm_dev_register() is called. Signed-off-by: Hsin-Yi Wang <hsinyi(a)chromium.org> --- This patch is to solve the same problem as [1] [1] https://patchwork.kernel.org/project/linux-mediatek/patch/20220530081910.39… --- drivers/gpu/drm/mediatek/mtk_dsi.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c index d9f10a33e6fa..091107f97ccc 100644 --- a/drivers/gpu/drm/mediatek/mtk_dsi.c +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c @@ -198,6 +198,7 @@ struct mtk_dsi { unsigned long mode_flags; enum mipi_dsi_pixel_format format; + enum drm_panel_orientation orientation; unsigned int lanes; struct videomode vm; struct mtk_phy_timing phy_timing; @@ -822,6 +823,10 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi) ret = PTR_ERR(dsi->connector); goto err_cleanup_encoder; } + + if (dsi->orientation != DRM_MODE_PANEL_ORIENTATION_UNKNOWN) + drm_connector_set_panel_orientation(dsi->connector, dsi->orientation); + drm_connector_attach_encoder(dsi->connector, &dsi->encoder); return 0; @@ -836,6 +841,14 @@ static int mtk_dsi_bind(struct device *dev, struct device *master, void *data) int ret; struct drm_device *drm = data; struct mtk_dsi *dsi = dev_get_drvdata(dev); + struct drm_panel *panel; + + /* Read panel orientation if existed */ + dsi->orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN; + ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0, &panel, NULL); + if (!ret && panel && panel->dev) { + of_drm_get_panel_orientation(panel->dev->of_node, &dsi->orientation); + } ret = mtk_dsi_encoder_init(drm, dsi); if (ret) -- 2.36.1.124.g0e6072fb45-goog

2 4

[PATCH 1/7] dt-bindings: display: mediatek: dpi: add power-domains property
by Fabien Parent 17 Jun '22

17 Jun '22

DPI is part of the display / multimedia block in MediaTek SoCs, and always have a power-domain (at least in the upstream device-trees). Add the power-domains property to the binding documentation. Signed-off-by: Fabien Parent <fparent(a)baylibre.com> --- .../devicetree/bindings/display/mediatek/mediatek,dpi.yaml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml index 77ee1b923991..caf4c88708f4 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml @@ -57,6 +57,9 @@ properties: Output port node. This port should be connected to the input port of an attached HDMI or LVDS encoder chip. + power-domains: + maxItems: 1 + required: - compatible - reg @@ -64,6 +67,7 @@ required: - clocks - clock-names - port + - power-domains additionalProperties: false @@ -71,11 +75,13 @@ examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/clock/mt8173-clk.h> + #include <dt-bindings/power/mt8183-power.h> dpi0: dpi@1401d000 { compatible = "mediatek,mt8173-dpi"; reg = <0x1401d000 0x1000>; interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&spm MT8173_POWER_DOMAIN_MM>; clocks = <&mmsys CLK_MM_DPI_PIXEL>, <&mmsys CLK_MM_DPI_ENGINE>, <&apmixedsys CLK_APMIXED_TVDPLL>; -- 2.36.1

5 17

[PATCH] drm/i915: Improve on suspend / resume time with VT-d enabled
by Thomas Hellström 17 Jun '22

17 Jun '22

When DMAR / VT-d is enabled, the display engine uses overfetching, presumably to deal with the increased latency. To avoid display engine errors and DMAR faults, as a workaround the GGTT is populated with scatch PTEs when VT-d is enabled. However starting with gen10, Write-combined writing of scratch PTES is no longer possible and as a result, populating the full GGTT with scratch PTEs like on resume becomes very slow as uncached access is needed. Therefore, on integrated GPUs utilize the fact that the PTEs are stored in stolen memory which retain content across S3 suspend. Don't clear the PTEs on suspend and resume. This improves on resume time with around 100 ms. While 100+ms might appear like a short time it's 10% to 20% of total resume time and important in some applications. One notable exception is Intel Rapid Start Technology which may cause stolen memory to be lost across what the OS percieves as S3 suspend. If IRST is enabled or if we can't detect whether IRST is enabled, retain the old workaround, clearing and re-instating PTEs. As an additional measure, if we detect that the last ggtt pte was lost during suspend, print a warning and re-populate the GGTT ptes On discrete GPUs, the display engine scans out from LMEM which isn't subject to DMAR, and presumably the workaround is therefore not needed, but that needs to be verified and disabling the workaround for dGPU, if possible, will be deferred to a follow-up patch. v2: - Rely on retained ptes to also speed up suspend and resume re-binding. - Re-build GGTT ptes if Intel rst is enabled. v3: - Re-build GGTT ptes also if we can't detect whether Intel rst is enabled, and if the guard page PTE and end of GGTT was lost. Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> --- drivers/gpu/drm/i915/gt/intel_ggtt.c | 56 +++++++++++++++++++++++++--- drivers/gpu/drm/i915/gt/intel_gtt.h | 20 ++++++++++ drivers/gpu/drm/i915/i915_driver.c | 16 ++++++++ 3 files changed, 86 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c b/drivers/gpu/drm/i915/gt/intel_ggtt.c index 04191fe2ee34..98441b1c1b75 100644 --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c @@ -23,6 +23,13 @@ #include "intel_gtt.h" #include "gen8_ppgtt.h" +static inline bool suspend_retains_ptes(struct i915_address_space *vm) +{ + return GRAPHICS_VER(vm->i915) >= 8 && + !HAS_LMEM(vm->i915) && + vm->is_ggtt; +} + static void i915_ggtt_color_adjust(const struct drm_mm_node *node, unsigned long color, u64 *start, @@ -116,6 +123,23 @@ static bool needs_idle_maps(struct drm_i915_private *i915) return false; } +/* + * Return the value of the last GGTT pte cast to an u64, if + * the system is supposed to retain ptes across resume. 0 otherwise. + */ +static u64 read_last_pte(struct i915_address_space *vm) +{ + struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm); + gen8_pte_t __iomem *ptep; + + if (!suspend_retains_ptes(vm)) + return 0; + + GEM_BUG_ON(GRAPHICS_VER(vm->i915) < 8); + ptep = (typeof(ptep))ggtt->gsm + (ggtt_total_entries(ggtt) - 1); + return readq(ptep); +} + /** * i915_ggtt_suspend_vm - Suspend the memory mappings for a GGTT or DPT VM * @vm: The VM to suspend the mappings for @@ -179,7 +203,10 @@ void i915_ggtt_suspend_vm(struct i915_address_space *vm) i915_gem_object_unlock(obj); } - vm->clear_range(vm, 0, vm->total); + if (!suspend_retains_ptes(vm)) + vm->clear_range(vm, 0, vm->total); + else + i915_vm_to_ggtt(vm)->probed_pte = read_last_pte(vm); vm->skip_pte_rewrite = save_skip_rewrite; @@ -578,6 +605,8 @@ static int init_ggtt(struct i915_ggtt *ggtt) struct drm_mm_node *entry; int ret; + ggtt->pte_lost = true; + /* * GuC requires all resources that we're sharing with it to be placed in * non-WOPCM memory. If GuC is not present or not in use we still need a @@ -1309,11 +1338,20 @@ bool i915_ggtt_resume_vm(struct i915_address_space *vm) { struct i915_vma *vma; bool write_domain_objs = false; + bool retained_ptes; drm_WARN_ON(&vm->i915->drm, !vm->is_ggtt && !vm->is_dpt); - /* First fill our portion of the GTT with scratch pages */ - vm->clear_range(vm, 0, vm->total); + /* + * First fill our portion of the GTT with scratch pages if + * they were not retained across suspend. + */ + retained_ptes = suspend_retains_ptes(vm) && + !i915_vm_to_ggtt(vm)->pte_lost && + !GEM_WARN_ON(i915_vm_to_ggtt(vm)->probed_pte != read_last_pte(vm)); + + if (!retained_ptes) + vm->clear_range(vm, 0, vm->total); /* clflush objects bound into the GGTT and rebind them. */ list_for_each_entry(vma, &vm->bound_list, vm_link) { @@ -1322,9 +1360,10 @@ bool i915_ggtt_resume_vm(struct i915_address_space *vm) atomic_read(&vma->flags) & I915_VMA_BIND_MASK; GEM_BUG_ON(!was_bound); - vma->ops->bind_vma(vm, NULL, vma->resource, - obj ? obj->cache_level : 0, - was_bound); + if (!retained_ptes) + vma->ops->bind_vma(vm, NULL, vma->resource, + obj ? obj->cache_level : 0, + was_bound); if (obj) { /* only used during resume => exclusive access */ write_domain_objs |= fetch_and_zero(&obj->write_domain); obj->read_domains |= I915_GEM_DOMAIN_GTT; @@ -1352,3 +1391,8 @@ void i915_ggtt_resume(struct i915_ggtt *ggtt) intel_ggtt_restore_fences(ggtt); } + +void i915_ggtt_mark_pte_lost(struct drm_i915_private *i915, bool val) +{ + to_gt(i915)->ggtt->pte_lost = val; +} diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h b/drivers/gpu/drm/i915/gt/intel_gtt.h index 4529b5e9f6e6..7561672c4f17 100644 --- a/drivers/gpu/drm/i915/gt/intel_gtt.h +++ b/drivers/gpu/drm/i915/gt/intel_gtt.h @@ -345,6 +345,15 @@ struct i915_ggtt { bool do_idle_maps; + /** + * Whether the system was recently restored from hibernate and + * thus may have lost pte content. + */ + bool pte_lost; + + /** Probed pte value on suspend. Re-checked on resume. */ + u64 probed_pte; + int mtrr; /** Bit 6 swizzling required for X tiling */ @@ -571,6 +580,17 @@ bool i915_ggtt_resume_vm(struct i915_address_space *vm); void i915_ggtt_suspend(struct i915_ggtt *gtt); void i915_ggtt_resume(struct i915_ggtt *ggtt); +/** + * i915_ggtt_mark_pte_lost - Mark ggtt ptes as lost or clear such a marking + * @i915 The device private. + * @val whether the ptes should be marked as lost. + * + * In some cases pte content is retained across suspend, but typically lost + * across hibernate. Typically they should be marked as lost on + * hibernation restore and such marking cleared on suspend. + */ +void i915_ggtt_mark_pte_lost(struct drm_i915_private *i915, bool val); + void fill_page_dma(struct drm_i915_gem_object *p, const u64 val, unsigned int count); diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c index 64e6f76861f9..f50256e4c2d2 100644 --- a/drivers/gpu/drm/i915/i915_driver.c +++ b/drivers/gpu/drm/i915/i915_driver.c @@ -98,6 +98,9 @@ #include "intel_region_ttm.h" #include "vlv_suspend.h" +/* Intel Rapid Start Technology ACPI device name */ +static const char irst_name[] = "INT3392"; + static const struct drm_driver i915_drm_driver; static int i915_get_bridge_dev(struct drm_i915_private *dev_priv) @@ -1425,6 +1428,8 @@ static int i915_pm_suspend(struct device *kdev) return -ENODEV; } + i915_ggtt_mark_pte_lost(i915, false); + if (i915->drm.switch_power_state == DRM_SWITCH_POWER_OFF) return 0; @@ -1477,6 +1482,14 @@ static int i915_pm_resume(struct device *kdev) if (i915->drm.switch_power_state == DRM_SWITCH_POWER_OFF) return 0; + /* + * If IRST is enabled, or if we can't detect whether it's enabled, + * then we must assume we lost the GGTT page table entries, since + * they are not retained if IRST decided to enter S4. + */ + if (!IS_ENABLED(CONFIG_ACPI) || acpi_dev_present(irst_name, NULL, -1)) + i915_ggtt_mark_pte_lost(i915, true); + return i915_drm_resume(&i915->drm); } @@ -1536,6 +1549,9 @@ static int i915_pm_restore_early(struct device *kdev) static int i915_pm_restore(struct device *kdev) { + struct drm_i915_private *i915 = kdev_to_i915(kdev); + + i915_ggtt_mark_pte_lost(i915, true); return i915_pm_resume(kdev); } -- 2.34.1

3 2

[PATCH v2] drm/nouveau/bios: Rename prom_init() and friends functions
by Christophe Leroy 17 Jun '22

17 Jun '22

While working at fixing powerpc headers, I ended up with the following error. drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.c:48:1: error: conflicting types for 'prom_init'; have 'void *(struct nvkm_bios *, const char *)' make[5]: *** [scripts/Makefile.build:288: drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.o] Error 1 powerpc and a few other architectures have a prom_init() global function. One day or another it will conflict with the one in shadowrom.c Those being static, they can easily be renamed. Do it. While at it, also rename the ops structure as 'nvbios_prom' instead of 'nvbios_rom' in order to make it clear that it refers to the NV_PROM device. Signed-off-by: Christophe Leroy <christophe.leroy(a)csgroup.eu> --- v2: using nvbios_prom prefix instead of nvbios_rom. Changed structure name to keep things consistant. drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h | 2 +- drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c | 2 +- .../gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.c | 14 +++++++------- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h index fac1bff1311b..cfa8a0c356dd 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h @@ -19,7 +19,7 @@ struct nvbios_source { int nvbios_extend(struct nvkm_bios *, u32 length); int nvbios_shadow(struct nvkm_bios *); -extern const struct nvbios_source nvbios_rom; +extern const struct nvbios_source nvbios_prom; extern const struct nvbios_source nvbios_ramin; extern const struct nvbios_source nvbios_acpi_fast; extern const struct nvbios_source nvbios_acpi_slow; diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c index 4b571cc6bc70..19188683c8fc 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c @@ -171,7 +171,7 @@ nvbios_shadow(struct nvkm_bios *bios) struct shadow mthds[] = { { 0, &nvbios_of }, { 0, &nvbios_ramin }, - { 0, &nvbios_rom }, + { 0, &nvbios_prom }, { 0, &nvbios_acpi_fast }, { 4, &nvbios_acpi_slow }, { 1, &nvbios_pcirom }, diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.c b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.c index ffa4b395220a..39144ceb117b 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.c @@ -25,7 +25,7 @@ #include <subdev/pci.h> static u32 -prom_read(void *data, u32 offset, u32 length, struct nvkm_bios *bios) +nvbios_prom_read(void *data, u32 offset, u32 length, struct nvkm_bios *bios) { struct nvkm_device *device = data; u32 i; @@ -38,14 +38,14 @@ prom_read(void *data, u32 offset, u32 length, struct nvkm_bios *bios) } static void -prom_fini(void *data) +nvbios_prom_fini(void *data) { struct nvkm_device *device = data; nvkm_pci_rom_shadow(device->pci, true); } static void * -prom_init(struct nvkm_bios *bios, const char *name) +nvbios_prom_init(struct nvkm_bios *bios, const char *name) { struct nvkm_device *device = bios->subdev.device; if (device->card_type == NV_40 && device->chipset >= 0x4c) @@ -55,10 +55,10 @@ prom_init(struct nvkm_bios *bios, const char *name) } const struct nvbios_source -nvbios_rom = { +nvbios_prom = { .name = "PROM", - .init = prom_init, - .fini = prom_fini, - .read = prom_read, + .init = nvbios_prom_init, + .fini = nvbios_prom_fini, + .read = nvbios_prom_read, .rw = false, }; -- 2.35.1

4 6

[PATCH v2] dma-buf: Move sysfs work out of DMA-BUF export path
by T.J. Mercier 17 Jun '22

17 Jun '22

Recently, we noticed an issue where a process went into direct reclaim while holding the kernfs rw semaphore for sysfs in write (exclusive) mode. This caused processes who were doing DMA-BUF exports and releases to go into uninterruptible sleep since they needed to acquire the same semaphore for the DMA-BUF sysfs entry creation/deletion. In order to avoid blocking DMA-BUF export for an indeterminate amount of time while another process is holding the sysfs rw semaphore in exclusive mode, this patch moves the per-buffer sysfs file creation to the default work queue. Note that this can lead to a short-term inaccuracy in the dmabuf sysfs statistics, but this is a tradeoff to prevent the hot path from being blocked. A work_struct is added to dma_buf to achieve this, but as it is unioned with the kobject in the sysfs_entry, dma_buf does not increase in size. Fixes: bdb8d06dfefd ("dmabuf: Add the capability to expose DMA-BUF stats in sysfs") Originally-by: Hridya Valsaraju <hridya(a)google.com> Signed-off-by: T.J. Mercier <tjmercier(a)google.com> --- See the originally submitted patch by Hridya Valsaraju here: https://lkml.org/lkml/2022/1/4/1066 v2 changes: - Defer only sysfs creation instead of creation and teardown per Christian König - Use a work queue instead of a kthread for deferred work per Christian König --- drivers/dma-buf/dma-buf-sysfs-stats.c | 56 ++++++++++++++++++++------- include/linux/dma-buf.h | 14 ++++++- 2 files changed, 54 insertions(+), 16 deletions(-) diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.c b/drivers/dma-buf/dma-buf-sysfs-stats.c index 2bba0babcb62..67b0a298291c 100644 --- a/drivers/dma-buf/dma-buf-sysfs-stats.c +++ b/drivers/dma-buf/dma-buf-sysfs-stats.c @@ -11,6 +11,7 @@ #include <linux/printk.h> #include <linux/slab.h> #include <linux/sysfs.h> +#include <linux/workqueue.h> #include "dma-buf-sysfs-stats.h" @@ -168,10 +169,46 @@ void dma_buf_uninit_sysfs_statistics(void) kset_unregister(dma_buf_stats_kset); } +static void sysfs_add_workfn(struct work_struct *work) +{ + struct dma_buf_sysfs_entry *sysfs_entry = + container_of(work, struct dma_buf_sysfs_entry, sysfs_add_work); + struct dma_buf *dmabuf = sysfs_entry->dmabuf; + + /* + * A dmabuf is ref-counted via its file member. If this handler holds the only + * reference to the dmabuf, there is no need for sysfs kobject creation. This is an + * optimization and a race; when the reference count drops to 1 immediately after + * this check it is not harmful as the sysfs entry will still get cleaned up in + * dma_buf_stats_teardown, which won't get called until the final dmabuf reference + * is released, and that can't happen until the end of this function. + */ + if (file_count(dmabuf->file) > 1) { + /* + * kobject_init_and_add expects kobject to be zero-filled, but we have populated it + * (the sysfs_add_work union member) to trigger this work function. + */ + memset(&dmabuf->sysfs_entry->kobj, 0, sizeof(dmabuf->sysfs_entry->kobj)); + dmabuf->sysfs_entry->kobj.kset = dma_buf_per_buffer_stats_kset; + if (kobject_init_and_add(&dmabuf->sysfs_entry->kobj, &dma_buf_ktype, NULL, + "%lu", file_inode(dmabuf->file)->i_ino)) { + kobject_put(&dmabuf->sysfs_entry->kobj); + dmabuf->sysfs_entry = NULL; + } + } else { + /* + * Free the sysfs_entry and reset the pointer so dma_buf_stats_teardown doesn't + * attempt to operate on it. + */ + kfree(dmabuf->sysfs_entry); + dmabuf->sysfs_entry = NULL; + } + dma_buf_put(dmabuf); +} + int dma_buf_stats_setup(struct dma_buf *dmabuf) { struct dma_buf_sysfs_entry *sysfs_entry; - int ret; if (!dmabuf || !dmabuf->file) return -EINVAL; @@ -181,25 +218,16 @@ int dma_buf_stats_setup(struct dma_buf *dmabuf) return -EINVAL; } - sysfs_entry = kzalloc(sizeof(struct dma_buf_sysfs_entry), GFP_KERNEL); + sysfs_entry = kmalloc(sizeof(struct dma_buf_sysfs_entry), GFP_KERNEL); if (!sysfs_entry) return -ENOMEM; - sysfs_entry->kobj.kset = dma_buf_per_buffer_stats_kset; sysfs_entry->dmabuf = dmabuf; - dmabuf->sysfs_entry = sysfs_entry; - /* create the directory for buffer stats */ - ret = kobject_init_and_add(&sysfs_entry->kobj, &dma_buf_ktype, NULL, - "%lu", file_inode(dmabuf->file)->i_ino); - if (ret) - goto err_sysfs_dmabuf; + INIT_WORK(&dmabuf->sysfs_entry->sysfs_add_work, sysfs_add_workfn); + get_dma_buf(dmabuf); /* This reference will be dropped in sysfs_add_workfn. */ + schedule_work(&dmabuf->sysfs_entry->sysfs_add_work); return 0; - -err_sysfs_dmabuf: - kobject_put(&sysfs_entry->kobj); - dmabuf->sysfs_entry = NULL; - return ret; } diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index 2097760e8e95..0200caa3c515 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -22,6 +22,7 @@ #include <linux/fs.h> #include <linux/dma-fence.h> #include <linux/wait.h> +#include <linux/workqueue.h> struct device; struct dma_buf; @@ -365,7 +366,7 @@ struct dma_buf { */ const char *name; - /** @name_lock: Spinlock to protect name acces for read access. */ + /** @name_lock: Spinlock to protect name access for read access. */ spinlock_t name_lock; /** @@ -441,6 +442,7 @@ struct dma_buf { __poll_t active; } cb_in, cb_out; + #ifdef CONFIG_DMABUF_SYSFS_STATS /** * @sysfs_entry: @@ -449,7 +451,15 @@ struct dma_buf { * `DMA-BUF statistics`_ for the uapi this enables. */ struct dma_buf_sysfs_entry { - struct kobject kobj; + union { + struct kobject kobj; + + /** @sysfs_add_work: + * + * For deferred sysfs kobject creation using a workqueue. + */ + struct work_struct sysfs_add_work; + }; struct dma_buf *dmabuf; } *sysfs_entry; #endif -- 2.36.0.550.gb090851708-goog

5 22

[PATCH] drm/mediatek: fix crtc index computation
by Fabien Parent 17 Jun '22

17 Jun '22

The code always assume that the main path is enabled, which is not always the case. When the main path is not enabled, the CRTC index of the ext path is incorrect which makes the secondary path not usable. Fix the CRTC index calculation. Signed-off-by: Fabien Parent <fparent(a)baylibre.com> --- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 46 +++++++++++++++------ 1 file changed, 34 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c index 5d7504a72b11..6f2abfc608fb 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c @@ -430,25 +430,47 @@ int mtk_ddp_comp_get_id(struct device_node *node, return -EINVAL; } +static bool mtk_drm_comp_is_enabled(struct drm_device *drm, + const enum mtk_ddp_comp_id *path, + unsigned int path_len) +{ + struct mtk_drm_private *priv = drm->dev_private; + + return path && path_len && !!priv->comp_node[path[path_len - 1]]; +} + unsigned int mtk_drm_find_possible_crtc_by_comp(struct drm_device *drm, struct device *dev) { struct mtk_drm_private *private = drm->dev_private; - unsigned int ret = 0; + unsigned int index = 0; - if (mtk_drm_find_comp_in_ddp(dev, private->data->main_path, private->data->main_len, + if (mtk_drm_find_comp_in_ddp(dev, private->data->main_path, + private->data->main_len, private->ddp_comp)) - ret = BIT(0); - else if (mtk_drm_find_comp_in_ddp(dev, private->data->ext_path, - private->data->ext_len, private->ddp_comp)) - ret = BIT(1); - else if (mtk_drm_find_comp_in_ddp(dev, private->data->third_path, - private->data->third_len, private->ddp_comp)) - ret = BIT(2); - else - DRM_INFO("Failed to find comp in ddp table\n"); + return BIT(index); + + if (mtk_drm_comp_is_enabled(drm, private->data->main_path, + private->data->main_len)) + index++; - return ret; + if (mtk_drm_find_comp_in_ddp(dev, private->data->ext_path, + private->data->ext_len, + private->ddp_comp)) + return BIT(index); + + if (mtk_drm_comp_is_enabled(drm, private->data->ext_path, + private->data->ext_len)) + index++; + + if (mtk_drm_find_comp_in_ddp(dev, private->data->third_path, + private->data->third_len, + private->ddp_comp)) + return BIT(index); + + DRM_INFO("Failed to find comp in ddp table\n"); + + return 0; } int mtk_ddp_comp_init(struct device_node *node, struct mtk_ddp_comp *comp, -- 2.36.1

2 1

[PATCH 0/2] dt-bindings: List supplies needed for sc7280 eDP
by Douglas Anderson 17 Jun '22

17 Jun '22

While looking through dts changes for sc7280 eDP I found that none of the regulators that were being defined were listed in the bindings. That being said, the current Linux drivers _were_ looking for regulators. This series tries to document the reality to the best of my ability. If someone from Qualcomm has better documentation than I do and wants to correct anything here then I'd be more than happy. For the PHY patch especially I don't have a great way to map what I see in datasheets / schematics to figure out which is the supply for the "phy" and the "pll". Assuming these look OK, I'd expect the PHY patch to land through the PHY tree and the display patch to land through msm-next. I can split the series up if need be--the two patches are just in one series because they have a similar topic--there are no actual dependencies here. Douglas Anderson (2): dt-bindings: msm/dp: List supplies in the bindings dt-bindings: phy: List supplies for qcom,edp-phy .../devicetree/bindings/display/msm/dp-controller.yaml | 6 ++++++ Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml | 6 ++++++ 2 files changed, 12 insertions(+) -- 2.36.0.rc2.479.g8af0fa9b8e-goog

6 13

[PATCH 5/5] drm/nouveau: Fix spelling typo in comments
by 1064094935＠qq.com 16 Jun '22

16 Jun '22

From: pengfuyuan <pengfuyuan(a)kylinos.cn> Fix spelling typo in comments. Reported-by: k2ci <kernel-bot(a)kylinos.cn> Signed-off-by: pengfuyuan <pengfuyuan(a)kylinos.cn> --- drivers/gpu/drm/nouveau/include/nvhw/drf.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/include/nvhw/drf.h b/drivers/gpu/drm/nouveau/include/nvhw/drf.h index bd0fc41446e2..d6969c0e2f29 100644 --- a/drivers/gpu/drm/nouveau/include/nvhw/drf.h +++ b/drivers/gpu/drm/nouveau/include/nvhw/drf.h @@ -190,7 +190,7 @@ #define DRF_MD_(X,_1,_2,_3,_4,_5,_6,_7,_8,_9,_10,IMPL,...) IMPL #define DRF_MD(A...) DRF_MD_(X, ##A, DRF_MD_I, DRF_MD_N)(X, ##A) -/* Helper for testing against field value in aribtrary object */ +/* Helper for testing against field value in arbitrary object */ #define DRF_TV_N(X,e,p,o,d,r, f,cmp,v) \ NVVAL_TEST_X(DRF_RD_X(e, (p), (o), d##_##r ), d##_##r##_##f, cmp, (v)) #define DRF_TV_I(X,e,p,o,d,r,i,f,cmp,v) \ @@ -198,7 +198,7 @@ #define DRF_TV_(X,_1,_2,_3,_4,_5,_6,_7,_8,_9,IMPL,...) IMPL #define DRF_TV(A...) DRF_TV_(X, ##A, DRF_TV_I, DRF_TV_N)(X, ##A) -/* Helper for testing against field definition in aribtrary object */ +/* Helper for testing against field definition in arbitrary object */ #define DRF_TD_N(X,e,p,o,d,r, f,cmp,v) \ NVVAL_TEST_X(DRF_RD_X(e, (p), (o), d##_##r ), d##_##r##_##f, cmp, d##_##r##_##f##_##v) #define DRF_TD_I(X,e,p,o,d,r,i,f,cmp,v) \ -- 2.25.1 No virus found Checked by Hillstone Network AntiVirus

3 3

← Newer
1
2
3
4
5
6
7
...
74
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2022