dri-devel October 2021

dri-devel@lists.freedesktop.org

347 participants
825 discussions

[PATCH v5 0/5] phy: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support
by Liu Ying 27 Mar '22

27 Mar '22

Hi, This series adds i.MX8qxp LVDS PHY mode support for the Mixel PHY in the Freescale i.MX8qxp SoC. The Mixel PHY is MIPI DPHY + LVDS PHY combo, which can works in either MIPI DPHY mode or LVDS PHY mode. The PHY mode is controlled by i.MX8qxp SCU firmware. The PHY driver would call a SCU function to configure the mode. The PHY driver is already supporting the Mixel MIPI DPHY in i.MX8mq SoC, where it appears to be a single MIPI DPHY. Patch 1/5 sets PHY mode in the Northwest Logic MIPI DSI host controller bridge driver, since i.MX8qxp SoC embeds this controller IP to support MIPI DSI displays together with the Mixel PHY. Patch 2/5 allows LVDS PHYs to be configured through the generic PHY functions and through a custom structure added to the generic PHY configuration union. Patch 3/5 converts mixel,mipi-dsi-phy plain text dt binding to json-schema. Patch 4/5 adds dt binding support for the Mixel combo PHY in i.MX8qxp SoC. Patch 5/5 adds the i.MX8qxp LVDS PHY mode support in the Mixel PHY driver. Welcome comments, thanks. v4->v5: * Align kernel-doc style of include/linux/phy/phy-lvds.h to include/linux/phy/phy.h for patch 2/5. (Vinod) * Trivial tweaks on patch 2/5. * Drop Robert's R-b tag on patch 2/5. v3->v4: * Add all R-b tags received from v3 on relevant patches and respin. (Robert) v2->v3: * Improve readability of mixel_dphy_set_mode() in the Mixel PHY driver. (Guido) * Improve the 'clock-names' property in the PHY dt binding. v1->v2: * Convert mixel,mipi-dsi-phy plain text dt binding to json-schema. (Guido) * Print invalid PHY mode in dmesg from the Mixel PHY driver. (Guido) * Add Guido's R-b tag on the patch for the nwl-dsi drm bridge driver. Liu Ying (5): drm/bridge: nwl-dsi: Set PHY mode in nwl_dsi_enable() phy: Add LVDS configuration options dt-bindings: phy: Convert mixel,mipi-dsi-phy to json-schema dt-bindings: phy: mixel: mipi-dsi-phy: Add Mixel combo PHY support for i.MX8qxp phy: freescale: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support .../devicetree/bindings/phy/mixel,mipi-dsi-phy.txt | 29 --- .../bindings/phy/mixel,mipi-dsi-phy.yaml | 107 ++++++++ drivers/gpu/drm/bridge/nwl-dsi.c | 6 + drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c | 269 ++++++++++++++++++++- include/linux/phy/phy-lvds.h | 32 +++ include/linux/phy/phy.h | 4 + 6 files changed, 407 insertions(+), 40 deletions(-) delete mode 100644 Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt create mode 100644 Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml create mode 100644 include/linux/phy/phy-lvds.h -- 2.7.4

2 9

[PATCH 0/6] dma-buf: Add an API for exporting sync files (v12)
by Jason Ekstrand 22 Mar '22

22 Mar '22

Modern userspace APIs like Vulkan are built on an explicit synchronization model. This doesn't always play nicely with the implicit synchronization used in the kernel and assumed by X11 and Wayland. The client -> compositor half of the synchronization isn't too bad, at least on intel, because we can control whether or not i915 synchronizes on the buffer and whether or not it's considered written. The harder part is the compositor -> client synchronization when we get the buffer back from the compositor. We're required to be able to provide the client with a VkSemaphore and VkFence representing the point in time where the window system (compositor and/or display) finished using the buffer. With current APIs, it's very hard to do this in such a way that we don't get confused by the Vulkan driver's access of the buffer. In particular, once we tell the kernel that we're rendering to the buffer again, any CPU waits on the buffer or GPU dependencies will wait on some of the client rendering and not just the compositor. This new IOCTL solves this problem by allowing us to get a snapshot of the implicit synchronization state of a given dma-buf in the form of a sync file. It's effectively the same as a poll() or I915_GEM_WAIT only, instead of CPU waiting directly, it encapsulates the wait operation, at the current moment in time, in a sync_file so we can check/wait on it later. As long as the Vulkan driver does the sync_file export from the dma-buf before we re-introduce it for rendering, it will only contain fences from the compositor or display. This allows to accurately turn it into a VkFence or VkSemaphore without any over- synchronization. This patch series actually contains two new ioctls. There is the export one mentioned above as well as an RFC for an import ioctl which provides the other half. The intention is to land the export ioctl since it seems like there's no real disagreement on that one. The import ioctl, however, has a lot of debate around it so it's intended to be RFC-only for now. Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4037 IGT tests: https://patchwork.freedesktop.org/series/90490/ v10 (Jason Ekstrand, Daniel Vetter): - Add reviews/acks - Add a patch to rename _rcu to _unlocked - Split things better so import is clearly RFC status v11 (Daniel Vetter): - Add more CCs to try and get maintainers - Add a patch to document DMA_BUF_IOCTL_SYNC - Generally better docs - Use separate structs for import/export (easier to document) - Fix an issue in the import patch v12 (Daniel Vetter): - Better docs for DMA_BUF_IOCTL_SYNC v12 (Christian König): - Drop the rename patch in favor of Christian's series - Add a comment to the commit message for the dma-buf sync_file export ioctl saying why we made it an ioctl on dma-buf Cc: Christian König <christian.koenig(a)amd.com> Cc: Michel Dänzer <michel(a)daenzer.net> Cc: Dave Airlie <airlied(a)redhat.com> Cc: Bas Nieuwenhuizen <bas(a)basnieuwenhuizen.nl> Cc: Daniel Stone <daniels(a)collabora.com> Cc: mesa-dev(a)lists.freedesktop.org Cc: wayland-devel(a)lists.freedesktop.org Test-with: 20210524205225.872316-1-jason(a)jlekstrand.net Christian König (1): dma-buf: Add dma_fence_array_for_each (v2) Jason Ekstrand (5): dma-buf: Add dma_resv_get_singleton (v6) dma-buf: Document DMA_BUF_IOCTL_SYNC (v2) dma-buf: Add an API for exporting sync files (v12) RFC: dma-buf: Add an extra fence to dma_resv_get_singleton_unlocked RFC: dma-buf: Add an API for importing sync files (v7) Documentation/driver-api/dma-buf.rst | 8 ++ drivers/dma-buf/dma-buf.c | 103 +++++++++++++++++++++++++ drivers/dma-buf/dma-fence-array.c | 27 +++++++ drivers/dma-buf/dma-resv.c | 110 +++++++++++++++++++++++++++ include/linux/dma-fence-array.h | 17 +++++ include/linux/dma-resv.h | 2 + include/uapi/linux/dma-buf.h | 103 ++++++++++++++++++++++++- 7 files changed, 369 insertions(+), 1 deletion(-) -- 2.31.1

8 31

[PATCH] drm: bridge: it66121: Added it66121 chip external screen status judgment
by Yunlongli 10 Mar '22

10 Mar '22

In the actual tests, the IT66121 chip sometimes misjudged whether it had an external screen, so, reference the it66121_user_guid.pdf about Audio/Video data is stable or not A typical initialization of HDMI link should be based on interrupt signal and appropriate register probing. Recommended flow is detailed in IT66121 Programming Guide. Simply put, the microcontroller should monitor the HPD status first. Upon valid HPD event, move on to check RxSENDetect register to see if the receiver chip is ready for further handshaking. When RxSENDetect is asserted, start reading EDID data through DDC channels and carry on the rest of the handshaking subsequently.If the micro-controller makes no use of the interrupt signal as well as the above-mentioned status registers, the link establishment might fail. Please do follow the suggested initialization flow recommended in IT66121 Programming Guide. So, I add the IT66121_SYS_STATUS_SENDECTECT register status detection. Signed-off-by: Yunlongli <liyunlonga(a)uniontech.com> --- drivers/gpu/drm/bridge/ite-it66121.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/ite-it66121.c b/drivers/gpu/drm/bridge/ite-it66121.c index 2f2a09adb4bc..9ed4fa298d11 100644 --- a/drivers/gpu/drm/bridge/ite-it66121.c +++ b/drivers/gpu/drm/bridge/ite-it66121.c @@ -523,7 +523,7 @@ static bool it66121_is_hpd_detect(struct it66121_ctx *ctx) if (regmap_read(ctx->regmap, IT66121_SYS_STATUS_REG, &val)) return false; - return val & IT66121_SYS_STATUS_HPDETECT; + return ((val & IT66121_SYS_STATUS_HPDETECT) && (val & IT66121_SYS_STATUS_SENDECTECT)); } static int it66121_bridge_attach(struct drm_bridge *bridge, -- 2.20.1

3 2

[PATCH v3 0/5] drm: use dyndbg in drm_print
by Jim Cromie 05 Mar '22

05 Mar '22

hi dri-devel, Im pretty new in this particular playground. Im using this to send, is it too spammy ? too --to ? git send-email --dry-run \ --to-cmd='scripts/get_maintainer.pl --no-rolestats v3-000*.patch' \ --to=jbaron(a)akamai.com v3-000*.patch drm_debug_enabled() is called a lot (by drm_dev_dbg) to do unlikely bit-tests to selectively enable debug printing; this is a good job for dynamic-debug, IFF it is built with JUMP_LABEL. This patchset enables the use of dynamic-debug to avoid those drm_debug_enabled() overheads, if CONFIG_DRM_USE_DYNAMIC_DEBUG=y. v3: fixes missed SOB, && on BOL, commit-log tweaks reordered patches, 1 is comment, 2 is whitespace. dropped RFC, to see what happens. v2: https://lore.kernel.org/lkml/20210711055003.528167-1-jim.cromie@gmail.com/ v1: https://lore.kernel.org/lkml/20201204035318.332419-1-jim.cromie@gmail.com/ Doing so creates many new pr_debug callsites, otherwise i915 has ~120 prdbgs, and drm has just 1; bash-5.1# modprobe i915 dyndbg: 8 debug prints in module video dyndbg: 305 debug prints in module drm dyndbg: 207 debug prints in module drm_kms_helper dyndbg: 2 debug prints in module ttm dyndbg: 1720 debug prints in module i915 On amdgpu, enabling it adds ~3200 prdbgs, currently at 56 bytes each. So CONFIG_DRM_USE_DYNAMIC_DEBUG=y affects resource requirements. Im running this patchset bare-metal on an i915 laptop & an amdgpu desktop (both as loadable modules). I booted the amdgpu box with: BOOT_IMAGE=(hd2,gpt2)/vmlinuz-5.13.0-dd7-13692-g8def25788f56 \ root=UUID=mumble ro \ rootflags=subvol=root00 rhgb \ dynamic_debug.verbose=3 main.dyndbg=+p \ amdgpu.debug=1 amdgpu.test=1 \ "amdgpu.dyndbg=format ^[ +p" That last line enables ~1700 prdbg callsites with a format like '[DML' etc at boot, and amdgpu.test=1 triggers 3 minutes of tests, causing ~76k prdbgs in 409 seconds, before I turned them off with: echo module amdgpu -p > /proc/dynamic_debug/control This is on top of master @ v5.14-rc1 Should I rebase onto something else ? Jim Cromie (5): drm/print: fixup spelling in a comment drm_print.h: rewrap __DRM_DEFINE_DBG_RATELIMITED macro drm/print: RFC add choice to use dynamic debug in drm-debug drm/print: move conditional deref into macro defn i915: map gvt pr_debug categories to bits in parameters/debug_gvt Note: 3/5, 5/5 have bits that are here for POC, but belong in dynamic_debug.c. drivers/gpu/drm/Kconfig | 13 ++++ drivers/gpu/drm/drm_print.c | 75 +++++++++++++++++- drivers/gpu/drm/i915/gvt/Makefile | 4 + drivers/gpu/drm/i915/i915_params.c | 76 +++++++++++++++++++ include/drm/drm_print.h | 117 ++++++++++++++++++++--------- 5 files changed, 247 insertions(+), 38 deletions(-) -- 2.31.1

4 12

[RFC PATCH 00/11] drm/bridge: ti-sn65dsi86: Support DisplayPort mode
by Laurent Pinchart 04 Mar '22

04 Mar '22

Hello, Despite the SN65DSI86 being a DSI to eDP bridge, it can also operate in DisplayPort mode. This patch series adds support for this feature to the ti-sn65dsi86 driver. The series starts with miscellaneous fixes and improvements in patch 01/11 to 04/11. Patch 05/11 then moves to the panel-bridge helper, and is followed by patches 06/11 and 07/11 that refactor the code to prepare for the next steps. As my goal is to use the sn65dsi86 with the R-Car DU driver, which requires DRM_BRIDGE_ATTACH_NO_CONNECTOR support, the series continues with support for this feature. In patch 08/11 the bridge connector operations are added, and in 09/11 the connector creation is made optional. Patch 10/11 then implements supports for DisplayPort mode, enabled automatically when the next component in the pipeline isn't a panel. Finally, patch 11/11 adds hotplug detection support, which isn't very useful for eDP, but is needed for DisplayPort. This series is an RFC as I haven't been able to test it fully yet. The platform I'm working on is missing support for three other components in the display pipeline (I'm on it), which are required in order to run tests. I would however like to receive feedback on the approach already, in case problems would need to be solved. Laurent Pinchart (11): dt-bindings: drm/bridge: ti-sn65dsi8: Make enable GPIO optional drm/bridge: ti-sn65dsi86: Make enable GPIO optional drm/bridge: ti-sn65dsi86: Unregister AUX adapter in remove() drm/bridge: ti-sn65dsi86: Use bitmask to store valid rates drm/bridge: ti-sn65dsi86: Wrap panel with panel-bridge drm/bridge: ti-sn65dsi86: Group code in sections drm/bridge: ti-sn65dsi86: Split connector creation to a function drm/bridge: ti-sn65dsi86: Implement bridge connector operations drm/bridge: ti-sn65dsi86: Make connector creation optional drm/bridge: ti-sn65dsi86: Support DisplayPort (non-eDP) mode drm/bridge: ti-sn65dsi86: Support hotplug detection .../bindings/display/bridge/ti,sn65dsi86.yaml | 1 - drivers/gpu/drm/bridge/ti-sn65dsi86.c | 266 ++++++++++++------ 2 files changed, 183 insertions(+), 84 deletions(-) -- Regards, Laurent Pinchart

8 55

[PATCH v3 RESEND 00/24] drm/exynos: add support for GSCALER planes on Exynos5433
by Andrzej Hajda 03 Mar '22

03 Mar '22

Hi Inki, GSCALERs in Exynos SoCs support conversion between wide range of image formats, plus scaling and rotation. Driver already supports mem2mem mode - via ExynosDRM IPP framework. This patchset adds support for mem to display mode - framebuffers can be converted, scaled and send directly to Display Controller. From DRM framework's point of view every GSCALER exposes drm_plane which can be connected to display controller (display panel or TV). The feature is not well documented so the development was quite difficult - a process of trial and error, vendor code analysis, guessing from datasheets. Hopefully most of the issues were solved. I have developed and tested it on TM2 device with panel and TV paths. The patchset contains three parts: 1. Preparatory patches - mostly cleanup and refactoring of drm_crtc and drm_plane related structures, to allow usage of planes which are not physically bound to crtcs (01-13). 2. Adding local path support to GSCALER and DECON (14-20). 3. Few fixes of bugs existing already in the code but discovered due to added local path support (21-23). The patchset is based on exynos_drm_next plus my patchset adding zpos to DECON and FIMD - 'drm/exynos: add support for dynamic zpos in DECON and FIMD' - it is required to allow set z-pos position of GSCALER planes. To simplify tests I have also created branch containing all required patches: Repo: https://git.tizen.org/cgit/platform/kernel/linux-exynos Branch: sandbox/ahajda/dev/exynos-drm-local-path This is v2 version of the patchset. In this version I have moved code setting cursor plane in crtc to separate patch together with code disabling fast cursor updates - hardware does not support it. To keep bisectability DTS patches should be applied before subsequent ones. It is rebased on today's exynos-drm-next. Please be aware that DTS patches has been already applied to samsung-soc tree, I left them here to simplify testing on exynos-drm-next, which is not in sync with samsung-soc, for this reason I have moved them on the beginning of the patchset. Regards Andrzej Andrzej Hajda (24): arm64: dts: exynos: configure GSCALER related clocks arm64: dts: exynos: add DSD/GSD clocks to DECONs and GSCALERs drm/exynos: remove exynos_drm_plane.h header drm/exynos: remove spare macro drm/exynos: drop exynos_drm_plane_config structure drm/exynos: add exynos_drm_crtc_init function drm/exynos/decon5433: embed exynos_drm_crtc directly into context drm/exynos/decon7: embed exynos_drm_crtc directly into context drm/exynos/fimd: embed exynos_drm_crtc directly into context drm/exynos/mixer: embed exynos_drm_crtc directly into context drm/exynos/vidi: embed exynos_drm_crtc directly into context drm/exynos: remove standalone exynos_drm_crtc leftovers drm/exynos/vidi: remove encoder_to_vidi helper drm/exynos: unify plane type assignment drm/exynos: set primary plane in exynos_drm_crtc_init drm/exynos: set cursor plane in exynos_drm_crtc_init drm/exynos: add plane update/disable callbacks for planes drm/exynos: add GSCALER plane capability drm/exynos/gscaler: fix id assignement drm/exynos/gscaler: add local path support drm/exynos/decon5433: add local path support drm/exynos/decon5433: wait for finish previous update drm/exynos/gscaler: change supported color format BGRX8888 to XBGR8888 drm/exynos/gscaler: fix handling YVU420 pixel format .../dts/exynos/exynos5433-tm2-common.dtsi | 6 + arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 6 +- arch/arm64/boot/dts/exynos/exynos5433.dtsi | 25 +- drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 162 ++++++++----- drivers/gpu/drm/exynos/exynos7_drm_decon.c | 66 +++-- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 46 ++-- drivers/gpu/drm/exynos/exynos_drm_crtc.h | 7 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 - drivers/gpu/drm/exynos/exynos_drm_drv.h | 50 ++-- drivers/gpu/drm/exynos/exynos_drm_fb.c | 10 +- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 85 +++---- drivers/gpu/drm/exynos/exynos_drm_gsc.c | 229 ++++++++++++++---- drivers/gpu/drm/exynos/exynos_drm_plane.c | 84 ++++--- drivers/gpu/drm/exynos/exynos_drm_plane.h | 14 -- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 48 ++-- drivers/gpu/drm/exynos/exynos_mixer.c | 95 +++----- drivers/gpu/drm/exynos/regs-decon5433.h | 6 + drivers/gpu/drm/exynos/regs-gsc.h | 6 + 18 files changed, 538 insertions(+), 408 deletions(-) delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_plane.h -- 2.17.1

5 35

[PATCH] drm/bridge: cdns-dsi: Make sure to to create proper aliases for dt
by Nishanth Menon 28 Feb '22

28 Feb '22

Add MODULE_DEVICE_TABLE to the device tree table to create required aliases needed for module to be loaded with device tree based platform. Fixes: e19233955d9e ("drm/bridge: Add Cadence DSI driver") Signed-off-by: Nishanth Menon <nm(a)ti.com> --- drivers/gpu/drm/bridge/cdns-dsi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c b/drivers/gpu/drm/bridge/cdns-dsi.c index d8a15c459b42..829e1a144656 100644 --- a/drivers/gpu/drm/bridge/cdns-dsi.c +++ b/drivers/gpu/drm/bridge/cdns-dsi.c @@ -1284,6 +1284,7 @@ static const struct of_device_id cdns_dsi_of_match[] = { { .compatible = "cdns,dsi" }, { }, }; +MODULE_DEVICE_TABLE(of, cdns_dsi_of_match); static struct platform_driver cdns_dsi_platform_driver = { .probe = cdns_dsi_drm_probe, -- 2.32.0

3 4

[PATCH] drm: Only select I2C_ALGOBIT for drivers that actually need it
by Uwe Kleine-König 21 Feb '22

21 Feb '22

While working on a drm driver that doesn't need the i2c algobit stuff I noticed that DRM selects this code even tough only 8 drivers actually use it. While also only some drivers use i2c, keep the select for I2C for the next cleanup patch. Still prepare this already by also selecting I2C for the individual drivers. Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> --- drivers/gpu/drm/Kconfig | 5 ++++- drivers/gpu/drm/ast/Kconfig | 2 ++ drivers/gpu/drm/gma500/Kconfig | 2 ++ drivers/gpu/drm/hisilicon/hibmc/Kconfig | 2 ++ drivers/gpu/drm/i915/Kconfig | 2 ++ drivers/gpu/drm/mgag200/Kconfig | 2 ++ drivers/gpu/drm/nouveau/Kconfig | 2 ++ 7 files changed, 16 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 3c16bd1afd87..351ea617c498 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -12,7 +12,6 @@ menuconfig DRM select HDMI select FB_CMDLINE select I2C - select I2C_ALGOBIT select DMA_SHARED_BUFFER select SYNC_FILE # gallium uses SYS_kcmp for os_same_file_description() to de-duplicate @@ -233,6 +232,8 @@ config DRM_RADEON select DRM_KMS_HELPER select DRM_TTM select DRM_TTM_HELPER + select I2C + select I2C_ALGOBIT select POWER_SUPPLY select HWMON select BACKLIGHT_CLASS_DEVICE @@ -254,6 +255,8 @@ config DRM_AMDGPU select DRM_SCHED select DRM_TTM select DRM_TTM_HELPER + select I2C + select I2C_ALGOBIT select POWER_SUPPLY select HWMON select BACKLIGHT_CLASS_DEVICE diff --git a/drivers/gpu/drm/ast/Kconfig b/drivers/gpu/drm/ast/Kconfig index fbcf2f45cef5..bcc25decd485 100644 --- a/drivers/gpu/drm/ast/Kconfig +++ b/drivers/gpu/drm/ast/Kconfig @@ -6,6 +6,8 @@ config DRM_AST select DRM_VRAM_HELPER select DRM_TTM select DRM_TTM_HELPER + select I2C + select I2C_ALGOBIT help Say yes for experimental AST GPU driver. Do not enable this driver without having a working -modesetting, diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig index 0cff20265f97..e26c3a24955d 100644 --- a/drivers/gpu/drm/gma500/Kconfig +++ b/drivers/gpu/drm/gma500/Kconfig @@ -3,6 +3,8 @@ config DRM_GMA500 tristate "Intel GMA500/600/3600/3650 KMS Framebuffer" depends on DRM && PCI && X86 && MMU select DRM_KMS_HELPER + select I2C + select I2C_ALGOBIT # GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like i915 select ACPI_VIDEO if ACPI select BACKLIGHT_CLASS_DEVICE if ACPI diff --git a/drivers/gpu/drm/hisilicon/hibmc/Kconfig b/drivers/gpu/drm/hisilicon/hibmc/Kconfig index 43943e980203..ac8c42dc79f6 100644 --- a/drivers/gpu/drm/hisilicon/hibmc/Kconfig +++ b/drivers/gpu/drm/hisilicon/hibmc/Kconfig @@ -6,6 +6,8 @@ config DRM_HISI_HIBMC select DRM_VRAM_HELPER select DRM_TTM select DRM_TTM_HELPER + select I2C + select I2C_ALGOBIT help Choose this option if you have a Hisilicon Hibmc soc chipset. If M is selected the module will be called hibmc-drm. diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index 69f57ca9c68d..b3bb6f7cfbbc 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -13,6 +13,8 @@ config DRM_I915 select DRM_PANEL select DRM_MIPI_DSI select RELAY + select I2C + select I2C_ALGOBIT select IRQ_WORK # i915 depends on ACPI_VIDEO when ACPI is enabled # but for select to work, need to select ACPI_VIDEO's dependencies, ick diff --git a/drivers/gpu/drm/mgag200/Kconfig b/drivers/gpu/drm/mgag200/Kconfig index eec59658a938..b28c5e4828f4 100644 --- a/drivers/gpu/drm/mgag200/Kconfig +++ b/drivers/gpu/drm/mgag200/Kconfig @@ -4,6 +4,8 @@ config DRM_MGAG200 depends on DRM && PCI && MMU select DRM_GEM_SHMEM_HELPER select DRM_KMS_HELPER + select I2C + select I2C_ALGOBIT help This is a KMS driver for Matrox G200 chips. It supports the original MGA G200 desktop chips and the server variants. It requires 0.3.0 diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig index 9436310d0854..8823f0b24c73 100644 --- a/drivers/gpu/drm/nouveau/Kconfig +++ b/drivers/gpu/drm/nouveau/Kconfig @@ -7,6 +7,8 @@ config DRM_NOUVEAU select DRM_KMS_HELPER select DRM_TTM select DRM_TTM_HELPER + select I2C + select I2C_ALGOBIT select BACKLIGHT_CLASS_DEVICE if DRM_NOUVEAU_BACKLIGHT select ACPI_VIDEO if ACPI && X86 && BACKLIGHT_CLASS_DEVICE && INPUT select X86_PLATFORM_DEVICES if ACPI && X86 base-commit: 315d99318179b9cd5077ccc9f7f26a164c9fa998 -- 2.30.2

1 1

[PATCH v2 1/2] drm/msm/dpu: Add a function to retrieve the current CTL status
by AngeloGioacchino Del Regno 18 Feb '22

18 Feb '22

Add a function that returns whether the requested CTL is active or not: this will be used in a later commit to fix command mode panel issues. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)somainline.org> --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 6 ++++++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 7 +++++++ 2 files changed, 13 insertions(+) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c index 64740ddb983e..3b6fd73eb3a8 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c @@ -91,6 +91,11 @@ static inline void dpu_hw_ctl_trigger_start(struct dpu_hw_ctl *ctx) DPU_REG_WRITE(&ctx->hw, CTL_START, 0x1); } +static inline bool dpu_hw_ctl_is_started(struct dpu_hw_ctl *ctx) +{ + return !!(DPU_REG_READ(&ctx->hw, CTL_START) & BIT(0)); +} + static inline void dpu_hw_ctl_trigger_pending(struct dpu_hw_ctl *ctx) { trace_dpu_hw_ctl_trigger_prepare(ctx->pending_flush_mask, @@ -579,6 +584,7 @@ static void _setup_ctl_ops(struct dpu_hw_ctl_ops *ops, ops->get_pending_flush = dpu_hw_ctl_get_pending_flush; ops->get_flush_register = dpu_hw_ctl_get_flush_register; ops->trigger_start = dpu_hw_ctl_trigger_start; + ops->is_started = dpu_hw_ctl_is_started; ops->trigger_pending = dpu_hw_ctl_trigger_pending; ops->reset = dpu_hw_ctl_reset_control; ops->wait_reset_status = dpu_hw_ctl_wait_reset_status; diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h index 806c171e5df2..ac1544474022 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h @@ -61,6 +61,13 @@ struct dpu_hw_ctl_ops { */ void (*trigger_start)(struct dpu_hw_ctl *ctx); + /** + * check if the ctl is started + * @ctx : ctl path ctx pointer + * @Return: true if started, false if stopped + */ + bool (*is_started)(struct dpu_hw_ctl *ctx); + /** * kickoff prepare is in progress hw operation for sw * controlled interfaces: DSI cmd mode and WB interface -- 2.32.0

3 11

[Bug 121831] New: Several kmemcheck: Caught 64-bit read from uninitialized memory in radeo
by bugzilla-daemon＠bugzilla.kernel.org 17 Feb '22

17 Feb '22

https://bugzilla.kernel.org/show_bug.cgi?id=121831 Bug ID: 121831 Summary: Several kmemcheck: Caught 64-bit read from uninitialized memory in radeo Product: Drivers Version: 2.5 Kernel Version: 4.7-rc6 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: casteyde.christian(a)free.fr Regression: No Created attachment 222631 --> https://bugzilla.kernel.org/attachment.cgi?id=222631&action=edit dmesg output Slackware 64 14.1 With kmemcheck activated, I get the following warnings: [ 1185.586288] WARNING: kmemcheck: Caught 64-bit read from uninitialized memory (ffff8801c2cd5d08) [ 1185.586292] 000000000000000060f11c81ffffffff68509ab40188ffff0100010001000000 [ 1185.586314] i i i i i i i i u u u u u u u u u u u u u u u u u u u u u u u u [ 1185.586335] ^ [ 1185.586337] RIP: 0010:[<ffffffff8158521d>] [<ffffffff8158521d>] fence_signal+0x1d/0xe0 [ 1185.586343] RSP: 0018:ffff8801b560fa20 EFLAGS: 00010282 [ 1185.586345] RAX: 0000000000000003 RBX: ffff8801c2cd5cc0 RCX: 0000000000000002 [ 1185.586346] RDX: 0000000080000002 RSI: ffff8801b5591fa0 RDI: ffff8801c2cd5cc0 [ 1185.586348] RBP: ffff8801b560fa50 R08: 0000000000000000 R09: 0000000000000001 [ 1185.586349] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000003 [ 1185.586350] R13: ffff8801c2cd5cc0 R14: 00000000021ae410 R15: ffff8800a9490000 [ 1185.586352] FS: 00007fe3e0e408c0(0000) GS:ffff8801c7400000(0000) knlGS:0000000000000000 [ 1185.586353] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1185.586355] CR2: ffff8801c7060c90 CR3: 00000001b558d000 CR4: 00000000000406f0 [ 1185.586356] [<ffffffff8148cb7a>] radeon_fence_signaled+0x4a/0x80 [ 1185.586360] [<ffffffff814f5cf7>] radeon_sa_bo_free+0x37/0xb0 [ 1185.586364] [<ffffffff81547f39>] radeon_ib_free+0x29/0x40 [ 1185.586369] [<ffffffff814a5105>] radeon_cs_parser_fini+0xc5/0x120 [ 1185.586372] [<ffffffff814a597b>] radeon_cs_ioctl+0x2fb/0x7d0 [ 1185.586374] [<ffffffff81449dce>] drm_ioctl+0x13e/0x530 [ 1185.586378] [<ffffffff81471b17>] radeon_drm_ioctl+0x47/0x80 [ 1185.586381] [<ffffffff811aebce>] do_vfs_ioctl+0x8e/0x670 [ 1185.586384] [<ffffffff811af1ec>] SyS_ioctl+0x3c/0x70 [ 1185.586386] [<ffffffff819434a5>] entry_SYSCALL_64_fastpath+0x18/0xa8 [ 1185.586391] [<ffffffffffffffff>] 0xffffffffffffffff [ 1197.075973] WARNING: kmemcheck: Caught 64-bit read from uninitialized memory (ffff8800a2cf4ac8) [ 1197.075977] 0200000000000000ffffffff3f000000ffffffff3f0000000000000000000000 [ 1197.075999] i i i i i i i i u u u u u u u u u u u u u u u u u u u u u u u u [ 1197.076019] ^ [ 1197.076021] RIP: 0010:[<ffffffff81584fc6>] [<ffffffff81584fc6>] fence_signal_locked+0x16/0xc0 [ 1197.076028] RSP: 0018:ffff8801c7403d18 EFLAGS: 00010082 [ 1197.076029] RAX: 000000000000001a RBX: ffff8800a2cf4b10 RCX: 0000000000000000 [ 1197.076031] RDX: ffff8800a9490000 RSI: 0000000000000003 RDI: ffff8800a2cf4a80 [ 1197.076032] RBP: ffff8801c7403d48 R08: 0000000000000000 R09: 0000000000000001 [ 1197.076033] R10: 0000000000000000 R11: ffffffff8200b540 R12: ffff8800a2cf4a80 [ 1197.076034] R13: ffff8800a9491ea8 R14: 0000000000000000 R15: 0000000000000003 [ 1197.076036] FS: 0000000000000000(0000) GS:ffff8801c7400000(0000) knlGS:0000000000000000 [ 1197.076038] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1197.076039] CR2: ffff8801c29c016c CR3: 0000000002006000 CR4: 00000000000406f0 [ 1197.076040] [<ffffffff8148c571>] radeon_fence_check_signaled+0x41/0x80 [ 1197.076044] [<ffffffff810da49d>] __wake_up_common+0x4d/0x80 [ 1197.076334] [<ffffffff810da504>] __wake_up+0x34/0x50 [ 1197.076336] [<ffffffff8148c6c6>] radeon_fence_process+0x26/0x30 [ 1197.076338] [<ffffffff814e0caa>] evergreen_irq_process+0x92a/0x17e0 [ 1197.076342] [<ffffffff814a4309>] radeon_driver_irq_handler_kms+0x19/0x40 [ 1197.076345] [<ffffffff810f15e4>] handle_irq_event_percpu+0x64/0x100 [ 1197.076349] [<ffffffff810f16b4>] handle_irq_event+0x34/0x60 [ 1197.076352] [<ffffffff810f466e>] handle_edge_irq+0xbe/0x150 [ 1197.076356] [<ffffffff810617f8>] handle_irq+0x68/0x180 [ 1197.076360] [<ffffffff81060ff8>] do_IRQ+0x68/0x130 [ 1197.076362] [<ffffffff81943e09>] ret_from_intr+0x0/0x19 [ 1197.076367] [<ffffffff816fec82>] cpuidle_enter+0x12/0x20 [ 1197.076371] [<ffffffff810db0f5>] call_cpuidle+0x25/0x40 [ 1197.076373] [<ffffffff810db3c3>] cpu_startup_entry+0x1b3/0x290 [ 1197.076375] [<ffffffff8193ad5c>] rest_init+0x12c/0x140 [ 1197.076379] [<ffffffff82299de5>] start_kernel+0x354/0x361 [ 1197.076384] [<ffffffff822992ae>] x86_64_start_reservations+0x2f/0x31 [ 1197.076387] [<ffffffff8229939b>] x86_64_start_kernel+0xeb/0xf0 [ 1197.076390] [<ffffffffffffffff>] 0xffffffffffffffff [ 1207.836251] WARNING: kmemcheck: Caught 64-bit read from uninitialized memory (ffff8800a2cf4348) etc. In gdb: (gdb) l *0xffffffff8158521d 0xffffffff8158521d is in fence_signal (drivers/dma-buf/fence.c:114). 109 unsigned long flags; 110 111 if (!fence) 112 return -EINVAL; 113 114 if (!ktime_to_ns(fence->timestamp)) { 115 fence->timestamp = ktime_get(); 116 smp_mb__before_atomic(); 117 } -- You are receiving this mail because: You are watching the assignee of the bug.

2 3

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2021