dri-devel January 2021

dri-devel@lists.freedesktop.org

322 participants
737 discussions

[PATCH] drm/rockchip: Require the YTR modifier for AFBC
by Alyssa Rosenzweig 26 Feb '21

26 Feb '21

The AFBC decoder used in the Rockchip VOP assumes the use of the YUV-like colourspace transform (YTR). YTR is lossless for RGB(A) buffers, which covers the RGBA8 and RGB565 formats supported in vop_convert_afbc_format. Use of YTR is signaled with the AFBC_FORMAT_MOD_YTR modifier, which prior to this commit was missing. As such, a producer would have to generate buffers that do not use YTR, which the VOP would erroneously decode as YTR, leading to severe visual corruption. The upstream AFBC support was developed against a captured frame, which failed to exercise modifier support. Prior to bring-up of AFBC in Mesa (in the Panfrost driver), no open userspace respected modifier reporting. As such, this change is not expected to affect broken userspaces. Tested on RK3399 with Panfrost and Weston. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig(a)collabora.com> --- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h index 4a2099cb5..857d97cdc 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h @@ -17,9 +17,20 @@ #define NUM_YUV2YUV_COEFFICIENTS 12 +/* AFBC supports a number of configurable modes. Relevant to us is block size + * (16x16 or 32x8), storage modifiers (SPARSE, SPLIT), and the YUV-like + * colourspace transform (YTR). 16x16 SPARSE mode is always used. SPLIT mode + * could be enabled via the hreg_block_split register, but is not currently + * handled. The colourspace transform is implicitly always assumed by the + * decoder, so consumers must use this transform as well. + * + * Failure to match modifiers will cause errors displaying AFBC buffers + * produced by conformant AFBC producers, including Mesa. + */ #define ROCKCHIP_AFBC_MOD \ DRM_FORMAT_MOD_ARM_AFBC( \ AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 | AFBC_FORMAT_MOD_SPARSE \ + | AFBC_FORMAT_MOD_YTR \ ) enum vop_data_format { -- 2.28.0

8 18

[PATCH v4 00/14] RFC Support hot device unplug in amdgpu
by Andrey Grodzovsky 25 Feb '21

25 Feb '21

