Re: [PATCH 6/8] xen/gntdev: Implement dma-buf export functionality
On 05/31/2018 02:10 AM, Dongwon Kim wrote: On Fri, May 25, 2018 at 06:33:29PM +0300, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko 1. Create a dma-buf from grant references provided by the foreign domain. By default dma-buf is backed by system memory pages, but by providing GNTDEV_DMA_FLAG_XXX flags it can also be created as a DMA write-combine/coherent buffer, e.g. allocated with corresponding dma_alloc_xxx API. Export the resulting buffer as a new dma-buf. 2. Implement waiting for the dma-buf to be released: block until the dma-buf with the file descriptor provided is released. If within the time-out provided the buffer is not released then -ETIMEDOUT error is returned. If the buffer with the file descriptor does not exist or has already been released, then -ENOENT is returned. For valid file descriptors this must not be treated as error. Signed-off-by: Oleksandr Andrushchenko --- drivers/xen/gntdev.c | 478 ++- 1 file changed, 476 insertions(+), 2 deletions(-) diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c index 9e450622af1a..52abc6cd5846 100644 --- a/drivers/xen/gntdev.c +++ b/drivers/xen/gntdev.c @@ -4,6 +4,8 @@ * Device for accessing (in user-space) pages that have been granted by other * domains. * + * DMA buffer implementation is based on drivers/gpu/drm/drm_prime.c. + * * Copyright (c) 2006-2007, D G Murray. * (c) 2009 Gerd Hoffmann * (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc. @@ -41,6 +43,9 @@ #ifdef CONFIG_XEN_GRANT_DMA_ALLOC #include #endif +#ifdef CONFIG_XEN_GNTDEV_DMABUF +#include +#endif #include #include @@ -81,6 +86,17 @@ struct gntdev_priv { /* Device for which DMA memory is allocated. */ struct device *dma_dev; #endif + +#ifdef CONFIG_XEN_GNTDEV_DMABUF + /* Private data of the hyper DMA buffers. */ + + /* List of exported DMA buffers. */ + struct list_head dmabuf_exp_list; + /* List of wait objects. */ + struct list_head dmabuf_exp_wait_list; + /* This is the lock which protects dma_buf_xxx lists. */ + struct mutex dmabuf_lock; +#endif }; struct unmap_notify { @@ -125,12 +141,38 @@ struct grant_map { #ifdef CONFIG_XEN_GNTDEV_DMABUF struct xen_dmabuf { + struct gntdev_priv *priv; + struct dma_buf *dmabuf; + struct list_head next; + int fd; + union { + struct { + /* Exported buffers are reference counted. */ + struct kref refcount; + struct grant_map *map; + } exp; struct { /* Granted references of the imported buffer. */ grant_ref_t *refs; } imp; } u; + + /* Number of pages this buffer has. */ + int nr_pages; + /* Pages of this buffer. */ + struct page **pages; +}; + +struct xen_dmabuf_wait_obj { + struct list_head next; + struct xen_dmabuf *xen_dmabuf; + struct completion completion; +}; + +struct xen_dmabuf_attachment { + struct sg_table *sgt; + enum dma_data_direction dir; }; #endif @@ -320,6 +362,16 @@ static void gntdev_put_map(struct gntdev_priv *priv, struct grant_map *map) gntdev_free_map(map); } +#ifdef CONFIG_XEN_GNTDEV_DMABUF +static void gntdev_remove_map(struct gntdev_priv *priv, struct grant_map *map) +{ + mutex_lock(>lock); + list_del(>next); + gntdev_put_map(NULL /* already removed */, map); + mutex_unlock(>lock); +} +#endif + /* -- */ static int find_grant_ptes(pte_t *pte, pgtable_t token, @@ -628,6 +680,12 @@ static int gntdev_open(struct inode *inode, struct file *flip) INIT_LIST_HEAD(>freeable_maps); mutex_init(>lock); +#ifdef CONFIG_XEN_GNTDEV_DMABUF + mutex_init(>dmabuf_lock); + INIT_LIST_HEAD(>dmabuf_exp_list); + INIT_LIST_HEAD(>dmabuf_exp_wait_list); +#endif + if (use_ptemod) { priv->mm = get_task_mm(current); if (!priv->mm) { @@ -1053,17 +,433 @@ static long gntdev_ioctl_grant_copy(struct gntdev_priv *priv, void __user *u) /* DMA buffer export support. */ /* -- */ +/* -- */ +/* Implementation of wait for exported DMA buffer to be released. */ +/* -- */ + +static void dmabuf_exp_release(struct kref *kref); + +static struct xen_dmabuf_wait_obj * +dmabuf_exp_wait_obj_new(struct gntdev_priv *priv, + struct xen_dmabuf *xen_dmabuf) +{ + struct xen_dmabuf_wait_obj *obj; + + obj =
[PATCH] ARM:drm ivip Intel FPGA Video and Image Processing Suite
From: Ong Hean Loong Driver for Intel FPGA Video and Image Processing Suite Frame Buffer II. The driver only supports the Intel Arria10 devkit and its variants. This driver can be either loaded staticlly or in modules. The OF device tree binding is located at: Documentation/devicetree/bindings/display/altr,vip-fb2.txt Signed-off-by: Ong Hean Loong --- drivers/gpu/drm/Kconfig |2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/ivip/Kconfig | 14 +++ drivers/gpu/drm/ivip/Makefile |9 ++ drivers/gpu/drm/ivip/intel_vip_conn.c | 95 drivers/gpu/drm/ivip/intel_vip_core.c | 163 drivers/gpu/drm/ivip/intel_vip_drv.h | 52 + drivers/gpu/drm/ivip/intel_vip_of.c | 193 + 8 files changed, 529 insertions(+), 0 deletions(-) create mode 100644 drivers/gpu/drm/ivip/Kconfig create mode 100644 drivers/gpu/drm/ivip/Makefile create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index deeefa7..cdc8e1a 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -204,6 +204,8 @@ source "drivers/gpu/drm/nouveau/Kconfig" source "drivers/gpu/drm/i915/Kconfig" +source "drivers/gpu/drm/ivip/Kconfig" + config DRM_VGEM tristate "Virtual GEM provider" depends on DRM diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 50093ff..c0fba1d 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -60,6 +60,7 @@ obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/ obj-$(CONFIG_DRM_MGA) += mga/ obj-$(CONFIG_DRM_I810) += i810/ obj-$(CONFIG_DRM_I915) += i915/ +obj-$(CONFIG_DRM_IVIP) += ivip/ obj-$(CONFIG_DRM_MGAG200) += mgag200/ obj-$(CONFIG_DRM_VC4) += vc4/ obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/ diff --git a/drivers/gpu/drm/ivip/Kconfig b/drivers/gpu/drm/ivip/Kconfig new file mode 100644 index 000..1d08b90 --- /dev/null +++ b/drivers/gpu/drm/ivip/Kconfig @@ -0,0 +1,14 @@ +config DRM_IVIP +tristate "Intel FGPA Video and Image Processing" +depends on DRM && OF +select DRM_GEM_CMA_HELPER +select DRM_KMS_HELPER +select DRM_KMS_FB_HELPER +select DRM_KMS_CMA_HELPER +help + Choose this option if you have an Intel FPGA Arria 10 system + and above with an Intel Display Port IP. This does not support + legacy Intel FPGA Cyclone V display port. Currently only single + frame buffer is supported. Note that ACPI and X_86 architecture + is not supported for Arria10. If M is selected the module will be + called ivip. diff --git a/drivers/gpu/drm/ivip/Makefile b/drivers/gpu/drm/ivip/Makefile new file mode 100644 index 000..cc55b04 --- /dev/null +++ b/drivers/gpu/drm/ivip/Makefile @@ -0,0 +1,9 @@ +# +# Makefile for the drm device driver. This driver provides support for the +# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. + +ccflags-y := -Iinclude/drm + +obj-$(CONFIG_DRM_IVIP) += ivip.o +ivip-objs := intel_vip_of.o intel_vip_core.o \ + intel_vip_conn.o diff --git a/drivers/gpu/drm/ivip/intel_vip_conn.c b/drivers/gpu/drm/ivip/intel_vip_conn.c new file mode 100644 index 000..46bb04c --- /dev/null +++ b/drivers/gpu/drm/ivip/intel_vip_conn.c @@ -0,0 +1,95 @@ +/* + * intel_vip_conn.c -- Intel Video and Image Processing(VIP) + * Frame Buffer II driver + * + * This driver supports the Intel VIP Frame Reader component. + * More info on the hardware can be found in the Intel Video + * and Image Processing Suite User Guide at this address + * http://www.altera.com/literature/ug/ug_vip.pdf. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + * + * This program is distributed in the hope it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * more details. + * + * Authors: + * Ong, Hean-Loong + * + */ + +#include +#include +#include +#include +#include +#include + +static enum drm_connector_status +intelvipfb_drm_connector_detect(struct drm_connector *connector, bool force) +{ + return connector_status_connected; +} + +static void intelvipfb_drm_connector_destroy(struct drm_connector *connector) +{ + drm_connector_unregister(connector); + drm_connector_cleanup(connector); +} + +static const struct drm_connector_funcs intelvipfb_drm_connector_funcs = { + .reset = drm_atomic_helper_connector_reset, + .detect
[PATCHv<8> 0/3] Intel FPGA Video and Image Processing Suite
From: Ong, Hean Loong The FPGA FrameBuffer Soft IP could be seen as the GPU and the DRM driver patch here is allocating memory for information to be streamed from the ARM/Linux to the display port. Basically the driver just wraps the information such as the pixels to be drawn by the FPGA FrameBuffer 2. The piece of hardware in discussion is the SoC FPGA where Linux runs on the ARM chip and the FGPA is driven by its NIOS soft core with its own proprietary firmware. For example the application from the ARM Linux would have to write information on the /dev/fb0 with the information stored in the SDRAM to be fetched by the FPGA framebuffer IP and displayed on the Display Port Monitor. Ong Hean Loong (3): ARM:dt-bindings:display Intel FPGA Video and Image Processing Suite ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite ARM:drm ivip Intel FPGA Video and Image Processing Suite .../devicetree/bindings/display/altr,vip-fb2.txt | 112 +++ arch/arm/configs/socfpga_defconfig |5 + drivers/gpu/drm/Kconfig|2 + drivers/gpu/drm/Makefile |1 + drivers/gpu/drm/ivip/Kconfig | 14 ++ drivers/gpu/drm/ivip/Makefile |9 + drivers/gpu/drm/ivip/intel_vip_conn.c | 96 ++ drivers/gpu/drm/ivip/intel_vip_core.c | 162 drivers/gpu/drm/ivip/intel_vip_drv.h | 52 ++ drivers/gpu/drm/ivip/intel_vip_of.c| 193 10 files changed, 646 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt create mode 100644 drivers/gpu/drm/ivip/Kconfig create mode 100644 drivers/gpu/drm/ivip/Makefile create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] xen: dma-buf support for grant device
On 05/31/2018 04:46 AM, Boris Ostrovsky wrote: On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: Oleksandr Andrushchenko (8): xen/grant-table: Make set/clear page private code shared xen/balloon: Move common memory reservation routines to a module xen/grant-table: Allow allocating buffers suitable for DMA xen/gntdev: Allow mappings for DMA buffers xen/gntdev: Add initial support for dma-buf UAPI xen/gntdev: Implement dma-buf export functionality xen/gntdev: Implement dma-buf import functionality xen/gntdev: Expose gntdev's dma-buf API for in-kernel use drivers/xen/Kconfig | 23 + drivers/xen/Makefile | 1 + drivers/xen/balloon.c | 71 +-- drivers/xen/gntdev.c | 1025 - I think this calls for gntdev_dma.c. I assume you mean as a separate file (part of gntdev driver)? I only had a quick look over gntdev changes but they very much are concentrated in dma-specific routines. I tried to do that, but there are some dependencies between the gntdev.c and gntdev_dma.c, so finally I decided to put it all together. You essentially only share file_operations entry points with original gntdev code, right? fops + mappings done by gntdev (struct grant_map) and I need to release map on dma_buf .release callback which makes some cross-dependencies between modules which seemed to be not cute (gntdev keeps its all structs and functions inside, so I cannot easily access those w/o helpers). But I'll try one more time and move all DMA specific stuff into gntdev_dma.c -boris Thank you, Oleksandr drivers/xen/grant-table.c | 176 +- drivers/xen/mem-reservation.c | 134 + include/uapi/xen/gntdev.h | 106 include/xen/grant_dev.h | 37 ++ include/xen/grant_table.h | 28 + include/xen/mem_reservation.h | 29 + 10 files changed, 1527 insertions(+), 103 deletions(-) create mode 100644 drivers/xen/mem-reservation.c create mode 100644 include/xen/grant_dev.h create mode 100644 include/xen/mem_reservation.h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite
From: Ong Hean Loong Intel FPGA Video and Image Processing Suite Frame Buffer II driver config for Arria 10 devkit and its variants Signed-off-by: Ong, Hean Loong --- arch/arm/configs/socfpga_defconfig |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig index 2620ce7..d7deee8 100644 --- a/arch/arm/configs/socfpga_defconfig +++ b/arch/arm/configs/socfpga_defconfig @@ -111,6 +111,11 @@ CONFIG_MFD_ALTERA_A10SR=y CONFIG_MFD_STMPE=y CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y +CONFIG_DRM=m +CONFIG_DRM_IVIP=m +CONFIG_DRM_IVIP_OF=m +CONFIG_FB=y +CONFIG_FB_SIMPLE=y CONFIG_USB=y CONFIG_USB_STORAGE=y CONFIG_USB_DWC2=y -- 1.7.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] ARM:dt-bindings:display Intel FPGA Video and Image Processing Suite
From: Ong, Hean Loong Device tree binding for Intel FPGA Video and Image Processing Suite. The binding involved would be generated from the Altera (Intel) Qsys system. The bindings would set the max width, max height, buts per pixel and memory port width. The device tree binding only supports the Intel Arria10 devkit and its variants. Vendor name retained as altr. V8: *Add port to Display port decoder V7: *Fix OF graph for better description *Add description for encoder V6: *Description have not describe DT device in general V5: *remove bindings for bits per symbol as it has only one value which is 8 V4: *fix properties that does not describe the values V3: *OF graph not in accordance to graph.txt V2: *Remove Linux driver description V1: *Missing vendor prefix Signed-off-by: Ong, Hean Loong --- .../devicetree/bindings/display/altr,vip-fb2.txt | 99 1 files changed, 99 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt diff --git a/Documentation/devicetree/bindings/display/altr,vip-fb2.txt b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt new file mode 100644 index 000..4092804 --- /dev/null +++ b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt @@ -0,0 +1,99 @@ +Intel Video and Image Processing(VIP) Frame Buffer II bindings + +Supported hardware: Intel FPGA SoC Arria10 and above with display port IP + +The Video Frame Buffer II in Video Image Processing (VIP) suite is an IP core +that interfaces between system memory and Avalon-ST video ports. The IP core +can be configured to support the memory reader (from memory to Avalon-ST) +and/or memory writer (from Avalon-ST to memory) interfaces. + +More information the FPGA video IP component can be acquired from +https://www.altera.com/content/dam/altera-www/global/en_US/pdfs\ +/literature/ug/ug_vip.pdf + +DT-Bindings: += +Required properties: + +- compatible: "altr,vip-frame-buffer-2.0" +- reg: Physical base address and length of the framebuffer controller's + registers. +- altr,max-width: The maximum width of the framebuffer in pixels. +- altr,max-height: The maximum height of the framebuffer in pixels. +- altr,mem-port-width = the bus width of the avalon master port + on the frame reader + +Optional sub-nodes: +- ports: The connection to the encoder + +Optional properties + +- compatible: "altr, display-port" +- reg: Physical base address and length of the display port controller's + registers +- clocks: required clock handles for specified pairs in clock name +- clock-names: required clock names. Contains: + - aux_clk: auxiliary clock, + - clk: 100 MHz output clock + - xcvr_mgmt_clk: transceiver management clock + +Optional sub-nodes: +- ports: The connection to the controller + +Connections between the Frame Buffer II and other video IP cores in the system +are modelled using the OF graph DT bindings. The Frame Buffer II node has up +to two OF graph ports. When the memory writer interface is enabled, port 0 +maps to the Avalon-ST Input (din) port. When the memory reader interface is +enabled, port 1 maps to the Avalon-ST Output (dout) port. + +The encoder is built into the FPGA HW design and therefore would not +be accessible from the DDR. + + Port 0 Port1 +- +ARRIA10 AVALON_ST (DIN)AVALON_ST (DOUT) + +Required Properties Example: + + +framebuffer@10280 { + compatible = "altr,vip-frame-buffer-2.0"; + reg = <0x0001 0x0280 0x0040>; + altr,max-width = <1280>; + altr,max-height = <720>; + altr,mem-port-width = <128>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@1 { + reg = <1>; + fb_output: endpoint { + remote-endpoint = <_encoder_input>; + }; + }; + }; +}; + +Optional Properties Example: +This is not required unless there are needs to customize +Display Port controller settings. + +displayport@12000 { + compatible = "altr, display-port"; + reg = <0x0001 0x2000 0x0800>; + clocks = <_0_clk_16 _0_clk_100 _0_clk_100>; + clock-names = "aux_clk", "clk", "xcvr_mgmt_clk"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <1>; + dp_input: endpoint { +
Re: [PATCH 1/8] xen/grant-table: Make set/clear page private code shared
On 05/31/2018 12:34 AM, Dongwon Kim wrote: On Fri, May 25, 2018 at 06:33:24PM +0300, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Make set/clear page private code shared and accessible to other kernel modules which can re-use these instead of open-coding. Signed-off-by: Oleksandr Andrushchenko --- drivers/xen/grant-table.c | 54 +-- include/xen/grant_table.h | 3 +++ 2 files changed, 38 insertions(+), 19 deletions(-) diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c index 27be107d6480..d7488226e1f2 100644 --- a/drivers/xen/grant-table.c +++ b/drivers/xen/grant-table.c @@ -769,29 +769,18 @@ void gnttab_free_auto_xlat_frames(void) } EXPORT_SYMBOL_GPL(gnttab_free_auto_xlat_frames); -/** - * gnttab_alloc_pages - alloc pages suitable for grant mapping into - * @nr_pages: number of pages to alloc - * @pages: returns the pages - */ -int gnttab_alloc_pages(int nr_pages, struct page **pages) +int gnttab_pages_set_private(int nr_pages, struct page **pages) { int i; - int ret; - - ret = alloc_xenballooned_pages(nr_pages, pages); - if (ret < 0) - return ret; for (i = 0; i < nr_pages; i++) { #if BITS_PER_LONG < 64 struct xen_page_foreign *foreign; foreign = kzalloc(sizeof(*foreign), GFP_KERNEL); - if (!foreign) { - gnttab_free_pages(nr_pages, pages); + if (!foreign) Don't we have to free previously allocated "foreign"(s) if it fails in the middle (e.g. 0 < i && i < nr_pages - 1) before returning? gnttab_free_pages(nr_pages, pages); will take care of it when called from outside, see below. It can also handle partial allocations, so no problem here return -ENOMEM; - } + set_page_private(pages[i], (unsigned long)foreign); #endif SetPagePrivate(pages[i]); @@ -799,14 +788,30 @@ int gnttab_alloc_pages(int nr_pages, struct page **pages) return 0; } -EXPORT_SYMBOL(gnttab_alloc_pages); +EXPORT_SYMBOL(gnttab_pages_set_private); /** - * gnttab_free_pages - free pages allocated by gnttab_alloc_pages() - * @nr_pages; number of pages to free - * @pages: the pages + * gnttab_alloc_pages - alloc pages suitable for grant mapping into + * @nr_pages: number of pages to alloc + * @pages: returns the pages */ -void gnttab_free_pages(int nr_pages, struct page **pages) +int gnttab_alloc_pages(int nr_pages, struct page **pages) +{ + int ret; + + ret = alloc_xenballooned_pages(nr_pages, pages); + if (ret < 0) + return ret; + + ret = gnttab_pages_set_private(nr_pages, pages); + if (ret < 0) + gnttab_free_pages(nr_pages, pages); + + return ret; +} +EXPORT_SYMBOL(gnttab_alloc_pages); + +void gnttab_pages_clear_private(int nr_pages, struct page **pages) { int i; @@ -818,6 +823,17 @@ void gnttab_free_pages(int nr_pages, struct page **pages) ClearPagePrivate(pages[i]); } } +} +EXPORT_SYMBOL(gnttab_pages_clear_private); + +/** + * gnttab_free_pages - free pages allocated by gnttab_alloc_pages() + * @nr_pages; number of pages to free + * @pages: the pages + */ +void gnttab_free_pages(int nr_pages, struct page **pages) +{ + gnttab_pages_clear_private(nr_pages, pages); free_xenballooned_pages(nr_pages, pages); } EXPORT_SYMBOL(gnttab_free_pages); diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h index 2e37741f6b8d..de03f2542bb7 100644 --- a/include/xen/grant_table.h +++ b/include/xen/grant_table.h @@ -198,6 +198,9 @@ void gnttab_free_auto_xlat_frames(void); int gnttab_alloc_pages(int nr_pages, struct page **pages); void gnttab_free_pages(int nr_pages, struct page **pages); +int gnttab_pages_set_private(int nr_pages, struct page **pages); +void gnttab_pages_clear_private(int nr_pages, struct page **pages); + int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, struct gnttab_map_grant_ref *kmap_ops, struct page **pages, unsigned int count); -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #16 from Pixie --- Running glxgears gives me a GL version of 3.1 Mesa 18.2.0-devel, that the one I'm looking for? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #15 from Pixie --- That Git install doesn't seem to have changed anything visible. Doesn't show in logs either, which is weird. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #14 from Pixie --- Created attachment 139880 --> https://bugs.freedesktop.org/attachment.cgi?id=139880=edit Broken Xorg log on 4.15 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #13 from Pixie --- Created attachment 139879 --> https://bugs.freedesktop.org/attachment.cgi?id=139879=edit Broken dmesg on 4.15 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #12 from Pixie --- Seems like I had the right idea. 4.15 runs amdgpu 3.23. May install a Mesa git version from a PPA after this to check. Really want the new kernels, so I'm probably gonna do that right away after posting the two logs. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #11 from Pixie --- Seems somewhere between what looks like versions 3.19 and 3.25. Gonna guess 4.15 has an earlier version; gonna fetch logs from that shortly. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #10 from Pixie --- Created attachment 139878 --> https://bugs.freedesktop.org/attachment.cgi?id=139878=edit Xorg log on the broken 4.17-rc1 setup The broken Xorg log doesn't even seem to acknowledge the monitor exists through a quick grep. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #9 from Pixie --- Created attachment 139877 --> https://bugs.freedesktop.org/attachment.cgi?id=139877=edit dmesg from a broken 4.17-rc1 setup; look here for the errors -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #8 from Pixie --- Nope, fell flat on its face. rc1 logs coming shortly. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #7 from Pixie --- Logs from working software submitted. Booting promptly into a newer kernel and salvaging logs from there. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #6 from Pixie --- Created attachment 139876 --> https://bugs.freedesktop.org/attachment.cgi?id=139876=edit Xorg log on the same functional 4.14.35 setup. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #5 from Pixie --- Created attachment 139875 --> https://bugs.freedesktop.org/attachment.cgi?id=139875=edit dmesg log on a working setup (kernel 4.14.35, latest stable mesa) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #4 from Pixie --- If instructed how, I would definitely be willing to bisect. Power went out, fell asleep, no xorg logs during the day. Sorry for the delay, a working log/dmesg combo on 4.14.35 coming up shortly, for reference. This breaks on any kernel 4.15 and above, by the way. Decided to report it against whatever is present in 4.17, since the issue still persists there. And if I can get rc4 to install, I'll test that and provide the logs from that. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/10] dt-bindings: tc358754: add DT bindings
On Wed, May 30, 2018 at 02:15:58PM +0200, Maciej Purski wrote: > From: Andrzej Hajda > > The patch adds bindings to Toshiba DSI/LVDS bridge TC358764. > Bindings describe power supplies, reset gpio and video interfaces. > > Signed-off-by: Andrzej Hajda > Signed-off-by: Maciej Purski > --- > .../bindings/display/bridge/toshiba,tc358764.txt | 37 > ++ > 1 file changed, 37 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt > > diff --git > a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt > b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt > new file mode 100644 > index 000..6eda14f > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt > @@ -0,0 +1,37 @@ > +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 zero to two 'port' child nodes, each with one How would 0 ports be valid? > +child 'endpoint' node, according to the bindings defined in [1]. > +The following are properties specific to those nodes. > + > +port: > + - reg: (required) can be 0 for DSI port or 1 for LVDS port; > + > +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt > + > +Example: > + > + bridge@0 { > + reg = <0>; > + compatible = "toshiba,tc358764"; > + vddc-supply = <_1v2_reg>; > + vddio-supply = <_1v8_reg>; > + vddlvds-supply = <_3v3_reg>; > + reset-gpios = < 6 GPIO_ACTIVE_LOW>; > + #address-cells = <1>; > + #size-cells = <0>; > + port@1 { > + reg = <1>; > + lvds_ep: endpoint { > + remote-endpoint = <_ep>; > + }; > + }; > + }; > -- > 2.7.4 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 05/10] panel/hv070wsa-100: add DT bindings
On Wed, May 30, 2018 at 02:15:56PM +0200, Maciej Purski wrote: > From: Andrzej Hajda "dt-bindings: display: ..." is preferred subject prefix. > > The patch adds bindings to BOE HV070-WSA WSVGA panel. > Bindings are compatible with simple panel bindings. > > Signed-off-by: Andrzej Hajda > Signed-off-by: Maciej Purski > --- > .../devicetree/bindings/display/panel/boe,hv070wsa-100.txt | 7 > +++ > 1 file changed, 7 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt > > diff --git > a/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt > b/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt > new file mode 100644 > index 000..bfc20ac > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt > @@ -0,0 +1,7 @@ > +BOE HV070WSA-100 7.01" WSVGA TFT LCD panel > + > +Required properties: > +- compatible: should be "boe,hv070wsa-100" > + > +This binding is compatible with the simple-panel binding, which is specified > +in simple-panel.txt in this directory. You have to state exactly which properties apply. Does this panel have a backlight? 1 supply, 2 supplies, no supplies? Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] dt-bindings: new binding for Ilitek ILI9341 display panels
On Fri, May 25, 2018 at 03:14:33PM -0500, David Lechner wrote: > On 05/25/2018 02:36 PM, David Lechner wrote: > > This adds a new binding for Ilitek ILI9341 display panels. It includes > > a compatible string for one display (more can be added in the future). > > > > The vendor prefix "noname" is used because the vendor is not known. > > Looks like I forgot to update "noname" to "adafruit" in the commit message. > Patch is as intended though. Other than that, Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/4] dt-bindings: Add vendor prefix for Adafruit
On Fri, May 25, 2018 at 02:36:21PM -0500, David Lechner wrote: > This adds a device tree vendor prefix for Adafruit Industries, LLC. > > Signed-off-by: David Lechner > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/9] drm/mediatek: update dt-bindings for mt2712
On Mon, May 28, 2018 at 02:38:19PM +0800, Stu Hsieh wrote: > Update device tree binding documentation for the display subsystem for > Mediatek MT2712 SoCs. > > Signed-off-by: Stu Hsieh > Acked-by: CK Hu > --- > Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DPU PATCH v2] drm/msm: make pclk_rate u64 to avoid truncation
Higher values of pclk can exceed 32 bits when multiplied by a factor. Make the pclk_rate u64 to accommodate higher pixel clock rates. Signed-off-by: Abhinav Kumar --- drivers/gpu/drm/msm/dsi/dsi_host.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c index b916f46..5a04f2d 100644 --- a/drivers/gpu/drm/msm/dsi/dsi_host.c +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c @@ -668,7 +668,8 @@ static int dsi_calc_clk_rate(struct msm_dsi_host *msm_host) const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd; u8 lanes = msm_host->lanes; u32 bpp = dsi_get_bpp(msm_host->format); - u32 pclk_rate; + u64 pclk_rate; + u64 pclk_bpp; if (!mode) { pr_err("%s: mode not set\n", __func__); @@ -676,14 +677,18 @@ static int dsi_calc_clk_rate(struct msm_dsi_host *msm_host) } pclk_rate = mode->clock * 1000; + pclk_bpp = pclk_rate * bpp; + if (lanes > 0) { - msm_host->byte_clk_rate = (pclk_rate * bpp) / (8 * lanes); + do_div(pclk_bpp, (8 * lanes)); } else { pr_err("%s: forcing mdss_dsi lanes to 1\n", __func__); - msm_host->byte_clk_rate = (pclk_rate * bpp) / 8; + do_div(pclk_bpp, 8); } - DBG("pclk=%d, bclk=%d", pclk_rate, msm_host->byte_clk_rate); + msm_host->byte_clk_rate = pclk_bpp; + + DBG("pclk=%llu, bclk=%d", pclk_rate, msm_host->byte_clk_rate); msm_host->esc_clk_rate = clk_get_rate(msm_host->esc_clk); -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106747] [CI] igt@* - crash - An internal exception that should have been handled was not: UnicodeDecodeError
https://bugs.freedesktop.org/show_bug.cgi?id=106747 Martin Peres changed: What|Removed |Added QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org Summary|[CI] igt@* - crash - An |[CI] igt@* - crash - An |internal exception that |internal exception that |should have been handled|should have been handled |was not:|was not: UnicodeDecodeError |UnicodeDecodeError.An | Whiteboard||ReadyForDev Component|DRM/Intel |IGT --- Comment #1 from Martin Peres --- Moving to IGT. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v6 2/6] drm/i915: hdmi: add CEC notifier to intel_hdmi
On Wed, May 30, 2018 at 06:29:36PM +0300, Ville Syrjälä wrote: > On Thu, May 24, 2018 at 11:57:17AM +0200, Neil Armstrong wrote: > > This patchs adds the cec_notifier feature to the intel_hdmi part > > of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate > > between each HDMI ports. > > The changes will allow the i915 HDMI code to notify EDID and HPD changes > > to an eventual CEC adapter. > > > > Signed-off-by: Neil Armstrong > > Reviewed-by: Hans Verkuil > > --- > > drivers/gpu/drm/i915/Kconfig | 1 + > > drivers/gpu/drm/i915/intel_display.h | 20 > > drivers/gpu/drm/i915/intel_drv.h | 2 ++ > > drivers/gpu/drm/i915/intel_hdmi.c| 13 + > > 4 files changed, 36 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig > > index dfd9588..2d65d56 100644 > > --- a/drivers/gpu/drm/i915/Kconfig > > +++ b/drivers/gpu/drm/i915/Kconfig > > @@ -23,6 +23,7 @@ config DRM_I915 > > select SYNC_FILE > > select IOSF_MBI > > select CRC32 > > + select CEC_CORE if CEC_NOTIFIER > > help > > Choose this option if you have a system that has "Intel Graphics > > Media Accelerator" or "HD Graphics" integrated graphics, > > diff --git a/drivers/gpu/drm/i915/intel_display.h > > b/drivers/gpu/drm/i915/intel_display.h > > index 4e7418b..c68d1c8 100644 > > --- a/drivers/gpu/drm/i915/intel_display.h > > +++ b/drivers/gpu/drm/i915/intel_display.h > > @@ -126,6 +126,26 @@ enum port { > > > > #define port_name(p) ((p) + 'A') > > > > +static inline const char *port_identifier(enum port port) > > +{ > > + switch (port) { > > + case PORT_A: > > + return "Port A"; > > + case PORT_B: > > + return "Port B"; > > + case PORT_C: > > + return "Port C"; > > + case PORT_D: > > + return "Port D"; > > + case PORT_E: > > + return "Port E"; > > + case PORT_F: > > + return "Port F"; > > + default: > > + return ""; > > + } > > +} > > Could use a comment to make it clear that this identifier is > expected to remain stable since it's referenced from other drivers. > > > + > > enum dpio_channel { > > DPIO_CH0, > > DPIO_CH1 > > diff --git a/drivers/gpu/drm/i915/intel_drv.h > > b/drivers/gpu/drm/i915/intel_drv.h > > index d436858..b50e51b 100644 > > --- a/drivers/gpu/drm/i915/intel_drv.h > > +++ b/drivers/gpu/drm/i915/intel_drv.h > > @@ -39,6 +39,7 @@ > > #include > > #include > > #include > > +#include > > > > /** > > * __wait_for - magic wait macro > > @@ -1001,6 +1002,7 @@ struct intel_hdmi { > > bool has_audio; > > bool rgb_quant_range_selectable; > > struct intel_connector *attached_connector; > > + struct cec_notifier *notifier; > > "notifier" seems a bit too generic a name. "cec_notifier" would be > better. > > Apart from that this seems OK to me > Reviewed-by: Ville Syrjälä It seems that you will need to push this to other trees right? Feel free to use: Acked-by: Rodrigo Vivi > > > }; > > > > struct intel_dp_mst_encoder; > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > > b/drivers/gpu/drm/i915/intel_hdmi.c > > index 1baef4a..d522b5b 100644 > > --- a/drivers/gpu/drm/i915/intel_hdmi.c > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > > @@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector) > > connected = true; > > } > > > > + cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid); > > + > > return connected; > > } > > > > @@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector, > > bool force) > > { > > enum drm_connector_status status; > > struct drm_i915_private *dev_priv = to_i915(connector->dev); > > + struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector); > > > > DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", > > connector->base.id, connector->name); > > @@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector, > > bool force) > > > > intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS); > > > > + if (status != connector_status_connected) > > + cec_notifier_phys_addr_invalidate(intel_hdmi->notifier); > > + > > return status; > > } > > > > @@ -2031,6 +2037,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder > > *encoder, > > > > static void intel_hdmi_destroy(struct drm_connector *connector) > > { > > + if (intel_attached_hdmi(connector)->notifier) > > + cec_notifier_put(intel_attached_hdmi(connector)->notifier); > > kfree(to_intel_connector(connector)->detect_edid); > > drm_connector_cleanup(connector); > > kfree(connector); > > @@ -2358,6 +2366,11 @@ void intel_hdmi_init_connector(struct > > intel_digital_port *intel_dig_port, > > u32 temp = I915_READ(PEG_BAND_GAP_DATA); > > I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd); > > } > > + > > +
Re: [PATCH 6/8] xen/gntdev: Implement dma-buf export functionality
On Fri, May 25, 2018 at 06:33:29PM +0300, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > 1. Create a dma-buf from grant references provided by the foreign >domain. By default dma-buf is backed by system memory pages, but >by providing GNTDEV_DMA_FLAG_XXX flags it can also be created >as a DMA write-combine/coherent buffer, e.g. allocated with >corresponding dma_alloc_xxx API. >Export the resulting buffer as a new dma-buf. > > 2. Implement waiting for the dma-buf to be released: block until the >dma-buf with the file descriptor provided is released. >If within the time-out provided the buffer is not released then >-ETIMEDOUT error is returned. If the buffer with the file descriptor >does not exist or has already been released, then -ENOENT is returned. >For valid file descriptors this must not be treated as error. > > Signed-off-by: Oleksandr Andrushchenko > --- > drivers/xen/gntdev.c | 478 ++- > 1 file changed, 476 insertions(+), 2 deletions(-) > > diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c > index 9e450622af1a..52abc6cd5846 100644 > --- a/drivers/xen/gntdev.c > +++ b/drivers/xen/gntdev.c > @@ -4,6 +4,8 @@ > * Device for accessing (in user-space) pages that have been granted by other > * domains. > * > + * DMA buffer implementation is based on drivers/gpu/drm/drm_prime.c. > + * > * Copyright (c) 2006-2007, D G Murray. > * (c) 2009 Gerd Hoffmann > * (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc. > @@ -41,6 +43,9 @@ > #ifdef CONFIG_XEN_GRANT_DMA_ALLOC > #include > #endif > +#ifdef CONFIG_XEN_GNTDEV_DMABUF > +#include > +#endif > > #include > #include > @@ -81,6 +86,17 @@ struct gntdev_priv { > /* Device for which DMA memory is allocated. */ > struct device *dma_dev; > #endif > + > +#ifdef CONFIG_XEN_GNTDEV_DMABUF > + /* Private data of the hyper DMA buffers. */ > + > + /* List of exported DMA buffers. */ > + struct list_head dmabuf_exp_list; > + /* List of wait objects. */ > + struct list_head dmabuf_exp_wait_list; > + /* This is the lock which protects dma_buf_xxx lists. */ > + struct mutex dmabuf_lock; > +#endif > }; > > struct unmap_notify { > @@ -125,12 +141,38 @@ struct grant_map { > > #ifdef CONFIG_XEN_GNTDEV_DMABUF > struct xen_dmabuf { > + struct gntdev_priv *priv; > + struct dma_buf *dmabuf; > + struct list_head next; > + int fd; > + > union { > + struct { > + /* Exported buffers are reference counted. */ > + struct kref refcount; > + struct grant_map *map; > + } exp; > struct { > /* Granted references of the imported buffer. */ > grant_ref_t *refs; > } imp; > } u; > + > + /* Number of pages this buffer has. */ > + int nr_pages; > + /* Pages of this buffer. */ > + struct page **pages; > +}; > + > +struct xen_dmabuf_wait_obj { > + struct list_head next; > + struct xen_dmabuf *xen_dmabuf; > + struct completion completion; > +}; > + > +struct xen_dmabuf_attachment { > + struct sg_table *sgt; > + enum dma_data_direction dir; > }; > #endif > > @@ -320,6 +362,16 @@ static void gntdev_put_map(struct gntdev_priv *priv, > struct grant_map *map) > gntdev_free_map(map); > } > > +#ifdef CONFIG_XEN_GNTDEV_DMABUF > +static void gntdev_remove_map(struct gntdev_priv *priv, struct grant_map > *map) > +{ > + mutex_lock(>lock); > + list_del(>next); > + gntdev_put_map(NULL /* already removed */, map); > + mutex_unlock(>lock); > +} > +#endif > + > /* -- */ > > static int find_grant_ptes(pte_t *pte, pgtable_t token, > @@ -628,6 +680,12 @@ static int gntdev_open(struct inode *inode, struct file > *flip) > INIT_LIST_HEAD(>freeable_maps); > mutex_init(>lock); > > +#ifdef CONFIG_XEN_GNTDEV_DMABUF > + mutex_init(>dmabuf_lock); > + INIT_LIST_HEAD(>dmabuf_exp_list); > + INIT_LIST_HEAD(>dmabuf_exp_wait_list); > +#endif > + > if (use_ptemod) { > priv->mm = get_task_mm(current); > if (!priv->mm) { > @@ -1053,17 +,433 @@ static long gntdev_ioctl_grant_copy(struct > gntdev_priv *priv, void __user *u) > /* DMA buffer export support. */ > /* -- */ > > +/* -- */ > +/* Implementation of wait for exported DMA buffer to be released. */ > +/* -- */ > + > +static void dmabuf_exp_release(struct kref *kref); > + > +static struct xen_dmabuf_wait_obj * > +dmabuf_exp_wait_obj_new(struct gntdev_priv *priv, > +
Re: [PATCH v4 1/2] drm/panel: Add support for Truly NT35597 panel
Hi Sean Thanks for your review. Some responses below. Please help to check. Thanks Abhinav On 2018-05-30 12:12, Sean Paul wrote: On Fri, May 25, 2018 at 05:27:51PM -0700, Abhinav Kumar wrote: Add support for Truly NT35597 panel used in MSM reference platforms. This panel supports both single DSI and dual DSI modes. However, this patch series adds support only for dual DSI mode. Changes in v4: - Fix the license identifier - Fix formatting issues for the regulator loads - Fix error messages and return code Signed-off-by: Archit Taneja Signed-off-by: Abhinav Kumar --- drivers/gpu/drm/panel/Kconfig | 8 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-truly-nt35597.c | 576 3 files changed, 585 insertions(+) create mode 100644 drivers/gpu/drm/panel/panel-truly-nt35597.c diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index 25682ff..2fcd9b1 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -177,4 +177,12 @@ config DRM_PANEL_SITRONIX_ST7789V Say Y here if you want to enable support for the Sitronix ST7789V controller for 240x320 LCD panels +config DRM_PANEL_TRULY_NT35597_WQXGA + tristate "Truly WQXGA" + depends on OF + depends on DRM_MIPI_DSI + select VIDEOMODE_HELPERS + help + Say Y here if you want to enable support for Truly NT35597 WQXGA Dual DSI + Video Mode panel endmenu diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile index f26efc1..056ea93 100644 --- a/drivers/gpu/drm/panel/Makefile +++ b/drivers/gpu/drm/panel/Makefile @@ -18,3 +18,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o +obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o diff --git a/drivers/gpu/drm/panel/panel-truly-nt35597.c b/drivers/gpu/drm/panel/panel-truly-nt35597.c new file mode 100644 index 000..a57cbf0 --- /dev/null +++ b/drivers/gpu/drm/panel/panel-truly-nt35597.c @@ -0,0 +1,576 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2018, The Linux Foundation. All rights reserved. + */ + +#include +#include +#include +#include + +#include +#include +#include + +#include +#include +#include + +static const char * const regulator_names[] = { + "vdda", + "vdispp", + "vdispn" +}; [Abhinav] Will add a ',' here as per jordan's comment + +static unsigned long const regulator_enable_loads[] = { + 62000, + 10, + 10, +}; + +static unsigned long const regulator_disable_loads[] = { + 80, + 100, + 100, +}; + +struct truly_wqxga { + struct device *dev; + struct drm_panel panel; + + struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)]; + + struct gpio_desc *reset_gpio; + struct gpio_desc *mode_gpio; + + struct backlight_device *backlight; + struct videomode vm; + + struct mipi_dsi_device *dsi[2]; + + bool prepared; + bool enabled; +}; + +static inline struct truly_wqxga *panel_to_truly_wqxga(struct drm_panel *panel) +{ + return container_of(panel, struct truly_wqxga, panel); +} + +static int truly_wqxga_power_on(struct truly_wqxga *ctx) +{ + int ret, i; + + for (i = 0; i < ARRAY_SIZE(ctx->supplies); i++) { + ret = regulator_set_load(ctx->supplies[i].consumer, + regulator_enable_loads[i]); + if (ret) + return ret; + } + + ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies); + if (ret < 0) + return ret; + + msleep(20); + gpiod_set_value(ctx->reset_gpio, 1); + msleep(20); + gpiod_set_value(ctx->reset_gpio, 0); + msleep(20); + gpiod_set_value(ctx->reset_gpio, 1); + msleep(50); Why is this needed? Could you please comment? Also, it seems like this is active low? You should specify that in the dt, and let gpiod translate the value. [Abhinav] This is the panel's reset sequence which demands this delay. I can comment the same. Its active HIGH. I can leave a comment in the bindings mentioning the same. Let me know if this is sufficient. + + return 0; +} + +static int truly_wqxga_power_off(struct truly_wqxga *ctx) +{ + int ret, i; + + gpiod_set_value(ctx->reset_gpio, 0); + + for (i = 0; i < ARRAY_SIZE(ctx->supplies); i++) { + ret = regulator_set_load(ctx->supplies[i].consumer, + regulator_disable_loads[i]); + if (ret) + return ret; + } + + return
Re: [DPU PATCH] drm/msm: make pclk_rate u64 to avoid truncation
Hi Abhinav, Thank you for the patch! Yet something to improve: [auto build test ERROR on robclark/msm-next] [also build test ERROR on v4.17-rc7] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Abhinav-Kumar/drm-msm-make-pclk_rate-u64-to-avoid-truncation/20180530-182643 base: git://people.freedesktop.org/~robclark/linux msm-next config: arm-allmodconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): >> ERROR: "__aeabi_uldivmod" [drivers/gpu/drm/msm/msm.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] fb_omap: add gpiolib dependency
Building the omap sub-drivers when CONFIG_GPIOLIB is disabled causes lots of build failures, either from using gpiolib interfaces, or from including the wrong headers: drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c: In function 'opa362_enable': drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:101:3: error: implicit declaration of function 'gpiod_set_value_cansleep'; did you mean 'gpio_set_value_cansleep'? [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c: In function 'panel_dpi_enable': drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c:86:2: error: implicit declaration of function 'gpiod_set_value_cansleep'; did you mean 'gpio_set_value_cansleep'? [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c: In function 'panel_dpi_probe_pdata': drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c:189:23: error: implicit declaration of function 'gpio_to_desc'; did you mean 'irq_to_desc'? [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c: In function 'panel_dpi_probe_of': drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c:210:9: error: implicit declaration of function 'devm_gpiod_get_optional'; did you mean 'devm_gpio_request_one'? [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c: In function 'sharp_ls_enable': drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c:120:3: error: implicit declaration of function 'gpiod_set_value_cansleep'; did you mean 'gpio_set_value_cansleep'? [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c: In function 'lb035q02_enable': drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c:170:3: error: implicit declaration of function 'gpiod_set_value_cansleep'; did you mean 'gpio_set_value_cansleep'? [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c: In function 'hdmi_probe_of': drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c:584:2: error: implicit declaration of function 'of_node_put'; did you mean 'node_set'? [-Werror=implicit-function-declaration] drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c: In function 'hdmi_probe_of': drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c:554:2: error: implicit declaration of function 'of_node_put'; did you mean 'node_set'? [-Werror=implicit-function-declaration] Rather than fixing up each one individually, this just marks all of it as depending on GPIOLIB. Signed-off-by: Arnd Bergmann --- drivers/video/fbdev/omap2/omapfb/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/fbdev/omap2/omapfb/Kconfig b/drivers/video/fbdev/omap2/omapfb/Kconfig index e6226aeed17e..3bf154e676d1 100644 --- a/drivers/video/fbdev/omap2/omapfb/Kconfig +++ b/drivers/video/fbdev/omap2/omapfb/Kconfig @@ -5,6 +5,7 @@ menuconfig FB_OMAP2 tristate "OMAP2+ frame buffer support" depends on FB depends on DRM_OMAP = n + depends on GPIOLIB select FB_OMAP2_DSS select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3 -- 2.9.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106594] [radeonsi,regression,apitrace] Prison Architect rendered unplayable by multicoloured flickering triangles and overlayed triangles when performing certain actions
https://bugs.freedesktop.org/show_bug.cgi?id=106594 Kai changed: What|Removed |Added CC||bri...@vmware.com, ||mathias.froehl...@web.de QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Keywords||bisected Component|Drivers/Gallium/radeonsi|Mesa core --- Comment #6 from Kai --- The bisection result is: > 9c7be67968aaba224d518dee86dff736a4b599c6 is the first bad commit > commit 9c7be67968aaba224d518dee86dff736a4b599c6 > Author: Mathias Fröhlich > Date: Sun May 13 09:18:57 2018 +0200 > > mesa: Remove FLUSH_VERTICES from VAO state changes. > > Pending draw calls on immediate mode or display list calls do > not depend on changes of the VAO state. So, remove calls to > FLUSH_VERTICES and flag _NEW_ARRAY as appropriate. > > Reviewed-by: Brian Paul > Signed-off-by: Mathias Fröhlich > > :04 04 ad95067168b41b30d17d7ff05ecd47be4ca150e4 > 97ab8bde466f83da431193b045a664e540595d80 M src Reverting that commit generates several conflicts. I'd probably have to revert the whole series? Since this touches core Mesa, the bug shouldn't be constrained to radeonsi, I'll adjust the component accordingly. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] xen/grant-table: Make set/clear page private code shared
On Fri, May 25, 2018 at 06:33:24PM +0300, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Make set/clear page private code shared and accessible to > other kernel modules which can re-use these instead of open-coding. > > Signed-off-by: Oleksandr Andrushchenko > --- > drivers/xen/grant-table.c | 54 +-- > include/xen/grant_table.h | 3 +++ > 2 files changed, 38 insertions(+), 19 deletions(-) > > diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c > index 27be107d6480..d7488226e1f2 100644 > --- a/drivers/xen/grant-table.c > +++ b/drivers/xen/grant-table.c > @@ -769,29 +769,18 @@ void gnttab_free_auto_xlat_frames(void) > } > EXPORT_SYMBOL_GPL(gnttab_free_auto_xlat_frames); > > -/** > - * gnttab_alloc_pages - alloc pages suitable for grant mapping into > - * @nr_pages: number of pages to alloc > - * @pages: returns the pages > - */ > -int gnttab_alloc_pages(int nr_pages, struct page **pages) > +int gnttab_pages_set_private(int nr_pages, struct page **pages) > { > int i; > - int ret; > - > - ret = alloc_xenballooned_pages(nr_pages, pages); > - if (ret < 0) > - return ret; > > for (i = 0; i < nr_pages; i++) { > #if BITS_PER_LONG < 64 > struct xen_page_foreign *foreign; > > foreign = kzalloc(sizeof(*foreign), GFP_KERNEL); > - if (!foreign) { > - gnttab_free_pages(nr_pages, pages); > + if (!foreign) Don't we have to free previously allocated "foreign"(s) if it fails in the middle (e.g. 0 < i && i < nr_pages - 1) before returning? > return -ENOMEM; > - } > + > set_page_private(pages[i], (unsigned long)foreign); > #endif > SetPagePrivate(pages[i]); > @@ -799,14 +788,30 @@ int gnttab_alloc_pages(int nr_pages, struct page > **pages) > > return 0; > } > -EXPORT_SYMBOL(gnttab_alloc_pages); > +EXPORT_SYMBOL(gnttab_pages_set_private); > > /** > - * gnttab_free_pages - free pages allocated by gnttab_alloc_pages() > - * @nr_pages; number of pages to free > - * @pages: the pages > + * gnttab_alloc_pages - alloc pages suitable for grant mapping into > + * @nr_pages: number of pages to alloc > + * @pages: returns the pages > */ > -void gnttab_free_pages(int nr_pages, struct page **pages) > +int gnttab_alloc_pages(int nr_pages, struct page **pages) > +{ > + int ret; > + > + ret = alloc_xenballooned_pages(nr_pages, pages); > + if (ret < 0) > + return ret; > + > + ret = gnttab_pages_set_private(nr_pages, pages); > + if (ret < 0) > + gnttab_free_pages(nr_pages, pages); > + > + return ret; > +} > +EXPORT_SYMBOL(gnttab_alloc_pages); > + > +void gnttab_pages_clear_private(int nr_pages, struct page **pages) > { > int i; > > @@ -818,6 +823,17 @@ void gnttab_free_pages(int nr_pages, struct page **pages) > ClearPagePrivate(pages[i]); > } > } > +} > +EXPORT_SYMBOL(gnttab_pages_clear_private); > + > +/** > + * gnttab_free_pages - free pages allocated by gnttab_alloc_pages() > + * @nr_pages; number of pages to free > + * @pages: the pages > + */ > +void gnttab_free_pages(int nr_pages, struct page **pages) > +{ > + gnttab_pages_clear_private(nr_pages, pages); > free_xenballooned_pages(nr_pages, pages); > } > EXPORT_SYMBOL(gnttab_free_pages); > diff --git a/include/xen/grant_table.h b/include/xen/grant_table.h > index 2e37741f6b8d..de03f2542bb7 100644 > --- a/include/xen/grant_table.h > +++ b/include/xen/grant_table.h > @@ -198,6 +198,9 @@ void gnttab_free_auto_xlat_frames(void); > int gnttab_alloc_pages(int nr_pages, struct page **pages); > void gnttab_free_pages(int nr_pages, struct page **pages); > > +int gnttab_pages_set_private(int nr_pages, struct page **pages); > +void gnttab_pages_clear_private(int nr_pages, struct page **pages); > + > int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, > struct gnttab_map_grant_ref *kmap_ops, > struct page **pages, unsigned int count); > -- > 2.17.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings
On Tue, May 29, 2018 at 08:41:42AM +0200, Andrzej Hajda wrote: > On 24.05.2018 18:41, Sandeep Panda wrote: > > Document the bindings used for the sn65dsi86 DSI to eDP bridge. > > > > Changes in v1: > > - Rephrase the dt-binding descriptions to be more inline with existing > >bindings (Andrzej Hajda). > > - Add missing dt-binding that are parsed by corresponding driver > >(Andrzej Hajda). > > > > Changes in v2: > > - Remove edp panel specific dt-binding entries. Only keep bridge > >specific entries (Sean Paul). > > - Remove custom-modes dt entry since its usage is removed from driver also > > (Sean Paul). > > - Remove is-pluggable dt entry since this will not be needed anymore (Sean > > Paul). > > > > Changes in v3: > > - Remove irq-gpio dt entry and instead populate is an interrupt > >property (Rob Herring). > > > > Changes in v4: > > - Add link to bridge chip datasheet (Stephen Boyd) > > - Add vpll and vcc regulator supply bindings (Stephen Boyd) > > - Add ref clk optional dt binding (Stephen Boyd) > > - Add gpio-controller optional dt binding (Stephen Boyd) > > > > Changes in v5: > > - Use clock property to specify the input refclk (Stephen Boyd). > > - Update gpio cell and pwm cell numbers (Stephen Boyd). > > > > Changes in v6: > > - Add property to mention the lane mapping scheme and polarity inversion > >(Stephen Boyd). > > > > Signed-off-by: Sandeep Panda > > --- > > .../bindings/display/bridge/ti,sn65dsi86.txt | 89 > > ++ > > 1 file changed, 89 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt > > > > diff --git > > a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt > > b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt > > new file mode 100644 > > index 000..4a771a3 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt > > @@ -0,0 +1,89 @@ > > +SN65DSI86 DSI to eDP bridge chip > > + > > + > > +This is the binding for Texas Instruments SN65DSI86 bridge. > > +http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86=pdf > > + > > +Required properties: > > +- compatible: Must be "ti,sn65dsi86" > > +- reg: i2c address of the chip, 0x2d as per datasheet > > +- enable-gpios: OF device-tree gpio specification for bridge_en pin > > info about active high should be added > > > + > > +- vccio-supply: A 1.8V supply that powers up the digital IOs. > > +- vpll-supply: A 1.8V supply that powers up the displayport PLL. > > +- vcca-supply: A 1.2V supply that powers up the analog circuits. > > +- vcc-supply: A 1.2V supply that powers up the digital core. > > + > > +Optional properties: > > +- interrupts: Specifier for the SN65DSI86 interrupt line. > > +- hpd-gpios: Specifications for HPD gpio pin. > > Again, please specify active level. Having this property in the bridge node is strange. Also, does eDP normally have a HPD signal? If you are using this for DP, then this property goes in the connector node (or is absent if the bridge chip has a dedicated signal). > > + > > +- gpio-controller: Marks the device has a GPIO controller. > > +- #gpio-cells: Should be two. The first cell is the pin number and > > + the second cell is used to specify flags. > > + See ../../gpio/gpio.txt for more information. > > +- #pwm-cells : Should be one. See ../../pwm/pwm.txt for description of > > + the cell formats. > > + > > +- clock-names: should be "refclk" > > +- clocks: Specification for input reference clock. The reference > > + clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz. > > + > > +- lane-config: Specification to describe the logical to physical lane > > + mapping scheme and polarity inversion of lanes. > > Please describe this property, I guess it is about DSI lanes, and it > should be exact(?) four pair of numbers, what are meaning and ranges of > both numbers. What should be assumed if property is not present. Btw you > can look into other bindings for reference, I guess there are already > bindings having such property. In fact, IIRC, some QCom bindings already have a property. Maybe it's the same. If so, don't describe it twice. Document in common location and just reference the common definition and add any constraints (like active level for a GPIO). Is this DSI or eDP lanes? Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/scheduler: Avoid using wait_event_killable for dying process.
Dying process might be blocked from receiving any more signals so avoid using it. Also retire enity->fini_status and just check the SW queue, if it's not empty do the fallback cleanup. Also handle entity->last_scheduled == NULL use case which happens when HW ring is already hangged whem a new entity tried to enqeue jobs. Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/scheduler/gpu_scheduler.c | 47 ++- include/drm/gpu_scheduler.h | 1 - 2 files changed, 34 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c b/drivers/gpu/drm/scheduler/gpu_scheduler.c index 44d4807..4d038f9 100644 --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c @@ -135,7 +135,6 @@ int drm_sched_entity_init(struct drm_gpu_scheduler *sched, entity->rq = rq; entity->sched = sched; entity->guilty = guilty; - entity->fini_status = 0; entity->last_scheduled = NULL; spin_lock_init(>rq_lock); @@ -173,7 +172,8 @@ static bool drm_sched_entity_is_initialized(struct drm_gpu_scheduler *sched, static bool drm_sched_entity_is_idle(struct drm_sched_entity *entity) { rmb(); - if (spsc_queue_peek(>job_queue) == NULL) + + if (entity->rq == NULL || spsc_queue_peek(>job_queue) == NULL) return true; return false; @@ -227,12 +227,16 @@ void drm_sched_entity_do_release(struct drm_gpu_scheduler *sched, * The client will not queue more IBs during this fini, consume existing * queued IBs or discard them on SIGKILL */ - if ((current->flags & PF_SIGNALED) && current->exit_code == SIGKILL) - entity->fini_status = -ERESTARTSYS; + if ((current->flags & PF_EXITING)) + wait_event_timeout(sched->job_scheduled, + drm_sched_entity_is_idle(entity), msecs_to_jiffies(1000)); else - entity->fini_status = wait_event_killable(sched->job_scheduled, - drm_sched_entity_is_idle(entity)); - drm_sched_entity_set_rq(entity, NULL); + wait_event_killable(sched->job_scheduled, drm_sched_entity_is_idle(entity)); + + + /* For killed process disable any more IBs enqueue right now */ + if ((current->flags & PF_EXITING) && (current->exit_code == SIGKILL)) + drm_sched_entity_set_rq(entity, NULL); } EXPORT_SYMBOL(drm_sched_entity_do_release); @@ -247,7 +251,13 @@ EXPORT_SYMBOL(drm_sched_entity_do_release); void drm_sched_entity_cleanup(struct drm_gpu_scheduler *sched, struct drm_sched_entity *entity) { - if (entity->fini_status) { + + drm_sched_entity_set_rq(entity, NULL); + + /* Consumption of existing IBs wasn't completed. Forcefully +* remove them here. +*/ + if (spsc_queue_peek(>job_queue)) { struct drm_sched_job *job; int r; @@ -267,12 +277,22 @@ void drm_sched_entity_cleanup(struct drm_gpu_scheduler *sched, struct drm_sched_fence *s_fence = job->s_fence; drm_sched_fence_scheduled(s_fence); dma_fence_set_error(_fence->finished, -ESRCH); - r = dma_fence_add_callback(entity->last_scheduled, >finish_cb, - drm_sched_entity_kill_jobs_cb); - if (r == -ENOENT) + + /* +* When pipe is hanged by older entity, new entity might +* not even have chance to submit it's first job to HW +* and so entity->last_scheduled will remain NULL +*/ + if (!entity->last_scheduled) drm_sched_entity_kill_jobs_cb(NULL, >finish_cb); - else if (r) - DRM_ERROR("fence add callback failed (%d)\n", r); + else { + r = dma_fence_add_callback(entity->last_scheduled, >finish_cb, + drm_sched_entity_kill_jobs_cb); + if (r == -ENOENT) + drm_sched_entity_kill_jobs_cb(NULL, >finish_cb); + else if (r) + DRM_ERROR("fence add callback failed (%d)\n", r); + } } } @@ -713,6 +733,7 @@ static int drm_sched_main(void *param) continue; sched_job = drm_sched_entity_pop_job(entity); + if (!sched_job) continue; diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h index dec6558..d220ac9 100644 --- a/include/drm/gpu_scheduler.h
Re: [PATCH] drm/atomic: Set current atomic state in drm_private_state
On Wed, May 30, 2018 at 06:30:52PM +0100, Alexandru Gheorghe wrote: > drm_private_state has a back pointer to the drm_atomic_state, > however that was not initialized in drm_atomic_get_private_obj_state > after duplication, as it is the case for other drm atomic getters > > Signed-off-by: Alexandru Gheorghe > --- > drivers/gpu/drm/drm_atomic.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c > index 7d25c42..249aaf8 100644 > --- a/drivers/gpu/drm/drm_atomic.c > +++ b/drivers/gpu/drm/drm_atomic.c > @@ -1108,6 +1108,7 @@ drm_atomic_get_private_obj_state(struct > drm_atomic_state *state, > state->private_objs[index].old_state = obj->state; > state->private_objs[index].new_state = obj_state; > state->private_objs[index].ptr = obj; > + obj_state->state = state; Reviewed-by: Ville Syrjälä I guess no one ever used that pointer. Should we add some WARNs to drm_atomic_helper_swap_state() to make sure these are correct? I think in general life might be nicer if we didn't even have these pointers at all. As it stands it's pretty easy to accidentally use them when you're not supposed to (eg. after swap_state() try to use the new_state->state). But there's tons of code that would need to be touched to eliminate them so not a very pleasant project. > > state->num_private_objs = num_objs; > > -- > 2.7.4 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 12/13] drm/vc4: Stop updating plane->fb/crtc
Ville Syrjala writes: > From: Ville Syrjälä > > We want to get rid of plane->fb/crtc on atomic drivers. Stop setting > them. > > Cc: Eric Anholt > Signed-off-by: Ville Syrjälä > Reviewed-by: Maarten Lankhorst > Reviewed-by: Daniel Vetter Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106735] [amdgpu] all displays reconnect after failed EDID read
https://bugs.freedesktop.org/show_bug.cgi?id=106735 --- Comment #3 from dwagner --- (In reply to Matthias from comment #2) > Should I try to force a binary EDID for the connected PSVR? At this time, I would recommend against this: I experience consistent crashes on evey S3 resume if use the kernel command line parameter to force a certain binary EDID. Which is a pity, because (a) this worked fine with prior kernel versions until early October 2017 and (b) it was useful when waking up the computer remotely while the connected display is still switched off. See also: https://bugs.freedesktop.org/show_bug.cgi?id=103277 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/amdgpu: move amdgpu_ctx_mgr_entity_fini to f_ops flush hook.
With this we can now terminate jobs enqueue into SW queue the moment the task is being killed instead of waiting for last user of drm file to release it. Also stop checking for kref_read(>refcount) == 1 when calling drm_sched_entity_do_release since other task might still hold a reference to this entity but we don't care since KILL means terminate job submission regardless of what other tasks are doing. Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 13 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 1 - 3 files changed, 19 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c index c5bb362..db69045 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c @@ -452,23 +452,24 @@ void amdgpu_ctx_mgr_entity_fini(struct amdgpu_ctx_mgr *mgr) idp = >ctx_handles; + mutex_lock(>lock); idr_for_each_entry(idp, ctx, id) { - if (!ctx->adev) + if (!ctx->adev) { + mutex_unlock(>lock); return; + } for (i = 0; i < ctx->adev->num_rings; i++) { if (ctx->adev->rings[i] == >adev->gfx.kiq.ring) continue; - if (kref_read(>refcount) == 1) - drm_sched_entity_do_release(>adev->rings[i]->sched, - >rings[i].entity); - else - DRM_ERROR("ctx %p is still alive\n", ctx); + drm_sched_entity_do_release(>adev->rings[i]->sched, + >rings[i].entity); } } + mutex_unlock(>lock); } void amdgpu_ctx_mgr_entity_cleanup(struct amdgpu_ctx_mgr *mgr) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c index b0bf2f2..36a9acf 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -855,9 +855,21 @@ static const struct dev_pm_ops amdgpu_pm_ops = { .runtime_idle = amdgpu_pmops_runtime_idle, }; +static int amdgpu_flush(struct file *f, fl_owner_t id) +{ + struct drm_file *file_priv = f->private_data; + struct amdgpu_fpriv *fpriv = file_priv->driver_priv; + + amdgpu_ctx_mgr_entity_fini(>ctx_mgr); + + return 0; +} + + static const struct file_operations amdgpu_driver_kms_fops = { .owner = THIS_MODULE, .open = drm_open, + .flush = amdgpu_flush, .release = drm_release, .unlocked_ioctl = amdgpu_drm_ioctl, .mmap = amdgpu_mmap, diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c index ca21549..1239384 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c @@ -930,7 +930,6 @@ void amdgpu_driver_postclose_kms(struct drm_device *dev, return; pm_runtime_get_sync(dev->dev); - amdgpu_ctx_mgr_entity_fini(>ctx_mgr); if (adev->asic_type != CHIP_RAVEN) { amdgpu_uvd_free_handles(adev, file_priv); -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/8] drm/v3d: add CONFIG_MMU dependency
Arnd Bergmann writes: > Without CONFIG_MMU, we get a link error: > > drivers/gpu/drm/v3d/v3d_bo.o: In function `v3d_gem_fault': > v3d_bo.c:(.text+0x3ca): undefined reference to `vm_insert_mixed' > > The other drivers with this problem already depend on CONFIG_MMU, > so let's do the same thing here. > > Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D > V3.x+") > Signed-off-by: Arnd Bergmann Applied to drm-misc-next-fixes. Thanks! signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] drm/panel: Add support for Truly NT35597 panel
On Wed, May 30, 2018 at 09:47:25AM -0600, Jordan Crouse wrote: > On Fri, May 25, 2018 at 05:27:51PM -0700, Abhinav Kumar wrote: > > Add support for Truly NT35597 panel used > > in MSM reference platforms. > > > > This panel supports both single DSI and dual DSI > > modes. > > > > However, this patch series adds support only for > > dual DSI mode. > > > > Changes in v4: > > - Fix the license identifier > > - Fix formatting issues for the regulator loads > > - Fix error messages and return code > > > > Signed-off-by: Archit Taneja > > Signed-off-by: Abhinav Kumar > > --- > > drivers/gpu/drm/panel/Kconfig | 8 + > > drivers/gpu/drm/panel/Makefile | 1 + > > drivers/gpu/drm/panel/panel-truly-nt35597.c | 576 > > > > 3 files changed, 585 insertions(+) > > create mode 100644 drivers/gpu/drm/panel/panel-truly-nt35597.c > > > > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig > > index 25682ff..2fcd9b1 100644 > > --- a/drivers/gpu/drm/panel/Kconfig > > +++ b/drivers/gpu/drm/panel/Kconfig > > @@ -177,4 +177,12 @@ config DRM_PANEL_SITRONIX_ST7789V > > Say Y here if you want to enable support for the Sitronix > > ST7789V controller for 240x320 LCD panels > > > > +config DRM_PANEL_TRULY_NT35597_WQXGA > > + tristate "Truly WQXGA" > > + depends on OF > > + depends on DRM_MIPI_DSI > > + select VIDEOMODE_HELPERS > > + help > > + Say Y here if you want to enable support for Truly NT35597 WQXGA Dual > > DSI > > + Video Mode panel > > endmenu > > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile > > index f26efc1..056ea93 100644 > > --- a/drivers/gpu/drm/panel/Makefile > > +++ b/drivers/gpu/drm/panel/Makefile > > @@ -18,3 +18,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += > > panel-seiko-43wvf1g.o > > obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o > > obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o > > obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o > > +obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o > > diff --git a/drivers/gpu/drm/panel/panel-truly-nt35597.c > > b/drivers/gpu/drm/panel/panel-truly-nt35597.c > > new file mode 100644 > > index 000..a57cbf0 > > --- /dev/null > > +++ b/drivers/gpu/drm/panel/panel-truly-nt35597.c > > @@ -0,0 +1,576 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > I guess it is up to Sean and Rob if they want to accept // comments for SPDX. > I'm not sure there is a hard and fast rule about it. > Hard meh from me. Looks like there are plenty of examples of both in drm. Sean > > +/* > > + * Copyright (c) 2018, The Linux Foundation. All rights reserved. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > +#include > > +#include > > + > > +#include > > +#include > > +#include > > + > > +static const char * const regulator_names[] = { > > + "vdda", > > + "vdispp", > > + "vdispn" > > The reason why the coding style insists on commas for the last member of an > listy is that if you added another item the resulting patch would > only need one line instead of three. For example: > > + "foo", > > instead of: > > - "vdispn" > + "vdispn", > + "foo", > > > > -- > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] drm/panel: Add support for Truly NT35597 panel
On Fri, May 25, 2018 at 05:27:51PM -0700, Abhinav Kumar wrote: > Add support for Truly NT35597 panel used > in MSM reference platforms. > > This panel supports both single DSI and dual DSI > modes. > > However, this patch series adds support only for > dual DSI mode. > > Changes in v4: > - Fix the license identifier > - Fix formatting issues for the regulator loads > - Fix error messages and return code > > Signed-off-by: Archit Taneja > Signed-off-by: Abhinav Kumar > --- > drivers/gpu/drm/panel/Kconfig | 8 + > drivers/gpu/drm/panel/Makefile | 1 + > drivers/gpu/drm/panel/panel-truly-nt35597.c | 576 > > 3 files changed, 585 insertions(+) > create mode 100644 drivers/gpu/drm/panel/panel-truly-nt35597.c > > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig > index 25682ff..2fcd9b1 100644 > --- a/drivers/gpu/drm/panel/Kconfig > +++ b/drivers/gpu/drm/panel/Kconfig > @@ -177,4 +177,12 @@ config DRM_PANEL_SITRONIX_ST7789V > Say Y here if you want to enable support for the Sitronix > ST7789V controller for 240x320 LCD panels > > +config DRM_PANEL_TRULY_NT35597_WQXGA > + tristate "Truly WQXGA" > + depends on OF > + depends on DRM_MIPI_DSI > + select VIDEOMODE_HELPERS > + help > + Say Y here if you want to enable support for Truly NT35597 WQXGA Dual > DSI > + Video Mode panel > endmenu > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile > index f26efc1..056ea93 100644 > --- a/drivers/gpu/drm/panel/Makefile > +++ b/drivers/gpu/drm/panel/Makefile > @@ -18,3 +18,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += > panel-seiko-43wvf1g.o > obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o > obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o > obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o > +obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o > diff --git a/drivers/gpu/drm/panel/panel-truly-nt35597.c > b/drivers/gpu/drm/panel/panel-truly-nt35597.c > new file mode 100644 > index 000..a57cbf0 > --- /dev/null > +++ b/drivers/gpu/drm/panel/panel-truly-nt35597.c > @@ -0,0 +1,576 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c) 2018, The Linux Foundation. All rights reserved. > + */ > + > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > + > +#include > +#include > +#include > + > +static const char * const regulator_names[] = { > + "vdda", > + "vdispp", > + "vdispn" > +}; > + > +static unsigned long const regulator_enable_loads[] = { > + 62000, > + 10, > + 10, > +}; > + > +static unsigned long const regulator_disable_loads[] = { > + 80, > + 100, > + 100, > +}; > + > +struct truly_wqxga { > + struct device *dev; > + struct drm_panel panel; > + > + struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)]; > + > + struct gpio_desc *reset_gpio; > + struct gpio_desc *mode_gpio; > + > + struct backlight_device *backlight; > + struct videomode vm; > + > + struct mipi_dsi_device *dsi[2]; > + > + bool prepared; > + bool enabled; > +}; > + > +static inline struct truly_wqxga *panel_to_truly_wqxga(struct drm_panel > *panel) > +{ > + return container_of(panel, struct truly_wqxga, panel); > +} > + > +static int truly_wqxga_power_on(struct truly_wqxga *ctx) > +{ > + int ret, i; > + > + for (i = 0; i < ARRAY_SIZE(ctx->supplies); i++) { > + ret = regulator_set_load(ctx->supplies[i].consumer, > + regulator_enable_loads[i]); > + if (ret) > + return ret; > + } > + > + ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies); > + if (ret < 0) > + return ret; > + > + msleep(20); > + gpiod_set_value(ctx->reset_gpio, 1); > + msleep(20); > + gpiod_set_value(ctx->reset_gpio, 0); > + msleep(20); > + gpiod_set_value(ctx->reset_gpio, 1); > + msleep(50); Why is this needed? Could you please comment? Also, it seems like this is active low? You should specify that in the dt, and let gpiod translate the value. > + > + return 0; > +} > + > +static int truly_wqxga_power_off(struct truly_wqxga *ctx) > +{ > + int ret, i; > + > + gpiod_set_value(ctx->reset_gpio, 0); > + > + for (i = 0; i < ARRAY_SIZE(ctx->supplies); i++) { > + ret = regulator_set_load(ctx->supplies[i].consumer, > + regulator_disable_loads[i]); > + if (ret) > + return ret; > + } > + > + return regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies); > +} > + > +static int truly_wqxga_disable(struct drm_panel *panel) > +{ > + struct truly_wqxga *ctx = panel_to_truly_wqxga(panel); > + > + if (!ctx->enabled) > +
Re: [PATCH 6/9] drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap
Noralf Trønnes writes: > These are needed for pl111 to use the generic fbdev emulation. Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 05/24] Revert "drm: Nerf the preclose callback for modern drivers"
Qiang Yu writes: > On Thu, May 24, 2018 at 3:51 PM, Daniel Vetter wrote: >> On Thu, May 24, 2018 at 09:18:04AM +0800, Qiang Yu wrote: >>> On Thu, May 24, 2018 at 4:31 AM, Daniel Vetter wrote: >>> > On Wed, May 23, 2018 at 2:59 PM, Qiang Yu wrote: >>> >> On Wed, May 23, 2018 at 5:04 PM, Daniel Vetter wrote: >>> >>> On Tue, May 22, 2018 at 09:04:17AM +0800, Qiang Yu wrote: >>> On Tue, May 22, 2018 at 3:37 AM, Eric Anholt wrote: >>> > Qiang Yu writes: >>> > >>> >> This reverts commit 45c3d213a400c952ab7119f394c5293bb6877e6b. >>> >> >>> >> lima driver need preclose to wait all task in the context >>> >> created within closing file to finish before free all the >>> >> buffer object. Otherwise pending tesk may fail and get >>> >> noisy MMU fault message. >>> >> >>> >> Move this wait to each buffer object free function can >>> >> achieve the same result but some buffer object is shared >>> >> with other file context, but we only want to wait the >>> >> closing file context's tasks. So the implementation is >>> >> not that straight forword compared to the preclose one. >>> > >>> > You should just separate your MMU structures from drm_file, and have >>> > drm_file and the jobs using it keep a reference on them. This is >>> > what >>> > I've done in V3D as well. >>> >>> It's not the VM/MMU struct that causes this problem, it's each buffer >>> object that gets freed before task is done (postclose is after buffer >>> free). >>> If you mean I should keep reference of all buffers for tasks, that's >>> not >>> as simple as just waiting task done before free buffers. >>> >>> >>> >>> Why can't you do that waiting in the postclose hook? If it's the lack of >>> >>> reference-counting in your driver for gem bo, then I'd say you need to >>> >>> roll out some reference counting. Relying on the implicit reference >>> >>> provided by the core is kinda not so great (which was the reason I've >>> >>> thrown out the preclose hook). There's also per-bo open/close hooks. >>> >> >>> >> It's possible to not use preclose, but the implementation is not as >>> >> simple >>> >> and straight forward as the preclose I think. There're two method I can >>> >> think of: >>> >> 1. do wait when free buffers callback unmap buffer from this process's >>> >> lima VM (wait buffer reservation object), this is fine and simple, >>> >> but >>> >> there's case that this buffer is shared between two processes, so the >>> >> best way should be only waiting fences from this process, so we'd >>> >> better do some record for fences for a "perfect waiting" >>> >> 2. keep a reference of involved buffers for a task, unreference it when >>> >> task done, also keep a reference of the buffer mapping in this >>> >> process's >>> >> lima VM (this is more complicated to implement) >>> >> >>> >> But if there's a preclose, just wait all this process's task done, then >>> >> unmap/free buffers, it's simple and straight forward. I'd like to hear if >>> >> there's other better way for only use postclose. >>> > >>> > Refcount your buffers. Borrowing references from other places tends to >>> > result in a maintenance headache with no end. So solution 2. >>> >>> In current lima implementation, refcount involved buffer for task is done >>> in user space. So kernel's task object don't keep that. User space >>> driver is responsible not unmap/free buffer before task is complete. This >>> works simple and fine except the case that user press Ctrl+C to terminate >>> the application which will force to close drm fd. I really don't think >>> adding >>> buffer refcount for tasks in kernel just for this case is valuable because >>> it has no benefits for normal case but some extra load. >> >> If kernel correctness relies on refcounting you have a giantic security >> problem. You need to fix that. Kernel _must_ assume that userspace is >> evil, trying to pull it over the table. > > It is OK if evil user free/unmap the buffer when task is not done > in my implementation. It will generate a MMU fault in that case and kernel > driver will do recovery. > > So does the Ctrl+C case, if don't deal with it, just get some noisy MMU > fault warning and a HW reset recovery. How about an app rendering to shared buffers, which glFlush()es and exits cleanly but doesn't close the DRI screen? What would cause that app's rendering to get completed succesfully instead of faulting to death? You really do need to refcount the buffers used in a rendering job so they don't get freed early. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/13] drm/vmwgfx: Stop using plane->fb in vmw_kms_helper_dirty()
On Fri, May 25, 2018 at 09:50:34PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Instead of plane->fb (which we're going to deprecate for atomic drivers) > we need to look at plane->state->fb. The maze of code leading to > vmw_kms_helper_dirty() wasn't particularly clear, but my analysis > concluded that the calls originating from vmw_*_primary_plane_atomic_update() > all pass in the crtc which means we'll never end up in this branch > of the function. All other callers use drm_modeset_lock_all() somewhere > higher up, which means accessing plane->state is safe. We'll toss in > a lockdep assert to catch wrongdoers. > > v2: Drop the comment and make the code do what it did before (Thomas) > > Cc: Deepak Rawat > Cc: Thomas Hellstrom > Cc: Sinclair Yeh > Cc: VMware Graphics > Cc: Daniel Vetter > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c > b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c > index 2e4c38bb846d..5417eb1b486e 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c > @@ -2326,9 +2326,12 @@ int vmw_kms_helper_dirty(struct vmw_private *dev_priv, > } else { > list_for_each_entry(crtc, _priv->dev->mode_config.crtc_list, > head) { > - if (crtc->primary->fb != >base) > - continue; > - units[num_units++] = vmw_crtc_to_du(crtc); > + struct drm_plane *plane = crtc->primary; > + > + lockdep_assert_held(>mutex); kbuild test robot told me >> include/linux/lockdep.h:347:52: error: 'struct drm_modeset_lock' has >> no member named 'dep_map' #define lockdep_is_held(lock) lock_is_held(&(lock)->dep_map) Maybe I'll just drop the asserts? Or do people really want them (in which case I gues I need to dig out the underlying mutex)? > + > + if (plane->state->fb == >base) > + units[num_units++] = vmw_crtc_to_du(crtc); > } > } > > -- > 2.16.1 -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-fixes for 4.17
Hi Dave, One more fix that came in today. It's fixing a regression introduced during the merge window, so it'd be nice to get it in. drm-misc-fixes-2018-05-30: dw-hdmi: Fix Oops regression from rc1 (Neil) Cc: Neil Armstrong Cheers, Sean The following changes since commit 2bc5ff0bdc00d81d719dad74589317a260d583ed: drm/omap: fix NULL deref crash with SDI displays (2018-05-24 19:14:46 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-05-30 for you to fetch changes up to c32048d9e93a5ab925d745396c63e7b912147f0a: drm/bridge/synopsys: dw-hdmi: fix dw_hdmi_setup_rx_sense (2018-05-30 13:42:39 -0400) dw-hdmi: Fix Oops regression from rc1 (Neil) Cc: Neil Armstrong Neil Armstrong (1): drm/bridge/synopsys: dw-hdmi: fix dw_hdmi_setup_rx_sense drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 15 --- drivers/gpu/drm/meson/meson_dw_hdmi.c | 2 +- include/drm/bridge/dw_hdmi.h | 2 +- 3 files changed, 6 insertions(+), 13 deletions(-) -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] xen/grant-table: Allow allocating buffers suitable for DMA
On 05/30/2018 06:20 PM, Boris Ostrovsky wrote: On 05/30/2018 02:34 AM, Oleksandr Andrushchenko wrote: On 05/29/2018 10:10 PM, Boris Ostrovsky wrote: On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: +/** + * gnttab_dma_free_pages - free DMAable pages + * @args: arguments to the function + */ +int gnttab_dma_free_pages(struct gnttab_dma_alloc_args *args) +{ + xen_pfn_t *frames; + size_t size; + int i, ret; + + gnttab_pages_clear_private(args->nr_pages, args->pages); + + frames = kcalloc(args->nr_pages, sizeof(*frames), GFP_KERNEL); Any way you can do it without allocating memory? One possibility is to keep allocated frames from gnttab_dma_alloc_pages(). (Not sure I like that either but it's the only thing I can think of). Yes, I was also thinking about storing the allocated frames array from gnttab_dma_alloc_pages(), but that seemed not to be clear enough as the caller of the gnttab_dma_alloc_pages will need to store those frames in some context, so we can pass them on free. But the caller doesn't really need the frames which might confuse, so I decided to make those allocations on the fly. But I can still rework that to store the frames if you insist: please let me know. I would prefer not to allocate anything in the release path. Yes, I realize that dragging frames array around is not necessary but IMO it's better than potentially failing an allocation during a teardown. A comment in the struct definition could explain the reason for having this field. Then I would suggest we have it this way: current API requires that struct page **pages are allocated from outside. So, let's allocate the frames from outside as well. This way the caller is responsible for both pages and frames arrays and API looks consistent. + if (!frames) + return -ENOMEM; + + for (i = 0; i < args->nr_pages; i++) + frames[i] = page_to_xen_pfn(args->pages[i]); Not xen_page_to_gfn()? Well, according to [1] it should be : /* XENMEM_populate_physmap requires a PFN based on Xen * granularity. */ frame_list[i] = page_to_xen_pfn(page); Ah, yes. I was looking at decrease_reservation and automatically assumed the same parameter type. Good, then this one is resolved -boris Thank you, Oleksandr ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsys: dw-hdmi: fix dw_hdmi_setup_rx_sense
On Wed, May 30, 2018 at 11:43:58AM +0200, Neil Armstrong wrote: > The dw_hdmi_setup_rx_sense exported function should not use struct device > to recover the dw-hdmi context using drvdata, but take struct dw_hdmi > directly like other exported functions. > > This caused a regression using Meson DRM on S905X since v4.17-rc1 : > > Internal error: Oops: 9607 [#1] PREEMPT SMP > [...] > CPU: 0 PID: 124 Comm: irq/32-dw_hdmi_ Not tainted 4.17.0-rc7 #2 > Hardware name: Libre Technology CC (DT) > [...] > pc : osq_lock+0x54/0x188 > lr : __mutex_lock.isra.0+0x74/0x530 > [...] > Process irq/32-dw_hdmi_ (pid: 124, stack limit = 0xadf418cb) > Call trace: > osq_lock+0x54/0x188 > __mutex_lock_slowpath+0x10/0x18 > mutex_lock+0x30/0x38 > __dw_hdmi_setup_rx_sense+0x28/0x98 > dw_hdmi_setup_rx_sense+0x10/0x18 > dw_hdmi_top_thread_irq+0x2c/0x50 > irq_thread_fn+0x28/0x68 > irq_thread+0x10c/0x1a0 > kthread+0x128/0x130 > ret_from_fork+0x10/0x18 > Code: 34000964 d00050a2 51000484 9135c042 (f864d844) > ---[ end trace 945641e1fbbc07da ]--- > note: irq/32-dw_hdmi_[124] exited with preempt_count 1 > genirq: exiting task "irq/32-dw_hdmi_" (124) is an active IRQ thread (irq 32) > > Fixes: eea034af90c6 ("drm/bridge/synopsys: dw-hdmi: don't clobber drvdata") > Signed-off-by: Neil Armstrong > Tested-by: Koen Kooi Thanks for your patch, Neil. I've applied it to -misc-fixes and will send it to Dave in hope it can sneak into 4.17. Sean > --- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 15 --- > drivers/gpu/drm/meson/meson_dw_hdmi.c | 2 +- > include/drm/bridge/dw_hdmi.h | 2 +- > 3 files changed, 6 insertions(+), 13 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > index ec8d000..3c136f2b 100644 > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > @@ -2077,7 +2077,7 @@ static irqreturn_t dw_hdmi_hardirq(int irq, void > *dev_id) > return ret; > } > > -void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense) > +void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense) > { > mutex_lock(>mutex); > > @@ -2103,13 +2103,6 @@ void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, > bool hpd, bool rx_sense) > } > mutex_unlock(>mutex); > } > - > -void dw_hdmi_setup_rx_sense(struct device *dev, bool hpd, bool rx_sense) > -{ > - struct dw_hdmi *hdmi = dev_get_drvdata(dev); > - > - __dw_hdmi_setup_rx_sense(hdmi, hpd, rx_sense); > -} > EXPORT_SYMBOL_GPL(dw_hdmi_setup_rx_sense); > > static irqreturn_t dw_hdmi_irq(int irq, void *dev_id) > @@ -2145,9 +2138,9 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id) >*/ > if (intr_stat & > (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) { > - __dw_hdmi_setup_rx_sense(hdmi, > - phy_stat & HDMI_PHY_HPD, > - phy_stat & HDMI_PHY_RX_SENSE); > + dw_hdmi_setup_rx_sense(hdmi, > +phy_stat & HDMI_PHY_HPD, > +phy_stat & HDMI_PHY_RX_SENSE); > > if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0) > cec_notifier_set_phys_addr(hdmi->cec_notifier, > diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c > b/drivers/gpu/drm/meson/meson_dw_hdmi.c > index a393095..c9ad456 100644 > --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c > +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c > @@ -529,7 +529,7 @@ static irqreturn_t dw_hdmi_top_thread_irq(int irq, void > *dev_id) > if (stat & HDMITX_TOP_INTR_HPD_RISE) > hpd_connected = true; > > - dw_hdmi_setup_rx_sense(dw_hdmi->dev, hpd_connected, > + dw_hdmi_setup_rx_sense(dw_hdmi->hdmi, hpd_connected, > hpd_connected); > > drm_helper_hpd_irq_event(dw_hdmi->encoder.dev); > diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h > index dd2a8cf..ccb5aa8 100644 > --- a/include/drm/bridge/dw_hdmi.h > +++ b/include/drm/bridge/dw_hdmi.h > @@ -151,7 +151,7 @@ struct dw_hdmi *dw_hdmi_bind(struct platform_device *pdev, >struct drm_encoder *encoder, >const struct dw_hdmi_plat_data *plat_data); > > -void dw_hdmi_setup_rx_sense(struct device *dev, bool hpd, bool rx_sense); > +void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense); > > void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, unsigned int rate); > void dw_hdmi_audio_enable(struct dw_hdmi *hdmi); > -- > 2.7.4 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Sean Paul, Software Engineer,
Re: [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module
On 05/30/2018 06:54 PM, Boris Ostrovsky wrote: On 05/30/2018 04:29 AM, Oleksandr Andrushchenko wrote: On 05/29/2018 11:03 PM, Boris Ostrovsky wrote: On 05/29/2018 02:22 PM, Oleksandr Andrushchenko wrote: On 05/29/2018 09:04 PM, Boris Ostrovsky wrote: On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: @@ -463,11 +457,6 @@ static enum bp_state increase_reservation(unsigned long nr_pages) int rc; unsigned long i; struct page *page; - struct xen_memory_reservation reservation = { - .address_bits = 0, - .extent_order = EXTENT_ORDER, - .domid = DOMID_SELF - }; if (nr_pages > ARRAY_SIZE(frame_list)) nr_pages = ARRAY_SIZE(frame_list); @@ -486,9 +475,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages) page = balloon_next_page(page); } - set_xen_guest_handle(reservation.extent_start, frame_list); - reservation.nr_extents = nr_pages; - rc = HYPERVISOR_memory_op(XENMEM_populate_physmap, ); + rc = xenmem_reservation_increase(nr_pages, frame_list); if (rc <= 0) return BP_EAGAIN; @@ -496,29 +483,7 @@ static enum bp_state increase_reservation(unsigned long nr_pages) page = balloon_retrieve(false); BUG_ON(page == NULL); -#ifdef CONFIG_XEN_HAVE_PVMMU - /* - * We don't support PV MMU when Linux and Xen is using - * different page granularity. - */ - BUILD_BUG_ON(XEN_PAGE_SIZE != PAGE_SIZE); - - if (!xen_feature(XENFEAT_auto_translated_physmap)) { - unsigned long pfn = page_to_pfn(page); - - set_phys_to_machine(pfn, frame_list[i]); - - /* Link back into the page tables if not highmem. */ - if (!PageHighMem(page)) { - int ret; - ret = HYPERVISOR_update_va_mapping( - (unsigned long)__va(pfn << PAGE_SHIFT), - mfn_pte(frame_list[i], PAGE_KERNEL), - 0); - BUG_ON(ret); - } - } -#endif + xenmem_reservation_va_mapping_update(1, , _list[i]); Can you make a single call to xenmem_reservation_va_mapping_update(rc, ...)? You need to keep track of pages but presumable they can be put into an array (or a list). In fact, perhaps we can have balloon_retrieve() return a set of pages. This is actually how it is used later on for dma-buf, but I just didn't want to alter original balloon code too much, but this can be done, in order of simplicity: 1. Similar to frame_list, e.g. static array of struct page* of size ARRAY_SIZE(frame_list): more static memory is used, but no allocations 2. Allocated at run-time with kcalloc: allocation can fail If this is called in freeing DMA buffer code path or in error path then we shouldn't do it. 3. Make balloon_retrieve() return a set of pages: will require list/array allocation and handling, allocation may fail, balloon_retrieve prototype change balloon pages are strung on the lru list. Can we keep have balloon_retrieve return a list of pages on that list? First of all, before we go deep in details, I will highlight the goal of the requested change: for balloon driver we call xenmem_reservation_va_mapping_update(*1*, , _list[i]); from increase_reservation and xenmem_reservation_va_mapping_reset(*1*, ); from decrease_reservation and it seems to be not elegant because of that one page/frame passed while we might have multiple pages/frames passed at once. In the balloon driver the producer of pages for increase_reservation is balloon_retrieve(false) and for decrease_reservation it is alloc_page(gfp). In case of decrease_reservation the page is added on the list: LIST_HEAD(pages); [...] list_add(>lru, ); and in case of increase_reservation it is retrieved page by page and can be put on a list as well with the same code from decrease_reservation, e.g. LIST_HEAD(pages); [...] list_add(>lru, ); Thus, both decrease_reservation and increase_reservation may hold their pages on a list before calling xenmem_reservation_va_mapping_{update|reset}. For that we need a prototype change: xenmem_reservation_va_mapping_reset(, ); But for xenmem_reservation_va_mapping_update it will look like: xenmem_reservation_va_mapping_update(, , ) which seems to be inconsistent. Converting entries of the static frame_list array into corresponding list doesn't seem to be cute as well. For dma-buf use-case arrays are more preferable as dma-buf constructs scatter-gather tables from array of pages etc. and if page list is passed then it needs to be converted into page array anyways. So, we can: 1. Keep the prototypes as is, e.g. accept array of pages and use nr_pages == 1 in case of balloon driver (existing code) 2. Statically allocate struct page* array in the balloon driver and fill it with pages when those pages are retrieved: static struct page *page_list[ARRAY_SIZE(frame_list)]; which will take additional
Re: [PATCH v2 00/13] drm: Eliminate plane->fb/crtc usage for atomic drivers
Thanks Ville. This series: Reviewed-by: Sinclair Yeh On Fri, May 25, 2018 at 09:50:32PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Here are again the last (?) bits of eliminating the plane->fb/crtc > usage for atomic drivers. I've pushed everything else (thanks to > everyone who reviewed them). > > Deepak said he'd tested the vmwgfx stuff, so I think it should be > safe to land. Just missing a bit of review... > > Cc: Alex Deucher > Cc: amd-...@lists.freedesktop.org > Cc: "Christian König" > Cc: Daniel Vetter > Cc: David Airlie > Cc: "David (ChunMing) Zhou" > Cc: Deepak Rawat > Cc: Eric Anholt > Cc: freedr...@lists.freedesktop.org > Cc: Gerd Hoffmann > Cc: Harry Wentland > Cc: Inki Dae > Cc: Joonyoung Shim > Cc: Kyungmin Park > Cc: linux-arm-...@vger.kernel.org > Cc: Rob Clark > Cc: Seung-Woo Kim > Cc: Sinclair Yeh > Cc: Thomas Hellstrom > Cc: virtualizat...@lists.linux-foundation.org > Cc: VMware Graphics > > Ville Syrjälä (13): > drm/vmwgfx: Stop using plane->fb in vmw_kms_atomic_check_modeset() > drm/vmwgfx: Stop using plane->fb in vmw_kms_helper_dirty() > drm/vmwgfx: Stop using plane->fb in vmw_kms_update_implicit_fb() > drm/vmwgfx: Stop updating plane->fb > drm/vmwgfx: Stop using plane->fb in atomic_enable() > drm/vmwgfx: Stop messing about with plane->fb/old_fb/crtc > drm/amdgpu/dc: Stop updating plane->fb > drm/i915: Stop updating plane->fb/crtc > drm/exynos: Stop updating plane->crtc > drm/msm: Stop updating plane->fb/crtc > drm/virtio: Stop updating plane->crtc > drm/vc4: Stop updating plane->fb/crtc > drm: Stop updating plane->crtc/fb/old_fb on atomic drivers > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 - > drivers/gpu/drm/drm_atomic.c | 55 > +++ > drivers/gpu/drm/drm_atomic_helper.c | 15 +-- > drivers/gpu/drm/drm_crtc.c| 8 +++- > drivers/gpu/drm/drm_fb_helper.c | 7 --- > drivers/gpu/drm/drm_framebuffer.c | 5 --- > drivers/gpu/drm/drm_plane.c | 14 +++--- > drivers/gpu/drm/drm_plane_helper.c| 4 +- > drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 - > drivers/gpu/drm/i915/intel_atomic_plane.c | 12 - > drivers/gpu/drm/i915/intel_display.c | 7 ++- > drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 1 - > drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c| 2 - > drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 1 - > drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c| 2 - > drivers/gpu/drm/vc4/vc4_crtc.c| 3 -- > drivers/gpu/drm/virtio/virtgpu_display.c | 2 - > drivers/gpu/drm/vmwgfx/vmwgfx_fb.c| 24 -- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 24 +++--- > drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 - > drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 5 +-- > include/drm/drm_atomic.h | 3 -- > 22 files changed, 46 insertions(+), 154 deletions(-) > > -- > 2.16.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 81620] radeon: fence wait failed (-35) after hybrid suspend on 3.15
https://bugs.freedesktop.org/show_bug.cgi?id=81620 i...@yahoo.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEEDINFO|RESOLVED --- Comment #2 from i...@yahoo.com --- Yes, the bug has been fixed long ago. I'm using vdpau all the time, so I'm sure it is working. At least on 64 bit kernels. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/atomic: Set current atomic state in drm_private_state
drm_private_state has a back pointer to the drm_atomic_state, however that was not initialized in drm_atomic_get_private_obj_state after duplication, as it is the case for other drm atomic getters Signed-off-by: Alexandru Gheorghe --- drivers/gpu/drm/drm_atomic.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 7d25c42..249aaf8 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1108,6 +1108,7 @@ drm_atomic_get_private_obj_state(struct drm_atomic_state *state, state->private_objs[index].old_state = obj->state; state->private_objs[index].new_state = obj_state; state->private_objs[index].ptr = obj; + obj_state->state = state; state->num_private_objs = num_objs; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106258] AMD Xorg start failes with non-4K page sizes
https://bugs.freedesktop.org/show_bug.cgi?id=106258 --- Comment #20 from Ben Crocker --- Please note that the path to the firmware, /lib/firmware/amdgpu, is correct for Red Hat products (RHEL, Fedora, CentOS) as well. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][next] drm/amdgpu/df: fix potential array out-of-bounds read
From: Colin Ian King The comparison with the number of elements in array df_v3_7_channel_number is off-by-one and can produce an array out-of-bounds read if fb_channel_number is equal to the number of elements of the array. Fix this by changing the comparison to >= instead of >. Detected by CoverityScan, CID#1469489 ("Out-of-bounds read") Fixes: 13b581502d51 ("drm/amdgpu/df: implement df v3_6 callback functions (v2)") Signed-off-by: Colin Ian King --- drivers/gpu/drm/amd/amdgpu/df_v3_6.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/df_v3_6.c b/drivers/gpu/drm/amd/amdgpu/df_v3_6.c index 60608b3df881..d5ebe566809b 100644 --- a/drivers/gpu/drm/amd/amdgpu/df_v3_6.c +++ b/drivers/gpu/drm/amd/amdgpu/df_v3_6.c @@ -64,7 +64,7 @@ static u32 df_v3_6_get_hbm_channel_number(struct amdgpu_device *adev) int fb_channel_number; fb_channel_number = adev->df_funcs->get_fb_channel_number(adev); - if (fb_channel_number > ARRAY_SIZE(df_v3_6_channel_number)) + if (fb_channel_number >= ARRAY_SIZE(df_v3_6_channel_number)) fb_channel_number = 0; return df_v3_6_channel_number[fb_channel_number]; -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [DPU PATCH 10/11] drm/msm/dpu: correct dpu_io_util.h include path
On Wed, May 30, 2018 at 08:19:47PM +0530, Rajesh Yadav wrote: > dpu_io_util.h is moved from standard include path > to driver folder, correct the include path in code. > > Signed-off-by: Rajesh Yadav If the previous patch doesn't compile without this fix you should squash them. > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 1 - > drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h | 2 +- > 2 files changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c > b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c > index 24c3274..f997bd9 100644 > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c > @@ -20,7 +20,6 @@ > #include > #include > #include > -#include > > #include "dpu_power_handle.h" > #include "dpu_trace.h" > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h > b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h > index 9a6d4b9..193f468 100644 > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h > @@ -21,7 +21,7 @@ > #define DPU_POWER_HANDLE_ENABLE_BUS_IB_QUOTA 16 > #define DPU_POWER_HANDLE_DISABLE_BUS_IB_QUOTA0 > > -#include > +#include "dpu_io_util.h" > > /* event will be triggered before power handler disable */ > #define DPU_POWER_EVENT_PRE_DISABLE 0x1 -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106666] amdgpu 0000:09:00.0: [gfxhub] VMC page fault (src_id:0 ring:56 vmid:3 pas_id:0), [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, last signaled seq=327845, last emitted seq=32
https://bugs.freedesktop.org/show_bug.cgi?id=10 --- Comment #4 from udo --- Created attachment 139864 --> https://bugs.freedesktop.org/attachment.cgi?id=139864=edit xorg log -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106666] amdgpu 0000:09:00.0: [gfxhub] VMC page fault (src_id:0 ring:56 vmid:3 pas_id:0), [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, last signaled seq=327845, last emitted seq=32
https://bugs.freedesktop.org/show_bug.cgi?id=10 --- Comment #3 from udo --- messages file has similar messages. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106666] amdgpu 0000:09:00.0: [gfxhub] VMC page fault (src_id:0 ring:56 vmid:3 pas_id:0), [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, last signaled seq=327845, last emitted seq=32
https://bugs.freedesktop.org/show_bug.cgi?id=10 --- Comment #2 from udo --- Created attachment 139863 --> https://bugs.freedesktop.org/attachment.cgi?id=139863=edit dmesg Another hang. Was reading slashdot, -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104391] DC R9 285 HDMI audio regression since drm/amd/display: try to find matching audio inst for enc inst first
https://bugs.freedesktop.org/show_bug.cgi?id=104391 --- Comment #8 from Andy Furniss --- I tried agd5f drm-next-4.19-wip, which reports [drm] Display Core initialized with v3.1.47 but still no sound. The warning/bt in dmesg is not there any more. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] drm/panel: Add support for Truly NT35597 panel
On Fri, May 25, 2018 at 05:27:51PM -0700, Abhinav Kumar wrote: > Add support for Truly NT35597 panel used > in MSM reference platforms. > > This panel supports both single DSI and dual DSI > modes. > > However, this patch series adds support only for > dual DSI mode. > > Changes in v4: > - Fix the license identifier > - Fix formatting issues for the regulator loads > - Fix error messages and return code > > Signed-off-by: Archit Taneja > Signed-off-by: Abhinav Kumar > --- > drivers/gpu/drm/panel/Kconfig | 8 + > drivers/gpu/drm/panel/Makefile | 1 + > drivers/gpu/drm/panel/panel-truly-nt35597.c | 576 > > 3 files changed, 585 insertions(+) > create mode 100644 drivers/gpu/drm/panel/panel-truly-nt35597.c > > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig > index 25682ff..2fcd9b1 100644 > --- a/drivers/gpu/drm/panel/Kconfig > +++ b/drivers/gpu/drm/panel/Kconfig > @@ -177,4 +177,12 @@ config DRM_PANEL_SITRONIX_ST7789V > Say Y here if you want to enable support for the Sitronix > ST7789V controller for 240x320 LCD panels > > +config DRM_PANEL_TRULY_NT35597_WQXGA > + tristate "Truly WQXGA" > + depends on OF > + depends on DRM_MIPI_DSI > + select VIDEOMODE_HELPERS > + help > + Say Y here if you want to enable support for Truly NT35597 WQXGA Dual > DSI > + Video Mode panel > endmenu > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile > index f26efc1..056ea93 100644 > --- a/drivers/gpu/drm/panel/Makefile > +++ b/drivers/gpu/drm/panel/Makefile > @@ -18,3 +18,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += > panel-seiko-43wvf1g.o > obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o > obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o > obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o > +obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o > diff --git a/drivers/gpu/drm/panel/panel-truly-nt35597.c > b/drivers/gpu/drm/panel/panel-truly-nt35597.c > new file mode 100644 > index 000..a57cbf0 > --- /dev/null > +++ b/drivers/gpu/drm/panel/panel-truly-nt35597.c > @@ -0,0 +1,576 @@ > +// SPDX-License-Identifier: GPL-2.0 I guess it is up to Sean and Rob if they want to accept // comments for SPDX. I'm not sure there is a hard and fast rule about it. > +/* > + * Copyright (c) 2018, The Linux Foundation. All rights reserved. > + */ > + > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > + > +#include > +#include > +#include > + > +static const char * const regulator_names[] = { > + "vdda", > + "vdispp", > + "vdispn" The reason why the coding style insists on commas for the last member of an listy is that if you added another item the resulting patch would only need one line instead of three. For example: + "foo", instead of: - "vdispn" + "vdispn", + "foo", -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v6 2/6] drm/i915: hdmi: add CEC notifier to intel_hdmi
On Thu, May 24, 2018 at 11:57:17AM +0200, Neil Armstrong wrote: > This patchs adds the cec_notifier feature to the intel_hdmi part > of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate > between each HDMI ports. > The changes will allow the i915 HDMI code to notify EDID and HPD changes > to an eventual CEC adapter. > > Signed-off-by: Neil Armstrong > Reviewed-by: Hans Verkuil > --- > drivers/gpu/drm/i915/Kconfig | 1 + > drivers/gpu/drm/i915/intel_display.h | 20 > drivers/gpu/drm/i915/intel_drv.h | 2 ++ > drivers/gpu/drm/i915/intel_hdmi.c| 13 + > 4 files changed, 36 insertions(+) > > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig > index dfd9588..2d65d56 100644 > --- a/drivers/gpu/drm/i915/Kconfig > +++ b/drivers/gpu/drm/i915/Kconfig > @@ -23,6 +23,7 @@ config DRM_I915 > select SYNC_FILE > select IOSF_MBI > select CRC32 > + select CEC_CORE if CEC_NOTIFIER > help > Choose this option if you have a system that has "Intel Graphics > Media Accelerator" or "HD Graphics" integrated graphics, > diff --git a/drivers/gpu/drm/i915/intel_display.h > b/drivers/gpu/drm/i915/intel_display.h > index 4e7418b..c68d1c8 100644 > --- a/drivers/gpu/drm/i915/intel_display.h > +++ b/drivers/gpu/drm/i915/intel_display.h > @@ -126,6 +126,26 @@ enum port { > > #define port_name(p) ((p) + 'A') > > +static inline const char *port_identifier(enum port port) > +{ > + switch (port) { > + case PORT_A: > + return "Port A"; > + case PORT_B: > + return "Port B"; > + case PORT_C: > + return "Port C"; > + case PORT_D: > + return "Port D"; > + case PORT_E: > + return "Port E"; > + case PORT_F: > + return "Port F"; > + default: > + return ""; > + } > +} Could use a comment to make it clear that this identifier is expected to remain stable since it's referenced from other drivers. > + > enum dpio_channel { > DPIO_CH0, > DPIO_CH1 > diff --git a/drivers/gpu/drm/i915/intel_drv.h > b/drivers/gpu/drm/i915/intel_drv.h > index d436858..b50e51b 100644 > --- a/drivers/gpu/drm/i915/intel_drv.h > +++ b/drivers/gpu/drm/i915/intel_drv.h > @@ -39,6 +39,7 @@ > #include > #include > #include > +#include > > /** > * __wait_for - magic wait macro > @@ -1001,6 +1002,7 @@ struct intel_hdmi { > bool has_audio; > bool rgb_quant_range_selectable; > struct intel_connector *attached_connector; > + struct cec_notifier *notifier; "notifier" seems a bit too generic a name. "cec_notifier" would be better. Apart from that this seems OK to me Reviewed-by: Ville Syrjälä > }; > > struct intel_dp_mst_encoder; > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > b/drivers/gpu/drm/i915/intel_hdmi.c > index 1baef4a..d522b5b 100644 > --- a/drivers/gpu/drm/i915/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > @@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector) > connected = true; > } > > + cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid); > + > return connected; > } > > @@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool > force) > { > enum drm_connector_status status; > struct drm_i915_private *dev_priv = to_i915(connector->dev); > + struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector); > > DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", > connector->base.id, connector->name); > @@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector, bool > force) > > intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS); > > + if (status != connector_status_connected) > + cec_notifier_phys_addr_invalidate(intel_hdmi->notifier); > + > return status; > } > > @@ -2031,6 +2037,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder > *encoder, > > static void intel_hdmi_destroy(struct drm_connector *connector) > { > + if (intel_attached_hdmi(connector)->notifier) > + cec_notifier_put(intel_attached_hdmi(connector)->notifier); > kfree(to_intel_connector(connector)->detect_edid); > drm_connector_cleanup(connector); > kfree(connector); > @@ -2358,6 +2366,11 @@ void intel_hdmi_init_connector(struct > intel_digital_port *intel_dig_port, > u32 temp = I915_READ(PEG_BAND_GAP_DATA); > I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd); > } > + > + intel_hdmi->notifier = cec_notifier_get_conn(dev->dev, > + port_identifier(port)); > + if (!intel_hdmi->notifier) > + DRM_DEBUG_KMS("CEC notifier get failed\n"); > } > > void intel_hdmi_init(struct drm_i915_private *dev_priv, > -- > 2.7.4 > >
[Bug 106735] [amdgpu] all displays reconnect after failed EDID read
https://bugs.freedesktop.org/show_bug.cgi?id=106735 --- Comment #2 from Matthias --- Should I try to force a binary EDID for the connected PSVR? maybe like the solution proposed here: http://hotcashew.com/2013/08/fixing-invalid-edid-in-linux-wit-fglrx/ -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106735] [amdgpu] all displays reconnect after failed EDID read
https://bugs.freedesktop.org/show_bug.cgi?id=106735 --- Comment #1 from Matthias --- Created attachment 139862 --> https://bugs.freedesktop.org/attachment.cgi?id=139862=edit Xorg.log -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106735] [amdgpu] all displays reconnect after failed EDID read
https://bugs.freedesktop.org/show_bug.cgi?id=106735 Bug ID: 106735 Summary: [amdgpu] all displays reconnect after failed EDID read Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: m...@matthias-kastner.de Created attachment 139861 --> https://bugs.freedesktop.org/attachment.cgi?id=139861=edit dmesg I am on ubuntu 18.04 LTS on gnome3 with X.org. I am using amdgpu with a Raden RX 580. > $ lspci -k | grep -EA3 'VGA|3D|Display' > 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] > Ellesmere [Radeon RX 470/480] (rev e7) > Subsystem: ASUSTeK Computer Inc. Ellesmere [Radeon RX 470/480/570/580] > Kernel driver in use: amdgpu > Kernel modules: amdgpu > $ uname -r > 4.15.0-22-generic > $ lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description: Ubuntu 18.04 LTS > Release: 18.04 > Codename: bionic Two screens for working are connected via DVI and HDMI. One HDMI output is connected to a PlayStation VR Headset. The Headset redirects all input to the TV but it is mostly turned off. When turned off but connected to the HDMI output, frequent EDID read fails are reported to syslog: > [drm:log_to_debug_console [amdgpu]] *ERROR* No EDID read. When un-plugging the PSVR Headset from HDMI the errors vanish. After the EDID read there is the HMD related messages like > [3.066968] [drm:log_to_debug_console [amdgpu]] *ERROR* No EDID read. > [3.091884] [drm] SIE HMD *08: [Block 0] > [3.091886] [drm] SIE HMD *08: [Block 1] > [3.091890] [drm] dc_link_detect: manufacturer_id = D94D, product_id = > B403, > serial_number = 1010101, manufacture_week = 38, manufacture_year = > 27, display_name = SIE HMD *08, speaker_flag = 15, audio_mode_count = 4 > [3.091896] [drm] dc_link_detect: mode number = 0, format_code = 1, > channel_count = 6, sample_rate = 87, sample_size = 7 > [3.091899] [drm] dc_link_detect: mode number = 1, format_code = 2, > channel_count = 6, sample_rate = 7, sample_size = 80 > [3.091902] [drm] dc_link_detect: mode number = 2, format_code = 7, > channel_count = 6, sample_rate = 7, sample_size = 188 > [3.091905] [drm] dc_link_detect: mode number = 3, format_code = 10, > channel_count = 8, sample_rate = 4, sample_size = 0 All connected Screens then reconnect: They turn black and the position of the screens (which is left and which is right screen) is sometimes also reset. This is annoying during productive work. My point is that I don't mind if there is no EDID from the PSVR HeadSet or any of the connected devices. The headset is turned off and As I see it, it should only check for the EDID when I turn it on. The only quick solution here is to unplug the Headset while on Linux. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DPU PATCH 07/11] drm/msm/dpu: remove dt parsing logic for bus_scale config
Bus scale config related dt-bindings are removed. Add bus_scale config in driver instead. Signed-off-by: Rajesh Yadav --- drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 254 +++ 1 file changed, 167 insertions(+), 87 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c index bdf18de..24c3274 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c @@ -20,15 +20,137 @@ #include #include #include -#ifdef CONFIG_QCOM_BUS_SCALING -#include -#include -#endif #include #include "dpu_power_handle.h" #include "dpu_trace.h" +#ifdef CONFIG_QCOM_BUS_SCALING +#include +#include + +#define DPU_BUS_VECTOR_ENTRY(src_val, dst_val, ab_val, ib_val) \ + { \ + .src = src_val,\ + .dst = dst_val,\ + .ab = (ab_val),\ + .ib = (ib_val),\ + } + +static struct msm_bus_vectors dpu_reg_bus_vectors[] = { + DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_FIRST, +MSM_BUS_SLAVE_DISPLAY_CFG, 0, 0), + DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_FIRST, +MSM_BUS_SLAVE_DISPLAY_CFG, 0, 7680), + DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_FIRST, +MSM_BUS_SLAVE_DISPLAY_CFG, 0, 15000), + DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_FIRST, +MSM_BUS_SLAVE_DISPLAY_CFG, 0, 3), +}; + +static struct msm_bus_paths dpu_reg_bus_usecases[] = { { + .num_paths = 1, + .vectors = _reg_bus_vectors[0], +}, { + .num_paths = 1, + .vectors = _reg_bus_vectors[1], +}, { + .num_paths = 1, + .vectors = _reg_bus_vectors[2], +}, { + .num_paths = 1, + .vectors = _reg_bus_vectors[3], +} }; + +static struct msm_bus_scale_pdata dpu_reg_bus_scale_table = { + .usecase = dpu_reg_bus_usecases, + .num_usecases = ARRAY_SIZE(dpu_reg_bus_usecases), + .name = "mdss_reg", +}; + +static struct msm_bus_vectors dpu_data_bus_vectors[] = { + DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_MDP_PORT0, +MSM_BUS_SLAVE_MNOC_HF_MEM_NOC, 0, 0), + DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_MDP_PORT1, +MSM_BUS_SLAVE_MNOC_HF_MEM_NOC, 0, 0), + DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_MDP_PORT0, +MSM_BUS_SLAVE_MNOC_HF_MEM_NOC, 0, 64), + DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_MDP_PORT1, +MSM_BUS_SLAVE_MNOC_HF_MEM_NOC, 0, 64), + DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_MDP_PORT0, +MSM_BUS_SLAVE_MNOC_HF_MEM_NOC, 0, 64), + DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_MDP_PORT1, +MSM_BUS_SLAVE_MNOC_HF_MEM_NOC, 0, 64), +}; + +static struct msm_bus_paths dpu_data_bus_usecases[] = { { + .num_paths = 2, + .vectors = _data_bus_vectors[0], +}, { + .num_paths = 2, + .vectors = _data_bus_vectors[2], +}, { + .num_paths = 2, + .vectors = _data_bus_vectors[4], +} }; + +static struct msm_bus_scale_pdata dpu_data_bus_scale_table = { + .usecase = dpu_data_bus_usecases, + .num_usecases = ARRAY_SIZE(dpu_data_bus_usecases), + .name = "mdss_mnoc", +}; + +static struct msm_bus_vectors dpu_llcc_bus_vectors[] = { + DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_MNOC_HF_MEM_NOC, +MSM_BUS_SLAVE_LLCC, 0, 0), + DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_MNOC_HF_MEM_NOC, +MSM_BUS_SLAVE_LLCC, 0, 64), + DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_MNOC_HF_MEM_NOC, +MSM_BUS_SLAVE_LLCC, 0, 64), +}; + +static struct msm_bus_paths dpu_llcc_bus_usecases[] = { { + .num_paths = 1, + .vectors = _llcc_bus_vectors[0], +}, { + .num_paths = 1, + .vectors = _llcc_bus_vectors[1], +}, { + .num_paths = 1, + .vectors = _llcc_bus_vectors[2], +} }; +static struct msm_bus_scale_pdata dpu_llcc_bus_scale_table = { + .usecase = dpu_llcc_bus_usecases, + .num_usecases = ARRAY_SIZE(dpu_llcc_bus_usecases), + .name = "mdss_llcc", +}; + +static struct msm_bus_vectors dpu_ebi_bus_vectors[] = { + DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_LLCC, +MSM_BUS_SLAVE_EBI_CH0, 0, 0), + DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_LLCC, +MSM_BUS_SLAVE_EBI_CH0, 0, 64), + DPU_BUS_VECTOR_ENTRY(MSM_BUS_MASTER_LLCC, +
[DPU PATCH 04/11] dt-bindings: msm/disp: remove unused writeback bindings
DPU writeback support is not enabled yet so removing the bindings. The corresponding driver code is also removed. The bindings will be added back when writeback support is reworked and enabled based on new DRM writeback connector at a later stage. Signed-off-by: Rajesh Yadav --- .../devicetree/bindings/drm/msm/dpu-wb.txt | 23 -- 1 file changed, 23 deletions(-) delete mode 100644 Documentation/devicetree/bindings/drm/msm/dpu-wb.txt diff --git a/Documentation/devicetree/bindings/drm/msm/dpu-wb.txt b/Documentation/devicetree/bindings/drm/msm/dpu-wb.txt deleted file mode 100644 index 02845536..000 --- a/Documentation/devicetree/bindings/drm/msm/dpu-wb.txt +++ /dev/null @@ -1,23 +0,0 @@ -QTI Snapdragon Display Engine (DPU) writeback display - -Required properties: -- compatible: "qcom,wb-display" - -Optional properties: -- cell-index: Index of writeback device instance. - Default to 0 if not specified. -- label: String to describe this writeback display. - Default to "unknown" if not specified. - -Example: - -/ { - ... - - dpu_wb: qcom,wb-display { - compatible = "qcom,wb-display"; - cell-index = <2>; - label = "wb_display"; - }; - -}; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DPU PATCH 01/11] dt-bindings: msm/disp: remove unused dsi & panel bindings
DPU driver switched to existing upstream dsi driver so removing the dsi-staging specific dsi and panel bindings. Signed-off-by: Rajesh Yadav --- .../devicetree/bindings/drm/msm/dpu-dsi.txt| 102 --- .../devicetree/bindings/drm/msm/mdss-dsi-panel.txt | 772 - .../devicetree/bindings/fb/mdss-dsi-panel.txt | 742 Documentation/devicetree/bindings/fb/mdss-pll.txt | 103 --- 4 files changed, 1719 deletions(-) delete mode 100644 Documentation/devicetree/bindings/drm/msm/dpu-dsi.txt delete mode 100644 Documentation/devicetree/bindings/drm/msm/mdss-dsi-panel.txt delete mode 100644 Documentation/devicetree/bindings/fb/mdss-dsi-panel.txt delete mode 100644 Documentation/devicetree/bindings/fb/mdss-pll.txt diff --git a/Documentation/devicetree/bindings/drm/msm/dpu-dsi.txt b/Documentation/devicetree/bindings/drm/msm/dpu-dsi.txt deleted file mode 100644 index 641cc26..000 --- a/Documentation/devicetree/bindings/drm/msm/dpu-dsi.txt +++ /dev/null @@ -1,102 +0,0 @@ -Qualcomm Technologies, Inc. - -mdss-dsi is the master DSI device which supports multiple DSI host controllers -that are compatible with MIPI display serial interface specification. - -DSI Controller: -Required properties: -- compatible: Should be "qcom,dsi-ctrl-hw-v". Supported - versions include 1.4, 2.0 and 2.2. - eg: qcom,dsi-ctrl-hw-v1.4, qcom,dsi-ctrl-hw-v2.0, - qcom,dsi-ctrl-hw-v2.2 - And for dsi phy driver: - qcom,dsi-phy-v0.0-hpm, qcom,dsi-phy-v0.0-lpm, - qcom,dsi-phy-v1.0, qcom,dsi-phy-v2.0, - qcom,dsi-phy-v3.0 -- reg: Base address and length of DSI controller's memory - mapped regions. -- reg-names:A list of strings that name the list of regs. - "dsi_ctrl" - DSI controller memory region. - "mmss_misc" - MMSS misc memory region. -- cell-index: Specifies the controller instance. -- clocks: Clocks required for DSI controller operation. -- clock-names: Names of the clocks corresponding to handles. Following - clocks are required: - "mdp_core_clk" - "iface_clk" - "core_mmss_clk" - "bus_clk" - "byte_clk" - "pixel_clk" - "core_clk" - "byte_clk_rcg" - "pixel_clk_rcg" -- gdsc-supply: phandle to gdsc regulator node. -- vdda-supply: phandle to vdda regulator node. -- vcca-supply: phandle to vcca regulator node. -- interrupt-parent phandle to the interrupt parent device node. -- interrupts: The interrupt signal from the DSI block. - -Bus Scaling Data: -- qcom,msm-bus,name: String property describing MDSS client. -- qcom,msm-bus,num-cases: This is the number of bus scaling use cases - defined in the vectors property. This must be - set to <2> for MDSS DSI driver where use-case 0 - is used to remove BW votes from the system. Use - case 1 is used to generate bandwidth requestes - when sending command packets. -- qcom,msm-bus,num-paths: This represents number of paths in each bus - scaling usecase. This value depends on number of - AXI master ports dedicated to MDSS for - particular chipset. -- qcom,msm-bus,vectors-KBps: A series of 4 cell properties, with a format - of (src, dst, ab, ib) which is defined at - Documentation/devicetree/bindings/arm/msm/msm_bus.txt. - DSI driver should always set average bandwidth - (ab) to 0 and always use instantaneous - bandwidth(ib) values. - -Optional properties: -- label: String to describe controller. -- qcom,platform-te-gpio: Specifies the gpio used for TE. -- qcom,dsi-display-active: Current active display -- qcom,dsi-ctrl: handle to dsi controller device -- qcom,dsi-phy: handle to dsi phy device -- qcom,dsi-manager: Specifies dsi manager is present -- qcom,dsi-display: Specifies dsi display is present -- qcom,hdmi-display: Specifies hdmi is present -- qcom,dp-display:Specified dp is present -- qcom,-supply-entries: A node that lists the elements of the supply used by the - a particular "type" of DSI module. The module "types" - can be "core", "ctrl", and "phy". Within the same type, -
[DPU PATCH 02/11] dt-bindings: msm/disp: remove unused display port bindings
DPU display port driver is not enabled yet so removing the bindings. The driver code is also reverted. The bindings will be added back when display port driver is reworked and enabled for sdm845. Signed-off-by: Rajesh Yadav --- .../devicetree/bindings/drm/msm/dpu-dp.txt | 217 - 1 file changed, 217 deletions(-) delete mode 100644 Documentation/devicetree/bindings/drm/msm/dpu-dp.txt diff --git a/Documentation/devicetree/bindings/drm/msm/dpu-dp.txt b/Documentation/devicetree/bindings/drm/msm/dpu-dp.txt deleted file mode 100644 index 1ed2715..000 --- a/Documentation/devicetree/bindings/drm/msm/dpu-dp.txt +++ /dev/null @@ -1,217 +0,0 @@ -Qualcomm Technologies, Inc. -dpu-dp is the master Display Port device which supports DP host controllers that are compatible with VESA Display Port interface specification. -DP Controller: Required properties: -- compatible: Should be "qcom,dp-display". -- reg: Base address and length of DP hardware's memory mapped regions. -- reg-names:A list of strings that name the list of regs. "dp_ctrl" - DP controller memory region. - "dp_phy" - DP PHY memory region. - "dp_ln_tx0" - USB3 DP PHY combo TX-0 lane memory region. - "dp_ln_tx1" - USB3 DP PHY combo TX-1 lane memory region. - "dp_mmss_cc" - Display Clock Control memory region. - "qfprom_physical" - QFPROM Phys memory region. - "dp_pll" - USB3 DP combo PLL memory region. - "usb3_dp_com" - USB3 DP PHY combo memory region. - "hdcp_physical" - DP HDCP memory region. -- cell-index: Specifies the controller instance. -- clocks: Clocks required for Display Port operation. -- clock-names: Names of the clocks corresponding to handles. Following clocks are required: - "core_aux_clk", "core_usb_ref_clk_src","core_usb_ref_clk", "core_usb_cfg_ahb_clk", - "core_usb_pipe_clk", "ctrl_link_clk", "ctrl_link_iface_clk", "ctrl_crypto_clk", - "ctrl_pixel_clk", "pixel_clk_rcg", "pixel_parent". -- gdsc-supply: phandle to gdsc regulator node. -- vdda-1p2-supply: phandle to vdda 1.2V regulator node. -- vdda-0p9-supply: phandle to vdda 0.9V regulator node. -- interrupt-parent phandle to the interrupt parent device node. -- interrupts: The interrupt signal from the DSI block. -- qcom,aux-en-gpio:Specifies the aux-channel enable gpio. -- qcom,aux-sel-gpio: Specifies the aux-channel select gpio. -- qcom,usbplug-cc-gpio:Specifies the usbplug orientation gpio. -- qcom,aux-cfg0-settings: Specifies the DP AUX configuration 0 settings. The first - entry in this array corresponds to the register offset - within DP AUX, while the remaining entries indicate the - programmable values. -- qcom,aux-cfg1-settings: Specifies the DP AUX configuration 1 settings. The first - entry in this array corresponds to the register offset - within DP AUX, while the remaining entries indicate the - programmable values. -- qcom,aux-cfg2-settings: Specifies the DP AUX configuration 2 settings. The first - entry in this array corresponds to the register offset - within DP AUX, while the remaining entries indicate the - programmable values. -- qcom,aux-cfg3-settings: Specifies the DP AUX configuration 3 settings. The first - entry in this array corresponds to the register offset - within DP AUX, while the remaining entries indicate the - programmable values. -- qcom,aux-cfg4-settings: Specifies the DP AUX configuration 4 settings. The first - entry in this array corresponds to the register offset - within DP AUX, while the remaining entries indicate the - programmable values. -- qcom,aux-cfg5-settings: Specifies the DP AUX configuration 5 settings. The first - entry in this array corresponds to the register offset - within DP AUX, while the remaining entries indicate the - programmable values. -- qcom,aux-cfg6-settings: Specifies the DP AUX configuration 6 settings.
[DPU PATCH 00/11] Remove unused code and cleanup devicetree bindings for DPU driver
This patch series aims at removing unused code from DPU driver and also cleaning up its devicetree bindings. Following functionality is removed in this series: - Removed display port driver, it will be posted back later after verification on SDM845 - Removed HDCP 1.x support, it will be posted back with display port driver - Removed writeback support, it will be added at later stage based on DRM writeback connector series Additionally, following cleanups are done: - Remove bus_scale config from devicetree and use static config in driver - Cleanup devicetree binding to model actual (tree like) HW hierarchy - Cleanup unused utility functions This series is rebased on following: 1. https://lists.freedesktop.org/archives/freedreno/2018-May/002502.html 2. https://lists.freedesktop.org/archives/freedreno/2018-May/002565.html Jordan Crouse (1): drm/msm/dpu: Remove unused code and move the header Rajesh Yadav (10): dt-bindings: msm/disp: remove unused dsi & panel bindings dt-bindings: msm/disp: remove unused display port bindings Revert "drm/msm: Add DisplayPort support" dt-bindings: msm/disp: remove unused writeback bindings drm/msm/dpu: remove writeback support drm/msm/dpu: remove hdcp support drm/msm/dpu: remove dt parsing logic for bus_scale config dt-bindings: msm/disp: cleanup bindings for Snapdragon 845 DPU drm/msm/dpu: correct dpu_io_util.h include path drm/msm/dpu: move dpu_io_util to dpu folder .../devicetree/bindings/display/msm/dpu.txt| 318 ++-- .../devicetree/bindings/drm/msm/dpu-dp.txt | 217 --- .../devicetree/bindings/drm/msm/dpu-dsi.txt| 102 -- .../devicetree/bindings/drm/msm/dpu-wb.txt | 23 - .../devicetree/bindings/drm/msm/mdss-dsi-panel.txt | 772 -- .../devicetree/bindings/fb/mdss-dsi-panel.txt | 742 - Documentation/devicetree/bindings/fb/mdss-pll.txt | 103 -- drivers/gpu/drm/msm/Makefile | 21 +- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h |3 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 94 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|2 - drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 63 - .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c| 1349 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 41 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 77 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c |3 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 19 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h |6 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c | 12 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h |4 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 321 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h | 186 --- drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c| 186 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.h| 61 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|5 - drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h|1 - drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c |2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 253 ++-- drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h |2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 42 +- drivers/gpu/drm/msm/disp/dpu1/dpu_wb.c | 767 -- drivers/gpu/drm/msm/disp/dpu1/dpu_wb.h | 232 --- drivers/gpu/drm/msm/dp/dp_audio.c | 806 -- drivers/gpu/drm/msm/dp/dp_audio.h | 81 - drivers/gpu/drm/msm/dp/dp_aux.c| 570 --- drivers/gpu/drm/msm/dp/dp_aux.h| 44 - drivers/gpu/drm/msm/dp/dp_catalog.c| 1320 drivers/gpu/drm/msm/dp/dp_catalog.h| 163 -- drivers/gpu/drm/msm/dp/dp_ctrl.c | 1474 -- drivers/gpu/drm/msm/dp/dp_ctrl.h | 50 - drivers/gpu/drm/msm/dp/dp_debug.c | 503 --- drivers/gpu/drm/msm/dp/dp_debug.h | 60 - drivers/gpu/drm/msm/dp/dp_display.c| 1255 drivers/gpu/drm/msm/dp/dp_display.h| 52 - drivers/gpu/drm/msm/dp/dp_drm.c| 538 --- drivers/gpu/drm/msm/dp/dp_drm.h| 96 -- drivers/gpu/drm/msm/dp/dp_hdcp2p2.c| 927 drivers/gpu/drm/msm/dp/dp_link.c | 1548 --- drivers/gpu/drm/msm/dp/dp_link.h | 184 --- drivers/gpu/drm/msm/dp/dp_panel.c | 526 --- drivers/gpu/drm/msm/dp/dp_panel.h | 115 -- drivers/gpu/drm/msm/dp/dp_parser.c | 645 drivers/gpu/drm/msm/dp/dp_parser.h | 200 --- drivers/gpu/drm/msm/dp/dp_power.c | 593 drivers/gpu/drm/msm/dp/dp_power.h
Re: [PATCH v2 0/2] drm/blend: Add per-plane pixel blend mode property
On Wed, May 30, 2018 at 07:23:52PM +0800, Lowry Li wrote: > Hi, > > This serie aims at adding the support for pixel blend modes represent the > alpha blending equation selection in the driver. It also introduces to use > it in the malidp driver. > > Let me know what you think, Hi Lowry, Thank you for doing this work. I know this is something that is missing for proper Android support, so it's most welcome. Do you have userspace patches using this property? Sean > Lowry > > Changes for v2: > - Moves the blending equation into the DOC comment > - Refines the comments of drm_plane_create_blend_mode_property to not >enumerate the #defines, but instead the string values > - Uses fg.* instead of pixel.* and plane_alpha instead of plane.alpha > - Introduces to use it in the malidp driver, which depends on the plane >alpha patch > > Changes from v1: > - v1 is just the core changes to request for commments > - Adds a pixel_blend_mode to drm_plane_state and a blend_mode_property to >drm_plane, and related support functions > - Defines three blend modes in drm_blend.h > - Rebased on current drm-next > > Lowry Li (2): > drm/blend: Add per-plane pixel blend mode property > drm/mali-dp: Implement plane alpha and pixel blend on malidp > > drivers/gpu/drm/arm/malidp_planes.c | 76 ++--- > drivers/gpu/drm/drm_atomic.c| 4 ++ > drivers/gpu/drm/drm_atomic_helper.c | 1 + > drivers/gpu/drm/drm_blend.c | 110 > > include/drm/drm_blend.h | 6 ++ > include/drm/drm_plane.h | 6 ++ > 6 files changed, 171 insertions(+), 32 deletions(-) > > -- > 1.9.1 > -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 09/10] ARM: dts: exynos5250: add DSI node
On Wed, May 30, 2018 at 2:16 PM, Maciej Purski wrote: > From: Andrzej Hajda > > The patch adds common part of DSI node for Exynos5250 platforms > and a required mipi-phy node. > > Signed-off-by: Andrzej Hajda > Signed-off-by: Maciej Purski > --- > arch/arm/boot/dts/exynos5250.dtsi | 21 + > 1 file changed, 21 insertions(+) Thanks for changes. I'll take both DTS patches after bindings get accepted and after upcomming merge window. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 87738] [OpenCL] Please add Image support
https://bugs.freedesktop.org/show_bug.cgi?id=87738 Jan Vesely changed: What|Removed |Added Blocks||82717 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=82717 [Bug 82717] OpenCL support for mandelbulber-opencl -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 82717] OpenCL support for mandelbulber-opencl
https://bugs.freedesktop.org/show_bug.cgi?id=82717 Jan Vesely changed: What|Removed |Added Depends on||87738 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=87738 [Bug 87738] [OpenCL] Please add Image support -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] ARM: dma-mapping: Implement arm_dma_iommu_detach_device()
On Wed, May 30, 2018 at 02:42:50PM +0100, Robin Murphy wrote: > On 30/05/18 14:12, Thierry Reding wrote: > > On Wed, May 30, 2018 at 02:54:46PM +0200, Thierry Reding wrote: > > > On Wed, May 30, 2018 at 10:59:30AM +0100, Robin Murphy wrote: > > > > On 30/05/18 09:03, Thierry Reding wrote: > > > > > From: Thierry Reding > > > > > > > > > > Implement this function to enable drivers from detaching from any > > > > > IOMMU > > > > > domains that architecture code might have attached them to so that > > > > > they > > > > > can take exclusive control of the IOMMU via the IOMMU API. > > > > > > > > > > Signed-off-by: Thierry Reding > > > > > --- > > > > > Changes in v3: > > > > > - make API 32-bit ARM specific > > > > > - avoid extra local variable > > > > > > > > > > Changes in v2: > > > > > - fix compilation > > > > > > > > > >arch/arm/include/asm/dma-mapping.h | 3 +++ > > > > >arch/arm/mm/dma-mapping-nommu.c| 4 > > > > >arch/arm/mm/dma-mapping.c | 16 > > > > >3 files changed, 23 insertions(+) > > > > > > > > > > diff --git a/arch/arm/include/asm/dma-mapping.h > > > > > b/arch/arm/include/asm/dma-mapping.h > > > > > index 8436f6ade57d..5960e9f3a9d0 100644 > > > > > --- a/arch/arm/include/asm/dma-mapping.h > > > > > +++ b/arch/arm/include/asm/dma-mapping.h > > > > > @@ -103,6 +103,9 @@ extern void arch_setup_dma_ops(struct device > > > > > *dev, u64 dma_base, u64 size, > > > > >#define arch_teardown_dma_ops arch_teardown_dma_ops > > > > >extern void arch_teardown_dma_ops(struct device *dev); > > > > > +#define arm_dma_iommu_detach_device arm_dma_iommu_detach_device > > > > > +extern void arm_dma_iommu_detach_device(struct device *dev); > > > > > + > > > > >/* do not use this function in a driver */ > > > > >static inline bool is_device_dma_coherent(struct device *dev) > > > > >{ > > > > > diff --git a/arch/arm/mm/dma-mapping-nommu.c > > > > > b/arch/arm/mm/dma-mapping-nommu.c > > > > > index f448a0663b10..eb781369377b 100644 > > > > > --- a/arch/arm/mm/dma-mapping-nommu.c > > > > > +++ b/arch/arm/mm/dma-mapping-nommu.c > > > > > @@ -241,3 +241,7 @@ void arch_setup_dma_ops(struct device *dev, u64 > > > > > dma_base, u64 size, > > > > >void arch_teardown_dma_ops(struct device *dev) > > > > >{ > > > > >} > > > > > + > > > > > +void arm_dma_iommu_detach_device(struct device *dev) > > > > > +{ > > > > > +} > > > > > diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c > > > > > index af27f1c22d93..6d8af08b3e7d 100644 > > > > > --- a/arch/arm/mm/dma-mapping.c > > > > > +++ b/arch/arm/mm/dma-mapping.c > > > > > @@ -2400,3 +2400,19 @@ void arch_teardown_dma_ops(struct device *dev) > > > > > arm_teardown_iommu_dma_ops(dev); > > > > >} > > > > > + > > > > > +void arm_dma_iommu_detach_device(struct device *dev) > > > > > +{ > > > > > +#ifdef CONFIG_ARM_DMA_USE_IOMMU > > > > > + struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev); > > > > > + > > > > > + if (!mapping) > > > > > + return; > > > > > + > > > > > + arm_iommu_release_mapping(mapping); > > > > > > > > Potentially freeing the mapping before you try to operate on it is > > > > never the > > > > best idea. Plus arm_iommu_detach_device() already releases a reference > > > > appropriately anyway, so it's a double-free. > > > > > > But the reference released by arm_iommu_detach_device() is to balance > > > out the reference acquired by arm_iommu_attach_device(), isn't it? In > > > the above, the arm_iommu_release_mapping() is supposed to drop the > > > final reference which was obtained by arm_iommu_create_mapping(). The > > > mapping shouldn't go away irrespective of the order in which these > > > will be called. > > > > Going over the DMA/IOMMU code I just remembered that I drew inspiration > > from arm_teardown_iommu_dma_ops() for the initial proposal which also > > calls both arm_iommu_detach_device() and arm_iommu_release_mapping(). > > That said, one other possibility to implement this would be to export > > the 32-bit and 64-bit ARM implementations of arch_teardown_dma_ops() > > and use that instead. linux/dma-mapping.h implements a stub for > > architectures that don't provide one, so it should work without any > > #ifdef guards. > > > > That combined with the set_dma_ops() fix in arm_iommu_detach_device() > > should fix this pretty nicely. > > OK, having a second look at the ARM code I see I had indeed overlooked that > extra reference held until arm_teardown_iommu_dma_ops() - mea culpa - but > frankly that looks wrong anyway, as it basically defeats the point of > refcounting the mapping at all. AFAICS arm_setup_iommu_dma_ops() should just > be made to behave 'normally' by unconditionally dropping the initial > reference after calling __arm_iommu_attach_device(), then we don't need all > these odd and confusing release calls dotted around at all. Good point. I can follow up with a series to fix
[PATCH v4 2/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping
From: Thierry Reding Depending on the kernel configuration, early ARM architecture setup code may have attached the GPU to a DMA/IOMMU mapping that transparently uses the IOMMU to back the DMA API. Tegra requires special handling for IOMMU backed buffers (a special bit in the GPU's MMU page tables indicates the memory path to take: via the SMMU or directly to the memory controller). Transparently backing DMA memory with an IOMMU prevents Nouveau from properly handling such memory accesses and causes memory access faults. As a side-note: buffers other than those allocated in instance memory don't need to be physically contiguous from the GPU's perspective since the GPU can map them into contiguous buffers using its own MMU. Mapping these buffers through the IOMMU is unnecessary and will even lead to performance degradation because of the additional translation. One exception to this are compressible buffers which need large pages. In order to enable these large pages, multiple small pages will have to be combined into one large (I/O virtually contiguous) mapping via the IOMMU. However, that is a topic outside the scope of this fix and isn't currently supported. An implementation will want to explicitly create these large pages in the Nouveau driver, so detaching from a DMA/IOMMU mapping would still be required. Signed-off-by: Thierry Reding --- Changes in v4: - use existing APIs to detach from a DMA/IOMMU mapping Changes in v3: - clarify the use of IOMMU mapping for compressible buffers - squash multiple patches into this drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c index 78597da6313a..0e372a190d3f 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c @@ -23,6 +23,10 @@ #ifdef CONFIG_NOUVEAU_PLATFORM_DRIVER #include "priv.h" +#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU) +#include +#endif + static int nvkm_device_tegra_power_up(struct nvkm_device_tegra *tdev) { @@ -105,6 +109,15 @@ nvkm_device_tegra_probe_iommu(struct nvkm_device_tegra *tdev) unsigned long pgsize_bitmap; int ret; +#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU) + if (dev->archdata.mapping) { + struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev); + + arm_iommu_detach_device(dev); + arm_iommu_release_mapping(mapping); + } +#endif + if (!tdev->func->iommu_bit) return; -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/2] ARM: dma-mapping: Set proper DMA ops in arm_iommu_detach_device()
From: Thierry Reding Instead of setting the DMA ops pointer to NULL, set the correct, non-IOMMU ops depending on the device's coherency setting. Signed-off-by: Thierry Reding --- Changes in v4: - new patch to fix existing arm_iommu_detach_device() to do what we need arch/arm/mm/dma-mapping.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c index af27f1c22d93..87a0037574e4 100644 --- a/arch/arm/mm/dma-mapping.c +++ b/arch/arm/mm/dma-mapping.c @@ -1151,6 +1151,11 @@ int arm_dma_supported(struct device *dev, u64 mask) return __dma_supported(dev, mask, false); } +static const struct dma_map_ops *arm_get_dma_map_ops(bool coherent) +{ + return coherent ? _coherent_dma_ops : _dma_ops; +} + #ifdef CONFIG_ARM_DMA_USE_IOMMU static int __dma_info_to_prot(enum dma_data_direction dir, unsigned long attrs) @@ -2296,7 +2301,7 @@ void arm_iommu_detach_device(struct device *dev) iommu_detach_device(mapping->domain, dev); kref_put(>kref, release_iommu_mapping); to_dma_iommu_mapping(dev) = NULL; - set_dma_ops(dev, NULL); + set_dma_ops(dev, arm_get_dma_map_ops(dev->archdata.dma_coherent)); pr_debug("Detached IOMMU controller from %s device.\n", dev_name(dev)); } @@ -2357,11 +2362,6 @@ static void arm_teardown_iommu_dma_ops(struct device *dev) { } #endif /* CONFIG_ARM_DMA_USE_IOMMU */ -static const struct dma_map_ops *arm_get_dma_map_ops(bool coherent) -{ - return coherent ? _coherent_dma_ops : _dma_ops; -} - void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size, const struct iommu_ops *iommu, bool coherent) { -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping
From: Thierry Reding An unfortunate interaction between the 32-bit ARM DMA/IOMMU mapping code and Tegra SMMU driver changes to support IOMMU groups introduced a boot- time regression on Tegra124. This was caught very late because none of the standard configurations that are tested on Tegra enable the ARM DMA/ IOMMU mapping code since it is not needed. The reason for the failure is that the GPU found on Tegra uses a special bit in physical addresses to determine whether or not a buffer is mapped through the SMMU. In order to achieve this, the Nouveau driver needs to explicitly understand which buffers are mapped through the SMMU and which aren't. Hiding usage of the SMMU behind the DMA API is bound to fail because the knowledge doesn't exist. Furthermore, the GPU has its own IOMMU and in most cases doesn't need buffers to be physically or virtually contiguous. One notable exception is for compressible buffers which need to be mapped with large pages, which in turn require all the small pages in a large page to be contiguous. This can be achieved with an SMMU mapping, though it isn't currently supported in Nouveau. Since Translating through the SMMU is unnecessary and can have a negative impact on performance for the common case, so we want to avoid it when possible. This series of patches adds a 32-bit ARM specific API that allows a driver to detach the device from the DMA/IOMMU mapping so that it can provide its own implementation for dealing with the SMMU. The second patch makes use of that new API in the Nouveau driver to fix the regression. Thierry Thierry Reding (2): ARM: dma-mapping: Set proper DMA ops in arm_iommu_detach_device() drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping arch/arm/mm/dma-mapping.c | 12 ++-- drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 13 + 2 files changed, 19 insertions(+), 6 deletions(-) -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/edid: Quirk Vive Pro VR headset non-desktop.
On Wed, 30 May 2018, Daniel Stone wrote: > On 29 May 2018 at 12:52, Lubosz Sarnecki > wrote: >> This adds the Vive Pro's EDID information and >> sets EDID_QUIRK_NON_DESKTOP. > > Trivially: > Reviewed-by: Daniel Stone Cc: sta...@vger.kernel.org # v4.when-was-this-feature-added? BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 93370] [clover/caicos] OpenCL atomic_cmpxchg() segmentation fault
https://bugs.freedesktop.org/show_bug.cgi?id=93370 Jan Vesely changed: What|Removed |Added Summary|[r600g] OpenCL |[clover/caicos] OpenCL |atomic_cmpxchg()|atomic_cmpxchg() |segmentation fault on |segmentation fault |Caicos | --- Comment #1 from Jan Vesely --- The backtrace does not look compilation related. However, atomic ops that return the old value are not supported atm. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] ARM: dma-mapping: Implement arm_dma_iommu_detach_device()
On 30/05/18 14:12, Thierry Reding wrote: On Wed, May 30, 2018 at 02:54:46PM +0200, Thierry Reding wrote: On Wed, May 30, 2018 at 10:59:30AM +0100, Robin Murphy wrote: On 30/05/18 09:03, Thierry Reding wrote: From: Thierry Reding Implement this function to enable drivers from detaching from any IOMMU domains that architecture code might have attached them to so that they can take exclusive control of the IOMMU via the IOMMU API. Signed-off-by: Thierry Reding --- Changes in v3: - make API 32-bit ARM specific - avoid extra local variable Changes in v2: - fix compilation arch/arm/include/asm/dma-mapping.h | 3 +++ arch/arm/mm/dma-mapping-nommu.c| 4 arch/arm/mm/dma-mapping.c | 16 3 files changed, 23 insertions(+) diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h index 8436f6ade57d..5960e9f3a9d0 100644 --- a/arch/arm/include/asm/dma-mapping.h +++ b/arch/arm/include/asm/dma-mapping.h @@ -103,6 +103,9 @@ extern void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size, #define arch_teardown_dma_ops arch_teardown_dma_ops extern void arch_teardown_dma_ops(struct device *dev); +#define arm_dma_iommu_detach_device arm_dma_iommu_detach_device +extern void arm_dma_iommu_detach_device(struct device *dev); + /* do not use this function in a driver */ static inline bool is_device_dma_coherent(struct device *dev) { diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c index f448a0663b10..eb781369377b 100644 --- a/arch/arm/mm/dma-mapping-nommu.c +++ b/arch/arm/mm/dma-mapping-nommu.c @@ -241,3 +241,7 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size, void arch_teardown_dma_ops(struct device *dev) { } + +void arm_dma_iommu_detach_device(struct device *dev) +{ +} diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c index af27f1c22d93..6d8af08b3e7d 100644 --- a/arch/arm/mm/dma-mapping.c +++ b/arch/arm/mm/dma-mapping.c @@ -2400,3 +2400,19 @@ void arch_teardown_dma_ops(struct device *dev) arm_teardown_iommu_dma_ops(dev); } + +void arm_dma_iommu_detach_device(struct device *dev) +{ +#ifdef CONFIG_ARM_DMA_USE_IOMMU + struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev); + + if (!mapping) + return; + + arm_iommu_release_mapping(mapping); Potentially freeing the mapping before you try to operate on it is never the best idea. Plus arm_iommu_detach_device() already releases a reference appropriately anyway, so it's a double-free. But the reference released by arm_iommu_detach_device() is to balance out the reference acquired by arm_iommu_attach_device(), isn't it? In the above, the arm_iommu_release_mapping() is supposed to drop the final reference which was obtained by arm_iommu_create_mapping(). The mapping shouldn't go away irrespective of the order in which these will be called. Going over the DMA/IOMMU code I just remembered that I drew inspiration from arm_teardown_iommu_dma_ops() for the initial proposal which also calls both arm_iommu_detach_device() and arm_iommu_release_mapping(). That said, one other possibility to implement this would be to export the 32-bit and 64-bit ARM implementations of arch_teardown_dma_ops() and use that instead. linux/dma-mapping.h implements a stub for architectures that don't provide one, so it should work without any #ifdef guards. That combined with the set_dma_ops() fix in arm_iommu_detach_device() should fix this pretty nicely. OK, having a second look at the ARM code I see I had indeed overlooked that extra reference held until arm_teardown_iommu_dma_ops() - mea culpa - but frankly that looks wrong anyway, as it basically defeats the point of refcounting the mapping at all. AFAICS arm_setup_iommu_dma_ops() should just be made to behave 'normally' by unconditionally dropping the initial reference after calling __arm_iommu_attach_device(), then we don't need all these odd and confusing release calls dotted around at all. Robin. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106718] On Ubuntu Bionic with kernels 4.15 and above, RX480 Displayport outputs don't work (dmesg reports "not connected")
https://bugs.freedesktop.org/show_bug.cgi?id=106718 --- Comment #3 from Alex Deucher --- Can you narrow down the regression or better yet bisect? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping
On Wed, May 30, 2018 at 02:30:51PM +0100, Robin Murphy wrote: > On 30/05/18 14:00, Thierry Reding wrote: > > On Wed, May 30, 2018 at 11:30:25AM +0100, Robin Murphy wrote: > > > On 30/05/18 09:03, Thierry Reding wrote: > > > > From: Thierry Reding > > > > > > > > Depending on the kernel configuration, early ARM architecture setup code > > > > may have attached the GPU to a DMA/IOMMU mapping that transparently uses > > > > the IOMMU to back the DMA API. Tegra requires special handling for IOMMU > > > > backed buffers (a special bit in the GPU's MMU page tables indicates the > > > > memory path to take: via the SMMU or directly to the memory controller). > > > > Transparently backing DMA memory with an IOMMU prevents Nouveau from > > > > properly handling such memory accesses and causes memory access faults. > > > > > > > > As a side-note: buffers other than those allocated in instance memory > > > > don't need to be physically contiguous from the GPU's perspective since > > > > the GPU can map them into contiguous buffers using its own MMU. Mapping > > > > these buffers through the IOMMU is unnecessary and will even lead to > > > > performance degradation because of the additional translation. One > > > > exception to this are compressible buffers which need large pages. In > > > > order to enable these large pages, multiple small pages will have to be > > > > combined into one large (I/O virtually contiguous) mapping via the > > > > IOMMU. However, that is a topic outside the scope of this fix and isn't > > > > currently supported. An implementation will want to explicitly create > > > > these large pages in the Nouveau driver, so detaching from a DMA/IOMMU > > > > mapping would still be required. > > > > > > I wonder if it might make sense to have a hook in iommu_attach_device() to > > > notify the arch DMA API code when moving devices between unmanaged and DMA > > > ops domains? That seems like it might be the most low-impact way to > > > address > > > the overall problem long-term. > > > > > > > Signed-off-by: Thierry Reding > > > > --- > > > > Changes in v3: > > > > - clarify the use of IOMMU mapping for compressible buffers > > > > - squash multiple patches into this > > > > > > > >drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 5 + > > > >1 file changed, 5 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c > > > > b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c > > > > index 78597da6313a..d0538af1b967 100644 > > > > --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c > > > > +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c > > > > @@ -105,6 +105,11 @@ nvkm_device_tegra_probe_iommu(struct > > > > nvkm_device_tegra *tdev) > > > > unsigned long pgsize_bitmap; > > > > int ret; > > > > +#if IS_ENABLED(CONFIG_ARM) > > > > > > Wouldn't CONFIG_ARM_DMA_USE_IOMMU be even more appropriate? > > > > Not necessarily. arm_dma_iommu_detach_device() is always defined on ARM, > > only with CONFIG_ARM_DMA_USE_IOMMU=n it will be empty. So this check is > > a guard to make sure we don't call the function when it isn't available, > > but it may still not do anything. > > Calling a function under condition A, which only does anything under > condition B, when B depends on A, is identical in behaviour to only calling > the function under condition B, except needlessly harder to follow. > > > > > + /* make sure we can use the IOMMU exclusively */ > > > > + arm_dma_iommu_detach_device(dev); > > > > > > As before, I would just use the existing infrastructure the same way the > > > Exynos DRM driver currently does in __exynos_iommu_attach() (albeit > > > without > > > then reattaching to another DMA ops mapping). > > > > That's pretty much what I initially did and which was shot down by > > Christoph. As I said earlier, at this point I don't really care what > > color the shed will be. Can you and Christoph come to an agreement > > on what it should be? > > What I was getting at is that arm_iommu_detach_device() already *is* the > exact function Christoph was asking for, it just needs a minor fix instead > of adding explicit set_dma_ops() fiddling at its callsites which only > obfuscates the fact that it's supposed to be responsible for resetting the > device's DMA ops already. It still has the downside of callers having to explicitly check for the existence of a mapping, otherwise they'll cause a warning to be printed to the kernel log. That's not all that bad, though. I'll prepare version 4 with those changes. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [DPU PATCH] drm/msm: make pclk_rate u64 to avoid truncation
Hi Abhinav, Thank you for the patch! Yet something to improve: [auto build test ERROR on robclark/msm-next] [also build test ERROR on v4.17-rc7 next-20180529] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Abhinav-Kumar/drm-msm-make-pclk_rate-u64-to-avoid-truncation/20180530-182643 base: git://people.freedesktop.org/~robclark/linux msm-next config: arm-multi_v7_defconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): drivers/gpu/drm/msm/dsi/dsi_host.o: In function `msm_dsi_host_get_phy_clk_req': >> dsi_host.c:(.text+0x2628): undefined reference to `__aeabi_uldivmod' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DPU PATCH 11/11] drm/msm/dpu: move dpu_io_util to dpu folder
dpu_io_util is used only by dpu driver so move it to dpu folder. Signed-off-by: Rajesh Yadav --- drivers/gpu/drm/msm/Makefile| 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c | 186 drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.h | 61 + drivers/gpu/drm/msm/dpu_io_util.c | 186 drivers/gpu/drm/msm/dpu_io_util.h | 61 - 5 files changed, 248 insertions(+), 248 deletions(-) create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.h delete mode 100644 drivers/gpu/drm/msm/dpu_io_util.c delete mode 100644 drivers/gpu/drm/msm/dpu_io_util.h diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile index f4c5951..956c6c4 100644 --- a/drivers/gpu/drm/msm/Makefile +++ b/drivers/gpu/drm/msm/Makefile @@ -68,6 +68,7 @@ msm-y := \ disp/dpu1/dpu_hw_top.o \ disp/dpu1/dpu_hw_util.o \ disp/dpu1/dpu_hw_vbif.o \ + disp/dpu1/dpu_io_util.o \ disp/dpu1/dpu_irq.o \ disp/dpu1/dpu_kms.o \ disp/dpu1/dpu_kms_utils.o \ @@ -77,7 +78,6 @@ msm-y := \ disp/dpu1/dpu_mdss.o \ disp/dpu1/dpu_power_handle.o \ dpu_dbg.o \ - dpu_io_util.o \ dpu_dbg_evtlog.o \ msm_atomic.o \ msm_debugfs.o \ diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c new file mode 100644 index 000..f7caec3 --- /dev/null +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_io_util.c @@ -0,0 +1,186 @@ +/* Copyright (c) 2012-2015, 2017-2018, The Linux Foundation. + * All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 and + * only version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include +#include + +#include "dpu_io_util.h" + +void msm_dss_put_clk(struct dss_clk *clk_arry, int num_clk) +{ + int i; + + for (i = num_clk - 1; i >= 0; i--) { + if (clk_arry[i].clk) + clk_put(clk_arry[i].clk); + clk_arry[i].clk = NULL; + } +} + +int msm_dss_get_clk(struct device *dev, struct dss_clk *clk_arry, int num_clk) +{ + int i, rc = 0; + + for (i = 0; i < num_clk; i++) { + clk_arry[i].clk = clk_get(dev, clk_arry[i].clk_name); + rc = PTR_RET(clk_arry[i].clk); + if (rc) { + DEV_ERR("%pS->%s: '%s' get failed. rc=%d\n", + __builtin_return_address(0), __func__, + clk_arry[i].clk_name, rc); + goto error; + } + } + + return rc; + +error: + for (i--; i >= 0; i--) { + if (clk_arry[i].clk) + clk_put(clk_arry[i].clk); + clk_arry[i].clk = NULL; + } + + return rc; +} + +int msm_dss_clk_set_rate(struct dss_clk *clk_arry, int num_clk) +{ + int i, rc = 0; + + for (i = 0; i < num_clk; i++) { + if (clk_arry[i].clk) { + if (clk_arry[i].type != DSS_CLK_AHB) { + DEV_DBG("%pS->%s: '%s' rate %ld\n", + __builtin_return_address(0), __func__, + clk_arry[i].clk_name, + clk_arry[i].rate); + rc = clk_set_rate(clk_arry[i].clk, + clk_arry[i].rate); + if (rc) { + DEV_ERR("%pS->%s: %s failed. rc=%d\n", + __builtin_return_address(0), + __func__, + clk_arry[i].clk_name, rc); + break; + } + } + } else { + DEV_ERR("%pS->%s: '%s' is not available\n", + __builtin_return_address(0), __func__, + clk_arry[i].clk_name); + rc = -EPERM; + break; + } + } + + return rc; +} + +int msm_dss_enable_clk(struct dss_clk *clk_arry, int num_clk, int enable) +{ + int i, rc = 0; + + if (enable) { + for (i = 0; i < num_clk; i++) { + DEV_DBG("%pS->%s: enable '%s'\n", + __builtin_return_address(0), __func__, +
[DPU PATCH 10/11] drm/msm/dpu: correct dpu_io_util.h include path
dpu_io_util.h is moved from standard include path to driver folder, correct the include path in code. Signed-off-by: Rajesh Yadav --- drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c index 24c3274..f997bd9 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c @@ -20,7 +20,6 @@ #include #include #include -#include #include "dpu_power_handle.h" #include "dpu_trace.h" diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h index 9a6d4b9..193f468 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h @@ -21,7 +21,7 @@ #define DPU_POWER_HANDLE_ENABLE_BUS_IB_QUOTA 16 #define DPU_POWER_HANDLE_DISABLE_BUS_IB_QUOTA 0 -#include +#include "dpu_io_util.h" /* event will be triggered before power handler disable */ #define DPU_POWER_EVENT_PRE_DISABLE0x1 -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DPU PATCH 08/11] dt-bindings: msm/disp: cleanup bindings for Snapdragon 845 DPU
SDM845 SoC has a MDSS top level wrapper which includes sub-blocks as dpu, dsi, dp, hdmi etc. But current DPU bindings are defined as if there is flat device hierarchy. The MDSS and DPU HW blocks were represented by single device and DSI, HDMI, DP etc. blocks are represented as separate independent devices. This change updates the binding as tree like hierarchy where MDSS is parent device and DPU, DSI, DP and HDMI are child devices to correctly model the HW associations. Signed-off-by: Rajesh Yadav --- .../devicetree/bindings/display/msm/dpu.txt| 318 - 1 file changed, 118 insertions(+), 200 deletions(-) diff --git a/Documentation/devicetree/bindings/display/msm/dpu.txt b/Documentation/devicetree/bindings/display/msm/dpu.txt index 90cd3e0..a4407b8 100644 --- a/Documentation/devicetree/bindings/display/msm/dpu.txt +++ b/Documentation/devicetree/bindings/display/msm/dpu.txt @@ -1,206 +1,124 @@ Qualcomm Technologies, Inc. DPU KMS -Snapdragon Display Engine implements Linux DRM/KMS APIs to drive user -interface to different panel interfaces. DPU driver is the core of -display subsystem which manage all data paths to different panel interfaces. - -Required properties -- compatible: Must be "qcom,dpu-kms" -- compatible: "msm-hdmi-audio-codec-rx"; -- reg: Offset and length of the register set for the device. -- reg-names : Names to refer to register sets related to this device -- clocks: List of Phandles for clock device nodes -needed by the device. -- clock-names: List of clock names needed by the device. -- mmagic-supply: Phandle for mmagic mdss supply regulator device node. -- vdd-supply: Phandle for vdd regulator device node. -- interrupt-parent: Must be core interrupt controller. -- interrupts: Interrupt associated with MDSS. -- interrupt-controller: Mark the device node as an interrupt controller. -- #interrupt-cells: Should be one. The first cell is interrupt number. -- iommus: Specifies the SID's used by this context bank. +Description: + +Device tree bindings for MSM Mobile Display Subsytem(MDSS) that encapsulates +sub-blocks like DPU display controller, DSI and DP interfaces etc. +The DPU display controller is found in SDM845 SoC. + +MDSS: +Required properties: +- compatible: "qcom,dpu-mdss" +- reg: physical base address and length of contoller's registers. +- reg-names: register region names. The following region is required: + * "mdss_phys" +- power-domains: a power domain consumer specifier according to + Documentation/devicetree/bindings/power/power_domain.txt +- clocks: list of phandles for clock device nodes needed by the device. +- clock-names: device clock names, must be in same order as clocks property. + The following clocks are required: + * "iface" + * "bus" + * "core" +- interrupts: interrupt signal from MDSS. +- interrupt-controller: identifies the node as an interrupt controller. +- #interrupt-cells: specifies the number of cells needed to encode an interrupt + source, should be 1. +- iommus: phandle of iommu device node. +- #address-cells: number of address cells for the MDSS children. Should be 1. +- #size-cells: Should be 1. +- ranges: parent bus address space is the same as the child bus address space. Optional properties: -- clock-rate: List of clock rates in Hz. -- clock-max-rate: List of maximum clock rate in Hz that this device supports. -- qcom,platform-supply-entries:A node that lists the elements of the supply. There - can be more than one instance of this binding, - in which case the entry would be appended with - the supply entry index. - e.g. qcom,platform-supply-entry@0 - -- reg: offset and length of the register set for the device. - -- qcom,supply-name: name of the supply (vdd/vdda/vddio) - -- qcom,supply-min-voltage: minimum voltage level (uV) - -- qcom,supply-max-voltage: maximum voltage level (uV) - -- qcom,supply-enable-load: load drawn (uA) from enabled supply - -- qcom,supply-disable-load: load drawn (uA) from disabled supply - -- qcom,supply-pre-on-sleep: time to sleep (ms) before turning on - -- qcom,supply-post-on-sleep: time to sleep (ms) after turning on - -- qcom,supply-pre-off-sleep: time to sleep (ms) before turning off - -- qcom,supply-post-off-sleep: time to sleep (ms) after turning off -- qcom,dpu-dram-channels: This represents the number of channels in the - Bus memory controller. -- qcom,dpu-num-nrt-paths: Integer property represents the number of non-realtime - paths in each Bus Scaling
[DPU PATCH 09/11] drm/msm/dpu: Remove unused code and move the header
From: Jordan Crouse Remove unused code from dpu_io_util.c. The functions are only used inside of the msm driver so remove the EXPORT_SYMBOL tags and move the header dpu_io_util.h from include/linux. Signed-off-by: Jordan Crouse [rya...@codeaurora.org: rebased and removed some extra unused code] Signed-off-by: Rajesh Yadav --- drivers/gpu/drm/msm/dpu_io_util.c | 380 +- drivers/gpu/drm/msm/dpu_io_util.h | 61 ++ drivers/gpu/drm/msm/msm_drv.h | 1 - include/linux/dpu_io_util.h | 115 4 files changed, 66 insertions(+), 491 deletions(-) create mode 100644 drivers/gpu/drm/msm/dpu_io_util.h delete mode 100644 include/linux/dpu_io_util.h diff --git a/drivers/gpu/drm/msm/dpu_io_util.c b/drivers/gpu/drm/msm/dpu_io_util.c index ecc297c..f7caec3 100644 --- a/drivers/gpu/drm/msm/dpu_io_util.c +++ b/drivers/gpu/drm/msm/dpu_io_util.c @@ -13,318 +13,9 @@ #include #include -#include -#include #include -#include -#define MAX_I2C_CMDS 16 -void dss_reg_w(struct dss_io_data *io, u32 offset, u32 value, u32 debug) -{ - u32 in_val; - - if (!io || !io->base) { - DEV_ERR("%pS->%s: invalid input\n", - __builtin_return_address(0), __func__); - return; - } - - if (offset > io->len) { - DEV_ERR("%pS->%s: offset out of range\n", - __builtin_return_address(0), __func__); - return; - } - - writel_relaxed(value, io->base + offset); - if (debug) { - in_val = readl_relaxed(io->base + offset); - DEV_DBG("[%08x] => %08x [%08x]\n", - (u32)(unsigned long)(io->base + offset), - value, in_val); - } -} /* dss_reg_w */ -EXPORT_SYMBOL(dss_reg_w); - -u32 dss_reg_r(struct dss_io_data *io, u32 offset, u32 debug) -{ - u32 value; - - if (!io || !io->base) { - DEV_ERR("%pS->%s: invalid input\n", - __builtin_return_address(0), __func__); - return -EINVAL; - } - - if (offset > io->len) { - DEV_ERR("%pS->%s: offset out of range\n", - __builtin_return_address(0), __func__); - return -EINVAL; - } - - value = readl_relaxed(io->base + offset); - if (debug) - DEV_DBG("[%08x] <= %08x\n", - (u32)(unsigned long)(io->base + offset), value); - - return value; -} /* dss_reg_r */ -EXPORT_SYMBOL(dss_reg_r); - -void dss_reg_dump(void __iomem *base, u32 length, const char *prefix, - u32 debug) -{ - if (debug) - print_hex_dump(KERN_INFO, prefix, DUMP_PREFIX_OFFSET, 32, 4, - (void *)base, length, false); -} /* dss_reg_dump */ -EXPORT_SYMBOL(dss_reg_dump); - -static struct resource *msm_dss_get_res_byname(struct platform_device *pdev, - unsigned int type, const char *name) -{ - struct resource *res = NULL; - - res = platform_get_resource_byname(pdev, type, name); - if (!res) - DEV_ERR("%s: '%s' resource not found\n", __func__, name); - - return res; -} /* msm_dss_get_res_byname */ -EXPORT_SYMBOL(msm_dss_get_res_byname); - -int msm_dss_ioremap_byname(struct platform_device *pdev, - struct dss_io_data *io_data, const char *name) -{ - struct resource *res = NULL; - - if (!pdev || !io_data) { - DEV_ERR("%pS->%s: invalid input\n", - __builtin_return_address(0), __func__); - return -EINVAL; - } - - res = msm_dss_get_res_byname(pdev, IORESOURCE_MEM, name); - if (!res) { - DEV_ERR("%pS->%s: '%s' msm_dss_get_res_byname failed\n", - __builtin_return_address(0), __func__, name); - return -ENODEV; - } - - io_data->len = (u32)resource_size(res); - io_data->base = ioremap(res->start, io_data->len); - if (!io_data->base) { - DEV_ERR("%pS->%s: '%s' ioremap failed\n", - __builtin_return_address(0), __func__, name); - return -EIO; - } - - return 0; -} /* msm_dss_ioremap_byname */ -EXPORT_SYMBOL(msm_dss_ioremap_byname); - -void msm_dss_iounmap(struct dss_io_data *io_data) -{ - if (!io_data) { - DEV_ERR("%pS->%s: invalid input\n", - __builtin_return_address(0), __func__); - return; - } - - if (io_data->base) { - iounmap(io_data->base); - io_data->base = NULL; - } - io_data->len = 0; -} /* msm_dss_iounmap */ -EXPORT_SYMBOL(msm_dss_iounmap); - -int msm_dss_config_vreg(struct device *dev, struct dss_vreg *in_vreg, - int num_vreg, int config) -{ - int i = 0, rc = 0; - struct dss_vreg *curr_vreg = NULL; - enum dss_vreg_type type; - - if (!in_vreg || !num_vreg) -
[DPU PATCH 06/11] drm/msm/dpu: remove hdcp support
Remove hdcp 1.x support from dpu driver. The hdcp 1.x support will be posted back with display port driver. Signed-off-by: Rajesh Yadav --- drivers/gpu/drm/msm/dpu_hdcp.h| 74 -- drivers/gpu/drm/msm/dpu_hdcp_1x.c | 1579 - 2 files changed, 1653 deletions(-) delete mode 100644 drivers/gpu/drm/msm/dpu_hdcp.h delete mode 100644 drivers/gpu/drm/msm/dpu_hdcp_1x.c diff --git a/drivers/gpu/drm/msm/dpu_hdcp.h b/drivers/gpu/drm/msm/dpu_hdcp.h deleted file mode 100644 index 63a98ca..000 --- a/drivers/gpu/drm/msm/dpu_hdcp.h +++ /dev/null @@ -1,74 +0,0 @@ -/* Copyright (c) 2012, 2014-2018, The Linux Foundation. All rights reserved. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 and - * only version 2 as published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - */ - -#ifndef __DPU_HDCP_H__ -#define __DPU_HDCP_H__ - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include "dpu_kms.h" - -enum dpu_hdcp_client_id { - HDCP_CLIENT_HDMI, - HDCP_CLIENT_DP, -}; - -enum dpu_hdcp_states { - HDCP_STATE_INACTIVE, - HDCP_STATE_AUTHENTICATING, - HDCP_STATE_AUTHENTICATED, - HDCP_STATE_AUTH_FAIL, - HDCP_STATE_AUTH_ENC_NONE, - HDCP_STATE_AUTH_ENC_1X, - HDCP_STATE_AUTH_ENC_2P2 -}; - -struct dpu_hdcp_init_data { - struct dss_io_data *core_io; - struct dss_io_data *qfprom_io; - struct dss_io_data *hdcp_io; - struct drm_dp_aux *drm_aux; - struct mutex *mutex; - struct workqueue_struct *workq; - void *cb_data; - void (*notify_status)(void *cb_data, enum dpu_hdcp_states status); - u8 sink_rx_status; - unsigned char *revision; - u32 phy_addr; - bool sec_access; - enum dpu_hdcp_client_id client_id; -}; - -struct dpu_hdcp_ops { - int (*isr)(void *ptr); - int (*cp_irq)(void *ptr); - int (*reauthenticate)(void *input); - int (*authenticate)(void *hdcp_ctrl); - bool (*feature_supported)(void *input); - void (*off)(void *hdcp_ctrl); -}; - -void *dpu_hdcp_1x_init(struct dpu_hdcp_init_data *init_data); -void dpu_hdcp_1x_deinit(void *input); -struct dpu_hdcp_ops *dpu_hdcp_1x_start(void *input); -void *dpu_dp_hdcp2p2_init(struct dpu_hdcp_init_data *init_data); -void dpu_dp_hdcp2p2_deinit(void *input); -const char *dpu_hdcp_state_name(enum dpu_hdcp_states hdcp_state); -struct dpu_hdcp_ops *dpu_dp_hdcp2p2_start(void *input); -#endif /* __DPU_HDCP_H__ */ diff --git a/drivers/gpu/drm/msm/dpu_hdcp_1x.c b/drivers/gpu/drm/msm/dpu_hdcp_1x.c deleted file mode 100644 index ebbd591..000 --- a/drivers/gpu/drm/msm/dpu_hdcp_1x.c +++ /dev/null @@ -1,1579 +0,0 @@ -/* Copyright (c) 2010-2018, The Linux Foundation. All rights reserved. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 and - * only version 2 as published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - */ - -#define pr_fmt(fmt)"[dpu-hdcp1x] %s: " fmt, __func__ - -#include -#include -#include -#include -#include -#include -#include -#include -#include "dpu_hdcp.h" -#include "hdmi.xml.h" -#include "video/msm_hdmi_hdcp_mgr.h" -#include "dp/dp_reg.h" - -#define DPU_HDCP_STATE_NAME (dpu_hdcp_state_name(hdcp->hdcp_state)) - -/* QFPROM Registers for HDMI/HDCP */ -#define QFPROM_RAW_FEAT_CONFIG_ROW0_LSB (0x00F8) -#define QFPROM_RAW_FEAT_CONFIG_ROW0_MSB (0x00FC) -#define QFPROM_RAW_VERSION_4 (0x00A8) -#define SEC_CTRL_HW_VERSION (0x6000) -#define HDCP_KSV_LSB (0x60D8) -#define HDCP_KSV_MSB (0x60DC) -#define HDCP_KSV_VERSION_4_OFFSET(0x0014) - -/* SEC_CTRL version that supports HDCP SEL */ -#define HDCP_SEL_MIN_SEC_VERSION (0x5001) - -/* HDCP Keys state based on HDMI_HDCP_LINK0_STATUS:KEYS_STATE */ -#define HDCP_KEYS_STATE_NO_KEYS0 -#define HDCP_KEYS_STATE_NOT_CHECKED1 -#define HDCP_KEYS_STATE_CHECKING 2 -#define HDCP_KEYS_STATE_VALID 3 -#define HDCP_KEYS_STATE_AKSV_NOT_VALID 4 -#define HDCP_KEYS_STATE_CHKSUM_MISMATCH5 -#define HDCP_KEYS_STATE_PROD_AKSV 6 -#define HDCP_KEYS_STATE_RESERVED 7 - -#define TZ_HDCP_CMD_ID 0x4401 - -#define HDCP_INT_CLR (isr->auth_success_ack | isr->auth_fail_ack | \ -
[DPU PATCH 05/11] drm/msm/dpu: remove writeback support
Remove writeback support from dpu driver as it is not enabled. Writeback support will be added back later based on DRM writeback connector. Signed-off-by: Rajesh Yadav --- drivers/gpu/drm/msm/Makefile |5 - drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h |3 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 94 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|2 - drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 63 - .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c| 1349 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 41 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 77 -- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c |3 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 19 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h |6 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c | 12 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h |4 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 321 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h | 186 --- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|5 - drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h|1 - drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c |2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 42 +- drivers/gpu/drm/msm/disp/dpu1/dpu_wb.c | 767 --- drivers/gpu/drm/msm/disp/dpu1/dpu_wb.h | 232 21 files changed, 23 insertions(+), 3211 deletions(-) delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_wb.c delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_wb.h diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile index 7fc3974..f4c5951 100644 --- a/drivers/gpu/drm/msm/Makefile +++ b/drivers/gpu/drm/msm/Makefile @@ -68,7 +68,6 @@ msm-y := \ disp/dpu1/dpu_hw_top.o \ disp/dpu1/dpu_hw_util.o \ disp/dpu1/dpu_hw_vbif.o \ - disp/dpu1/dpu_hw_wb.o \ disp/dpu1/dpu_irq.o \ disp/dpu1/dpu_kms.o \ disp/dpu1/dpu_kms_utils.o \ @@ -99,9 +98,6 @@ msm-y := \ msm-$(CONFIG_DEBUG_FS) += adreno/a5xx_debugfs.o -msm_wb-$(CONFIG_DRM_MSM_WRITEBACK) += disp/dpu1/dpu_wb.o \ - disp/dpu1/dpu_encoder_phys_wb.o - msm-$(CONFIG_DRM_MSM_ROTATOR) += disp/dpu1/dpu_hw_rot.o msm-$(CONFIG_DRM_FBDEV_EMULATION) += msm_fbdev.o @@ -134,4 +130,3 @@ msm-$(CONFIG_DRM_MSM_DSI_10NM_PHY) += dsi/pll/dsi_pll_10nm.o endif obj-$(CONFIG_DRM_MSM) += msm.o -obj-$(CONFIG_DRM_MSM_WRITEBACK) += msm_wb.o diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h index 0f3aa60..39def93 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h @@ -440,8 +440,7 @@ static inline enum dpu_crtc_client_type dpu_crtc_get_client_type( if (!cstate) return NRT_CLIENT; - return dpu_crtc_get_intf_mode(crtc) == INTF_MODE_WB_LINE ? NRT_CLIENT : - RT_CLIENT; + return RT_CLIENT; } /** diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c index 1d45c8f..7dd609c 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c @@ -1405,15 +1405,6 @@ static enum dpu_intf dpu_encoder_get_intf(struct dpu_mdss_cfg *catalog, return INTF_MAX; } -static enum dpu_wb dpu_encoder_get_wb(struct dpu_mdss_cfg *catalog, - enum dpu_intf_type type, u32 controller_id) -{ - if (controller_id < catalog->wb_count) - return catalog->wb[controller_id].id; - - return WB_MAX; -} - static void dpu_encoder_vblank_callback(struct drm_encoder *drm_enc, struct dpu_encoder_phys *phy_enc) { @@ -2144,12 +2135,6 @@ static int _dpu_encoder_status_show(struct seq_file *s, void *data) case INTF_MODE_CMD: seq_puts(s, "mode: command\n"); break; - case INTF_MODE_WB_BLOCK: - seq_puts(s, "mode: wb block\n"); - break; - case INTF_MODE_WB_LINE: - seq_puts(s, "mode: wb line\n"); - break; default: seq_puts(s, "mode: ???\n"); break; @@ -2409,39 +2394,6 @@ static int dpu_encoder_virt_add_phys_encs( return 0; } -static int dpu_encoder_virt_add_phys_enc_wb(struct dpu_encoder_virt *dpu_enc, - struct dpu_enc_phys_init_params *params) -{ -#ifdef CONFIG_DRM_MSM_WRITEBACK - struct dpu_encoder_phys *enc = NULL; - - if (!dpu_enc) { -
Re: [PATCH v2 2/2] drm/mali-dp: Implement plane alpha and pixel blend on malidp
Hi Lowry, On Wed, May 30, 2018 at 07:23:54PM +0800, Lowry Li wrote: Check the pixel blending mode and plane alpha value when do the plane_check. Mali DP supports blending the current plane with the background either based on the pixel alpha blending mode or by using the layer's alpha value, but not both at the same time. If both case, plane_check will return failed. Set the HW when doing plane_update accordingly. If plane alpha is the 0x, set the PREM bit accordingly. If not we'd set ALPHA bit as zero and layer alpha value. The code looks correct - but the description of the PREM bit seems wrong here. Did you mean "set the pixel blending bits accordingly"? With that fixed: Reviewed-by: Brian Starkey Signed-off-by: Lowry Li --- drivers/gpu/drm/arm/malidp_planes.c | 76 + 1 file changed, 44 insertions(+), 32 deletions(-) diff --git a/drivers/gpu/drm/arm/malidp_planes.c b/drivers/gpu/drm/arm/malidp_planes.c index 7a44897..daa3f4f 100644 --- a/drivers/gpu/drm/arm/malidp_planes.c +++ b/drivers/gpu/drm/arm/malidp_planes.c @@ -35,6 +35,7 @@ #define LAYER_COMP_MASK (0x3 << 12) #define LAYER_COMP_PIXEL (0x3 << 12) #define LAYER_COMP_PLANE (0x2 << 12) +#define LAYER_PMUL_ENABLE(0x1 << 14) #define LAYER_ALPHA_OFFSET(16) #define LAYER_ALPHA_MASK (0xff) #define LAYER_ALPHA(x)(((x) & LAYER_ALPHA_MASK) << LAYER_ALPHA_OFFSET) @@ -182,6 +183,7 @@ static int malidp_de_plane_check(struct drm_plane *plane, struct malidp_plane_state *ms = to_malidp_plane_state(state); bool rotated = state->rotation & MALIDP_ROTATED_MASK; struct drm_framebuffer *fb; + u16 pixel_alpha = state->pixel_blend_mode; int i, ret; if (!state->crtc || !state->fb) @@ -244,6 +246,11 @@ static int malidp_de_plane_check(struct drm_plane *plane, ms->rotmem_size = val; } + /* HW can't support plane + pixel blending */ + if ((state->alpha != DRM_BLEND_ALPHA_OPAQUE) && + (pixel_alpha != DRM_MODE_BLEND_PIXEL_NONE)) + return -EINVAL; + return 0; } @@ -325,31 +332,33 @@ static void malidp_de_plane_update(struct drm_plane *plane, { struct malidp_plane *mp; struct malidp_plane_state *ms = to_malidp_plane_state(plane->state); + struct drm_plane_state *state = plane->state; + u16 pixel_alpha = state->pixel_blend_mode; + u8 plane_alpha = state->alpha >> 8; u32 src_w, src_h, dest_w, dest_h, val; int i; - bool format_has_alpha = plane->state->fb->format->has_alpha; mp = to_malidp_plane(plane); /* convert src values from Q16 fixed point to integer */ - src_w = plane->state->src_w >> 16; - src_h = plane->state->src_h >> 16; - dest_w = plane->state->crtc_w; - dest_h = plane->state->crtc_h; + src_w = state->src_w >> 16; + src_h = state->src_h >> 16; + dest_w = state->crtc_w; + dest_h = state->crtc_h; malidp_hw_write(mp->hwdev, ms->format, mp->layer->base); for (i = 0; i < ms->n_planes; i++) { /* calculate the offset for the layer's plane registers */ u16 ptr = mp->layer->ptr + (i << 4); - dma_addr_t fb_addr = drm_fb_cma_get_gem_addr(plane->state->fb, -plane->state, i); + dma_addr_t fb_addr = drm_fb_cma_get_gem_addr(state->fb, +state, i); malidp_hw_write(mp->hwdev, lower_32_bits(fb_addr), ptr); malidp_hw_write(mp->hwdev, upper_32_bits(fb_addr), ptr + 4); } malidp_de_set_plane_pitches(mp, ms->n_planes, - plane->state->fb->pitches); + state->fb->pitches); if ((plane->state->color_encoding != old_state->color_encoding) || (plane->state->color_range != old_state->color_range)) @@ -362,8 +371,8 @@ static void malidp_de_plane_update(struct drm_plane *plane, malidp_hw_write(mp->hwdev, LAYER_H_VAL(dest_w) | LAYER_V_VAL(dest_h), mp->layer->base + MALIDP_LAYER_COMP_SIZE); - malidp_hw_write(mp->hwdev, LAYER_H_VAL(plane->state->crtc_x) | - LAYER_V_VAL(plane->state->crtc_y), + malidp_hw_write(mp->hwdev, LAYER_H_VAL(state->crtc_x) | + LAYER_V_VAL(state->crtc_y), mp->layer->base + MALIDP_LAYER_OFFSET); if (mp->layer->id == DE_SMART) @@ -376,38 +385,35 @@ static void malidp_de_plane_update(struct drm_plane *plane, val &= ~LAYER_ROT_MASK; /* setup the rotation and axis flip bits */ - if (plane->state->rotation & DRM_MODE_ROTATE_MASK) + if (state->rotation & DRM_MODE_ROTATE_MASK) val |=
[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)
https://bugs.freedesktop.org/show_bug.cgi?id=105425 --- Comment #74 from MirceaKitsune --- pcie_aspm=off makes no difference. In addition, I tried booting back to the radeon module (instead of amdgpu) and disabling the SI scheduler: This seems to have slightly mitigated the problem in some cases (eg: Blender) but made no difference in others (eg: Xonotic). As for suspending to RAM: I haven't used Standby mode in ages. I never suspend my computer to RAM, so this could not be an issue. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping
On 30/05/18 14:00, Thierry Reding wrote: On Wed, May 30, 2018 at 11:30:25AM +0100, Robin Murphy wrote: On 30/05/18 09:03, Thierry Reding wrote: From: Thierry Reding Depending on the kernel configuration, early ARM architecture setup code may have attached the GPU to a DMA/IOMMU mapping that transparently uses the IOMMU to back the DMA API. Tegra requires special handling for IOMMU backed buffers (a special bit in the GPU's MMU page tables indicates the memory path to take: via the SMMU or directly to the memory controller). Transparently backing DMA memory with an IOMMU prevents Nouveau from properly handling such memory accesses and causes memory access faults. As a side-note: buffers other than those allocated in instance memory don't need to be physically contiguous from the GPU's perspective since the GPU can map them into contiguous buffers using its own MMU. Mapping these buffers through the IOMMU is unnecessary and will even lead to performance degradation because of the additional translation. One exception to this are compressible buffers which need large pages. In order to enable these large pages, multiple small pages will have to be combined into one large (I/O virtually contiguous) mapping via the IOMMU. However, that is a topic outside the scope of this fix and isn't currently supported. An implementation will want to explicitly create these large pages in the Nouveau driver, so detaching from a DMA/IOMMU mapping would still be required. I wonder if it might make sense to have a hook in iommu_attach_device() to notify the arch DMA API code when moving devices between unmanaged and DMA ops domains? That seems like it might be the most low-impact way to address the overall problem long-term. Signed-off-by: Thierry Reding --- Changes in v3: - clarify the use of IOMMU mapping for compressible buffers - squash multiple patches into this drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c index 78597da6313a..d0538af1b967 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c @@ -105,6 +105,11 @@ nvkm_device_tegra_probe_iommu(struct nvkm_device_tegra *tdev) unsigned long pgsize_bitmap; int ret; +#if IS_ENABLED(CONFIG_ARM) Wouldn't CONFIG_ARM_DMA_USE_IOMMU be even more appropriate? Not necessarily. arm_dma_iommu_detach_device() is always defined on ARM, only with CONFIG_ARM_DMA_USE_IOMMU=n it will be empty. So this check is a guard to make sure we don't call the function when it isn't available, but it may still not do anything. Calling a function under condition A, which only does anything under condition B, when B depends on A, is identical in behaviour to only calling the function under condition B, except needlessly harder to follow. + /* make sure we can use the IOMMU exclusively */ + arm_dma_iommu_detach_device(dev); As before, I would just use the existing infrastructure the same way the Exynos DRM driver currently does in __exynos_iommu_attach() (albeit without then reattaching to another DMA ops mapping). That's pretty much what I initially did and which was shot down by Christoph. As I said earlier, at this point I don't really care what color the shed will be. Can you and Christoph come to an agreement on what it should be? What I was getting at is that arm_iommu_detach_device() already *is* the exact function Christoph was asking for, it just needs a minor fix instead of adding explicit set_dma_ops() fiddling at its callsites which only obfuscates the fact that it's supposed to be responsible for resetting the device's DMA ops already. Robin. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/blend: Add per-plane pixel blend mode property
Hi Lowry, On Wed, May 30, 2018 at 07:23:53PM +0800, Lowry Li wrote: Pixel blend modes represent the alpha blending equation selection, describing how the pixels from the current plane are composited with the background. Add a pixel_blend_mode to drm_plane_state and a blend_mode_property to drm_plane, and related support functions. Defines three blend modes in drm_blend.h. Signed-off-by: Lowry Li With or without the kerneldoc tweaks I've suggested below, this patch is: Reviewed-by: Brian Starkey --- drivers/gpu/drm/drm_atomic.c| 4 ++ drivers/gpu/drm/drm_atomic_helper.c | 1 + drivers/gpu/drm/drm_blend.c | 110 include/drm/drm_blend.h | 6 ++ include/drm/drm_plane.h | 6 ++ 5 files changed, 127 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 7d25c42..467f8de 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -783,6 +783,8 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane, state->src_w = val; } else if (property == config->prop_src_h) { state->src_h = val; + } else if (property == plane->blend_mode_property) { + state->pixel_blend_mode = val; } else if (property == plane->rotation_property) { if (!is_power_of_2(val & DRM_MODE_ROTATE_MASK)) return -EINVAL; @@ -848,6 +850,8 @@ static int drm_atomic_plane_set_property(struct drm_plane *plane, *val = state->src_w; } else if (property == config->prop_src_h) { *val = state->src_h; + } else if (property == plane->blend_mode_property) { + *val = state->pixel_blend_mode; } else if (property == plane->rotation_property) { *val = state->rotation; } else if (property == plane->zpos_property) { diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index c356545..ddbd0d2 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -3484,6 +3484,7 @@ void drm_atomic_helper_plane_reset(struct drm_plane *plane) if (plane->state) { plane->state->plane = plane; plane->state->rotation = DRM_MODE_ROTATE_0; + plane->state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI; } } EXPORT_SYMBOL(drm_atomic_helper_plane_reset); diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c index 5a81e1b..4ac45da 100644 --- a/drivers/gpu/drm/drm_blend.c +++ b/drivers/gpu/drm/drm_blend.c @@ -100,6 +100,41 @@ * planes. Without this property the primary plane is always below the cursor * plane, and ordering between all other planes is undefined. * + * pixel blend mode: + * Pixel blend mode is set up with drm_plane_create_blend_mode_property(). + * It adds a blend mode for alpha blending equation selection, describing + * how the pixels from the current plane are composited with the + * background. + * + * Three alpha blending equations(note that the fg.rgb or bg.rgb notation + * means each of the R, G or B channels for the foreground and background + * colors, respectively): + * + * "None": Blend formula that ignores the pixel alpha. + * out.rgb = plane_alpha * fg.rgb + (1 - plane_alpha) * bg.rgb + * + * "Pre-multiplied": Blend formula that assumes the pixel color values + * have been already pre-multiplied with the alpha + * channel values. + * out.rgb = plane_alpha * fg.rgb + (1 - (plane_alpha * fg.alpha)) * bg.rgb + * + * "Coverage": Blend formula that assumes the pixel color values have not + * been pre-multiplied and will do so when blending them to the background + * color values. + * out.rgb = plane_alpha * fg.alpha * fg.rgb + + * (1 - (plane_alpha * fg.alpha)) * bg.rgb + * + * fg.rgb: Each of the RGB component values from the plane's pixel + * fg.alpha: Alpha component value from the plane's pixel + * bg.rgb: Each of the RGB component values from the background + * plane_alpha: Plane alpha value set by the plane alpha property (if + * applicable). + * + * This property has no effect on formats with no pixel alpha, as fg.alpha + * is assumed to be 1.0. If the plane does not expose the "alpha" property, + * then plane_alpha is assumed to be 1.0, otherwise, it is the value of the + * "alpha" property. + * I did a little fiddling to make this render nicely in the documentation output. If you like it, you can apply the hunk below: -- >8 -- diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c index 714b0602127d..7b5c3307d4c1 100644 --- a/drivers/gpu/drm/drm_blend.c +++ b/drivers/gpu/drm/drm_blend.c @@ -113,34 +113,45 @@ * how the pixels from the current plane are composited with the * background. * -
Re: [PATCH 07/12] dt-bindings: tc358754: add DT bindings
Hi Andrzej, On Wednesday, 30 May 2018 16:07:29 EEST Andrzej Hajda wrote: > On 30.05.2018 14:35, Laurent Pinchart wrote: > > On Wednesday, 30 May 2018 12:59:12 EEST Andrzej Hajda wrote: > >> On 28.05.2018 12:18, Laurent Pinchart wrote: > >>> On Monday, 28 May 2018 12:47:11 EEST Maciej Purski wrote: > The patch adds bindings to Toshiba DSI/LVDS bridge TC358764. > Bindings describe power supplies, reset gpio and video interfaces. > > Signed-off-by: Andrzej Hajda > Signed-off-by: Maciej Purski > --- > > .../bindings/display/bridge/toshiba,tc358764.txt | 42 > > 1 file changed, 42 insertions(+) > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt > > diff --git > a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt > b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt > new > file mode 100644 > index 000..d09bdc2 > --- /dev/null > +++ > b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt > @@ -0,0 +1,42 @@ > +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 > + - vddio-supply: I/O voltage supply > + - vddmipi-supply: MIPI voltage supply > + - vddlvds133-supply: LVDS1 3.3V voltage supply > + - vddlvds112-supply: LVDS1 1.2V voltage supply > >>> > >>> That's a lot of power supplies. Could some of them be merged together ? > >>> See https://patchwork.freedesktop.org/patch/216058/ for an earlier > >>> discussion on the same subject. > >> > >> Specs says about 3 supply voltage values: > >> - 1.2V - digital core, DSI-RX PHY > >> - 1.8-3.3V - digital I/O > >> - 3.3V - LVDS-TX PHY > >> > >> So I guess it should be minimal number of supplies. Natural candidates: > >> > >> - 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 > >> > >> I have changed name of the latest supply to be more consistent with > >> other supplies, and changed 1.8-3.3 (which incorrectly suggest voltage > >> range), to more precise voltage alternative. > > > > This looks fine to me. > > > + - reset-gpios: a GPIO spec for the reset pin > + > +The device node can contain zero to two 'port' child nodes, each with > one > +child > +'endpoint' node, according to the bindings defined in [1]. > +The following are properties specific to those nodes. > + > +port: > + - reg: (required) can be 0 for DSI port or 1 for LVDS port; > >>> > >>> This seems pretty vague to me. It could be read as meaning that ports > >>> are > >>> completely optional, and that the port number you list can be used, but > >>> that something else could be used to. > >>> > >>> Let's make the port nodes mandatory. I propose the following. > >>> > >>> Required nodes: > >>> > >>> The TC358764 has DSI and LVDS ports whose connections are described > >>> using > >>> the OF graph bindings defined in > >>> Documentation/devicetree/bindings/graph.txt. The device node must > >>> contain > >>> one 'port' child node per DSI and LVDS port. The port nodes are numbered > >>> as follows. > >>> > >>> Port Number > >>> > >>> --- > >>> > >>> DSI Input 0 > >>> LVDS Output 1 > >>> > >>> Each port node must contain endpoint nodes describing the hardware > >>> connections. > >> > >> Since the bridge is controlled via DSI bus, DSI input port is not > >> necessary. > > > > I don't agree with this. Regardless of how the bridge is controlled, I > > think we should always use ports to describe the data connections. > > Otherwise it would get more complicated for display controller drivers to > > use different types of bridges. > > It was discussed already, and DT guideline is to skip graphs in simple > case of parent/child nodes, see for example [1]. > > [1]: https://marc.info/?l=dri-devel=148354108702517=2 That's when the child as no other connection at all. I don't think it makes sense to mix description of connections through parent/child relationships and through ports for a single device. And that being said, I don't agree with Rob's comment there. Having two different methods to describe connections means that you have to implement them both in all display controller drivers (and even all bridge drivers in the case of chained bridges). That's an extra complexity that can easily be avoided by standardizing DT bindings. I also wonder whether Rob's position hasn't been reconsidered since then; I vaguely recalled another more recent discussion on this topic. I'm a bit too busy
Re: [PATCH v3 1/2] ARM: dma-mapping: Implement arm_dma_iommu_detach_device()
On Wed, May 30, 2018 at 02:54:46PM +0200, Thierry Reding wrote: > On Wed, May 30, 2018 at 10:59:30AM +0100, Robin Murphy wrote: > > On 30/05/18 09:03, Thierry Reding wrote: > > > From: Thierry Reding > > > > > > Implement this function to enable drivers from detaching from any IOMMU > > > domains that architecture code might have attached them to so that they > > > can take exclusive control of the IOMMU via the IOMMU API. > > > > > > Signed-off-by: Thierry Reding > > > --- > > > Changes in v3: > > > - make API 32-bit ARM specific > > > - avoid extra local variable > > > > > > Changes in v2: > > > - fix compilation > > > > > > arch/arm/include/asm/dma-mapping.h | 3 +++ > > > arch/arm/mm/dma-mapping-nommu.c| 4 > > > arch/arm/mm/dma-mapping.c | 16 > > > 3 files changed, 23 insertions(+) > > > > > > diff --git a/arch/arm/include/asm/dma-mapping.h > > > b/arch/arm/include/asm/dma-mapping.h > > > index 8436f6ade57d..5960e9f3a9d0 100644 > > > --- a/arch/arm/include/asm/dma-mapping.h > > > +++ b/arch/arm/include/asm/dma-mapping.h > > > @@ -103,6 +103,9 @@ extern void arch_setup_dma_ops(struct device *dev, > > > u64 dma_base, u64 size, > > > #define arch_teardown_dma_ops arch_teardown_dma_ops > > > extern void arch_teardown_dma_ops(struct device *dev); > > > +#define arm_dma_iommu_detach_device arm_dma_iommu_detach_device > > > +extern void arm_dma_iommu_detach_device(struct device *dev); > > > + > > > /* do not use this function in a driver */ > > > static inline bool is_device_dma_coherent(struct device *dev) > > > { > > > diff --git a/arch/arm/mm/dma-mapping-nommu.c > > > b/arch/arm/mm/dma-mapping-nommu.c > > > index f448a0663b10..eb781369377b 100644 > > > --- a/arch/arm/mm/dma-mapping-nommu.c > > > +++ b/arch/arm/mm/dma-mapping-nommu.c > > > @@ -241,3 +241,7 @@ void arch_setup_dma_ops(struct device *dev, u64 > > > dma_base, u64 size, > > > void arch_teardown_dma_ops(struct device *dev) > > > { > > > } > > > + > > > +void arm_dma_iommu_detach_device(struct device *dev) > > > +{ > > > +} > > > diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c > > > index af27f1c22d93..6d8af08b3e7d 100644 > > > --- a/arch/arm/mm/dma-mapping.c > > > +++ b/arch/arm/mm/dma-mapping.c > > > @@ -2400,3 +2400,19 @@ void arch_teardown_dma_ops(struct device *dev) > > > arm_teardown_iommu_dma_ops(dev); > > > } > > > + > > > +void arm_dma_iommu_detach_device(struct device *dev) > > > +{ > > > +#ifdef CONFIG_ARM_DMA_USE_IOMMU > > > + struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev); > > > + > > > + if (!mapping) > > > + return; > > > + > > > + arm_iommu_release_mapping(mapping); > > > > Potentially freeing the mapping before you try to operate on it is never the > > best idea. Plus arm_iommu_detach_device() already releases a reference > > appropriately anyway, so it's a double-free. > > But the reference released by arm_iommu_detach_device() is to balance > out the reference acquired by arm_iommu_attach_device(), isn't it? In > the above, the arm_iommu_release_mapping() is supposed to drop the > final reference which was obtained by arm_iommu_create_mapping(). The > mapping shouldn't go away irrespective of the order in which these > will be called. Going over the DMA/IOMMU code I just remembered that I drew inspiration from arm_teardown_iommu_dma_ops() for the initial proposal which also calls both arm_iommu_detach_device() and arm_iommu_release_mapping(). That said, one other possibility to implement this would be to export the 32-bit and 64-bit ARM implementations of arch_teardown_dma_ops() and use that instead. linux/dma-mapping.h implements a stub for architectures that don't provide one, so it should work without any #ifdef guards. That combined with the set_dma_ops() fix in arm_iommu_detach_device() should fix this pretty nicely. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/12] dt-bindings: tc358754: add DT bindings
On 30.05.2018 14:35, Laurent Pinchart wrote: > Hi Andrzej, > > On Wednesday, 30 May 2018 12:59:12 EEST Andrzej Hajda wrote: >> On 28.05.2018 12:18, Laurent Pinchart wrote: >>> On Monday, 28 May 2018 12:47:11 EEST Maciej Purski wrote: The patch adds bindings to Toshiba DSI/LVDS bridge TC358764. Bindings describe power supplies, reset gpio and video interfaces. Signed-off-by: Andrzej Hajda Signed-off-by: Maciej Purski --- .../bindings/display/bridge/toshiba,tc358764.txt | 42 1 file changed, 42 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt new file mode 100644 index 000..d09bdc2 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt @@ -0,0 +1,42 @@ +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 + - vddio-supply: I/O voltage supply + - vddmipi-supply: MIPI voltage supply + - vddlvds133-supply: LVDS1 3.3V voltage supply + - vddlvds112-supply: LVDS1 1.2V voltage supply >>> That's a lot of power supplies. Could some of them be merged together ? >>> See https://patchwork.freedesktop.org/patch/216058/ for an earlier >>> discussion on the same subject. >> Specs says about 3 supply voltage values: >> - 1.2V - digital core, DSI-RX PHY >> - 1.8-3.3V - digital I/O >> - 3.3V - LVDS-TX PHY >> >> So I guess it should be minimal number of supplies. Natural candidates: >> >> - 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 >> >> I have changed name of the latest supply to be more consistent with >> other supplies, and changed 1.8-3.3 (which incorrectly suggest voltage >> range), to more precise voltage alternative. > This looks fine to me. > + - reset-gpios: a GPIO spec for the reset pin + +The device node can contain zero to two 'port' child nodes, each with one +child +'endpoint' node, according to the bindings defined in [1]. +The following are properties specific to those nodes. + +port: + - reg: (required) can be 0 for DSI port or 1 for LVDS port; >>> This seems pretty vague to me. It could be read as meaning that ports are >>> completely optional, and that the port number you list can be used, but >>> that something else could be used to. >>> >>> Let's make the port nodes mandatory. I propose the following. >>> >>> Required nodes: >>> >>> The TC358764 has DSI and LVDS ports whose connections are described using >>> the OF graph bindings defined in >>> Documentation/devicetree/bindings/graph.txt. The device node must contain >>> one 'port' child node per DSI and LVDS port. The port nodes are numbered >>> as follows. >>> >>> Port Number >>> --- >>> DSI Input 0 >>> LVDS Output 1 >>> >>> Each port node must contain endpoint nodes describing the hardware >>> connections. >> Since the bridge is controlled via DSI bus, DSI input port is not necessary. > I don't agree with this. Regardless of how the bridge is controlled, I think > we should always use ports to describe the data connections. Otherwise it > would get more complicated for display controller drivers to use different > types of bridges. It was discussed already, and DT guideline is to skip graphs in simple case of parent/child nodes, see for example [1]. [1]: https://marc.info/?l=dri-devel=148354108702517=2 Regards Andrzej +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt + +Example: + + bridge@0 { + reg = <0>; + compatible = "toshiba,tc358764"; + vddc-supply = <_1v2_reg>; + vddio-supply = <_1v8_reg>; + vddmipi-supply = <_1v2_reg>; + vddlvds133-supply = <_3v3_reg>; + vddlvds112-supply = <_1v2_reg>; + reset-gpios = < 6 GPIO_ACTIVE_LOW>; + #address-cells = <1>; + #size-cells = <0>; + port@1 { + reg = <1>; + lvds_ep: endpoint { + remote-endpoint = <_ep>; + }; + }; + }; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping
On Wed, May 30, 2018 at 11:30:25AM +0100, Robin Murphy wrote: > On 30/05/18 09:03, Thierry Reding wrote: > > From: Thierry Reding > > > > Depending on the kernel configuration, early ARM architecture setup code > > may have attached the GPU to a DMA/IOMMU mapping that transparently uses > > the IOMMU to back the DMA API. Tegra requires special handling for IOMMU > > backed buffers (a special bit in the GPU's MMU page tables indicates the > > memory path to take: via the SMMU or directly to the memory controller). > > Transparently backing DMA memory with an IOMMU prevents Nouveau from > > properly handling such memory accesses and causes memory access faults. > > > > As a side-note: buffers other than those allocated in instance memory > > don't need to be physically contiguous from the GPU's perspective since > > the GPU can map them into contiguous buffers using its own MMU. Mapping > > these buffers through the IOMMU is unnecessary and will even lead to > > performance degradation because of the additional translation. One > > exception to this are compressible buffers which need large pages. In > > order to enable these large pages, multiple small pages will have to be > > combined into one large (I/O virtually contiguous) mapping via the > > IOMMU. However, that is a topic outside the scope of this fix and isn't > > currently supported. An implementation will want to explicitly create > > these large pages in the Nouveau driver, so detaching from a DMA/IOMMU > > mapping would still be required. > > I wonder if it might make sense to have a hook in iommu_attach_device() to > notify the arch DMA API code when moving devices between unmanaged and DMA > ops domains? That seems like it might be the most low-impact way to address > the overall problem long-term. > > > Signed-off-by: Thierry Reding > > --- > > Changes in v3: > > - clarify the use of IOMMU mapping for compressible buffers > > - squash multiple patches into this > > > > drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c > > b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c > > index 78597da6313a..d0538af1b967 100644 > > --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c > > +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c > > @@ -105,6 +105,11 @@ nvkm_device_tegra_probe_iommu(struct nvkm_device_tegra > > *tdev) > > unsigned long pgsize_bitmap; > > int ret; > > +#if IS_ENABLED(CONFIG_ARM) > > Wouldn't CONFIG_ARM_DMA_USE_IOMMU be even more appropriate? Not necessarily. arm_dma_iommu_detach_device() is always defined on ARM, only with CONFIG_ARM_DMA_USE_IOMMU=n it will be empty. So this check is a guard to make sure we don't call the function when it isn't available, but it may still not do anything. > > > + /* make sure we can use the IOMMU exclusively */ > > + arm_dma_iommu_detach_device(dev); > > As before, I would just use the existing infrastructure the same way the > Exynos DRM driver currently does in __exynos_iommu_attach() (albeit without > then reattaching to another DMA ops mapping). That's pretty much what I initially did and which was shot down by Christoph. As I said earlier, at this point I don't really care what color the shed will be. Can you and Christoph come to an agreement on what it should be? Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] ARM: dma-mapping: Implement arm_dma_iommu_detach_device()
On Wed, May 30, 2018 at 10:59:30AM +0100, Robin Murphy wrote: > On 30/05/18 09:03, Thierry Reding wrote: > > From: Thierry Reding > > > > Implement this function to enable drivers from detaching from any IOMMU > > domains that architecture code might have attached them to so that they > > can take exclusive control of the IOMMU via the IOMMU API. > > > > Signed-off-by: Thierry Reding > > --- > > Changes in v3: > > - make API 32-bit ARM specific > > - avoid extra local variable > > > > Changes in v2: > > - fix compilation > > > > arch/arm/include/asm/dma-mapping.h | 3 +++ > > arch/arm/mm/dma-mapping-nommu.c| 4 > > arch/arm/mm/dma-mapping.c | 16 > > 3 files changed, 23 insertions(+) > > > > diff --git a/arch/arm/include/asm/dma-mapping.h > > b/arch/arm/include/asm/dma-mapping.h > > index 8436f6ade57d..5960e9f3a9d0 100644 > > --- a/arch/arm/include/asm/dma-mapping.h > > +++ b/arch/arm/include/asm/dma-mapping.h > > @@ -103,6 +103,9 @@ extern void arch_setup_dma_ops(struct device *dev, u64 > > dma_base, u64 size, > > #define arch_teardown_dma_ops arch_teardown_dma_ops > > extern void arch_teardown_dma_ops(struct device *dev); > > +#define arm_dma_iommu_detach_device arm_dma_iommu_detach_device > > +extern void arm_dma_iommu_detach_device(struct device *dev); > > + > > /* do not use this function in a driver */ > > static inline bool is_device_dma_coherent(struct device *dev) > > { > > diff --git a/arch/arm/mm/dma-mapping-nommu.c > > b/arch/arm/mm/dma-mapping-nommu.c > > index f448a0663b10..eb781369377b 100644 > > --- a/arch/arm/mm/dma-mapping-nommu.c > > +++ b/arch/arm/mm/dma-mapping-nommu.c > > @@ -241,3 +241,7 @@ void arch_setup_dma_ops(struct device *dev, u64 > > dma_base, u64 size, > > void arch_teardown_dma_ops(struct device *dev) > > { > > } > > + > > +void arm_dma_iommu_detach_device(struct device *dev) > > +{ > > +} > > diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c > > index af27f1c22d93..6d8af08b3e7d 100644 > > --- a/arch/arm/mm/dma-mapping.c > > +++ b/arch/arm/mm/dma-mapping.c > > @@ -2400,3 +2400,19 @@ void arch_teardown_dma_ops(struct device *dev) > > arm_teardown_iommu_dma_ops(dev); > > } > > + > > +void arm_dma_iommu_detach_device(struct device *dev) > > +{ > > +#ifdef CONFIG_ARM_DMA_USE_IOMMU > > + struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev); > > + > > + if (!mapping) > > + return; > > + > > + arm_iommu_release_mapping(mapping); > > Potentially freeing the mapping before you try to operate on it is never the > best idea. Plus arm_iommu_detach_device() already releases a reference > appropriately anyway, so it's a double-free. But the reference released by arm_iommu_detach_device() is to balance out the reference acquired by arm_iommu_attach_device(), isn't it? In the above, the arm_iommu_release_mapping() is supposed to drop the final reference which was obtained by arm_iommu_create_mapping(). The mapping shouldn't go away irrespective of the order in which these will be called. > > + arm_iommu_detach_device(dev); > > + > > + set_dma_ops(dev, arm_get_dma_map_ops(dev->archdata.dma_coherent)); > > +#endif > > +} > > +EXPORT_SYMBOL(arm_dma_iommu_detach_device); > > I really don't see why we need an extra function that essentially just > duplicates arm_iommu_detach_device(). The only real difference here is that > here you reset the DMA ops more appropriately, but I think the existing > function should be fixed to do that anyway, since set_dma_ops(dev, NULL) now > just behaves as an unconditional fallback to the noncoherent arm_dma_ops, > which clearly isn't always right. The idea behind making this an extra function is that we can call it unconditionally and it will do the right things. Granted, that already doesn't quite work as elegantly anymore as I had hoped since this is now an ARM specific function, so we need an #ifdef guard anyway. I don't care very strongly either way, so if you and Christoph can both agree that we just want arm_iommu_detach_device() to call the proper variant of set_dma_ops(), that's fine with me, too. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/10] dt-bindings: tc358754: add DT bindings
Hi Maciej, On Wednesday, 30 May 2018 15:15:58 EEST Maciej Purski wrote: > From: Andrzej Hajda > > The patch adds bindings to Toshiba DSI/LVDS bridge TC358764. > Bindings describe power supplies, reset gpio and video interfaces. > > Signed-off-by: Andrzej Hajda > Signed-off-by: Maciej Purski > --- > .../bindings/display/bridge/toshiba,tc358764.txt | 37 +++ > 1 file changed, 37 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt > > diff --git > a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt > b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt new > file mode 100644 > index 000..6eda14f > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt > @@ -0,0 +1,37 @@ > +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 zero to two 'port' child nodes, each with one > +child 'endpoint' node, according to the bindings defined in [1]. > +The following are properties specific to those nodes. > + > +port: > + - reg: (required) can be 0 for DSI port or 1 for LVDS port; > + > +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt Could you please take the comments I made on v1 into account when you'll post v3 ? > +Example: > + > + bridge@0 { > + reg = <0>; > + compatible = "toshiba,tc358764"; > + vddc-supply = <_1v2_reg>; > + vddio-supply = <_1v8_reg>; > + vddlvds-supply = <_3v3_reg>; > + reset-gpios = < 6 GPIO_ACTIVE_LOW>; > + #address-cells = <1>; > + #size-cells = <0>; > + port@1 { > + reg = <1>; > + lvds_ep: endpoint { > + remote-endpoint = <_ep>; > + }; > + }; > + }; -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel