dri-devel April 2020

dri-devel@lists.freedesktop.org

353 participants
944 discussions

etnaviv: command buffer outside valid memory window
by Johannes Pointner 08 Apr '20

08 Apr '20

Hello, I'm trying to get etnaviv on an i.MX6Q (2 GB DDR RAM) device running with kernel 5.6.2 but it is failing to setup the GPU with the following error: [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] cma: Reserved 256 MiB at 0x7f400000 [ 0.000000] On node 0 totalpages: 524288 [ 0.000000] Normal zone: 4608 pages used for memmap [ 0.000000] Normal zone: 0 pages reserved [ 0.000000] Normal zone: 524288 pages, LIFO batch:63 ... [ 0.000000] Memory: 1803240K/2097152K available (6144K kernel code, 247K rwdata, 2284K rodata, 1024K init, 375K bss, 31768K reserved, 262144K cma-reserved, 0K highmem) ... [ 0.529924] etnaviv etnaviv: bound 130000.gpu (ops gpu_ops) [ 0.530153] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops) [ 0.530408] etnaviv etnaviv: bound 2204000.gpu (ops gpu_ops) [ 0.530427] etnaviv-gpu 130000.gpu: model: GC2000, revision: 5108 [ 0.530748] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007 [ 0.530833] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215 [ 0.530853] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0 ... [ 5.374046] etnaviv etnaviv: command buffer outside valid memory window [ 5.389451] etnaviv etnaviv: command buffer outside valid memory window [ 5.406062] etnaviv etnaviv: command buffer outside valid memory window [ 5.421381] etnaviv etnaviv: command buffer outside valid memory window I have a similar setup with a i.MX6DL (1GB DDR RAM) and this works w/o an error. I found this patch https://lkml.org/lkml/2019/6/19/809 which describes a similar issue. Is there something I'm missing or I have misconfigured? Any hint would be highly appreciated. Thx, Hannes

1 0

[PATCH 00/10] Set up generic fbdev after registering device
by Thomas Zimmermann 08 Apr '20

08 Apr '20

Generic fbdev emulation is a DRM client. If possible, it should behave like userspace clients. Therefore it should not run before the driver registered the new DRM device. If the setup function fails, the driver should not report an error. This is a follow-up patchset to the discussion at [1]. I went through all calls to drm_fbdev_generic_setup(), moved them to the final operation of their driver's probe function, and removed the return value. Built-tested on x86-64, aarch64 and arm. [1] https://lore.kernel.org/dri-devel/20200403135828.2542770-1-daniel.vetter@ff… Thomas Zimmermann (10): drm/ast: Set up fbdev after registering device; remove error checks drm/hibmc: Remove error check from fbdev setup drm/kirin: Set up fbdev after fully registering device drm/ingenic: Remove error check from fbdev setup drm/mediathek: Remove error check from fbdev setup drm/mgag200: Set up fbdev after registering device; remove error checks drm/tilcdc: Set up fbdev after fully registering device drm/udl: Remove error check from fbdev setup drm/vboxvideo: Set up fbdev after registering device; remove error checks drm/fb-helper: Remove return value from drm_fbdev_generic_setup() drivers/gpu/drm/ast/ast_drv.c | 3 +++ drivers/gpu/drm/ast/ast_main.c | 5 ----- drivers/gpu/drm/drm_fb_helper.c | 18 ++++++++---------- .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 6 +----- .../gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 4 ++-- drivers/gpu/drm/ingenic/ingenic-drm.c | 4 +--- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 +--- drivers/gpu/drm/mgag200/mgag200_drv.c | 2 ++ drivers/gpu/drm/mgag200/mgag200_main.c | 4 ---- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 3 +-- drivers/gpu/drm/udl/udl_drv.c | 6 +----- drivers/gpu/drm/vboxvideo/vbox_drv.c | 6 ++---- include/drm/drm_fb_helper.h | 5 +++-- 13 files changed, 25 insertions(+), 45 deletions(-) -- 2.26.0

8 26

[PATCH v2 1/2] dt-bindings: display: panel: Add binding document for Leadtek LTK050H3146W
by Heiko Stuebner 08 Apr '20

08 Apr '20