Until now extracting a card either by physical extraction (e.g. eGPU with thunderbolt connection or by emulation through syfs -> /sys/bus/pci/devices/device_id/remove) would cause random crashes in user apps. The random crashes in apps were mostly due to the app having mapped a device backed BO into its address space was still trying to access the BO while the backing device was gone. To answer this first problem Christian suggested to fix the handling of mapped memory in the clients when the device goes away by forcibly unmap all buffers the user processes has by clearing their respective VMAs mapping the device BOs. Then when the VMAs try to fill in the page tables again we check in the fault handlerif the device is removed and if so, return an error. This will generate a SIGBUS to the application which can then cleanly terminate.This indeed was done but this in turn created a problem of kernel OOPs were the OOPSes were due to the fact that while the app was terminating because of the SIGBUSit would trigger use after free in the driver by calling to accesses device structures that were already released from the pci remove sequence.This was handled by introducing a 'flush' sequence during device removal were we wait for drm file reference to drop to 0 meaning all user clients directly using this device terminated. v2: Based on discussions in the mailing list with Daniel and Pekka [1] and based on the document produced by Pekka from those discussions [2] the whole approach with returning SIGBUS and waiting for all user clients having CPU mapping of device BOs to die was dropped. Instead as per the document suggestion the device structures are kept alive until the last reference to the device is dropped by user client and in the meanwhile all existing and new CPU mappings of the BOs belonging to the device directly or by dma-buf import are rerouted to per user process dummy rw page.Also, I skipped the 'Requirements for KMS UAPI' section of [2] since i am trying to get the minimal set of requirements that still give useful solution to work and this is the'Requirements for Render and Cross-Device UAPI' section and so my test case is removing a secondary device, which is render only and is not involved in KMS. v3: More updates following comments from v2 such as removing loop to find DRM file when rerouting page faults to dummy page,getting rid of unnecessary sysfs handling refactoring and moving prevention of GPU recovery post device unplug from amdgpu to scheduler layer. On top of that added unplug support for the IOMMU enabled system. v4: Drop last sysfs hack and use sysfs default attribute. Guard against write accesses after device removal to avoid modifying released memory. Update dummy pages handling to on demand allocation and release through drm managed framework. Add return value to scheduler job TO handler (by Luben Tuikov) and use this in amdgpu for prevention of GPU recovery post device unplug Also rebase on top of drm-misc-mext instead of amd-staging-drm-next With these patches I am able to gracefully remove the secondary card using sysfs remove hook while glxgears is running off of secondary card (DRI_PRIME=1) without kernel oopses or hangs and keep working with the primary card or soft reset the device without hangs or oopses TODOs for followup work: Convert AMDGPU code to use devm (for hw stuff) and drmm (for sw stuff and allocations) (Daniel) Support plugging the secondary device back after unplug - currently still experiencing HW error on plugging back. Add support for 'Requirements for KMS UAPI' section of [2] - unplugging primary, display connected card. [1] - Discussions during v3 of the patchset https://www.spinics.net/lists/amd-gfx/msg55576.html [2] - drm/doc: device hot-unplug for userspace https://www.spinics.net/lists/dri-devel/msg259755.html [3] - Related gitlab ticket https://gitlab.freedesktop.org/drm/amd/-/issues/1081 Andrey Grodzovsky (13): drm/ttm: Remap all page faults to per process dummy page. drm: Unamp the entire device address space on device unplug drm/ttm: Expose ttm_tt_unpopulate for driver use drm/sched: Cancel and flush all oustatdning jobs before finish. drm/amdgpu: Split amdgpu_device_fini into early and late drm/amdgpu: Add early fini callback drm/amdgpu: Register IOMMU topology notifier per device. drm/amdgpu: Fix a bunch of sdma code crash post device unplug drm/amdgpu: Remap all page faults to per process dummy page. dmr/amdgpu: Move some sysfs attrs creation to default_attr drm/amdgpu: Guard against write accesses after device removal drm/sched: Make timeout timer rearm conditional. drm/amdgpu: Prevent any job recoveries after device is unplugged. Luben Tuikov (1): drm/scheduler: Job timeout handler returns status drivers/gpu/drm/amd/amdgpu/amdgpu.h | 11 +- drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 17 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 149 ++++++++++++++++++++-- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 20 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 15 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gart.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 9 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 25 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 26 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 19 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 12 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 10 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 53 +++++--- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 3 + drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 70 ++++++++++ drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 52 +------- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 21 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 14 +- drivers/gpu/drm/amd/amdgpu/cik_ih.c | 2 +- drivers/gpu/drm/amd/amdgpu/cz_ih.c | 2 +- drivers/gpu/drm/amd/amdgpu/iceland_ih.c | 2 +- drivers/gpu/drm/amd/amdgpu/navi10_ih.c | 2 +- drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 16 +-- drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 8 +- drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 8 +- drivers/gpu/drm/amd/amdgpu/si_ih.c | 2 +- drivers/gpu/drm/amd/amdgpu/tonga_ih.c | 2 +- drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 2 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 +- drivers/gpu/drm/amd/include/amd_shared.h | 2 + drivers/gpu/drm/drm_drv.c | 3 + drivers/gpu/drm/etnaviv/etnaviv_sched.c | 10 +- drivers/gpu/drm/lima/lima_sched.c | 4 +- drivers/gpu/drm/panfrost/panfrost_job.c | 9 +- drivers/gpu/drm/scheduler/sched_main.c | 18 ++- drivers/gpu/drm/ttm/ttm_bo_vm.c | 82 +++++++++++- drivers/gpu/drm/ttm/ttm_tt.c | 1 + drivers/gpu/drm/v3d/v3d_sched.c | 32 ++--- include/drm/gpu_scheduler.h | 17 ++- include/drm/ttm/ttm_bo_api.h | 2 + 45 files changed, 583 insertions(+), 198 deletions(-) -- 2.7.4

9 96

[PATCH 01/15] drm/arc: Switch to devm_drm_dev_alloc
by Daniel Vetter 25 Feb '21

25 Feb '21

