dri-devel February 2022

dri-devel@lists.freedesktop.org

394 participants
865 discussions

[PATCH v2 00/11] lib/string_helpers: Add a few string helpers
by Lucas De Marchi 01 Feb '22

01 Feb '22

Add some helpers under lib/string_helpers.h so they can be used throughout the kernel. When I started doing this there were 2 other previous attempts I know of, not counting the iterations each of them had: 1) https://lore.kernel.org/all/20191023131308.9420-1-jani.nikula@intel.com/ 2) https://lore.kernel.org/all/20210215142137.64476-1-andriy.shevchenko@linux.… Now there is also the v1 of this same patch series: https://lore.kernel.org/all/20220119072450.2890107-1-lucas.demarchi@intel.c… Going through the comments I tried to find some common ground and justification for what is in here, addressing some of the concerns raised. a. This version should be a drop-in replacement for what is currently in the tree, with no change in behavior or binary size. For binary size what I checked was that the linked objects in the end have the same size (gcc 11). From comments in the previous attempts this seems also the case for earlier compiler versions b. I didn't change the function name to choice_* as suggested by Andrew Morton in 20191023155619.43e0013f0c8c673a5c508c1e(a)linux-foundation.org because other people argumented in favor of shorter names for these simple helpers - if they are long and people simply not use due to that, we failed. However as pointed out in v1 of this patchseries, onoff(), yesno(), enabledisable(), enableddisabled() have some issues: the last 2 are hard to read and for the first 2 it would not be hard to have the symbol to clash with variable names. From comments in v1, most people were in favor (or at least not opposed) to using str_on_off(), str_yes_no(), str_enable_disable() and str_enabled_disabled(). c. Use string_helper.h for these helpers - pulling string.h in the compilations units was one of the concerns and I think re-using this already existing header is better than creating a new string-choice.h d. One alternative to all of this suggested by Christian König (43456ba7-c372-84cc-4949-dcb817188e21(a)amd.com) would be to add a printk format. But besides the comment, he also seemed to like the common function. This brought the argument from others that the simple yesno()/enabledisable() already used in the code (or new renamed version) is easier to remember and use than e.g. %py[DOY] Changes in v2: - Use str_ prefix and separate other words with underscore: it's a little bit longer, but should improve readability - Patches we re-split due to the rename: first patch adds all the new functions, then additional patches try to do one conversion at a time. While doing so, there were some fixes for issues already present along the way - Style suggestions from v1 were adopted In v1 it was suggested to apply this in drm-misc. I will leave this to maintainers to decide: maybe it would be simpler to merge the first patches on drm-intel-next, wait for the back merge and merge the rest through drm-misc - my fear is a big conflict with other work going in drm-intel-next since the bulk of the rename is there. I tried to figure out acks and reviews from v1 and apply them to how the patches are now split. thanks Lucas De Marchi Lucas De Marchi (11): lib/string_helpers: Consolidate string helpers implementation drm/i915: Fix trailing semicolon drm/i915: Use str_yes_no() drm/i915: Use str_enable_disable() drm/i915: Use str_enabled_disabled() drm/i915: Use str_on_off() drm/amd/display: Use str_yes_no() drm/gem: Sort includes alphabetically drm: Convert open-coded yes/no strings to yesno() tomoyo: Use str_yes_no() cxgb4: Use str_yes_no() drivers/gpu/drm/amd/amdgpu/atom.c | 4 +- .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 14 +- drivers/gpu/drm/dp/drm_dp.c | 3 +- drivers/gpu/drm/drm_client_modeset.c | 3 +- drivers/gpu/drm/drm_gem.c | 23 +- drivers/gpu/drm/i915/display/g4x_dp.c | 6 +- .../gpu/drm/i915/display/intel_backlight.c | 3 +- drivers/gpu/drm/i915/display/intel_ddi.c | 4 +- drivers/gpu/drm/i915/display/intel_display.c | 46 ++-- .../drm/i915/display/intel_display_debugfs.c | 74 +++--- .../drm/i915/display/intel_display_power.c | 4 +- .../drm/i915/display/intel_display_trace.h | 9 +- drivers/gpu/drm/i915/display/intel_dp.c | 20 +- drivers/gpu/drm/i915/display/intel_dpll.c | 3 +- drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 7 +- drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 7 +- drivers/gpu/drm/i915/display/intel_fbc.c | 4 +- drivers/gpu/drm/i915/display/intel_fdi.c | 8 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 3 +- drivers/gpu/drm/i915/display/intel_sprite.c | 6 +- drivers/gpu/drm/i915/display/vlv_dsi_pll.c | 3 +- .../gpu/drm/i915/gem/selftests/huge_pages.c | 9 +- .../drm/i915/gem/selftests/i915_gem_context.c | 7 +- drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 3 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 11 +- .../drm/i915/gt/intel_execlists_submission.c | 7 +- drivers/gpu/drm/i915/gt/intel_gt_pm.c | 3 +- drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 52 ++-- drivers/gpu/drm/i915/gt/intel_rc6.c | 5 +- drivers/gpu/drm/i915/gt/intel_reset.c | 3 +- drivers/gpu/drm/i915/gt/intel_rps.c | 13 +- drivers/gpu/drm/i915/gt/intel_sseu.c | 9 +- drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 10 +- drivers/gpu/drm/i915/gt/selftest_timeline.c | 3 +- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 5 +- drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 5 +- drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 6 +- drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 4 +- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 14 +- drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c | 20 +- drivers/gpu/drm/i915/i915_debugfs.c | 17 +- drivers/gpu/drm/i915/i915_driver.c | 4 +- drivers/gpu/drm/i915/i915_gpu_error.c | 9 +- drivers/gpu/drm/i915/i915_params.c | 5 +- drivers/gpu/drm/i915/i915_utils.h | 21 +- drivers/gpu/drm/i915/intel_device_info.c | 8 +- drivers/gpu/drm/i915/intel_dram.c | 10 +- drivers/gpu/drm/i915/intel_pm.c | 14 +- drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 4 +- drivers/gpu/drm/i915/selftests/i915_active.c | 3 +- drivers/gpu/drm/i915/vlv_suspend.c | 3 +- drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c | 5 +- drivers/gpu/drm/radeon/atom.c | 3 +- drivers/gpu/drm/v3d/v3d_debugfs.c | 11 +- drivers/gpu/drm/virtio/virtgpu_debugfs.c | 4 +- .../ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 249 ++++++++++-------- include/linux/string_helpers.h | 20 ++ security/tomoyo/audit.c | 2 +- security/tomoyo/common.c | 19 +- security/tomoyo/common.h | 1 - 60 files changed, 482 insertions(+), 373 deletions(-) -- 2.34.1