From: Heiko Stuebner <heiko.stuebner(a)theobroma-systems.com> The LTK050H3146W is a 5.0" 720x1280 DSI display. changes in v2: - add display variants Signed-off-by: Heiko Stuebner <heiko.stuebner(a)theobroma-systems.com> --- .../display/panel/leadtek,ltk050h3146w.yaml | 51 +++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml diff --git a/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml new file mode 100644 index 000000000000..a372bdc5bde1 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/leadtek,ltk050h3146w.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Leadtek LTK050H3146W 5.0in 720x1280 DSI panel + +maintainers: + - Heiko Stuebner <heiko.stuebner(a)theobroma-systems.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + enum: + - leadtek,ltk050h3146w + - leadtek,ltk050h3146w-a2 + reg: true + backlight: true + reset-gpios: true + iovcc-supply: + description: regulator that supplies the iovcc voltage + vci-supply: + description: regulator that supplies the vci voltage + +required: + - compatible + - reg + - backlight + - iovcc-supply + - vci-supply + +additionalProperties: false + +examples: + - | + dsi { + #address-cells = <1>; + #size-cells = <0>; + panel@0 { + compatible = "leadtek,ltk050h3146w"; + reg = <0>; + backlight = <&backlight>; + iovcc-supply = <&vcc_1v8>; + vci-supply = <&vcc3v3_lcd>; + }; + }; + +... -- 2.24.1

2 3

[PATCH 0/2] drm/vkms: Add Virtual hardware module option
by Gabriela Bittencourt 08 Apr '20

08 Apr '20

Hi, I'm trying to implement the virtual hardware (virtual_hw) module option on VKMS module. The virtual hardware module option is implemented as an option to skip the timing and vblank subtests. The main idea of virtual_hw is shorten the time used on each period of operation. For this, the timer for counting the period is eliminated and the KMS configurations are implemented along with the standard atomic operations. During the 'atomic_enable' and 'atomic_disable' the vblank is initialized only if the virtual_hw is disabled (and therefore, the vblank is enabled). A kick of crc/vblank is decoupled from vblank_simulate. Case the vblank is disabled (that is, the vblank_simulate will never execute) a vkms_composer_work routine is added to the end of the atomic_flush. The IGT tests used to check the patch were the kms-flip, which kept the same results, with and without my alterations, with the exceptions of the tests that required vblank. The warning message and the related tests are presented below: Test requirement not met in function run_test_on_crtc_set, file ../tests/kms_flip.c:1285: Test requirement: vblank There is no VBlank Last errno: 95, Operation not supported - wf_vblank-ts-check - blocking-wf_vblank - absolute-wf_vblank - blocking-absolute-wf_vblank - busy-flip - plain-flip-ts-check - plain-flip-fb-recreate - flip-vs-expired-vblank - flip-vs-absolute-wf_vblank - basic-flip-vs-wf_vblank - flip-vs-blocking-wf-vblank - dpms-vs-vblank-race - modeset-vs-vblank-race - wf_vblank-ts-check-interruptible - absolute-wf_vblank-interruptible - blocking-absolute-wf_vblank-interruptible - plain-flip-ts-check-interruptible - plain-flip-fb-recreate-interruptible - flip-vs-expired-vblank-interruptible - flip-vs-absolute-wf_vblank-interruptible - flip-vs-wf_vblank-interruptible - dpms-vs-vblank-race-interruptible - modeset-vs-vblank-race-interruptible Any suggestions are very welcome :) Gabriela Bittencourt (2): drm/vkms: Rework vkms_vblank_simulate drm/vkms: Add 'virtual_hw' module option drivers/gpu/drm/vkms/vkms_crtc.c | 42 +++++++++++++++++++++++++++----- drivers/gpu/drm/vkms/vkms_drv.c | 13 ++++++++-- drivers/gpu/drm/vkms/vkms_drv.h | 2 ++ 3 files changed, 49 insertions(+), 8 deletions(-) -- 2.25.1

1 2

[git pull] drm fixes for 5.7-rc1
by Dave Airlie 08 Apr '20

08 Apr '20