- Need to embedded the drm_device, but for now we keep the usual pointer chasing. - No more devm_kzalloc, which fixes a lifetime issues on driver remove. - No more drm_dev_put, that's done by devm_ now. Acked-by: Sam Ravnborg <sam(a)ravnborg.org> Cc: Eugeniy Paltsev <Eugeniy.Paltsev(a)synopsys.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Alexey Brodkin <abrodkin(a)synopsys.com> --- drivers/gpu/drm/arc/arcpgu.h | 1 + drivers/gpu/drm/arc/arcpgu_drv.c | 33 +++++++++++++------------------- 2 files changed, 14 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h index 6aac44b953ad..cd9e932f501e 100644 --- a/drivers/gpu/drm/arc/arcpgu.h +++ b/drivers/gpu/drm/arc/arcpgu.h @@ -9,6 +9,7 @@ #define _ARCPGU_H_ struct arcpgu_drm_private { + struct drm_device drm; void __iomem *regs; struct clk *clk; struct drm_framebuffer *fb; diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c index f164818ec477..68eb4a31c54b 100644 --- a/drivers/gpu/drm/arc/arcpgu_drv.c +++ b/drivers/gpu/drm/arc/arcpgu_drv.c @@ -42,18 +42,14 @@ static void arcpgu_setup_mode_config(struct drm_device *drm) DEFINE_DRM_GEM_CMA_FOPS(arcpgu_drm_ops); -static int arcpgu_load(struct drm_device *drm) +static int arcpgu_load(struct arcpgu_drm_private *arcpgu) { - struct platform_device *pdev = to_platform_device(drm->dev); - struct arcpgu_drm_private *arcpgu; + struct platform_device *pdev = to_platform_device(arcpgu->drm.dev); struct device_node *encoder_node = NULL, *endpoint_node = NULL; + struct drm_device *drm = &arcpgu->drm; struct resource *res; int ret; - arcpgu = devm_kzalloc(&pdev->dev, sizeof(*arcpgu), GFP_KERNEL); - if (arcpgu == NULL) - return -ENOMEM; - drm->dev_private = arcpgu; arcpgu->clk = devm_clk_get(drm->dev, "pxlclk"); @@ -162,30 +158,28 @@ static struct drm_driver arcpgu_drm_driver = { static int arcpgu_probe(struct platform_device *pdev) { - struct drm_device *drm; + struct arcpgu_drm_private *arcpgu; int ret; - drm = drm_dev_alloc(&arcpgu_drm_driver, &pdev->dev); - if (IS_ERR(drm)) - return PTR_ERR(drm); + arcpgu = devm_drm_dev_alloc(&pdev->dev, &arcpgu_drm_driver, + struct arcpgu_drm_private, drm); + if (IS_ERR(arcpgu)) + return PTR_ERR(arcpgu); - ret = arcpgu_load(drm); + ret = arcpgu_load(arcpgu); if (ret) - goto err_unref; + return ret; - ret = drm_dev_register(drm, 0); + ret = drm_dev_register(&arcpgu->drm, 0); if (ret) goto err_unload; - drm_fbdev_generic_setup(drm, 16); + drm_fbdev_generic_setup(&arcpgu->drm, 16); return 0; err_unload: - arcpgu_unload(drm); - -err_unref: - drm_dev_put(drm); + arcpgu_unload(&arcpgu->drm); return ret; } @@ -196,7 +190,6 @@ static int arcpgu_remove(struct platform_device *pdev) drm_dev_unregister(drm); arcpgu_unload(drm); - drm_dev_put(drm); return 0; } -- 2.29.2

3 18

[PATCH v4 0/3] Add MIPI rx DPI support
by Xin Ji 25 Feb '21

25 Feb '21

Hi all, this patch series implement MIPI rx DPI feature. Please help to review. This is the v4 version, any mistakes, please let me know, I'll fix it in the next series. Change history: v4: Fix Rob Herring comment - Rebase code on the branch 'drm-misc-next' - Change 'analogix,hdcp-support' type to boolean v3: Fix Rob Herring, Dan Carpenter, Nicolas comment - Split the patch, fix not correct return data - Fix several coding format - Split DP tx swing register setting to two property - Add HDCP support vender flag - remove 'analogix,swing-setting' and 'analogix,mipi-dpi-in' property v2: Fix Rob Herring comment - Fix yamllint warnings/errors in analogix,anx7625.yaml - Fix kernel robot compile warning v1: initial MIPI rx DPI feature support Xin Ji (3): dt-bindings:drm/bridge:anx7625:add vendor define flags drm/bridge: anx7625: fix not correct return value drm/bridge: anx7625: add MIPI DPI input feature support .../bindings/display/bridge/analogix,anx7625.yaml | 54 +++- drivers/gpu/drm/bridge/analogix/anx7625.c | 330 +++++++++++++++++---- drivers/gpu/drm/bridge/analogix/anx7625.h | 20 +- 3 files changed, 340 insertions(+), 64 deletions(-) -- 2.7.4

