dri-devel October 2021

dri-devel@lists.freedesktop.org

347 participants
825 discussions

[PATCH] drm/i915/gem: Remove gpu reloc workaround
by Thomas Hellström 27 Oct '21

27 Oct '21

GPU relocs are gone. There should be no need for this workaround anymore. Remove it. Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> --- .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 19 +------------------ 1 file changed, 1 insertion(+), 18 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c index 1231224728e4..04af88e6d453 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c @@ -1327,7 +1327,6 @@ eb_relocate_entry(struct i915_execbuffer *eb, { struct drm_i915_private *i915 = eb->i915; struct eb_vma *target; - int err; /* we've already hold a reference to all valid objects */ target = eb_get_vma(eb, reloc->target_handle); @@ -1357,25 +1356,9 @@ eb_relocate_entry(struct i915_execbuffer *eb, return -EINVAL; } - if (reloc->write_domain) { + if (reloc->write_domain) target->flags |= EXEC_OBJECT_WRITE; - /* - * Sandybridge PPGTT errata: We need a global gtt mapping - * for MI and pipe_control writes because the gpu doesn't - * properly redirect them through the ppgtt for non_secure - * batchbuffers. - */ - if (reloc->write_domain == I915_GEM_DOMAIN_INSTRUCTION && - GRAPHICS_VER(eb->i915) == 6) { - err = i915_vma_bind(target->vma, - target->vma->obj->cache_level, - PIN_GLOBAL, NULL); - if (err) - return err; - } - } - /* * If the relocation already has the right value in it, no * more work needs to be done. -- 2.31.1

2 1

[PATCH v5 00/21] drm/bridge: Make panel and bridge probe order consistent
by Maxime Ripard 27 Oct '21

27 Oct '21

Hi, We've encountered an issue with the RaspberryPi DSI panel that prevented the whole display driver from probing. The issue is described in detail in the commit 7213246a803f ("drm/vc4: dsi: Only register our component once a DSI device is attached"), but the basic idea is that since the panel is probed through i2c, there's no synchronization between its probe and the registration of the MIPI-DSI host it's attached to. We initially moved the component framework registration to the MIPI-DSI Host attach hook to make sure we register our component only when we have a DSI device attached to our MIPI-DSI host, and then use lookup our DSI device in our bind hook. However, all the DSI bridges controlled through i2c are only registering their associated DSI device in their bridge attach hook, meaning with our change above, we never got that far, and therefore ended up in the same situation than the one we were trying to fix for panels. The best practice to avoid those issues is to register its functions only after all its dependencies are live. We also shouldn't wait any longer than we should to play nice with the other components that are waiting for us, so in our case that would mean moving the DSI device registration to the bridge probe. This has been tested on vc4 (with sn65dsi83 and ps8640), msm (sn65dsi86, lt9611), kirin (adv7511) and exynos. Let me know what you think, Maxime --- Changes from v4: - Rebased on current drm-misc-next - Collected the various tags - Fix for Kirin - Added conversion patch for msm Changes from v3: - Converted exynos and kirin - Converted all the affected bridge drivers - Reworded the documentation a bit Changes from v2: - Changed the approach as suggested by Andrzej, and aligned the bridge on the panel this time. - Fixed some typos Changes from v1: - Change the name of drm_of_get_next function to drm_of_get_bridge - Mention the revert of 87154ff86bf6 and squash the two patches that were reverting that commit - Add some documentation - Make drm_panel_attach and _detach succeed when no callback is there Maxime Ripard (20): drm/bridge: adv7533: Switch to devm MIPI-DSI helpers drm/bridge: adv7511: Register and attach our DSI device at probe drm/bridge: anx7625: Switch to devm MIPI-DSI helpers drm/bridge: anx7625: Register and attach our DSI device at probe drm/bridge: lt8912b: Switch to devm MIPI-DSI helpers drm/bridge: lt8912b: Register and attach our DSI device at probe drm/bridge: lt9611: Switch to devm MIPI-DSI helpers drm/bridge: lt9611: Register and attach our DSI device at probe drm/bridge: lt9611uxc: Switch to devm MIPI-DSI helpers drm/bridge: lt9611uxc: Register and attach our DSI device at probe drm/bridge: ps8640: Switch to devm MIPI-DSI helpers drm/bridge: ps8640: Register and attach our DSI device at probe drm/bridge: sn65dsi83: Fix bridge removal drm/bridge: sn65dsi83: Switch to devm MIPI-DSI helpers drm/bridge: sn65dsi83: Register and attach our DSI device at probe drm/bridge: sn65dsi86: Switch to devm MIPI-DSI helpers drm/bridge: sn65dsi86: Register and attach our DSI device at probe drm/bridge: tc358775: Switch to devm MIPI-DSI helpers drm/bridge: tc358775: Register and attach our DSI device at probe drm/kirin: dsi: Adjust probe order Rob Clark (1): drm/msm/dsi: Adjust probe order drivers/gpu/drm/bridge/adv7511/adv7511.h | 1 - drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 15 ++- drivers/gpu/drm/bridge/adv7511/adv7533.c | 20 +--- drivers/gpu/drm/bridge/analogix/anx7625.c | 40 ++++--- drivers/gpu/drm/bridge/lontium-lt8912b.c | 31 ++---- drivers/gpu/drm/bridge/lontium-lt9611.c | 62 ++++------- drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 65 +++++------ drivers/gpu/drm/bridge/parade-ps8640.c | 107 ++++++++++--------- drivers/gpu/drm/bridge/tc358775.c | 50 +++++---- drivers/gpu/drm/bridge/ti-sn65dsi83.c | 88 ++++++++------- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 101 +++++++++-------- drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 52 +++++---- drivers/gpu/drm/msm/dsi/dsi.c | 50 +++++---- drivers/gpu/drm/msm/dsi/dsi.h | 2 +- drivers/gpu/drm/msm/dsi/dsi_host.c | 22 ++-- drivers/gpu/drm/msm/dsi/dsi_manager.c | 6 +- drivers/gpu/drm/msm/msm_drv.h | 2 + 17 files changed, 348 insertions(+), 366 deletions(-) -- 2.31.1

4 28

[PATCH v6] dt-bindings: drm/msm/gpu: convert to YAML
by David Heidelberg 27 Oct '21

27 Oct '21

Conversion of text binding for Adreno GPU to the YAML format. Signed-off-by: David Heidelberg <david(a)ixit.cz> --- v2: - added compatbile description from Rob Clark - dropped reg description - reg numbers increased to 3 (since we also have uncommon cx_dbgc) - specified interconnect-names items range - defined zap-shader as an object and added it's properties - enforce 0 clocks for Andreno >= 6xx since it's defined in GMU node v3: - fix patterns (add backslash before dot) - add additional clocks - adreno@ -> gpu@ - add few const and change enum to anyOf - added clock & clock-names placeholder in non-conditional part (description) v4: - clock & clock-names - true,false instead maxItems - impl. #stream-id-cells, nvmem-cell-names, nvmem-cells - dropped requirement on firmware-name in zap_shader v5: - maxOtems -> maxItems typo fix v6: - enum -> const to fix ordering - opp-table is object - spacing - drop undocumented and unused #stream-id-cells .../devicetree/bindings/display/msm/gpu.txt | 157 ---------- .../devicetree/bindings/display/msm/gpu.yaml | 288 ++++++++++++++++++ 2 files changed, 288 insertions(+), 157 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/msm/gpu.txt create mode 100644 Documentation/devicetree/bindings/display/msm/gpu.yaml diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt b/Documentation/devicetree/bindings/display/msm/gpu.txt deleted file mode 100644 index 090dcb3fc34d..000000000000 --- a/Documentation/devicetree/bindings/display/msm/gpu.txt +++ /dev/null @@ -1,157 +0,0 @@ -Qualcomm adreno/snapdragon GPU - -Required properties: -- compatible: "qcom,adreno-XYZ.W", "qcom,adreno" or - "amd,imageon-XYZ.W", "amd,imageon" - for example: "qcom,adreno-306.0", "qcom,adreno" - Note that you need to list the less specific "qcom,adreno" (since this - is what the device is matched on), in addition to the more specific - with the chip-id. - If "amd,imageon" is used, there should be no top level msm device. -- reg: Physical base address and length of the controller's registers. -- interrupts: The interrupt signal from the gpu. -- clocks: device clocks (if applicable) - See ../clocks/clock-bindings.txt for details. -- clock-names: the following clocks are required by a3xx, a4xx and a5xx - cores: - * "core" - * "iface" - * "mem_iface" - For GMU attached devices the GPU clocks are not used and are not required. The - following devices should not list clocks: - - qcom,adreno-630.2 -- iommus: optional phandle to an adreno iommu instance -- operating-points-v2: optional phandle to the OPP operating points -- interconnects: optional phandle to an interconnect provider. See - ../interconnect/interconnect.txt for details. Some A3xx and all A4xx platforms - will have two paths; all others will have one path. -- interconnect-names: The names of the interconnect paths that correspond to the - interconnects property. Values must be gfx-mem and ocmem. -- qcom,gmu: For GMU attached devices a phandle to the GMU device that will - control the power for the GPU. Applicable targets: - - qcom,adreno-630.2 -- zap-shader: For a5xx and a6xx devices this node contains a memory-region that - points to reserved memory to store the zap shader that can be used to help - bring the GPU out of secure mode. -- firmware-name: optional property of the 'zap-shader' node, listing the - relative path of the device specific zap firmware. -- sram: phandle to the On Chip Memory (OCMEM) that's present on some a3xx and - a4xx Snapdragon SoCs. See - Documentation/devicetree/bindings/sram/qcom,ocmem.yaml. - -Optional properties: -- #cooling-cells: The value must be 2. For details, please refer - Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml. - -Example 3xx/4xx: - -/ { - ... - - gpu: adreno@fdb00000 { - compatible = "qcom,adreno-330.2", - "qcom,adreno"; - reg = <0xfdb00000 0x10000>; - reg-names = "kgsl_3d0_reg_memory"; - interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "kgsl_3d0_irq"; - clock-names = "core", - "iface", - "mem_iface"; - clocks = <&mmcc OXILI_GFX3D_CLK>, - <&mmcc OXILICX_AHB_CLK>, - <&mmcc OXILICX_AXI_CLK>; - sram = <&gpu_sram>; - power-domains = <&mmcc OXILICX_GDSC>; - operating-points-v2 = <&gpu_opp_table>; - iommus = <&gpu_iommu 0>; - #cooling-cells = <2>; - }; - - gpu_sram: ocmem@fdd00000 { - compatible = "qcom,msm8974-ocmem"; - - reg = <0xfdd00000 0x2000>, - <0xfec00000 0x180000>; - reg-names = "ctrl", - "mem"; - - clocks = <&rpmcc RPM_SMD_OCMEMGX_CLK>, - <&mmcc OCMEMCX_OCMEMNOC_CLK>; - clock-names = "core", - "iface"; - - #address-cells = <1>; - #size-cells = <1>; - - gpu_sram: gpu-sram@0 { - reg = <0x0 0x100000>; - ranges = <0 0 0xfec00000 0x100000>; - }; - }; -}; - -Example a6xx (with GMU): - -/ { - ... - - gpu@5000000 { - compatible = "qcom,adreno-630.2", "qcom,adreno"; - #stream-id-cells = <16>; - - reg = <0x5000000 0x40000>, <0x509e000 0x10>; - reg-names = "kgsl_3d0_reg_memory", "cx_mem"; - - #cooling-cells = <2>; - - /* - * Look ma, no clocks! The GPU clocks and power are - * controlled entirely by the GMU - */ - - interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>; - - iommus = <&adreno_smmu 0>; - - operating-points-v2 = <&gpu_opp_table>; - - interconnects = <&rsc_hlos MASTER_GFX3D &rsc_hlos SLAVE_EBI1>; - interconnect-names = "gfx-mem"; - - gpu_opp_table: opp-table { - compatible = "operating-points-v2"; - - opp-430000000 { - opp-hz = /bits/ 64 <430000000>; - opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>; - opp-peak-kBps = <5412000>; - }; - - opp-355000000 { - opp-hz = /bits/ 64 <355000000>; - opp-level = <RPMH_REGULATOR_LEVEL_SVS>; - opp-peak-kBps = <3072000>; - }; - - opp-267000000 { - opp-hz = /bits/ 64 <267000000>; - opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>; - opp-peak-kBps = <3072000>; - }; - - opp-180000000 { - opp-hz = /bits/ 64 <180000000>; - opp-level = <RPMH_REGULATOR_LEVEL_MIN_SVS>; - opp-peak-kBps = <1804000>; - }; - }; - - qcom,gmu = <&gmu>; - - zap-shader { - memory-region = <&zap_shader_region>; - firmware-name = "qcom/LENOVO/81JL/qcdxkmsuc850.mbn" - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml b/Documentation/devicetree/bindings/display/msm/gpu.yaml new file mode 100644 index 000000000000..99a1ba3ada56 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml @@ -0,0 +1,288 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- + +$id: "http://devicetree.org/schemas/display/msm/gpu.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Devicetree bindings for the Adreno or Snapdragon GPUs + +maintainers: + - Rob Clark <robdclark(a)gmail.com> + +properties: + compatible: + oneOf: + - description: | + The driver is parsing the compat string for Adreno to + figure out the gpu-id and patch level. + items: + - pattern: '^qcom,adreno-[3-6][0-9][0-9]\.[0-9]$' + - const: qcom,adreno + - description: | + The driver is parsing the compat string for Imageon to + figure out the gpu-id and patch level. + items: + - pattern: '^amd,imageon-200\.[0-1]$' + - const: amd,imageon + + clocks: true + + clock-names: true + + reg: + minItems: 1 + maxItems: 3 + + reg-names: + minItems: 1 + items: + - const: kgsl_3d0_reg_memory + - const: cx_mem + - const: cx_dbgc + + interrupts: + maxItems: 1 + + interrupt-names: + maxItems: 1 + + interconnects: + minItems: 1 + maxItems: 2 + + interconnect-names: + minItems: 1 + items: + - const: gfx-mem + - const: ocmem + + iommus: + maxItems: 1 + + sram: + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 4 + description: | + phandles to one or more reserved on-chip SRAM regions. + phandle to the On Chip Memory (OCMEM) that's present on some a3xx and + a4xx Snapdragon SoCs. See + Documentation/devicetree/bindings/sram/qcom,ocmem.yaml + + operating-points-v2: true + opp-table: + type: object + + power-domains: + maxItems: 1 + + zap-shader: + type: object + description: | + For a5xx and a6xx devices this node contains a memory-region that + points to reserved memory to store the zap shader that can be used to + help bring the GPU out of secure mode. + properties: + memory-region: + $ref: /schemas/types.yaml#/definitions/phandle + + firmware-name: + description: | + Default name of the firmware to load to the remote processor. + + "#cooling-cells": + const: 2 + + nvmem-cell-names: + maxItems: 1 + + nvmem-cells: + description: efuse registers + maxItems: 1 + + qcom,gmu: + $ref: /schemas/types.yaml#/definitions/phandle + description: | + For GMU attached devices a phandle to the GMU device that will + control the power for the GPU. + + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + pattern: '^qcom,adreno-[3-5][0-9][0-9]\.[0-9]$' + + then: + properties: + clocks: + minItems: 2 + maxItems: 7 + + clock-names: + items: + anyOf: + - const: core + description: GPU Core clock + - const: iface + description: GPU Interface clock + - const: mem + description: GPU Memory clock + - const: mem_iface + description: GPU Memory Interface clock + - const: alt_mem_iface + description: GPU Alternative Memory Interface clock + - const: gfx3d + description: GPU 3D engine clock + - const: rbbmtimer + description: GPU RBBM Timer for Adreno 5xx series + minItems: 2 + maxItems: 7 + + required: + - clocks + - clock-names + - if: + properties: + compatible: + contains: + pattern: '^qcom,adreno-6[0-9][0-9]\.[0-9]$' + + then: # Since Adreno 6xx series clocks should be defined in GMU + properties: + clocks: false + clock-names: false + +examples: + - | + + // Example a3xx/4xx: + + #include <dt-bindings/clock/qcom,mmcc-msm8974.h> + #include <dt-bindings/clock/qcom,rpmcc.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + gpu: gpu@fdb00000 { + compatible = "qcom,adreno-330.2", "qcom,adreno"; + + reg = <0xfdb00000 0x10000>; + reg-names = "kgsl_3d0_reg_memory"; + + clock-names = "core", "iface", "mem_iface"; + clocks = <&mmcc OXILI_GFX3D_CLK>, + <&mmcc OXILICX_AHB_CLK>, + <&mmcc OXILICX_AXI_CLK>; + + interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "kgsl_3d0_irq"; + + sram = <&gpu_sram>; + power-domains = <&mmcc OXILICX_GDSC>; + operating-points-v2 = <&gpu_opp_table>; + iommus = <&gpu_iommu 0>; + #cooling-cells = <2>; + }; + + ocmem@fdd00000 { + compatible = "qcom,msm8974-ocmem"; + + reg = <0xfdd00000 0x2000>, + <0xfec00000 0x180000>; + reg-names = "ctrl", "mem"; + + clocks = <&rpmcc RPM_SMD_OCMEMGX_CLK>, + <&mmcc OCMEMCX_OCMEMNOC_CLK>; + clock-names = "core", "iface"; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0xfec00000 0x100000>; + + gpu_sram: gpu-sram@0 { + reg = <0x0 0x100000>; + }; + }; + - | + + // Example a6xx (with GMU): + + #include <dt-bindings/clock/qcom,gpucc-sdm845.h> + #include <dt-bindings/clock/qcom,gcc-sdm845.h> + #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interconnect/qcom,sdm845.h> + + reserved-memory { + #address-cells = <2>; + #size-cells = <2>; + + zap_shader_region: gpu@8f200000 { + compatible = "shared-dma-pool"; + reg = <0x0 0x90b00000 0x0 0xa00000>; + no-map; + }; + }; + + gpu@5000000 { + compatible = "qcom,adreno-630.2", "qcom,adreno"; + + reg = <0x5000000 0x40000>, <0x509e000 0x10>; + reg-names = "kgsl_3d0_reg_memory", "cx_mem"; + + #cooling-cells = <2>; + + interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>; + + iommus = <&adreno_smmu 0>; + + operating-points-v2 = <&gpu_opp_table>; + + interconnects = <&rsc_hlos MASTER_GFX3D &rsc_hlos SLAVE_EBI1>; + interconnect-names = "gfx-mem"; + + qcom,gmu = <&gmu>; + + gpu_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-430000000 { + opp-hz = /bits/ 64 <430000000>; + opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>; + opp-peak-kBps = <5412000>; + }; + + opp-355000000 { + opp-hz = /bits/ 64 <355000000>; + opp-level = <RPMH_REGULATOR_LEVEL_SVS>; + opp-peak-kBps = <3072000>; + }; + + opp-267000000 { + opp-hz = /bits/ 64 <267000000>; + opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>; + opp-peak-kBps = <3072000>; + }; + + opp-180000000 { + opp-hz = /bits/ 64 <180000000>; + opp-level = <RPMH_REGULATOR_LEVEL_MIN_SVS>; + opp-peak-kBps = <1804000>; + }; + }; + + zap-shader { + memory-region = <&zap_shader_region>; + firmware-name = "qcom/LENOVO/81JL/qcdxkmsuc850.mbn"; + }; + }; -- 2.33.0

2 2

gpu: drm_fb_cma_helper.c:46: undefined reference to `drm_gem_fb_get_obj'
by Naresh Kamboju 27 Oct '21

27 Oct '21

Regression found on arm gcc-11 built with multi_v5_defconfig Following build warnings / errors reported on linux next 20211025. metadata: git_describe: next-20211025 git_repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next git_short_log: 9ae1fbdeabd3 (\"Add linux-next specific files for 20211025\") target_arch: arm toolchain: gcc-11 config: multi_v5_defconfig build error : -------------- arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.o: in function `drm_fb_cma_get_gem_obj': drivers/gpu/drm/drm_fb_cma_helper.c:46: undefined reference to `drm_gem_fb_get_obj' arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:46: undefined reference to `drm_gem_fb_get_obj' arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:46: undefined reference to `drm_gem_fb_get_obj' arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.o: in function `drm_fb_cma_sync_non_coherent': drivers/gpu/drm/drm_fb_cma_helper.c:133: undefined reference to `drm_atomic_helper_damage_iter_init' arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:135: undefined reference to `drm_atomic_helper_damage_iter_next' make[1]: *** [Makefile:1252: vmlinux] Error 1 make[1]: Target '__all' not remade because of errors. make: *** [Makefile:226: __sub-make] Error 2 Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> build link: ----------- https://builds.tuxbuild.com/1zzgFZBGjpQ5R0lawQFW9iJ39Hp/build.log build config: ------------- https://builds.tuxbuild.com/1zzgFZBGjpQ5R0lawQFW9iJ39Hp/config # To install tuxmake on your system globally # sudo pip3 install -U tuxmake tuxmake --runtime podman --target-arch arm --toolchain gcc-11 --kconfig multi_v5_defconfig -- Linaro LKFT https://lkft.linaro.org

4 10

[PATCH v2 0/4] ti-sn65dsi83 patches
by Alexander Stein 27 Oct '21

27 Oct '21

Changes in V2 of this set: * Add patch from Laurent for fixing the binding regarding optional GPIO * Reorder patches so bindings are changed beforehand * Add small fixes from Sam's review Alexander Stein (3): drm/bridge: ti-sn65dsi83: Make enable GPIO optional dt-bindings: drm/bridge: ti-sn65dsi83: Add vcc supply bindings drm/bridge: ti-sn65dsi83: Add vcc supply regulator support Laurent Pinchart (1): dt-bindings: display: bridge: sn65dsi83: Make enable GPIO optional .../bindings/display/bridge/ti,sn65dsi83.yaml | 6 +++++- drivers/gpu/drm/bridge/ti-sn65dsi83.c | 18 ++++++++++++++++-- 2 files changed, 21 insertions(+), 3 deletions(-) -- 2.25.1

4 15

[PATCH v2] dt-bindings: display/bridge: tc358764: Convert to YAML binding
by AngeloGioacchino Del Regno 27 Oct '21

27 Oct '21

Convert the Toshiba TC358764 txt documentation to YAML. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> --- Note: dtbs_check on exynos5250-arndale.dts will give some warnings after applying this patch: since the preferred way is to have 'ports', this warning was ignored. I have no Exynos5250 board, so the dts fix is left to someone who is able to test on the real hw. .../display/bridge/toshiba,tc358764.txt | 35 ------- .../display/bridge/toshiba,tc358764.yaml | 94 +++++++++++++++++++ 2 files changed, 94 insertions(+), 35 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt create mode 100644 Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.yaml diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt deleted file mode 100644 index 8f9abf28a8fa..000000000000 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt +++ /dev/null @@ -1,35 +0,0 @@ -TC358764 MIPI-DSI to LVDS panel bridge - -Required properties: - - compatible: "toshiba,tc358764" - - reg: the virtual channel number of a DSI peripheral - - vddc-supply: core voltage supply, 1.2V - - vddio-supply: I/O voltage supply, 1.8V or 3.3V - - vddlvds-supply: LVDS1/2 voltage supply, 3.3V - - reset-gpios: a GPIO spec for the reset pin - -The device node can contain following 'port' child nodes, -according to the OF graph bindings defined in [1]: - 0: DSI Input, not required, if the bridge is DSI controlled - 1: LVDS Output, mandatory - -[1]: Documentation/devicetree/bindings/media/video-interfaces.txt - -Example: - - bridge@0 { - reg = <0>; - compatible = "toshiba,tc358764"; - vddc-supply = <&vcc_1v2_reg>; - vddio-supply = <&vcc_1v8_reg>; - vddlvds-supply = <&vcc_3v3_reg>; - reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>; - #address-cells = <1>; - #size-cells = <0>; - port@1 { - reg = <1>; - lvds_ep: endpoint { - remote-endpoint = <&panel_ep>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.yaml new file mode 100644 index 000000000000..815eedb9094f --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.yaml @@ -0,0 +1,94 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358764.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Toshiba TC358764 MIPI-DSI to LVDS bridge + +maintainers: + - Andrzej Hajda <a.hajda(a)samsung.com> + +description: | + The TC358764 is bridge device which converts MIPI DSI or MIPI DPI to DP/eDP. + +properties: + compatible: + enum: + - toshiba,tc358764 + + reg: + description: Virtual channel number of a DSI peripheral + maxItems: 1 + + reset-gpios: + description: GPIO connected to the reset pin. + maxItems: 1 + + vddc-supply: + description: Core voltage supply, 1.2V + + vddio-supply: + description: I/O voltage supply, 1.8V or 3.3V + + vddlvds-supply: + description: LVDS1/2 voltage supply, 3.3V + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: + Video port for MIPI DSI input, if the bridge DSI controlled + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: + Video port for LVDS output (panel or connector). + + required: + - port@1 + +required: + - compatible + - reg + - vddc-supply + - vddio-supply + - vddlvds-supply + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + bridge@0 { + compatible = "toshiba,tc358764"; + reg = <0>; + vddc-supply = <&vcc_1v2_reg>; + vddio-supply = <&vcc_1v8_reg>; + vddlvds-supply = <&vcc_3v3_reg>; + reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@1 { + reg = <1>; + lvds_ep: endpoint { + remote-endpoint = <&panel_ep>; + }; + }; + }; + }; + }; + +... -- 2.33.0

2 1

KASAN: vmalloc-out-of-bounds Write in imageblit
by Hao Sun 27 Oct '21

27 Oct '21

Hello, When using Healer to fuzz the latest Linux kernel, the following crash was triggered. HEAD commit: 42d43c92fc57 Merge branch 'for-linus' git tree: upstream console output: https://drive.google.com/file/d/1fV8jSOKPspCPI-4i7Ee_FJIPIvz24MYu/view?usp=… kernel config: https://drive.google.com/file/d/15vWoQRbJuuMu4ovWhUm1h4SrHyNwK8im/view?usp=… Sorry, I don't have a reproducer for this crash, hope the symbolized report can help. If you fix this issue, please add the following tag to the commit: Reported-by: Hao Sun <sunhao.th(a)gmail.com> ================================================================== BUG: KASAN: vmalloc-out-of-bounds in fast_imageblit drivers/video/fbdev/core/sysimgblt.c:229 [inline] BUG: KASAN: vmalloc-out-of-bounds in sys_imageblit+0x1372/0x13f0 drivers/video/fbdev/core/sysimgblt.c:275 Write of size 4 at addr ffffc90005741000 by task syz-executor/15849 CPU: 0 PID: 15849 Comm: syz-executor Not tainted 5.15.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0xf/0x334 mm/kasan/report.c:256 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 fast_imageblit drivers/video/fbdev/core/sysimgblt.c:229 [inline] sys_imageblit+0x1372/0x13f0 drivers/video/fbdev/core/sysimgblt.c:275 drm_fb_helper_sys_imageblit+0x1c/0x180 drivers/gpu/drm/drm_fb_helper.c:794 drm_fbdev_fb_imageblit+0x179/0x260 drivers/gpu/drm/drm_fb_helper.c:2276 bit_putcs_unaligned drivers/video/fbdev/core/bitblit.c:139 [inline] bit_putcs+0x8ed/0xd80 drivers/video/fbdev/core/bitblit.c:188 fbcon_putcs+0x362/0x450 drivers/video/fbdev/core/fbcon.c:1296 do_update_region+0x399/0x630 drivers/tty/vt/vt.c:676 invert_screen+0x2a7/0x610 drivers/tty/vt/vt.c:800 highlight drivers/tty/vt/selection.c:57 [inline] clear_selection drivers/tty/vt/selection.c:84 [inline] clear_selection+0x55/0x70 drivers/tty/vt/selection.c:80 vc_do_resize+0xda8/0x10a0 drivers/tty/vt/vt.c:1257 fbcon_do_set_font+0x47e/0x780 drivers/video/fbdev/core/fbcon.c:2397 fbcon_set_font+0x81e/0xa10 drivers/video/fbdev/core/fbcon.c:2483 con_font_set drivers/tty/vt/vt.c:4666 [inline] con_font_op+0x73a/0xca0 drivers/tty/vt/vt.c:4710 vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline] vt_ioctl+0x1de9/0x2af0 drivers/tty/vt/vt_ioctl.c:752 tty_ioctl+0xc80/0x1450 drivers/tty/tty_io.c:2805 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fbb0c85cc4d Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fbb09dc4c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fbb0c9830a0 RCX: 00007fbb0c85cc4d RDX: 0000000020000080 RSI: 0000000000004b72 RDI: 0000000000000006 RBP: 00007fbb0c8d5d80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fbb0c9830a0 R13: 00007ffdbece6b9f R14: 00007ffdbece6d40 R15: 00007fbb09dc4dc0 Memory state around the buggy address: ffffc90005740f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffc90005740f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc90005741000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90005741080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90005741100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ==================================================================

1 1

[PATCH] vgacon: Propagate console boot parameters before calling `vc_resize'
by Maciej W. Rozycki 27 Oct '21

27 Oct '21

Fix a division by zero in `vgacon_resize' with a backtrace like: vgacon_resize vc_do_resize vgacon_init do_bind_con_driver do_unbind_con_driver fbcon_fb_unbind do_unregister_framebuffer do_register_framebuffer register_framebuffer __drm_fb_helper_initial_config_and_unlock drm_helper_hpd_irq_event dw_hdmi_irq irq_thread kthread caused by `c->vc_cell_height' not having been initialized. This has only started to trigger with commit 860dafa90259 ("vt: Fix character height handling with VT_RESIZEX"), however the ultimate offender is commit 50ec42edd978 ("[PATCH] Detaching fbcon: fix vgacon to allow retaking of the console"). Said commit has added a call to `vc_resize' whenever `vgacon_init' is called with the `init' argument set to 0, which did not happen before. And the call is made before a key vgacon boot parameter retrieved in `vgacon_startup' has been propagated in `vgacon_init' for `vc_resize' to use to the console structure being worked on. Previously the parameter was `c->vc_font.height' and now it is `c->vc_cell_height'. In this particular scenario the registration of fbcon has failed and vt resorts to vgacon. Now fbcon does have initialized `c->vc_font.height' somehow, unlike `c->vc_cell_height', which is why this code did not crash before, but either way the boot parameters should have been copied to the console structure ahead of the call to `vc_resize' rather than afterwards, so that first the call has a chance to use them and second they do not change the console structure to something possibly different from what was used by `vc_resize'. Move the propagation of the vgacon boot parameters ahead of the call to `vc_resize' then. Adjust the comment accordingly. Signed-off-by: Maciej W. Rozycki <macro(a)orcam.me.uk> Reported-by: Wim Osterholt <wim(a)djo.tudelft.nl> Reported-by: Pavel V. Panteleev <panteleev_p(a)mcst.ru> Fixes: 50ec42edd978 ("[PATCH] Detaching fbcon: fix vgacon to allow retaking of the console") Cc: stable(a)vger.kernel.org # v2.6.18+ --- drivers/video/console/vgacon.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) linux-vt-vgacon-init-cell-height-fix.diff Index: linux-macro-ide-tty/drivers/video/console/vgacon.c =================================================================== --- linux-macro-ide-tty.orig/drivers/video/console/vgacon.c +++ linux-macro-ide-tty/drivers/video/console/vgacon.c @@ -366,11 +366,17 @@ static void vgacon_init(struct vc_data * struct uni_pagedir *p; /* - * We cannot be loaded as a module, therefore init is always 1, - * but vgacon_init can be called more than once, and init will - * not be 1. + * We cannot be loaded as a module, therefore init will be 1 + * if we are the default console, however if we are a fallback + * console, for example if fbcon has failed registration, then + * init will be 0, so we need to make sure our boot parameters + * have been copied to the console structure for vgacon_resize + * ultimately called by vc_resize. Any subsequent calls to + * vgacon_init init will have init set to 0 too. */ c->vc_can_do_color = vga_can_do_color; + c->vc_scan_lines = vga_scan_lines; + c->vc_font.height = c->vc_cell_height = vga_video_font_height; /* set dimensions manually if init != 0 since vc_resize() will fail */ if (init) { @@ -379,8 +385,6 @@ static void vgacon_init(struct vc_data * } else vc_resize(c, vga_video_num_columns, vga_video_num_lines); - c->vc_scan_lines = vga_scan_lines; - c->vc_font.height = c->vc_cell_height = vga_video_font_height; c->vc_complement_mask = 0x7700; if (vga_512_chars) c->vc_hi_font_mask = 0x0800;

2 1

[PATCH] dt-bindings: display: xilinx: Fix example with psgtr
by Michal Simek 26 Oct '21

26 Oct '21

Commit cea0f76a483d ("dt-bindings: phy: Add DT bindings for Xilinx ZynqMP PSGTR PHY") clearly defines #phy-cells as 4. In past 5 cells were used by it never went to upstream. That's why fix example by using only 4 cells instead of 5. Fixes: e7c7970a678d ("dt-bindings: display: xlnx: Add ZynqMP DP subsystem bindings") Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> --- .../devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml index d88bd93f4b80..10ec78ca1c65 100644 --- a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml +++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml @@ -160,8 +160,8 @@ examples: <&xlnx_dpdma 2>, <&xlnx_dpdma 3>; - phys = <&psgtr 1 PHY_TYPE_DP 0 3 27000000>, - <&psgtr 0 PHY_TYPE_DP 1 3 27000000>; + phys = <&psgtr 1 PHY_TYPE_DP 0 3>, + <&psgtr 0 PHY_TYPE_DP 1 3>; phy-names = "dp-phy0", "dp-phy1"; }; -- 2.33.1

3 2

[PATCH v2] drm: bridge: fix unmet dependency on DRM_KMS_HELPER for DRM_PANEL_BRIDGE
by Julian Braha 26 Oct '21

26 Oct '21

When DRM_CHIPONE_ICN6211 is selected, and DRM_KMS_HELPER is not selected, Kbuild gives the following warning: WARNING: unmet direct dependencies detected for DRM_PANEL_BRIDGE Depends on [n]: HAS_IOMEM [=y] && DRM_BRIDGE [=y] && DRM_KMS_HELPER [=n] Selected by [y]: - DRM_CHIPONE_ICN6211 [=y] && HAS_IOMEM [=y] && DRM [=y] && DRM_BRIDGE [=y] && OF [=y] This is because DRM_CHIPONE_ICN6211 selects DRM_PANEL_BRIDGE without depending on or selecting DRM_KMS_HELPER, despite DRM_PANEL_BRIDGE depending on DRM_KMS_HELPER. This unmet dependency bug was detected by Kismet, a static analysis tool for Kconfig. Please advise if this is not the appropriate solution. v2: - changed from "select" to "depends on" Fixes: ce517f18944e ("drm: bridge: Add Chipone ICN6211 MIPI-DSI to RGB bridge") Reviewed-by: Robert Foss <robert.foss(a)linaro.org> Signed-off-by: Julian Braha <julianbraha(a)gmail.com> --- drivers/gpu/drm/bridge/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 431b6e12a81f..a630cb8fd1c8 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -30,6 +30,7 @@ config DRM_CDNS_DSI config DRM_CHIPONE_ICN6211 tristate "Chipone ICN6211 MIPI-DSI/RGB Converter bridge" depends on OF + depends on DRM_KMS_HELPER select DRM_MIPI_DSI select DRM_PANEL_BRIDGE help -- 2.30.2

2 1

← Newer
1
...
26
27
28
29
30
31
32
...
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