[PATCHv5 1/3] ARM:dt-bindings 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.
Signed-off-by: Ong, Hean Loong
---
.../devicetree/bindings/display/altr,vip-fb2.txt | 39 ++
1 file changed, 39 insertions(+)
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..c4338d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
@@ -0,0 +1,39 @@
+Intel Video and Image Processing(VIP) Frame Buffer II bindings
+
+Supported hardware: Arria 10 and above with display port IP
+
+The hardware associated with this device tree is a SoC FPGA. Where there is an
ARM controller
+and a FPGA device. The ARM controller would host the Linux OS while the FPGA
device runs on its
+individual IP firmware. In the Intel VIP Frame Buffer II the ARM controller
would be
+driving data from the Linux OS to the FPGA device programmed with the Frame
Buffer II IP
+to render pixels to be streamed to the Display Port connector.
+
+The Frame Buffer II device is a simple frame buffer device. The device
contains the display
+properties and the bridge or connector register. The output for this device
currently
+is a dedicated to a single Display Port. Currently the max resolution
supported is 1280 x 720 at
+60Hz.
+
+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
+
+
+New 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 width of the framebuffer in pixels.
+- altr,max-height: The height of the framebuffer in pixels.
+- altr,mem-port-width = the bus width of the avalon master port on the frame
reader
+
+Example:
+
+ dp_0_frame_buf: display-controller@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>;
+ };
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 3/3] ARM:drm ivip Intel FPGA Video and Image Processing Suite
From: Ong Hean Loong
Signed-off-by: Ong Hean Loong
---
V5:
*Fix Comments
V4:
*Fix Comments
V3:
*Changes to fixing drm_simple_pipe
*Used drm_fb_cma_get_gem_addr
V2:
*Adding drm_simple_display_pipe_init
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/ivip/Kconfig | 13 +++
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 | 194 ++
8 files changed, 529 insertions(+)
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 83cb2a8..38a184d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -195,6 +195,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 24a066e..4162a0e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -58,6 +58,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..9a8c5ce
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Kconfig
@@ -0,0 +1,13 @@
+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 a Intel FPGA Arria 10 system
+and above with a 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 yet
+to be supported.If M is selected the module would be called ivip.
diff --git a/drivers/gpu/drm/ivip/Makefile b/drivers/gpu/drm/ivip/Makefile
new file mode 100644
index 000..95291c6
--- /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..c88df23
--- /dev/null
+++ b/drivers/gpu/drm/ivip/intel_vip_conn.c
@@ -0,0 +1,96 @@
+/*
+ * 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 = {
+ .dpms = drm_atomic_helper_connector_dpms,
+ .reset = drm_atomic_helper_connector_reset,
+ .detect = intelvipfb_drm_connector_detect,
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .destroy = intelvipfb_drm_connector_destroy,
+ .atomic_duplicate_state = d
[PATCHv5 0/3] Intel FPGA VIP Frame Buffer II drm driver
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 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 | 39 + arch/arm/configs/socfpga_defconfig | 6 + drivers/gpu/drm/Kconfig| 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/ivip/Kconfig | 13 ++ 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| 194 + 10 files changed, 574 insertions(+) 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 -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 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 | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig index 2620ce7..255f553 100644 --- a/arch/arm/configs/socfpga_defconfig +++ b/arch/arm/configs/socfpga_defconfig @@ -111,6 +111,12 @@ 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_FRAMEBUFFER_CONSOLE=m CONFIG_USB=y CONFIG_USB_STORAGE=y CONFIG_USB_DWC2=y -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v13 5/7] vfio: ABI for mdev display dma-buf operation
On Thu, 3 Aug 2017 03:17:09 +
"Zhang, Tina" wrote:
> > -Original Message-
> > From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> > Of
> > Alex Williamson
> > Sent: Wednesday, August 2, 2017 5:18 AM
> > To: Zhang, Tina
> > Cc: Tian, Kevin ; kra...@redhat.com; intel-
> > g...@lists.freedesktop.org; Wang, Zhi A ;
> > kwankh...@nvidia.com; dri-devel@lists.freedesktop.org; intel-gvt-
> > d...@lists.freedesktop.org; Lv, Zhiyuan
> > Subject: Re: [PATCH v13 5/7] vfio: ABI for mdev display dma-buf operation
> >
> > On Tue, 25 Jul 2017 17:28:18 +0800
> > Tina Zhang wrote:
> >
> > > Add VFIO_DEVICE_QUERY_GFX_PLANE ioctl command to let user mode query
> > > and get the plan and its related information.
> > >
> > > The dma-buf's life cycle is handled by user mode and tracked by kernel.
> > > The returned fd in struct vfio_device_query_gfx_plane can be a new fd
> > > or an old fd of a re-exported dma-buf. Host User mode can check the
> > > value of fd and to see if it needs to create new resource according to
> > > the new fd or just use the existed resource related to the old fd.
> > >
> > > Signed-off-by: Tina Zhang
> > > ---
> > > include/uapi/linux/vfio.h | 28
> > > 1 file changed, 28 insertions(+)
> > >
> > > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > > index ae46105..827a230 100644
> > > --- a/include/uapi/linux/vfio.h
> > > +++ b/include/uapi/linux/vfio.h
> > > @@ -502,6 +502,34 @@ struct vfio_pci_hot_reset {
> > >
> > > #define VFIO_DEVICE_PCI_HOT_RESET_IO(VFIO_TYPE, VFIO_BASE +
> > 13)
> > >
> > > +/**
> > > + * VFIO_DEVICE_QUERY_GFX_PLANE - _IOW(VFIO_TYPE, VFIO_BASE + 14,
> > > +struct vfio_device_query_gfx_plane)
> > > + *
> > > + * Set the drm_plane_type and retrieve information about the gfx plane.
> > > + *
> > > + * Return: 0 on success, -errno on failure.
> > > + */
> > > +struct vfio_device_gfx_plane_info {
> > > + __u32 argsz;
> > > + __u32 flags;
> > > + /* in */
> > > + __u32 drm_plane_type; /* type of plane: DRM_PLANE_TYPE_* */
> > > + /* out */
> > > + __u32 drm_format; /* drm format of plane */
> > > + __u64 drm_format_mod; /* tiled mode */
> > > + __u32 width;/* width of plane */
> > > + __u32 height; /* height of plane */
> > > + __u32 stride; /* stride of plane */
> > > + __u32 size; /* size of plane in bytes, align on page*/
> > > + __u32 x_pos;/* horizontal position of cursor plane, upper left
> > > corner
> > in pixels */
> > > + __u32 y_pos;/* vertical position of cursor plane, upper left corner
> > > in
> > lines*/
> > > + __u32 region_index;
> > > + __s32 fd; /* dma-buf fd */
> >
> > How do I know which of these is valid, region_index or fd? Can I ask for
> > one vs
> > the other? What are the errno values to differentiate unsupported vs not
> > initialized? Is there a "probe" flag that I can use to determine what the
> > device
> > supports without allocating those resources yet?
> Dma-buf won't use region_index, which means region_index is zero all the time
> for dma-buf usage.
> As we discussed, there won't be errno if not initialized, just keep all
> fields zero.
> I will add the comments about these in the next version. Thanks
Zero is a valid region index.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102008] DRI_PRIME causes X Error of failed request: BadAlloc (insufficient resources for operation)
https://bugs.freedesktop.org/show_bug.cgi?id=102008 --- Comment #4 from MWATTT --- I also have this problem to with my laptop (Intel Skylake iGPU + AMD TOPAZ dGPU) The issue is only with opengl, radv works fine. The BadAlloc only happens with some window sizes. It can be easily tested with glxgears. For instance, there is no problem with 1600x900 or default size, 300x300. With this height (300), I can resize the width between 257 and 448 without hitting a BadAlloc. With a width of 192, I have no problem with the following heights: 123, 124, 129, 123, 131, 132, 134, 135, 136, 139, 140, 145, 146, 147, 148, 150, 151, 152, 155, 156, 161 I have a BadAlloc with those heights: 125, 126, 127, 128, 133, 137, 138, 141, 142, 143, 144, 149, 153, 154, 157, 158, 159, 160 -- 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 v13 5/7] vfio: ABI for mdev display dma-buf operation
> -Original Message-
> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
> Alex Williamson
> Sent: Wednesday, August 2, 2017 5:18 AM
> To: Zhang, Tina
> Cc: Tian, Kevin ; kra...@redhat.com; intel-
> g...@lists.freedesktop.org; Wang, Zhi A ;
> kwankh...@nvidia.com; dri-devel@lists.freedesktop.org; intel-gvt-
> d...@lists.freedesktop.org; Lv, Zhiyuan
> Subject: Re: [PATCH v13 5/7] vfio: ABI for mdev display dma-buf operation
>
> On Tue, 25 Jul 2017 17:28:18 +0800
> Tina Zhang wrote:
>
> > Add VFIO_DEVICE_QUERY_GFX_PLANE ioctl command to let user mode query
> > and get the plan and its related information.
> >
> > The dma-buf's life cycle is handled by user mode and tracked by kernel.
> > The returned fd in struct vfio_device_query_gfx_plane can be a new fd
> > or an old fd of a re-exported dma-buf. Host User mode can check the
> > value of fd and to see if it needs to create new resource according to
> > the new fd or just use the existed resource related to the old fd.
> >
> > Signed-off-by: Tina Zhang
> > ---
> > include/uapi/linux/vfio.h | 28
> > 1 file changed, 28 insertions(+)
> >
> > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > index ae46105..827a230 100644
> > --- a/include/uapi/linux/vfio.h
> > +++ b/include/uapi/linux/vfio.h
> > @@ -502,6 +502,34 @@ struct vfio_pci_hot_reset {
> >
> > #define VFIO_DEVICE_PCI_HOT_RESET _IO(VFIO_TYPE, VFIO_BASE +
> 13)
> >
> > +/**
> > + * VFIO_DEVICE_QUERY_GFX_PLANE - _IOW(VFIO_TYPE, VFIO_BASE + 14,
> > +struct vfio_device_query_gfx_plane)
> > + *
> > + * Set the drm_plane_type and retrieve information about the gfx plane.
> > + *
> > + * Return: 0 on success, -errno on failure.
> > + */
> > +struct vfio_device_gfx_plane_info {
> > + __u32 argsz;
> > + __u32 flags;
> > + /* in */
> > + __u32 drm_plane_type; /* type of plane: DRM_PLANE_TYPE_* */
> > + /* out */
> > + __u32 drm_format; /* drm format of plane */
> > + __u64 drm_format_mod; /* tiled mode */
> > + __u32 width;/* width of plane */
> > + __u32 height; /* height of plane */
> > + __u32 stride; /* stride of plane */
> > + __u32 size; /* size of plane in bytes, align on page*/
> > + __u32 x_pos;/* horizontal position of cursor plane, upper left
> > corner
> in pixels */
> > + __u32 y_pos;/* vertical position of cursor plane, upper left corner
> > in
> lines*/
> > + __u32 region_index;
> > + __s32 fd; /* dma-buf fd */
>
> How do I know which of these is valid, region_index or fd? Can I ask for one
> vs
> the other? What are the errno values to differentiate unsupported vs not
> initialized? Is there a "probe" flag that I can use to determine what the
> device
> supports without allocating those resources yet?
Dma-buf won't use region_index, which means region_index is zero all the time
for dma-buf usage.
As we discussed, there won't be errno if not initialized, just keep all fields
zero.
I will add the comments about these in the next version. Thanks
Tina
>
> Kirti, does this otherwise meet your needs?
>
> Thanks,
> Alex
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101976] glmark2 random blank or background only screen freeze over mesa3d 17.1 and 17.3 with radeon rx550 AMD POLARIS12
https://bugs.freedesktop.org/show_bug.cgi?id=101976 --- Comment #6 from Pablo Estigarribia --- I forgot to add info for newcomers: You can also put these vars in cat /etc/environment to avoid the issues happening for other applications. -- 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 101976] glmark2 random blank or background only screen freeze over mesa3d 17.1 and 17.3 with radeon rx550 AMD POLARIS12
https://bugs.freedesktop.org/show_bug.cgi?id=101976 --- Comment #5 from Pablo Estigarribia --- After reading many many many pages around the web and trying everything I could try I have got some config that doesn't crash with white/blank screen or background screen. command tested: MESA_GL_VERSION_OVERRIDE=2.1 MESA_GLES_VERSION_OVERRIDE=2.0 MESA_NO_ERROR=1 MESA_EXTENSION_MAX_YEAR=2014 glmark2 Looks like there is no guide for people new in debugging mesa3d, so I had to spend lot of time looking on the web and trying to get tips to know what I can try here. debugging tips doesn't helps for newcomers to mesa3d debuggin: https://www.mesa3d.org/debugging.html First tried with some vars shown in: https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa I was also looking in the information shown here: https://www.x.org/wiki/RadeonFeature/#index12h2 Then finally used first test with: https://www.mesa3d.org/envvars.html I have put the first command I tried, but still don't know what should I really use. Probably the issue is with MESA_GL or MESA_GLES not fully implemented for the version automatically recognized for the driver (from glxinfo not using the vars to force the version): Max core profile version: 4.5 Max compat profile version: 3.0 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.1 Is there any documentation that could help me assign the bug-free GL version should I use? I will be trying different versions until get the bigger and will comment again. I got blank screen also watching youtube videos, it seems to be some random bug that I couldn't identify yet but hope this information could help some other more familiar with mesa3d could. -- 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] drm/fb-helper: pass physical dimensions to fbdev
On 08/02/2017 06:28 PM, Daniel Vetter wrote: On Wed, Aug 2, 2017 at 6:37 PM, David Lechner wrote: On 08/02/2017 04:46 AM, Daniel Vetter wrote: On Tue, Aug 01, 2017 at 10:26:41AM -0500, David Lechner wrote: The fbdev subsystem has a place for physical dimensions (width and height in mm) that is readable by userspace. Since DRM also knows these dimensions, pass this information to the fbdev device. Signed-off-by: David Lechner Still in the wrong function. Also please add some notation about what you changed when resubmitting a patch (it took me a while to remember that I replied to you already). That makes patch reviewing more efficient. Sorry for being so dense. :-/ I did read your first reply at least 10 times. All of the terminology is foreign to me, but after sleeping on it a few days, I think it is slowly soaking into my brain. No problem, the code is fairly convoluted. One more question on your v3: From reading fbdev code I don't see any place that overwrites the physical dimensions except the fill_var helper function (which is called deep down from register_framebuffer). If we entirely remove the var.width/height assignments from that (including the -1 default) and move all of it into setup_crtcs, would that work? I tried that, but in my case, drm_setup_crtcs() is only called once before the fbdev is allocated. So, I got a kernel oops from dereferencing a null pointer, which is why there is a null check for fb_helper->fbdev as part of the if statement I added there. Since drm_setup_crtcs() is not called again, the var.width and height are never set. I also noticed that there is another similar workaround/code duplication for the framebuffer not being allocated in the first call to drm_setup_crtcs() seen at the end of drm_fb_helper_single_fb_probe(). I kinda don't like have the same logic in 2 completely different places, once for driver load and once for hotplug handling. That tends to cause bugs (because then no one bothers to test hotplug handling or the boot-up case properly). Would it be possible to split drm_setup_crtcs() into two functions, a top half and a bottom half. During init (pseudo-code)... drm_begin_setup_crtcs() drm_fb_helper_single_fb_probe() drm_finish_setup_crtcs() and during hotplug event, just... drm_begin_setup_crtcs() drm_finish_crtcs_bottom_half() I think it could solve both cases. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] selftests: sync: add test that closes the fd before fence signal
Hi Shuah,
On Wed, 2017-08-02 at 13:45 -0600, Shuah Khan wrote:
> On 07/31/2017 01:43 PM, Gustavo Padovan wrote:
> > 2017-07-30 Chris Wilson :
> >
> > > Quoting Gustavo Padovan (2017-07-29 16:22:17)
> > > > From: Gustavo Padovan
> > > >
> > > > We found this bug in the sw_sync so adding a test case to
> > > > prevent it to
> > > > happen in the future.
> > > >
> > > > Cc: Shuah Khan
> > > > Cc: linux-kselft...@vger.kernel.org
> > > > Signed-off-by: Gustavo Padovan
> > > >
> > > > ---
> > > > To be applied after the TAP13 convertion patches.
> > > > ---
> > > > tools/testing/selftests/sync/sync_fence.c | 23
> > > > +++
> > > > tools/testing/selftests/sync/sync_test.c | 1 +
> > > > tools/testing/selftests/sync/synctest.h | 1 +
> > > > 3 files changed, 25 insertions(+)
> > > >
> > > > diff --git a/tools/testing/selftests/sync/sync_fence.c
> > > > b/tools/testing/selftests/sync/sync_fence.c
> > > > index 13f1752..70cfa61 100644
> > > > --- a/tools/testing/selftests/sync/sync_fence.c
> > > > +++ b/tools/testing/selftests/sync/sync_fence.c
> > > > @@ -29,6 +29,29 @@
> > > > #include "sw_sync.h"
> > > > #include "synctest.h"
> > > >
> > > > +int test_close_fence_fd_before_inc(void)
> > > > +{
> > > > + int fence, valid, ret;
> > > > + int timeline = sw_sync_timeline_create();
> > > > +
> > > > + valid = sw_sync_timeline_is_valid(timeline);
> > > > + ASSERT(valid, "Failure allocating timeline\n");
> > > > +
> > > > + fence = sw_sync_fence_create(timeline, "allocFence",
> > > > 1);
> > > > + valid = sw_sync_fence_is_valid(fence);
> > > > + ASSERT(valid, "Failure allocating fence\n");
> > > > +
> > >
> > > /*
> > > * We want the destroy + inc to run within the same RCU grace
> > > period so
> > > * that the zombie fence still exists on the timeline.
> > > */
> > >
> > > > + sw_sync_fence_destroy(fence);
> > >
> > > I think this doesn't exercise the bug you found as we should be
> > > entering
> > > the timeline_inc loop with fence.refcount==0 rather than the
> > > refcount
> > > going to zero within the loop.
> > >
> > > To achieve that we need to find a callback that does unreference
> > > a
> > > dma-fence and chain those together so that it frees a sw_sync
> > > from the
> > > same timeline.
> >
> > Indeed. Without the internal callback this test is a bit useless.
> > We
> > could test this under drm atomic tests on IGT. Particulary, I hit
> > it
> > playing with tests for v4l2 fences.
> >
>
> Hi Gustavo,
>
> Would you like this pulled into 4.14-rc1? Sounds like this test is
> for a
> feature that doesn't exist yet?
It is for the current code, but I need to find a better way to trigger
what I want. I'll rethink this test and resend.
Gustavo
--
Gustavo Padovan
Collabora Ltd.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH for v4.13] ARM: dts: exynos: add needs-hpd for Odroid-XU3/4
On Mon, Jul 31, 2017 at 01:56:42PM +0200, Hans Verkuil wrote: > CEC support was added for Exynos5 in 4.13, but for the Odroids we need to set > 'needs-hpd' as well since CEC is disabled when there is no HDMI hotplug > signal, > just as for the exynos4 Odroid-U3. > > This is due to the level-shifter that is disabled when there is no HPD, thus > blocking the CEC signal as well. Same close-but-no-cigar board design as the > Odroid-U3. > > Tested with my Odroid XU4. > > Signed-off-by: Hans Verkuil Thanks, applied for v4.13. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] Please pull ARCPGU changes
Hi Dave, Could you please pull a couple of minor fixes and improvements for ARCPGU. These changes are based on today's drm-next branch. The following changes since commit dd24df657075fdf1e850612ea50634816f3c3581: Merge branch 'drm-next-4.14' of git://people.freedesktop.org/~agd5f/linux into drm-next (2017-08-02 12:43:12 +1000) are available in the git repository at: https://github.com/foss-for-synopsys-dwc-arc-processors/linux topic-arcpgu-updates for you to fetch changes up to 22d0be2a557e53a22feb484e8fce255fe09e6ad5: drm: arcpgu: Allow some clock deviation in crtc->mode_valid() callback (2017-08-03 00:11:02 +0300) Alexey Brodkin (2): drm/arcpgu: Opt in debugfs arcpgu: Simplify driver name Jose Abreu (3): drm: arcpgu: Fix mmap() callback drm: arcpgu: Fix module unload drm: arcpgu: Allow some clock deviation in crtc->mode_valid() callback drivers/gpu/drm/arc/arcpgu_crtc.c | 7 --- drivers/gpu/drm/arc/arcpgu_drv.c | 57 - 2 files changed, 36 insertions(+), 28 deletions(-) Regards, Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/bridge: dw-hdmi: add cec driver
On Wed, Aug 02, 2017 at 05:22:54PM +0300, Laurent Pinchart wrote: > Then it should be even simpler. Instead of creating a separate platform > device > for the DW HDMI CEC, we can just call the DW HDMI CEC driver init/cleanup > functions directly when the IP core implements CEC. When it doesn't, a > separate device will be described in DT (at least to my understanding, > otherwise where would it come from ?) and a separate driver would handle it. Let me put this plainly, because my previous message seems not to have the desired effect. I am not changing this driver again until it is merged. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] selftests: sync: add test that closes the fd before fence signal
On 07/31/2017 01:43 PM, Gustavo Padovan wrote:
> 2017-07-30 Chris Wilson :
>
>> Quoting Gustavo Padovan (2017-07-29 16:22:17)
>>> From: Gustavo Padovan
>>>
>>> We found this bug in the sw_sync so adding a test case to prevent it to
>>> happen in the future.
>>>
>>> Cc: Shuah Khan
>>> Cc: linux-kselft...@vger.kernel.org
>>> Signed-off-by: Gustavo Padovan
>>>
>>> ---
>>> To be applied after the TAP13 convertion patches.
>>> ---
>>> tools/testing/selftests/sync/sync_fence.c | 23 +++
>>> tools/testing/selftests/sync/sync_test.c | 1 +
>>> tools/testing/selftests/sync/synctest.h | 1 +
>>> 3 files changed, 25 insertions(+)
>>>
>>> diff --git a/tools/testing/selftests/sync/sync_fence.c
>>> b/tools/testing/selftests/sync/sync_fence.c
>>> index 13f1752..70cfa61 100644
>>> --- a/tools/testing/selftests/sync/sync_fence.c
>>> +++ b/tools/testing/selftests/sync/sync_fence.c
>>> @@ -29,6 +29,29 @@
>>> #include "sw_sync.h"
>>> #include "synctest.h"
>>>
>>> +int test_close_fence_fd_before_inc(void)
>>> +{
>>> + int fence, valid, ret;
>>> + int timeline = sw_sync_timeline_create();
>>> +
>>> + valid = sw_sync_timeline_is_valid(timeline);
>>> + ASSERT(valid, "Failure allocating timeline\n");
>>> +
>>> + fence = sw_sync_fence_create(timeline, "allocFence", 1);
>>> + valid = sw_sync_fence_is_valid(fence);
>>> + ASSERT(valid, "Failure allocating fence\n");
>>> +
>>
>> /*
>> * We want the destroy + inc to run within the same RCU grace period so
>> * that the zombie fence still exists on the timeline.
>> */
>>
>>> + sw_sync_fence_destroy(fence);
>>
>> I think this doesn't exercise the bug you found as we should be entering
>> the timeline_inc loop with fence.refcount==0 rather than the refcount
>> going to zero within the loop.
>>
>> To achieve that we need to find a callback that does unreference a
>> dma-fence and chain those together so that it frees a sw_sync from the
>> same timeline.
>
> Indeed. Without the internal callback this test is a bit useless. We
> could test this under drm atomic tests on IGT. Particulary, I hit it
> playing with tests for v4l2 fences.
>
Hi Gustavo,
Would you like this pulled into 4.14-rc1? Sounds like this test is for a
feature that doesn't exist yet?
thanks,
-- Shuah
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 01/13] dt-bindings: update the binding for Allwinner H3 DE2 support
于 2017年8月3日 GMT+08:00 上午3:06:26, "Jernej Škrabec" 写到: >Hi, > >Dne sreda, 02. avgust 2017 ob 07:02:39 CEST je icen...@aosc.io >napisal(a): >> 在 2017-08-02 12:53，Jernej Škrabec 写道： >> >> > Hi Icenowy, >> > >> > Dne torek, 01. avgust 2017 ob 15:12:52 CEST je Icenowy Zheng >> > >> > napisal(a): >> >> Allwinner H3 features a "Display Engine 2.0". >> >> >> >> Add device tree bindings for the following parts: >> >> - H3 TCONs >> >> - H3 Mixers >> >> - H3 Display engine >> >> >> >> Signed-off-by: Icenowy Zheng >> >> --- >> >> >> >> .../bindings/display/sunxi/sun4i-drm.txt | 25 >> >> >> >> ++ 1 file changed, 21 insertions(+), 4 >> >> deletions(-) >> >> >> >> diff --git >> >> a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt >> >> b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt >index >> >> 2ee6ff0ef98e..92512953943e 100644 >> >> --- >a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt >> >> +++ >b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt >> >> >> >> @@ -87,18 +87,17 @@ Required properties: >> >> * allwinner,sun6i-a31-tcon >> >> * allwinner,sun6i-a31s-tcon >> >> * allwinner,sun8i-a33-tcon >> >> >> >> + * allwinner,sun8i-h3-tcon >> >> >> >> * allwinner,sun8i-v3s-tcon >> >> >> >> - reg: base address and size of memory-mapped region >> >> - interrupts: interrupt associated to this IP >> >> >> >> - clocks: phandles to the clocks feeding the TCON. Three are >needed: >> >> - 'ahb': the interface clocks >> >> >> >> - - 'tcon-ch0': The clock driving the TCON channel 0 >> >> >> >> - resets: phandles to the reset controllers driving the encoder >> >> >> >> - "lcd": the reset line for the TCON channel 0 >> >> >> >> - clock-names: the clock names mentioned above >> >> - reset-names: the reset names mentioned above >> >> >> >> - - clock-output-names: Name of the pixel clock created >> >> >> >> - ports: A ports node with endpoint definitions as defined in >> >> >> >>Documentation/devicetree/bindings/media/video-interfaces.txt. >The >> >> >> >> @@ -112,7 +111,23 @@ Required properties: >> >>channel the endpoint is associated to. If that property is not >> >>present, the endpoint number will be used as the channel >number. >> >> >> >> -On SoCs other than the A33 and V3s, there is one more clock >required: >> >> +For the following compatibles: >> >> + * allwinner,sun5i-a13-tcon >> >> + * allwinner,sun6i-a31-tcon >> >> + * allwinner,sun6i-a31s-tcon >> >> + * allwinner,sun8i-a33-tcon >> >> + * allwinner,sun8i-v3s-tcon >> >> +there is one more clock and one more property required: >> >> + - clocks: >> >> + - 'tcon-ch0': The clock driving the TCON channel 0 >> >> + - clock-output-names: Name of the pixel clock created >> >> + >> >> +For the following compatibles: >> >> + * allwinner,sun5i-a13-tcon >> >> + * allwinner,sun6i-a31-tcon >> >> + * allwinner,sun6i-a31s-tcon >> >> + * allwinner,sun8i-h3-tcon >> >> >> >> +there is one more clock required: >> >> - 'tcon-ch1': The clock driving the TCON channel 1 >> >> >> >> DRC >> >> >> >> @@ -207,6 +222,8 @@ supported. >> >> >> >> Required properties: >> >>- compatible: value must be one of: >> >> * allwinner,sun8i-v3s-de2-mixer >> >> >> >> +* allwinner,sun8i-h3-de2-mixer0 >> >> +* allwinner,sun8i-h3-de2-mixer1 >> > >> > About that, I concur with Maxime here, plane number properties >would be >> > better. If we don't do this now, we will never have it. >> >> But I still prefer different compatibles, as the capabilities are >> already >> proven to be different between mixer0 and mixer1, and furtherly we >> cannot >> promise Allwinner won't add more functions only available at mixer0. >> >> Then we will be trapped into a situation that we describe more and >more >> functions via properties, but they should be encoded into the >> compatible. > >It is either multiple compatibles or multiple properties. I prefer the >later, >but it is up to maintainers to decide. > >Anyway, I think DE2 will not evolve much since DE3 is almost ready >(H6). At >least basics seems to be similar according to a BSP code drop. According to what I heard from TL Lim, DE3 is just an evolution to DE2. > >Regards, >Jernej > >> >> > Reference: >> > >http://lists.infradead.org/pipermail/linux-arm-kernel/2017-June/512902.htm >> > l >> > >> > Regards, >> > Jernej >> >> -- >> You received this message because you are subscribed to the Google >Groups >> "linux-sunxi" group. To unsubscribe from this group and stop >receiving >> emails from it, send an email to >linux-sunxi+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Please pull ARCPGU changes
Hi Alex, On Wed, 2017-08-02 at 14:24 -0400, Alex Deucher wrote: > On Wed, Aug 2, 2017 at 6:16 AM, Alexey Brodkin > wrote: > > > > Hi Daniel, > > > > On Wed, 2017-08-02 at 11:41 +0200, Daniel Vetter wrote: > > > > > > On Mon, Jul 31, 2017 at 11:11:06AM +, Alexey Brodkin wrote: > > > > > > > > > > > > Hi Dave, > > > > > > > > Could you please pull a couple of minor fixes for ARCPGU. > > > > These changes are based on today's drm-misc/drm-misc-next. > > > > > > You can't send Dave a pull based on a random snapshot of drm-misc-next. If > > > you want to maintain your driver on top of drm-misc, then become part of > > > the group (arcgpu would fit imo). Otherwise you need to base your pulls on > > > top of Dave's tree. > > > > I don't have any specific requirement for "drm-misc-next" to b used as a > > base. > > That said Dave trees are OK for me. Still could you please point me to > > his "for-curr" and "for-next" (or equivalent) trees? > > next: > https://urldefense.proofpoint.com/v2/url?u=https-3A__cgit.freedesktop.org_-7Eairlied_linux_log_-3Fh-3Ddrm-2Dnext&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r > =lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=pbG-5bjYHB5-5W7BvTn5O7AaB-7boN5rb88XcxgLT5s&s=WrBr72Zx251yCmFMiv7mH7uKt5omhSWk8vlr0GDvG60&e= > > > fixes: > https://urldefense.proofpoint.com/v2/url?u=https-3A__cgit.freedesktop.org_-7Eairlied_linux_log_-3Fh-3Ddrm-2Dfixes&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&; > r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=pbG-5bjYHB5-5W7BvTn5O7AaB-7boN5rb88XcxgLT5s&s=iRx0mpfiNcQURDcMGyXfb9arq0OQsCnMddGvXDVk7Zg&e= > I added this repo as a remote and sent new pull-request based on drm-next. Thanks a lot for your help. -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 01/13] dt-bindings: update the binding for Allwinner H3 DE2 support
Hi, Dne sreda, 02. avgust 2017 ob 07:02:39 CEST je icen...@aosc.io napisal(a): > 在 2017-08-02 12:53，Jernej Škrabec 写道： > > > Hi Icenowy, > > > > Dne torek, 01. avgust 2017 ob 15:12:52 CEST je Icenowy Zheng > > > > napisal(a): > >> Allwinner H3 features a "Display Engine 2.0". > >> > >> Add device tree bindings for the following parts: > >> - H3 TCONs > >> - H3 Mixers > >> - H3 Display engine > >> > >> Signed-off-by: Icenowy Zheng > >> --- > >> > >> .../bindings/display/sunxi/sun4i-drm.txt | 25 > >> > >> ++ 1 file changed, 21 insertions(+), 4 > >> deletions(-) > >> > >> diff --git > >> a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > >> b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index > >> 2ee6ff0ef98e..92512953943e 100644 > >> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > >> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > >> > >> @@ -87,18 +87,17 @@ Required properties: > >> * allwinner,sun6i-a31-tcon > >> * allwinner,sun6i-a31s-tcon > >> * allwinner,sun8i-a33-tcon > >> > >> + * allwinner,sun8i-h3-tcon > >> > >> * allwinner,sun8i-v3s-tcon > >> > >> - reg: base address and size of memory-mapped region > >> - interrupts: interrupt associated to this IP > >> > >> - clocks: phandles to the clocks feeding the TCON. Three are needed: > >> - 'ahb': the interface clocks > >> > >> - - 'tcon-ch0': The clock driving the TCON channel 0 > >> > >> - resets: phandles to the reset controllers driving the encoder > >> > >> - "lcd": the reset line for the TCON channel 0 > >> > >> - clock-names: the clock names mentioned above > >> - reset-names: the reset names mentioned above > >> > >> - - clock-output-names: Name of the pixel clock created > >> > >> - ports: A ports node with endpoint definitions as defined in > >> > >>Documentation/devicetree/bindings/media/video-interfaces.txt. The > >> > >> @@ -112,7 +111,23 @@ Required properties: > >>channel the endpoint is associated to. If that property is not > >>present, the endpoint number will be used as the channel number. > >> > >> -On SoCs other than the A33 and V3s, there is one more clock required: > >> +For the following compatibles: > >> + * allwinner,sun5i-a13-tcon > >> + * allwinner,sun6i-a31-tcon > >> + * allwinner,sun6i-a31s-tcon > >> + * allwinner,sun8i-a33-tcon > >> + * allwinner,sun8i-v3s-tcon > >> +there is one more clock and one more property required: > >> + - clocks: > >> + - 'tcon-ch0': The clock driving the TCON channel 0 > >> + - clock-output-names: Name of the pixel clock created > >> + > >> +For the following compatibles: > >> + * allwinner,sun5i-a13-tcon > >> + * allwinner,sun6i-a31-tcon > >> + * allwinner,sun6i-a31s-tcon > >> + * allwinner,sun8i-h3-tcon > >> > >> +there is one more clock required: > >> - 'tcon-ch1': The clock driving the TCON channel 1 > >> > >> DRC > >> > >> @@ -207,6 +222,8 @@ supported. > >> > >> Required properties: > >>- compatible: value must be one of: > >> * allwinner,sun8i-v3s-de2-mixer > >> > >> +* allwinner,sun8i-h3-de2-mixer0 > >> +* allwinner,sun8i-h3-de2-mixer1 > > > > About that, I concur with Maxime here, plane number properties would be > > better. If we don't do this now, we will never have it. > > But I still prefer different compatibles, as the capabilities are > already > proven to be different between mixer0 and mixer1, and furtherly we > cannot > promise Allwinner won't add more functions only available at mixer0. > > Then we will be trapped into a situation that we describe more and more > functions via properties, but they should be encoded into the > compatible. It is either multiple compatibles or multiple properties. I prefer the later, but it is up to maintainers to decide. Anyway, I think DE2 will not evolve much since DE3 is almost ready (H6). At least basics seems to be similar according to a BSP code drop. Regards, Jernej > > > Reference: > > http://lists.infradead.org/pipermail/linux-arm-kernel/2017-June/512902.htm > > l > > > > Regards, > > Jernej > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. To unsubscribe from this group and stop receiving > emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/4] drm/bridge: dw-hdmi: add cec notifier support
On Wed, Aug 02, 2017 at 04:17:15PM +0200, Hans Verkuil wrote: > Yes, you should. Well spotted, I missed that one. Great, another respin. I give up. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102008] DRI_PRIME causes X Error of failed request: BadAlloc (insufficient resources for operation)
https://bugs.freedesktop.org/show_bug.cgi?id=102008 Mike Lothian changed: What|Removed |Added CC||m...@fireburn.co.uk --- Comment #3 from Mike Lothian --- I've been seeing this too, out of interest Bartos do 32bit apps render correctly with DRI_PRIME I've been getting a black screen? -- 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 102014] Mesa git build broken by commit bc7f41e11d325280db12e7b9444501357bc13922
https://bugs.freedesktop.org/show_bug.cgi?id=102014 Vinson Lee changed: What|Removed |Added Keywords||bisected, regression -- 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] drm/fb-helper: pass physical dimensions to fbdev
On Wed, Aug 2, 2017 at 6:37 PM, David Lechner wrote: > On 08/02/2017 04:46 AM, Daniel Vetter wrote: >> >> On Tue, Aug 01, 2017 at 10:26:41AM -0500, David Lechner wrote: >>> >>> The fbdev subsystem has a place for physical dimensions (width and height >>> in mm) that is readable by userspace. Since DRM also knows these >>> dimensions, pass this information to the fbdev device. >>> >>> Signed-off-by: David Lechner >> >> >> Still in the wrong function. Also please add some notation about what you >> changed when resubmitting a patch (it took me a while to remember that I >> replied to you already). That makes patch reviewing more efficient. >> > > Sorry for being so dense. :-/ > > I did read your first reply at least 10 times. All of the terminology is > foreign to me, but after sleeping on it a few days, I think it is slowly > soaking into my brain. No problem, the code is fairly convoluted. One more question on your v3: From reading fbdev code I don't see any place that overwrites the physical dimensions except the fill_var helper function (which is called deep down from register_framebuffer). If we entirely remove the var.width/height assignments from that (including the -1 default) and move all of it into setup_crtcs, would that work? I kinda don't like have the same logic in 2 completely different places, once for driver load and once for hotplug handling. That tends to cause bugs (because then no one bothers to test hotplug handling or the boot-up case properly). Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101977] UE4 4.17 causes Assertion `G_0286CC_LINEAR_CENTER_ENA(shader->config.spi_ps_input_addr)' failed
https://bugs.freedesktop.org/show_bug.cgi?id=101977 --- Comment #2 from Timothee Besset --- hakzsam on irc was able to reproduce the issue on his system. also to note, hakzam uses a different LLVM version than I do. problem does not reproduce with nouveau driver, only radeonsi ran with MESA_GLSL=dump R600_DEBUG=ps,vs,tcs,tes,cs,gs to extract more information: https://gist.github.com/TTimo/4f08718e1c5d9de003d617e3f0daea2a after debugging some more, to the best of my understanding, the assertion happens against the config of 'shader 3' (https://gist.github.com/TTimo/4f08718e1c5d9de003d617e3f0daea2a#file-gistfile1-txt-L411) -- 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 3/4] drm: Only lastclose on unload for legacy drivers
On Wed, Aug 2, 2017 at 10:50 PM, Alex Deucher wrote:
> On Wed, Aug 2, 2017 at 7:56 AM, Daniel Vetter wrote:
>> The only thing modern drivers are supposed to do in lastclose is
>> restore the fb emulation state. Which is entirely optional, and
>> there's really no reason to do that. So restrict it to legacy drivers
>> (where the driver cleanup essentially happens in lastclose).
>
> vga_switcheroo_process_delayed_switch() gets called in lastclose.
> Won't that need to get moved elsewhere for this to work?
Hm right, I forgot the lazy way to do runtime pm by keeping the device
alive as long as anyone has an open fd for it ... This shouldn't be a
problem, since you need to unregister from vgaswitcheroo anyway on
unload. Maybe that blows up, I'll check the code and augment the patch
as needed.
-Daniel
>
> Alex
>
>>
>> This will also allow us to share the unregister function with
>> drm_dev_unplug().
>>
>> Signed-off-by: Daniel Vetter
>> ---
>> drivers/gpu/drm/drm_drv.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> index 39191e5c240e..694040a240af 100644
>> --- a/drivers/gpu/drm/drm_drv.c
>> +++ b/drivers/gpu/drm/drm_drv.c
>> @@ -860,7 +860,8 @@ void drm_dev_unregister(struct drm_device *dev)
>> {
>> struct drm_map_list *r_list, *list_temp;
>>
>> - drm_lastclose(dev);
>> + if (drm_core_check_feature(dev, DRIVER_LEGACY))
>> + drm_lastclose(dev);
>>
>> dev->registered = false;
>>
>> --
>> 2.13.3
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 96296] clpeak causes a GPU hang
https://bugs.freedesktop.org/show_bug.cgi?id=96296 Jan Vesely changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #10 from Jan Vesely --- turns out I spoke too fast. The GPU still hangs, but Linux is better at recovering. There are still GPU hang(ring 0 stalled for more than) messages in dmesg. -- 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 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Bug 99553 depends on bug 96296, which changed state. Bug 96296 Summary: clpeak causes a GPU hang https://bugs.freedesktop.org/show_bug.cgi?id=96296 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- -- 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 101977] UE4 4.17 causes Assertion `G_0286CC_LINEAR_CENTER_ENA(shader->config.spi_ps_input_addr)' failed
https://bugs.freedesktop.org/show_bug.cgi?id=101977 Timothee Besset changed: What|Removed |Added Summary|UE4 4.17 causes hang in |UE4 4.17 causes Assertion |amdgpu_cs_query_fence_statu |`G_0286CC_LINEAR_CENTER_ENA |s |(shader->config.spi_ps_inpu ||t_addr)' failed --- Comment #1 from Timothee Besset --- Default/release config drivers will cause a system hang. Debug drivers will cause an assert: si_shader.c:7417: _Bool si_shader_select_ps_parts(struct si_screen *, LLVMTargetMachineRef, struct si_shader *, struct pipe_debug_callback *): Assertion `G_0286CC_LINEAR_CENTER_ENA(shader->config.spi_ps_input_addr)' failed. -- 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
[pull] amdgpu drm-fixes-4.13
Hi Dave, Just a few small fixes for 4.13. The following changes since commit 517069ff6ec0971e0794ab97d4fcfa8b143746e4: Merge branch 'drm-fixes-4.13' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2017-07-27 08:49:48 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.13 for you to fetch changes up to 68c9793d63e02f0683fdbf5e82d148d72ed1dbe0: drm/amdgpu: Use list_del_init in amdgpu_mn_unregister (2017-08-02 14:29:58 -0400) Alex Deucher (1): drm/amdgpu: fix header on gfx9 clear state Felix Kuehling (1): drm/amdgpu: Use list_del_init in amdgpu_mn_unregister Jean Delvare (1): drm/amdgpu: Fix undue fallthroughs in golden registers initialization drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 2 +- drivers/gpu/drm/amd/amdgpu/clearstate_gfx9.h | 41 ++-- drivers/gpu/drm/amd/amdgpu/si.c | 2 ++ 3 files changed, 24 insertions(+), 21 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/6] drm/i915: Implement .get_format_info() hook for CCS
Drp... replied to an old patch.
The userspace mesa patches to produce Y_TILED_CCS surfaces have been
reviewed for a couple of weeks now. So long as kmscube counts as
userspace, I think this should be good to land.
Acked-by: Jason Ekstrand
On Tue, Aug 1, 2017 at 9:58 AM, Ben Widawsky wrote:
> From: Ville Syrjälä
>
> SKL+ display engine can scan out certain kinds of compressed surfaces
> produced by the render engine. This involved telling the display engine
> the location of the color control surfae (CCS) which describes which
> parts of the main surface are compressed and which are not. The location
> of CCS is provided by userspace as just another plane with its own offset.
>
> By providing our own format information for the CCS formats, we should
> be able to make framebuffer_check() do the right thing for the CCS
> surface as well.
>
> Note that we'll return the same format info for both Y and Yf tiled
> format as that's what happens with the non-CCS Y vs. Yf as well. If
> desired, we could potentially return a unique pointer for each
> pixel_format+tiling+ccs combination, in which case we immediately be
> able to tell if any of that stuff changed by just comparing the
> pointers. But that does sound a bit wasteful space wise.
>
> v2: Drop the 'dev' argument from the hook
> v3: Include the description of the CCS surface layout
> v4: Pretend CCS tiles are regular 128 byte wide Y tiles (Jason)
>
> Cc: Daniel Vetter
> Cc: Ben Widawsky
> Cc: Jason Ekstrand
> Reviewed-by: Ben Widawsky (v3)
> Signed-off-by: Ville Syrjä
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/drm_fourcc.c | 2 +-
> drivers/gpu/drm/i915/intel_display.c | 37 ++
> ++
> include/drm/drm_mode_config.h| 3 ++-
> include/uapi/drm/drm_fourcc.h| 3 +++
> 4 files changed, 43 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 9c0152df45ad..50da6180c495 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -222,7 +222,7 @@ drm_get_format_info(struct drm_device *dev,
> const struct drm_format_info *info = NULL;
>
> if (dev->mode_config.funcs->get_format_info)
> - info = dev->mode_config.funcs->get_format_info(mode_cmd);
> + info = dev->mode_config.funcs->get_format_info(dev,
> mode_cmd);
>
> if (!info)
> info = drm_format_info(mode_cmd->pixel_format);
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index e92fd14c06c7..6b00689ef6e0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2433,6 +2433,42 @@ static unsigned int
> intel_fb_modifier_to_tiling(uint64_t
> fb_modifier)
> }
> }
>
> +static const struct drm_format_info ccs_formats[] = {
> + { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2,
> .cpp = { 4, 1, }, .hsub = 16, .vsub = 8, },
> + { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2,
> .cpp = { 4, 1, }, .hsub = 16, .vsub = 8, },
> + { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2,
> .cpp = { 4, 1, }, .hsub = 16, .vsub = 8, },
> + { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2,
> .cpp = { 4, 1, }, .hsub = 16, .vsub = 8, },
> +};
> +
> +static const struct drm_format_info *
> +lookup_format_info(const struct drm_format_info formats[],
> + int num_formats, u32 format)
> +{
> + int i;
> +
> + for (i = 0; i < num_formats; i++) {
> + if (formats[i].format == format)
> + return &formats[i];
> + }
> +
> + return NULL;
> +}
> +
> +static const struct drm_format_info *
> +intel_get_format_info(struct drm_device *dev,
> + const struct drm_mode_fb_cmd2 *cmd)
> +{
> + switch (cmd->modifier[0]) {
> + case I915_FORMAT_MOD_Y_TILED_CCS:
> + case I915_FORMAT_MOD_Yf_TILED_CCS:
> + return lookup_format_info(ccs_formats,
> + ARRAY_SIZE(ccs_formats),
> + cmd->pixel_format);
> + default:
> + return NULL;
> + }
> +}
> +
> static int
> intel_fill_fb_info(struct drm_i915_private *dev_priv,
>struct drm_framebuffer *fb)
> @@ -14630,6 +14666,7 @@ static void intel_atomic_state_free(struct
> drm_atomic_state *state)
>
> static const struct drm_mode_config_funcs intel_mode_funcs = {
> .fb_create = intel_user_framebuffer_create,
> + .get_format_info = intel_get_format_info,
> .output_poll_changed = intel_fbdev_output_poll_changed,
> .atomic_check = intel_atomic_check,
> .atomic_commit = intel_atomic_commit,
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 42981711189b..f0d3d3857ae2 100644
> --- a/include/drm/drm_mode_
[Bug 102008] DRI_PRIME causes X Error of failed request: BadAlloc (insufficient resources for operation)
https://bugs.freedesktop.org/show_bug.cgi?id=102008 --- Comment #2 from bartos.p...@gmail.com --- So I have some partial results. First problem I've encoutered is that I had to use patch from https://bugs.freedesktop.org/show_bug.cgi?id=101774 in order to be able to build mesa between 7250cbafb90271579a1d07160498e902996cbc97 and 5ffe0c9e1be0257de1943135244419cbc86a6d84 so I hope it does not affect these results. Second problem I found is that problem is connected with using modesetting DDX drivers, and between working and non-working commits is some problem causing segfault with modesetting drivers (X do not start). So I have tested not only particular commits, but also DDX driver combinations: intel - IGPU, DRI3, SNA accel radeon - DGPU, DRI3, glamor accel modesetting - both, default settings So far I managed to find this (I have not finished bisecting yet, so these commits are ones I've found so far): f33d8af7aa354d00808f8bfd55028c396c706635 intel, radeon - OK intel, modesetting - OK modesetting, radeon - ERROR modesetting, modesetting - ERROR 81fb1547772d42c527318837d4207ecdb6899e5d intel, radeon - OK intel, modesetting - SEGFAULT modesetting, radeon - SEGFAULT modesetting, modesetting - SEGFAULT 3645268748c44825ce8d37bf03f684731eb2652a intel, radeon - OK intel, modesetting - SEGFAULT modesetting, radeon - SEGFAULT modesetting, modesetting - SEGFAULT 84ed8b67c56b323cd834d463151e1a3c0430c53e intel, radeon - OK intel, modesetting - OK modesetting, radeon - OK modesetting, modesetting - OK So it seems between somewhere between 84ed8b67c56b323cd834d463151e1a3c0430c53e and f33d8af7aa354d00808f8bfd55028c396c706635 (https://cgit.freedesktop.org/mesa/mesa/log/?qt=range&q=84ed8b67c56b323cd834d463151e1a3c0430c53e..f33d8af7aa354d00808f8bfd55028c396c706635) modesetting driver started to segfault which was fixed, but this fix probably also caused problem which I have reported. It also seems there is no problem when using only intel+radeon DDX drivers. -- 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/3] drm/vc4: Fix double destroy of the BO cache on teardown.
Den 02.08.2017 22.32, skrev Eric Anholt:
It's also destroyed from the top level vc4_drv.c initialization, which
is where the cache was actually initialized from.
This used to just involve duplicate del_timer() and cancel_work_sync()
being called, but it started causing kmalloc issues once we
double-freed the new BO label array.
Fixes: 1908a876f909 ("drm/vc4: Add an ioctl for labeling GEM BOs for summary
stats")
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_gem.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 209fccd0d3b4..892a031a3ced 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -1117,6 +1117,4 @@ vc4_gem_destroy(struct drm_device *dev)
if (vc4->hang_state)
vc4_free_hang_state(dev, vc4->hang_state);
-
- vc4_bo_cache_destroy(dev);
}
I don't have a display connected, but there's no crashing anymore.
Tested-by: Noralf Trønnes
Acked-by: Noralf Trønnes
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm: Only lastclose on unload for legacy drivers
On Wed, Aug 2, 2017 at 7:56 AM, Daniel Vetter wrote:
> The only thing modern drivers are supposed to do in lastclose is
> restore the fb emulation state. Which is entirely optional, and
> there's really no reason to do that. So restrict it to legacy drivers
> (where the driver cleanup essentially happens in lastclose).
vga_switcheroo_process_delayed_switch() gets called in lastclose.
Won't that need to get moved elsewhere for this to work?
Alex
>
> This will also allow us to share the unregister function with
> drm_dev_unplug().
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_drv.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 39191e5c240e..694040a240af 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -860,7 +860,8 @@ void drm_dev_unregister(struct drm_device *dev)
> {
> struct drm_map_list *r_list, *list_temp;
>
> - drm_lastclose(dev);
> + if (drm_core_check_feature(dev, DRIVER_LEGACY))
> + drm_lastclose(dev);
>
> dev->registered = false;
>
> --
> 2.13.3
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/vc4: Fix double destroy of the BO cache on teardown.
It's also destroyed from the top level vc4_drv.c initialization, which
is where the cache was actually initialized from.
This used to just involve duplicate del_timer() and cancel_work_sync()
being called, but it started causing kmalloc issues once we
double-freed the new BO label array.
Fixes: 1908a876f909 ("drm/vc4: Add an ioctl for labeling GEM BOs for summary
stats")
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_gem.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 209fccd0d3b4..892a031a3ced 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -1117,6 +1117,4 @@ vc4_gem_destroy(struct drm_device *dev)
if (vc4->hang_state)
vc4_free_hang_state(dev, vc4->hang_state);
-
- vc4_bo_cache_destroy(dev);
}
--
2.13.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/vc4: Fix errant drm_bridge_remove() in DSI.
drm_bridge_remove() is for unregistering a bridge driver, not for
detaching a bridge from its consumer.
Fixes: 656fa22f9cea ("drm/vc4: Switch DSI to the panel-bridge layer, and
support bridges.")
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_dsi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index 13481bb6322f..d1e0dc908048 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -1636,7 +1636,6 @@ static void vc4_dsi_unbind(struct device *dev, struct
device *master,
pm_runtime_disable(dev);
- drm_bridge_remove(dsi->bridge);
vc4_dsi_encoder_destroy(dsi->encoder);
mipi_dsi_host_unregister(&dsi->dsi_host);
--
2.13.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/vc4: Don't disable DSI clocks on component unload.
The clocks are enabled/disabled at encoder enable/disable time, not at
component load. Fixes a WARN_ON at boot if V3D fails to probe.
Fixes: 4078f5757144 ("drm/vc4: Add DSI driver")
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_dsi.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index 629d372633e6..13481bb6322f 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -1641,9 +1641,6 @@ static void vc4_dsi_unbind(struct device *dev, struct
device *master,
mipi_dsi_host_unregister(&dsi->dsi_host);
- clk_disable_unprepare(dsi->pll_phy_clock);
- clk_disable_unprepare(dsi->escape_clock);
-
if (dsi->port == 1)
vc4->dsi1 = NULL;
}
--
2.13.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BISECTED] vc4: f309946 crashes the kernel if vc4 can't allocate buffers
Noralf Trønnes writes: > The following commit crashes the kernel if vc4 can't allocate buffers: > > drm/vc4: Add an ioctl for labeling GEM BOs for summary stats > > It boots fine if I give it enough memory: cma=128M > I'm doing this on a Pi1 with bcm2835_defconfig. I'm successfully reproducing issues, even without the patch. I've reverted it locally and I'm chewing through kmalloc debug stuff, then I'll unrevert and see what I can find. 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 1/4] drm/tinydrm: remove call to mipi_dbi_init() from mipi_dbi_spi_init()
Den 02.08.2017 00.11, skrev David Lechner:
This removes the call to mipi_dbi_init() from mipi_dbi_spi_init() so that
drivers can have a driver-specific implementation if needed.
Also fixed order of @dc parameter in the doc comment.
Suggested-by: Noralf Trønnes
Signed-off-by: David Lechner
---
Reviewed-by: Noralf Trønnes
Add this when you resend the series, if I haven't applied it.
drivers/gpu/drm/tinydrm/mi0283qt.c | 8 ++--
drivers/gpu/drm/tinydrm/mipi-dbi.c | 17 +
include/drm/tinydrm/mipi-dbi.h | 6 +-
3 files changed, 12 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 482ff1c3..7e5bb7d 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -195,8 +195,12 @@ static int mi0283qt_probe(struct spi_device *spi)
device_property_read_u32(dev, "rotation", &rotation);
- ret = mipi_dbi_spi_init(spi, mipi, dc, &mi0283qt_pipe_funcs,
- &mi0283qt_driver, &mi0283qt_mode, rotation);
+ ret = mipi_dbi_spi_init(spi, mipi, dc);
+ if (ret)
+ return ret;
+
+ ret = mipi_dbi_init(&spi->dev, mipi, &mi0283qt_pipe_funcs,
+ &mi0283qt_driver, &mi0283qt_mode, rotation);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index e10fa4b..cba9784 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -777,15 +777,12 @@ static int mipi_dbi_typec3_command(struct mipi_dbi *mipi,
u8 cmd,
/**
* mipi_dbi_spi_init - Initialize MIPI DBI SPI interfaced controller
* @spi: SPI device
- * @dc: D/C gpio (optional)
* @mipi: &mipi_dbi structure to initialize
- * @pipe_funcs: Display pipe functions
- * @driver: DRM driver
- * @mode: Display mode
- * @rotation: Initial rotation in degrees Counter Clock Wise
+ * @dc: D/C gpio (optional)
*
* This function sets &mipi_dbi->command, enables &mipi->read_commands for the
- * usual read commands and initializes @mipi using mipi_dbi_init().
+ * usual read commands. It should be followed by a call to mipi_dbi_init() or
+ * a driver-specific init.
*
* If @dc is set, a Type C Option 3 interface is assumed, if not
* Type C Option 1.
@@ -800,11 +797,7 @@ static int mipi_dbi_typec3_command(struct mipi_dbi *mipi,
u8 cmd,
* Zero on success, negative error code on failure.
*/
int mipi_dbi_spi_init(struct spi_device *spi, struct mipi_dbi *mipi,
- struct gpio_desc *dc,
- const struct drm_simple_display_pipe_funcs *pipe_funcs,
- struct drm_driver *driver,
- const struct drm_display_mode *mode,
- unsigned int rotation)
+ struct gpio_desc *dc)
{
size_t tx_size = tinydrm_spi_max_transfer_size(spi, 0);
struct device *dev = &spi->dev;
@@ -850,7 +843,7 @@ int mipi_dbi_spi_init(struct spi_device *spi, struct
mipi_dbi *mipi,
return -ENOMEM;
}
- return mipi_dbi_init(dev, mipi, pipe_funcs, driver, mode, rotation);
+ return 0;
}
EXPORT_SYMBOL(mipi_dbi_spi_init);
diff --git a/include/drm/tinydrm/mipi-dbi.h b/include/drm/tinydrm/mipi-dbi.h
index d137b16..83346dd 100644
--- a/include/drm/tinydrm/mipi-dbi.h
+++ b/include/drm/tinydrm/mipi-dbi.h
@@ -62,11 +62,7 @@ mipi_dbi_from_tinydrm(struct tinydrm_device *tdev)
}
int mipi_dbi_spi_init(struct spi_device *spi, struct mipi_dbi *mipi,
- struct gpio_desc *dc,
- const struct drm_simple_display_pipe_funcs *pipe_funcs,
- struct drm_driver *driver,
- const struct drm_display_mode *mode,
- unsigned int rotation);
+ struct gpio_desc *dc);
int mipi_dbi_init(struct device *dev, struct mipi_dbi *mipi,
const struct drm_simple_display_pipe_funcs *pipe_funcs,
struct drm_driver *driver,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/tinydrm: mipi-dbi: Fix unbalanced DMA access
Den 01.08.2017 22.14, skrev David Lechner: If we return here and import_attach is true, then dma_buf_end_cpu_access() will not be called balance dma_buf_begin_cpu_access(). Fix by setting ret instead of returning. Signed-off-by: David Lechner --- Reviewed-by: Noralf Trønnes drivers/gpu/drm/tinydrm/mipi-dbi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c b/drivers/gpu/drm/tinydrm/mipi-dbi.c index c83eeb7..e10fa4b 100644 --- a/drivers/gpu/drm/tinydrm/mipi-dbi.c +++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c @@ -183,7 +183,8 @@ static int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb, dev_err_once(fb->dev->dev, "Format is not supported: %s\n", drm_get_format_name(fb->format->format, &format_name)); - return -EINVAL; + ret = -EINVAL; + break; } if (import_attach) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/4] drm/tinydrm: add support for LEGO MINDSTORMS EV3 LCD
Den 02.08.2017 18.24, skrev David Lechner: On 08/02/2017 08:03 AM, Noralf Trønnes wrote: Please use tinydrm_xrgb_to_gray8(). I considered this, but is seems excessive to loop through the entire fb twice just to make a 4x6 cursor blink. Yes, you're right about that. Can you change tinydrm_xrgb_to_gray8 to match the other copy/conversion functions so we can pass it a clip rectangle: int tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr, struct drm_framebuffer *fb, struct drm_clip_rect *clip) And move the import_attach part to the driver (repaper). repaper doesn't do partial updates, so pass a full clip. You should use this function to enable the regulator and init the controller. Don't look at mi0283qt it should have been fixed. ACK. But this is why I was not keen on writing a standalone driver. I know some things about kernel development, but not everything. How am I supposed to know what is OK to copy from other drivers and what is not? You can't know, and it's part of the review process to sort that out. That being said, I really should have fixed mi0283qt, because it will be copied... And if I am going to be put down as the maintainer of this driver, it bothers me that I don't know so much about how it all works. You don't need to know all the details. If I make a change, you can assume that I know what I'm doing and ack it, but I need someone to look at my patches, I can't apply my own patches without anyone looking at it, we all make mistakes. And if someone else sends a patch and you don't know if it is good or not, just ping me and I'll look at it. Either way I have to look at all tinydrm patches before applying them. I'm not keen on being default maintainer on drivers that I can't test. The upside of being a maintainer is that you control the future of the driver, what changes goes in. And I'm kind of in the same boat as you, I know tinydrm, but drm is very complex and I don't know half of what's going on. If I'm stuck or out of my league, I have to ask for help. Like with adding drm formats. Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv3 0/4] dw-hdmi CEC support
From: Hans Verkuil Russell's v2 cover letter: -- Hi, This series adds dw-hdmi CEC support. This is done in four stages: 1. Add cec-notifier support 2. Fix up the clkdis register support, as this register contains a clock disable bit for the CEC module. 3. Add the driver. 4. Remove definitions that are not required from dw-hdmi.h The CEC driver has been updated to use the register accessors in the main driver - it would be nice if it was possible to use the regmap support directly, but there's some knowledge private to the main driver that's required to correctly access the registers. (I don't understand why the register stride isn't part of regmap.) drivers/gpu/drm/bridge/synopsys/Kconfig | 10 + drivers/gpu/drm/bridge/synopsys/Makefile | 1 + drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 326 ++ drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h | 19 ++ drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 93 +++- drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 46 +--- 6 files changed, 437 insertions(+), 58 deletions(-) v2 - fix selection of CEC_NOTIFIER in Kconfig -- Changes in this v3: - add missing cec_notifier_put to remove() - some checkpatch unsigned -> unsigned int changes - cec_transmit_done is replaced by the newer cec_transmit_attempt_done - added missing CEC_CAP_PASSTHROUGH Regards, Hans Russell King (4): drm/bridge: dw-hdmi: add cec notifier support drm/bridge: dw-hdmi: add better clock disable control drm/bridge: dw-hdmi: add cec driver drm/bridge: dw-hdmi: remove CEC engine register definitions drivers/gpu/drm/bridge/synopsys/Kconfig | 10 + drivers/gpu/drm/bridge/synopsys/Makefile | 1 + drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 327 ++ drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h | 19 ++ drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 96 +++- drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 46 +--- 6 files changed, 441 insertions(+), 58 deletions(-) create mode 100644 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c create mode 100644 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h -- 2.13.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv3 2/4] drm/bridge: dw-hdmi: add better clock disable control
From: Russell King
The video setup path aways sets the clock disable register to a specific
value, which has the effect of disabling the CEC engine. When we add the
CEC driver, this becomes a problem.
Fix this by only setting/clearing the bits that the video path needs to.
Reviewed-by: Jose Abreu
Signed-off-by: Russell King
Acked-by: Hans Verkuil
Tested-by: Hans Verkuil
Tested-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 108495862cac..0ac1e3240cc3 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -166,6 +166,7 @@ struct dw_hdmi {
bool bridge_is_on; /* indicates the bridge is on */
bool rxsense; /* rxsense state */
u8 phy_mask;/* desired phy int mask settings */
+ u8 mc_clkdis; /* clock disable register */
spinlock_t audio_lock;
struct mutex audio_mutex;
@@ -551,8 +552,11 @@ EXPORT_SYMBOL_GPL(dw_hdmi_set_sample_rate);
static void hdmi_enable_audio_clk(struct dw_hdmi *hdmi, bool enable)
{
- hdmi_modb(hdmi, enable ? 0 : HDMI_MC_CLKDIS_AUDCLK_DISABLE,
- HDMI_MC_CLKDIS_AUDCLK_DISABLE, HDMI_MC_CLKDIS);
+ if (enable)
+ hdmi->mc_clkdis &= ~HDMI_MC_CLKDIS_AUDCLK_DISABLE;
+ else
+ hdmi->mc_clkdis |= HDMI_MC_CLKDIS_AUDCLK_DISABLE;
+ hdmi_writeb(hdmi, hdmi->mc_clkdis, HDMI_MC_CLKDIS);
}
static void dw_hdmi_ahb_audio_enable(struct dw_hdmi *hdmi)
@@ -1574,8 +1578,6 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
/* HDMI Initialization Step B.4 */
static void dw_hdmi_enable_video_path(struct dw_hdmi *hdmi)
{
- u8 clkdis;
-
/* control period minimum duration */
hdmi_writeb(hdmi, 12, HDMI_FC_CTRLDUR);
hdmi_writeb(hdmi, 32, HDMI_FC_EXCTRLDUR);
@@ -1587,17 +1589,21 @@ static void dw_hdmi_enable_video_path(struct dw_hdmi
*hdmi)
hdmi_writeb(hdmi, 0x21, HDMI_FC_CH2PREAM);
/* Enable pixel clock and tmds data path */
- clkdis = 0x7F;
- clkdis &= ~HDMI_MC_CLKDIS_PIXELCLK_DISABLE;
- hdmi_writeb(hdmi, clkdis, HDMI_MC_CLKDIS);
+ hdmi->mc_clkdis |= HDMI_MC_CLKDIS_HDCPCLK_DISABLE |
+ HDMI_MC_CLKDIS_CSCCLK_DISABLE |
+ HDMI_MC_CLKDIS_AUDCLK_DISABLE |
+ HDMI_MC_CLKDIS_PREPCLK_DISABLE |
+ HDMI_MC_CLKDIS_TMDSCLK_DISABLE;
+ hdmi->mc_clkdis &= ~HDMI_MC_CLKDIS_PIXELCLK_DISABLE;
+ hdmi_writeb(hdmi, hdmi->mc_clkdis, HDMI_MC_CLKDIS);
- clkdis &= ~HDMI_MC_CLKDIS_TMDSCLK_DISABLE;
- hdmi_writeb(hdmi, clkdis, HDMI_MC_CLKDIS);
+ hdmi->mc_clkdis &= ~HDMI_MC_CLKDIS_TMDSCLK_DISABLE;
+ hdmi_writeb(hdmi, hdmi->mc_clkdis, HDMI_MC_CLKDIS);
/* Enable csc path */
if (is_color_space_conversion(hdmi)) {
- clkdis &= ~HDMI_MC_CLKDIS_CSCCLK_DISABLE;
- hdmi_writeb(hdmi, clkdis, HDMI_MC_CLKDIS);
+ hdmi->mc_clkdis &= ~HDMI_MC_CLKDIS_CSCCLK_DISABLE;
+ hdmi_writeb(hdmi, hdmi->mc_clkdis, HDMI_MC_CLKDIS);
}
/* Enable color space conversion if needed */
@@ -2272,6 +2278,7 @@ __dw_hdmi_probe(struct platform_device *pdev,
hdmi->disabled = true;
hdmi->rxsense = true;
hdmi->phy_mask = (u8)~(HDMI_PHY_HPD | HDMI_PHY_RX_SENSE);
+ hdmi->mc_clkdis = 0x7f;
mutex_init(&hdmi->mutex);
mutex_init(&hdmi->audio_mutex);
--
2.13.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv3 4/4] drm/bridge: dw-hdmi: remove CEC engine register definitions
From: Russell King We don't need the CEC engine register definitions, so let's remove them. Signed-off-by: Russell King Acked-by: Hans Verkuil Tested-by: Hans Verkuil Tested-by: Laurent Pinchart --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 45 --- 1 file changed, 45 deletions(-) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h index 69644c83a0f8..9d90eb9c46e5 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h @@ -478,51 +478,6 @@ #define HDMI_A_PRESETUP 0x501A #define HDMI_A_SRM_BASE 0x5020 -/* CEC Engine Registers */ -#define HDMI_CEC_CTRL 0x7D00 -#define HDMI_CEC_STAT 0x7D01 -#define HDMI_CEC_MASK 0x7D02 -#define HDMI_CEC_POLARITY 0x7D03 -#define HDMI_CEC_INT0x7D04 -#define HDMI_CEC_ADDR_L 0x7D05 -#define HDMI_CEC_ADDR_H 0x7D06 -#define HDMI_CEC_TX_CNT 0x7D07 -#define HDMI_CEC_RX_CNT 0x7D08 -#define HDMI_CEC_TX_DATA0 0x7D10 -#define HDMI_CEC_TX_DATA1 0x7D11 -#define HDMI_CEC_TX_DATA2 0x7D12 -#define HDMI_CEC_TX_DATA3 0x7D13 -#define HDMI_CEC_TX_DATA4 0x7D14 -#define HDMI_CEC_TX_DATA5 0x7D15 -#define HDMI_CEC_TX_DATA6 0x7D16 -#define HDMI_CEC_TX_DATA7 0x7D17 -#define HDMI_CEC_TX_DATA8 0x7D18 -#define HDMI_CEC_TX_DATA9 0x7D19 -#define HDMI_CEC_TX_DATA10 0x7D1a -#define HDMI_CEC_TX_DATA11 0x7D1b -#define HDMI_CEC_TX_DATA12 0x7D1c -#define HDMI_CEC_TX_DATA13 0x7D1d -#define HDMI_CEC_TX_DATA14 0x7D1e -#define HDMI_CEC_TX_DATA15 0x7D1f -#define HDMI_CEC_RX_DATA0 0x7D20 -#define HDMI_CEC_RX_DATA1 0x7D21 -#define HDMI_CEC_RX_DATA2 0x7D22 -#define HDMI_CEC_RX_DATA3 0x7D23 -#define HDMI_CEC_RX_DATA4 0x7D24 -#define HDMI_CEC_RX_DATA5 0x7D25 -#define HDMI_CEC_RX_DATA6 0x7D26 -#define HDMI_CEC_RX_DATA7 0x7D27 -#define HDMI_CEC_RX_DATA8 0x7D28 -#define HDMI_CEC_RX_DATA9 0x7D29 -#define HDMI_CEC_RX_DATA10 0x7D2a -#define HDMI_CEC_RX_DATA11 0x7D2b -#define HDMI_CEC_RX_DATA12 0x7D2c -#define HDMI_CEC_RX_DATA13 0x7D2d -#define HDMI_CEC_RX_DATA14 0x7D2e -#define HDMI_CEC_RX_DATA15 0x7D2f -#define HDMI_CEC_LOCK 0x7D30 -#define HDMI_CEC_WKUPCTRL 0x7D31 - /* I2C Master Registers (E-DDC) */ #define HDMI_I2CM_SLAVE 0x7E00 #define HDMI_I2CM_ADDRESS 0x7E01 -- 2.13.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv3 1/4] drm/bridge: dw-hdmi: add cec notifier support
From: Russell King
Add CEC notifier support to the HDMI bridge driver, so that the CEC
part of the IP can receive its physical address.
Signed-off-by: Russell King
[hans.verkuil: added missing cec_notifier_put to remove()]
Acked-by: Hans Verkuil
Tested-by: Hans Verkuil
Tested-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/synopsys/Kconfig | 1 +
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 25 -
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig
b/drivers/gpu/drm/bridge/synopsys/Kconfig
index 53e78d092d18..351db000599a 100644
--- a/drivers/gpu/drm/bridge/synopsys/Kconfig
+++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
@@ -2,6 +2,7 @@ config DRM_DW_HDMI
tristate
select DRM_KMS_HELPER
select REGMAP_MMIO
+ select CEC_CORE if CEC_NOTIFIER
config DRM_DW_HDMI_AHB_AUDIO
tristate "Synopsys Designware AHB Audio interface"
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index ead11242c4b9..108495862cac 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -36,7 +36,10 @@
#include "dw-hdmi.h"
#include "dw-hdmi-audio.h"
+#include
+
#define DDC_SEGMENT_ADDR 0x30
+
#define HDMI_EDID_LEN 512
enum hdmi_datamap {
@@ -175,6 +178,8 @@ struct dw_hdmi {
struct regmap *regm;
void (*enable_audio)(struct dw_hdmi *hdmi);
void (*disable_audio)(struct dw_hdmi *hdmi);
+
+ struct cec_notifier *cec_notifier;
};
#define HDMI_IH_PHY_STAT0_RX_SENSE \
@@ -1896,6 +1901,7 @@ static int dw_hdmi_connector_get_modes(struct
drm_connector *connector)
hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
drm_mode_connector_update_edid_property(connector, edid);
+ cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier, edid);
ret = drm_add_edid_modes(connector, edid);
/* Store the ELD */
drm_edid_to_eld(connector, edid);
@@ -2119,11 +2125,16 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
* ask the source to re-read the EDID.
*/
if (intr_stat &
- (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD))
+ (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);
+ if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0)
+ cec_notifier_set_phys_addr(hdmi->cec_notifier,
+ CEC_PHYS_ADDR_INVALID);
+ }
+
if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
dev_dbg(hdmi->dev, "EVENT=%s\n",
phy_int_pol & HDMI_PHY_HPD ? "plugin" : "plugout");
@@ -2376,6 +2387,12 @@ __dw_hdmi_probe(struct platform_device *pdev,
if (ret)
goto err_iahb;
+ hdmi->cec_notifier = cec_notifier_get(dev);
+ if (!hdmi->cec_notifier) {
+ ret = -ENOMEM;
+ goto err_iahb;
+ }
+
/*
* To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator
* N and cts values before enabling phy
@@ -2452,6 +2469,9 @@ __dw_hdmi_probe(struct platform_device *pdev,
hdmi->ddc = NULL;
}
+ if (hdmi->cec_notifier)
+ cec_notifier_put(hdmi->cec_notifier);
+
clk_disable_unprepare(hdmi->iahb_clk);
err_isfr:
clk_disable_unprepare(hdmi->isfr_clk);
@@ -2469,6 +2489,9 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
/* Disable all interrupts */
hdmi_writeb(hdmi, ~0, HDMI_IH_MUTE_PHY_STAT0);
+ if (hdmi->cec_notifier)
+ cec_notifier_put(hdmi->cec_notifier);
+
clk_disable_unprepare(hdmi->iahb_clk);
clk_disable_unprepare(hdmi->isfr_clk);
--
2.13.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv3 3/4] drm/bridge: dw-hdmi: add cec driver
From: Russell King
Add a CEC driver for the dw-hdmi hardware.
Reviewed-by: Neil Armstrong
Signed-off-by: Russell King
[hans.verkuil: unsigned -> unsigned int]
[hans.verkuil: cec_transmit_done -> cec_transmit_attempt_done]
[hans.verkuil: add missing CEC_CAP_PASSTHROUGH]
Acked-by: Hans Verkuil
Tested-by: Hans Verkuil
Tested-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/synopsys/Kconfig | 9 +
drivers/gpu/drm/bridge/synopsys/Makefile | 1 +
drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 327 ++
drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h | 19 ++
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 42 +++-
drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 1 +
6 files changed, 398 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
create mode 100644 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h
diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig
b/drivers/gpu/drm/bridge/synopsys/Kconfig
index 351db000599a..d34c3dc04ba9 100644
--- a/drivers/gpu/drm/bridge/synopsys/Kconfig
+++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
@@ -23,3 +23,12 @@ config DRM_DW_HDMI_I2S_AUDIO
help
Support the I2S Audio interface which is part of the Synopsys
Designware HDMI block.
+
+config DRM_DW_HDMI_CEC
+ tristate "Synopsis Designware CEC interface"
+ depends on DRM_DW_HDMI
+ select CEC_CORE
+ select CEC_NOTIFIER
+ help
+ Support the CE interface which is part of the Synopsys
+ Designware HDMI block.
diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile
b/drivers/gpu/drm/bridge/synopsys/Makefile
index 17aa7a65b57e..6fe415903668 100644
--- a/drivers/gpu/drm/bridge/synopsys/Makefile
+++ b/drivers/gpu/drm/bridge/synopsys/Makefile
@@ -3,3 +3,4 @@
obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
+obj-$(CONFIG_DRM_DW_HDMI_CEC) += dw-hdmi-cec.o
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
new file mode 100644
index ..6c323510f128
--- /dev/null
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
@@ -0,0 +1,327 @@
+/*
+ * Designware HDMI CEC driver
+ *
+ * Copyright (C) 2015-2017 Russell King.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+
+#include "dw-hdmi-cec.h"
+
+enum {
+ HDMI_IH_CEC_STAT0 = 0x0106,
+ HDMI_IH_MUTE_CEC_STAT0 = 0x0186,
+
+ HDMI_CEC_CTRL = 0x7d00,
+ CEC_CTRL_START = BIT(0),
+ CEC_CTRL_FRAME_TYP = 3 << 1,
+ CEC_CTRL_RETRY = 0 << 1,
+ CEC_CTRL_NORMAL = 1 << 1,
+ CEC_CTRL_IMMED = 2 << 1,
+
+ HDMI_CEC_STAT = 0x7d01,
+ CEC_STAT_DONE = BIT(0),
+ CEC_STAT_EOM= BIT(1),
+ CEC_STAT_NACK = BIT(2),
+ CEC_STAT_ARBLOST= BIT(3),
+ CEC_STAT_ERROR_INIT = BIT(4),
+ CEC_STAT_ERROR_FOLL = BIT(5),
+ CEC_STAT_WAKEUP = BIT(6),
+
+ HDMI_CEC_MASK = 0x7d02,
+ HDMI_CEC_POLARITY = 0x7d03,
+ HDMI_CEC_INT= 0x7d04,
+ HDMI_CEC_ADDR_L = 0x7d05,
+ HDMI_CEC_ADDR_H = 0x7d06,
+ HDMI_CEC_TX_CNT = 0x7d07,
+ HDMI_CEC_RX_CNT = 0x7d08,
+ HDMI_CEC_TX_DATA0 = 0x7d10,
+ HDMI_CEC_RX_DATA0 = 0x7d20,
+ HDMI_CEC_LOCK = 0x7d30,
+ HDMI_CEC_WKUPCTRL = 0x7d31,
+};
+
+struct dw_hdmi_cec {
+ struct dw_hdmi *hdmi;
+ const struct dw_hdmi_cec_ops *ops;
+ u32 addresses;
+ struct cec_adapter *adap;
+ struct cec_msg rx_msg;
+ unsigned int tx_status;
+ bool tx_done;
+ bool rx_done;
+ struct cec_notifier *notify;
+ int irq;
+};
+
+static void dw_hdmi_write(struct dw_hdmi_cec *cec, u8 val, int offset)
+{
+ cec->ops->write(cec->hdmi, val, offset);
+}
+
+static u8 dw_hdmi_read(struct dw_hdmi_cec *cec, int offset)
+{
+ return cec->ops->read(cec->hdmi, offset);
+}
+
+static int dw_hdmi_cec_log_addr(struct cec_adapter *adap, u8 logical_addr)
+{
+ struct dw_hdmi_cec *cec = cec_get_drvdata(adap);
+
+ if (logical_addr == CEC_LOG_ADDR_INVALID)
+ cec->addresses = 0;
+ else
+ cec->addresses |= BIT(logical_addr) | BIT(15);
+
+ dw_hdmi_write(cec, cec->addresses & 255, HDMI_CEC_ADDR_L);
+ dw_hdmi_write(cec, cec->addresses >> 8, HDMI_CEC_ADDR_H);
+
+ return 0;
+}
+
+static int dw_hdmi_cec_transmit(struct cec_adapter *adap, u8 attempts,
+ u32 signal_free_time, struct cec
Re: Please pull ARCPGU changes
On Wed, Aug 2, 2017 at 6:16 AM, Alexey Brodkin wrote: > Hi Daniel, > > On Wed, 2017-08-02 at 11:41 +0200, Daniel Vetter wrote: >> On Mon, Jul 31, 2017 at 11:11:06AM +, Alexey Brodkin wrote: >> > >> > Hi Dave, >> > >> > Could you please pull a couple of minor fixes for ARCPGU. >> > These changes are based on today's drm-misc/drm-misc-next. >> >> You can't send Dave a pull based on a random snapshot of drm-misc-next. If >> you want to maintain your driver on top of drm-misc, then become part of >> the group (arcgpu would fit imo). Otherwise you need to base your pulls on >> top of Dave's tree. > > I don't have any specific requirement for "drm-misc-next" to b used as a base. > That said Dave trees are OK for me. Still could you please point me to > his "for-curr" and "for-next" (or equivalent) trees? next: https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next fixes: https://cgit.freedesktop.org/~airlied/linux/log/?h=drm-fixes Alex > >> Also, your pull is missing the [PULL] tag in the >> subject. > > Sorry for that, will fix it in the next request. > > -Alexey > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/fb-helper: pass physical dimensions to fbdev
The fbdev subsystem has a place for physical dimensions (width and height
in mm) that is readable by userspace. Since DRM also knows these
dimensions, pass this information to the fbdev device.
Signed-off-by: David Lechner
---
v1 changes (from RFC):
* Use loop to get info from first connected connector instead of just the
first connector.
v2 changes:
* Update width in height in drm_setup_crtcs() also to handle hotplug events.
As mentioned in the comments below, drm_setup_crtcs() can't set these values
during init because the data structure hasn't been allocated yet, so we end up
doing the same thing in two different places.
drivers/gpu/drm/drm_fb_helper.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index b2a01d1..7813b86 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1884,6 +1884,7 @@ void drm_fb_helper_fill_var(struct fb_info *info, struct
drm_fb_helper *fb_helpe
uint32_t fb_width, uint32_t fb_height)
{
struct drm_framebuffer *fb = fb_helper->fb;
+ int i;
info->pseudo_palette = fb_helper->pseudo_palette;
info->var.xres_virtual = fb->width;
@@ -1896,6 +1897,18 @@ void drm_fb_helper_fill_var(struct fb_info *info, struct
drm_fb_helper *fb_helpe
info->var.height = -1;
info->var.width = -1;
+ drm_fb_helper_for_each_connector(fb_helper, i) {
+ struct drm_connector *connector =
+ fb_helper->connector_info[i]->connector;
+
+ /* use the first connected connector for the physical
dimensions */
+ if (connector->status == connector_status_connected) {
+ info->var.height = connector->display_info.width_mm;
+ info->var.width = connector->display_info.height_mm;
+ break;
+ }
+ }
+
switch (fb->format->depth) {
case 8:
info->var.red.offset = 0;
@@ -2355,6 +2368,7 @@ static void drm_setup_crtcs(struct drm_fb_helper
*fb_helper,
struct drm_display_mode **modes;
struct drm_fb_offset *offsets;
bool *enabled;
+ bool var_updated = false;
int i;
DRM_DEBUG_KMS("\n");
@@ -2429,6 +2443,23 @@ static void drm_setup_crtcs(struct drm_fb_helper
*fb_helper,
modeset->fb = fb_helper->fb;
modeset->x = offset->x;
modeset->y = offset->y;
+
+ /*
+* During init, drm_setup_crtcs() is called before the
+* fbdev is allocated, so this only affects hotplug
+* events.
+* Only the info from the first connected connector is
+* used.
+*/
+ if (!var_updated && fb_helper->fbdev &&
+ connector->status == connector_status_connected) {
+ struct fb_var_screeninfo *var =
+ &fb_helper->fbdev->var;
+
+ var->width = connector->display_info.width_mm;
+ var->height = connector->display_info.height_mm;
+ var_updated = true;
+ }
}
}
out:
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/fb: Fix pointer dereference before null check.
fb_crtc is used before a null check, so move the use after the null check.
This was just identified by inspection. I haven't actually observed a crash
here, so it is possible that the null check could be unnecessary.
Signed-off-by: David Lechner
---
drivers/gpu/drm/drm_fb_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 2cc28f0..2d3f93e 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2424,9 +2424,9 @@ static void drm_setup_crtcs(struct drm_fb_helper
*fb_helper,
struct drm_display_mode *mode = modes[i];
struct drm_fb_helper_crtc *fb_crtc = crtcs[i];
struct drm_fb_offset *offset = &offsets[i];
- struct drm_mode_set *modeset = &fb_crtc->mode_set;
if (mode && fb_crtc) {
+ struct drm_mode_set *modeset = &fb_crtc->mode_set;
struct drm_connector *connector =
fb_helper->connector_info[i]->connector;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 07/13] ARM: sun8i: h3: add display engine pipeline barebone
Hi Icenowy,
Dne torek, 01. avgust 2017 ob 15:12:58 CEST je Icenowy Zheng napisal(a):
> As we have already the support for the DE2 on Allwinner H3, add the
> display engine pipeline device tree nodes to its DTSI file.
>
> The H5 pipeline has some differences and will be enabled later.
>
> Signed-off-by: Icenowy Zheng
> ---
> arch/arm/boot/dts/sun8i-h3.dtsi | 170
> 1 file changed, 170 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
> b/arch/arm/boot/dts/sun8i-h3.dtsi index b36f9f423c39..75ad7b65a7fc 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -41,6 +41,8 @@
> */
>
> #include "sunxi-h3-h5.dtsi"
> +#include
> +#include
>
> / {
> cpus {
> @@ -72,6 +74,174 @@
> };
> };
>
> + de: display-engine {
> + compatible = "allwinner,sun8i-h3-display-engine";
> + allwinner,pipelines = <&mixer0>,
> + <&mixer1>;
> + status = "disabled";
> + };
> +
> + soc {
> + display_clocks: clock@100 {
> + compatible = "allwinner,sun8i-a83t-de2-clk";
> + reg = <0x0100 0x10>;
> + clocks = <&ccu CLK_BUS_DE>,
> + <&ccu CLK_DE>;
> + clock-names = "bus",
> + "mod";
> + resets = <&ccu RST_BUS_DE>;
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + assigned-clocks = <&ccu CLK_DE>;
> + assigned-clock-parents = <&ccu CLK_PLL_DE>;
> + assigned-clock-rates = <43200>;
> + };
I believe Maxime ask you to use clk_set_rate() in the past:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-June/512909.html
Regards,
Jernej
> +
> + mixer0: mixer@110 {
> + compatible = "allwinner,sun8i-h3-de2-mixer0";
> + reg = <0x0110 0x10>;
> + clocks = <&display_clocks CLK_BUS_MIXER0>,
> + <&display_clocks CLK_MIXER0>;
> + clock-names = "bus",
> + "mod";
> + resets = <&display_clocks RST_MIXER0>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mixer0_out: port@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + mixer0_out_tcon0: endpoint@0 {
> + reg = <0>;
> + remote-endpoint =
> <&tcon0_in_mixer0>;
> + };
> +
> + mixer0_out_tcon1: endpoint@1 {
> + reg = <1>;
> + remote-endpoint =
> <&tcon1_in_mixer0>;
> + };
> + };
> + };
> + };
> +
> + mixer1: mixer@120 {
> + compatible = "allwinner,sun8i-h3-de2-mixer1";
> + reg = <0x0120 0x10>;
> + clocks = <&display_clocks CLK_BUS_MIXER1>,
> + <&display_clocks CLK_MIXER1>;
> + clock-names = "bus",
> + "mod";
> + resets = <&display_clocks RST_WB>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + mixer1_out: port@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + mixer1_out_tcon0: endpoint@0 {
> + reg = <0>;
> + remote-endpoint =
> <&tcon0_in_mixer1>;
> + };
> +
> + mixer1_out_tcon1: endpoint@1 {
> + reg = <1>;
> + remote-endpoint =
> <&tcon1_in_mixer1>;
> + };
> + };
> + };
> + };
> +
> + tcon0: lcd-controller@1c0c000 {
> + compatible = "allwinner,sun8i-h3-t
Re: [linux-sunxi] [PATCH 07/13] ARM: sun8i: h3: add display engine pipeline barebone
在 2017-08-02 12:47，Jernej Škrabec 写道：
Hi Icenowy,
Dne torek, 01. avgust 2017 ob 15:12:58 CEST je Icenowy Zheng
napisal(a):
As we have already the support for the DE2 on Allwinner H3, add the
display engine pipeline device tree nodes to its DTSI file.
The H5 pipeline has some differences and will be enabled later.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-h3.dtsi | 170
1 file changed, 170
insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
b/arch/arm/boot/dts/sun8i-h3.dtsi index b36f9f423c39..75ad7b65a7fc
100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -41,6 +41,8 @@
*/
#include "sunxi-h3-h5.dtsi"
+#include
+#include
/ {
cpus {
@@ -72,6 +74,174 @@
};
};
+ de: display-engine {
+ compatible = "allwinner,sun8i-h3-display-engine";
+ allwinner,pipelines = <&mixer0>,
+ <&mixer1>;
+ status = "disabled";
+ };
+
+ soc {
+ display_clocks: clock@100 {
+ compatible = "allwinner,sun8i-a83t-de2-clk";
+ reg = <0x0100 0x10>;
+ clocks = <&ccu CLK_BUS_DE>,
+<&ccu CLK_DE>;
+ clock-names = "bus",
+ "mod";
+ resets = <&ccu RST_BUS_DE>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ assigned-clocks = <&ccu CLK_DE>;
+ assigned-clock-parents = <&ccu CLK_PLL_DE>;
+ assigned-clock-rates = <43200>;
+ };
I believe Maxime ask you to use clk_set_rate() in the past:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-June/512909.html
Yes, but I think the frequency is still part of our configuration, not
forced
by the hardware.
If we set it in the driver, why don't we set it to 300MHz?
(In fact for pipelines without TVE we can really use 300MHz for CLK_DE,
and if
we do not want 4K we can even use lower frequency)
Regards,
Jernej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 01/13] dt-bindings: update the binding for Allwinner H3 DE2 support
Hi Icenowy, Dne torek, 01. avgust 2017 ob 15:12:52 CEST je Icenowy Zheng napisal(a): > Allwinner H3 features a "Display Engine 2.0". > > Add device tree bindings for the following parts: > - H3 TCONs > - H3 Mixers > - H3 Display engine > > Signed-off-by: Icenowy Zheng > --- > .../bindings/display/sunxi/sun4i-drm.txt | 25 > ++ 1 file changed, 21 insertions(+), 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index > 2ee6ff0ef98e..92512953943e 100644 > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > @@ -87,18 +87,17 @@ Required properties: > * allwinner,sun6i-a31-tcon > * allwinner,sun6i-a31s-tcon > * allwinner,sun8i-a33-tcon > + * allwinner,sun8i-h3-tcon > * allwinner,sun8i-v3s-tcon > - reg: base address and size of memory-mapped region > - interrupts: interrupt associated to this IP > - clocks: phandles to the clocks feeding the TCON. Three are needed: > - 'ahb': the interface clocks > - - 'tcon-ch0': The clock driving the TCON channel 0 > - resets: phandles to the reset controllers driving the encoder > - "lcd": the reset line for the TCON channel 0 > > - clock-names: the clock names mentioned above > - reset-names: the reset names mentioned above > - - clock-output-names: Name of the pixel clock created > > - ports: A ports node with endpoint definitions as defined in >Documentation/devicetree/bindings/media/video-interfaces.txt. The > @@ -112,7 +111,23 @@ Required properties: >channel the endpoint is associated to. If that property is not >present, the endpoint number will be used as the channel number. > > -On SoCs other than the A33 and V3s, there is one more clock required: > +For the following compatibles: > + * allwinner,sun5i-a13-tcon > + * allwinner,sun6i-a31-tcon > + * allwinner,sun6i-a31s-tcon > + * allwinner,sun8i-a33-tcon > + * allwinner,sun8i-v3s-tcon > +there is one more clock and one more property required: > + - clocks: > + - 'tcon-ch0': The clock driving the TCON channel 0 > + - clock-output-names: Name of the pixel clock created > + > +For the following compatibles: > + * allwinner,sun5i-a13-tcon > + * allwinner,sun6i-a31-tcon > + * allwinner,sun6i-a31s-tcon > + * allwinner,sun8i-h3-tcon > +there is one more clock required: > - 'tcon-ch1': The clock driving the TCON channel 1 > > DRC > @@ -207,6 +222,8 @@ supported. > Required properties: >- compatible: value must be one of: > * allwinner,sun8i-v3s-de2-mixer > +* allwinner,sun8i-h3-de2-mixer0 > +* allwinner,sun8i-h3-de2-mixer1 About that, I concur with Maxime here, plane number properties would be better. If we don't do this now, we will never have it. Reference: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-June/512902.html Regards, Jernej >- reg: base address and size of the memory-mapped region. >- clocks: phandles to the clocks feeding the mixer > * bus: the mixer interface clock > @@ -218,7 +235,6 @@ Required properties: >Documentation/devicetree/bindings/media/video-interfaces.txt. The >first port should be the input endpoints, the second one the output > > - > Display Engine Pipeline > --- > > @@ -233,6 +249,7 @@ Required properties: > * allwinner,sun6i-a31-display-engine > * allwinner,sun6i-a31s-display-engine > * allwinner,sun8i-a33-display-engine > +* allwinner,sun8i-h3-display-engine > * allwinner,sun8i-v3s-display-engine > >- allwinner,pipelines: list of phandle to the display engine > -- > 2.13.0 > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. To unsubscribe from this group and stop receiving > emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] gpu: host1x: Don't fail on NULL bo physical address
On 02.08.2017 12:55, Mikko Perttunen wrote:
> Pinning a Host1x BO currently cannot fail and zero is a valid address
> for a BO when IOMMU is enabled. To avoid false errors remove checks
> for NULL BO physical addresses.
>
> Fixes: 404bfb78daf3 ("gpu: host1x: Add IOMMU support")
> Signed-off-by: Mikko Perttunen
> ---
> drivers/gpu/host1x/job.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
> index bee504406cfc..db509ab8874e 100644
> --- a/drivers/gpu/host1x/job.c
> +++ b/drivers/gpu/host1x/job.c
> @@ -197,10 +197,6 @@ static unsigned int pin_job(struct host1x *host, struct
> host1x_job *job)
> }
>
> phys_addr = host1x_bo_pin(reloc->target.bo, &sgt);
> - if (!phys_addr) {
> - err = -EINVAL;
> - goto unpin;
> - }
>
> job->addr_phys[job->num_unpins] = phys_addr;
> job->unpins[job->num_unpins].bo = reloc->target.bo;
> @@ -225,10 +221,6 @@ static unsigned int pin_job(struct host1x *host, struct
> host1x_job *job)
> }
>
> phys_addr = host1x_bo_pin(g->bo, &sgt);
> - if (!phys_addr) {
> - err = -EINVAL;
> - goto unpin;
> - }
>
> if (!IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL) && host->domain) {
> for_each_sg(sgt->sgl, sg, sgt->nents, j)
>
I think 'Fixes' tag isn't really needed for this patch since it's not a bug fix,
but a cleanup.
Reviewed-by: Dmitry Osipenko
--
Dmitry
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Please pull ARCPGU changes
Hi Daniel, On Wed, 2017-08-02 at 11:41 +0200, Daniel Vetter wrote: > On Mon, Jul 31, 2017 at 11:11:06AM +, Alexey Brodkin wrote: > > > > Hi Dave, > > > > Could you please pull a couple of minor fixes for ARCPGU. > > These changes are based on today's drm-misc/drm-misc-next. > > You can't send Dave a pull based on a random snapshot of drm-misc-next. If > you want to maintain your driver on top of drm-misc, then become part of > the group (arcgpu would fit imo). Otherwise you need to base your pulls on > top of Dave's tree. I don't have any specific requirement for "drm-misc-next" to b used as a base. That said Dave trees are OK for me. Still could you please point me to his "for-curr" and "for-next" (or equivalent) trees? > Also, your pull is missing the [PULL] tag in the > subject. Sorry for that, will fix it in the next request. -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 01/13] dt-bindings: update the binding for Allwinner H3 DE2 support
在 2017-08-02 12:53，Jernej Škrabec 写道： Hi Icenowy, Dne torek, 01. avgust 2017 ob 15:12:52 CEST je Icenowy Zheng napisal(a): Allwinner H3 features a "Display Engine 2.0". Add device tree bindings for the following parts: - H3 TCONs - H3 Mixers - H3 Display engine Signed-off-by: Icenowy Zheng --- .../bindings/display/sunxi/sun4i-drm.txt | 25 ++ 1 file changed, 21 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index 2ee6ff0ef98e..92512953943e 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -87,18 +87,17 @@ Required properties: * allwinner,sun6i-a31-tcon * allwinner,sun6i-a31s-tcon * allwinner,sun8i-a33-tcon + * allwinner,sun8i-h3-tcon * allwinner,sun8i-v3s-tcon - reg: base address and size of memory-mapped region - interrupts: interrupt associated to this IP - clocks: phandles to the clocks feeding the TCON. Three are needed: - 'ahb': the interface clocks - - 'tcon-ch0': The clock driving the TCON channel 0 - resets: phandles to the reset controllers driving the encoder - "lcd": the reset line for the TCON channel 0 - clock-names: the clock names mentioned above - reset-names: the reset names mentioned above - - clock-output-names: Name of the pixel clock created - ports: A ports node with endpoint definitions as defined in Documentation/devicetree/bindings/media/video-interfaces.txt. The @@ -112,7 +111,23 @@ Required properties: channel the endpoint is associated to. If that property is not present, the endpoint number will be used as the channel number. -On SoCs other than the A33 and V3s, there is one more clock required: +For the following compatibles: + * allwinner,sun5i-a13-tcon + * allwinner,sun6i-a31-tcon + * allwinner,sun6i-a31s-tcon + * allwinner,sun8i-a33-tcon + * allwinner,sun8i-v3s-tcon +there is one more clock and one more property required: + - clocks: + - 'tcon-ch0': The clock driving the TCON channel 0 + - clock-output-names: Name of the pixel clock created + +For the following compatibles: + * allwinner,sun5i-a13-tcon + * allwinner,sun6i-a31-tcon + * allwinner,sun6i-a31s-tcon + * allwinner,sun8i-h3-tcon +there is one more clock required: - 'tcon-ch1': The clock driving the TCON channel 1 DRC @@ -207,6 +222,8 @@ supported. Required properties: - compatible: value must be one of: * allwinner,sun8i-v3s-de2-mixer +* allwinner,sun8i-h3-de2-mixer0 +* allwinner,sun8i-h3-de2-mixer1 About that, I concur with Maxime here, plane number properties would be better. If we don't do this now, we will never have it. But I still prefer different compatibles, as the capabilities are already proven to be different between mixer0 and mixer1, and furtherly we cannot promise Allwinner won't add more functions only available at mixer0. Then we will be trapped into a situation that we describe more and more functions via properties, but they should be encoded into the compatible. Reference: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-June/512902.html Regards, Jernej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v13 5/7] vfio: ABI for mdev display dma-buf operation
On 8/2/2017 2:48 AM, Alex Williamson wrote:
> On Tue, 25 Jul 2017 17:28:18 +0800
> Tina Zhang wrote:
>
>> Add VFIO_DEVICE_QUERY_GFX_PLANE ioctl command to let user mode query and
>> get the plan and its related information.
>>
>> The dma-buf's life cycle is handled by user mode and tracked by kernel.
>> The returned fd in struct vfio_device_query_gfx_plane can be a new
>> fd or an old fd of a re-exported dma-buf. Host User mode can check the
>> value of fd and to see if it needs to create new resource according to
>> the new fd or just use the existed resource related to the old fd.
>>
>> Signed-off-by: Tina Zhang
>> ---
>> include/uapi/linux/vfio.h | 28
>> 1 file changed, 28 insertions(+)
>>
>> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
>> index ae46105..827a230 100644
>> --- a/include/uapi/linux/vfio.h
>> +++ b/include/uapi/linux/vfio.h
>> @@ -502,6 +502,34 @@ struct vfio_pci_hot_reset {
>>
>> #define VFIO_DEVICE_PCI_HOT_RESET _IO(VFIO_TYPE, VFIO_BASE + 13)
>>
>> +/**
>> + * VFIO_DEVICE_QUERY_GFX_PLANE - _IOW(VFIO_TYPE, VFIO_BASE + 14, struct
>> vfio_device_query_gfx_plane)
>> + *
>> + * Set the drm_plane_type and retrieve information about the gfx plane.
>> + *
>> + * Return: 0 on success, -errno on failure.
>> + */
>> +struct vfio_device_gfx_plane_info {
>> +__u32 argsz;
>> +__u32 flags;
>> +/* in */
>> +__u32 drm_plane_type; /* type of plane: DRM_PLANE_TYPE_* */
>> +/* out */
>> +__u32 drm_format; /* drm format of plane */
>> +__u64 drm_format_mod; /* tiled mode */
>> +__u32 width;/* width of plane */
>> +__u32 height; /* height of plane */
>> +__u32 stride; /* stride of plane */
>> +__u32 size; /* size of plane in bytes, align on page*/
>> +__u32 x_pos;/* horizontal position of cursor plane, upper left
>> corner in pixels */
>> +__u32 y_pos;/* vertical position of cursor plane, upper left corner
>> in lines*/
>> +__u32 region_index;
>> +__s32 fd; /* dma-buf fd */
>
> How do I know which of these is valid, region_index or fd? Can I ask
> for one vs the other? What are the errno values to differentiate
> unsupported vs not initialized? Is there a "probe" flag that I can use
> to determine what the device supports without allocating those
> resources yet?
>
> Kirti, does this otherwise meet your needs?
>
I wanted to test my change with this interface, but I couldn't, was busy
with other stuff.
This structure looks good to me for region type support.
> What are the errno values to differentiate
> unsupported vs not initialized?
In previous version discussion, we decided that vendor driver should
set all members to 0 in such cases. Mainly, if size is 0 then there is
nothing to copy.
Thanks,
Kirti
> Thanks,
> Alex
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] gpu: host1x: Don't fail on NULL bo physical address
On 08/02/2017 02:06 PM, Dmitry Osipenko wrote:
On 02.08.2017 12:55, Mikko Perttunen wrote:
Pinning a Host1x BO currently cannot fail and zero is a valid address
for a BO when IOMMU is enabled. To avoid false errors remove checks
for NULL BO physical addresses.
Fixes: 404bfb78daf3 ("gpu: host1x: Add IOMMU support")
Signed-off-by: Mikko Perttunen
---
drivers/gpu/host1x/job.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index bee504406cfc..db509ab8874e 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -197,10 +197,6 @@ static unsigned int pin_job(struct host1x *host, struct
host1x_job *job)
}
phys_addr = host1x_bo_pin(reloc->target.bo, &sgt);
- if (!phys_addr) {
- err = -EINVAL;
- goto unpin;
- }
job->addr_phys[job->num_unpins] = phys_addr;
job->unpins[job->num_unpins].bo = reloc->target.bo;
@@ -225,10 +221,6 @@ static unsigned int pin_job(struct host1x *host, struct
host1x_job *job)
}
phys_addr = host1x_bo_pin(g->bo, &sgt);
- if (!phys_addr) {
- err = -EINVAL;
- goto unpin;
- }
if (!IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL) && host->domain) {
for_each_sg(sgt->sgl, sg, sgt->nents, j)
I think 'Fixes' tag isn't really needed for this patch since it's not a bug fix,
but a cleanup.
Reviewed-by: Dmitry Osipenko
Actually without this, host1x_test fails for me on the first try on TX1
:) So it's a bugfix.
Thanks for the reviews and tests.
Mikko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] gpu: host1x: Don't fail on NULL bo physical address
On 02.08.2017 14:16, Mikko Perttunen wrote:
> On 08/02/2017 02:06 PM, Dmitry Osipenko wrote:
>> On 02.08.2017 12:55, Mikko Perttunen wrote:
>>> Pinning a Host1x BO currently cannot fail and zero is a valid address
>>> for a BO when IOMMU is enabled. To avoid false errors remove checks
>>> for NULL BO physical addresses.
>>>
>>> Fixes: 404bfb78daf3 ("gpu: host1x: Add IOMMU support")
>>> Signed-off-by: Mikko Perttunen
>>> ---
>>> drivers/gpu/host1x/job.c | 8
>>> 1 file changed, 8 deletions(-)
>>>
>>> diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
>>> index bee504406cfc..db509ab8874e 100644
>>> --- a/drivers/gpu/host1x/job.c
>>> +++ b/drivers/gpu/host1x/job.c
>>> @@ -197,10 +197,6 @@ static unsigned int pin_job(struct host1x *host, struct
>>> host1x_job *job)
>>> }
>>> phys_addr = host1x_bo_pin(reloc->target.bo, &sgt);
>>> -if (!phys_addr) {
>>> -err = -EINVAL;
>>> -goto unpin;
>>> -}
>>> job->addr_phys[job->num_unpins] = phys_addr;
>>> job->unpins[job->num_unpins].bo = reloc->target.bo;
>>> @@ -225,10 +221,6 @@ static unsigned int pin_job(struct host1x *host, struct
>>> host1x_job *job)
>>> }
>>> phys_addr = host1x_bo_pin(g->bo, &sgt);
>>> -if (!phys_addr) {
>>> -err = -EINVAL;
>>> -goto unpin;
>>> -}
>>> if (!IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL) && host->domain) {
>>> for_each_sg(sgt->sgl, sg, sgt->nents, j)
>>>
>>
>> I think 'Fixes' tag isn't really needed for this patch since it's not a bug
>> fix,
>> but a cleanup.
>>
>> Reviewed-by: Dmitry Osipenko
>>
>
> Actually without this, host1x_test fails for me on the first try on TX1 :) So
> it's a bugfix.
Right, my bad.
>
> Thanks for the reviews and tests.
>
I haven't tested this patch, only the the second because I've tested it on top
of grate's kernel which has a conflicting patch being applied.
--
Dmitry
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/4] drm/bridge: dw-hdmi: add cec driver
On Wed, Aug 02, 2017 at 04:14:34PM +0300, Laurent Pinchart wrote:
> Hi Hans,
>
> On Wednesday 02 Aug 2017 08:47:23 Hans Verkuil wrote:
> > On 08/02/2017 12:32 AM, Laurent Pinchart wrote:
> > >> +
> > >> +cec_register_cec_notifier(cec->adap, cec->notify);
> > >> +
> > >> +return 0;
> > >> +}
> > >> +
> > >> +static int dw_hdmi_cec_remove(struct platform_device *pdev)
> > >> +{
> > >> +struct dw_hdmi_cec *cec = platform_get_drvdata(pdev);
> > >> +
> > >> +cec_unregister_adapter(cec->adap);
> > >> +cec_notifier_put(cec->notify);
> > >> +
> > >> +return 0;
> > >> +}
> > >> +
> > >> +static struct platform_driver dw_hdmi_cec_driver = {
> > >> +.probe = dw_hdmi_cec_probe,
> > >> +.remove = dw_hdmi_cec_remove,
> > >> +.driver = {
> > >> +.name = "dw-hdmi-cec",
> > >> +},
> > >> +};
> > >> +module_platform_driver(dw_hdmi_cec_driver);
> > >
> > > Is there a particular reason why this has to be a separate module instead
> > > of simply calling the CEC init/cleanup functions directly from the main
> > > dw-hdmi driver ?
> >
> > Not all SoCs that use dw-hdmi also use the dw-hdmi CEC implementation. Some
> > use their own implementation (amlogic).
>
> Lovely. Of course we need to reinvent the wheel every time, where would the
> fun be otherwise ?
>
> > So by implementing the cec-notifier in the dw-hdmi driver and keeping dw-
> > hdmi CEC separate you can easily choose whether or not you want to use this
> > CEC driver or another SoC CEC driver.
>
> I'm certainly fine with such a split, but I don't think it requires a
> separate
> platform_driver. We could use a similar approach as with the HDMI PHY that
> can
> also differ between SoCs. The PHY is identified at runtime when possible, and
> the SoC-specific glue code can override that with a few data fields and
> function pointers.
Excuse me if I completely lose interest in reworking the driver at this
point, as it's enough of an effort to follow the churn in CEC from one
kernel version to another. I'm not about to rewrite the driver and
restart the review cycle from scratch and then have several iterations
of having to update it as CEC continues to evolve.
Let's get this driver in mainline, and then if we want further changes
we can do that later.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] gpu: host1x: Fix bitshift/mask multipliers
On 02.08.2017 12:55, Mikko Perttunen wrote:
> Some parts of Host1x uses BIT_WORD/BIT_MASK/BITS_PER_LONG to calculate
> register or field offsets. This worked fine on ARMv7, but now that
> BITS_PER_LONG is 64 but our registers are still 32-bit things are
> broken.
>
> Fix by replacing..
> - BIT_WORD with (x / 32)
> - BIT_MASK with BIT(x % 32)
> - BITS_PER_LONG with 32
>
> Signed-off-by: Mikko Perttunen
> ---
> drivers/gpu/host1x/hw/intr_hw.c | 24
> drivers/gpu/host1x/hw/syncpt_hw.c | 2 +-
> 2 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/host1x/hw/intr_hw.c b/drivers/gpu/host1x/hw/intr_hw.c
> index dacb8009a605..37ebb51703fa 100644
> --- a/drivers/gpu/host1x/hw/intr_hw.c
> +++ b/drivers/gpu/host1x/hw/intr_hw.c
> @@ -33,10 +33,10 @@ static void host1x_intr_syncpt_handle(struct
> host1x_syncpt *syncpt)
> unsigned int id = syncpt->id;
> struct host1x *host = syncpt->host;
>
> - host1x_sync_writel(host, BIT_MASK(id),
> - HOST1X_SYNC_SYNCPT_THRESH_INT_DISABLE(BIT_WORD(id)));
> - host1x_sync_writel(host, BIT_MASK(id),
> - HOST1X_SYNC_SYNCPT_THRESH_CPU0_INT_STATUS(BIT_WORD(id)));
> + host1x_sync_writel(host, BIT(id % 32),
> + HOST1X_SYNC_SYNCPT_THRESH_INT_DISABLE(id / 32));
> + host1x_sync_writel(host, BIT(id % 32),
> + HOST1X_SYNC_SYNCPT_THRESH_CPU0_INT_STATUS(id / 32));
>
> schedule_work(&syncpt->intr.work);
> }
> @@ -50,9 +50,9 @@ static irqreturn_t syncpt_thresh_isr(int irq, void *dev_id)
> for (i = 0; i < DIV_ROUND_UP(host->info->nb_pts, 32); i++) {
> reg = host1x_sync_readl(host,
> HOST1X_SYNC_SYNCPT_THRESH_CPU0_INT_STATUS(i));
> - for_each_set_bit(id, ®, BITS_PER_LONG) {
> + for_each_set_bit(id, ®, 32) {
> struct host1x_syncpt *syncpt =
> - host->syncpt + (i * BITS_PER_LONG + id);
> + host->syncpt + (i * 32 + id);
> host1x_intr_syncpt_handle(syncpt);
> }
> }
> @@ -117,17 +117,17 @@ static void _host1x_intr_set_syncpt_threshold(struct
> host1x *host,
> static void _host1x_intr_enable_syncpt_intr(struct host1x *host,
> unsigned int id)
> {
> - host1x_sync_writel(host, BIT_MASK(id),
> - HOST1X_SYNC_SYNCPT_THRESH_INT_ENABLE_CPU0(BIT_WORD(id)));
> + host1x_sync_writel(host, BIT(id % 32),
> + HOST1X_SYNC_SYNCPT_THRESH_INT_ENABLE_CPU0(id / 32));
> }
>
> static void _host1x_intr_disable_syncpt_intr(struct host1x *host,
>unsigned int id)
> {
> - host1x_sync_writel(host, BIT_MASK(id),
> - HOST1X_SYNC_SYNCPT_THRESH_INT_DISABLE(BIT_WORD(id)));
> - host1x_sync_writel(host, BIT_MASK(id),
> - HOST1X_SYNC_SYNCPT_THRESH_CPU0_INT_STATUS(BIT_WORD(id)));
> + host1x_sync_writel(host, BIT(id % 32),
> + HOST1X_SYNC_SYNCPT_THRESH_INT_DISABLE(id / 32));
> + host1x_sync_writel(host, BIT(id % 32),
> + HOST1X_SYNC_SYNCPT_THRESH_CPU0_INT_STATUS(id / 32));
> }
>
> static int _host1x_free_syncpt_irq(struct host1x *host)
> diff --git a/drivers/gpu/host1x/hw/syncpt_hw.c
> b/drivers/gpu/host1x/hw/syncpt_hw.c
> index c93f74fcce72..7b0270d60742 100644
> --- a/drivers/gpu/host1x/hw/syncpt_hw.c
> +++ b/drivers/gpu/host1x/hw/syncpt_hw.c
> @@ -89,7 +89,7 @@ static int syncpt_cpu_incr(struct host1x_syncpt *sp)
> host1x_syncpt_idle(sp))
> return -EINVAL;
>
> - host1x_sync_writel(host, BIT_MASK(sp->id),
> + host1x_sync_writel(host, BIT(sp->id % 32),
> HOST1X_SYNC_SYNCPT_CPU_INCR(reg_offset));
> wmb();
>
>
Reviewed-by: Dmitry Osipenko
Tested-by: Dmitry Osipenko
--
Dmitry
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: add const to bin_attribute
Add const to bin_attribute structures as they are only passed to the
functions sysfs_{remove/create}_bin_file or
device_{remove/create}_bin_file. The corresponding arguments are of
type const, so declare the structures to be const.
Signed-off-by: Bhumika Goyal
---
drivers/gpu/drm/i915/i915_sysfs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index 7fcf006..d61c872 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -220,7 +220,7 @@ static int l3_access_valid(struct drm_i915_private
*dev_priv, loff_t offset)
return ret;
}
-static struct bin_attribute dpf_attrs = {
+static const struct bin_attribute dpf_attrs = {
.attr = {.name = "l3_parity", .mode = (S_IRUSR | S_IWUSR)},
.size = GEN7_L3LOG_SIZE,
.read = i915_l3_read,
@@ -229,7 +229,7 @@ static int l3_access_valid(struct drm_i915_private
*dev_priv, loff_t offset)
.private = (void *)0
};
-static struct bin_attribute dpf_attrs_1 = {
+static const struct bin_attribute dpf_attrs_1 = {
.attr = {.name = "l3_parity_slice_1", .mode = (S_IRUSR | S_IWUSR)},
.size = GEN7_L3LOG_SIZE,
.read = i915_l3_read,
@@ -532,7 +532,7 @@ static ssize_t error_state_write(struct file *file, struct
kobject *kobj,
return count;
}
-static struct bin_attribute error_state_attr = {
+static const struct bin_attribute error_state_attr = {
.attr.name = "error",
.attr.mode = S_IRUSR | S_IWUSR,
.size = 0,
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/6] drm/bridge: tc358767: filter out too high modes
On Tue, Aug 1, 2017 at 4:11 PM, Philipp Zabel
wrote:
> On Thu, 2017-07-27 at 15:47 +0300, Andrey Gusakov wrote:
> > Minimum pixel clock period is 6.5 nS for DPI. Do not accept modes
> > with lower pixel clock period.
> >
> > Signed-off-by: Andrey Gusakov
> > ---
> > drivers/gpu/drm/bridge/tc358767.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/
> tc358767.c
> > index f605bb7d1aa3..e8008e0c2e88 100644
> > --- a/drivers/gpu/drm/bridge/tc358767.c
> > +++ b/drivers/gpu/drm/bridge/tc358767.c
> > @@ -1103,7 +1103,10 @@ static bool tc_bridge_mode_fixup(struct
> drm_bridge *bridge,
> > static int tc_connector_mode_valid(struct drm_connector *connector,
> > struct drm_display_mode *mode)
> > {
> > - /* Accept any mode */
> > + /* PCLK limitation = 6.5 nS */
> > + if (mode->clock > 163000)
> > + return MODE_CLOCK_HIGH;
>
> The comment doesn't match the code. If the limit is 6.5 nS, shouldn't
> that be
> if (mode->clock > 153846)
> ?
>
You are right. Have no idea where did I take this value from.
Datasheet says it is up to 154MHz. I'll resend this patch.
Thank you.
>
> regards
> Philipp
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fb-helper: pass physical dimensions to fbdev
On 08/02/2017 04:46 AM, Daniel Vetter wrote: On Tue, Aug 01, 2017 at 10:26:41AM -0500, David Lechner wrote: The fbdev subsystem has a place for physical dimensions (width and height in mm) that is readable by userspace. Since DRM also knows these dimensions, pass this information to the fbdev device. Signed-off-by: David Lechner Still in the wrong function. Also please add some notation about what you changed when resubmitting a patch (it took me a while to remember that I replied to you already). That makes patch reviewing more efficient. Sorry for being so dense. :-/ I did read your first reply at least 10 times. All of the terminology is foreign to me, but after sleeping on it a few days, I think it is slowly soaking into my brain. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/4] drm/tinydrm: add support for LEGO MINDSTORMS EV3 LCD
On 08/02/2017 08:03 AM, Noralf Trønnes wrote: Please use tinydrm_xrgb_to_gray8(). I considered this, but is seems excessive to loop through the entire fb twice just to make a 4x6 cursor blink. You should use this function to enable the regulator and init the controller. Don't look at mi0283qt it should have been fixed. ACK. But this is why I was not keen on writing a standalone driver. I know some things about kernel development, but not everything. How am I supposed to know what is OK to copy from other drivers and what is not? And if I am going to be put down as the maintainer of this driver, it bothers me that I don't know so much about how it all works. Why 2 emulation formats? I chose DRM_FORMAT_XRGB since I expected everything to support it. Please use only that. Because my graphics library currently does not work with XRGB. ;-) I can fix the graphics library and drop the RGB565 format in the kernel driver. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display
On 08/02/2017 03:05 AM, Noralf Trønnes wrote:
Den 02.08.2017 00.26, skrev David Lechner:
On 08/01/2017 01:08 PM, Noralf Trønnes wrote:
(cc: Daniel Vetter)
Den 01.08.2017 18.51, skrev David Lechner:
On 07/30/2017 12:14 PM, Noralf Trønnes wrote:
Den 29.07.2017 21.40, skrev David Lechner:
On 07/29/2017 02:17 PM, David Lechner wrote:
The goal of this series is to get the built-in LCD of the LEGO
MINDSTORMS EV3
working. But, most of the content here is building up the
infrastructure to do
that.
Some general comments/questions:
I have noticed that DRM doesn't really have support for monochrome
displays. I'm guessing that is because no one really uses them
anymore?
The repaper driver was the first monochrome drm driver and I chose to
present it to userspace as XRGB and convert it to monochrome.
The reason for this is that everything, libraries, apps, plymouth
(boot
splash, no rgb565) supports it. I didn't see any point in adding a new
monochrome drm format that didn't have, or probably wouldn't get
userspace support (by libraries at least). The application of course
needs to know this to get a good result.
tinydrm_xrgb_to_gray8() does the conversion:
https://cgit.freedesktop.org/drm/drm-misc/commit/drivers/gpu/drm/tinydrm?id=379ea9a1a59a5a32c8db6f164e80a3fd00cb3781
The LEGO EV3 display is just an LCD (not the backlit kind). It has
two modes of operation. It can to 2bbp grayscale or it can do 1bpp
monochrome. The grayscale isn't the best (looks splotchy in
places), so it would be nice to be able to choose between these
two modes. How would I implement something like that?
Do you expect anyone to use grayscale if it doesn't look good?
Maybe better to add it later if there's a demand for it.
I don't expect many people to use it at all. The people that do will
be hackers like me that want to see what it is capable of, so I
think I will keep it grayscale by default.
It looks like the best way to satisfy your needs is to add specific
formats.
Video for Linux have these:
include/uapi/linux/videodev2.h
/* Grey formats */
#define V4L2_PIX_FMT_GREYv4l2_fourcc('G', 'R', 'E', 'Y') /* 8
Greyscale */
#define V4L2_PIX_FMT_Y4 v4l2_fourcc('Y', '0', '4', ' ') /* 4
Greyscale */
#define V4L2_PIX_FMT_Y6 v4l2_fourcc('Y', '0', '6', ' ') /* 6
Greyscale */
#define V4L2_PIX_FMT_Y10 v4l2_fourcc('Y', '1', '0', ' ') /* 10
Greyscale */
#define V4L2_PIX_FMT_Y12 v4l2_fourcc('Y', '1', '2', ' ') /* 12
Greyscale */
#define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16
Greyscale */
#define V4L2_PIX_FMT_Y16_BE v4l2_fourcc_be('Y', '1', '6', ' ') /* 16
Greyscale BE */
Maybe we can add formats like these:
include/uapi/drm/drm_fourcc.h
#define DRM_FORMAT_MONOfourcc_code('Y', '0', '1', ' ') /* [0]
Monochrome */
or
#define DRM_FORMAT_Y1fourcc_code('Y', '0', '1', ' ') /* [0]
Monochrome */
#define DRM_FORMAT_Y2fourcc_code('Y', '0', '2', ' ') /* [1:0]
Greyscale */
Daniel, what do you think?
2 of the first 3 tinydrm drivers are monochrome (and I would like to
write a driver for the Seeed/Grove I2C OLED displays which are also
monochrome), so I think the 1bpp modes would definitely be useful. I
think there is enough userspace code still around that knows about
FB_VISUAL_MONO01 and FB_VISUAL_MONO10 that could use these.
Can you elaborate, would you use the display trough monochrome fbdev
or through drm?
I have a small collection of programs and libraries that work using
monochrome fbdev. I would like to just keep using them without having to
convert everything to drm.
I don't think a Y02 mode would be useful though. There is pretty much
nothing out there (that I could find) that uses such a mode.
A Y08 mode for 8bpp grayscale would be useful though. This is another
more commonly used format.
Another source of fourcc's is FFmpeg which has these:
{ AV_PIX_FMT_GRAY8,MKTAG('Y', '8', '0', '0') },
{ AV_PIX_FMT_GRAY8,MKTAG('Y', '8', ' ', ' ') },
{ AV_PIX_FMT_GRAY8, MKTAG('G', 'R', 'E', 'Y') },
{ AV_PIX_FMT_MONOWHITE,MKTAG('B', '1', 'W', '0') },
{ AV_PIX_FMT_MONOBLACK,MKTAG('B', '0', 'W', '1') },
AV_PIX_FMT_GRAY8
Y , 8bpp.
AV_PIX_FMT_MONOWHITE
Y , 1bpp, 0 is white, 1 is black,
in each byte pixels are ordered from the msb to the lsb.
AV_PIX_FMT_MONOBLACK
Y , 1bpp, 0 is black, 1 is white,
in each byte pixels are ordered from the msb to the lsb.
__drm_format_info() provides details about formats:
{ .format = DRM_FORMAT_MONO,.depth = 1, .num_planes = 1, .cpp
= { 0, 0, 0 }, .hsub = 1, .vsub = 1 },
{ .format = DRM_FORMAT_GREY,.depth = 8, .num_planes = 1, .cpp
= { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
framebuffer_check() and drm_fb_cma_create_with_funcs() use cpp for
validation and they don't expect it to be zero.
Noralf.
Also, how can I indicate to userspace that this display really is
monochrome/grayscale sinc
Re: 10bit output via KMS
Hi, >>> On 24 July 2017 at 14:56, Volker Vogelhuber >>> wrote: I wonder if it is possible to have drmModeAddFB2 to handle 'X', 'R', '3', '0' at all. So is this supported in any way? >>> Secondly, you're correct that you would need (theoretically) to extend >>> drmModeAddFB2, however it already has DRM_FORMAT_XRGB2101010 and >>> DRM_FORMAT_XBGR2101010 for i965 and above, which covers everything in >>> the last 10 years. This is the 'XR30' FourCC you mention, so it should >>> already be there and working in the kernel. >> This question probably better fits to the drm mailing list, although the >> discussion started on the mesa list. >> >> I got it working now that my 10bit buffers are correctly displayed >> on a Samsung QM49F via drmModeAddFB2 and the 'X', 'R', '3', '0' >> fourcc code. Based on the Samsung's datasheet it should support 10bit >> signals, although the EDID does not seem to contain a vendor >> specific data block that would confirm that assumption. >> >> I have connected an Apollo Lake module with a display port cable >> to that display but I'm unsure if it's really 10bit or if there is some >> conversion logic somewhere in between that may downsample my >> 10 bit buffer to 8bit before sending it via displayport to the display. > > Well you could just try to display a 10bit image with a gradient going from black to white. > The difference between 8bit and 10bit should be obvious even to the naked eye. Thanks Christian. I tried your proposal but as I already assumed there seem to be no difference. I switched the display to an LG 27UD58-B which supports the vendor specific data block and also states that it supports 36bpp as well as 30bpp input signals. It even has a deep color option to be enabled in it's menu. But apparently the apollo lake GPU does not care about that, or at least it makes no difference regarding my test buffer. What I verified is that the buffer generated by OpenGL is really 10bit. When I pass the 10bit buffer to drmModeAddFB2 as an 8bit buffer it is shown with various color artifacts because of the wrong bit mapping. I just stumbled upon a slide from Andy Ritger where he mentions that there are some components still missing for HDR10. (https://www.x.org/wiki/Events/XDC2016/Program/xdc-2016-hdr.pdf) As far as I understand it, he proposes that the driver should accept an scRGB FP16 buffer and that this part is still missing in the Linux kernel. My question is: is that only true for HDR10 with regards to SMPTE 2086, or is it even not possible to output a "deep color" DRM_FORMAT_XBGR2101010 buffer as a 10bit BPP signal via displayport. So far I stumbled over some patches regarding color management >> in the drm part of the kernel, but couldn't figure out how one could >> configure what is really send to the display. It seem to mostly be used to manipulate gamma values and so on. As the only indicator >> what is provided to the display is the buffer format handled by >> drmModeAddFB2 I doubt this is enough to configure the signal. >> Otherwise one could argue that the link speed of the display signal >> would have to toggle every time I send a different buffer format, which is certainly not the case. So what portion of the kms/drm chain do I >> miss currently? The drmModeModeInfo pointer has a clock field, but I guess this is meant to be for the pixel clock not the clock of the serialized signal. Probably that's why I couldn't find modelines for 4k@60 especially for 10bit compared to 8bit. >> >> Thanks >> Volker >> >> >> >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v4] drm/hdcp: drm enum property for CP State
Default connector property called "Content Protection" is added to
represent the content protection state of a connector and to
configure the same.
Userspace can request for enable or disable of content protection
on a connector. Set "DESIRED" for Enable and "UNDESIRED" for disable.
Content protection states defined:
DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED - Unsupported
DRM_MODE_CONTENT_PROTECTION_UNDESIRED - Undesired
DRM_MODE_CONTENT_PROTECTION_DESIRED - Desired
DRM_MODE_CONTENT_PROTECTION_ENABLED - Enabled
v2: Redesigned the property to match with CP needs of CrOS [Sean].
v3: Renamed the state names. Header is removed [Sean].
v4: Aligned with existing userspace(CrOS's usage) [Sean].
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/drm_connector.c | 24
include/drm/drm_mode_config.h | 5 +
include/uapi/drm/drm_mode.h | 7 +++
3 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 8072e6e4c62c..f4ce0af63ad3 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -617,6 +617,14 @@ static const struct drm_prop_enum_list
drm_link_status_enum_list[] = {
};
DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
+static const struct drm_prop_enum_list drm_cp_enum_list[] = {
+ { DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED, "Unsupported" },
+ { DRM_MODE_CONTENT_PROTECTION_UNDESIRED,"Undesired" },
+ { DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
+ { DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
+};
+DRM_ENUM_NAME_FN(drm_get_cp_status_name, drm_cp_enum_list)
+
/**
* drm_display_info_set_bus_formats - set the supported bus formats
* @info: display info to store bus formats in
@@ -741,6 +749,15 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
* value of link-status is "GOOD". If something fails during or after
modeset,
* the kernel driver may set this to "BAD" and issue a hotplug uevent.
Drivers
* should update this value using
drm_mode_connector_set_link_status_property().
+ * Content Protection:
+ * Connector Content Protection property to indicate the content
protection
+ * status of a connector. Default value is "UNDESIRED". Kernel will set
+ * to "UNSUPPORTED" if there is no common HDCP ver supported between Src
+ * and Sink. User space could set this to "DESIRED" to enabled the content
+ * protection on the connector. If content protection setup process is
+ * success, kernel will set this property to "ENABLED". To Disable the
+ * content protection on the connector userspace could set this property
to
+ * "UNDESIRED".
*
* Connectors also have one standardized atomic property:
*
@@ -789,6 +806,13 @@ int drm_connector_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.link_status_property = prop;
+ prop = drm_property_create_enum(dev, 0, "Content Protection",
+ drm_cp_enum_list,
+ ARRAY_SIZE(drm_cp_enum_list));
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.cp_property = prop;
+
return 0;
}
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 42981711189b..72e2b4e6d51d 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -538,6 +538,11 @@ struct drm_mode_config {
*/
struct drm_property *link_status_property;
/**
+* @cp_property: Default connector property for content protection
+* status of a connector
+*/
+ struct drm_property *cp_property;
+ /**
* @plane_type_property: Default plane property to differentiate
* CURSOR, PRIMARY and OVERLAY legacy uses of planes.
*/
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 403339f98a92..61685a64cd6a 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -173,6 +173,13 @@ extern "C" {
DRM_MODE_REFLECT_X | \
DRM_MODE_REFLECT_Y)
+/* Content Protection options */
+enum cp_state {
+ DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED = -1,
+ DRM_MODE_CONTENT_PROTECTION_UNDESIRED,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ DRM_MODE_CONTENT_PROTECTION_ENABLED,
+};
struct drm_mode_modeinfo {
__u32 clock;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: mali-dp: Restore commit_tail behaviour to the runtime_pm friendly version.
Commit 46f1d42f2738 ("drm: mali-dp: Update the state of all planes
before re-enabling active CRTCs.") changed the runtime_pm recommended
order of doing the commit_tail (disable old crtc, enable new crtc, do
the plane updates) to the old non-atomic compat order (disable old crtc,
do the plane updates, enable new crtc) in order to stop planes streaming
out stale data. Turns out that the proper thing to do is to remember to
disable the planes on the crtcs that get disabled, and the problem goes
away. Oh, and only activate the planes that are involved in the new
commit, too.
Fixes commit 46f1d42f2738 ("drm: mali-dp: Update the state of all planes
before re-enabling active CRTCs.")
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_crtc.c | 4
drivers/gpu/drm/arm/malidp_drv.c | 11 +++
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
b/drivers/gpu/drm/arm/malidp_crtc.c
index 3615d18a7ddf..ca413896b087 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -77,7 +77,11 @@ static void malidp_crtc_atomic_disable(struct drm_crtc *crtc,
struct malidp_hw_device *hwdev = malidp->dev;
int err;
+ /* always disable planes on the CRTC that is being turned off */
+ drm_atomic_helper_disable_planes_on_crtc(old_state, false);
+
drm_crtc_vblank_off(crtc);
+
hwdev->enter_config_mode(hwdev);
clk_disable_unprepare(hwdev->pxlclk);
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index a6a05a768dd1..d4b1636b441a 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -221,9 +221,8 @@ static void malidp_atomic_commit_tail(struct
drm_atomic_state *state)
struct drm_crtc_state *old_crtc_state;
int i;
- pm_runtime_get_sync(drm->dev);
-
drm_atomic_helper_commit_modeset_disables(drm, state);
+ drm_atomic_helper_commit_modeset_enables(drm, state);
for_each_old_crtc_in_state(state, crtc, old_crtc_state, i) {
malidp_atomic_commit_update_gamma(crtc, old_crtc_state);
@@ -231,16 +230,12 @@ static void malidp_atomic_commit_tail(struct
drm_atomic_state *state)
malidp_atomic_commit_se_config(crtc, old_crtc_state);
}
- drm_atomic_helper_commit_planes(drm, state, 0);
-
- drm_atomic_helper_commit_modeset_enables(drm, state);
+ drm_atomic_helper_commit_planes(drm, state,
DRM_PLANE_COMMIT_ACTIVE_ONLY);
malidp_atomic_commit_hw_done(state);
drm_atomic_helper_wait_for_vblanks(drm, state);
- pm_runtime_put(drm->dev);
-
drm_atomic_helper_cleanup_planes(drm, state);
}
@@ -685,12 +680,12 @@ static void malidp_unbind(struct device *dev)
struct malidp_drm *malidp = drm->dev_private;
drm_dev_unregister(drm);
+ pm_runtime_get_sync(dev);
if (malidp->fbdev) {
drm_fbdev_cma_fini(malidp->fbdev);
malidp->fbdev = NULL;
}
drm_kms_helper_poll_fini(drm);
- pm_runtime_get_sync(dev);
malidp_se_irq_fini(drm);
malidp_de_irq_fini(drm);
component_unbind_all(dev, drm);
--
2.13.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Add support for CCS modifiers
On 17-08-02 12:14:15, Daniel Vetter wrote:
On Tue, Aug 01, 2017 at 09:14:50AM -0700, Ben Widawsky wrote:
On 17-07-31 10:29:55, Daniel Vetter wrote:
> On Sat, Jul 29, 2017 at 09:25:50AM -0700, Ben Widawsky wrote:
> > On 17-07-29 13:53:10, Daniel Stone wrote:
> > > Hi Ben,
> > >
> > > On 26 July 2017 at 19:08, Ben Widawsky wrote:
> > > > + } else if (INTEL_GEN(dev_priv) >= 9) {
> > > > intel_primary_formats = skl_primary_formats;
> > > > num_formats = ARRAY_SIZE(skl_primary_formats);
> > > > - modifiers = skl_format_modifiers;
> > > > + if (pipe >= PIPE_C)
> > > > + modifiers = skl_format_modifiers_ccs;
> > > > + else
> > > > + modifiers = skl_format_modifiers_noccs;
> > >
> > > Shouldn't that be (pipe < PIPE_C)?
> > >
> > > Cheers,
> > > Daniel
> >
> > Yep. It was wrong in v7 too :/. I have it fixed locally.
>
> Shouldn't the igt catch this, or does it not try to exercise all the
> plane/crtc combos there are?
> -Daniel
I don't know whether or not IGT should have caught this, but it wouldn't have
because I had been sending these without Ville's patches, so my patches alone
don't even build (since his patches defined the modifiers).
You can run igt testcases locally. I expect you to do that, at least for
the stuff you're touching.
Does this mean there's no igts for this at all?
-Daniel
I haven't been running IGT locally, so I don't know if they touch this path.
We've done all testing so far with kmscube, X, and weston; then measure the
overall bandwidth. In this case, I'd stop testing these since Jason/Daniel took
over my other patches. I don't even know how to locally make sure I get a
display on pipe C.
You could easily make an IGT make sure that you get back the right list of
modifiers for a given pipe on a given GEN. Probably should do one.
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v3] drm/hdcp: drm enum property for CP State
On Wednesday 26 July 2017 11:24 PM, Sean Paul wrote:
On Wed, Jul 26, 2017 at 12:51 PM, C, Ramalingam wrote:
-Original Message-
From: Sean Paul [mailto:seanp...@chromium.org]
Sent: Wednesday, July 26, 2017 8:23 PM
To: C, Ramalingam
Cc: Sean Paul ; Vetter, Daniel
; Intel Graphics Development ; dri-devel ; Daniel
Vetter
Subject: Re: [RFC v3] drm/hdcp: drm enum property for CP State
On Wed, Jul 26, 2017 at 03:24:10PM +0530, Ramalingam C wrote:
On Tuesday 25 July 2017 06:04 PM, Sean Paul wrote:
On Mon, Jul 24, 2017 at 2:12 PM, Ramalingam C
wrote:
DRM connector property is created to represent the content
protection state of the connector and to configure the same.
Content protection states defined:
DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED -
Unsupported
DRM_MODE_CONTENT_PROTECTION_DISABLE - Disabled
DRM_MODE_CONTENT_PROTECTION_ENABLE - Enabled
v2: Redesigned the property to match with CP needs of CrOS [Sean].
v3: Renamed the state names. Header is removed [sean].
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/drm_connector.c | 14 ++
include/drm/drm_mode_config.h | 5 +
include/uapi/drm/drm_mode.h | 5 +
3 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c
b/drivers/gpu/drm/drm_connector.c index 5cd61af..d6aaa08 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -617,6 +617,13 @@ static const struct drm_prop_enum_list
drm_link_status_enum_list[] = {
};
DRM_ENUM_NAME_FN(drm_get_link_status_name,
drm_link_status_enum_list)
+static const struct drm_prop_enum_list drm_cp_enum_list[] = {
+ { DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED,
"Unsupported" },
You're still changing the enum names from the original patch/CrOS
implementation.
https://lists.freedesktop.org/archives/dri-devel/2014-December/07333
6.html
https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_d
isplay.cc?l=27
Sean,
I think we have bit of confusion here.
Agreed :)
And in previous discussion you were fine with new state of property
that is "unsupported" - indicates no common HDCP version is supported
on HDCP src and Sink combo.
when CP is not possible, if property exist, userspace will interpret
it as CP is supported and attempt for enabling.
I prefer indicating Unsupported state than failing such requests blindly.
In that case to interpret the new state, we need to change CrOS User
space code.
In the RFC you mentioned above, two version of uapi interfaces are
discussed.
V1 uses single property to configure the CP and also for
status indication.
V2 uses two properties one for configuring and another one for
status of Content protection.
But CrOS user space is currently using the V1 interface.
which will be preferred approach right now (V1/V2)?
In either way we need to change the CrOS :(
We can't upstream code without a userspace implementation, so V1. Without
any modifications.
Based on uAPI rules mentioned by Daniel, what I infer is that once a uAPI is in
place,
usecase of uAPI cant be changed. It can be only be extended for future needs.
So IMHO it is better to shape the userspace as per the uAPI
interfaces that community want to have for longer run. And mainly we should
adapt to a
interface which can be conveniently extended for HDCP2.2 and future specs
versions.
So IMO it is worth seeing what it takes for CrOS Userspace changes for HDCP2.2
interfaces.
And In the interest of having HDCP2.2 in their stack sooner, if the CrOS
community or Google
is interested in providing that userspace support, it will be smoother to put
the
complete and preferred uAPI for HDCP2.2 and 1.4 in place.
Sean, I think you will be better person to comment on this from both sides,
CrOS and DRM.
As has been mentioned before in this thread, it's a lot easier to upstream code
that is proven to work, than it is to merge speculative API. Further, if this
patch
were merged, it would be CrOS which is currently the only consumer... not a
good look :)
Not exactly. CrOS will be the first consumer, Android will follow soon after
this.
We need to enable this feature on HwC for that purpose. Yup might take required
time :)
Lets say we need to modify CrOS user space, will there be any help for that?
I am not aware what it takes though.
You could probably reach out to chromium-...@chromium.org or the author of
the Chrome hdcp implementation for help.
Thank you for the contact.
And before reaching out, it is better to conclude the HDCP1.4/2.2 uAPI
interfaces that is agreeable for this community.
In that perspective, can we consider and review the uAPI interface with two
properties discussed for V2 of your earlier patches?
Complete use case is discussed in my previous mail.
Based on userspace commitment for HDCP2.2, we can add blob property for SRM too.
Sean
I am trying to discuss both uapi versions of V1 and V2
[Bug 102014] Mesa git build broken by commit bc7f41e11d325280db12e7b9444501357bc13922
https://bugs.freedesktop.org/show_bug.cgi?id=102014 --- Comment #5 from Nicolai Hähnle --- *sigh* This has not been a good week for me. Please see https://patchwork.freedesktop.org/patch/170007/ -- 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 2/4] drm/tinydrm: add support for LEGO MINDSTORMS EV3 LCD
Den 02.08.2017 00.11, skrev David Lechner:
LEGO MINDSTORMS EV3 has an LCD with a ST7586 controller. This adds a new
module for the ST7586 controller with parameters for the EV3 LCD display.
Signed-off-by: David Lechner
---
.../devicetree/bindings/display/st7586.txt | 26 +
I forgot, the binding doc should be a separate patch.
Noralf.
drivers/gpu/drm/tinydrm/Kconfig| 10 +
drivers/gpu/drm/tinydrm/Makefile | 1 +
drivers/gpu/drm/tinydrm/st7586.c | 579 +
include/drm/tinydrm/st7586.h | 34 ++
5 files changed, 650 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/st7586.txt
create mode 100644 drivers/gpu/drm/tinydrm/st7586.c
create mode 100644 include/drm/tinydrm/st7586.h
diff --git a/Documentation/devicetree/bindings/display/st7586.txt
b/Documentation/devicetree/bindings/display/st7586.txt
new file mode 100644
index 000..acf784aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/st7586.txt
@@ -0,0 +1,26 @@
+Sitronix ST7586 display panel
+
+Required properties:
+- compatible: "lego,ev3-lcd".
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be specified.
+
+Optional properties:
+- dc-gpios:D/C pin. The presence/absence of this GPIO determines
+ the panel interface mode (IM[3:0] pins):
+ - present: IM=x110 4-wire 8-bit data serial interface
+ - absent: IM=x101 3-wire 9-bit data serial interface
+- reset-gpios: Reset pin
+- power-supply:A regulator node for the supply voltage.
+- backlight: phandle of the backlight device attached to the panel
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+
+Example:
+ display@0{
+ compatible = "lego,ev3-lcd";
+ reg = <0>;
+ spi-max-frequency = <1000>;
+ dc-gpios = <&gpio 43 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio 80 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index f17c3ca..2e790e7 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -32,3 +32,13 @@ config TINYDRM_REPAPER
2.71" TFT EPD Panel (E2271CS021)
If M is selected the module will be called repaper.
+
+config TINYDRM_ST7586
+ tristate "DRM support for Sitronix ST7586 display panels"
+ depends on DRM_TINYDRM && SPI
+ select TINYDRM_MIPI_DBI
+ help
+ DRM driver for the following Sitronix ST7586 panels:
+ * LEGO MINDSTORMS EV3
+
+ If M is selected the module will be called st7586.
diff --git a/drivers/gpu/drm/tinydrm/Makefile b/drivers/gpu/drm/tinydrm/Makefile
index 95bb4d4..0c184bd 100644
--- a/drivers/gpu/drm/tinydrm/Makefile
+++ b/drivers/gpu/drm/tinydrm/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_TINYDRM_MIPI_DBI) += mipi-dbi.o
# Displays
obj-$(CONFIG_TINYDRM_MI0283QT)+= mi0283qt.o
obj-$(CONFIG_TINYDRM_REPAPER) += repaper.o
+obj-$(CONFIG_TINYDRM_ST7586) += st7586.o
diff --git a/drivers/gpu/drm/tinydrm/st7586.c b/drivers/gpu/drm/tinydrm/st7586.c
new file mode 100644
index 000..6093021
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/st7586.c
@@ -0,0 +1,579 @@
+/*
+ * DRM driver for Sitronix ST7586 panels
+ *
+ * Copyright 2017 David Lechner
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static inline u8 st7586_rgb565_to_gray2(u16 rgb)
+{
+ u8 r = (rgb & 0xf800) >> 11;
+ u8 g = (rgb & 0x07e0) >> 5;
+ u8 b = rgb & 0x001f;
+ /* ITU BT.601: Y = 0.299 R + 0.587 G + 0.114 B */
+ /* g is already * 2 because it is 6-bit */
+ u8 gray5 = (3 * r + 3 * g + b) / 10;
+
+ return gray5 >> 3;
+}
+
+static void st7586_from_rgb565(u8 *dst, void *vaddr,
+ struct drm_framebuffer *fb,
+ struct drm_clip_rect *clip)
+{
+ size_t len;
+ unsigned int x, y;
+ u16 *src, *buf;
+ u8 val;
+
+ /* 3 pixels per byte, so grow clip to nearest multiple of 3 */
+ clip->x1 = clip->x1 / 3 * 3;
+ clip->x2 = (clip->x2 + 2) / 3 * 3;
+ len = (clip->x2 - clip->x1) * sizeof(u16);
+
+ buf = kmalloc(len, GFP_KERNEL);
+ if (!buf)
+ return;
+
+ for (y = clip->y1; y < clip->y2; y++) {
+ src = vaddr + (y * fb->pitches[0]);
+ src += clip->x1;
+ memcpy(buf, src, len);
+ src
[Bug 102016] build error - pipe_r300.c:12:39: error: ‘flags’ undeclared (first use in this function)
https://bugs.freedesktop.org/show_bug.cgi?id=102016 Bug ID: 102016 Summary: build error - pipe_r300.c:12:39: error: ‘flags’ undeclared (first use in this function) Product: Mesa Version: git Hardware: All OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 Assignee: dri-devel@lists.freedesktop.org Reporter: pedretti.fa...@gmail.com QA Contact: dri-devel@lists.freedesktop.org Full log here: https://launchpadlibrarian.net/331638998/buildlog_ubuntu-xenial-i386.mesa_17.3~git1708021542.44828e~gd~x_BUILDING.txt.gz -- 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 1/4] drm/atomic: implement drm_atomic_helper_commit_tail for runtime_pm users
On Wed, Aug 2, 2017 at 3:27 PM, Laurent Pinchart
wrote:
> Hi Livu,
>
> On Wednesday 02 Aug 2017 13:46:48 Liviu Dudau wrote:
>> On Wed, Aug 02, 2017 at 01:27:23PM +0200, Daniel Vetter wrote:
>> > On Wed, Aug 2, 2017 at 1:20 PM, Liviu Dudau wrote:
>> >> On Thu, Jul 20, 2017 at 03:01:16PM +0200, Maxime Ripard wrote:
>> >>> +/**
>> >>> + * drm_atomic_helper_commit_tail_rpm - commit atomic update to
>> >>> hardware
>> >>> + * @old_state: new modeset state to be committed
>> >>> + *
>> >>> + * This is an alternative implementation for the
>> >>> + * &drm_mode_config_helper_funcs.atomic_commit_tail hook, for drivers
>> >>> + * that support runtime_pm or need the CRTC to be enabled to perform a
>> >>> + * commit. Otherwise, one should use the default implementation
>> >>> + * drm_atomic_helper_commit_tail().
>> >>> + */
>> >>> +void drm_atomic_helper_commit_tail_rpm(struct drm_atomic_state
>> >>> *old_state)
>> >>> +{
>> >>> + struct drm_device *dev = old_state->dev;
>> >>> +
>> >>> + drm_atomic_helper_commit_modeset_disables(dev, old_state);
>> >>> +
>> >>> + drm_atomic_helper_commit_modeset_enables(dev, old_state);
>> >>> +
>> >>> + drm_atomic_helper_commit_planes(dev, old_state,
>> >>> + DRM_PLANE_COMMIT_ACTIVE_ONLY);
>> >>> +
>> >>> + drm_atomic_helper_commit_hw_done(old_state);
>> >>> +
>> >>> + drm_atomic_helper_wait_for_vblanks(dev, old_state);
>> >>> +
>> >>> + drm_atomic_helper_cleanup_planes(dev, old_state);
>> >>> +}
>> >>> +EXPORT_SYMBOL(drm_atomic_helper_commit_tail_rpm);
>> >>> +
>> >>
>> >> Given that this function is supposed to be used by runtime PM aware
>> >> drivers and that the hook is called from the DRM core, should there not
>> >> be some pm_runtime_{get,put} calls wrapping the body of this function?
>>
>> Hi Daniel,
>>
>> > No, because the drm atomic helpers have no idea which device is
>> > backing which part of the drm device. Some drivers might on have one
>> > device for the entire driver, some one device for just the display
>> > part (which might or might not match drm_device->dev). And many arm
>> > drivers have a device for each block separately (and you need to call
>> > rpm_get/put on each). And some something in-between (e.g. core device
>> > + external encoders).
>>
>> Hmm, I understand your point about this function not having to care about
>> pm_runtime_{get,put}, but I do not agree with your view that if it wanted to
>> care about it, it wouldn't be able to do the right thing because it doesn't
>> have the right device. After all, this function is about handling the
>> updates that this atomic commit is concerned about, so having the
>> old_state->dev drm_device pointer and its associated device should be
>> enough. Am I missing something?
>
> In embedded system it's quite common for display hardware to be made of
> multiple IP cores. Depending on the SoC you could have to manage runtime PM at
> the CRTC level for instance. The DRM core doesn't know about that, and sees a
> single device only.
>
> I've expressed my doubts previously about the need for a RPM version of
> drm_atomic_helper_commit_tail(), as the resulting order of CRTC enable/disable
> and plane update operations can lead to corrupt frames when enabling the CRTC.
> I had a commit tail implementation in the rcar-du driver that was very similar
> to drm_atomic_helper_commit_tail_rpm(), and had to move back to the standard
> order to fix the corrupt frame issue. The result isn't as clean as I would
> like, as power handling is split between the CRTC enable/disable and the
> atomic begin/flush in a way that is not straightforward.
>
> It now occurred to me that a simpler implementation could be possible. I'll
> have to experiment with it first, but the idea is as follows.
>
> 1 Call pm_runtime_get_sync() at the beginning of .commit_tail() and
> pm_runtime_put() at the end.
>
> 2. Use the standard CRTC disable, plane update, CRTC enable order in
> .commit_tail().
>
> 3. Call pm_runtime_get() in the CRTC .enable() handler and pm_runtime_put() in
> the CRTC .disable() handler;
>
> This should guarantee that the device won't be suspended between CRTC disable
> and CRTC enable during a mode set, without requiring any special collaboration
> between CRTC enable/disable and atomic begin/flush to handle runtime PM. If
> drivers implement this, there should be no need for
> drm_atomic_helper_commit_tail_rpm().
>
> Maxime, Daniel, what do you think about this ?
Ok, since you just said on irc that the corrupted frame is some random
color, that's indeed not cool. What all other drivers (well at least
i915) do is:
1. Enable the screen, but scan out nothing as a pure black. This might
mean you need to set up the blend unit with a background color of
black.
2. Do an atomic flip to the new screen contents.
This way you get the sequence implement in the new _rpm
implementation. And for most normal hw this gives you the simplest
implementation, and has the benefit
[Bug 102014] Mesa git build broken by commit bc7f41e11d325280db12e7b9444501357bc13922
https://bugs.freedesktop.org/show_bug.cgi?id=102014
--- Comment #4 from Emil Velikov ---
Thanks for the report Marko.
Can you please squash these three patches (analogous to the offending commit)
and send the patch to the list - see
https://www.mesa3d.org/submittingpatches.html for details.
One small correction - one should get the flags from config->flags.
Please include the following in the commit message:
Cc: Nicolai Hähnle
Fixes: bc7f41e11d3 ("gallium: add pipe_screen_config to screen_create
functions")
--
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 3/4] drm/bridge: dw-hdmi: add cec driver
Hi Hans,
On Wednesday 02 Aug 2017 15:34:33 Hans Verkuil wrote:
> On 08/02/17 15:27, Russell King - ARM Linux wrote:
> > On Wed, Aug 02, 2017 at 04:14:34PM +0300, Laurent Pinchart wrote:
> >> On Wednesday 02 Aug 2017 08:47:23 Hans Verkuil wrote:
> >>> On 08/02/2017 12:32 AM, Laurent Pinchart wrote:
> > +
> > + cec_register_cec_notifier(cec->adap, cec->notify);
> > +
> > + return 0;
> > +}
> > +
> > +static int dw_hdmi_cec_remove(struct platform_device *pdev)
> > +{
> > + struct dw_hdmi_cec *cec = platform_get_drvdata(pdev);
> > +
> > + cec_unregister_adapter(cec->adap);
> > + cec_notifier_put(cec->notify);
> > +
> > + return 0;
> > +}
> > +
> > +static struct platform_driver dw_hdmi_cec_driver = {
> > + .probe = dw_hdmi_cec_probe,
> > + .remove = dw_hdmi_cec_remove,
> > + .driver = {
> > + .name = "dw-hdmi-cec",
> > + },
> > +};
> > +module_platform_driver(dw_hdmi_cec_driver);
>
> Is there a particular reason why this has to be a separate module
> instead of simply calling the CEC init/cleanup functions directly from
> the main dw-hdmi driver ?
> >>>
> >>> Not all SoCs that use dw-hdmi also use the dw-hdmi CEC implementation.
> >>> Some use their own implementation (amlogic).
> >>
> >> Lovely. Of course we need to reinvent the wheel every time, where would
> >> the fun be otherwise ?
> >>
> >>> So by implementing the cec-notifier in the dw-hdmi driver and keeping
> >>> dw-hdmi CEC separate you can easily choose whether or not you want to
> >>> use this CEC driver or another SoC CEC driver.
> >>
> >> I'm certainly fine with such a split, but I don't think it requires a
> >> separate platform_driver. We could use a similar approach as with the
> >> HDMI PHY that can also differ between SoCs. The PHY is identified at
> >> runtime when possible, and the SoC-specific glue code can override that
> >> with a few data fields and function pointers.
> >
> > Excuse me if I completely lose interest in reworking the driver at this
> > point, as it's enough of an effort to follow the churn in CEC from one
> > kernel version to another. I'm not about to rewrite the driver and
> > restart the review cycle from scratch and then have several iterations
> > of having to update it as CEC continues to evolve.
> >
> > Let's get this driver in mainline, and then if we want further changes
> > we can do that later.
>
> +1
>
> I also don't think the phy idea applies here. CEC implementations range from
> tightly coupled to the HDMI implementation to a completely independent i2c
> device that is unrelated to any HDMI receiver/transmitter. And various
> shades in between those extremes.
Then it should be even simpler. Instead of creating a separate platform device
for the DW HDMI CEC, we can just call the DW HDMI CEC driver init/cleanup
functions directly when the IP core implements CEC. When it doesn't, a
separate device will be described in DT (at least to my understanding,
otherwise where would it come from ?) and a separate driver would handle it.
> The only thing that is needed is that the CEC device needs to be informed
> when an EDID is read and when the hotplug disappears. The CEC notifier does
> just that and it is already in use, so it is nothing new. No need to rework
> this.
The notifier implementation in patch 1/4 looks good to me (except for the
missing cec_notifier_put() call that I mentioned in my review).
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/4] drm/atomic: implement drm_atomic_helper_commit_tail for runtime_pm users
Hi Liviu,
On Wednesday 02 Aug 2017 14:57:30 Liviu Dudau wrote:
> On Wed, Aug 02, 2017 at 04:49:16PM +0300, Laurent Pinchart wrote:
> > On Wednesday 02 Aug 2017 14:32:06 Liviu Dudau wrote:
> >> On Wed, Aug 02, 2017 at 04:27:27PM +0300, Laurent Pinchart wrote:
> >>> On Wednesday 02 Aug 2017 13:46:48 Liviu Dudau wrote:
> On Wed, Aug 02, 2017 at 01:27:23PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 2, 2017 at 1:20 PM, Liviu Dudau wrote:
> >> On Thu, Jul 20, 2017 at 03:01:16PM +0200, Maxime Ripard wrote:
> >>> +/**
> >>> + * drm_atomic_helper_commit_tail_rpm - commit atomic update to
> >>> hardware
> >>> + * @old_state: new modeset state to be committed
> >>> + *
> >>> + * This is an alternative implementation for the
> >>> + * &drm_mode_config_helper_funcs.atomic_commit_tail hook, for
> >>> drivers
> >>> + * that support runtime_pm or need the CRTC to be enabled to
> >>> perform a
> >>> + * commit. Otherwise, one should use the default implementation
> >>> + * drm_atomic_helper_commit_tail().
> >>> + */
> >>> +void drm_atomic_helper_commit_tail_rpm(struct drm_atomic_state
> >>> *old_state)
> >>> +{
> >>> + struct drm_device *dev = old_state->dev;
> >>> +
> >>> + drm_atomic_helper_commit_modeset_disables(dev, old_state);
> >>> +
> >>> + drm_atomic_helper_commit_modeset_enables(dev, old_state);
> >>> +
> >>> + drm_atomic_helper_commit_planes(dev, old_state,
> >>> +
> >>> DRM_PLANE_COMMIT_ACTIVE_ONLY);
> >>> +
> >>> + drm_atomic_helper_commit_hw_done(old_state);
> >>> +
> >>> + drm_atomic_helper_wait_for_vblanks(dev, old_state);
> >>> +
> >>> + drm_atomic_helper_cleanup_planes(dev, old_state);
> >>> +}
> >>> +EXPORT_SYMBOL(drm_atomic_helper_commit_tail_rpm);
> >>> +
> >>
> >> Given that this function is supposed to be used by runtime PM aware
> >> drivers and that the hook is called from the DRM core, should there
> >> not be some pm_runtime_{get,put} calls wrapping the body of this
> >> function?
>
> Hi Daniel,
>
> > No, because the drm atomic helpers have no idea which device is
> > backing which part of the drm device. Some drivers might on have one
> > device for the entire driver, some one device for just the display
> > part (which might or might not match drm_device->dev). And many arm
> > drivers have a device for each block separately (and you need to
> > call rpm_get/put on each). And some something in-between (e.g. core
> > device + external encoders).
>
> Hmm, I understand your point about this function not having to care
> about pm_runtime_{get,put}, but I do not agree with your view that if
> it wanted to care about it, it wouldn't be able to do the right thing
> because it doesn't have the right device. After all, this function is
> about handling the updates that this atomic commit is concerned
> about, so having the old_state->dev drm_device pointer and its
> associated device should be enough. Am I missing something?
> >>>
> >>> In embedded system it's quite common for display hardware to be made
> >>> of multiple IP cores. Depending on the SoC you could have to manage
> >>> runtime PM at the CRTC level for instance. The DRM core doesn't know
> >>> about that, and sees a single device only.
> >>>
> >>> I've expressed my doubts previously about the need for a RPM version
> >>> of drm_atomic_helper_commit_tail(), as the resulting order of CRTC
> >>> enable/disable and plane update operations can lead to corrupt frames
> >>> when enabling the CRTC. I had a commit tail implementation in the
> >>> rcar-du driver that was very similar to
> >>> drm_atomic_helper_commit_tail_rpm(), and had to move back to the
> >>> standard order to fix the corrupt frame issue. The result isn't as clean
> >>> as I would like, as power handling is split between the CRTC
> >>> enable/disable and the atomic begin/flush in a way that is not
> >>> straightforward.
> >>>
> >>> It now occurred to me that a simpler implementation could be possible.
> >>> I'll have to experiment with it first, but the idea is as follows.
> >>>
> >>> 1 Call pm_runtime_get_sync() at the beginning of .commit_tail() and
> >>> pm_runtime_put() at the end.
> >>>
> >>> 2. Use the standard CRTC disable, plane update, CRTC enable order in
> >>> .commit_tail().
> >>>
> >>> 3. Call pm_runtime_get() in the CRTC .enable() handler and
> >>> pm_runtime_put() in the CRTC .disable() handler;
> >>
> >> Well, that is what mali-dp driver currently does, but according to
> >> Daniel (and I can see his POV) that is wrong.
> >
> > Is it ? I might not have understood his arguments the same way (or
> > possibly failed to even see them). Are you referring to this comments in
> > this mail thread, or to something else ?
>
> I'm talking about his r
Re: [PATCH v2 3/4] drm/bridge: dw-hdmi: add cec driver
On 08/02/2017 03:14 PM, Laurent Pinchart wrote:
> Hi Hans,
>
> On Wednesday 02 Aug 2017 08:47:23 Hans Verkuil wrote:
>> On 08/02/2017 12:32 AM, Laurent Pinchart wrote:
+
+ cec_register_cec_notifier(cec->adap, cec->notify);
+
+ return 0;
+}
+
+static int dw_hdmi_cec_remove(struct platform_device *pdev)
+{
+ struct dw_hdmi_cec *cec = platform_get_drvdata(pdev);
+
+ cec_unregister_adapter(cec->adap);
+ cec_notifier_put(cec->notify);
+
+ return 0;
+}
+
+static struct platform_driver dw_hdmi_cec_driver = {
+ .probe = dw_hdmi_cec_probe,
+ .remove = dw_hdmi_cec_remove,
+ .driver = {
+ .name = "dw-hdmi-cec",
+ },
+};
+module_platform_driver(dw_hdmi_cec_driver);
>>>
>>> Is there a particular reason why this has to be a separate module instead
>>> of simply calling the CEC init/cleanup functions directly from the main
>>> dw-hdmi driver ?
>>
>> Not all SoCs that use dw-hdmi also use the dw-hdmi CEC implementation. Some
>> use their own implementation (amlogic).
>
> Lovely. Of course we need to reinvent the wheel every time, where would the
> fun be otherwise ?
>
>> So by implementing the cec-notifier in the dw-hdmi driver and keeping dw-
>> hdmi CEC separate you can easily choose whether or not you want to use this
>> CEC driver or another SoC CEC driver.
>
> I'm certainly fine with such a split, but I don't think it requires a
> separate
> platform_driver. We could use a similar approach as with the HDMI PHY that
> can
> also differ between SoCs. The PHY is identified at runtime when possible, and
> the SoC-specific glue code can override that with a few data fields and
> function pointers.
The HDMI CEC is in the Synopsys IP like the I2S or AHB Audio, and is optional.
So it's legitimate to handle it in a similar fashion.
Amlogic has a separate custom CEC implementation, having an optional driver
makes it possible to avoid loading unnecessary code like the AHB audio driver
for non-freescale platforms.
>
+MODULE_AUTHOR("Russell King ");
+MODULE_DESCRIPTION("Synopsys Designware HDMI CEC driver for i.MX");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS(PLATFORM_MODULE_PREFIX "dw-hdmi-cec");
>
Yes let's get this merged !
Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: vboxvideo: use drm_gem_object_put instead of drm_gem_object_unreference
On Wed, Aug 2, 2017 at 3:47 PM, Cihangir Akturk wrote: > On Wed, Aug 02, 2017 at 02:38:50PM +0200, Daniel Vetter wrote: >> On Wed, Aug 2, 2017 at 1:46 AM, Cihangir Akturk wrote: >> > drm_gem_object_unreference is a compatibility alias for drm_gem_object_put >> > so should >> > not be used by new code. >> > >> > This patch fixes the following warning reported by coccinelle: >> > >> > drivers/staging/vboxvideo/vbox_main.c:528:1-27: WARNING: use get/put >> > helpers to reference and dereference obj >> > >> > Signed-off-by: Cihangir Akturk >> >> Care to do this for all the drm drivers, not just the single one in staging? > > Sure, I'll send a v2 shortly as you suggested. Patch per driver would be better I think, there's probably going to be a _lot_ of hits. Thanks, Daniel > > Thanks. > >> >> Hans/Greg: Can we pls fix up MAINTAINERS to make sure vboxdrm patches >> also go to dri-devel? >> >> Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/4] drm/bridge: dw-hdmi: add cec notifier support
On 08/02/17 16:11, Laurent Pinchart wrote:
> Hi Russell,
>
> Thank you for the patch.
>
> On Monday 31 Jul 2017 15:29:41 Russell King wrote:
>> Add CEC notifier support to the HDMI bridge driver, so that the CEC
>> part of the IP can receive its physical address.
>>
>> Signed-off-by: Russell King
>> ---
>> drivers/gpu/drm/bridge/synopsys/Kconfig | 1 +
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 22 +-
>> 2 files changed, 22 insertions(+), 1 deletion(-)
>
> [snip]
>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
>> ead11242c4b9..82e55ee8e4fa 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>
> [snip]
>
>> @@ -2376,6 +2387,12 @@ __dw_hdmi_probe(struct platform_device *pdev,
>> if (ret)
>> goto err_iahb;
>>
>> +hdmi->cec_notifier = cec_notifier_get(dev);
>> +if (!hdmi->cec_notifier) {
>> +ret = -ENOMEM;
>> +goto err_iahb;
>> +}
>> +
>> /*
>> * To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator
>> * N and cts values before enabling phy
>> @@ -2452,6 +2469,9 @@ __dw_hdmi_probe(struct platform_device *pdev,
>> hdmi->ddc = NULL;
>> }
>>
>> +if (hdmi->cec_notifier)
>> +cec_notifier_put(hdmi->cec_notifier);
>> +
>> clk_disable_unprepare(hdmi->iahb_clk);
>> err_isfr:
>> clk_disable_unprepare(hdmi->isfr_clk);
>
> I'm not very familiar yet with the CEC API so I made have missed something,
> but shouldn't you call cec_notifier_put() in the remove() handler ?
>
Yes, you should. Well spotted, I missed that one.
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/4] drm/bridge: dw-hdmi: add cec notifier support
Hi Russell,
Thank you for the patch.
On Monday 31 Jul 2017 15:29:41 Russell King wrote:
> Add CEC notifier support to the HDMI bridge driver, so that the CEC
> part of the IP can receive its physical address.
>
> Signed-off-by: Russell King
> ---
> drivers/gpu/drm/bridge/synopsys/Kconfig | 1 +
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 22 +-
> 2 files changed, 22 insertions(+), 1 deletion(-)
[snip]
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> ead11242c4b9..82e55ee8e4fa 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
[snip]
> @@ -2376,6 +2387,12 @@ __dw_hdmi_probe(struct platform_device *pdev,
> if (ret)
> goto err_iahb;
>
> + hdmi->cec_notifier = cec_notifier_get(dev);
> + if (!hdmi->cec_notifier) {
> + ret = -ENOMEM;
> + goto err_iahb;
> + }
> +
> /*
>* To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator
>* N and cts values before enabling phy
> @@ -2452,6 +2469,9 @@ __dw_hdmi_probe(struct platform_device *pdev,
> hdmi->ddc = NULL;
> }
>
> + if (hdmi->cec_notifier)
> + cec_notifier_put(hdmi->cec_notifier);
> +
> clk_disable_unprepare(hdmi->iahb_clk);
> err_isfr:
> clk_disable_unprepare(hdmi->isfr_clk);
I'm not very familiar yet with the CEC API so I made have missed something,
but shouldn't you call cec_notifier_put() in the remove() handler ?
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/4] drm/atomic: implement drm_atomic_helper_commit_tail for runtime_pm users
On Wed, Aug 02, 2017 at 04:49:16PM +0300, Laurent Pinchart wrote:
> Hi Liviu,
>
> On Wednesday 02 Aug 2017 14:32:06 Liviu Dudau wrote:
> > On Wed, Aug 02, 2017 at 04:27:27PM +0300, Laurent Pinchart wrote:
> > > On Wednesday 02 Aug 2017 13:46:48 Liviu Dudau wrote:
> > >> On Wed, Aug 02, 2017 at 01:27:23PM +0200, Daniel Vetter wrote:
> > >>> On Wed, Aug 2, 2017 at 1:20 PM, Liviu Dudau wrote:
> > On Thu, Jul 20, 2017 at 03:01:16PM +0200, Maxime Ripard wrote:
> > > +/**
> > > + * drm_atomic_helper_commit_tail_rpm - commit atomic update to
> > > hardware
> > > + * @old_state: new modeset state to be committed
> > > + *
> > > + * This is an alternative implementation for the
> > > + * &drm_mode_config_helper_funcs.atomic_commit_tail hook, for
> > > drivers
> > > + * that support runtime_pm or need the CRTC to be enabled to
> > > perform a
> > > + * commit. Otherwise, one should use the default implementation
> > > + * drm_atomic_helper_commit_tail().
> > > + */
> > > +void drm_atomic_helper_commit_tail_rpm(struct drm_atomic_state
> > > *old_state)
> > > +{
> > > + struct drm_device *dev = old_state->dev;
> > > +
> > > + drm_atomic_helper_commit_modeset_disables(dev, old_state);
> > > +
> > > + drm_atomic_helper_commit_modeset_enables(dev, old_state);
> > > +
> > > + drm_atomic_helper_commit_planes(dev, old_state,
> > > + DRM_PLANE_COMMIT_ACTIVE_ONLY);
> > > +
> > > + drm_atomic_helper_commit_hw_done(old_state);
> > > +
> > > + drm_atomic_helper_wait_for_vblanks(dev, old_state);
> > > +
> > > + drm_atomic_helper_cleanup_planes(dev, old_state);
> > > +}
> > > +EXPORT_SYMBOL(drm_atomic_helper_commit_tail_rpm);
> > > +
> >
> > Given that this function is supposed to be used by runtime PM aware
> > drivers and that the hook is called from the DRM core, should there
> > not be some pm_runtime_{get,put} calls wrapping the body of this
> > function?
> > >>
> > >> Hi Daniel,
> > >>
> > >>> No, because the drm atomic helpers have no idea which device is
> > >>> backing which part of the drm device. Some drivers might on have one
> > >>> device for the entire driver, some one device for just the display
> > >>> part (which might or might not match drm_device->dev). And many arm
> > >>> drivers have a device for each block separately (and you need to call
> > >>> rpm_get/put on each). And some something in-between (e.g. core device
> > >>> + external encoders).
> > >>
> > >> Hmm, I understand your point about this function not having to care
> > >> about pm_runtime_{get,put}, but I do not agree with your view that if it
> > >> wanted to care about it, it wouldn't be able to do the right thing
> > >> because it doesn't have the right device. After all, this function is
> > >> about handling the updates that this atomic commit is concerned about,
> > >> so having the old_state->dev drm_device pointer and its associated device
> > >> should be enough. Am I missing something?
> > >
> > > In embedded system it's quite common for display hardware to be made of
> > > multiple IP cores. Depending on the SoC you could have to manage runtime
> > > PM at the CRTC level for instance. The DRM core doesn't know about that,
> > > and sees a single device only.
> > >
> > > I've expressed my doubts previously about the need for a RPM version of
> > > drm_atomic_helper_commit_tail(), as the resulting order of CRTC
> > > enable/disable and plane update operations can lead to corrupt frames
> > > when enabling the CRTC. I had a commit tail implementation in the rcar-du
> > > driver that was very similar to drm_atomic_helper_commit_tail_rpm(), and
> > > had to move back to the standard order to fix the corrupt frame issue.
> > > The result isn't as clean as I would like, as power handling is split
> > > between the CRTC enable/disable and the atomic begin/flush in a way that
> > > is not straightforward.
> > >
> > > It now occurred to me that a simpler implementation could be possible.
> > > I'll have to experiment with it first, but the idea is as follows.
> > >
> > > 1 Call pm_runtime_get_sync() at the beginning of .commit_tail() and
> > > pm_runtime_put() at the end.
> > >
> > > 2. Use the standard CRTC disable, plane update, CRTC enable order in
> > > .commit_tail().
> > >
> > > 3. Call pm_runtime_get() in the CRTC .enable() handler and
> > > pm_runtime_put() in the CRTC .disable() handler;
> >
> > Well, that is what mali-dp driver currently does, but according to Daniel
> > (and I can see his POV) that is wrong.
>
> Is it ? I might not have understood his arguments the same way (or possibly
> failed to even see them). Are you referring to this comments in this mail
> thread, or to something else ?
I'm talking about his reply above. My understanding: you can't do
pm_runtime_{get,set} in the atomic_commi
Re: [PATCH v2 1/4] drm/atomic: implement drm_atomic_helper_commit_tail for runtime_pm users
Hi Liviu,
On Wednesday 02 Aug 2017 14:32:06 Liviu Dudau wrote:
> On Wed, Aug 02, 2017 at 04:27:27PM +0300, Laurent Pinchart wrote:
> > On Wednesday 02 Aug 2017 13:46:48 Liviu Dudau wrote:
> >> On Wed, Aug 02, 2017 at 01:27:23PM +0200, Daniel Vetter wrote:
> >>> On Wed, Aug 2, 2017 at 1:20 PM, Liviu Dudau wrote:
> On Thu, Jul 20, 2017 at 03:01:16PM +0200, Maxime Ripard wrote:
> > +/**
> > + * drm_atomic_helper_commit_tail_rpm - commit atomic update to
> > hardware
> > + * @old_state: new modeset state to be committed
> > + *
> > + * This is an alternative implementation for the
> > + * &drm_mode_config_helper_funcs.atomic_commit_tail hook, for
> > drivers
> > + * that support runtime_pm or need the CRTC to be enabled to
> > perform a
> > + * commit. Otherwise, one should use the default implementation
> > + * drm_atomic_helper_commit_tail().
> > + */
> > +void drm_atomic_helper_commit_tail_rpm(struct drm_atomic_state
> > *old_state)
> > +{
> > + struct drm_device *dev = old_state->dev;
> > +
> > + drm_atomic_helper_commit_modeset_disables(dev, old_state);
> > +
> > + drm_atomic_helper_commit_modeset_enables(dev, old_state);
> > +
> > + drm_atomic_helper_commit_planes(dev, old_state,
> > + DRM_PLANE_COMMIT_ACTIVE_ONLY);
> > +
> > + drm_atomic_helper_commit_hw_done(old_state);
> > +
> > + drm_atomic_helper_wait_for_vblanks(dev, old_state);
> > +
> > + drm_atomic_helper_cleanup_planes(dev, old_state);
> > +}
> > +EXPORT_SYMBOL(drm_atomic_helper_commit_tail_rpm);
> > +
>
> Given that this function is supposed to be used by runtime PM aware
> drivers and that the hook is called from the DRM core, should there
> not be some pm_runtime_{get,put} calls wrapping the body of this
> function?
> >>
> >> Hi Daniel,
> >>
> >>> No, because the drm atomic helpers have no idea which device is
> >>> backing which part of the drm device. Some drivers might on have one
> >>> device for the entire driver, some one device for just the display
> >>> part (which might or might not match drm_device->dev). And many arm
> >>> drivers have a device for each block separately (and you need to call
> >>> rpm_get/put on each). And some something in-between (e.g. core device
> >>> + external encoders).
> >>
> >> Hmm, I understand your point about this function not having to care
> >> about pm_runtime_{get,put}, but I do not agree with your view that if it
> >> wanted to care about it, it wouldn't be able to do the right thing
> >> because it doesn't have the right device. After all, this function is
> >> about handling the updates that this atomic commit is concerned about,
> >> so having the old_state->dev drm_device pointer and its associated device
> >> should be enough. Am I missing something?
> >
> > In embedded system it's quite common for display hardware to be made of
> > multiple IP cores. Depending on the SoC you could have to manage runtime
> > PM at the CRTC level for instance. The DRM core doesn't know about that,
> > and sees a single device only.
> >
> > I've expressed my doubts previously about the need for a RPM version of
> > drm_atomic_helper_commit_tail(), as the resulting order of CRTC
> > enable/disable and plane update operations can lead to corrupt frames
> > when enabling the CRTC. I had a commit tail implementation in the rcar-du
> > driver that was very similar to drm_atomic_helper_commit_tail_rpm(), and
> > had to move back to the standard order to fix the corrupt frame issue.
> > The result isn't as clean as I would like, as power handling is split
> > between the CRTC enable/disable and the atomic begin/flush in a way that
> > is not straightforward.
> >
> > It now occurred to me that a simpler implementation could be possible.
> > I'll have to experiment with it first, but the idea is as follows.
> >
> > 1 Call pm_runtime_get_sync() at the beginning of .commit_tail() and
> > pm_runtime_put() at the end.
> >
> > 2. Use the standard CRTC disable, plane update, CRTC enable order in
> > .commit_tail().
> >
> > 3. Call pm_runtime_get() in the CRTC .enable() handler and
> > pm_runtime_put() in the CRTC .disable() handler;
>
> Well, that is what mali-dp driver currently does, but according to Daniel
> (and I can see his POV) that is wrong.
Is it ? I might not have understood his arguments the same way (or possibly
failed to even see them). Are you referring to this comments in this mail
thread, or to something else ?
> I'm playing with removing all of that to see if there are any side effects
> in Mali DP like the ones you mentioned for RCAR.
Note that the first frame will usually not be noticed as it often takes a few
frames for the display to turn on.
> > This should guarantee that the device won't be suspended between CRTC
> > disable and CRTC enable during a mode set, wit
Re: [PATCH v2 3/4] drm/bridge: dw-hdmi: add cec driver
On 08/02/17 15:27, Russell King - ARM Linux wrote:
> On Wed, Aug 02, 2017 at 04:14:34PM +0300, Laurent Pinchart wrote:
>> Hi Hans,
>>
>> On Wednesday 02 Aug 2017 08:47:23 Hans Verkuil wrote:
>>> On 08/02/2017 12:32 AM, Laurent Pinchart wrote:
> +
> + cec_register_cec_notifier(cec->adap, cec->notify);
> +
> + return 0;
> +}
> +
> +static int dw_hdmi_cec_remove(struct platform_device *pdev)
> +{
> + struct dw_hdmi_cec *cec = platform_get_drvdata(pdev);
> +
> + cec_unregister_adapter(cec->adap);
> + cec_notifier_put(cec->notify);
> +
> + return 0;
> +}
> +
> +static struct platform_driver dw_hdmi_cec_driver = {
> + .probe = dw_hdmi_cec_probe,
> + .remove = dw_hdmi_cec_remove,
> + .driver = {
> + .name = "dw-hdmi-cec",
> + },
> +};
> +module_platform_driver(dw_hdmi_cec_driver);
Is there a particular reason why this has to be a separate module instead
of simply calling the CEC init/cleanup functions directly from the main
dw-hdmi driver ?
>>>
>>> Not all SoCs that use dw-hdmi also use the dw-hdmi CEC implementation. Some
>>> use their own implementation (amlogic).
>>
>> Lovely. Of course we need to reinvent the wheel every time, where would the
>> fun be otherwise ?
>>
>>> So by implementing the cec-notifier in the dw-hdmi driver and keeping dw-
>>> hdmi CEC separate you can easily choose whether or not you want to use this
>>> CEC driver or another SoC CEC driver.
>>
>> I'm certainly fine with such a split, but I don't think it requires a
>> separate
>> platform_driver. We could use a similar approach as with the HDMI PHY that
>> can
>> also differ between SoCs. The PHY is identified at runtime when possible,
>> and
>> the SoC-specific glue code can override that with a few data fields and
>> function pointers.
>
> Excuse me if I completely lose interest in reworking the driver at this
> point, as it's enough of an effort to follow the churn in CEC from one
> kernel version to another. I'm not about to rewrite the driver and
> restart the review cycle from scratch and then have several iterations
> of having to update it as CEC continues to evolve.
>
> Let's get this driver in mainline, and then if we want further changes
> we can do that later.
+1
I also don't think the phy idea applies here. CEC implementations range from
tightly coupled to the HDMI implementation to a completely independent i2c
device that is unrelated to any HDMI receiver/transmitter. And various shades
in between those extremes.
The only thing that is needed is that the CEC device needs to be informed when
an EDID is read and when the hotplug disappears. The CEC notifier does just
that and it is already in use, so it is nothing new. No need to rework this.
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/4] drm/atomic: implement drm_atomic_helper_commit_tail for runtime_pm users
On Wed, Aug 02, 2017 at 04:27:27PM +0300, Laurent Pinchart wrote:
> Hi Livu,
>
> On Wednesday 02 Aug 2017 13:46:48 Liviu Dudau wrote:
> > On Wed, Aug 02, 2017 at 01:27:23PM +0200, Daniel Vetter wrote:
> > > On Wed, Aug 2, 2017 at 1:20 PM, Liviu Dudau wrote:
> > >> On Thu, Jul 20, 2017 at 03:01:16PM +0200, Maxime Ripard wrote:
> > >>> +/**
> > >>> + * drm_atomic_helper_commit_tail_rpm - commit atomic update to
> > >>> hardware
> > >>> + * @old_state: new modeset state to be committed
> > >>> + *
> > >>> + * This is an alternative implementation for the
> > >>> + * &drm_mode_config_helper_funcs.atomic_commit_tail hook, for drivers
> > >>> + * that support runtime_pm or need the CRTC to be enabled to perform a
> > >>> + * commit. Otherwise, one should use the default implementation
> > >>> + * drm_atomic_helper_commit_tail().
> > >>> + */
> > >>> +void drm_atomic_helper_commit_tail_rpm(struct drm_atomic_state
> > >>> *old_state)
> > >>> +{
> > >>> + struct drm_device *dev = old_state->dev;
> > >>> +
> > >>> + drm_atomic_helper_commit_modeset_disables(dev, old_state);
> > >>> +
> > >>> + drm_atomic_helper_commit_modeset_enables(dev, old_state);
> > >>> +
> > >>> + drm_atomic_helper_commit_planes(dev, old_state,
> > >>> + DRM_PLANE_COMMIT_ACTIVE_ONLY);
> > >>> +
> > >>> + drm_atomic_helper_commit_hw_done(old_state);
> > >>> +
> > >>> + drm_atomic_helper_wait_for_vblanks(dev, old_state);
> > >>> +
> > >>> + drm_atomic_helper_cleanup_planes(dev, old_state);
> > >>> +}
> > >>> +EXPORT_SYMBOL(drm_atomic_helper_commit_tail_rpm);
> > >>> +
> > >>
> > >> Given that this function is supposed to be used by runtime PM aware
> > >> drivers and that the hook is called from the DRM core, should there not
> > >> be some pm_runtime_{get,put} calls wrapping the body of this function?
> >
> > Hi Daniel,
> >
> > > No, because the drm atomic helpers have no idea which device is
> > > backing which part of the drm device. Some drivers might on have one
> > > device for the entire driver, some one device for just the display
> > > part (which might or might not match drm_device->dev). And many arm
> > > drivers have a device for each block separately (and you need to call
> > > rpm_get/put on each). And some something in-between (e.g. core device
> > > + external encoders).
> >
> > Hmm, I understand your point about this function not having to care about
> > pm_runtime_{get,put}, but I do not agree with your view that if it wanted to
> > care about it, it wouldn't be able to do the right thing because it doesn't
> > have the right device. After all, this function is about handling the
> > updates that this atomic commit is concerned about, so having the
> > old_state->dev drm_device pointer and its associated device should be
> > enough. Am I missing something?
>
> In embedded system it's quite common for display hardware to be made of
> multiple IP cores. Depending on the SoC you could have to manage runtime PM
> at
> the CRTC level for instance. The DRM core doesn't know about that, and sees a
> single device only.
>
> I've expressed my doubts previously about the need for a RPM version of
> drm_atomic_helper_commit_tail(), as the resulting order of CRTC
> enable/disable
> and plane update operations can lead to corrupt frames when enabling the
> CRTC.
> I had a commit tail implementation in the rcar-du driver that was very
> similar
> to drm_atomic_helper_commit_tail_rpm(), and had to move back to the standard
> order to fix the corrupt frame issue. The result isn't as clean as I would
> like, as power handling is split between the CRTC enable/disable and the
> atomic begin/flush in a way that is not straightforward.
>
> It now occurred to me that a simpler implementation could be possible. I'll
> have to experiment with it first, but the idea is as follows.
>
> 1 Call pm_runtime_get_sync() at the beginning of .commit_tail() and
> pm_runtime_put() at the end.
>
> 2. Use the standard CRTC disable, plane update, CRTC enable order in
> .commit_tail().
>
> 3. Call pm_runtime_get() in the CRTC .enable() handler and pm_runtime_put()
> in
> the CRTC .disable() handler;
Well, that is what mali-dp driver currently does, but according to Daniel
(and I can see his POV) that is wrong. I'm playing with removing all of that
to see if there are any side effects in Mali DP like the ones you mentioned for
RCAR.
Best regards,
Liviu
>
> This should guarantee that the device won't be suspended between CRTC disable
> and CRTC enable during a mode set, without requiring any special
> collaboration
> between CRTC enable/disable and atomic begin/flush to handle runtime PM. If
> drivers implement this, there should be no need for
> drm_atomic_helper_commit_tail_rpm().
>
> Maxime, Daniel, what do you think about this ?
>
> > > I don't think there's anything the helpers can to to help support this.
> > >
> > > Also, just wrapping functions with rpm_
[Bug 100306] System randomly freezes or crashes to the login screen, glitches until rebooted
https://bugs.freedesktop.org/show_bug.cgi?id=100306 --- Comment #33 from MirceaKitsune --- After months of careful testing and experimentation, I have discovered what seems to be the primary trigger of this freeze at last. It's not what triggers it per say, but what "rigs" the system and causes it to crash within the course of the next hours... the actual trigger is alt-tab switching between windows, or certain desktop effects playing. The freeze is mined into the system when you disable and re-enable KDE desktop compositing. If I hit Alt + Shift + F12 to turn off desktop effects, then hit the key combo to turn them back on... there is a great chance that within a few hours the crash occurs. If I don't toggle compositing on the run and just leave it enabled after the system has started, I seem to be fine... this only happens if I turn it off and back on during runtime. It's uncertain whether anything else mines the system, but this is almost always what seems to do it for me. Notice: I use OpenGL 3.1 for desktop compositing. I remember selecting OpenGL 2.0 long ago, but that still caused the freeze at that time. I can't use Xrender on a daily basis as many effects don't work with it. No other compositor options seem to affect the problem either. It would be highly appreciated if at least after this information, the developers and maintainers could finally look at this issue! It has taken me months to confirm this as a cause, and I really hope this information (alongside dozens of comments and logs I have posted) can finally be put to use. -- 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 1/4] drm/atomic: implement drm_atomic_helper_commit_tail for runtime_pm users
Hi Livu,
On Wednesday 02 Aug 2017 13:46:48 Liviu Dudau wrote:
> On Wed, Aug 02, 2017 at 01:27:23PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 2, 2017 at 1:20 PM, Liviu Dudau wrote:
> >> On Thu, Jul 20, 2017 at 03:01:16PM +0200, Maxime Ripard wrote:
> >>> +/**
> >>> + * drm_atomic_helper_commit_tail_rpm - commit atomic update to
> >>> hardware
> >>> + * @old_state: new modeset state to be committed
> >>> + *
> >>> + * This is an alternative implementation for the
> >>> + * &drm_mode_config_helper_funcs.atomic_commit_tail hook, for drivers
> >>> + * that support runtime_pm or need the CRTC to be enabled to perform a
> >>> + * commit. Otherwise, one should use the default implementation
> >>> + * drm_atomic_helper_commit_tail().
> >>> + */
> >>> +void drm_atomic_helper_commit_tail_rpm(struct drm_atomic_state
> >>> *old_state)
> >>> +{
> >>> + struct drm_device *dev = old_state->dev;
> >>> +
> >>> + drm_atomic_helper_commit_modeset_disables(dev, old_state);
> >>> +
> >>> + drm_atomic_helper_commit_modeset_enables(dev, old_state);
> >>> +
> >>> + drm_atomic_helper_commit_planes(dev, old_state,
> >>> + DRM_PLANE_COMMIT_ACTIVE_ONLY);
> >>> +
> >>> + drm_atomic_helper_commit_hw_done(old_state);
> >>> +
> >>> + drm_atomic_helper_wait_for_vblanks(dev, old_state);
> >>> +
> >>> + drm_atomic_helper_cleanup_planes(dev, old_state);
> >>> +}
> >>> +EXPORT_SYMBOL(drm_atomic_helper_commit_tail_rpm);
> >>> +
> >>
> >> Given that this function is supposed to be used by runtime PM aware
> >> drivers and that the hook is called from the DRM core, should there not
> >> be some pm_runtime_{get,put} calls wrapping the body of this function?
>
> Hi Daniel,
>
> > No, because the drm atomic helpers have no idea which device is
> > backing which part of the drm device. Some drivers might on have one
> > device for the entire driver, some one device for just the display
> > part (which might or might not match drm_device->dev). And many arm
> > drivers have a device for each block separately (and you need to call
> > rpm_get/put on each). And some something in-between (e.g. core device
> > + external encoders).
>
> Hmm, I understand your point about this function not having to care about
> pm_runtime_{get,put}, but I do not agree with your view that if it wanted to
> care about it, it wouldn't be able to do the right thing because it doesn't
> have the right device. After all, this function is about handling the
> updates that this atomic commit is concerned about, so having the
> old_state->dev drm_device pointer and its associated device should be
> enough. Am I missing something?
In embedded system it's quite common for display hardware to be made of
multiple IP cores. Depending on the SoC you could have to manage runtime PM at
the CRTC level for instance. The DRM core doesn't know about that, and sees a
single device only.
I've expressed my doubts previously about the need for a RPM version of
drm_atomic_helper_commit_tail(), as the resulting order of CRTC enable/disable
and plane update operations can lead to corrupt frames when enabling the CRTC.
I had a commit tail implementation in the rcar-du driver that was very similar
to drm_atomic_helper_commit_tail_rpm(), and had to move back to the standard
order to fix the corrupt frame issue. The result isn't as clean as I would
like, as power handling is split between the CRTC enable/disable and the
atomic begin/flush in a way that is not straightforward.
It now occurred to me that a simpler implementation could be possible. I'll
have to experiment with it first, but the idea is as follows.
1 Call pm_runtime_get_sync() at the beginning of .commit_tail() and
pm_runtime_put() at the end.
2. Use the standard CRTC disable, plane update, CRTC enable order in
.commit_tail().
3. Call pm_runtime_get() in the CRTC .enable() handler and pm_runtime_put() in
the CRTC .disable() handler;
This should guarantee that the device won't be suspended between CRTC disable
and CRTC enable during a mode set, without requiring any special collaboration
between CRTC enable/disable and atomic begin/flush to handle runtime PM. If
drivers implement this, there should be no need for
drm_atomic_helper_commit_tail_rpm().
Maxime, Daniel, what do you think about this ?
> > I don't think there's anything the helpers can to to help support this.
> >
> > Also, just wrapping functions with rpm_get/put only papers over bugs
> > in your driver - either you enable something, then the rpm_get needs
> > to be done anyway (since the hw will be shut down otherwise), or you
> > disable something, same reasons. The only thing a rpm_get/put does is
> > paper over the bugs where you try to access the hw when it's off. As
> > soon as this function finishes, the hw is shut down again, drops all
> > register values on the floor, so either that access wasn't needed, or
> > your driver has a bug (because it assumes the register values sur
[PATCH] drm/omap: Rework the rotation-on-crtc hack
Op 02-08-17 om 10:02 schreef Daniel Vetter:
> On Tue, Aug 1, 2017 at 12:20 PM, Laurent Pinchart
> wrote:
>> On Tuesday 01 Aug 2017 07:59:13 Maarten Lankhorst wrote:
>>> + pri_state = drm_atomic_get_new_plane_state(crtc->primary,
>>> state->state);
>>> + if (pri_state) {
>>> + struct omap_crtc_state *omap_crtc_state =
>>> + to_omap_crtc_state(state);
>>> +
>>> + omap_crtc_state->zpos = pri_state->zpos;
>>> + omap_crtc_state->rotation = pri_state->rotation;
>>> + }
>>>
>>> That way even when updating the property through the primary plane, it gets
>>> reflected correctly. For example when vt switching with fbdev.
>> Let's not make it over-complicated. This hack is only needed fo the legacy X
>> OMAP modesetting driver. The CRTC zpos and rotation properties should not be
>> used through the atomic API.
> Marten is right, the atomic properties are all such that you can
> unconditionally restore them (e.g. fences report a no-op value), to
> make compositor switching easier. Not sure anyone implements that, but
> I think it's a useful idea to keep. I'll respin (or maybe Maarten
> simply submits his patch with a proper sob ...).
> -Daniel
Here you go, compile tested version. :)
8<
I want/need to rework the core property handling, and this hack is
getting in the way. But since it's a non-standard propety only used by
legacy userspace we know that this will only every be called from
ioctl code. And never on some other free-standing state struct, where
this old hack wouldn't work either.
v2: don't forget zorder and get_property!
v3: Shadow the legacy state to avoid locking issues in get_property
(Maarten).
v4: Review from Laurent
- Move struct omap_crtc_state into omap_crtc.c
- Clean up comments.
- Don't forget to copy the shadowed state over on duplicate.
v5: Don't forget to update the reset handler (Maarten).
v6: Update omap_crtc_state shadow values in omap_crtc_atomic_check (Maarten).
Reviewed-by: Laurent Pinchart (v4)
Cc: Maarten Lankhorst
Cc: Tomi Valkeinen
Signed-off-by: Daniel Vetter
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 118 +---
1 file changed, 81 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 14e8a7738b06..b842fcd9914a 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -26,6 +26,16 @@
#include "omap_drv.h"
+#define to_omap_crtc_state(x) container_of(x, struct omap_crtc_state, base)
+
+struct omap_crtc_state {
+ /* Must be first. */
+ struct drm_crtc_state base;
+ /* Shadow values for legacy userspace support. */
+ unsigned int rotation;
+ unsigned int zpos;
+};
+
#define to_omap_crtc(x) container_of(x, struct omap_crtc, base)
struct omap_crtc {
@@ -445,6 +455,8 @@ static void omap_crtc_mode_set_nofb(struct drm_crtc *crtc)
static int omap_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_crtc_state *state)
{
+ struct drm_plane_state *pri_state;
+
if (state->color_mgmt_changed && state->gamma_lut) {
uint length = state->gamma_lut->length /
sizeof(struct drm_color_lut);
@@ -453,6 +465,16 @@ static int omap_crtc_atomic_check(struct drm_crtc *crtc,
return -EINVAL;
}
+ pri_state = drm_atomic_get_new_plane_state(state->state, crtc->primary);
+ if (pri_state) {
+ struct omap_crtc_state *omap_crtc_state =
+ to_omap_crtc_state(state);
+
+ /* Mirror new values for zpos and rotation in omap_crtc_state */
+ omap_crtc_state->zpos = pri_state->zpos;
+ omap_crtc_state->rotation = pri_state->rotation;
+ }
+
return 0;
}
@@ -498,39 +520,32 @@ static void omap_crtc_atomic_flush(struct drm_crtc *crtc,
spin_unlock_irq(&crtc->dev->event_lock);
}
-static bool omap_crtc_is_plane_prop(struct drm_crtc *crtc,
- struct drm_property *property)
-{
- struct drm_device *dev = crtc->dev;
- struct omap_drm_private *priv = dev->dev_private;
-
- return property == priv->zorder_prop ||
- property == crtc->primary->rotation_property;
-}
-
static int omap_crtc_atomic_set_property(struct drm_crtc *crtc,
struct drm_crtc_state *state,
struct drm_property *property,
uint64_t val)
{
- if (omap_crtc_is_plane_prop(crtc, property)) {
- struct drm_plane_state *plane_state;
- struct drm_plane *plane = crtc->primary;
-
- /*
-* Delegate property set to the primary plane. Get the plane
-* state and set the property directly.
-*/
-
-
Re: [PATCH v2 3/4] drm/bridge: dw-hdmi: add cec driver
Hi Hans,
On Wednesday 02 Aug 2017 08:47:23 Hans Verkuil wrote:
> On 08/02/2017 12:32 AM, Laurent Pinchart wrote:
> >> +
> >> + cec_register_cec_notifier(cec->adap, cec->notify);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static int dw_hdmi_cec_remove(struct platform_device *pdev)
> >> +{
> >> + struct dw_hdmi_cec *cec = platform_get_drvdata(pdev);
> >> +
> >> + cec_unregister_adapter(cec->adap);
> >> + cec_notifier_put(cec->notify);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static struct platform_driver dw_hdmi_cec_driver = {
> >> + .probe = dw_hdmi_cec_probe,
> >> + .remove = dw_hdmi_cec_remove,
> >> + .driver = {
> >> + .name = "dw-hdmi-cec",
> >> + },
> >> +};
> >> +module_platform_driver(dw_hdmi_cec_driver);
> >
> > Is there a particular reason why this has to be a separate module instead
> > of simply calling the CEC init/cleanup functions directly from the main
> > dw-hdmi driver ?
>
> Not all SoCs that use dw-hdmi also use the dw-hdmi CEC implementation. Some
> use their own implementation (amlogic).
Lovely. Of course we need to reinvent the wheel every time, where would the
fun be otherwise ?
> So by implementing the cec-notifier in the dw-hdmi driver and keeping dw-
> hdmi CEC separate you can easily choose whether or not you want to use this
> CEC driver or another SoC CEC driver.
I'm certainly fine with such a split, but I don't think it requires a separate
platform_driver. We could use a similar approach as with the HDMI PHY that can
also differ between SoCs. The PHY is identified at runtime when possible, and
the SoC-specific glue code can override that with a few data fields and
function pointers.
> >> +MODULE_AUTHOR("Russell King ");
> >> +MODULE_DESCRIPTION("Synopsys Designware HDMI CEC driver for i.MX");
> >> +MODULE_LICENSE("GPL");
> >> +MODULE_ALIAS(PLATFORM_MODULE_PREFIX "dw-hdmi-cec");
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/4] drm/tinydrm: add support for LEGO MINDSTORMS EV3 LCD
Den 02.08.2017 00.11, skrev David Lechner:
LEGO MINDSTORMS EV3 has an LCD with a ST7586 controller. This adds a new
module for the ST7586 controller with parameters for the EV3 LCD display.
Signed-off-by: David Lechner
---
.../devicetree/bindings/display/st7586.txt | 26 +
drivers/gpu/drm/tinydrm/Kconfig| 10 +
drivers/gpu/drm/tinydrm/Makefile | 1 +
drivers/gpu/drm/tinydrm/st7586.c | 579 +
include/drm/tinydrm/st7586.h | 34 ++
Please add a MAINTAINERS entry.
That way you'll be notified on changes.
5 files changed, 650 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/st7586.txt
create mode 100644 drivers/gpu/drm/tinydrm/st7586.c
create mode 100644 include/drm/tinydrm/st7586.h
diff --git a/Documentation/devicetree/bindings/display/st7586.txt
b/Documentation/devicetree/bindings/display/st7586.txt
new file mode 100644
index 000..acf784aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/st7586.txt
@@ -0,0 +1,26 @@
+Sitronix ST7586 display panel
+
+Required properties:
+- compatible: "lego,ev3-lcd".
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be specified.
+
+Optional properties:
+- dc-gpios:D/C pin. The presence/absence of this GPIO determines
+ the panel interface mode (IM[3:0] pins):
+ - present: IM=x110 4-wire 8-bit data serial interface
+ - absent: IM=x101 3-wire 9-bit data serial interface
This doesn't match the ST7586 datasheet I have, the pins are called
IF[3:1] and the values are different.
+- reset-gpios: Reset pin
+- power-supply:A regulator node for the supply voltage.
+- backlight: phandle of the backlight device attached to the panel
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+
+Example:
+ display@0{
+ compatible = "lego,ev3-lcd";
+ reg = <0>;
+ spi-max-frequency = <1000>;
+ dc-gpios = <&gpio 43 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio 80 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index f17c3ca..2e790e7 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -32,3 +32,13 @@ config TINYDRM_REPAPER
2.71" TFT EPD Panel (E2271CS021)
If M is selected the module will be called repaper.
+
+config TINYDRM_ST7586
+ tristate "DRM support for Sitronix ST7586 display panels"
+ depends on DRM_TINYDRM && SPI
+ select TINYDRM_MIPI_DBI
+ help
+ DRM driver for the following Sitronix ST7586 panels:
+ * LEGO MINDSTORMS EV3
+
+ If M is selected the module will be called st7586.
diff --git a/drivers/gpu/drm/tinydrm/Makefile b/drivers/gpu/drm/tinydrm/Makefile
index 95bb4d4..0c184bd 100644
--- a/drivers/gpu/drm/tinydrm/Makefile
+++ b/drivers/gpu/drm/tinydrm/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_TINYDRM_MIPI_DBI) += mipi-dbi.o
# Displays
obj-$(CONFIG_TINYDRM_MI0283QT)+= mi0283qt.o
obj-$(CONFIG_TINYDRM_REPAPER) += repaper.o
+obj-$(CONFIG_TINYDRM_ST7586) += st7586.o
diff --git a/drivers/gpu/drm/tinydrm/st7586.c b/drivers/gpu/drm/tinydrm/st7586.c
new file mode 100644
index 000..6093021
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/st7586.c
@@ -0,0 +1,579 @@
+/*
+ * DRM driver for Sitronix ST7586 panels
+ *
+ * Copyright 2017 David Lechner
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static inline u8 st7586_rgb565_to_gray2(u16 rgb)
+{
+ u8 r = (rgb & 0xf800) >> 11;
+ u8 g = (rgb & 0x07e0) >> 5;
+ u8 b = rgb & 0x001f;
+ /* ITU BT.601: Y = 0.299 R + 0.587 G + 0.114 B */
+ /* g is already * 2 because it is 6-bit */
+ u8 gray5 = (3 * r + 3 * g + b) / 10;
+
+ return gray5 >> 3;
+}
+
+static void st7586_from_rgb565(u8 *dst, void *vaddr,
+ struct drm_framebuffer *fb,
+ struct drm_clip_rect *clip)
+{
+ size_t len;
+ unsigned int x, y;
+ u16 *src, *buf;
+ u8 val;
+
+ /* 3 pixels per byte, so grow clip to nearest multiple of 3 */
+ clip->x1 = clip->x1 / 3 * 3;
+ clip->x2 = (clip->x2 + 2) / 3 * 3;
+ len = (clip->x2 - clip->x1) * sizeof(u16);
+
+ buf = kmalloc(len, GFP_KERNEL);
+ if (!buf)
+ return;
+
+ for (y = clip->y1; y < clip->y2; y++) {
+ src = vad
[Bug 102014] Mesa git build broken by commit bc7f41e11d325280db12e7b9444501357bc13922
https://bugs.freedesktop.org/show_bug.cgi?id=102014 --- Comment #3 from Marko --- Created attachment 133198 --> https://bugs.freedesktop.org/attachment.cgi?id=133198&action=edit Patch #3 to fix build -- 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 102014] Mesa git build broken by commit bc7f41e11d325280db12e7b9444501357bc13922
https://bugs.freedesktop.org/show_bug.cgi?id=102014 --- Comment #2 from Marko --- Created attachment 133197 --> https://bugs.freedesktop.org/attachment.cgi?id=133197&action=edit Patch #2 to fix build -- 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 102014] Mesa git build broken by commit bc7f41e11d325280db12e7b9444501357bc13922
https://bugs.freedesktop.org/show_bug.cgi?id=102014 --- Comment #1 from Marko --- Created attachment 133196 --> https://bugs.freedesktop.org/attachment.cgi?id=133196&action=edit Patch #1 to fix build -- 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 102014] Mesa git build broken by commit bc7f41e11d325280db12e7b9444501357bc13922
https://bugs.freedesktop.org/show_bug.cgi?id=102014 Bug ID: 102014 Summary: Mesa git build broken by commit bc7f41e11d325280db12e7b9444501357bc13922 Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: marko.sken...@protonmail.com QA Contact: dri-devel@lists.freedesktop.org Hello, Current git build is seemingly broken by: [ 511s] pipe_radeonsi.c: In function 'create_screen': [ 511s] pipe_radeonsi.c:15:34: error: 'flags' undeclared (first use in this function); did you mean 'fabs'? [ 511s] rw = amdgpu_winsys_create(fd, flags, radeonsi_screen_create); [ 511s] ^ [ 511s] fabs [ 511s] pipe_radeonsi.c:15:34: note: each undeclared identifier is reported only once for each function it appears in [ 511s] make[4]: *** [Makefile:996: pipe_radeonsi.lo] Error 1 [ 511s] make[4]: *** Waiting for unfinished jobs [ 511s] pipe_r600.c: In function 'create_screen': [ 511s] pipe_r600.c:12:38: error: 'flags' undeclared (first use in this function); did you mean 'fabs'? [ 511s] rw = radeon_drm_winsys_create(fd, flags, r600_screen_create); [ 511s] ^ [ 511s] fabs [ 511s] pipe_r600.c:12:38: note: each undeclared identifier is reported only once for each function it appears in [ 511s] pipe_r300.c: In function 'create_screen': [ 511s] pipe_r300.c:12:39: error: 'flags' undeclared (first use in this function); did you mean 'fabs'? [ 511s] sws = radeon_drm_winsys_create(fd, flags, r300_screen_create); [ 511s]^ [ 511s]fabs Regards, Marko -- 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 1/4] drm/atomic: implement drm_atomic_helper_commit_tail for runtime_pm users
On Wed, Aug 02, 2017 at 01:27:23PM +0200, Daniel Vetter wrote:
> On Wed, Aug 2, 2017 at 1:20 PM, Liviu Dudau wrote:
> > On Thu, Jul 20, 2017 at 03:01:16PM +0200, Maxime Ripard wrote:
> >> +/**
> >> + * drm_atomic_helper_commit_tail_rpm - commit atomic update to hardware
> >> + * @old_state: new modeset state to be committed
> >> + *
> >> + * This is an alternative implementation for the
> >> + * &drm_mode_config_helper_funcs.atomic_commit_tail hook, for drivers
> >> + * that support runtime_pm or need the CRTC to be enabled to perform a
> >> + * commit. Otherwise, one should use the default implementation
> >> + * drm_atomic_helper_commit_tail().
> >> + */
> >> +void drm_atomic_helper_commit_tail_rpm(struct drm_atomic_state *old_state)
> >> +{
> >> + struct drm_device *dev = old_state->dev;
> >> +
> >> + drm_atomic_helper_commit_modeset_disables(dev, old_state);
> >> +
> >> + drm_atomic_helper_commit_modeset_enables(dev, old_state);
> >> +
> >> + drm_atomic_helper_commit_planes(dev, old_state,
> >> + DRM_PLANE_COMMIT_ACTIVE_ONLY);
> >> +
> >> + drm_atomic_helper_commit_hw_done(old_state);
> >> +
> >> + drm_atomic_helper_wait_for_vblanks(dev, old_state);
> >> +
> >> + drm_atomic_helper_cleanup_planes(dev, old_state);
> >> +}
> >> +EXPORT_SYMBOL(drm_atomic_helper_commit_tail_rpm);
> >> +
> >
> > Given that this function is supposed to be used by runtime PM aware
> > drivers and that the hook is called from the DRM core, should there not
> > be some pm_runtime_{get,put} calls wrapping the body of this function?
Hi Daniel,
>
> No, because the drm atomic helpers have no idea which device is
> backing which part of the drm device. Some drivers might on have one
> device for the entire driver, some one device for just the display
> part (which might or might not match drm_device->dev). And many arm
> drivers have a device for each block separately (and you need to call
> rpm_get/put on each). And some something in-between (e.g. core device
> + external encoders).
Hmm, I understand your point about this function not having to care about
pm_runtime_{get,put}, but I do not agree with your view that if it wanted to
care about it, it wouldn't be able to do the right thing because it doesn't
have the right device. After all, this function is about handling the
updates that this atomic commit is concerned about, so having the
old_state->dev drm_device pointer and its associated device should be
enough. Am I missing something?
>
> I don't think there's anything the helpers can to to help support this.
>
> Also, just wrapping functions with rpm_get/put only papers over bugs
> in your driver - either you enable something, then the rpm_get needs
> to be done anyway (since the hw will be shut down otherwise), or you
> disable something, same reasons. The only thing a rpm_get/put does is
> paper over the bugs where you try to access the hw when it's off. As
> soon as this function finishes, the hw is shut down again, drops all
> register values on the floor, so either that access wasn't needed, or
> your driver has a bug (because it assumes the register values survive
> when they don't).
>
> So imo all around a bad idea, at least from my experience of doing rpm
> enabling on i915 hw.
Understood. Thanks!
Best regards,
Liviu
> -Daniel
>
> >
> > Best regards,
> > Liviu
> >
> >
> >> static void commit_tail(struct drm_atomic_state *old_state)
> >> {
> >> struct drm_device *dev = old_state->dev;
> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> >> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> >> index d48fd7c918f8..ed1a648d518c 100644
> >> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> >> @@ -187,33 +187,8 @@ dma_addr_t exynos_drm_fb_dma_addr(struct
> >> drm_framebuffer *fb, int index)
> >> return exynos_fb->dma_addr[index];
> >> }
> >>
> >> -static void exynos_drm_atomic_commit_tail(struct drm_atomic_state *state)
> >> -{
> >> - struct drm_device *dev = state->dev;
> >> -
> >> - drm_atomic_helper_commit_modeset_disables(dev, state);
> >> -
> >> - drm_atomic_helper_commit_modeset_enables(dev, state);
> >> -
> >> - /*
> >> - * Exynos can't update planes with CRTCs and encoders disabled,
> >> - * its updates routines, specially for FIMD, requires the clocks
> >> - * to be enabled. So it is necessary to handle the modeset operations
> >> - * *before* the commit_planes() step, this way it will always
> >> - * have the relevant clocks enabled to perform the update.
> >> - */
> >> - drm_atomic_helper_commit_planes(dev, state,
> >> - DRM_PLANE_COMMIT_ACTIVE_ONLY);
> >> -
> >> - drm_atomic_helper_commit_hw_done(state);
> >> -
> >> - drm_atomic_helper_wait_for_vblanks(dev, state);
> >> -
> >> - drm_atomic_helper_cleanup_planes(dev, state);
> >> -}
> >> -
> >> static struct drm_mode_config_helper_
Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900
On Wed, Aug 2, 2017 at 1:54 PM, Tomi Valkeinen wrote:
> On 02/08/17 13:12, Daniel Vetter wrote:
>> On Mon, Jul 31, 2017 at 04:21:51PM +0300, Tomi Valkeinen wrote:
>>> On 30/06/17 15:36, Daniel Vetter wrote:
>>>
I don't think registering before everything is loaded make sense. On the
big desktop driver chips we have all the bridge/encoder/panel drivers
built into the driver. arm-soc loves to make everything a separate module,
but in the end if you decided to not compile half of the driver you need,
then it's not going to work.
>>>
>>> I don't think that's quite the same. On the desktop you just have the
>>> video card, and it's easy to enable that single component. On an
>>> embedded device you have the SoC's display controller and then possibly
>>> multiple external encoders/panels on the board. Those external
>>> components have to be separate modules, they can't be part of the SoC
>>> driver. The desktop video card matches only to the SoC's display controller.
>>
>> Please take a look at the encoder drivers both nouveau and i915 have had
>> (for older hw). In neither of these cases did we register an incomplete
>> driver.
>>
Imo the only thing we should support to be hotplugged in drm is stuff you
can physically hotplug (like atm connectors). Everything else just
complicates the code for no good reason at all.
>>>
>>> "unplugging" components would not give much, I think, but allowing
>>> adding new displays at runtime would be a very good thing.
>>
>> We do, just register another drm_device.
>
> But a drm_device is the display controller ("graphics card") side of the
> whole, isn't it? Well, that's not exactly true, it also contains the
> output side, like panel, but it's the display controller that defines
> how many drm_devices we have.
This was a reply to "Adding new displays at runtime". We support that,
by either hotplugging drm_device or drm_connector. Not anything else.
And there's not a real-world use-case as in "you can physically
hotplug it" to support more, at least for now. There's a design
problem in armsoc (you're not the only one who want to make this
work), but I really don't understand why it's a use-case we care
about.
>>> It's not only about mistakenly having the driver disabled in the kernel
>>> config, it could also be that some base driver failed to probe, which
>>> then makes an encoder or a panel to defer probing as it can't get the
>>> base resource. But HDMI or some other panel would work fine, but with
>>> current architecture can't be used.
>>>
>>> And if you really want to optimize, one a phone-type device you could
>>> have the LCD driver built-in, but HDMI drivers as modules, and only load
>>> the HDMI drivers if the user actually needs the HDMI.
>>
>> I don't see why we should support this as a valid use-case. E.g. if i915
>> fails to load a component (just because it's all in the same .ko doesn't
>> mean it's not multiple bits, same way you can have multiple drivers in the
>> same .ko), we also fail the overall driver bind. Really not seeing any
>> difference with arm-soc vs. desktop here.
>
> I admit I'm not that familiar with the desktop side, but I don't follow.
>
> From the user's perspective, why would his board's HDMI not work, if the
> embedded panel fails, or the kernel doesn't have the driver for the
> panel? As a user, at least I would very much like the HDMI to work even
> if the other display doesn't.
>
> If there's a clear error on the panel side, the DRM driver can handle
> that and just leave the panel away. I think the real problems are the
> deferred probing and loading as modules, as we don't know when, if ever,
> the panel is ok.
>
> At least for me there's a clear distinction between, say, i915 and, say,
> boards with OMAP DSS hardware:
>
> i915 is one whole component, and if parts of it don't load, it makes
> sense that i915 as a whole doesn't load. And the i915 driver knows and
> understand about everything that i915 contains. And i915 can be a single
> .ko, splitting it into smaller .kos probably doesn't give much benefit.
>
> On an OMAP board, we have DSS in the SoC, which contains a bunch of
> subcomponents. Everything I said above about i915 goes also for DSS
> driver. Then we have external encoders and panels. Those have to be
> separate drivers and modules, as there can be any number of those, used
> in any combination, on any platform.
>
> If I'm configuring the kernel for my OMAP board which has HDMI output
> and a panel, and I want to use the HDMI output, it makes sense that I
> enable DSS and whatever is needed on the HDMI path. It doesn't really
> make sense that I also need to enable panel-foobar.
>
> It's almost as if my board has a GPIO chip, and I would need to enable
> and successfully load all the drivers for the devices using the GPIO
> chip until any of the devices would work.
>
> Now, I don't think this is a big issue, and I don't think normal users
> would often encounter it, but it does
Re: [BISECTED, REGRESSION] v4.12-rc: omapdrm fails to probe on Nokia N900
On 02/08/17 13:12, Daniel Vetter wrote:
> On Mon, Jul 31, 2017 at 04:21:51PM +0300, Tomi Valkeinen wrote:
>> On 30/06/17 15:36, Daniel Vetter wrote:
>>
>>> I don't think registering before everything is loaded make sense. On the
>>> big desktop driver chips we have all the bridge/encoder/panel drivers
>>> built into the driver. arm-soc loves to make everything a separate module,
>>> but in the end if you decided to not compile half of the driver you need,
>>> then it's not going to work.
>>
>> I don't think that's quite the same. On the desktop you just have the
>> video card, and it's easy to enable that single component. On an
>> embedded device you have the SoC's display controller and then possibly
>> multiple external encoders/panels on the board. Those external
>> components have to be separate modules, they can't be part of the SoC
>> driver. The desktop video card matches only to the SoC's display controller.
>
> Please take a look at the encoder drivers both nouveau and i915 have had
> (for older hw). In neither of these cases did we register an incomplete
> driver.
>
>>> Imo the only thing we should support to be hotplugged in drm is stuff you
>>> can physically hotplug (like atm connectors). Everything else just
>>> complicates the code for no good reason at all.
>>
>> "unplugging" components would not give much, I think, but allowing
>> adding new displays at runtime would be a very good thing.
>
> We do, just register another drm_device.
But a drm_device is the display controller ("graphics card") side of the
whole, isn't it? Well, that's not exactly true, it also contains the
output side, like panel, but it's the display controller that defines
how many drm_devices we have.
>> It's not only about mistakenly having the driver disabled in the kernel
>> config, it could also be that some base driver failed to probe, which
>> then makes an encoder or a panel to defer probing as it can't get the
>> base resource. But HDMI or some other panel would work fine, but with
>> current architecture can't be used.
>>
>> And if you really want to optimize, one a phone-type device you could
>> have the LCD driver built-in, but HDMI drivers as modules, and only load
>> the HDMI drivers if the user actually needs the HDMI.
>
> I don't see why we should support this as a valid use-case. E.g. if i915
> fails to load a component (just because it's all in the same .ko doesn't
> mean it's not multiple bits, same way you can have multiple drivers in the
> same .ko), we also fail the overall driver bind. Really not seeing any
> difference with arm-soc vs. desktop here.
I admit I'm not that familiar with the desktop side, but I don't follow.
From the user's perspective, why would his board's HDMI not work, if the
embedded panel fails, or the kernel doesn't have the driver for the
panel? As a user, at least I would very much like the HDMI to work even
if the other display doesn't.
If there's a clear error on the panel side, the DRM driver can handle
that and just leave the panel away. I think the real problems are the
deferred probing and loading as modules, as we don't know when, if ever,
the panel is ok.
At least for me there's a clear distinction between, say, i915 and, say,
boards with OMAP DSS hardware:
i915 is one whole component, and if parts of it don't load, it makes
sense that i915 as a whole doesn't load. And the i915 driver knows and
understand about everything that i915 contains. And i915 can be a single
.ko, splitting it into smaller .kos probably doesn't give much benefit.
On an OMAP board, we have DSS in the SoC, which contains a bunch of
subcomponents. Everything I said above about i915 goes also for DSS
driver. Then we have external encoders and panels. Those have to be
separate drivers and modules, as there can be any number of those, used
in any combination, on any platform.
If I'm configuring the kernel for my OMAP board which has HDMI output
and a panel, and I want to use the HDMI output, it makes sense that I
enable DSS and whatever is needed on the HDMI path. It doesn't really
make sense that I also need to enable panel-foobar.
It's almost as if my board has a GPIO chip, and I would need to enable
and successfully load all the drivers for the devices using the GPIO
chip until any of the devices would work.
Now, I don't think this is a big issue, and I don't think normal users
would often encounter it, but it does feel confusing when you hit the
problem when debugging or doing new kernel configs.
Tomi
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm: Clean up drm_dev_unplug
Use drm_dev_unregister to unregister the interfaces, which also allows
us to simplify the open_count == 0 case.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 694040a240af..be38ac7050d4 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -381,21 +381,12 @@ static void drm_device_set_unplugged(struct drm_device
*dev)
*/
void drm_dev_unplug(struct drm_device *dev)
{
- /* for a USB device */
- if (drm_core_check_feature(dev, DRIVER_MODESET))
- drm_modeset_unregister_all(dev);
-
- drm_minor_unregister(dev, DRM_MINOR_PRIMARY);
- drm_minor_unregister(dev, DRM_MINOR_RENDER);
- drm_minor_unregister(dev, DRM_MINOR_CONTROL);
+ drm_dev_unregister(dev);
mutex_lock(&drm_global_mutex);
-
drm_device_set_unplugged(dev);
-
- if (dev->open_count == 0) {
- drm_put_dev(dev);
- }
+ if (dev->open_count == 0)
+ drm_dev_unref(dev);
mutex_unlock(&drm_global_mutex);
}
EXPORT_SYMBOL(drm_dev_unplug);
--
2.13.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm: Document device unplug infrastructure
While at it, also ocd and give them a consistent drm_dev_ prefix, like
the other device instance functionality. Plus move the functions into
the right places.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 24 +---
drivers/gpu/drm/drm_file.c | 2 +-
drivers/gpu/drm/drm_gem.c | 2 +-
drivers/gpu/drm/drm_gem_cma_helper.c| 2 +-
drivers/gpu/drm/drm_ioctl.c | 4 ++--
drivers/gpu/drm/drm_vm.c| 2 +-
drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 2 +-
drivers/gpu/drm/udl/udl_connector.c | 2 +-
drivers/gpu/drm/udl/udl_drv.c | 2 +-
drivers/gpu/drm/udl/udl_fb.c| 2 +-
include/drm/drmP.h | 13 -
include/drm/drm_drv.h | 22 --
12 files changed, 51 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 2ed2d919beae..39191e5c240e 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -291,7 +291,7 @@ struct drm_minor *drm_minor_acquire(unsigned int minor_id)
if (!minor) {
return ERR_PTR(-ENODEV);
- } else if (drm_device_is_unplugged(minor->dev)) {
+ } else if (drm_dev_is_unplugged(minor->dev)) {
drm_dev_unref(minor->dev);
return ERR_PTR(-ENODEV);
}
@@ -364,7 +364,22 @@ void drm_put_dev(struct drm_device *dev)
}
EXPORT_SYMBOL(drm_put_dev);
-void drm_unplug_dev(struct drm_device *dev)
+static void drm_device_set_unplugged(struct drm_device *dev)
+{
+ smp_wmb();
+ atomic_set(&dev->unplugged, 1);
+}
+
+/**
+ * drm_dev_unplug - unplug a DRM device
+ * @dev: DRM device
+ *
+ * This unplugs a hotpluggable DRM device, which makes it inaccessible to
+ * userspace operations. Entry-points can use drm_dev_is_unplugged(). This
+ * essentially unregisters the device like drm_dev_unregister(), but can be
+ * called while there are still open users of @dev.
+ */
+void drm_dev_unplug(struct drm_device *dev)
{
/* for a USB device */
if (drm_core_check_feature(dev, DRIVER_MODESET))
@@ -383,7 +398,7 @@ void drm_unplug_dev(struct drm_device *dev)
}
mutex_unlock(&drm_global_mutex);
}
-EXPORT_SYMBOL(drm_unplug_dev);
+EXPORT_SYMBOL(drm_dev_unplug);
/*
* DRM internal mount
@@ -835,6 +850,9 @@ EXPORT_SYMBOL(drm_dev_register);
* drm_dev_register() but does not deallocate the device. The caller must call
* drm_dev_unref() to drop their final reference.
*
+ * A special form of unregistering for hotpluggable devices is
drm_dev_unplug(),
+ * which can be called while there are still open users of @dev.
+ *
* This should be called first in the device teardown code to make sure
* userspace can't access the device instance any more.
*/
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 59b75a974357..b3c6e997ccdb 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -436,7 +436,7 @@ int drm_release(struct inode *inode, struct file *filp)
if (!--dev->open_count) {
drm_lastclose(dev);
- if (drm_device_is_unplugged(dev))
+ if (drm_dev_is_unplugged(dev))
drm_put_dev(dev);
}
mutex_unlock(&drm_global_mutex);
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index a8d396bed6a4..ad4e9cfe48a2 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1001,7 +1001,7 @@ int drm_gem_mmap(struct file *filp, struct vm_area_struct
*vma)
struct drm_vma_offset_node *node;
int ret;
- if (drm_device_is_unplugged(dev))
+ if (drm_dev_is_unplugged(dev))
return -ENODEV;
drm_vma_offset_lock_lookup(dev->vma_offset_manager);
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 275ab872b34f..f4e00571839d 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -390,7 +390,7 @@ unsigned long drm_gem_cma_get_unmapped_area(struct file
*filp,
struct drm_device *dev = priv->minor->dev;
struct drm_vma_offset_node *node;
- if (drm_device_is_unplugged(dev))
+ if (drm_dev_is_unplugged(dev))
return -ENODEV;
drm_vma_offset_lock_lookup(dev->vma_offset_manager);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 1aad32fe6cda..f7aaa9331243 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -716,7 +716,7 @@ long drm_ioctl_kernel(struct file *file, drm_ioctl_t *func,
void *kdata,
struct drm_device *dev = file_priv->minor->dev;
int retcode;
- if (drm_device_is_unplugged(dev))
+ if (drm_dev_is_unplugged(dev))
return -ENODEV;
retcode = drm_ioctl_permit(flags,
[PATCH 3/4] drm: Only lastclose on unload for legacy drivers
The only thing modern drivers are supposed to do in lastclose is
restore the fb emulation state. Which is entirely optional, and
there's really no reason to do that. So restrict it to legacy drivers
(where the driver cleanup essentially happens in lastclose).
This will also allow us to share the unregister function with
drm_dev_unplug().
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 39191e5c240e..694040a240af 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -860,7 +860,8 @@ void drm_dev_unregister(struct drm_device *dev)
{
struct drm_map_list *r_list, *list_temp;
- drm_lastclose(dev);
+ if (drm_core_check_feature(dev, DRIVER_LEGACY))
+ drm_lastclose(dev);
dev->registered = false;
--
2.13.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm: Extract drm_device.h
I need this to untangle an include loop in the next patch.
Signed-off-by: Daniel Vetter
---
include/drm/drmP.h | 175 +--
include/drm/drm_device.h | 190 +++
2 files changed, 191 insertions(+), 174 deletions(-)
create mode 100644 include/drm/drm_device.h
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3aa3809ab524..3031c256105e 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -82,19 +82,10 @@
#include
#include
#include
-
+#include
struct module;
-struct drm_device;
-struct drm_agp_head;
-struct drm_local_map;
-struct drm_device_dma;
-struct drm_gem_object;
-struct drm_master;
-struct drm_vblank_crtc;
-struct drm_vma_offset_manager;
-
struct device_node;
struct videomode;
struct reservation_object;
@@ -306,170 +297,6 @@ struct pci_controller;
/**
- * DRM device structure. This structure represent a complete card that
- * may contain multiple heads.
- */
-struct drm_device {
- struct list_head legacy_dev_list;/**< list of devices per driver for
stealth attach cleanup */
- int if_version; /**< Highest interface version set */
-
- /** \name Lifetime Management */
- /*@{ */
- struct kref ref;/**< Object ref-count */
- struct device *dev; /**< Device structure of bus-device */
- struct drm_driver *driver; /**< DRM driver managing the device */
- void *dev_private; /**< DRM driver private data */
- struct drm_minor *control; /**< Control node */
- struct drm_minor *primary; /**< Primary node */
- struct drm_minor *render; /**< Render node */
- bool registered;
-
- /* currently active master for this device. Protected by master_mutex */
- struct drm_master *master;
-
- atomic_t unplugged; /**< Flag whether dev is dead */
- struct inode *anon_inode; /**< inode for private
address-space */
- char *unique; /**< unique name of the device
*/
- /*@} */
-
- /** \name Locks */
- /*@{ */
- struct mutex struct_mutex; /**< For others */
- struct mutex master_mutex; /**< For drm_minor::master and
drm_file::is_master */
- /*@} */
-
- /** \name Usage Counters */
- /*@{ */
- int open_count; /**< Outstanding files open, protected
by drm_global_mutex. */
- spinlock_t buf_lock;/**< For drm_device::buf_use and a few
other things. */
- int buf_use;/**< Buffers in use -- cannot alloc */
- atomic_t buf_alloc; /**< Buffer allocation in progress */
- /*@} */
-
- struct mutex filelist_mutex;
- struct list_head filelist;
-
- /** \name Memory management */
- /*@{ */
- struct list_head maplist; /**< Linked list of regions */
- struct drm_open_hash map_hash; /**< User token hash table for maps */
-
- /** \name Context handle management */
- /*@{ */
- struct list_head ctxlist; /**< Linked list of context handles */
- struct mutex ctxlist_mutex; /**< For ctxlist */
-
- struct idr ctx_idr;
-
- struct list_head vmalist; /**< List of vmas (for debugging) */
-
- /*@} */
-
- /** \name DMA support */
- /*@{ */
- struct drm_device_dma *dma; /**< Optional pointer for DMA
support */
- /*@} */
-
- /** \name Context support */
- /*@{ */
-
- __volatile__ long context_flag; /**< Context swapping flag */
- int last_context; /**< Last current context */
- /*@} */
-
- /**
-* @irq_enabled:
-*
-* Indicates that interrupt handling is enabled, specifically vblank
-* handling. Drivers which don't use drm_irq_install() need to set this
-* to true manually.
-*/
- bool irq_enabled;
- int irq;
-
- /**
-* @vblank_disable_immediate:
-*
-* If true, vblank interrupt will be disabled immediately when the
-* refcount drops to zero, as opposed to via the vblank disable
-* timer.
-*
-* This can be set to true it the hardware has a working vblank counter
-* with high-precision timestamping (otherwise there are races) and the
-* driver uses drm_crtc_vblank_on() and drm_crtc_vblank_off()
-* appropriately. See also @max_vblank_count and
-* &drm_crtc_funcs.get_vblank_counter.
-*/
- bool vblank_disable_immediate;
-
- /**
-* @vblank:
-*
-* Array of vblank tracking structures, one per &struct drm_crtc. For
-* historical reasons (vblank support predates kernel modesetting) this
-* is free-standing and not part of &struct drm_crtc itself. It must b
[PATCH 0/4] drm unplugging docs
Hi all, Just a small cleanup plus kerneldoc for the unplug support. There's still the fundamental problem that most likely our lifetime stuff is entirely screwed up for this, at least never export a dma-buf or dma-fence from a driver which can be hot-unplugged. It'd be sweet if we could properly fix this by attaching resources to either the physical device (which should be drm_device->dev) or the sw device (aka drm_device) depending upon whether it is needed after unplugging. There's also the slight problem of synchronizing all that access somehow. Either way this is a separate topic, I just thought about it a bit more while cleaning this up. On the patches themselves: I had to move struct drm_device into drm_device.h to avoid a header include loop, since that's a bit invasive it'd be great if I can land this fast. Cheers, Daniel Daniel Vetter (4): drm: Extract drm_device.h drm: Document device unplug infrastructure drm: Only lastclose on unload for legacy drivers drm: Clean up drm_dev_unplug drivers/gpu/drm/drm_drv.c | 40 +++--- drivers/gpu/drm/drm_file.c | 2 +- drivers/gpu/drm/drm_gem.c | 2 +- drivers/gpu/drm/drm_gem_cma_helper.c| 2 +- drivers/gpu/drm/drm_ioctl.c | 4 +- drivers/gpu/drm/drm_vm.c| 2 +- drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 2 +- drivers/gpu/drm/udl/udl_connector.c | 2 +- drivers/gpu/drm/udl/udl_drv.c | 2 +- drivers/gpu/drm/udl/udl_fb.c| 2 +- include/drm/drmP.h | 188 +-- include/drm/drm_device.h| 190 include/drm/drm_drv.h | 22 +++- 13 files changed, 246 insertions(+), 214 deletions(-) create mode 100644 include/drm/drm_device.h -- 2.13.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