4 14

[PATCH 1/3] drivers/nouveau/kms/nv50-: Reject format modifiers for cursor planes
by Lyude Paul 24 Feb '21

24 Feb '21

Nvidia hardware doesn't actually support using tiling formats with the cursor plane, only linear is allowed. In the future, we should write a testcase for this. Fixes: c586f30bf74c ("drm/nouveau/kms: Add format mod prop to base/ovly/nvdisp") Cc: James Jones <jajones(a)nvidia.com> Cc: Martin Peres <martin.peres(a)free.fr> Cc: Jeremy Cline <jcline(a)redhat.com> Cc: Simon Ser <contact(a)emersion.fr> Cc: <stable(a)vger.kernel.org> # v5.8+ Signed-off-by: Lyude Paul <lyude(a)redhat.com> --- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c b/drivers/gpu/drm/nouveau/dispnv50/wndw.c index ce451242f79e..271de3a63f21 100644 --- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c +++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c @@ -702,6 +702,11 @@ nv50_wndw_init(struct nv50_wndw *wndw) nvif_notify_get(&wndw->notify); } +static const u64 nv50_cursor_format_modifiers[] = { + DRM_FORMAT_MOD_LINEAR, + DRM_FORMAT_MOD_INVALID, +}; + int nv50_wndw_new_(const struct nv50_wndw_func *func, struct drm_device *dev, enum drm_plane_type type, const char *name, int index, @@ -713,6 +718,7 @@ nv50_wndw_new_(const struct nv50_wndw_func *func, struct drm_device *dev, struct nvif_mmu *mmu = &drm->client.mmu; struct nv50_disp *disp = nv50_disp(dev); struct nv50_wndw *wndw; + const u64 *format_modifiers; int nformat; int ret; @@ -728,10 +734,13 @@ nv50_wndw_new_(const struct nv50_wndw_func *func, struct drm_device *dev, for (nformat = 0; format[nformat]; nformat++); - ret = drm_universal_plane_init(dev, &wndw->plane, heads, &nv50_wndw, - format, nformat, - nouveau_display(dev)->format_modifiers, - type, "%s-%d", name, index); + if (type == DRM_PLANE_TYPE_CURSOR) + format_modifiers = nv50_cursor_format_modifiers; + else + format_modifiers = nouveau_display(dev)->format_modifiers; + + ret = drm_universal_plane_init(dev, &wndw->plane, heads, &nv50_wndw, format, nformat, + format_modifiers, type, "%s-%d", name, index); if (ret) { kfree(*pwndw); *pwndw = NULL; -- 2.29.2

6 21

[PATCH 1/2] dt-bindings: display: bridge: Add documentation for SN65DSI84
by Jagan Teki 24 Feb '21

24 Feb '21

SN65DSI84 is a Single Channel DSI to Dual-link LVDS bridge from Texas Instruments. SN65DSI83, SN65DSI85 are variants of the same family of bridge controllers. Right now the bridge driver is supporting a single link, dual-link support requires to initiate I2C Channel B registers, so dt-bindings documented with single link LVDS. Signed-off-by: Jagan Teki <jagan(a)amarulasolutions.com> --- .../bindings/display/bridge/ti,sn65dsi84.yaml | 127 ++++++++++++++++++ 1 file changed, 127 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi84.yaml diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi84.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi84.yaml new file mode 100644 index 000000000000..891382a76c1a --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi84.yaml @@ -0,0 +1,127 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi84.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI SN65DSI84 MIPI DSI to LVDS bridge bindings + +maintainers: + - Jagan Teki <jagan(a)amarulasolutions.com> + +description: | + The SN65DSI84 DSI to FlatLink bridge features a single channel MIPI D-PHY receiver + front-end configuration with 4 lanes per channel operating at 1 Gbps per lanes. + The bridge decodes MIPI DSI 18bpp RGB666 and 240bpp RG888 packets and converts + the formatted video data stream to a FlatLink compatible LVDS output operating + at pixel clocks operating from 25 MHx to 154 MHz, offering a Dual-Link LVDS, + Single-Link LVDS interface with four data lanes per link. + + https://www.ti.com/product/SN65DSI84 + +properties: + compatible: + const: ti,sn65dsi84 + + reg: + maxItems: 1 + description: i2c address of the bridge, 0x2c + + enable-gpios: + maxItems: 1 + description: GPIO specifier for bridge enable pin (active high). + + ports: + type: object + description: + A node containing input and output port nodes with endpoint definitions + as documented in + Documentation/devicetree/bindings/media/video-interfaces.txt + properties: + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + port@0: + type: object + description: | + DSI Input. The remote endpoint phandle should be a + reference to a valid mipi_dsi_host device node. + + port@1: + type: object + description: | + Video port for LVDS output (panel or connector). + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - enable-gpios + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dsi_in: endpoint { + remote-endpoint = <&ltdc_ep0_out>; + }; + }; + + port@1 { + reg = <1>; + dsi_out: endpoint { + remote-endpoint = <&bridge_in>; + data-lanes = <0 1>; + }; + }; + }; + }; + + i2c6 { + #address-cells = <1>; + #size-cells = <0>; + + bridge@2c { + compatible = "ti,sn65dsi84"; + reg = <0x2c>; + enable-gpios = <&gpiof 15 GPIO_ACTIVE_HIGH>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + bridge_in: endpoint { + remote-endpoint = <&dsi_out>; + }; + }; + + port@1 { + reg = <1>; + bridge_out: endpoint { + remote-endpoint = <&panel_in_lvds>; + }; + }; + }; + }; + }; -- 2.25.1

4 7

[PATCH 4/5] drm/nouveau/kms/nvd9-nv138: Fix CRC calculation for the cursor channel
by Lyude Paul 23 Feb '21

23 Feb '21

While working on igt support for nouveau, I noticed that CRC calculation appeared to be broken when the cursor channel was being used. For example, if I had an igt test that would compare a software rendered image of a completely black fb with a green square in it, and then attempt to reproduce that image by positioning the cursor channel and setting it to a green rectangle, the CRCs output by the hardware would differ between the reference fb's CRC and the output's CRC. This was bizarre particularly because through use of the Chamelium I have, I was able to confirm that the image coming out of the display was identical between the reference and output. As well, the issue wouldn't happen when using the outp CRC sources that use the SF CRC source (so, DisplayPort) - only sources using the SOR CRC source (so, everything other then DisplayPort and VGA). It also didn't happen with the ovly plane, only the cursor plane. Eventually I noticed 0x00000040 being set in the default state cache values for the CRC methods, which isn't in Nvidia's open-gpu-docs and as such appears to be inadvertently cleared to 0s when we enable CRCs. After enabling this again during CRC capture, CRCs appear to be calculated normally in all circumstances now. Note that we might need to do this for Volta+ as well, but I'm not entirely sure yet as there seem to be some bugs with how Volta+ handles cursors that are currently causing kms_cursor_crc tests to fail. Cc: Martin Peres <martin.peres(a)free.fr> Cc: Jeremy Cline <jcline(a)redhat.com> Cc: Simon Ser <contact(a)emersion.fr> Signed-off-by: Lyude Paul <lyude(a)redhat.com> --- drivers/gpu/drm/nouveau/dispnv50/crc907d.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/crc907d.c b/drivers/gpu/drm/nouveau/dispnv50/crc907d.c index 0a89ae9523d4..f9cb484437aa 100644 --- a/drivers/gpu/drm/nouveau/dispnv50/crc907d.c +++ b/drivers/gpu/drm/nouveau/dispnv50/crc907d.c @@ -32,7 +32,8 @@ crc907d_set_src(struct nv50_head *head, int or, enum nv50_crc_source_type source NVDEF(NV907D, HEAD_SET_CRC_CONTROL, EXPECT_BUFFER_COLLAPSE, FALSE) | NVDEF(NV907D, HEAD_SET_CRC_CONTROL, TIMESTAMP_MODE, FALSE) | NVDEF(NV907D, HEAD_SET_CRC_CONTROL, SECONDARY_OUTPUT, NONE) | - NVDEF(NV907D, HEAD_SET_CRC_CONTROL, CRC_DURING_SNOOZE, DISABLE); + NVDEF(NV907D, HEAD_SET_CRC_CONTROL, CRC_DURING_SNOOZE, DISABLE) | + 0x00000040; int ret; switch (source) { -- 2.29.2

1 1