Hi Linus, This is a set of fixes that have queued up, I think I might have another pull with some more before rc1 but I'd like to dequeue what I have now just in case Easter is more eggciting that expected. The main thing in here is a fix for a longstanding nouveau power management issues on certain laptops, it should help runtime suspend/resume for a lot of people. There is also a reverted patch for some drm_mm behaviour in atomic contexts. Dave. drm-next-2020-04-08: drm fixes for 5.7-rc1 core: - revert drm_mm atomic patch - dt binding fixes fbcon: - null ptr error fix i915: - GVT fixes nouveau: - runpm fix - svm fixes amdgpu: - HDCP fixes - gfx10 fix - Misc display fixes - BACO fixes amdkfd: - Fix memory leak vboxvideo: - remove conflicting fbs vc4: - mode validation fix xen: - fix PTR_ERR usage The following changes since commit 0e7e6198af28c1573267aba1be33dd0b7fb35691: Merge branch 'ttm-transhuge' of git://people.freedesktop.org/~thomash/linux into drm-next (2020-04-03 09:07:49 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-next-2020-04-08 for you to fetch changes up to 12ab316ced2c5f32ced0e6300a054db644b5444a: Merge tag 'amd-drm-next-5.7-2020-04-01' of git://people.freedesktop.org/~agd5f/linux into drm-next (2020-04-08 09:34:27 +1000) ---------------------------------------------------------------- drm fixes for 5.7-rc1 core: - revert drm_mm atomic patch - dt binding fixes fbcon: - null ptr error fix i915: - GVT fixes nouveau: - runpm fix - svm fixes amdgpu: - HDCP fixes - gfx10 fix - Misc display fixes - BACO fixes amdkfd: - Fix memory leak vboxvideo: - remove conflicting fbs vc4: - mode validation fix xen: - fix PTR_ERR usage ---------------------------------------------------------------- Aric Cyr (1): drm/amd/display: LFC not working on 2.0x range monitors (v2) Ben Skeggs (5): drm/nouveau/ttm: evict other IO mappings when running out of BAR1 space drm/nouveau/gr/gp107,gp108: implement workaround for HW hanging during init drm/nouveau/nvif: access PTIMER through usermode class, if available drm/nouveau/nvif: protect waits against GPU falling off the bus drm/nouveau/kms/nv50-: wait for FIFO space on PIO channels Bhawanpreet Lakha (3): drm/amd/display: Don't try hdcp1.4 when content_type is set to type1 drm/amd/display: Correctly cancel future watchdog and callback events drm/amd/display: increase HDCP authentication delay Christian König (1): drm/mm: revert "Break long searches in fragmented address spaces" Dave Airlie (4): Merge tag 'drm-intel-next-fixes-2020-04-02' of git://anongit.freedesktop.org/drm/drm-intel into drm-next Merge tag 'drm-misc-next-fixes-2020-04-04' of git://anongit.freedesktop.org/drm/drm-misc into drm-next Merge branch 'linux-5.7' of git://github.com/skeggsb/linux into drm-next Merge tag 'amd-drm-next-5.7-2020-04-01' of git://people.freedesktop.org/~agd5f/linux into drm-next Ding Xiang (1): drm/xen: fix passing zero to 'PTR_ERR' warning Dmytro Laktyushkin (1): drm/amd/display: Fix dcn21 num_states Eric Bernstein (1): drm/amd/display: Update function to get optimal number of taps Evan Quan (2): drm/amd/powerplay: drop redundant BIF doorbell interrupt operations drm/amd/powerplay: move the ASIC specific nbio operation out of smu_v11_0.c Geert Uytterhoeven (1): dma-buf: Improve CONFIG_DMABUF_MOVE_NOTIFY help text Hans de Goede (1): drm/vboxvideo: Add missing remove_conflicting_pci_framebuffers call, v2 Isabel Zhang (1): drm/amd/display: Revert change to HDCP display states Jack Zhang (1): drm/amdkfd: kfree the wrong pointer Karol Herbst (1): drm/nouveau: workaround runpm fail by disabling PCI power management on certain intel bridges Kevin Wang (1): drm/amdgpu: fix hpd bo size calculation error Mauro Carvalho Chehab (1): docs: dt: display/ti: fix typos at the devicetree/ directory name Nicholas Kazlauskas (1): drm/amd/display: Use double buffered DRR timing update by default Nicolas Saenz Julienne (1): drm/vc4: Fix HDMI mode validation Qiujun Huang (1): fbcon: fix null-ptr-deref in fbcon_switch Ralph Campbell (3): drm/nouveau/svm: fix vma range check for migration drm/nouveau/svm: check for SVM initialized before migrating drm/nouveau/svm: remove useless SVM range check Rob Herring (1): dt-bindings: display: ti: Fix dtc unit-address warnings in examples Rodrigo Vivi (1): Merge tag 'gvt-next-fixes-2020-03-31' of https://github.com/intel/gvt-linux into drm-intel-next-fixes Sam Ravnborg (2): dt-bindings: display: drop data-mapping from panel-dpi drm/panel-simple: drop use of data-mapping property Stylon Wang (3): drm/amd/display: Support P010 pixel format drm/amd/display: Support plane level CTM drm/amd/display: Enable BT2020 in COLOR_ENCODING property Tina Zhang (3): drm/i915/gvt: Add some regs to force-to-nonpriv whitelist drm/i915/gvt: Fix display port type issue drm/i915/gvt: Fix klocwork issues about data size Wambui Karuga (1): drm/nouveau: remove checks for return value of debugfs functions Yan Zhao (2): drm/i915/gvt: add support to command SWTESS_BASE_ADDRESS drm/i915/gvt: do not check len & max_len for lri Yongqiang Sun (1): drm/amd/display: Not doing optimize bandwidth if flip pending. .../bindings/display/panel/panel-dpi.yaml | 10 ---- .../bindings/display/ti/ti,am65x-dss.yaml | 4 +- .../bindings/display/ti/ti,j721e-dss.yaml | 4 +- .../devicetree/bindings/display/ti/ti,k2g-dss.yaml | 4 +- drivers/dma-buf/Kconfig | 11 ++-- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_device.c | 4 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 ++++- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c | 14 +++-- drivers/gpu/drm/amd/display/dc/core/dc.c | 33 +++++++++++- drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 1 + drivers/gpu/drm/amd/display/dc/dc.h | 3 ++ .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 6 +++ drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c | 18 +++++++ drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.h | 3 ++ .../gpu/drm/amd/display/dc/dcn10/dcn10_resource.c | 3 +- .../gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 5 +- .../gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 40 +++++--------- drivers/gpu/drm/amd/display/dc/dml/dc_features.h | 2 +- .../drm/amd/display/dc/dml/display_mode_structs.h | 7 +-- .../drm/amd/display/modules/freesync/freesync.c | 34 ++++++------ drivers/gpu/drm/amd/display/modules/hdcp/hdcp.c | 5 +- drivers/gpu/drm/amd/display/modules/hdcp/hdcp.h | 28 +++++++--- .../drm/amd/display/modules/hdcp/hdcp1_execution.c | 2 +- .../drm/amd/display/modules/hdcp/hdcp2_execution.c | 2 +- .../gpu/drm/amd/display/modules/hdcp/hdcp_psp.c | 39 ++++++++------ drivers/gpu/drm/amd/display/modules/inc/mod_hdcp.h | 1 + drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 15 +++++- drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 18 ++++++- drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 24 +-------- drivers/gpu/drm/amd/powerplay/vega20_ppt.c | 14 ++++- drivers/gpu/drm/drm_mm.c | 8 +-- drivers/gpu/drm/i915/gvt/cmd_parser.c | 16 ++---- drivers/gpu/drm/i915/gvt/display.c | 6 +-- drivers/gpu/drm/i915/gvt/handlers.c | 8 ++- drivers/gpu/drm/i915/gvt/scheduler.c | 4 +- drivers/gpu/drm/nouveau/dispnv04/dac.c | 3 +- drivers/gpu/drm/nouveau/dispnv04/hw.c | 1 + drivers/gpu/drm/nouveau/dispnv50/base507c.c | 1 + drivers/gpu/drm/nouveau/dispnv50/core507d.c | 1 + drivers/gpu/drm/nouveau/dispnv50/corec37d.c | 2 + drivers/gpu/drm/nouveau/dispnv50/curs507a.c | 21 ++++++-- drivers/gpu/drm/nouveau/dispnv50/cursc37a.c | 9 ++-- drivers/gpu/drm/nouveau/dispnv50/disp.c | 1 + drivers/gpu/drm/nouveau/dispnv50/ovly827e.c | 2 + drivers/gpu/drm/nouveau/dispnv50/wndw.h | 1 + drivers/gpu/drm/nouveau/include/nvif/device.h | 21 -------- drivers/gpu/drm/nouveau/include/nvif/timer.h | 35 ++++++++++++ drivers/gpu/drm/nouveau/include/nvif/user.h | 1 + drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +++- drivers/gpu/drm/nouveau/nouveau_debugfs.c | 20 +++---- drivers/gpu/drm/nouveau/nouveau_drm.c | 63 ++++++++++++++++++++++ drivers/gpu/drm/nouveau/nouveau_drv.h | 2 + drivers/gpu/drm/nouveau/nouveau_svm.c | 9 ++-- drivers/gpu/drm/nouveau/nvif/Kbuild | 1 + drivers/gpu/drm/nouveau/nvif/device.c | 14 +++-- drivers/gpu/drm/nouveau/nvif/timer.c | 56 +++++++++++++++++++ drivers/gpu/drm/nouveau/nvif/userc361.c | 14 +++++ drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c | 26 +++++++++ drivers/gpu/drm/panel/panel-simple.c | 11 ---- drivers/gpu/drm/vboxvideo/vbox_drv.c | 4 ++ drivers/gpu/drm/vc4/vc4_hdmi.c | 20 +++++-- drivers/gpu/drm/xen/xen_drm_front.c | 2 +- drivers/video/fbdev/core/fbcon.c | 3 ++ 65 files changed, 538 insertions(+), 227 deletions(-) create mode 100644 drivers/gpu/drm/nouveau/include/nvif/timer.h create mode 100644 drivers/gpu/drm/nouveau/nvif/timer.c