5 23

[PATCH v1 0/4] fbtft: Unorphan the driver for maintenance
by Andy Shevchenko 01 Feb '22

01 Feb '22

Since we got a maintainer for fbdev, I would like to unorphan fbtft (with the idea of sending PRs to Helge) and move it out of staging since there is no more clean up work expected and no more drivers either. Thoughts? Andy Shevchenko (4): fbtft: Unorphan the driver fbtft: Move driver out from staging fbtft: Kill outdated documentation fbtft: Replace 'depends on FB_TFT' by 'if FB_TFT ... endif' MAINTAINERS | 6 ++-- drivers/staging/Kconfig | 2 -- drivers/staging/Makefile | 1 - drivers/staging/fbtft/README | 32 ------------------ drivers/staging/fbtft/TODO | 3 -- drivers/video/Kconfig | 1 + drivers/video/Makefile | 1 + drivers/{staging => video}/fbtft/Kconfig | 33 +++---------------- drivers/{staging => video}/fbtft/Makefile | 0 .../{staging => video}/fbtft/fb_agm1264k-fl.c | 0 .../{staging => video}/fbtft/fb_bd663474.c | 0 .../{staging => video}/fbtft/fb_hx8340bn.c | 0 drivers/{staging => video}/fbtft/fb_hx8347d.c | 0 drivers/{staging => video}/fbtft/fb_hx8353d.c | 0 drivers/{staging => video}/fbtft/fb_hx8357d.c | 0 drivers/{staging => video}/fbtft/fb_hx8357d.h | 0 drivers/{staging => video}/fbtft/fb_ili9163.c | 0 drivers/{staging => video}/fbtft/fb_ili9320.c | 0 drivers/{staging => video}/fbtft/fb_ili9325.c | 0 drivers/{staging => video}/fbtft/fb_ili9340.c | 0 drivers/{staging => video}/fbtft/fb_ili9341.c | 0 drivers/{staging => video}/fbtft/fb_ili9481.c | 0 drivers/{staging => video}/fbtft/fb_ili9486.c | 0 drivers/{staging => video}/fbtft/fb_pcd8544.c | 0 drivers/{staging => video}/fbtft/fb_ra8875.c | 0 drivers/{staging => video}/fbtft/fb_s6d02a1.c | 0 drivers/{staging => video}/fbtft/fb_s6d1121.c | 0 drivers/{staging => video}/fbtft/fb_seps525.c | 0 drivers/{staging => video}/fbtft/fb_sh1106.c | 0 drivers/{staging => video}/fbtft/fb_ssd1289.c | 0 drivers/{staging => video}/fbtft/fb_ssd1305.c | 0 drivers/{staging => video}/fbtft/fb_ssd1306.c | 0 drivers/{staging => video}/fbtft/fb_ssd1325.c | 0 drivers/{staging => video}/fbtft/fb_ssd1331.c | 0 drivers/{staging => video}/fbtft/fb_ssd1351.c | 0 drivers/{staging => video}/fbtft/fb_st7735r.c | 0 drivers/{staging => video}/fbtft/fb_st7789v.c | 0 drivers/{staging => video}/fbtft/fb_tinylcd.c | 0 drivers/{staging => video}/fbtft/fb_tls8204.c | 0 drivers/{staging => video}/fbtft/fb_uc1611.c | 0 drivers/{staging => video}/fbtft/fb_uc1701.c | 0 .../{staging => video}/fbtft/fb_upd161704.c | 0 drivers/{staging => video}/fbtft/fbtft-bus.c | 0 drivers/{staging => video}/fbtft/fbtft-core.c | 0 drivers/{staging => video}/fbtft/fbtft-io.c | 0 .../{staging => video}/fbtft/fbtft-sysfs.c | 0 drivers/{staging => video}/fbtft/fbtft.h | 0 drivers/{staging => video}/fbtft/internal.h | 0 48 files changed, 10 insertions(+), 69 deletions(-) delete mode 100644 drivers/staging/fbtft/README delete mode 100644 drivers/staging/fbtft/TODO rename drivers/{staging => video}/fbtft/Kconfig (89%) rename drivers/{staging => video}/fbtft/Makefile (100%) rename drivers/{staging => video}/fbtft/fb_agm1264k-fl.c (100%) rename drivers/{staging => video}/fbtft/fb_bd663474.c (100%) rename drivers/{staging => video}/fbtft/fb_hx8340bn.c (100%) rename drivers/{staging => video}/fbtft/fb_hx8347d.c (100%) rename drivers/{staging => video}/fbtft/fb_hx8353d.c (100%) rename drivers/{staging => video}/fbtft/fb_hx8357d.c (100%) rename drivers/{staging => video}/fbtft/fb_hx8357d.h (100%) rename drivers/{staging => video}/fbtft/fb_ili9163.c (100%) rename drivers/{staging => video}/fbtft/fb_ili9320.c (100%) rename drivers/{staging => video}/fbtft/fb_ili9325.c (100%) rename drivers/{staging => video}/fbtft/fb_ili9340.c (100%) rename drivers/{staging => video}/fbtft/fb_ili9341.c (100%) rename drivers/{staging => video}/fbtft/fb_ili9481.c (100%) rename drivers/{staging => video}/fbtft/fb_ili9486.c (100%) rename drivers/{staging => video}/fbtft/fb_pcd8544.c (100%) rename drivers/{staging => video}/fbtft/fb_ra8875.c (100%) rename drivers/{staging => video}/fbtft/fb_s6d02a1.c (100%) rename drivers/{staging => video}/fbtft/fb_s6d1121.c (100%) rename drivers/{staging => video}/fbtft/fb_seps525.c (100%) rename drivers/{staging => video}/fbtft/fb_sh1106.c (100%) rename drivers/{staging => video}/fbtft/fb_ssd1289.c (100%) rename drivers/{staging => video}/fbtft/fb_ssd1305.c (100%) rename drivers/{staging => video}/fbtft/fb_ssd1306.c (100%) rename drivers/{staging => video}/fbtft/fb_ssd1325.c (100%) rename drivers/{staging => video}/fbtft/fb_ssd1331.c (100%) rename drivers/{staging => video}/fbtft/fb_ssd1351.c (100%) rename drivers/{staging => video}/fbtft/fb_st7735r.c (100%) rename drivers/{staging => video}/fbtft/fb_st7789v.c (100%) rename drivers/{staging => video}/fbtft/fb_tinylcd.c (100%) rename drivers/{staging => video}/fbtft/fb_tls8204.c (100%) rename drivers/{staging => video}/fbtft/fb_uc1611.c (100%) rename drivers/{staging => video}/fbtft/fb_uc1701.c (100%) rename drivers/{staging => video}/fbtft/fb_upd161704.c (100%) rename drivers/{staging => video}/fbtft/fbtft-bus.c (100%) rename drivers/{staging => video}/fbtft/fbtft-core.c (100%) rename drivers/{staging => video}/fbtft/fbtft-io.c (100%) rename drivers/{staging => video}/fbtft/fbtft-sysfs.c (100%) rename drivers/{staging => video}/fbtft/fbtft.h (100%) rename drivers/{staging => video}/fbtft/internal.h (100%) -- 2.34.1

