dri-devel November 2020

dri-devel@lists.freedesktop.org

316 participants
811 discussions

[PATCH 0/8] drm/vram-helper: Lock GEM BOs while they are mapped
by Thomas Zimmermann 01 Dec '20

01 Dec '20

GEM VRAM helpers used to pin the BO in their implementation of vmap, so that they could not be relocated. In a recent discussion, [1] it became clear that this is incorrect and that vmap should rather repend on the reservation lock to prevent relocation. This patchset addresses the issue. Besides the vram helpers, this affects ast, vboxvideo and the generic fbdev emulation. Patch 1 adds a few more rules to vmap internfaces. With VRAM, it is necessary to keep the BO evictable, which requires soem care when mapping the memory. Patch 2 changes ast's cursor code accordingly. Patch 3 adds vram helpers that acquires the reservation lock and vmap the memory buffer. Same for vunmap in reverse. Patches 4 and 5 convert ast and vboxvideo to the new helper. Patch 6 removes pinning and locking from VRAM helper's vmap and vunmap. The affected users in ast and fbdev emulation acquire the reservation locks of the GEM objects before vmapping BOs. VRAM helpers don't support to export the buffer, so there are no other users of these functions. The the pinning and locking removed, vmap can be simplified as done in patches 7 and 8. Tested on ast with GEM VRAM and also on mgag200 to verify that the fbdev change does not interfere with GEM SHMEM. Thomas Zimmermann (8): drm/gem: Write down some rules for vmap usage drm/ast: Only map cursor BOs during updates drm/vram-helper: Provide drm_gem_vram_vmap_unlocked() drm/ast: Use drm_gem_vram_vmap_unlocked() in ast_cursor_show() drm/vboxvideo: Use drm_gem_vram_vmap_unlocked() in cursor update drm/vram-helper: Remove pinning and locking from drm_gem_vram_vmap() drm/vram-helper: Remove vmap reference counting drm/vram-helper: Simplify vmap implementation drivers/gpu/drm/ast/ast_cursor.c | 63 +++++++++------- drivers/gpu/drm/ast/ast_drv.h | 2 - drivers/gpu/drm/drm_client.c | 31 ++++++++ drivers/gpu/drm/drm_fb_helper.c | 10 ++- drivers/gpu/drm/drm_gem_vram_helper.c | 101 +++++++++++++------------- drivers/gpu/drm/drm_prime.c | 6 ++ drivers/gpu/drm/vboxvideo/vbox_mode.c | 7 +- include/drm/drm_client.h | 2 + include/drm/drm_gem.h | 16 ++++ include/drm/drm_gem_vram_helper.h | 21 ++---- 10 files changed, 159 insertions(+), 100 deletions(-) -- 2.29.2

3 30

[PATCH v3 0/6] drm/tidss: Use new connector model for tidss
by Nikhil Devshatwar 01 Dec '20

01 Dec '20

This series moves the tidss to using new connectoe model, where the SoC driver (tidss) creates the connector and all the bridges are attached with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR Since the bridges do not create the connector, the bus format and bus_flag is set after the format negotiation. Support format negotiations in the tfp410 and mhdp bridge drivers as a first step before moving the connector model. Nikhil Devshatwar (6): drm: bridge: Propagate the bus flags from bridge->timings drm/bridge: tfp410: Support format negotiation hooks drm/bridge: mhdp8546: Add minimal format negotiation drm/tidss: Set bus_format correctly from bridge/connector drm/tidss: Move to newer connector model drm/bridge: cdns-mhdp8546: Fix the interrupt enable/disable .../drm/bridge/cadence/cdns-mhdp8546-core.c | 69 +++++++++++++------ drivers/gpu/drm/bridge/ti-tfp410.c | 33 +++++++++ drivers/gpu/drm/drm_bridge.c | 8 +++ drivers/gpu/drm/tidss/tidss_drv.h | 3 + drivers/gpu/drm/tidss/tidss_encoder.c | 36 ++++------ drivers/gpu/drm/tidss/tidss_kms.c | 19 ++++- 6 files changed, 123 insertions(+), 45 deletions(-) -- 2.17.1

3 22

[PATCH 0/5] Thermal devfreq cooling improvements with Energy Model
by Lukasz Luba 01 Dec '20

01 Dec '20