2 1

[PATCH] drm/i915: check to see if the FPU is available before using it
by Jason A. Donenfeld 08 Apr '20

08 Apr '20

It's not safe to just grab the FPU willy nilly without first checking to see if it's available. This patch adds the usual call to may_use_simd() and falls back to boring memcpy if it's not available. Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com> --- drivers/gpu/drm/i915/i915_memcpy.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_memcpy.c b/drivers/gpu/drm/i915/i915_memcpy.c index fdd550405fd3..7c0e022586bc 100644 --- a/drivers/gpu/drm/i915/i915_memcpy.c +++ b/drivers/gpu/drm/i915/i915_memcpy.c @@ -24,6 +24,7 @@ #include <linux/kernel.h> #include <asm/fpu/api.h> +#include <asm/simd.h> #include "i915_memcpy.h" @@ -38,6 +39,12 @@ static DEFINE_STATIC_KEY_FALSE(has_movntdqa); #ifdef CONFIG_AS_MOVNTDQA static void __memcpy_ntdqa(void *dst, const void *src, unsigned long len) { + if (unlikely(!may_use_simd())) { + memcpy(dst, src, len); + return; + } + + kernel_fpu_begin(); while (len >= 4) { @@ -67,6 +74,11 @@ static void __memcpy_ntdqa(void *dst, const void *src, unsigned long len) static void __memcpy_ntdqu(void *dst, const void *src, unsigned long len) { + if (unlikely(!may_use_simd())) { + memcpy(dst, src, len); + return; + } + kernel_fpu_begin(); while (len >= 4) { -- 2.26.0

2 2

[PATCH 1/2] dt-bindings: display: panel: Add binding document for Leadtek LTK050H3146W
by Heiko Stuebner 07 Apr '20

07 Apr '20

From: Heiko Stuebner <heiko.stuebner(a)theobroma-systems.com> The LTK050H3146W is a 5.0" 720x1280 DSI display. Signed-off-by: Heiko Stuebner <heiko.stuebner(a)theobroma-systems.com> --- .../display/panel/leadtek,ltk050h3146w.yaml | 49 +++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml diff --git a/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml new file mode 100644 index 000000000000..91a0212b63b2 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/leadtek,ltk050h3146w.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Leadtek LTK050H3146W 5.0in 720x1280 DSI panel + +maintainers: + - Heiko Stuebner <heiko.stuebner(a)theobroma-systems.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: leadtek,ltk050h3146w + reg: true + backlight: true + reset-gpios: true + iovcc-supply: + description: regulator that supplies the iovcc voltage + vci-supply: + description: regulator that supplies the vci voltage + +required: + - compatible + - reg + - backlight + - iovcc-supply + - vci-supply + +additionalProperties: false + +examples: + - | + dsi { + #address-cells = <1>; + #size-cells = <0>; + panel@0 { + compatible = "leadtek,ltk050h3146w"; + reg = <0>; + backlight = <&backlight>; + iovcc-supply = <&vcc_1v8>; + vci-supply = <&vcc3v3_lcd>; + }; + }; + +... -- 2.24.1

2 2

Curtaining API / Force blanking displays
by Erik Jensen 07 Apr '20

07 Apr '20

