dri-devel February 2021

dri-devel@lists.freedesktop.org

314 participants
684 discussions

[PATCH v6 0/5] Enable rk3066a HDMI sound
by Johan Jonker 22 Mar '21

22 Mar '21

Update the rk3066a HDMI documents with a #sound-dai-cells property. Include the code for sound in the HDMI driver. Add a simple-sound-card compatible node to rk3066a.dtsi, because I2S0 and HDMI TX are connected internally. And as last enable rk3066a HDMI sound in the rk3066a-mk808.dts file. make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- -j4 cp ./arch/arm/boot/zImage ../zImage-dtb cat ./arch/arm/boot/dts/rk3066a-mk808.dtb >> ../zImage-dtb ../tools/rkcrc -k ../zImage-dtb ../mk808.img sudo ../tools/rkflashtool w 0x4000 0x8000 < ../mk808.img sudo ../tools/rkflashtool b Changed v6: remove patches that are applied to linux-next add platform_device_unregister() restyle Changed v5: removed unused variable fill frame structure Johan Jonker (4): dt-bindings: display: add #sound-dai-cells property to rockchip rk3066 hdmi ARM: dts: rockchip: rk3066a: add #sound-dai-cells to hdmi node ARM: dts: rockchip: add hdmi-sound node to rk3066a.dtsi ARM: dts: rockchip: enable hdmi_sound and i2s0 for rk3066a-mk808 Zheng Yang (1): drm: rockchip: add sound support to rk3066 hdmi driver .../display/rockchip/rockchip,rk3066-hdmi.yaml | 4 + arch/arm/boot/dts/rk3066a-mk808.dts | 8 + arch/arm/boot/dts/rk3066a.dtsi | 17 ++ drivers/gpu/drm/rockchip/Kconfig | 2 + drivers/gpu/drm/rockchip/rk3066_hdmi.c | 277 ++++++++++++++++++++- 5 files changed, 307 insertions(+), 1 deletion(-) -- 2.11.0

2 7

[PATCH v4, 00/10] soc: mediatek: mmsys: Use function call for setting the routing registers
by Yongqiang Niu 22 Mar '21

22 Mar '21

The following series are intended to prepare the mtk-mmsys driver to allow different DDP (Data Display Path) function call per SoC. base 5.11-rc1 change since v3: - move register operation into mmsys path select function Yongqiang Niu (10): soc: mediatek: mmsys: create mmsys folder soc: mediatek: mmsys: Create struct mtk_mmsys to store context data soc: mediatek: mmsys: move register operation into mmsys path select function soc: mediatek: mmsys: Use function call for setting the routing registers soc: mediatek: mmsys: add mt8183 function call for setting the routing registers soc: mediatek: mmsys: add component OVL_2L2 soc: mediatek: mmsys: add component POSTMASK soc: mediatek: mmsys: add component RDMA4 soc: mediatek: mmsys: Use function call for setting mmsys ovl mout register soc: mediatek: mmsys: add mt8192 mmsys support drivers/soc/mediatek/Makefile | 2 +- drivers/soc/mediatek/mmsys/Makefile | 5 + drivers/soc/mediatek/mmsys/mt2701-mmsys.c | 254 ++++++++++++++++++++ drivers/soc/mediatek/mmsys/mt8183-mmsys.c | 110 +++++++++ drivers/soc/mediatek/mmsys/mt8192-mmsys.c | 149 ++++++++++++ drivers/soc/mediatek/mmsys/mtk-mmsys.c | 180 ++++++++++++++ drivers/soc/mediatek/mtk-mmsys.c | 373 ------------------------------ include/linux/soc/mediatek/mtk-mmsys.h | 25 ++ 8 files changed, 724 insertions(+), 374 deletions(-) create mode 100644 drivers/soc/mediatek/mmsys/Makefile create mode 100644 drivers/soc/mediatek/mmsys/mt2701-mmsys.c create mode 100644 drivers/soc/mediatek/mmsys/mt8183-mmsys.c create mode 100644 drivers/soc/mediatek/mmsys/mt8192-mmsys.c create mode 100644 drivers/soc/mediatek/mmsys/mtk-mmsys.c delete mode 100644 drivers/soc/mediatek/mtk-mmsys.c -- 1.8.1.1.dirty

6 18

soc: mediatek: Prepare MMSYS for DDP routing using function call
by Yongqiang Niu 22 Mar '21

22 Mar '21

The following series are intended to prepare the mtk-mmsys driver to allow different DDP (Data Display Path) function call per SoC. base change: https://patchwork.kernel.org/project/linux-mediatek/patch/20201006193320.40… Change since v2: - fix review issue in v2 - add 8183 mmsys function call - add 8192 new component - add 8192 mmsys function call

3 17

[PATCH v4 1/2] dt-bindings: drm/bridge: anx7625: Add power supplies
by Hsin-Yi Wang 19 Mar '21

19 Mar '21

anx7625 requires 3 power supply regulators. Signed-off-by: Hsin-Yi Wang <hsinyi(a)chromium.org> Reviewed-by: Rob Herring <robh(a)kernel.org> Reviewed-by: Robert Foss <robert.foss(a)linaro.org> --- v3->v4: rebase to drm-misc/for-linux-next --- .../bindings/display/bridge/analogix,anx7625.yaml | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml index c789784efe306..ab48ab2f4240d 100644 --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml @@ -34,6 +34,15 @@ properties: description: used for reset chip control, RESET_N pin B7. maxItems: 1 + vdd10-supply: + description: Regulator that provides the supply 1.0V power. + + vdd18-supply: + description: Regulator that provides the supply 1.8V power. + + vdd33-supply: + description: Regulator that provides the supply 3.3V power. + ports: $ref: /schemas/graph.yaml#/properties/ports @@ -55,6 +64,9 @@ properties: required: - compatible - reg + - vdd10-supply + - vdd18-supply + - vdd33-supply - ports additionalProperties: false @@ -72,6 +84,9 @@ examples: reg = <0x58>; enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>; reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>; + vdd10-supply = <&pp1000_mipibrdg>; + vdd18-supply = <&pp1800_mipibrdg>; + vdd33-supply = <&pp3300_mipibrdg>; ports { #address-cells = <1>; -- 2.30.1.766.gb4fecdf3b7-goog

2 3

[PATCH] drm/mediatek: fine tune the data lane trail by project dts
by Jitao Shi 18 Mar '21

18 Mar '21

Some panels or bridges require customized hs_da_trail time. So add a property in devicetree for this panels and bridges. Signed-off-by: Jitao Shi <jitao.shi(a)mediatek.com> --- drivers/gpu/drm/mediatek/mtk_dsi.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c index 8c70ec39bfe1..6e7092fa2fee 100644 --- a/drivers/gpu/drm/mediatek/mtk_dsi.c +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c @@ -194,6 +194,7 @@ struct mtk_dsi { struct clk *hs_clk; u32 data_rate; + u32 da_trail_delta; unsigned long mode_flags; enum mipi_dsi_pixel_format format; @@ -234,7 +235,7 @@ static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi) timing->da_hs_prepare = (80 * data_rate_mhz + 4 * 1000) / 8000; timing->da_hs_zero = (170 * data_rate_mhz + 10 * 1000) / 8000 + 1 - timing->da_hs_prepare; - timing->da_hs_trail = timing->da_hs_prepare + 1; + timing->da_hs_trail = timing->da_hs_prepare + 1 + dsi->da_trail_delta; timing->ta_go = 4 * timing->lpx - 2; timing->ta_sure = timing->lpx + 2; @@ -1094,6 +1095,13 @@ static int mtk_dsi_probe(struct platform_device *pdev) goto err_unregister_host; } + ret = of_property_read_u32_index(dev->of_node, "da_trail_delta", 0, + &dsi->da_trail_delta); + if (ret) { + dev_info(dev, "Can't get da_trail_delta, keep it as 0: %d\n", ret); + dsi->da_trail_delta = 0; + } + comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DSI); if (comp_id < 0) { dev_err(dev, "Failed to identify by alias: %d\n", comp_id); -- 2.12.5

3 2

[PATCH v13 0/8] drm/mediatek: add support for mediatek SOC MT8183
by Hsin-Yi Wang 17 Mar '21

17 Mar '21

This series is based on kernel/git/chunkuang.hu/linux.git mediatek-drm-next The series is tested on a mt8183 krane device. Change since v12 - fix mtk_dither_config Change since v10, v11 - fix review comments in v9 Change since v9 - change several function to rebase to mediatek-drm-next Change since v8 - fix some review comment in v8 - separate gamma module for mt8183 has no dither function in gamma - enable dither function for 5 or 6 bpc panel display - separate ddp mutex patch from the whole Soc patch Change since v7 - add dt-binding for mt8183 display - base mmsys patch https://patchwork.kernel.org/project/linux-mediatek/cover/1607506379-10998-… - base dts patch https://patchwork.kernel.org/project/linux-mediatek/cover/20201127104930.19… - add mt8183 function call for setting the routing registers - add RDMA fifo size error handle Change since v6 - move ddp component define into mtk_mmsys.h - add mmsys private data to support different ic path connection - add mt8183-mmsys.c to support 8183 path connection - fix reviewed issue in v6 Change since v5 - fix reviewed issue in v5 base https://patchwork.kernel.org/project/linux-mediatek/list/?series=213219 Change since v4 - fix reviewed issue in v4 Change since v3 - fix reviewed issue in v3 - fix type error in v3 - fix conflict with iommu patch Change since v2 - fix reviewed issue in v2 - add mutex node into dts file Changes since v1: - fix reviewed issue in v1 - add dts for mt8183 display nodes - adjust display clock control flow in patch 22 - add vmap support for mediatek drm in patch 23 - fix page offset issue for mmap function in patch 24 - enable allow_fb_modifiers for mediatek drm in patch 25 Hsin-Yi Wang (1): drm/mediatek: add mtk_dither_set_common() function Yongqiang Niu (7): arm64: dts: mt8183: rename rdma fifo size arm64: dts: mt8183: refine gamma compatible name drm/mediatek: separate gamma module drm/mediatek: add has_dither private data for gamma drm/mediatek: enable dither function soc: mediatek: add mtk mutex support for MT8183 drm/mediatek: add support for mediatek SOC MT8183 arch/arm64/boot/dts/mediatek/mt8183.dtsi | 7 +- drivers/gpu/drm/mediatek/Makefile | 1 + drivers/gpu/drm/mediatek/mtk_disp_drv.h | 14 ++ drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 198 ++++++++++++++++++++ drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 18 ++ drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 6 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 111 ++++------- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 49 ++++- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 + drivers/soc/mediatek/mtk-mutex.c | 50 +++++ 10 files changed, 379 insertions(+), 76 deletions(-) create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_gamma.c -- 2.30.0.365.g02bc693789-goog

4 19

[PATCH 0/8] drm/vc4: hdmi: Support the 4k @ 60Hz modes
by Maxime Ripard 17 Mar '21

17 Mar '21

Hi, Here is a series that enables the higher resolutions on the HDMI0 Controller found in the BCM2711 (RPi4). In order to work it needs a few adjustments to config.txt, most notably to enable the enable_hdmi_4kp60 and force_turbo options. The firmware also has a glitch at the moment and will not properly release the BSC controllers, which will make the EDID retrieval fail. We can work around this using the following config.txt options: disable_fw_kms_setup=1 hdmi_edid_file:0=1 hdmi_edid_filename:0=1366x768.bin hdmi_ignore_edid:0=1 hdmi_edid_file:1=1 hdmi_edid_filename:1=1366x768.bin hdmi_ignore_edid:1=1 A fix will come for the firmware eventually. Let me know what you think, Maxime Maxime Ripard (8): clk: Add range accessors drm/vc4: hvs: Make the HVS bind first drm/vc4: hdmi: Properly compute the BVB clock rate drm/vc4: hdmi: Check and warn if we can't reach 4kp60 frequencies drm/vc4: hdmi: Enable the scrambler drm/vc4: hdmi: Raise the maximum clock rate drm/vc4: plane: Fix typo in scaler width and height drm/vc4: plane: Remove redundant assignment drivers/clk/clk.c | 30 ++++++++++ drivers/gpu/drm/vc4/vc4_drv.c | 11 +++- drivers/gpu/drm/vc4/vc4_hdmi.c | 88 ++++++++++++++++++++++++++--- drivers/gpu/drm/vc4/vc4_hdmi.h | 8 +++ drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 3 + drivers/gpu/drm/vc4/vc4_plane.c | 5 +- include/linux/clk.h | 16 ++++++ 7 files changed, 148 insertions(+), 13 deletions(-) -- 2.29.2

3 23

[PATCHv1 0/6] Support for GE B1x5v2
by Sebastian Reichel 16 Mar '21

16 Mar '21

Hi, This series adds support for another General Electric patient monitor series (similar to existing Bx50v3), which is based on i.MX6DL using Congatec's QMX6 module. The module uses an I2C RTC to provide the i.MX6 32768 Hz clock, so it's important to keep it enabled. Not doing so results in incorrect timings of watchdog and i.MX6 RTC. The bootloader enables the watchdog, so disabling the clock results in system reboot. [0] The second patch is required for B155v2, which uses a 1366x768 G156XTN01 panel. The 1366 width is not supported by the display pipeline and result in boot hanging without the patch. [1] Patches 3+4 are updating DT bindings for the new board compatible values. Patch 5 adds missing sst25vf032b to spi-nor bindings. Checkpatch still complains, since the binding lists all chips without vendor prefix. This probably should be fixed when the files is moved to YAML, but is non-trivial since those chips are manufactured by multiple vendors. E.g. sst25vf032b can be sourced from at least sst and microchip. Finally patch 6 adds the board files. Thanks, [0] There has been a discussion for the problem on the mailinglists last year. The discussion died off, when I told people their ideas don't work. I hope using protected-clocks is fine for this usecase. https://lore.kernel.org/linux-clk/20191108170135.9053-1-sebastian.reichel@c… [1] I've sent this before as a separate patch in September, but nobody seemed to care. This adds full context for the problem. https://lore.kernel.org/dri-devel/20200910162831.321556-1-sebastian.reichel… -- Sebastian Sebastian Reichel (6): rtc: m41t80: add support for protected clock drm/imx: Add 8 pixel alignment fix dt-bindings: vendor-prefixes: add congatec dt-bindings: arm: fsl: add GE B1x5pv2 boards dt-bindings: mtd: jedec,spi-nor: add sst25vf032b ARM: dts: imx6: Add GE B1x5v2 .../devicetree/bindings/arm/fsl.yaml | 11 + .../devicetree/bindings/mtd/jedec,spi-nor.txt | 1 + .../devicetree/bindings/rtc/rtc-m41t80.txt | 1 + .../devicetree/bindings/vendor-prefixes.yaml | 2 + arch/arm/boot/dts/Makefile | 5 + arch/arm/boot/dts/imx6dl-b105pv2.dts | 35 + arch/arm/boot/dts/imx6dl-b105v2.dts | 35 + arch/arm/boot/dts/imx6dl-b125pv2.dts | 33 + arch/arm/boot/dts/imx6dl-b125v2.dts | 33 + arch/arm/boot/dts/imx6dl-b155v2.dts | 36 + arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi | 434 ++++++++++++ arch/arm/boot/dts/imx6dl-b1x5v2.dtsi | 61 ++ arch/arm/boot/dts/imx6dl-qmx6.dtsi | 623 ++++++++++++++++++ drivers/gpu/drm/imx/imx-drm-core.c | 19 +- drivers/gpu/drm/imx/imx-ldb.c | 5 + drivers/gpu/drm/imx/ipuv3-crtc.c | 11 +- drivers/gpu/drm/imx/ipuv3-plane.c | 19 +- drivers/gpu/ipu-v3/ipu-dc.c | 5 + drivers/gpu/ipu-v3/ipu-di.c | 7 + drivers/rtc/rtc-m41t80.c | 3 + 20 files changed, 1373 insertions(+), 6 deletions(-) create mode 100644 arch/arm/boot/dts/imx6dl-b105pv2.dts create mode 100644 arch/arm/boot/dts/imx6dl-b105v2.dts create mode 100644 arch/arm/boot/dts/imx6dl-b125pv2.dts create mode 100644 arch/arm/boot/dts/imx6dl-b125v2.dts create mode 100644 arch/arm/boot/dts/imx6dl-b155v2.dts create mode 100644 arch/arm/boot/dts/imx6dl-b1x5pv2.dtsi create mode 100644 arch/arm/boot/dts/imx6dl-b1x5v2.dtsi create mode 100644 arch/arm/boot/dts/imx6dl-qmx6.dtsi -- 2.30.0

5 16

[RFC v3 0/3] Introduce Virtio based Dmabuf driver
by Vivek Kasireddy 15 Mar '21

15 Mar '21

The Virtual Dmabuf or Virtio based Dmabuf (Vdmabuf) driver can be used to "transfer" a page-backed dmabuf created in the Guest to the Host without making any copies. This is mostly accomplished by recreating the dmabuf on the Host using the PFNs and other meta-data shared by the guest. A use-case where this driver would be a good fit is a multi-GPU system (perhaps one discrete and one integrated) where one of the GPUs does not have access to the display/connectors/outputs. This could be an embedded system design decision or a restriction made at the firmware/BIOS level or perhaps the device is setup in UPT (Universal Passthrough) mode. When such a GPU is passthrough'd to a Guest OS, this driver can help in transferring the scanout buffer(s) (rendered using the native rendering stack) to the Host for the purpose of displaying them. Or, quite simply, this driver can be used to transfer a dmabuf created by an application running on the Guest to another application running on the Host. The userspace component running in the Guest that transfers the dmabuf is referred to as the producer or exporter and its counterpart running in the Host is referred to as importer or consumer. For instance, a Wayland compositor would potentially be a producer and Qemu UI would be a consumer. It is the producer's responsibility to not reuse or destroy the shared buffer while it is still being used by the consumer. The consumer would send a release cmd indicating that it is done after which the shared buffer can be safely used again by the producer. One way the producer can prevent accidental re-use of the shared buffer is to lock the buffer when it exports it and unlock it after it gets a release cmd. As an example, the GBM API provides a simple way to lock and unlock a surface's buffers. For each dmabuf that is to be shared with the Host, a 128-bit unique ID is generated that identifies this buffer across the whole system. This ID is a combination of the Qemu process ID, a counter and a randomizer. We could potentially use UUID API but we currently use the above mentioned combination to identify the source of the buffer at any given time for potential bookkeeping. A typical cycle starts with the producer or exporter calling the export IOCTL to export a dmabuf; a new unique ID is generated for this buffer and it gets registered with the Host. The Host then alerts the consumer or importer by raising an event and shares the ID. In response, the consumer calls the import IOCTL using the ID and gets a newly created dmabuf fd in return. After it is done using the dmabuf, the consumer finally calls the release IOCTL and the Guest is notified which in turn notifies the producer letting it know that the buffer is now safe to reuse. v2: - Added a notifier mechanism for getting the kvm pointer. - Added start and stop routines in the Vhost backend. - Augmented the cover letter and made some minor improvements. v3: - Refactored the code to make it similar to vsock Vivek Kasireddy (3): kvm: Add a notifier for create and destroy VM events virtio: Introduce Vdmabuf driver vhost: Add Vdmabuf backend drivers/vhost/Kconfig | 9 + drivers/vhost/Makefile | 3 + drivers/vhost/vdmabuf.c | 1446 +++++++++++++++++++++++++++ drivers/virtio/Kconfig | 8 + drivers/virtio/Makefile | 1 + drivers/virtio/virtio_vdmabuf.c | 1090 ++++++++++++++++++++ include/linux/kvm_host.h | 5 + include/linux/virtio_vdmabuf.h | 271 +++++ include/uapi/linux/vhost.h | 3 + include/uapi/linux/virtio_ids.h | 1 + include/uapi/linux/virtio_vdmabuf.h | 99 ++ virt/kvm/kvm_main.c | 20 +- 12 files changed, 2954 insertions(+), 2 deletions(-) create mode 100644 drivers/vhost/vdmabuf.c create mode 100644 drivers/virtio/virtio_vdmabuf.c create mode 100644 include/linux/virtio_vdmabuf.h create mode 100644 include/uapi/linux/virtio_vdmabuf.h -- 2.26.2

6 18

[PATCH 0/2] pci sysfs file iomem revoke support
by Daniel Vetter 13 Mar '21

13 Mar '21

Hi all, This is a revised version of patch 12 from my series to lock down some follow_pfn vs VM_SPECIAL races: https://lore.kernel.org/dri-devel/CAKwvOdnSrsnTgPEuQJyaOTSkTP2dR9208Y66HQG_… Stephen reported an issue on HAVE_PCI_LEGACY platforms which this patch set tries to address. Previous patches are all still in linux-next. Stephen, would be awesome if you can give this a spin. Björn/Greg, review on the first patch is needed, I think that's the cleanest approach from all the options I discussed with Greg in this thread: https://lore.kernel.org/dri-devel/CAKMK7uGrdDrbtj0OyzqQc0CGrQwc2F3tFJU9vLfm… Cheers, Daniel Cc: Stephen Rothwell <sfr(a)canb.auug.org.au> Cc: Jason Gunthorpe <jgg(a)ziepe.ca> Cc: Kees Cook <keescook(a)chromium.org> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: John Hubbard <jhubbard(a)nvidia.com> Cc: Jérôme Glisse <jglisse(a)redhat.com> Cc: Jan Kara <jack(a)suse.cz> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: linux-mm(a)kvack.org Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-samsung-soc(a)vger.kernel.org Cc: linux-media(a)vger.kernel.org Cc: Bjorn Helgaas <bhelgaas(a)google.com> Cc: linux-pci(a)vger.kernel.org Daniel Vetter (2): PCI: also set up legacy files only after sysfs init PCI: Revoke mappings like devmem drivers/pci/pci-sysfs.c | 11 +++++++++++ drivers/pci/proc.c | 1 + 2 files changed, 12 insertions(+) -- 2.30.0

3 8

← Newer
1
...
10
11
12
13
14
15
16
...
69
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2021