Hi all, This path set is a continuation of my previous work, which aimed to add Energy Model to all devices. This series is a follow up for the patches which got merged to v5.9-rc1. It aims to change the thermal devfreq cooling and use the Energy Model instead of private calculation and structures. The new registration interface in the patch 3/5 helps to register devfreq cooling and the EM in one call. There is also another improvement, patch 2/5 is changing the way how thermal gets the device status. Now it's taken on demand and stored as a copy. The last patch wouldn't go through thermal tree, but it's here to consistency. The patch set is based on current next (next-20200921). Regards, Lukasz Luba [1] https://lkml.org/lkml/2020/5/11/326 Lukasz Luba (5): thermal: devfreq_cooling: change tracing function and arguments thermal: devfreq_cooling: get a copy of device status thermal: devfreq_cooling: add new registration functions with Energy Model thermal: devfreq_cooling: remove old power model and use EM drm/panfrost: Register devfreq cooling and attempt to add Energy Model drivers/gpu/drm/panfrost/panfrost_devfreq.c | 2 +- drivers/thermal/devfreq_cooling.c | 414 ++++++++++---------- include/linux/devfreq_cooling.h | 39 +- include/trace/events/thermal.h | 19 +- 4 files changed, 249 insertions(+), 225 deletions(-) -- 2.17.1

3 19

[PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs
by Dmitry Osipenko 01 Dec '20

01 Dec '20

Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs, which reduces power consumption and heating of the Tegra chips. Tegra SoC has multiple hardware units which belong to a core power domain of the SoC and share the core voltage. The voltage must be selected in accordance to a minimum requirement of every core hardware unit. The minimum core voltage requirement depends on: 1. Clock enable state of a hardware unit. 2. Clock frequency. 3. Unit's internal idling/active state. This series is tested on Acer A500 (T20), AC100 (T20), Nexus 7 (T30) and Ouya (T30) devices. I also added voltage scaling to the Ventana (T20) and Cardhu (T30) boards which are tested by NVIDIA's CI farm. Tegra30 is now up to 5C cooler on Nexus 7 and stays cool on Ouya (instead of becoming burning hot) while system is idling. It should be possible to improve this further by implementing a more advanced power management features for the kernel drivers. The DVFS support is opt-in for all boards, meaning that older DTBs will continue to work like they did it before this series. It should be possible to easily add the core voltage scaling support for Tegra114+ SoCs based on this grounding work later on, if anyone will want to implement it. WARNING(!) This series is made on top of the memory interconnect patches which are currently under review [1]. The Tegra EMC driver and devicetree-related patches need to be applied on top of the ICC series. [1] https://patchwork.ozlabs.org/project/linux-tegra/list/?series=212196 Dmitry Osipenko (30): dt-bindings: host1x: Document OPP and voltage regulator properties dt-bindings: mmc: tegra: Document OPP and voltage regulator properties dt-bindings: pwm: tegra: Document OPP and voltage regulator properties media: dt: bindings: tegra-vde: Document OPP and voltage regulator properties dt-binding: usb: ci-hdrc-usb2: Document OPP and voltage regulator properties dt-bindings: usb: tegra-ehci: Document OPP and voltage regulator properties soc/tegra: Add sync state API soc/tegra: regulators: Support Tegra SoC device sync state API soc/tegra: regulators: Fix lockup when voltage-spread is out of range regulator: Allow skipping disabled regulators in regulator_check_consumers() drm/tegra: dc: Support OPP and SoC core voltage scaling drm/tegra: gr2d: Correct swapped device-tree compatibles drm/tegra: gr2d: Support OPP and SoC core voltage scaling drm/tegra: gr3d: Support OPP and SoC core voltage scaling drm/tegra: hdmi: Support OPP and SoC core voltage scaling gpu: host1x: Support OPP and SoC core voltage scaling mmc: sdhci-tegra: Support OPP and core voltage scaling pwm: tegra: Support OPP and core voltage scaling media: staging: tegra-vde: Support OPP and SoC core voltage scaling usb: chipidea: tegra: Support OPP and SoC core voltage scaling usb: host: ehci-tegra: Support OPP and SoC core voltage scaling memory: tegra20-emc: Support Tegra SoC device state syncing memory: tegra30-emc: Support Tegra SoC device state syncing ARM: tegra: Add OPP tables for Tegra20 peripheral devices ARM: tegra: Add OPP tables for Tegra30 peripheral devices ARM: tegra: ventana: Add voltage supplies to DVFS-capable devices ARM: tegra: paz00: Add voltage supplies to DVFS-capable devices ARM: tegra: acer-a500: Add voltage supplies to DVFS-capable devices ARM: tegra: cardhu-a04: Add voltage supplies to DVFS-capable devices ARM: tegra: nexus7: Add voltage supplies to DVFS-capable devices .../display/tegra/nvidia,tegra20-host1x.txt | 56 +++ .../bindings/media/nvidia,tegra-vde.txt | 12 + .../bindings/mmc/nvidia,tegra20-sdhci.txt | 12 + .../bindings/pwm/nvidia,tegra20-pwm.txt | 13 + .../devicetree/bindings/usb/ci-hdrc-usb2.txt | 4 + .../bindings/usb/nvidia,tegra20-ehci.txt | 2 + .../boot/dts/tegra20-acer-a500-picasso.dts | 30 +- arch/arm/boot/dts/tegra20-paz00.dts | 40 +- .../arm/boot/dts/tegra20-peripherals-opp.dtsi | 386 ++++++++++++++++ arch/arm/boot/dts/tegra20-ventana.dts | 65 ++- arch/arm/boot/dts/tegra20.dtsi | 14 + .../tegra30-asus-nexus7-grouper-common.dtsi | 23 + arch/arm/boot/dts/tegra30-cardhu-a04.dts | 44 ++ .../arm/boot/dts/tegra30-peripherals-opp.dtsi | 415 ++++++++++++++++++ arch/arm/boot/dts/tegra30.dtsi | 13 + drivers/gpu/drm/tegra/Kconfig | 1 + drivers/gpu/drm/tegra/dc.c | 138 +++++- drivers/gpu/drm/tegra/dc.h | 5 + drivers/gpu/drm/tegra/gr2d.c | 140 +++++- drivers/gpu/drm/tegra/gr3d.c | 136 ++++++ drivers/gpu/drm/tegra/hdmi.c | 63 ++- drivers/gpu/host1x/Kconfig | 1 + drivers/gpu/host1x/dev.c | 87 ++++ drivers/memory/tegra/tegra20-emc.c | 8 +- drivers/memory/tegra/tegra30-emc.c | 8 +- drivers/mmc/host/Kconfig | 1 + drivers/mmc/host/sdhci-tegra.c | 70 ++- drivers/pwm/Kconfig | 1 + drivers/pwm/pwm-tegra.c | 84 +++- drivers/regulator/core.c | 12 +- .../soc/samsung/exynos-regulator-coupler.c | 2 +- drivers/soc/tegra/common.c | 152 ++++++- drivers/soc/tegra/regulators-tegra20.c | 25 +- drivers/soc/tegra/regulators-tegra30.c | 30 +- drivers/staging/media/tegra-vde/Kconfig | 1 + drivers/staging/media/tegra-vde/vde.c | 127 ++++++ drivers/staging/media/tegra-vde/vde.h | 1 + drivers/usb/chipidea/Kconfig | 1 + drivers/usb/chipidea/ci_hdrc_tegra.c | 79 ++++ drivers/usb/host/Kconfig | 1 + drivers/usb/host/ehci-tegra.c | 79 ++++ include/linux/regulator/coupler.h | 6 +- include/soc/tegra/common.h | 22 + 43 files changed, 2360 insertions(+), 50 deletions(-) -- 2.27.0

9 97

[RESEND PATCH 0/3] Move Mediatek MIPI DSI PHY driver from DRM folder to PHY folder
by Chun-Kuang Hu 01 Dec '20

01 Dec '20

mtk_mipi_dsi_phy is currently placed inside mediatek drm driver, but it's more suitable to place a phy driver into phy driver folder, so move mtk_mipi_dsi_phy driver into phy driver folder. Chun-Kuang Hu (3): drm/mediatek: Separate mtk_mipi_tx to an independent module phy: mediatek: Move mtk_mipi_dsi_phy driver into drivers/phy/mediatek folder MAINTAINERS: add files for Mediatek DRM drivers MAINTAINERS | 1 + drivers/gpu/drm/mediatek/Kconfig | 1 + drivers/gpu/drm/mediatek/Makefile | 3 --- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 - drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 - drivers/phy/mediatek/Kconfig | 7 +++++++ drivers/phy/mediatek/Makefile | 5 +++++ .../mediatek/phy-mtk-mipi-dsi-mt8173.c} | 2 +- .../mediatek/phy-mtk-mipi-dsi-mt8183.c} | 2 +- .../mtk_mipi_tx.c => phy/mediatek/phy-mtk-mipi-dsi.c} | 5 ++++- .../mtk_mipi_tx.h => phy/mediatek/phy-mtk-mipi-dsi.h} | 0 11 files changed, 20 insertions(+), 8 deletions(-) rename drivers/{gpu/drm/mediatek/mtk_mt8173_mipi_tx.c => phy/mediatek/phy-mtk-mipi-dsi-mt8173.c} (99%) rename drivers/{gpu/drm/mediatek/mtk_mt8183_mipi_tx.c => phy/mediatek/phy-mtk-mipi-dsi-mt8183.c} (99%) rename drivers/{gpu/drm/mediatek/mtk_mipi_tx.c => phy/mediatek/phy-mtk-mipi-dsi.c} (97%) rename drivers/{gpu/drm/mediatek/mtk_mipi_tx.h => phy/mediatek/phy-mtk-mipi-dsi.h} (100%) -- 2.17.1

3 8

GPU-side memory protection landscape
by Alexander Monakov 01 Dec '20

01 Dec '20

Hi, On #dri-devel Daniel invited me to chime in on the topic of clearing GPU memory handed to userspace, so here I go. I was asking how information leak from giving userspace dirty memory previously used by another process is not seen as a security issue. I was pointed to a recent thread, which offers a little perspective: https://lists.freedesktop.org/archives/dri-devel/2020-November/287144.html I think the main argument shown there is weak: > And for the legacy node model with authentication of clients against > the X server, leaking that all around was ok. seeing how there's the XCSECURITY extension that is supposed to limit what clients can retrieve, or there could be two X servers running for different users. My other concern is how easy it is to cause system instability or hangs by out-of-bounds writes from the GPU (via compute shaders or copy commands). In my experience of several years doing GPU computing with NVIDIA tech, I don't recall needing to lose time rebooting my PC after running a buggy CUDA "kernel". Heck, I could run the GCC C testsuite on the GPU without worrying about locking myself and others from the server. But now when I develop on a laptop with AMD's latest mobile SoC, every time I make a mistake in my GLSL code it more often than not forces a reboot. I hope you understand what a huge pain it is. What are the existing GPU hardware capabilities for memory protection (both in terms of preventing random accesses to system memory like with an IOMMU, and in terms of isolating different process contexts from each other), and to what extend Linux DRM drivers are taking advantage of them? Would you consider producing a document with answers to the above so users know what to expect? Thank you. Alexander

3 2

[PATCH v2] drm: document that user-space should force-probe connectors
by Simon Ser 01 Dec '20

01 Dec '20

It seems like we can't have nice things, so let's just document the disappointing behaviour instead. The previous version assumed the kernel would perform the probing work when appropriate, however this is not the case today. Update the documentation to reflect reality. v2: - Improve commit message to explain why this change is made (Pekka) - Keep the bit about flickering (Daniel) - Explain when user-space should force-probe, and when it shouldn't (Daniel) Signed-off-by: Simon Ser <contact(a)emersion.fr> Fixes: 2ac5ef3b2362 ("drm: document drm_mode_get_connector") Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Pekka Paalanen <ppaalanen(a)gmail.com> Cc: Ville Syrjala <ville.syrjala(a)linux.intel.com> --- include/uapi/drm/drm_mode.h | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index b49fbf2bdc40..1c064627e6c3 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -414,15 +414,12 @@ enum drm_mode_subconnector { * * If the @count_modes field is set to zero, the kernel will perform a forced * probe on the connector to refresh the connector status, modes and EDID. - * A forced-probe can be slow and the ioctl will block. A force-probe can cause - * flickering and temporary freezes, so it should not be performed - * automatically. + * A forced-probe can be slow, might cause flickering and the ioctl will block. * - * User-space shouldn't need to force-probe connectors in general: the kernel - * will automatically take care of probing connectors that don't support - * hot-plug detection when appropriate. However, user-space may force-probe - * connectors on user request (e.g. clicking a "Scan connectors" button, or - * opening a UI to manage screens). + * User-space needs to force-probe connectors to ensure their metadata is + * up-to-date at startup and after receiving a hot-plug event. User-space + * may perform a forced-probe when the user explicitly requests it. User-space + * shouldn't perform a forced-probe in other situations. */ struct drm_mode_get_connector { /** @encoders_ptr: Pointer to ``__u32`` array of object IDs. */ -- 2.29.2

2 1

[BUG] drm/vkms: Failure when using drmGetConnectorCurrent()
by Leandro Ribeiro 01 Dec '20

01 Dec '20

Hello, We have a patch in Weston to replace drmGetConnector() calls with drmGetConnectorCurrent(): https://gitlab.freedesktop.org/wayland/weston/-/issues/437 https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/518 Unfortunately this is not working when we use VKMS (upstream version tested). Please see https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/518#note_700… for more information, and feel free to jump into the discussion. If there's more helpful information that I can share, please let me know. Thank you, Leandro

5 12

[PATCH v3] dt-bindings: display: mcde: Convert to YAML schema
by Linus Walleij 01 Dec '20

01 Dec '20

This moves the MCDE bindings over to using the YAML schema to describe the ST-Ericsson MCDE display controller, making use of the generic DSI controller schema. In the process we correct an error in the old text bindings: the clocks for the SDI host controllers were specified as part of the main MCDE component while they should be specified in the DSI host controller subnodes. This was a leftover from an earlier iteration of the first patch series adding the MCDE. We also add the "port" node, we will use this when adding LCD panels using the direct parallel interface DPI instead of DSI. Cc: devicetree(a)vger.kernel.org Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> --- ChangeLog v2->v3: - Add resets to the bindings for future-proofing, set additionalProperties: false - Extend commit message to explain the the old bindings were incorrect. ChangeLog v1->v2: - Cut the description on the interrupts. - Drop maxItems: 3 on clocks and clock-names: implicit from the number of listed items. - Tag the DSI ports with unevaluatedProperties: false - Tag the MCDE as such with additionalProperties: true - It was a bit hard to test this because of the code base being out of phase with the validation tools but it seems to check out. --- .../devicetree/bindings/display/ste,mcde.txt | 104 ----------- .../devicetree/bindings/display/ste,mcde.yaml | 169 ++++++++++++++++++ 2 files changed, 169 insertions(+), 104 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/ste,mcde.txt create mode 100644 Documentation/devicetree/bindings/display/ste,mcde.yaml diff --git a/Documentation/devicetree/bindings/display/ste,mcde.txt b/Documentation/devicetree/bindings/display/ste,mcde.txt deleted file mode 100644 index 4c33c692bd5f..000000000000 --- a/Documentation/devicetree/bindings/display/ste,mcde.txt +++ /dev/null @@ -1,104 +0,0 @@ -ST-Ericsson Multi Channel Display Engine MCDE - -The ST-Ericsson MCDE is a display controller with support for compositing -and displaying several channels memory resident graphics data on DSI or -LCD displays or bridges. It is used in the ST-Ericsson U8500 platform. - -Required properties: - -- compatible: must be: - "ste,mcde" -- reg: register base for the main MCDE control registers, should be - 0x1000 in size -- interrupts: the interrupt line for the MCDE -- epod-supply: a phandle to the EPOD regulator -- vana-supply: a phandle to the analog voltage regulator -- clocks: an array of the MCDE clocks in this strict order: - MCDECLK (main MCDE clock), LCDCLK (LCD clock), PLLDSI - (HDMI clock), DSI0ESCLK (DSI0 energy save clock), - DSI1ESCLK (DSI1 energy save clock), DSI2ESCLK (DSI2 energy - save clock) -- clock-names: must be the following array: - "mcde", "lcd", "hdmi" - to match the required clock inputs above. -- #address-cells: should be <1> (for the DSI hosts that will be children) -- #size-cells: should be <1> (for the DSI hosts that will be children) -- ranges: this should always be stated - -Required subnodes: - -The devicetree must specify subnodes for the DSI host adapters. -These must have the following characteristics: - -- compatible: must be: - "ste,mcde-dsi" -- reg: must specify the register range for the DSI host -- vana-supply: phandle to the VANA voltage regulator -- clocks: phandles to the high speed and low power (energy save) clocks - the high speed clock is not present on the third (dsi2) block, so it - should only have the "lp" clock -- clock-names: "hs" for the high speed clock and "lp" for the low power - (energy save) clock -- #address-cells: should be <1> -- #size-cells: should be <0> - -Display panels and bridges will appear as children on the DSI hosts, and -the displays are connected to the DSI hosts using the common binding -for video transmitter interfaces; see -Documentation/devicetree/bindings/media/video-interfaces.txt - -If a DSI host is unused (not connected) it will have no children defined. - -Example: - -mcde@a0350000 { - compatible = "ste,mcde"; - reg = <0xa0350000 0x1000>; - interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>; - epod-supply = <&db8500_b2r2_mcde_reg>; - vana-supply = <&ab8500_ldo_ana_reg>; - clocks = <&prcmu_clk PRCMU_MCDECLK>, /* Main MCDE clock */ - <&prcmu_clk PRCMU_LCDCLK>, /* LCD clock */ - <&prcmu_clk PRCMU_PLLDSI>; /* HDMI clock */ - clock-names = "mcde", "lcd", "hdmi"; - #address-cells = <1>; - #size-cells = <1>; - ranges; - - dsi0: dsi@a0351000 { - compatible = "ste,mcde-dsi"; - reg = <0xa0351000 0x1000>; - vana-supply = <&ab8500_ldo_ana_reg>; - clocks = <&prcmu_clk PRCMU_DSI0CLK>, <&prcmu_clk PRCMU_DSI0ESCCLK>; - clock-names = "hs", "lp"; - #address-cells = <1>; - #size-cells = <0>; - - panel { - compatible = "samsung,s6d16d0"; - reg = <0>; - vdd1-supply = <&ab8500_ldo_aux1_reg>; - reset-gpios = <&gpio2 1 GPIO_ACTIVE_LOW>; - }; - - }; - dsi1: dsi@a0352000 { - compatible = "ste,mcde-dsi"; - reg = <0xa0352000 0x1000>; - vana-supply = <&ab8500_ldo_ana_reg>; - clocks = <&prcmu_clk PRCMU_DSI1CLK>, <&prcmu_clk PRCMU_DSI1ESCCLK>; - clock-names = "hs", "lp"; - #address-cells = <1>; - #size-cells = <0>; - }; - dsi2: dsi@a0353000 { - compatible = "ste,mcde-dsi"; - reg = <0xa0353000 0x1000>; - vana-supply = <&ab8500_ldo_ana_reg>; - /* This DSI port only has the Low Power / Energy Save clock */ - clocks = <&prcmu_clk PRCMU_DSI2ESCCLK>; - clock-names = "lp"; - #address-cells = <1>; - #size-cells = <0>; - }; -}; diff --git a/Documentation/devicetree/bindings/display/ste,mcde.yaml b/Documentation/devicetree/bindings/display/ste,mcde.yaml new file mode 100644 index 000000000000..830c9b4091cc --- /dev/null +++ b/Documentation/devicetree/bindings/display/ste,mcde.yaml @@ -0,0 +1,169 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/ste,mcde.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ST-Ericsson Multi Channel Display Engine MCDE + +maintainers: + - Linus Walleij <linus.walleij(a)linaro.org> + +properties: + compatible: + const: ste,mcde + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + description: an array of the MCDE clocks + items: + - description: MCDECLK (main MCDE clock) + - description: LCDCLK (LCD clock) + - description: PLLDSI (HDMI clock) + + clock-names: + items: + - const: mcde + - const: lcd + - const: hdmi + + resets: + maxItems: 1 + + epod-supply: + description: a phandle to the EPOD regulator + + vana-supply: + description: a phandle to the analog voltage regulator + + port: + type: object + description: + A DPI port node with endpoint definitions as defined in + Documentation/devicetree/bindings/media/video-interfaces.txt + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + ranges: true + +patternProperties: + "^dsi@[0-9a-f]+$": + description: subnodes for the three DSI host adapters + type: object + allOf: + - $ref: dsi-controller.yaml# + properties: + compatible: + const: ste,mcde-dsi + + reg: + maxItems: 1 + + vana-supply: + description: a phandle to the analog voltage regulator + + clocks: + description: phandles to the high speed and low power (energy save) clocks + the high speed clock is not present on the third (dsi2) block, so it + should only have the "lp" clock + minItems: 1 + maxItems: 2 + + clock-names: + oneOf: + - items: + - const: hs + - const: lp + - items: + - const: lp + + required: + - compatible + - reg + - vana-supply + - clocks + - clock-names + + unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - epod-supply + - vana-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/mfd/dbx500-prcmu.h> + #include <dt-bindings/gpio/gpio.h> + + mcde@a0350000 { + compatible = "ste,mcde"; + reg = <0xa0350000 0x1000>; + interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>; + epod-supply = <&db8500_b2r2_mcde_reg>; + vana-supply = <&ab8500_ldo_ana_reg>; + clocks = <&prcmu_clk PRCMU_MCDECLK>, + <&prcmu_clk PRCMU_LCDCLK>, + <&prcmu_clk PRCMU_PLLDSI>; + clock-names = "mcde", "lcd", "hdmi"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + dsi0: dsi@a0351000 { + compatible = "ste,mcde-dsi"; + reg = <0xa0351000 0x1000>; + vana-supply = <&ab8500_ldo_ana_reg>; + clocks = <&prcmu_clk PRCMU_DSI0CLK>, <&prcmu_clk PRCMU_DSI0ESCCLK>; + clock-names = "hs", "lp"; + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "samsung,s6d16d0"; + reg = <0>; + vdd1-supply = <&ab8500_ldo_aux1_reg>; + reset-gpios = <&gpio2 1 GPIO_ACTIVE_LOW>; + }; + }; + + dsi1: dsi@a0352000 { + compatible = "ste,mcde-dsi"; + reg = <0xa0352000 0x1000>; + vana-supply = <&ab8500_ldo_ana_reg>; + clocks = <&prcmu_clk PRCMU_DSI1CLK>, <&prcmu_clk PRCMU_DSI1ESCCLK>; + clock-names = "hs", "lp"; + #address-cells = <1>; + #size-cells = <0>; + }; + + dsi2: dsi@a0353000 { + compatible = "ste,mcde-dsi"; + reg = <0xa0353000 0x1000>; + vana-supply = <&ab8500_ldo_ana_reg>; + /* This DSI port only has the Low Power / Energy Save clock */ + clocks = <&prcmu_clk PRCMU_DSI2ESCCLK>; + clock-names = "lp"; + #address-cells = <1>; + #size-cells = <0>; + }; + }; + +... -- 2.26.2

3 2

[RFC v2 0/8] drm/i915: Add support for Intel's eDP backlight controls
by Lyude Paul 01 Dec '20

01 Dec '20

A while ago we ran into issues while trying to enable the eDP backlight control interface as defined by VESA, in order to make the DPCD backlight controls on newer laptop panels work. The issue ended up being much more complicated however, as we also apparently needed to add support for an Intel-specific DPCD backlight control interface as the VESA interface is broken on many laptop panels. For lack of a better name, we just call this the Intel HDR backlight interface. While this only adds support for the SDR backlight mode (I think), this will fix a lot of user's laptop panels that we weren't able to properly automatically detect DPCD backlight controls on previously. Lyude Paul (8): drm/i915/dp: Program source OUI on eDP panels drm/i915: Rename pwm_* backlight callbacks to ext_pwm_* drm/i915: Keep track of pwm-related backlight hooks separately drm/i915/dp: Rename eDP VESA backlight interface functions drm/i915/dp: Add register definitions for Intel HDR backlight interface drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now) drm/i915/dp: Allow forcing specific interfaces through enable_dpcd_backlight drm/dp: Revert "drm/dp: Introduce EDID-based quirks" drivers/gpu/drm/drm_dp_helper.c | 82 +-- drivers/gpu/drm/drm_dp_mst_topology.c | 3 +- .../drm/i915/display/intel_display_types.h | 24 +- drivers/gpu/drm/i915/display/intel_dp.c | 42 +- .../drm/i915/display/intel_dp_aux_backlight.c | 384 ++++++++++++-- drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 +- drivers/gpu/drm/i915/display/intel_panel.c | 476 ++++++++++-------- drivers/gpu/drm/i915/display/intel_panel.h | 4 + drivers/gpu/drm/i915/display/intel_psr.c | 2 +- drivers/gpu/drm/i915/i915_params.c | 2 +- include/drm/drm_dp_helper.h | 21 +- 11 files changed, 672 insertions(+), 371 deletions(-) -- 2.26.2

6 20

← Newer
1
...
16
17
18
19
20
21
22
...
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel November 2020