First off, apologies if the functionality described already exists and I just failed to find it, or if this isn't the correct venue for this discussion. If so, pointers to the correct location would be appreciated. I'm currently looking into the feasibility of developing a remote access tool using kernel-level interfaces (e.g., drmModeGetFB and uinput) to operate regardless of whether the user is using Xorg, a Wayland compositor, or even a text console (assuming KMS is in use). One of the requirements, however, is the remote user is able to "curtain" their session in order to prevent individuals near the physical machine from watching their session. Imagine a user working from home and connecting to their workstation in a shared office space. One possible solution I came up with would be a new kernel API to allow a privileged process other than the DRM-Master to request that all displays of a card be blanked or left in power saving mode. This wouldn't affect the ability of the DRM-Master to change modes and layout configuration, but no content would be visible on the physical displays until the curtaining process ended the curtain or exited. Is this (a) a good approach to solving this issue, (b) an API that, if implemented, would be likely to be accepted into the kernel, and (c) something that would be feasible to implement given the current architecture? E.g., would it require changes in individual drivers, or could it be managed solely in driver-independent kernel code? I'm new to DRI development, so if it is something that folks would be open to having, pointers to a good part of the code to look at to start implementing such a feature would be appreciated. Thanks!

5 8

[PATCH] gpu/drm: ingenic: Delete an error message in ingenic_drm_probe()
by Markus Elfring 07 Apr '20

07 Apr '20