[PATCH] drm: Fix HDMI_STATIC_METADATA_TYPE1 constant.
by Mario Kleiner 23 Feb '21

23 Feb '21

According to the CTA 861.G spec, HDMI_STATIC_METADATA_TYPE1 is not 1, but zero, so fix this enum. While this doesn't cause problems in the kernel yet, as the constant isn't actively used by drivers yet, it did create confusion while debugging HDR problems in yours truly, and also potential bugs in userspace components, as the wrong enum propagates to components, e.g., like it did already into intel-gpu-tools (tests/kms_hdr.c) or is used as wrong reference when writing future new userspace HDR components like compositors. Fixes: fbb5d0353c62 ("drm: Add HDR source metadata property") Signed-off-by: Mario Kleiner <mario.kleiner.de(a)gmail.com> Cc: Uma Shankar <uma.shankar(a)intel.com> Cc: Shashank Sharma <shashank.sharma(a)intel.com> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- include/linux/hdmi.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h index 9850d59d6f1c..c8ec982ff498 100644 --- a/include/linux/hdmi.h +++ b/include/linux/hdmi.h @@ -156,7 +156,7 @@ enum hdmi_content_type { }; enum hdmi_metadata_type { - HDMI_STATIC_METADATA_TYPE1 = 1, + HDMI_STATIC_METADATA_TYPE1 = 0, }; enum hdmi_eotf { -- 2.25.1

3 18

[PATCH v3 1/2] dt-bindings: drm/bridge: anx7625: Add power supplies
by Hsin-Yi Wang 23 Feb '21

23 Feb '21

anx7625 requires 3 power supply regulators. Signed-off-by: Hsin-Yi Wang <hsinyi(a)chromium.org> Reviewed-by: Rob Herring <robh(a)kernel.org> --- .../bindings/display/bridge/analogix,anx7625.yaml | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml index 60585a4fc22b..3ae97d9523e5 100644 --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml @@ -34,6 +34,15 @@ properties: description: used for reset chip control, RESET_N pin B7. maxItems: 1 + vdd10-supply: + description: Regulator that provides the supply 1.0V power. + + vdd18-supply: + description: Regulator that provides the supply 1.8V power. + + vdd33-supply: + description: Regulator that provides the supply 3.3V power. + ports: type: object @@ -55,6 +64,9 @@ properties: required: - compatible - reg + - vdd10-supply + - vdd18-supply + - vdd33-supply - ports additionalProperties: false @@ -72,6 +84,9 @@ examples: reg = <0x58>; enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>; reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>; + vdd10-supply = <&pp1000_mipibrdg>; + vdd18-supply = <&pp1800_mipibrdg>; + vdd33-supply = <&pp3300_mipibrdg>; ports { #address-cells = <1>; -- 2.30.0.284.gd98b1dd5eaa7-goog

2 2

[PATCH] efifb: Ensure graphics device for efifb stays at PCI D0
by Kai-Heng Feng 22 Feb '21

22 Feb '21

We are seeing root ports on some desktop boards support D3cold for discrete graphics card. So when efifb is in use while graphics device isn't bound to a driver, PCI and ACPI will put the graphics to D3cold when runtime suspend kicks in, makes efifb stop working. So ensure the graphics device won't be runtime suspended, to keep efifb work all the time. Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> --- drivers/video/fbdev/efifb.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c index e57c00824965..19edd7206409 100644 --- a/drivers/video/fbdev/efifb.c +++ b/drivers/video/fbdev/efifb.c @@ -16,6 +16,7 @@ #include <linux/platform_device.h> #include <linux/printk.h> #include <linux/screen_info.h> +#include <linux/pm_runtime.h> #include <video/vga.h> #include <asm/efi.h> #include <drm/drm_utils.h> /* For drm_get_panel_orientation_quirk */ @@ -575,6 +576,7 @@ static int efifb_probe(struct platform_device *dev) goto err_fb_dealoc; } fb_info(info, "%s frame buffer device\n", info->fix.id); + pm_runtime_get_sync(&efifb_pci_dev->dev); return 0; err_fb_dealoc: @@ -601,6 +603,7 @@ static int efifb_remove(struct platform_device *pdev) unregister_framebuffer(info); sysfs_remove_groups(&pdev->dev.kobj, efifb_groups); framebuffer_release(info); + pm_runtime_put(&efifb_pci_dev->dev); return 0; } -- 2.29.2

3 3

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2021