18 86

[PATCH -next 1/2 v2] video: fbdev: pxa168fb: Remove unnecessary print function dev_err()
by Yang Li 01 Feb '22

01 Feb '22

The print function dev_err() is redundant because platform_get_irq() already prints an error. Eliminate the follow coccicheck warning: ./drivers/video/fbdev/pxa168fb.c:621:2-9: line 621 is redundant because platform_get_irq() already prints an error Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Signed-off-by: Yang Li <yang.lee(a)linux.alibaba.com> --- -Change in v2: drop the surrounding braces drivers/video/fbdev/pxa168fb.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/video/fbdev/pxa168fb.c b/drivers/video/fbdev/pxa168fb.c index c25739f6934d..e943300d23e8 100644 --- a/drivers/video/fbdev/pxa168fb.c +++ b/drivers/video/fbdev/pxa168fb.c @@ -617,10 +617,8 @@ static int pxa168fb_probe(struct platform_device *pdev) } irq = platform_get_irq(pdev, 0); - if (irq < 0) { - dev_err(&pdev->dev, "no IRQ defined\n"); + if (irq < 0) return -ENOENT; - } info = framebuffer_alloc(sizeof(struct pxa168fb_info), &pdev->dev); if (info == NULL) { -- 2.20.1.7.g153144c

2 2

kmscube: GLES3/gl3.h: No such file or directory
by Fabio Estevam 01 Feb '22

01 Feb '22

Hi Rob, We are getting the following kmscube build error in Buildroot: ../cube-shadertoy.c:37:10: fatal error: GLES3/gl3.h: No such file or directory 37 | #include <GLES3/gl3.h> Complete log: http://autobuild.buildroot.net/results/7f559e89a96273fc019056eae13104e14161… In OpenEmbedded the following patch is used: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-graphics/k… What would be the appropriate fix for this issue? Thanks, Fabio Estevam

1 0

[PATCH v7 0/5] discrete card 64K page support
by Robert Beckett 01 Feb '22

01 Feb '22

This series continues support for 64K pages for discrete cards. It supersedes the 64K patches from https://patchwork.freedesktop.org/series/95686/#rev4 Changes since that series: - set min alignment for DG2 to 2MB in i915_address_space_init - replace coloring with simpler 2MB VA alignment for lmem buffers - enforce alignment to 2MB for lmem objects on DG2 in i915_vma_insert - expand vma reservation to round up to 2MB on DG2 in i915_vma_insert - add alignment test v2: rebase and fix for async vma that landed v3: * fix uapi doc typos * add needs_compact_pt flag patch * cleanup vma expansion to use vm->min_alignment instead of hard coding v4: * fix err return in igt_ppgtt_compact test * placate ci robot with explicit enum conversion in misaligned_pin * remove some blank lines v5: * fix obj alignment requirements querying for internal buffers that have no memory region associated. (fixes v3 bug) v6: * use NEEDS_COMPACT_PT inead of hard coding in misalignment test * tiled_blits_create correctly pick largest required alignment * minor doc formatting v7: * use i915_vma_unbind_unlocked in misalignment test Reviewed-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Matthew Auld (3): drm/i915: enforce min GTT alignment for discrete cards drm/i915: support 64K GTT pages for discrete cards drm/i915/uapi: document behaviour for DG2 64K support Ramalingam C (1): drm/i915: add needs_compact_pt flag Robert Beckett (1): drm/i915: add gtt misalignment test .../gpu/drm/i915/gem/selftests/huge_pages.c | 60 +++++ .../i915/gem/selftests/i915_gem_client_blt.c | 21 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 108 ++++++++- drivers/gpu/drm/i915/gt/intel_gtt.c | 12 + drivers/gpu/drm/i915/gt/intel_gtt.h | 21 ++ drivers/gpu/drm/i915/gt/intel_ppgtt.c | 1 + drivers/gpu/drm/i915/i915_drv.h | 11 +- drivers/gpu/drm/i915/i915_pci.c | 2 + drivers/gpu/drm/i915/i915_vma.c | 9 + drivers/gpu/drm/i915/intel_device_info.h | 1 + drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 224 +++++++++++++++--- include/uapi/drm/i915_drm.h | 44 +++- 12 files changed, 462 insertions(+), 52 deletions(-) -- 2.25.1

1 5

[PATCH v3] drm/cma-helper: Describe what a "contiguous chunk" actually means
by Daniel Thompson 01 Feb '22

01 Feb '22

Since it's inception in 2012 it has been understood that the DRM GEM CMA helpers do not depend on CMA as the backend allocator. In fact the first bug fix to ensure the cma-helpers work correctly with an IOMMU backend appeared in 2014. However currently the documentation for drm_gem_cma_create() talks about "a contiguous chunk of memory" without making clear which address space it will be a contiguous part of. Additionally the CMA introduction is actively misleading because it only contemplates the CMA backend. This matters because when the device accesses the bus through an IOMMU (and don't use the CMA backend) then the allocated memory is contiguous only in the IOVA space. This is a significant difference compared to the CMA backend and the behaviour can be a surprise even to someone who does a reasonable level of code browsing (but doesn't find all the relevant function pointers ;-) ). Improve the kernel doc comments accordingly. Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org> --- Notes: Changes in v3: - Rebased on v5.17-rc2 - Minor improvements to wording. Changes in v2: - Oops. I did a final proof read and acidentally committed these changes as a seperate patch. This means that v1 contains only one tenth of the actual patch. This is fixed in v2. Many apologies for the noise! drivers/gpu/drm/drm_gem_cma_helper.c | 39 +++++++++++++++++++++------- 1 file changed, 29 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c b/drivers/gpu/drm/drm_gem_cma_helper.c index cefd0cbf9debb..ee003af40ffe6 100644 --- a/drivers/gpu/drm/drm_gem_cma_helper.c +++ b/drivers/gpu/drm/drm_gem_cma_helper.c @@ -26,12 +26,22 @@ /** * DOC: cma helpers * - * The Contiguous Memory Allocator reserves a pool of memory at early boot - * that is used to service requests for large blocks of contiguous memory. + * The DRM GEM/CMA helpers are a means to provide buffer objects that are + * presented to the device as a contiguous chunk of memory. This is useful + * for devices that do not support scatter-gather DMA (either directly or + * by using an intimately attached IOMMU). * - * The DRM GEM/CMA helpers use this allocator as a means to provide buffer - * objects that are physically contiguous in memory. This is useful for - * display drivers that are unable to map scattered buffers via an IOMMU. + * Despite the name, the DRM GEM/CMA helpers are not hardwired to use the + * Contiguous Memory Allocator (CMA). + * + * For devices that access the memory bus through an (external) IOMMU then + * the buffer objects are allocated using a traditional page-based + * allocator and may be scattered through physical memory. However they + * are contiguous in the IOVA space so appear contiguous to devices using + * them. + * + * For other devices then the helpers rely on CMA to provide buffer + * objects that are physically contiguous in memory. * * For GEM callback helpers in struct &drm_gem_object functions, see likewise * named functions with an _object_ infix (e.g., drm_gem_cma_object_vmap() wraps @@ -111,8 +121,14 @@ __drm_gem_cma_create(struct drm_device *drm, size_t size, bool private) * @drm: DRM device * @size: size of the object to allocate * - * This function creates a CMA GEM object and allocates a contiguous chunk of - * memory as backing store. + * This function creates a CMA GEM object and allocates memory as backing store. + * The allocated memory will occupy a contiguous chunk of bus address space. + * + * For devices that are directly connected to the memory bus then the allocated + * memory will be physically contiguous. For devices that access through an + * IOMMU, then the allocated memory is not expected to be physically contiguous + * because having contiguous IOVAs is sufficient to meet a devices DMA + * requirements. * * Returns: * A struct drm_gem_cma_object * on success or an ERR_PTR()-encoded negative @@ -162,9 +178,12 @@ EXPORT_SYMBOL_GPL(drm_gem_cma_create); * @size: size of the object to allocate * @handle: return location for the GEM handle * - * This function creates a CMA GEM object, allocating a physically contiguous - * chunk of memory as backing store. The GEM object is then added to the list - * of object associated with the given file and a handle to it is returned. + * This function creates a CMA GEM object, allocating a chunk of memory as + * backing store. The GEM object is then added to the list of object associated + * with the given file and a handle to it is returned. + * + * The allocated memory will occupy a contiguous chunk of bus address space. + * See drm_gem_cma_create() for more details. * * Returns: * A struct drm_gem_cma_object * on success or an ERR_PTR()-encoded negative base-commit: 26291c54e111ff6ba87a164d85d4a4e134b7315c -- 2.34.1

1 0

[Bug 214801] New: polaris11 (rx560) regression
by bugzilla-daemon＠bugzilla.kernel.org 01 Feb '22

01 Feb '22

https://bugzilla.kernel.org/show_bug.cgi?id=214801 Bug ID: 214801 Summary: polaris11 (rx560) regression Product: Drivers Version: 2.5 Kernel Version: 5.14.14 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: roxmail(a)list.ru Regression: No Created attachment 299307 --> https://bugzilla.kernel.org/attachment.cgi?id=299307&action=edit dmesg After a long using 4.19.122, i am trying to move for a newer kernel (my xhci greatly improved since), currently it is 5.14.14 and there are noticeable slowdown. For a numbers the Unigine Heaven Benchmark 4.0 (linux OpenGL) was used. 4.19.122: FPS: 43.9 Score: 1105 Min FPS: 15.2 Max FPS: 90.7 5.14.14: FPS: 31.4 Score: 790 Min FPS: 22.4 Max FPS: 60.1 And there are flickering artifacts visible while benchmarking with newer kernel. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.

2 1

[PATCH] Revert "drm/panel-edp: Allow querying the detected panel via sysfs"
by Douglas Anderson 01 Feb '22

01 Feb '22

This reverts commit 363c4c3811db330dee9ce27dd3cee6f590d44e4c. Since the point of this attribute is for a test, this should be done in debugfs, not sysfs. Let's revert and a new patch can be added later doing it in debugfs. Signed-off-by: Douglas Anderson <dianders(a)chromium.org> --- drivers/gpu/drm/panel/panel-edp.c | 39 ++++--------------------------- 1 file changed, 5 insertions(+), 34 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/panel-edp.c index 23da4040e263..a394a15dc3fb 100644 --- a/drivers/gpu/drm/panel/panel-edp.c +++ b/drivers/gpu/drm/panel/panel-edp.c @@ -222,8 +222,6 @@ struct panel_edp { struct gpio_desc *enable_gpio; struct gpio_desc *hpd_gpio; - const struct edp_panel_entry *detected_panel; - struct edid *edid; struct drm_display_mode override_mode; @@ -668,6 +666,7 @@ static const struct edp_panel_entry *find_edp_panel(u32 panel_id); static int generic_edp_panel_probe(struct device *dev, struct panel_edp *panel) { + const struct edp_panel_entry *edp_panel; struct panel_desc *desc; u32 panel_id; char vend[4]; @@ -706,14 +705,14 @@ static int generic_edp_panel_probe(struct device *dev, struct panel_edp *panel) } drm_edid_decode_panel_id(panel_id, vend, &product_id); - panel->detected_panel = find_edp_panel(panel_id); + edp_panel = find_edp_panel(panel_id); /* * We're using non-optimized timings and want it really obvious that * someone needs to add an entry to the table, so we'll do a WARN_ON * splat. */ - if (WARN_ON(!panel->detected_panel)) { + if (WARN_ON(!edp_panel)) { dev_warn(dev, "Unknown panel %s %#06x, using conservative timings\n", vend, product_id); @@ -735,14 +734,12 @@ static int generic_edp_panel_probe(struct device *dev, struct panel_edp *panel) */ desc->delay.unprepare = 2000; desc->delay.enable = 200; - - panel->detected_panel = ERR_PTR(-EINVAL); } else { dev_info(dev, "Detected %s %s (%#06x)\n", - vend, panel->detected_panel->name, product_id); + vend, edp_panel->name, product_id); /* Update the delay; everything else comes from EDID */ - desc->delay = *panel->detected_panel->delay; + desc->delay = *edp_panel->delay; } ret = 0; @@ -753,28 +750,6 @@ static int generic_edp_panel_probe(struct device *dev, struct panel_edp *panel) return ret; } -static ssize_t detected_panel_show(struct device *dev, - struct device_attribute *attr, char *buf) -{ - struct panel_edp *p = dev_get_drvdata(dev); - - if (IS_ERR(p->detected_panel)) - return sysfs_emit(buf, "UNKNOWN\n"); - else if (!p->detected_panel) - return sysfs_emit(buf, "HARDCODED\n"); - else - return sysfs_emit(buf, "%s\n", p->detected_panel->name); -} - -static const DEVICE_ATTR_RO(detected_panel); - -static void edp_panel_remove_detected_panel(void *data) -{ - struct panel_edp *p = data; - - device_remove_file(p->base.dev, &dev_attr_detected_panel); -} - static int panel_edp_probe(struct device *dev, const struct panel_desc *desc, struct drm_dp_aux *aux) { @@ -874,10 +849,6 @@ static int panel_edp_probe(struct device *dev, const struct panel_desc *desc, drm_panel_add(&panel->base); - err = device_create_file(dev, &dev_attr_detected_panel); - if (!err) - devm_add_action_or_reset(dev, edp_panel_remove_detected_panel, panel); - return 0; err_finished_pm_runtime: -- 2.35.0.rc2.247.g8bbb082509-goog

2 1

[PATCH] drm/panel-edp: Allow querying the detected panel via sysfs
by Douglas Anderson 01 Feb '22

01 Feb '22

Recently we added generic "edp-panel"s probed by EDID. To support panels in this way we look at the panel ID in the EDID and look up the panel in a table that has power sequence timings. If we find a panel that's not in the table we will still attempt to use it but we'll use conservative timings. While it's likely that these conservative timings will work for most nearly all panels, the performance of turning the panel off and on suffers. We'd like to be able to reliably detect the case that we're using the hardcoded timings without relying on parsing dmesg. This allows us to implement tests that ensure that no devices get shipped that are relying on the conservative timings. Let's add a new sysfs entry to panel devices. It will have one of: * UNKNOWN - We tried to detect a panel but it wasn't in our table. * HARDCODED - We're not using generic "edp-panel" probed by EDID. * A panel name - This is the name of the panel from our table. Signed-off-by: Douglas Anderson <dianders(a)chromium.org> --- drivers/gpu/drm/panel/panel-edp.c | 39 +++++++++++++++++++++++++++---- 1 file changed, 34 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/panel-edp.c index 99ca1bd0091c..719c1bb6c45c 100644 --- a/drivers/gpu/drm/panel/panel-edp.c +++ b/drivers/gpu/drm/panel/panel-edp.c @@ -222,6 +222,8 @@ struct panel_edp { struct gpio_desc *enable_gpio; struct gpio_desc *hpd_gpio; + const struct edp_panel_entry *detected_panel; + struct edid *edid; struct drm_display_mode override_mode; @@ -666,7 +668,6 @@ static const struct edp_panel_entry *find_edp_panel(u32 panel_id); static int generic_edp_panel_probe(struct device *dev, struct panel_edp *panel) { - const struct edp_panel_entry *edp_panel; struct panel_desc *desc; u32 panel_id; char vend[4]; @@ -705,14 +706,14 @@ static int generic_edp_panel_probe(struct device *dev, struct panel_edp *panel) } drm_edid_decode_panel_id(panel_id, vend, &product_id); - edp_panel = find_edp_panel(panel_id); + panel->detected_panel = find_edp_panel(panel_id); /* * We're using non-optimized timings and want it really obvious that * someone needs to add an entry to the table, so we'll do a WARN_ON * splat. */ - if (WARN_ON(!edp_panel)) { + if (WARN_ON(!panel->detected_panel)) { dev_warn(dev, "Unknown panel %s %#06x, using conservative timings\n", vend, product_id); @@ -734,12 +735,14 @@ static int generic_edp_panel_probe(struct device *dev, struct panel_edp *panel) */ desc->delay.unprepare = 2000; desc->delay.enable = 200; + + panel->detected_panel = ERR_PTR(-EINVAL); } else { dev_info(dev, "Detected %s %s (%#06x)\n", - vend, edp_panel->name, product_id); + vend, panel->detected_panel->name, product_id); /* Update the delay; everything else comes from EDID */ - desc->delay = *edp_panel->delay; + desc->delay = *panel->detected_panel->delay; } ret = 0; @@ -750,6 +753,28 @@ static int generic_edp_panel_probe(struct device *dev, struct panel_edp *panel) return ret; } +static ssize_t detected_panel_show(struct device *dev, + struct device_attribute *attr, char *buf) +{ + struct panel_edp *p = dev_get_drvdata(dev); + + if (IS_ERR(p->detected_panel)) + return sysfs_emit(buf, "UNKNOWN\n"); + else if (!p->detected_panel) + return sysfs_emit(buf, "HARDCODED\n"); + else + return sysfs_emit(buf, "%s\n", p->detected_panel->name); +} + +static const DEVICE_ATTR_RO(detected_panel); + +static void edp_panel_remove_detected_panel(void *data) +{ + struct panel_edp *p = data; + + device_remove_file(p->base.dev, &dev_attr_detected_panel); +} + static int panel_edp_probe(struct device *dev, const struct panel_desc *desc, struct drm_dp_aux *aux) { @@ -849,6 +874,10 @@ static int panel_edp_probe(struct device *dev, const struct panel_desc *desc, drm_panel_add(&panel->base); + err = device_create_file(dev, &dev_attr_detected_panel); + if (!err) + devm_add_action_or_reset(dev, edp_panel_remove_detected_panel, panel); + return 0; err_finished_pm_runtime: -- 2.35.0.rc0.227.g00780c9af4-goog

4 6

[PATCH v4 0/3] drm/lsdc: add drm driver for loongson display controller
by Sui Jingfeng 01 Feb '22

01 Feb '22

v4: add dts required and explain why device tree is required. give more description about the code. fix warnings reported by kernel test robot. introduce stride_alignment member into struct lsdc_chip_desc, the stride alignment is 256 bytes for ls7a1000, ls2k1000 and ls2k0500 SoC. But ls7a2000 improve it to 32 bytes. v3: fix more grammar mistakes in Kconfig reported by Randy Dunlap and give more details about lsdc. v2: fixup warnings reported by kernel test robot There is a display controller in loongson's LS2K1000 SoC and LS7A1000 bridge, and the DC in those chip is a PCI device. This display controller have two display pipes but with only one hardware cursor. Each way has a DVO output interface and the CRTC is able to scanout from 1920x1080 resolution at 60Hz. LS2K1000 is a SoC, only system memory is available. Therefore scanout form system memory is the only choice and we prefer the cma helper base solution even through it is possible to use VRAM helper base solution on ls2k1000 by carving out part of system memory as VRAM. The dc in ls7a1000 can scanout from both the system memory and the dedicate VRAM attached to the ddr3 memory controller. Sadly, only scanout from the VRAM is proved to be a reliable solution for massive product. Scanout from the system memory suffer from some hardware deficiency which cause the screen flickering under RAM pressure. This is the reason why we integrate two distict helpers into one piece of device driver. +------+ | DDR4 | +------+ || MC0 +-----------------------+------------+ +----------+ Hyper | LS7A1000 | DDR3 | +------+ | LS3A4000 |<--------->| +--------+ +-------+ | memory |<->| VRAM | | CPU |<--------->| | GC1000 | | LSDC | | controller | +------+ +----------+ Transport | +--------+ +-+---+-+ +------------| || MC1 +---------------|---|----------------+ +------+ | | | DDR4 | +-------+ DVO0 | | DVO1 +------+ +------+ VGA <--|ADV7125|<---------+ +------->|TFP410|--> DVI/HDMI +-------+ +------+ The above picture give a simple usage of LS7A1000, note that the encoder is not necessary adv7125 or tfp410, it is a choice of the downstream board manufacturer. Other candicate encoder can be ch7034b, sil9022 and ite66121 etc. This is the reason why we still need device tree to provide board specific information. Beside, the dc in both ls2k1000 and ls7k1000 have the vendor:device id of 0x0014:0x7a06. even the reverison id is also same. We can't tell it apart simply(this is the firmware engineer's mistake). But firmware already flushed to the board and sold out, so we resolve those issues by using the device tree which already have certain support. Nevertheless, this patch try to provided a minimal support for this display controller which is mainly for graphic environment bring up. Hope that the code can speak for itself. For ls7a1000, there are 4 gpios who register is located at dc register space which is used to emulation i2c. LS2K1000 and LS2K0500 SoC don't have those hardware, they use general purpose gpio or hardware i2c to serve this purpose. For ladc, there is only a 1:1 mapping of encoders and connectors. +-------------------+ _________ | | | | | CRTC0 --> DVO0 ---------> Encoder0 --> Connector0 ---> | Monotor | | | ^ ^ |_________| | | | | | <----- i2c0 ----------------+ | LSDC IP CORE | | <----- i2c1 ----------------+ | | | | _________ | | | | | | | CRTC1 --> DVO1 ---------> Encoder1 --> Connector1 ---> | Panel | | | |_________| +-------------------+ Below is a brief introduction of loongson's CPU, bridge chip and SoC. LS2K1000 is a double core 1.0Ghz mips64r2 compatible SoC[1]. LS7A1000 is a bridge chip made by Loongson corporation which act as north and/or south bridge of loongson's desktop and server level processor. It is equivalent to RS780E or something like that. More details can be read from its user manual[2]. This bridge chip is typically use with LS3A3000, LS3A4000 and LS3A5000 cpu. LS3A3000 is 4 core 1.45gHz mips64r2 compatible cpu. LS3A4000 is 4 core 1.8gHz mips64r5 compatible cpu. LS3A5000 is 4 core 2.5gHz loongarch cpu[3]. [1] https://wiki.debian.org/InstallingDebianOn/Lemote/Loongson2K1000 [2] https://loongson.github.io/LoongArch-Documentation/Loongson-7A1000-usermanu… [3] https://loongson.github.io/LoongArch-Documentation/Loongson-3A5000-usermanu… Signed-off-by: suijingfeng <suijingfeng(a)loongson.cn> Signed-off-by: Sui Jingfeng <15330273260(a)189.cn> suijingfeng (3): drm/lsdc: add drm driver for loongson display controller dt-bingdings: ls2k1000: add the display controller device node dt-bingdings: mips: loongson: introduce board specific dts arch/mips/boot/dts/loongson/lemote_a1901.dts | 64 ++ .../boot/dts/loongson/loongson64-2k1000.dtsi | 11 + .../boot/dts/loongson/ls3a4000_7a1000_evb.dts | 69 ++ arch/mips/boot/dts/loongson/ls7a-pch.dtsi | 2 +- drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/lsdc/Kconfig | 38 + drivers/gpu/drm/lsdc/Makefile | 15 + drivers/gpu/drm/lsdc/lsdc_connector.c | 439 +++++++++ drivers/gpu/drm/lsdc/lsdc_connector.h | 60 ++ drivers/gpu/drm/lsdc/lsdc_crtc.c | 441 +++++++++ drivers/gpu/drm/lsdc/lsdc_drv.c | 838 ++++++++++++++++++ drivers/gpu/drm/lsdc/lsdc_drv.h | 211 +++++ drivers/gpu/drm/lsdc/lsdc_encoder.c | 79 ++ drivers/gpu/drm/lsdc/lsdc_i2c.c | 220 +++++ drivers/gpu/drm/lsdc/lsdc_i2c.h | 61 ++ drivers/gpu/drm/lsdc/lsdc_irq.c | 77 ++ drivers/gpu/drm/lsdc/lsdc_irq.h | 37 + drivers/gpu/drm/lsdc/lsdc_plane.c | 688 ++++++++++++++ drivers/gpu/drm/lsdc/lsdc_pll.c | 613 +++++++++++++ drivers/gpu/drm/lsdc/lsdc_pll.h | 109 +++ drivers/gpu/drm/lsdc/lsdc_regs.h | 246 +++++ 22 files changed, 4320 insertions(+), 1 deletion(-) create mode 100644 arch/mips/boot/dts/loongson/lemote_a1901.dts create mode 100644 arch/mips/boot/dts/loongson/ls3a4000_7a1000_evb.dts create mode 100644 drivers/gpu/drm/lsdc/Kconfig create mode 100644 drivers/gpu/drm/lsdc/Makefile create mode 100644 drivers/gpu/drm/lsdc/lsdc_connector.c create mode 100644 drivers/gpu/drm/lsdc/lsdc_connector.h create mode 100644 drivers/gpu/drm/lsdc/lsdc_crtc.c create mode 100644 drivers/gpu/drm/lsdc/lsdc_drv.c create mode 100644 drivers/gpu/drm/lsdc/lsdc_drv.h create mode 100644 drivers/gpu/drm/lsdc/lsdc_encoder.c create mode 100644 drivers/gpu/drm/lsdc/lsdc_i2c.c create mode 100644 drivers/gpu/drm/lsdc/lsdc_i2c.h create mode 100644 drivers/gpu/drm/lsdc/lsdc_irq.c create mode 100644 drivers/gpu/drm/lsdc/lsdc_irq.h create mode 100644 drivers/gpu/drm/lsdc/lsdc_plane.c create mode 100644 drivers/gpu/drm/lsdc/lsdc_pll.c create mode 100644 drivers/gpu/drm/lsdc/lsdc_pll.h create mode 100644 drivers/gpu/drm/lsdc/lsdc_regs.h -- 2.20.1

1 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2022