From: Markus Elfring <elfring(a)users.sourceforge.net> Date: Sun, 5 Apr 2020 11:25:30 +0200 The function “platform_get_irq” can log an error already. Thus omit a redundant message for the exception handling in the calling function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring(a)users.sourceforge.net> --- drivers/gpu/drm/ingenic/ingenic-drm.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c b/drivers/gpu/drm/ingenic/ingenic-drm.c index 9dfe7cb530e1..06ca752b76ee 100644 --- a/drivers/gpu/drm/ingenic/ingenic-drm.c +++ b/drivers/gpu/drm/ingenic/ingenic-drm.c @@ -661,10 +661,8 @@ static int ingenic_drm_probe(struct platform_device *pdev) } irq = platform_get_irq(pdev, 0); - if (irq < 0) { - dev_err(dev, "Failed to get platform irq"); + if (irq < 0) return irq; - } if (soc_info->needs_dev_clk) { priv->lcd_clk = devm_clk_get(dev, "lcd"); -- 2.26.0

2 2

[PATCH v5 1/2] dt-bindings: display: convert rockchip vop bindings to yaml
by Johan Jonker 07 Apr '20

07 Apr '20

Current dts files with 'vop' nodes are manually verified. In order to automate this process rockchip-vop.txt has to be converted to yaml. Signed-off-by: Johan Jonker <jbx6244(a)gmail.com> Reviewed-by: Rob Herring <robh(a)kernel.org> --- Changes v5: Add reviewed by Fix irq.h already included in arm-gic.h Changes v4: Change description Replace compatible oneOf by enum Change interrupts description Remove resets minItems Changes v3: Change description Changes v2: No new properties --- .../bindings/display/rockchip/rockchip-vop.txt | 74 ------------- .../bindings/display/rockchip/rockchip-vop.yaml | 123 +++++++++++++++++++++ 2 files changed, 123 insertions(+), 74 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt deleted file mode 100644 index 8b3a5f514..000000000 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt +++ /dev/null @@ -1,74 +0,0 @@ -device-tree bindings for rockchip soc display controller (vop) - -VOP (Visual Output Processor) is the Display Controller for the Rockchip -series of SoCs which transfers the image data from a video memory -buffer to an external LCD interface. - -Required properties: -- compatible: value should be one of the following - "rockchip,rk3036-vop"; - "rockchip,rk3126-vop"; - "rockchip,px30-vop-lit"; - "rockchip,px30-vop-big"; - "rockchip,rk3066-vop"; - "rockchip,rk3188-vop"; - "rockchip,rk3288-vop"; - "rockchip,rk3368-vop"; - "rockchip,rk3366-vop"; - "rockchip,rk3399-vop-big"; - "rockchip,rk3399-vop-lit"; - "rockchip,rk3228-vop"; - "rockchip,rk3328-vop"; - -- reg: Must contain one entry corresponding to the base address and length - of the register space. Can optionally contain a second entry - corresponding to the CRTC gamma LUT address. - -- interrupts: should contain a list of all VOP IP block interrupts in the - order: VSYNC, LCD_SYSTEM. The interrupt specifier - format depends on the interrupt controller used. - -- clocks: must include clock specifiers corresponding to entries in the - clock-names property. - -- clock-names: Must contain - aclk_vop: for ddr buffer transfer. - hclk_vop: for ahb bus to R/W the phy regs. - dclk_vop: pixel clock. - -- resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names: Must include the following entries: - - axi - - ahb - - dclk - -- iommus: required a iommu node - -- port: A port node with endpoint definitions as defined in - Documentation/devicetree/bindings/media/video-interfaces.txt. - -Example: -SoC specific DT entry: - vopb: vopb@ff930000 { - compatible = "rockchip,rk3288-vop"; - reg = <0x0 0xff930000 0x0 0x19c>, <0x0 0xff931000 0x0 0x1000>; - interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>; - clock-names = "aclk_vop", "dclk_vop", "hclk_vop"; - resets = <&cru SRST_LCDC1_AXI>, <&cru SRST_LCDC1_AHB>, <&cru SRST_LCDC1_DCLK>; - reset-names = "axi", "ahb", "dclk"; - iommus = <&vopb_mmu>; - vopb_out: port { - #address-cells = <1>; - #size-cells = <0>; - vopb_out_edp: endpoint@0 { - reg = <0>; - remote-endpoint=<&edp_in_vopb>; - }; - vopb_out_hdmi: endpoint@1 { - reg = <1>; - remote-endpoint=<&hdmi_in_vopb>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml new file mode 100644 index 000000000..42ee2b5c3 --- /dev/null +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.yaml @@ -0,0 +1,123 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/rockchip/rockchip-vop.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip SoC display controller (VOP) + +description: + VOP (Video Output Processor) is the display controller for the Rockchip + series of SoCs which transfers the image data from a video memory + buffer to an external LCD interface. + +maintainers: + - Sandy Huang <hjc(a)rock-chips.com> + - Heiko Stuebner <heiko(a)sntech.de> + +properties: + compatible: + enum: + - rockchip,px30-vop-big + - rockchip,px30-vop-lit + - rockchip,rk3036-vop + - rockchip,rk3066-vop + - rockchip,rk3126-vop + - rockchip,rk3188-vop + - rockchip,rk3228-vop + - rockchip,rk3288-vop + - rockchip,rk3328-vop + - rockchip,rk3366-vop + - rockchip,rk3368-vop + - rockchip,rk3399-vop-big + - rockchip,rk3399-vop-lit + + reg: + minItems: 1 + items: + - description: + Must contain one entry corresponding to the base address and length + of the register space. + - description: + Can optionally contain a second entry corresponding to + the CRTC gamma LUT address. + + interrupts: + maxItems: 1 + description: + The VOP interrupt is shared by several interrupt sources, such as + frame start (VSYNC), line flag and other status interrupts. + + clocks: + items: + - description: Clock for ddr buffer transfer. + - description: Pixel clock. + - description: Clock for the ahb bus to R/W the phy regs. + + clock-names: + items: + - const: aclk_vop + - const: dclk_vop + - const: hclk_vop + + resets: + maxItems: 3 + + reset-names: + items: + - const: axi + - const: ahb + - const: dclk + + port: + type: object + description: + A port node with endpoint definitions as defined in + Documentation/devicetree/bindings/media/video-interfaces.txt. + + iommus: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - resets + - reset-names + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/rk3288-cru.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + vopb: vopb@ff930000 { + compatible = "rockchip,rk3288-vop"; + reg = <0x0 0xff930000 0x0 0x19c>, + <0x0 0xff931000 0x0 0x1000>; + interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cru ACLK_VOP0>, + <&cru DCLK_VOP0>, + <&cru HCLK_VOP0>; + clock-names = "aclk_vop", "dclk_vop", "hclk_vop"; + resets = <&cru SRST_LCDC1_AXI>, + <&cru SRST_LCDC1_AHB>, + <&cru SRST_LCDC1_DCLK>; + reset-names = "axi", "ahb", "dclk"; + iommus = <&vopb_mmu>; + vopb_out: port { + #address-cells = <1>; + #size-cells = <0>; + vopb_out_edp: endpoint@0 { + reg = <0>; + remote-endpoint=<&edp_in_vopb>; + }; + vopb_out_hdmi: endpoint@1 { + reg = <1>; + remote-endpoint=<&hdmi_in_vopb>; + }; + }; + }; -- 2.11.0

2 2

← Newer
1
...
82
83
84
85
86
87
88
...
95
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2020