[PATCHv15 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 | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig index 371fca4e1ab7..4727a96a16da 100644 --- a/arch/arm/configs/socfpga_defconfig +++ b/arch/arm/configs/socfpga_defconfig @@ -112,6 +112,14 @@ 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_DUMMY_CONSOLE=y +CONFIG_FRAMEBUFFER_CONSOLE=y +CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y CONFIG_USB=y CONFIG_USB_STORAGE=y CONFIG_USB_DWC2=y -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv15 3/3] ARM:drm ivip Intel FPGA Video and Image Processing Suite
From: "Ong, Hean Loong" Driver for Intel FPGA Video and Image Processing Suite Frame Buffer II. The driver only supports the Intel Arria10 devkit and its variants. This driver can be either loaded staticlly or in modules. The OF device tree binding is located at: Documentation/devicetree/bindings/display/altr,vip-fb2.txt Signed-off-by: Ong, Hean Loong Acked-by: Acked-by: Daniel Vetter V15: Fix indentation issues V14: Fix indentation issues V13: Fix drm-misc build failure V12: Fix comments V11: move to drm-misc V10: Fix Build failure V9: Fix Build failure V8: Changes to device tree docs V6: Changes to device tree docs V7: Changes to device tree docs V6: Fix comments V5: Fix comments V4: Fix comments V3: Fix comments V2: Move to simple drm V1: Initial changes --- MAINTAINERS | 9 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/ivip/Kconfig | 14 ++ drivers/gpu/drm/ivip/Makefile | 6 + drivers/gpu/drm/ivip/intel_vip_conn.c | 93 +++ drivers/gpu/drm/ivip/intel_vip_drv.c | 335 ++ drivers/gpu/drm/ivip/intel_vip_drv.h | 73 ++ 8 files changed, 533 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_drv.c create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h diff --git a/MAINTAINERS b/MAINTAINERS index e7e81fadff65..0fdec52a356a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5229,6 +5229,15 @@ L: dri-devel@lists.freedesktop.org F: include/drm/ttm/ F: drivers/gpu/drm/ttm/ +DRM INTEL IVIP +M: Hean Loong, Ong +L: dri-devel@lists.freedesktop.org +T: git git://anongit.freedesktop.org/drm/drm-misc +S: Maintained +F: intel_vip_conn.c +F: intel_vip_drv.c +F: intel_vip_drv.h + DSBR100 USB FM RADIO DRIVER M: Alexey Klimov L: linux-me...@vger.kernel.org diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index bd943a71756c..3db01e99479b 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -231,6 +231,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 1ac55c65eac0..e8ac4e3de9c6 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -63,6 +63,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_V3D) += v3d/ obj-$(CONFIG_DRM_VC4) += vc4/ diff --git a/drivers/gpu/drm/ivip/Kconfig b/drivers/gpu/drm/ivip/Kconfig new file mode 100644 index ..1b2af85fe757 --- /dev/null +++ b/drivers/gpu/drm/ivip/Kconfig @@ -0,0 +1,14 @@ +config DRM_IVIP +tristate "Intel FGPA Video and Image Processing" +depends on DRM && OF +select DRM_GEM_CMA_HELPER +select DRM_KMS_HELPER +select DRM_KMS_FB_HELPER +select DRM_KMS_CMA_HELPER +help + Choose this option if you have an Intel FPGA Arria 10 system + and above with an Intel Display Port IP. This does not support + legacy Intel FPGA Cyclone V display port. Currently only single + frame buffer is supported. Note that ACPI and X_86 architecture + is not supported for Arria10. If M is selected the module will be + called ivip. diff --git a/drivers/gpu/drm/ivip/Makefile b/drivers/gpu/drm/ivip/Makefile new file mode 100644 index ..8c54e11daeca --- /dev/null +++ b/drivers/gpu/drm/ivip/Makefile @@ -0,0 +1,6 @@ +# +# Makefile for the drm device driver. This driver provides support for the +# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. + +obj-$(CONFIG_DRM_IVIP) += ivip.o +ivip-objs := intel_vip_drv.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 ..041b7a576983 --- /dev/null +++ b/drivers/gpu/drm/ivip/intel_vip_conn.c @@ -0,0 +1,93 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2019 Intel Corporation. + * + * 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. + * + * Authors: + * Walter Goossens + * Thomas Chou + * Chris Rauer + * Ong, Hean-Loong + * + */ + +#include +#include +#include +#include +#include +#include +#include +
[PATCHv15 1/3] ARM:dt-bindings:display Intel FPGA Video and Image Processing Suite
From: "Ong, Hean Loong"
Device tree binding for Intel FPGA Video and Image Processing Suite.
The bindings would set the max width, max height,
bits per pixel and memory port width.
The device tree binding only supports the Intel
Arria10 devkit and its variants. Vendor name retained as altr.
V12:
Wrap comments and fix commit message
V11:
No change
V10:
No change
V9:
Remove Display port node
V8:
*Add port to Display port decoder
V7:
*Fix OF graph for better description
*Add description for encoder
V6:
*Description have not describe DT device in general
V5:
*remove bindings for bits per symbol as it has only one value which is 8
V4:
*fix properties that does not describe the values
V3:
*OF graph not in accordance to graph.txt
V2:
*Remove Linux driver description
V1:
*Missing vendor prefix
Signed-off-by: Ong, Hean Loong
---
.../bindings/display/altr,vip-fb2.txt | 63 +++
1 file changed, 63 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 ..89a3b9e166a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
@@ -0,0 +1,63 @@
+Intel Video and Image Processing(VIP) Frame Buffer II bindings
+
+Supported hardware: Intel FPGA SoC Arria10 and above with display port IP
+
+The Video Frame Buffer II in Video Image Processing (VIP) suite is an IP core
+that interfaces between system memory and Avalon-ST video ports. The IP core
+can be configured to support the memory reader (from memory to Avalon-ST)
+and/or memory writer (from Avalon-ST to memory) interfaces.
+
+More information the FPGA video IP component can be acquired from
+https://www.altera.com/content/dam/altera-www/global/en_US/pdfs\
+/literature/ug/ug_vip.pdf
+
+DT-Bindings:
+=
+Required properties:
+
+- compatible: "altr,vip-frame-buffer-2.0"
+- reg: Physical base address and length of the framebuffer controller's
+ registers.
+- altr,max-width: The maximum width of the framebuffer in pixels.
+- altr,max-height: The maximum height of the framebuffer in pixels.
+- altr,mem-port-width = the bus width of the avalon master port
+ on the frame reader
+
+Optional sub-nodes:
+- ports: The connection to the encoder
+
+Connections between the Frame Buffer II and other video IP cores in the system
+are modelled using the OF graph DT bindings. The Frame Buffer II node has up
+to two OF graph ports. When the memory writer interface is enabled, port 0
+maps to the Avalon-ST Input (din) port. When the memory reader interface is
+enabled, port 1 maps to the Avalon-ST Output (dout) port.
+
+The encoder is built into the FPGA HW design and therefore would not
+be accessible from the DDR.
+
+ Port 0 Port1
+-
+ARRIA10 AVALON_ST (DIN)AVALON_ST (DOUT)
+
+Required Properties Example:
+
+
+framebuffer@10280 {
+ compatible = "altr,vip-frame-buffer-2.0";
+ reg = <0x0001 0x0280 0x0040>;
+ altr,max-width = <1280>;
+ altr,max-height = <720>;
+ altr,mem-port-width = <128>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+ fb_output: endpoint {
+ remote-endpoint =
<&dp_encoder_input>;
+ };
+ };
+ };
+};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv15 0/3] Intel FPGA Video and Image Processing Suite
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 Sodt IP 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 Framebuffer 2 Soft IP and displayed on the Display Port Monitor. Ong Hean Loong (1): ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite Ong, Hean Loong (2): ARM:dt-bindings:display Intel FPGA Video and Image Processing Suite ARM:drm ivip Intel FPGA Video and Image Processing Suite .../bindings/display/altr,vip-fb2.txt | 63 MAINTAINERS | 9 + arch/arm/configs/socfpga_defconfig| 8 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/ivip/Kconfig | 14 + drivers/gpu/drm/ivip/Makefile | 6 + drivers/gpu/drm/ivip/intel_vip_conn.c | 93 + drivers/gpu/drm/ivip/intel_vip_drv.c | 335 ++ drivers/gpu/drm/ivip/intel_vip_drv.h | 73 10 files changed, 604 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_drv.c create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
udl unplug fixes
I've sent two udl fixes for plugging in, these two fix the unplug scenario, The first avoids hitting the unregister path twice, once in device unplug and once in last open fd release. The second avoids uninit the modeset configs while userspace still has the open fd which can access them. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: do lower level device put on unplugged releases
From: Dave Airlie
When we release the file handle on a device that has been unplugged
it has already called the unregister path, which doesn't like being
called again. We should just do the dev put version instead.
This fixes some crashes unplugged in a udl device.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 83a5bbca6e7e..900fe8228745 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -492,7 +492,7 @@ int drm_release(struct inode *inode, struct file *filp)
if (!--dev->open_count) {
drm_lastclose(dev);
if (drm_dev_is_unplugged(dev))
- drm_put_dev(dev);
+ drm_dev_put(dev);
}
mutex_unlock(&drm_global_mutex);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/udl: add a release method and delay modeset teardown
From: Dave Airlie
If we unplug a udl device, the usb callback with deinit the
mode_config struct, however userspace will still have an open
file descriptor and a framebuffer on that device. When userspace
closes the fd, we'll oops because it'll try and look stuff up
in the object idr which we've destroyed.
This punts destroying the mode objects until release time instead.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/udl/udl_drv.c | 1 +
drivers/gpu/drm/udl/udl_drv.h | 1 +
drivers/gpu/drm/udl/udl_main.c | 8 +++-
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index 22cd2d13e272..ff47f890e6ad 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -52,6 +52,7 @@ static struct drm_driver driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME,
.load = udl_driver_load,
.unload = udl_driver_unload,
+ .release = udl_driver_release,
/* gem hooks */
.gem_free_object_unlocked = udl_gem_free_object,
diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index e9e9b1ff678e..4ae67d882eae 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -104,6 +104,7 @@ void udl_urb_completion(struct urb *urb);
int udl_driver_load(struct drm_device *dev, unsigned long flags);
void udl_driver_unload(struct drm_device *dev);
+void udl_driver_release(struct drm_device *dev);
int udl_fbdev_init(struct drm_device *dev);
void udl_fbdev_cleanup(struct drm_device *dev);
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 9086d0d1b880..5626e1f11852 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -379,6 +379,12 @@ void udl_driver_unload(struct drm_device *dev)
udl_free_urb_list(dev);
udl_fbdev_cleanup(dev);
- udl_modeset_cleanup(dev);
kfree(udl);
}
+
+void udl_driver_release(struct drm_device *dev)
+{
+ drm_mode_config_cleanup(dev);
+ drm_dev_fini(dev);
+ kfree(dev);
+}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
udl hotunplug broken
Hey, Not sure how long this has been broken, considering plugging it in was broken, unplugging is much worse. Is there anything outside my tree that might be fixing this? Currently it appears if I unplug udl while userspace has the device open, it's bad, I get the userspace fb leaked thing which isn't surprising, but I do get a lot of backtracing and warns which differ depending on which way the race happens between X and unload. I'm going to see if I can find a fix, but I'm guessing it's a lot of digging to figure this out. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/18] drm/mediatek: add gmc_bits for ovl private data
On Fri, Mar 15, 2019 at 10:34 AM Yongqiang Niu
wrote:
>
> On Tue, 2018-12-25 at 12:15 +0800, Nicolas Boichat wrote:
> > On Mon, Dec 24, 2018 at 6:53 PM Yongqiang Niu
> > wrote:
> > >
> > > This patch add gmc_bits for ovl private data
> > >
> > > Signed-off-by: Yongqiang Niu
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 23 +--
> > > 1 file changed, 21 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > > b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > > index 28d1911..afb313c 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > > @@ -39,7 +39,9 @@
> > > #define DISP_REG_OVL_ADDR_MT8173 0x0f40
> > > #define DISP_REG_OVL_ADDR(ovl, n) ((ovl)->data->addr + 0x20
> > > * (n))
> > >
> > > -#defineOVL_RDMA_MEM_GMC0x40402020
> > > +#define GMC_THRESHOLD_BITS 16
> > > +#define GMC_THRESHOLD_HIGH ((1 << GMC_THRESHOLD_BITS) / 4)
> > > +#define GMC_THRESHOLD_LOW ((1 << GMC_THRESHOLD_BITS) / 8)
> > >
> > > #define OVL_CON_BYTE_SWAP BIT(24)
> > > #define OVL_CON_MTX_YUV_TO_RGB (6 << 16)
> > > @@ -57,6 +59,7 @@
> > >
> > > struct mtk_disp_ovl_data {
> > > unsigned int addr;
> > > + unsigned int gmc_bits;
> > > bool fmt_rgb565_is_0;
> > > };
> > >
> > > @@ -140,9 +143,23 @@ static unsigned int mtk_ovl_layer_nr(struct
> > > mtk_ddp_comp *comp)
> > > static void mtk_ovl_layer_on(struct mtk_ddp_comp *comp, unsigned int idx)
> > > {
> > > unsigned int reg;
> > > + unsigned int gmc_thrshd_l;
> > > + unsigned int gmc_thrshd_h;
> > > + unsigned int gmc_value;
> > > + struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
> > >
> > > writel(0x1, comp->regs + DISP_REG_OVL_RDMA_CTRL(idx));
> > > - writel(OVL_RDMA_MEM_GMC, comp->regs + DISP_REG_OVL_RDMA_GMC(idx));
> > > +
> > > + gmc_thrshd_l = GMC_THRESHOLD_LOW >>
> > > + (GMC_THRESHOLD_BITS - ovl->data->gmc_bits);
> > > + gmc_thrshd_h = GMC_THRESHOLD_HIGH >>
> > > + (GMC_THRESHOLD_BITS - ovl->data->gmc_bits);
> > > + if (ovl->data->gmc_bits == 10)
> > > + gmc_value = gmc_thrshd_h | gmc_thrshd_h << 16;
> >
> > I don't really get what this does, but is it intentional that you
> > don't use gmc_thrshd_l here?
> >
> GMC register was set RDMA ultra and pre-ultra threshold.
> MT8183 GMC register define is different with other SOC, gmc_thrshd_l not
> used here.
Ok cool. My issue is that this really appears to be like a mistake, so
maybe it's better to only compute gmc_thrshd_l in the else branch?
gmc_thrshd_h = GMC_THRESHOLD_HIGH >>
(GMC_THRESHOLD_BITS - ovl->data->gmc_bits);
if (ovl->data->gmc_bits == 10) {
gmc_value = gmc_thrshd_h | gmc_thrshd_h << 16;
} else {
gmc_thrshd_l = GMC_THRESHOLD_LOW >>
(GMC_THRESHOLD_BITS - ovl->data->gmc_bits);
gmc_value = gmc_thrshd_l | gmc_thrshd_l << 8 |
gmc_thrshd_h << 16 | gmc_thrshd_h << 24;
}
> > Also, if you only ever use 8 or 10 bits gmc, maybe it's easier to
> > hard-code the 2 values?
> > if (ovl->data->gmc_bits == 10)
> > gmc_value = OVL_RDMA_MEM_GMC_10BIT;
> > else
> > gmc_value = OVL_RDMA_MEM_GMC_8BIT; //0x40402020
> >
>
> our internal maintainer prefer calculate GMC setting with private data
> gmc bit instead of hard-core.
> and with calculation function that will be more flexible
Sounds ok.
> > > + else
> > > + gmc_value = gmc_thrshd_l | gmc_thrshd_l << 8 |
> > > + gmc_thrshd_h << 16 | gmc_thrshd_h << 24;
> > > + writel(gmc_value, comp->regs + DISP_REG_OVL_RDMA_GMC(idx));
> > >
> > > reg = readl(comp->regs + DISP_REG_OVL_SRC_CON);
> > > reg = reg | BIT(idx);
> > > @@ -324,11 +341,13 @@ static int mtk_disp_ovl_remove(struct
> > > platform_device *pdev)
> > >
> > > static const struct mtk_disp_ovl_data mt2701_ovl_driver_data = {
> > > .addr = DISP_REG_OVL_ADDR_MT2701,
> > > + .gmc_bits = 8,
> > > .fmt_rgb565_is_0 = false,
> > > };
> > >
> > > static const struct mtk_disp_ovl_data mt8173_ovl_driver_data = {
> > > .addr = DISP_REG_OVL_ADDR_MT8173,
> > > + .gmc_bits = 8,
> > > .fmt_rgb565_is_0 = true,
> > > };
> > >
> > > --
> > > 1.8.1.1.dirty
> > > ___
> > > 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
Re: [PATCH 03/18] drm/mediatek: redefine mtk_ddp_sout_sel
On Fri, Mar 15, 2019 at 10:06 AM Yongqiang Niu
wrote:
>
> On Tue, 2018-12-25 at 11:57 +0800, Nicolas Boichat wrote:
> > On Mon, Dec 24, 2018 at 6:52 PM Yongqiang Niu
> > wrote:
> > >
> > > This patch redefine mtk_ddp_sout_sel
> >
> > Can you describe a bit more why you are making this change?
>
> the format of "mtk_ddp_sout_sel"was not flexible, after we add more
> mediatek SOC support, that will be redundant
>
> set this function format like mtk_ddp_mout_en and mtk_ddp_sel_in
This needs to be 2 patches:
1. Make the change to "cur == DDP_COMPONENT_BLS && next ==
DDP_COMPONENT_DPI0", along with an explanation of why this is
reasonable.
2. Change the format to look like mtk_ddp_mout_en and mtk_ddp_sel_in
> >
> > > Signed-off-by: Yongqiang Niu
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 32
> > >
> > > 1 file changed, 20 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > index adb37e4..592f852 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > @@ -405,21 +405,27 @@ static unsigned int mtk_ddp_sel_in(enum
> > > mtk_ddp_comp_id cur,
> > > return value;
> > > }
> > >
> > > -static void mtk_ddp_sout_sel(void __iomem *config_regs,
> > > -enum mtk_ddp_comp_id cur,
> > > -enum mtk_ddp_comp_id next)
> > > +static unsigned int mtk_ddp_sout_sel(void __iomem *config_regs,
> >
> > You don't use config_regs anymore, drop it.
>
> ok, will drop it in next version
>
> >
> > > +enum mtk_ddp_comp_id cur,
> > > +enum mtk_ddp_comp_id next,
> > > +unsigned int *addr)
> > > {
> > > + unsigned int value;
> > > +
> > > if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) {
> > > - writel_relaxed(BLS_TO_DSI_RDMA1_TO_DPI1,
> > > - config_regs + DISP_REG_CONFIG_OUT_SEL);
> > > + *addr = DISP_REG_CONFIG_OUT_SEL;
> > > + value = BLS_TO_DSI_RDMA1_TO_DPI1;
> >
> > You can directly return BLS_TO_DSI_RDMA1_TO_DPI1.
>
> just format this like mtk_ddp_mout_en and mtk_ddp_sel_in
Since there is precedent, sounds ok.
> >
> > > } else if (cur == DDP_COMPONENT_BLS && next ==
> > > DDP_COMPONENT_DPI0) {
> > > - writel_relaxed(BLS_TO_DPI_RDMA1_TO_DSI,
> > > - config_regs + DISP_REG_CONFIG_OUT_SEL);
> > > - writel_relaxed(DSI_SEL_IN_RDMA,
> > > - config_regs + DISP_REG_CONFIG_DSI_SEL);
> > > - writel_relaxed(DPI_SEL_IN_BLS,
> > > - config_regs + DISP_REG_CONFIG_DPI_SEL);
> > > + *addr = DISP_REG_CONFIG_OUT_SEL;
> > > + value = BLS_TO_DPI_RDMA1_TO_DSI;
> >
> > I (kind of) understand the change above, as you still end up writing
> > BLS_TO_DSI_RDMA1_TO_DPI1 in DISP_REG_CONFIG_OUT_SEL.
> >
> > This changes the behaviour, as now you only write
> > BLS_TO_DPI_RDMA1_TO_DSI to DISP_REG_CONFIG_OUT_SEL, but the previous
> > revision of the code would also write to DISP_REG_CONFIG_DSI_SEL and
> > DISP_REG_CONFIG_DPI_SEL. Why?
> >
>
> DISP_REG_CONFIG_DSI_SEL set in the next lines.
Ok, but where is mtk_ddp_sout_sel(DDP_COMPONENT_RDMA1,
DDP_COMPONENT_DSI0) called from?
Before this change, we just needed to call:
mtk_ddp_sout_sel(DDP_COMPONENT_BLS, DDP_COMPONENT_DSI0)
and the following 3 registers would be modified:
BLS_TO_DPI_RDMA1_TO_DSI, DSI_SEL_IN_RDMA, DPI_SEL_IN_BLS.
Now, to get similar behaviour, we need to call:
mtk_ddp_sout_sel(DDP_COMPONENT_BLS, DDP_COMPONENT_DSI0)
mtk_ddp_sout_sel(DDP_COMPONENT_RDMA1, DDP_COMPONENT_DSI0)
Maybe that's ok, but you really need to explain the reason for this
change in the commit message.
> DPI_SEL_IN_BLS is 0 for DISP_REG_CONFIG_DPI_SEL set, and hardware
> default setting is also 0, so this one is no need anymore
That's somewhat reasonable, but this needs to be at the very least
described in the commit message.
> > > + } else if (cur == DDP_COMPONENT_RDMA1 && next ==
> > > DDP_COMPONENT_DSI0) {
> > > + *addr = DISP_REG_CONFIG_DSI_SEL;
> > > + value = DSI_SEL_IN_RDMA;
> > > + } else {
> > > + value = 0;
> > > }
> > > +
> > > + return value;
> > > }
> > >
> > > void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
> > > @@ -434,7 +440,9 @@ void mtk_ddp_add_comp_to_path(void __iomem
> > > *config_regs,
> > > writel_relaxed(reg, config_regs + addr);
> > > }
> > >
> > > - mtk_ddp_sout_sel(config_regs, cur, next);
> > > + value = mtk_ddp_sout_sel(cur, next, &addr);
> > > + if (value)
> > > + writel_relaxed(value, config_regs + addr);
> >
> > Why this change
[Bug 110117] Waking from Suspend causes screen to appear with grey static (like a TV with no signal)
https://bugs.freedesktop.org/show_bug.cgi?id=110117 Craig changed: What|Removed |Added Hardware|Other |x86-64 (AMD64) OS|All |Linux (All) Priority|medium |high -- 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 110117] Waking from Suspend causes screen to appear with grey static (like a TV with no signal)
https://bugs.freedesktop.org/show_bug.cgi?id=110117 Bug ID: 110117 Summary: Waking from Suspend causes screen to appear with grey static (like a TV with no signal) Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: stein...@gmail.com Created attachment 143671 --> https://bugs.freedesktop.org/attachment.cgi?id=143671&action=edit journalctl -b -1 -k I am running Ubuntu 18.10. This is the PH517-61 Acer Predator Helios 500 with the Ryzen processor. I have temporarily disabled suspend. If I do let the laptop suspend and then hit the keyboard I get what appears to be a TV with no signal. At this point I manually power down and then power up again and am able to view things on screen. I have reported this downstream here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1813820 in log.txt I have attached the output of 'journalctl -b -1 -k' uname -a: 5.0.2-050002-generic #201903131832 SMP Wed Mar 13 22:35:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux Loaded newer kernel from this source: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.0.2/ This is a Vega 56 card but here is what I get with this command: lspci -k | grep -EA3 'VGA|3D|Display' 08:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Vega 10 XT [Radeon RX Vega 64] (rev c7) Subsystem: Acer Incorporated [ALI] Vega 10 XT [Radeon RX Vega 64] Kernel driver in use: amdgpu Kernel modules: amdgpu glxinfo | grep "OpenGL version" OpenGL version string: 4.4 (Compatibility Profile) Mesa 18.2.2 Expected Behaviour: I expect to continue to be able to use my machine normally and be able to see what is happening on screen. Actual Behaviour: Static on screen obscures everything. -- 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 04/13] arm64: dts: allwinner: a64: Add cross links for the mixers
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote: > > Unlike what the binding for multiple pipeline documents, the A64 doesn't > have the cross links between the TCON and the mixers. > > Let's add them. > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 03/13] ARM: dts: sun8i: a83t: Add cross links for the mixers
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote: > > Unlike what the binding for multiple pipeline documents, the A83t doesn't > have the cross links between the TCON and the mixers. > > Let's add them. > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 02/13] drm/sun4i: mixer: Simplify the get_id logic
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote:
>
> Using the new helpers introduced since we wrote that code, we can simplify
> the code to retrieve the mixer ID significantly.
>
> The new code will also allow us to deal nicely with endpoints that don't
> have a reg property, as expected in the case where there's a single
> endpoint for a given port.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/sun4i/sun8i_mixer.c | 39 --
> 1 file changed, 11 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> index 30a2eff55687..bf44a601a653 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> @@ -325,38 +325,21 @@ static struct regmap_config sun8i_mixer_regmap_config =
> {
>
> static int sun8i_mixer_of_get_id(struct device_node *node)
> {
> - struct device_node *port, *ep;
> - int ret = -EINVAL;
> + struct device_node *ep, *remote;
> + struct of_endpoint of_ep;
>
> - /* output is port 1 */
> - port = of_graph_get_port_by_id(node, 1);
> - if (!port)
> + /* Output port is 1, and we want the first endpoint. */
> + ep = of_graph_get_endpoint_by_regs(node, 1, -1);
> + if (!ep)
> return -EINVAL;
>
> - /* try to find downstream endpoint */
> - for_each_available_child_of_node(port, ep) {
> - struct device_node *remote;
> - u32 reg;
> -
> - remote = of_graph_get_remote_endpoint(ep);
> - if (!remote)
> - continue;
> -
> - ret = of_property_read_u32(remote, "reg", ®);
> - if (!ret) {
> - of_node_put(remote);
> - of_node_put(ep);
> - of_node_put(port);
> -
> - return reg;
> - }
> -
> - of_node_put(remote);
> - }
> -
> - of_node_put(port);
> + remote = of_graph_get_remote_endpoint(ep);
Same comment as the previous patch.
Reviewed-by: Chen-Yu Tsai
once fixed.
> + if (!remote)
> + return -EINVAL;
>
> - return ret;
> + of_graph_parse_endpoint(remote, &of_ep);
> + of_node_put(remote);
> + return of_ep.id;
> }
>
> static int sun8i_mixer_bind(struct device *dev, struct device *master,
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/13] drm/sun4i: backend: Simplify the get_id logic
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote:
>
> Using the new helpers introduced since we wrote that code, we can simplify
> the code to retrieve the backend ID significantly.
>
> The new code will also allow us to deal nicely with endpoints that don't
> have a reg property, as expected in the case where there's a single
> endpoint for a given port.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/sun4i/sun4i_backend.c | 34 +---
> 1 file changed, 11 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
> b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index 4c0d51f73237..02ef8e455db8 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -720,33 +720,21 @@ static int sun4i_backend_free_sat(struct device *dev) {
> */
> static int sun4i_backend_of_get_id(struct device_node *node)
> {
> - struct device_node *port, *ep;
> - int ret = -EINVAL;
> + struct device_node *ep, *remote;
> + struct of_endpoint of_ep;
>
> - /* input is port 0 */
> - port = of_graph_get_port_by_id(node, 0);
> - if (!port)
> + /* Input port is 0, and we want the first endpoint. */
> + ep = of_graph_get_endpoint_by_regs(node, 0, -1);
> + if (!ep)
> return -EINVAL;
>
> - /* try finding an upstream endpoint */
> - for_each_available_child_of_node(port, ep) {
> - struct device_node *remote;
> - u32 reg;
> -
> - remote = of_graph_get_remote_endpoint(ep);
> - if (!remote)
> - continue;
> -
> - ret = of_property_read_u32(remote, "reg", ®);
> - if (ret)
> - continue;
> -
> - ret = reg;
> - }
> -
> - of_node_put(port);
> + remote = of_graph_get_remote_endpoint(ep);
I believe you also need to call of_node_put for ep?
Otherwise,
Reviewed-by: Chen-Yu Tsai
> + if (!remote)
> + return -EINVAL;
>
> - return ret;
> + of_graph_parse_endpoint(remote, &of_ep);
> + of_node_put(remote);
> + return of_ep.id;
> }
>
> /* TODO: This needs to take multiple pipelines into account */
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 13/13] ARM: dts: sun9i: Add missing unit address
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote:
>
> The soc node in the A80 DTSI has a ranges property, but no matching unit
> address, which results in a DTC warning. Add the unit address to remove
> that warning.
>
> Signed-off-by: Maxime Ripard
> ---
> arch/arm/boot/dts/sun9i-a80.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi
> b/arch/arm/boot/dts/sun9i-a80.dtsi
> index 9b15f272e5f5..7a495c84ab65 100644
> --- a/arch/arm/boot/dts/sun9i-a80.dtsi
> +++ b/arch/arm/boot/dts/sun9i-a80.dtsi
> @@ -289,7 +289,7 @@
> status = "disabled";
> };
>
> - soc {
> + soc@2 {
I thought we didn't like the soc node having an address?
Maybe we just bite the bullet and use 64-bit addresses and sizes for the A80?
ChenYu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 12/13] ARM: dts: sun9i: Fix Display Engine DTC warnings
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote: > > Our display engine endpoints trigger some DTC warnings due to the fact that > we're having a single endpoint that doesn't need any reg property, and > since we don't have a reg property, we don't need the address-cells and > size-cells properties anymore. > > Fix those > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/13] ARM: dts: sun8i: r40: Fix Display Engine DTC warnings
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote: > > Our display engine endpoints trigger some DTC warnings due to the fact that > we're having a single endpoint that doesn't need any reg property, and > since we don't have a reg property, we don't need the address-cells and > size-cells properties anymore. > > Fix those > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/13] ARM: dts: sun8i: a83t: Fix Display Engine DTC warnings
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote: > > Our display engine endpoints trigger some DTC warnings due to the fact that > we're having a single endpoint that doesn't need any reg property, and > since we don't have a reg property, we don't need the address-cells and > size-cells properties anymore. > > Fix those > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai but we're going to end up adding it back if DSI gets added. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 09/13] ARM: dts: sun8i: v3s: Fix Display Engine DTC warnings
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote: > > Our display engine endpoints trigger some DTC warnings due to the fact that > we're having a single endpoint that doesn't need any reg property, and > since we don't have a reg property, we don't need the address-cells and > size-cells properties anymore. > > Fix those > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 06/13] ARM: dts: sun5i: Fix Display Engine DTC warnings
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote: > > Our display engine endpoints trigger some DTC warnings due to the fact that > we're having a single endpoint that doesn't need any reg property, and > since we don't have a reg property, we don't need the address-cells and > size-cells properties anymore. > > Fix those > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/13] ARM: dts: sun6i: Fix Display Engine DTC warnings
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote: > > Our display engine endpoints trigger some DTC warnings due to the fact that > we're having a single endpoint that doesn't need any reg property, and > since we don't have a reg property, we don't need the address-cells and > size-cells properties anymore. > > Fix those > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 05/13] ARM: dts: sun5i: Fix display pipeline endpoint warnings in DTC
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote: > > Since most of the display IPs have a single endpoint, having a reg > property, a unit-address and #address-cells and #size-cells will emit a > warning. > > Let's remove those. > > Signed-off-by: Maxime Ripard Acked-by: Chen-Yu Tsai ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 08/13] ARM: dts: sun8i: a23/a33: Fix Display Engine DTC warnings
On Fri, Mar 15, 2019 at 4:16 AM Maxime Ripard wrote:
>
> Our display engine endpoints trigger some DTC warnings due to the fact that
> we're having a single endpoint that doesn't need any reg property, and
> since we don't have a reg property, we don't need the address-cells and
> size-cells properties anymore.
>
> Fix those
>
> Signed-off-by: Maxime Ripard
> ---
> arch/arm/boot/dts/sun8i-a23-a33.dtsi | 32 +++
> arch/arm/boot/dts/sun8i-a23-q8-tablet.dts | 6 -
> arch/arm/boot/dts/sun8i-a33-q8-tablet.dts | 7 -
> arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 11 +--
> arch/arm/boot/dts/sun8i-a33.dtsi | 18 +++
> arch/arm/boot/dts/sun8i-q8-common.dtsi | 18 +--
> 6 files changed, 29 insertions(+), 63 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
> b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
> index 43fe215e83ea..6d2625a90a09 100644
> --- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
> @@ -192,19 +192,14 @@
> #size-cells = <0>;
>
> tcon0_in: port@0 {
> - #address-cells = <1>;
> - #size-cells = <0>;
> reg = <0>;
>
> - tcon0_in_drc0: endpoint@0 {
> - reg = <0>;
> + tcon0_in_drc0: endpoint {
> remote-endpoint =
> <&drc0_out_tcon0>;
> };
> };
>
> tcon0_out: port@1 {
> - #address-cells = <1>;
> - #size-cells = <0>;
> reg = <1>;
> };
> };
> @@ -627,12 +622,9 @@
> #size-cells = <0>;
>
> fe0_out: port@1 {
> - #address-cells = <1>;
> - #size-cells = <0>;
> reg = <1>;
>
> - fe0_out_be0: endpoint@0 {
> - reg = <0>;
> + fe0_out_be0: endpoint {
> remote-endpoint =
> <&be0_in_fe0>;
> };
> };
> @@ -654,23 +646,17 @@
> #size-cells = <0>;
>
> be0_in: port@0 {
> - #address-cells = <1>;
> - #size-cells = <0>;
> reg = <0>;
>
> - be0_in_fe0: endpoint@0 {
> - reg = <0>;
> + be0_in_fe0: endpoint {
> remote-endpoint =
> <&fe0_out_be0>;
> };
> };
>
> be0_out: port@1 {
> - #address-cells = <1>;
> - #size-cells = <0>;
> reg = <1>;
>
> - be0_out_drc0: endpoint@0 {
> - reg = <0>;
> + be0_out_drc0: endpoint {
> remote-endpoint =
> <&drc0_in_be0>;
> };
> };
> @@ -694,23 +680,17 @@
> #size-cells = <0>;
>
> drc0_in: port@0 {
> - #address-cells = <1>;
> - #size-cells = <0>;
> reg = <0>;
>
> - drc0_in_be0: endpoint@0 {
> - reg = <0>;
> + drc0_in_be0: endpoint {
> remote-endpoint =
> <&be0_out_drc0>;
> };
> };
>
> drc0_out: port@1 {
> - #address-cells = <1>;
> - #size-cells = <0>;
> reg = <1>;
>
> - drc0_out_tcon0: endpoint@0 {
> -
Re: [PATCH] drm/udl: Refactor edid retreiving in UDL driver
On Thu, 14 Mar 2019 at 18:25, Robert Tarasov wrote: > > Now drm/udl driver uses drm_do_get_edid() function to retreive and > validate all blocks of EDID data. Old approach had insufficient > validation routine and had problems with retreiving of extra blocks > > Signed-off-by: Robert Tarasov Reviewed-by: Dave Airlie I've posted two other udl fixes this morning to actually make my udl work again. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/udl: Cut >165 MHz modes for DVI
On Sat, 9 Mar 2019 at 19:39, Robert Tarasov wrote:
>
> Filter out all modes with clock higher than 165 MHz for DVI connector in
> drm/udl driver.
>
> Signed-off-by: Robert Tarasov
> ---
> drivers/gpu/drm/udl/udl_connector.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/udl/udl_connector.c
> b/drivers/gpu/drm/udl/udl_connector.c
> index 68b221b9a01f..3b9be500b9ae 100644
> --- a/drivers/gpu/drm/udl/udl_connector.c
> +++ b/drivers/gpu/drm/udl/udl_connector.c
> @@ -109,6 +109,14 @@ static int udl_mode_valid(struct drm_connector
> *connector,
> struct drm_display_mode *mode)
> {
> struct udl_device *udl = connector->dev->dev_private;
> + int con_type = connector->connector_type;
> +
> + if ((con_type == DRM_MODE_CONNECTOR_DVII ||
> +con_type == DRM_MODE_CONNECTOR_DVID ||
> +con_type == DRM_MODE_CONNECTOR_DVIA) &&
> + mode->clock > 165000)
> + return MODE_CLOCK_HIGH;
I think you can just do (mode->clock > 165000)
At least currently the driver hardcodes DVII connectors always.
Whether that is worth fixing (not even sure we get told what is on the
other side), is another question.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/fb: avoid setting 0 depth.
From: Dave Airlie
If the downscaling fails and we end up with a best_depth of 0,
then ignore it.
This actually works around a cascade of failure, but it the
simplest fix for now.
The scaling patch broke the udl driver, as the udl driver doesn't
expose planes at all, so gets the two default 32-bit formats, but
the udl driver then ask for 16bpp fbdev, and the scaling code falls
over.
This fixes the udl driver since the scaled depth support was added.
Fixes: f4bd542bcaee (drm/fb-helper: Scale back depth to supported maximum)
Cc: Daniel Vetter
Cc: Linus Walleij
Signed-off-by: Dave Airlie
---
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 0e9349ff2d16..af2ab640cadb 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1963,7 +1963,7 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
best_depth = fmt->depth;
}
}
- if (sizes.surface_depth != best_depth) {
+ if (sizes.surface_depth != best_depth && best_depth) {
DRM_INFO("requested bpp %d, scaled depth down to %d",
sizes.surface_bpp, best_depth);
sizes.surface_depth = best_depth;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/udl: use drm_gem_object_put_unlocked.
From: Dave Airlie When Daniel removed struct_mutex he didn't fix this call to the unlocked variant which is required since we no longer use struct mutex. This fixes a bunch of: WARNING: CPU: 4 PID: 1370 at drivers/gpu/drm/drm_gem.c:931 drm_gem_object_put+0x2b/0x30 [drm] Modules linked in: udl xt_CHECKSUM ipt_MASQUERADE tun bridge stp llc nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t> CPU: 4 PID: 1370 Comm: Xorg Not tainted 5.0.0+ #2 backtraces when you plug in a udl device. Fixes: ae358dacd217 (drm/udl: Get rid of dev->struct_mutex usage) Cc: Daniel Vetter Cc: Sean Paul Signed-off-by: Dave Airlie --- drivers/gpu/drm/udl/udl_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c index d5a23295dd80..bb7b58407039 100644 --- a/drivers/gpu/drm/udl/udl_gem.c +++ b/drivers/gpu/drm/udl/udl_gem.c @@ -224,7 +224,7 @@ int udl_gem_mmap(struct drm_file *file, struct drm_device *dev, *offset = drm_vma_node_offset_addr(&gobj->base.vma_node); out: - drm_gem_object_put(&gobj->base); + drm_gem_object_put_unlocked(&gobj->base); unlock: mutex_unlock(&udl->gem_lock); return ret; -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for 5.1-rc1
Hi Linus, A few various fixes pulls and one late -next pull but it was nearly all fixes anyways. etnaviv: - late next pull - mmu mapping fix - build non-ARM arches - misc fixes i915: - HDCP state handling fix - shrinker interaction fix - atomic state leak fix qxl: - kick out framebuffers early fix amdgpu: - Powerplay fixes - DC fixes - BACO turned off for now on vega20 - Locking fix - KFD MQD fix - gfx9 golden register updates. Dave. drm-next-2019-03-15: drm i915, amdgpu, qxl and etnaviv fixes The following changes since commit 4b057e73f28f1df13b77b77a52094238ffdf8abd: Merge tag 'drm-misc-fixes-2019-02-22' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2019-03-05 08:14:22 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-next-2019-03-15 for you to fetch changes up to 0f1d37e65a59e9db33ab85f6e2c9784768ef80f4: Merge branch 'drm-next-5.1' of git://people.freedesktop.org/~agd5f/linux into drm-next (2019-03-14 12:15:02 +1000) drm i915, amdgpu, qxl and etnaviv fixes Alex Deucher (1): drm/amdgpu/powerplay: add missing breaks in polaris10_smumgr Anthony Koo (1): drm/amd/display: Fix issue with link_active state not correct for MST Ben Dooks (1): drm: add __user attribute to ptr_to_compat() Candice Li (1): Revert "drm/amdgpu: use BACO reset on vega20 if platform support" Chris Wilson (4): drm/i915: Protect i915_active iterators from the shrinker drm/i915: Reacquire priolist cache after dropping the engine lock drm/i915/selftests: Always free spinner on __sseu_prepare error drm/i915: Acquire breadcrumb ref before cancelling Christian König (1): drm/amdgpu: clear PDs/PTs only after initializing them Dan Carpenter (3): drm/etnaviv: fix some off by one bugs drm/etnaviv: NULL vs IS_ERR() buf in etnaviv_core_dump() drm/etnaviv: potential NULL dereference Dave Airlie (6): Merge tag 'drm-misc-next-fixes-2019-03-06' of git://anongit.freedesktop.org/drm/drm-misc into drm-next Merge branch 'drm-next-5.1' of git://people.freedesktop.org/~agd5f/linux into drm-next Merge branch 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux into drm-next Merge tag 'drm-misc-next-fixes-2019-03-13' of git://anongit.freedesktop.org/drm/drm-misc into drm-next Merge tag 'drm-intel-next-fixes-2019-03-12' of git://anongit.freedesktop.org/drm/drm-intel into drm-next Merge branch 'drm-next-5.1' of git://people.freedesktop.org/~agd5f/linux into drm-next Evan Quan (11): drm/amd/powerplay: fix the confusing ppfeature mask calculations drm/amd/powerplay: drop redundant soft min/max settings drm/amd/powerplay: need to reapply the dpm level settings drm/amd/powerplay: force FCLK to highest also for 5K or higher displays drm/amd/powerplay: overwrite ODSettingsMin for UCLK_FMAX feature drm/amd/powerplay: support retrieving clock information from other sysplls drm/amd/powerplay: set default fclk for no fclk dpm support case drm/amd/powerplay: honor the OD settings drm/amd/powerplay: show the right override pcie parameters drm/amd/powerplay: set max fan target temperature as 105C drm/amd/powerplay: correct power reading on fiji Gerd Hoffmann (3): drm: move i915_kick_out_vgacon to vgaarb drm/fb-helper: call vga_remove_vgacon automatically. drm/qxl: remove conflicting framebuffers earlier Harry Wentland (1): drm/amd/display: don't call dm_pp_ function from an fpu block Huang Rui (2): drm/amd/powerplay: use REG32_PCIE wrapper instead for powerplay drm/amdgpu: use REG32_PCIE wrapper instead for psp José Roberto de Souza (1): drm/i915: Fix atomic state leak when resetting HDMI link Kevin Wang (1): drm/amdkfd: use init_mqd function to allocate object for hid_mqd (CI) Lucas Stach (3): drm/etnaviv: move job context pointer to etnaviv_gem_submit drm/etnaviv: don't restrict to certain architectures drm/etnaviv: mmuv2: don't map zero page Mathias Fröhlich (1): drm/amd/display: Fix reference counting for struct dc_sink. Matthew Wilcox (2): etnaviv mailing list is moderated Build etnaviv on non-ARM architectures Nathan Chancellor (1): drm/amd/display: Pass app_tf by value rather than by reference Ramalingam C (1): drm/i915: HDCP state handling in ddi_update_pipe Sean Paul (1): drm: Merge __drm_atomic_helper_disable_all() into drm_atomic_helper_disable_all() Tvrtko Ursulin (1): drm/i915: Relax mmap VMA check shaoyunl (2): drm/powerplay: print current clock level when dpm is disabled on vg20 drm/amdgpu: Update gc golden setting for vega family MAINTAINERS| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
Re: [PATCH 2/2] drm/lima: driver for ARM Mali4xx GPUs
Rob Herring writes:
> On Thu, Mar 14, 2019 at 3:45 PM Dave Airlie wrote:
>>
>> On Thu, 14 Feb 2019 at 19:12, Christian König via dri-devel
>> wrote:
>> >
>> > Am 14.02.19 um 03:52 schrieb Alex Deucher via dri-devel:
>> > > [SNIP]
>> > > +static int lima_ioctl_gem_va(struct drm_device *dev, void *data,
>> > > struct drm_file *file)
>> > > +{
>> > > + struct drm_lima_gem_va *args = data;
>> > > +
>> > > + switch (args->op) {
>> > > + case LIMA_VA_OP_MAP:
>> > > + return lima_gem_va_map(file, args->handle,
>> > > args->flags, args->va);
>> > > + case LIMA_VA_OP_UNMAP:
>> > > + return lima_gem_va_unmap(file, args->handle,
>> > > args->va);
>> > These are mapping to GPU VA. Why not do that on GEM object creation or
>> > import or when the objects are submitted with cmd queue as other
>> > drivers do?
>> >
>> > To put it another way, These ioctls look different than what other
>> > drivers do. Why do you need to do things differently? My understanding
>> > is best practice is to map and return the GPU offset when the GEM
>> > object is created. This is what v3d does. I think Intel is moving to
>> > that. And panfrost will do that.
>> > >>> I think it would be a good idea to look at the amdgpu driver. This
>> > >>> driver is heavily modeled after it. Basically the GEM VA ioctl allows
>> > >>> userspace to manage per process (per fd really) virtual addresses.
>> > >> Why do you want userspace to manage assigning VAs versus the kernel to
>> > >> do so? Exposing that detail to userspace means the driver must support
>> > >> a per process address space. Letting the kernel assign addresses means
>> > >> it can either be a single address space or be a per process address
>> > >> space. It seems to me more flexible to allow the kernel driver to
>> > >> evolve without that ABI.
>> > > Having it in userspace provides a lot more flexibility and makes it
>> > > easier to support things like unified address space between CPU and
>> > > GPU. I guess it depends on the hw as to what is the right choice.
>> >
>> > To summarize we actually have tried this approach with the radeon and it
>> > turned out to be a really bad mistake.
>> >
>> > To implement features like partial residential textures and shared
>> > virtual address space you absolutely need userspace to be in charge of
>> > allocating virtual addresses.
>> >
>>
>> I think for lima not having this is fine, but for panfrost it really
>> should have it.
>>
>> If you can implement vulkan you probably want this, nouveau hasn't a
>> vulkan driver because of exactly this problem in their uapi, so maybe
>> adjust panfrost to do user-space managed vma.
>
> Wouldn't this just require an allocation flag to not map the BO up
> front and then new ioctl's like above to map and unmap at specified
> VAs? Seems like we could add that when we get there.
Sounds pretty reasonable to me.
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm: rcar-du: Remove unused prototypes
The CRTC suspend and resume functions have been replaced, but the
prototypes were not removed.
Remove the redundant definitions.
Signed-off-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index bcb35b0b7612..3f339a7e8d14 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -97,8 +97,6 @@ enum rcar_du_output {
int rcar_du_crtc_create(struct rcar_du_group *rgrp, unsigned int swindex,
unsigned int hwindex);
-void rcar_du_crtc_suspend(struct rcar_du_crtc *rcrtc);
-void rcar_du_crtc_resume(struct rcar_du_crtc *rcrtc);
void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm: rcar-du: crtc: make local functions static
The rcar_du_crtc_mode_valid() and rcar_du_crtc_get_crc_sources()
functions are accessed only through a function pointer table.
Convert the function definitions to be static to the module.
Signed-off-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 4cdea14d552f..57fd5c00494b 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -761,8 +761,9 @@ static void rcar_du_crtc_atomic_flush(struct drm_crtc *crtc,
rcar_du_vsp_atomic_flush(rcrtc);
}
-enum drm_mode_status rcar_du_crtc_mode_valid(struct drm_crtc *crtc,
- const struct drm_display_mode *mode)
+static enum drm_mode_status
+rcar_du_crtc_mode_valid(struct drm_crtc *crtc,
+ const struct drm_display_mode *mode)
{
struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
struct rcar_du_device *rcdu = rcrtc->group->dev;
@@ -981,8 +982,8 @@ static int rcar_du_crtc_verify_crc_source(struct drm_crtc
*crtc,
return 0;
}
-const char *const *rcar_du_crtc_get_crc_sources(struct drm_crtc *crtc,
- size_t *count)
+static const char *const *
+rcar_du_crtc_get_crc_sources(struct drm_crtc *crtc, size_t *count)
{
struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm: fix subtle spelling error in drm_crtc_state
The drm_crtc_state documentation contains a subtle misspelling of the word subtle. Correct it. Signed-off-by: Kieran Bingham --- include/drm/drm_crtc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index 85abd3fe9e83..f2b3762636df 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -78,7 +78,7 @@ struct drm_plane_helper_funcs; /** * struct drm_crtc_state - mutable CRTC state * - * Note that the distinction between @enable and @active is rather subtile: + * Note that the distinction between @enable and @active is rather subtle: * Flipping @active while @enable is set without changing anything else may * never return in a failure from the &drm_mode_config_funcs.atomic_check * callback. Userspace assumes that a DPMS On will always succeed. In other -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm: rcar-du: Cleanup minor CRTC issues
Three fairly trivial cleanup patches from while I've been working on the CRTC code on rcar-du. The first is a small spelling error in the drm_crtc_state documentation, and the following two are more directly cleaning up the rcar-du. Kieran Bingham (3): drm: fix subtle spelling error in drm_crtc_state drm: rcar-du: crtc: make local functions static drm: rcar-du: Remove unused prototypes drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 9 + drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 -- include/drm/drm_crtc.h | 2 +- 3 files changed, 6 insertions(+), 7 deletions(-) -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/lima: driver for ARM Mali4xx GPUs
On Thu, Mar 14, 2019 at 3:45 PM Dave Airlie wrote:
>
> On Thu, 14 Feb 2019 at 19:12, Christian König via dri-devel
> wrote:
> >
> > Am 14.02.19 um 03:52 schrieb Alex Deucher via dri-devel:
> > > [SNIP]
> > > +static int lima_ioctl_gem_va(struct drm_device *dev, void *data,
> > > struct drm_file *file)
> > > +{
> > > + struct drm_lima_gem_va *args = data;
> > > +
> > > + switch (args->op) {
> > > + case LIMA_VA_OP_MAP:
> > > + return lima_gem_va_map(file, args->handle,
> > > args->flags, args->va);
> > > + case LIMA_VA_OP_UNMAP:
> > > + return lima_gem_va_unmap(file, args->handle,
> > > args->va);
> > These are mapping to GPU VA. Why not do that on GEM object creation or
> > import or when the objects are submitted with cmd queue as other
> > drivers do?
> >
> > To put it another way, These ioctls look different than what other
> > drivers do. Why do you need to do things differently? My understanding
> > is best practice is to map and return the GPU offset when the GEM
> > object is created. This is what v3d does. I think Intel is moving to
> > that. And panfrost will do that.
> > >>> I think it would be a good idea to look at the amdgpu driver. This
> > >>> driver is heavily modeled after it. Basically the GEM VA ioctl allows
> > >>> userspace to manage per process (per fd really) virtual addresses.
> > >> Why do you want userspace to manage assigning VAs versus the kernel to
> > >> do so? Exposing that detail to userspace means the driver must support
> > >> a per process address space. Letting the kernel assign addresses means
> > >> it can either be a single address space or be a per process address
> > >> space. It seems to me more flexible to allow the kernel driver to
> > >> evolve without that ABI.
> > > Having it in userspace provides a lot more flexibility and makes it
> > > easier to support things like unified address space between CPU and
> > > GPU. I guess it depends on the hw as to what is the right choice.
> >
> > To summarize we actually have tried this approach with the radeon and it
> > turned out to be a really bad mistake.
> >
> > To implement features like partial residential textures and shared
> > virtual address space you absolutely need userspace to be in charge of
> > allocating virtual addresses.
> >
>
> I think for lima not having this is fine, but for panfrost it really
> should have it.
>
> If you can implement vulkan you probably want this, nouveau hasn't a
> vulkan driver because of exactly this problem in their uapi, so maybe
> adjust panfrost to do user-space managed vma.
Wouldn't this just require an allocation flag to not map the BO up
front and then new ioctl's like above to map and unmap at specified
VAs? Seems like we could add that when we get there.
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
2019 X.Org Foundation Election Delayed
To all X.Org Foundation Members: In order to give members more time to process the proposed changes to the bylaw the elections committee decided to delay the start of voting by one week. Updated Schedule: Nomination period Start: Jan 31 00:00 UTC Nomination period End: Feb 28 23:59 UTC Deadline of X.Org membership application or renewal: Mar 07 23:59 UTC Publication of Candidates & start of Candidate QA: Mar 11 Election Start: Mar 21 00:00 UTC Election End: Apr 4 23:59 UTC Please take some time to familiarize yourself with the proposed bylaw changes and the candidates. Details are at https://www.x.org/wiki/BoardOfDirectors/Elections/2019/ Harry, on behalf of the X.Org elections committee ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Bylaw Changes Vote
To all X.Org Foundation Members: My previous emails about the 2019 X.Org elections failed to mention on important ballot items that we'd like to vote on, in addition to the new board members: the Bylaw change The updated Bylaws to be voted on can be found here: https://gitlab.freedesktop.org/xorgfoundation/bylaws/blob/bylaw-updates/bylaws.pdf The individual changes can be seen here: https://gitlab.freedesktop.org/xorgfoundation/bylaws/commit/06e7f04f79131df2c86e9cdfedc00aa1d1ec3f52 Please take a look. To give members more time to understand and discuss this the elections committee decided to move the election out by a week. Voting will start Mar 21. Harry, on behalf of the X.Org elections committee ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 2019 X.Org Foundation Election Candidates
On 2019-03-14 4:40 p.m., Luc Verhaegen wrote: > On Thu, Mar 14, 2019 at 08:36:13PM +, Wentland, Harry wrote: >> On 2019-03-12 6:49 a.m., Luc Verhaegen wrote: >>> >>> Are these candidates the only thing we will be voting on? >>> >> >> You're right. The FDO question totally slipped me mind. >> >> We'll also be voting on the bylaw change I sent out sometime toward the end >> of last year to facilitate the marriage of fdo and x.org. >> >> I'll send out details shortly. > > Cool, thanks! > > This way members can actually review and perhaps discuss this instead of > being confrontend with this when voting for just candidates, without > preparation, which could've perhaps invalidated the result. > Definitely a big oversight on my part. Details are now on https://www.x.org/wiki/BoardOfDirectors/Elections/2019/ I'll bring this up at today's board meeting. Not sure if this warrants delaying start of voting but I'd consider extending the end date. Harry > Luc Verhaegen. > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/lima: driver for ARM Mali4xx GPUs
On Thu, 14 Feb 2019 at 19:12, Christian König via dri-devel
wrote:
>
> Am 14.02.19 um 03:52 schrieb Alex Deucher via dri-devel:
> > [SNIP]
> > +static int lima_ioctl_gem_va(struct drm_device *dev, void *data,
> > struct drm_file *file)
> > +{
> > + struct drm_lima_gem_va *args = data;
> > +
> > + switch (args->op) {
> > + case LIMA_VA_OP_MAP:
> > + return lima_gem_va_map(file, args->handle, args->flags,
> > args->va);
> > + case LIMA_VA_OP_UNMAP:
> > + return lima_gem_va_unmap(file, args->handle, args->va);
> These are mapping to GPU VA. Why not do that on GEM object creation or
> import or when the objects are submitted with cmd queue as other
> drivers do?
>
> To put it another way, These ioctls look different than what other
> drivers do. Why do you need to do things differently? My understanding
> is best practice is to map and return the GPU offset when the GEM
> object is created. This is what v3d does. I think Intel is moving to
> that. And panfrost will do that.
> >>> I think it would be a good idea to look at the amdgpu driver. This
> >>> driver is heavily modeled after it. Basically the GEM VA ioctl allows
> >>> userspace to manage per process (per fd really) virtual addresses.
> >> Why do you want userspace to manage assigning VAs versus the kernel to
> >> do so? Exposing that detail to userspace means the driver must support
> >> a per process address space. Letting the kernel assign addresses means
> >> it can either be a single address space or be a per process address
> >> space. It seems to me more flexible to allow the kernel driver to
> >> evolve without that ABI.
> > Having it in userspace provides a lot more flexibility and makes it
> > easier to support things like unified address space between CPU and
> > GPU. I guess it depends on the hw as to what is the right choice.
>
> To summarize we actually have tried this approach with the radeon and it
> turned out to be a really bad mistake.
>
> To implement features like partial residential textures and shared
> virtual address space you absolutely need userspace to be in charge of
> allocating virtual addresses.
>
I think for lima not having this is fine, but for panfrost it really
should have it.
If you can implement vulkan you probably want this, nouveau hasn't a
vulkan driver because of exactly this problem in their uapi, so maybe
adjust panfrost to do user-space managed vma.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 2019 X.Org Foundation Election Candidates
On Thu, Mar 14, 2019 at 08:36:13PM +, Wentland, Harry wrote: > On 2019-03-12 6:49 a.m., Luc Verhaegen wrote: > > > > Are these candidates the only thing we will be voting on? > > > > You're right. The FDO question totally slipped me mind. > > We'll also be voting on the bylaw change I sent out sometime toward the end > of last year to facilitate the marriage of fdo and x.org. > > I'll send out details shortly. Cool, thanks! This way members can actually review and perhaps discuss this instead of being confrontend with this when voting for just candidates, without preparation, which could've perhaps invalidated the result. Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 2019 X.Org Foundation Election Candidates
On 2019-03-12 6:49 a.m., Luc Verhaegen wrote: > On Tue, Mar 12, 2019 at 12:24:00AM +, Wentland, Harry wrote: >> To all X.Org Foundation Members: >> >> The election for the X.Org Foundation Board of Directors will begin on >> 14 March 2019. We have 6 candidates who are running for 4 seats. They >> are (in alphabetical order): > >> Attached below are the Personal Statements each candidate submitted >> for your consideration along with their Statements of Contribution >> that they submitted with the membership application. Please review >> each of the candidates' statements to help you decide whom to vote for >> during the upcoming election. >> >> If you have questions of the candidates, you should feel free to ask them >> here on the mailing list. >> >> The election committee will provide detailed instructions on how the voting >> system will work when the voting period begins. >> >> Harry, on behalf of the X.Org elections committee > > Are these candidates the only thing we will be voting on? > You're right. The FDO question totally slipped me mind. We'll also be voting on the bylaw change I sent out sometime toward the end of last year to facilitate the marriage of fdo and x.org. I'll send out details shortly. Harry > Luc Verhaegen. > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/7] dt-bindings: bus: Add binding for the Allwinner MBUS controller
The MBUS controller drives the MBUS that other devices in the SoC will
use to perform DMA. It also has a register interface that allows to
monitor and control the bandwidth and priorities for masters on that
bus.
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/arm/sunxi/sunxi-mbus.txt | 36 +++-
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/sunxi/sunxi-mbus.txt
diff --git a/Documentation/devicetree/bindings/arm/sunxi/sunxi-mbus.txt
b/Documentation/devicetree/bindings/arm/sunxi/sunxi-mbus.txt
new file mode 100644
index ..1464a4713553
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/sunxi/sunxi-mbus.txt
@@ -0,0 +1,36 @@
+Allwinner Memory Bus (MBUS) controller
+
+The MBUS controller drives the MBUS that other devices in the SoC will
+use to perform DMA. It also has a register interface that allows to
+monitor and control the bandwidth and priorities for masters on that
+bus.
+
+Required properties:
+ - compatible: Must be one of:
+ - allwinner,sun5i-a13-mbus
+ - reg: Offset and length of the register set for the controller
+ - clocks: phandle to the clock driving the controller
+ - dma-ranges: See section 2.3.9 of the DeviceTree Specification
+ - #interconnect-cells: Must be one, with the argument being the MBUS
+ port ID
+
+Each device having to perform their DMA through the MBUS must have the
+interconnects and interconnect-names properties set to the MBUS
+controller and with "dma-mem" as the interconnect name.
+
+Example:
+
+mbus: dram-controller@1c01000 {
+ compatible = "allwinner,sun5i-a13-mbus";
+ reg = <0x01c01000 0x1000>;
+ clocks = <&ccu CLK_MBUS>;
+ dma-ranges = <0x 0x4000 0x2000>;
+ #interconnect-cells = <1>;
+};
+
+fe0: display-frontend@1e0 {
+ compatible = "allwinner,sun5i-a13-display-frontend";
+ ...
+ interconnects = <&mbus 19>;
+ interconnect-names = "dma-mem";
+};
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/7] dt-bindings: interconnect: Add a dma interconnect name
The current DT bindings assume that the DMA will be performed by the
devices through their parent DT node, and rely on that assumption for the
address translation using dma-ranges.
However, some SoCs have devices that will perform DMA through another bus,
with separate address translation rules. We therefore need to express that
relationship, through the special interconnect name "dma".
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/interconnect/interconnect.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt
b/Documentation/devicetree/bindings/interconnect/interconnect.txt
index 5a3c575b387a..6f5d23a605b7 100644
--- a/Documentation/devicetree/bindings/interconnect/interconnect.txt
+++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
@@ -51,6 +51,10 @@ interconnect-names : List of interconnect path name strings
sorted in the same
interconnect-names to match interconnect paths with
interconnect
specifier pairs.
+ Reserved interconnect names:
+* dma-mem: Path from the device to the main memory of
+ the system
+
Example:
sdhci@7864000 {
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/7] sunxi: Add DT representation for the MBUS controller
Hi, We've had for quite some time to hack around in our drivers to take into account the fact that our DMA accesses are not done through the parent node, but through another bus with a different mapping than the CPU for the RAM (0 instead of 0x4000 for most SoCs). After some discussion after the submission of a camera device suffering of the same hacks, I've decided to put together a serie that introduce a special interconnect name called "dma" that that allows to express the DMA relationship between a master and its bus, even if they are not direct parents in the DT. Let me know what you think, Maxime Changes from v3: - Rebased on top of current next - Use a function pointer instead of the parent device node to fix the recursive cases - Fix the usage of the device_node index in __of_get_dma_parent - Refer to the DT Specification for dma-ranges in the MBUS binding - Used dma-mem as the property instead of dma Changes from v2: - Rewrite commit logs still mentionning dma-parent - Removed dma-parent-cells left over in the binding example - Removed dma-parent still being mentionned in comments Changes from v1: - Change to use the now merged interconnect bindings - Move the DMA parent retrieval logic to its own function - Rebase on top of 5.0 Maxime Ripard (7): dt-bindings: interconnect: Add a dma interconnect name dt-bindings: bus: Add binding for the Allwinner MBUS controller of: address: Add parent pointer to the __of_translate_address args of: address: Add support for the parent DMA bus drm/sun4i: Rely on dma interconnect for our RAM offset clk: sunxi-ng: sun5i: Export the MBUS clock ARM: dts: sun5i: Add the MBUS controller Documentation/devicetree/bindings/arm/sunxi/sunxi-mbus.txt | 36 ++- Documentation/devicetree/bindings/interconnect/interconnect.txt | 4 +- arch/arm/boot/dts/sun5i.dtsi| 13 ++- drivers/clk/sunxi-ng/ccu-sun5i.h| 4 +- drivers/gpu/drm/sun4i/sun4i_backend.c | 28 +++-- drivers/of/address.c| 42 +-- include/dt-bindings/clock/sun5i-ccu.h | 2 +- 7 files changed, 110 insertions(+), 19 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/sunxi/sunxi-mbus.txt base-commit: cf08baa29613dd899954089e7cc7dba1d478b365 -- git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 5/7] drm/sun4i: Rely on dma interconnect for our RAM offset
Now that we can express our DMA topology, rely on those property instead of
hardcoding an offset from the dma_addr_t which wasn't really great.
We still need to add some code to deal with the old DT that would lack that
property, but we move the offset to the DRM device dma_pfn_offset to be
able to rely on just the dma_addr_t associated to the GEM object.
Acked-by: Daniel Vetter
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 4c0d51f73237..93f3cacc3e74 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -361,13 +361,6 @@ int sun4i_backend_update_layer_buffer(struct sun4i_backend
*backend,
paddr = drm_fb_cma_get_gem_addr(fb, state, 0);
DRM_DEBUG_DRIVER("Setting buffer address to %pad\n", &paddr);
- /*
-* backend DMA accesses DRAM directly, bypassing the system
-* bus. As such, the address range is different and the buffer
-* address needs to be corrected.
-*/
- paddr -= PHYS_OFFSET;
-
if (fb->format->is_yuv)
return sun4i_backend_update_yuv_buffer(backend, fb, paddr);
@@ -814,6 +807,27 @@ static int sun4i_backend_bind(struct device *dev, struct
device *master,
dev_set_drvdata(dev, backend);
spin_lock_init(&backend->frontend_lock);
+ if (of_find_property(dev->of_node, "interconnects", NULL)) {
+ /*
+* This assume we have the same DMA constraints for all our the
+* devices in our pipeline (all the backends, but also the
+* frontends). This sounds bad, but it has always been the case
+* for us, and DRM doesn't do per-device allocation either, so
+* we would need to fix DRM first...
+*/
+ ret = of_dma_configure(drm->dev, dev->of_node, true);
+ if (ret)
+ return ret;
+ } else {
+ /*
+* If we don't have the interconnect property, most likely
+* because of an old DT, we need to set the DMA offset by hand
+* on our device since the RAM mapping is at 0 for the DMA bus,
+* unlike the CPU.
+*/
+ drm->dev->dma_pfn_offset = PHYS_PFN_OFFSET;
+ }
+
backend->engine.node = dev->of_node;
backend->engine.ops = &sun4i_backend_engine_ops;
backend->engine.id = sun4i_backend_of_get_id(dev->of_node);
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/7] of: address: Add support for the parent DMA bus
Some SoCs have devices that are using a separate bus from the main bus to
perform DMA.
These buses might have some restrictions and/or different mapping than from
the CPU side, so we'd need to express those using the usual dma-ranges, but
using a different DT node than the node's parent.
Now that the generic interconnect bindings are available, we can model an
interconnect with the reserved name "dma" for those use-cases.
Signed-off-by: Maxime Ripard
---
drivers/of/address.c | 29 ++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 140bd0718067..95e47f2e9198 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -678,14 +678,31 @@ u64 of_translate_address(struct device_node *dev, const
__be32 *in_addr)
}
EXPORT_SYMBOL(of_translate_address);
+static struct device_node *__of_get_dma_parent(const struct device_node *np)
+{
+ struct of_phandle_args args;
+ int ret, index;
+
+ index = of_property_match_string(np, "interconnect-names", "dma-mem");
+ if (index < 0)
+ return of_get_parent(np);
+
+ ret = of_parse_phandle_with_args(np, "interconnects",
+"#interconnect-cells",
+index, &args);
+ if (ret < 0)
+ return of_get_parent(np);
+
+ return of_node_get(args.np);
+}
+
u64 of_translate_dma_address(struct device_node *dev, const __be32 *in_addr)
{
struct device_node *host;
u64 ret;
- ret = __of_translate_address(dev, of_get_parent,
+ ret = __of_translate_address(dev, __of_get_dma_parent,
in_addr, "dma-ranges", &host);
-
if (host) {
of_node_put(host);
return OF_BAD_ADDR;
@@ -913,9 +930,15 @@ int of_dma_get_range(struct device_node *np, u64
*dma_addr, u64 *paddr, u64 *siz
return -EINVAL;
while (1) {
+ struct device_node *parent;
+
naddr = of_n_addr_cells(node);
nsize = of_n_size_cells(node);
- node = of_get_next_parent(node);
+
+ parent = __of_get_dma_parent(node);
+ of_node_put(node);
+
+ node = parent;
if (!node)
break;
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 6/7] clk: sunxi-ng: sun5i: Export the MBUS clock
The MBUS clock is used by the MBUS controller, so let's export it so that we can use it in our DT node. Reviewed-by: Rob Herring Signed-off-by: Maxime Ripard --- drivers/clk/sunxi-ng/ccu-sun5i.h | 4 include/dt-bindings/clock/sun5i-ccu.h | 2 +- 2 files changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/clk/sunxi-ng/ccu-sun5i.h b/drivers/clk/sunxi-ng/ccu-sun5i.h index 93a275fbd9a9..b66abd4fd0bf 100644 --- a/drivers/clk/sunxi-ng/ccu-sun5i.h +++ b/drivers/clk/sunxi-ng/ccu-sun5i.h @@ -60,10 +60,6 @@ /* The rest of the module clocks are exported */ -#define CLK_MBUS 99 - -/* And finally the IEP clock */ - #define CLK_NUMBER (CLK_IEP + 1) #endif /* _CCU_SUN5I_H_ */ diff --git a/include/dt-bindings/clock/sun5i-ccu.h b/include/dt-bindings/clock/sun5i-ccu.h index 81f34d477aeb..2e6b9ddcc24e 100644 --- a/include/dt-bindings/clock/sun5i-ccu.h +++ b/include/dt-bindings/clock/sun5i-ccu.h @@ -100,7 +100,7 @@ #define CLK_AVS96 #define CLK_HDMI 97 #define CLK_GPU98 - +#define CLK_MBUS 99 #define CLK_IEP100 #endif /* _DT_BINDINGS_CLK_SUN5I_H_ */ -- git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 7/7] ARM: dts: sun5i: Add the MBUS controller
The MBUS (and its associated controller) is the bus in the Allwinner SoCs
that DMA devices use in the system to access the memory.
Among other things (and depending on the SoC generation), it can also
enforce priorities or report bandwidth usages on a per-master basis.
One of the most notable thing is that instead of having the same mapping
for the RAM than the CPU, it maps it at address 0, which means we'll have
to do address translation thanks to the dma-ranges property.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun5i.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 5497d985c54a..1718dfb0b9b9 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -127,6 +127,7 @@
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
+ dma-ranges;
ranges;
system-control@1c0 {
@@ -181,6 +182,14 @@
};
};
+ mbus: dram-controller@1c01000 {
+ compatible = "allwinner,sun5i-a13-mbus";
+ reg = <0x01c01000 0x1000>;
+ clocks = <&ccu CLK_MBUS>;
+ dma-ranges = <0x 0x4000 0x2000>;
+ #interconnect-cells = <1>;
+ };
+
dma: dma-controller@1c02000 {
compatible = "allwinner,sun4i-a10-dma";
reg = <0x01c02000 0x1000>;
@@ -727,6 +736,8 @@
clock-names = "ahb", "mod",
"ram";
resets = <&ccu RST_DE_FE>;
+ interconnects = <&mbus 19>;
+ interconnect-names = "dma-mem";
status = "disabled";
ports {
@@ -755,6 +766,8 @@
clock-names = "ahb", "mod",
"ram";
resets = <&ccu RST_DE_BE>;
+ interconnects = <&mbus 18>;
+ interconnect-names = "dma-mem";
status = "disabled";
assigned-clocks = <&ccu CLK_DE_BE>;
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/7] of: address: Add parent pointer to the __of_translate_address args
The __of_translate_address function is used to translate the device tree
addresses to physical addresses using the various ranges property to create
the offset.
However, it's shared between the CPU addresses (based on the ranges
property) and the DMA addresses (based on dma-ranges). Since we're going to
add support for a DMA parent node that is not the DT parent node, we need
to change the logic a bit to have an optional parent node that we should
use.
Signed-off-by: Maxime Ripard
---
drivers/of/address.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 2270373b30ab..140bd0718067 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -569,6 +569,7 @@ static int of_translate_one(struct device_node *parent,
struct of_bus *bus,
* relative to that node.
*/
static u64 __of_translate_address(struct device_node *dev,
+ struct device_node *(*get_parent)(const
struct device_node *),
const __be32 *in_addr, const char *rprop,
struct device_node **host)
{
@@ -585,9 +586,10 @@ static u64 __of_translate_address(struct device_node *dev,
*host = NULL;
/* Get parent & match bus type */
- parent = of_get_parent(dev);
+ parent = get_parent(dev);
if (parent == NULL)
goto bail;
+
bus = of_match_bus(parent);
/* Count address cells & copy address locally */
@@ -609,7 +611,7 @@ static u64 __of_translate_address(struct device_node *dev,
/* Switch to parent bus */
of_node_put(dev);
dev = parent;
- parent = of_get_parent(dev);
+ parent = get_parent(dev);
/* If root, we have finished */
if (parent == NULL) {
@@ -665,7 +667,8 @@ u64 of_translate_address(struct device_node *dev, const
__be32 *in_addr)
struct device_node *host;
u64 ret;
- ret = __of_translate_address(dev, in_addr, "ranges", &host);
+ ret = __of_translate_address(dev, of_get_parent,
+in_addr, "ranges", &host);
if (host) {
of_node_put(host);
return OF_BAD_ADDR;
@@ -680,7 +683,8 @@ u64 of_translate_dma_address(struct device_node *dev, const
__be32 *in_addr)
struct device_node *host;
u64 ret;
- ret = __of_translate_address(dev, in_addr, "dma-ranges", &host);
+ ret = __of_translate_address(dev, of_get_parent,
+in_addr, "dma-ranges", &host);
if (host) {
of_node_put(host);
@@ -736,7 +740,8 @@ static u64 of_translate_ioport(struct device_node *dev,
const __be32 *in_addr,
unsigned long port;
struct device_node *host;
- taddr = __of_translate_address(dev, in_addr, "ranges", &host);
+ taddr = __of_translate_address(dev, of_get_parent,
+ in_addr, "ranges", &host);
if (host) {
/* host-specific port access */
port = logic_pio_trans_hwaddr(&host->fwnode, taddr, size);
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 12/13] ARM: dts: sun9i: Fix Display Engine DTC warnings
Our display engine endpoints trigger some DTC warnings due to the fact that
we're having a single endpoint that doesn't need any reg property, and
since we don't have a reg property, we don't need the address-cells and
size-cells properties anymore.
Fix those
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 15 +
arch/arm/boot/dts/sun9i-a80.dtsi| 64 --
2 files changed, 15 insertions(+), 64 deletions(-)
diff --git a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
index 28c034928d67..18156ffa3ce9 100644
--- a/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
+++ b/arch/arm/boot/dts/sun9i-a80-cubieboard4.dts
@@ -89,31 +89,23 @@
vga-dac {
compatible = "corpro,gm7123", "adi,adv7123", "dumb-vga-dac";
vdd-supply = <®_dcdc1>;
- #address-cells = <1>;
- #size-cells = <0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <0>;
- vga_dac_in: endpoint@0 {
- reg = <0>;
+ vga_dac_in: endpoint {
remote-endpoint = <&tcon0_out_vga>;
};
};
port@1 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <1>;
- vga_dac_out: endpoint@0 {
- reg = <0>;
+ vga_dac_out: endpoint {
remote-endpoint = <&vga_con_in>;
};
};
@@ -502,8 +494,7 @@
};
&tcon0_out {
- tcon0_out_vga: endpoint@0 {
- reg = <0>;
+ tcon0_out_vga: endpoint {
remote-endpoint = <&vga_dac_in>;
};
};
diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index 6fb292e0b662..9b15f272e5f5 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -596,12 +596,9 @@
#size-cells = <0>;
fe0_out: port@1 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <1>;
- fe0_out_deu0: endpoint@0 {
- reg = <0>;
+ fe0_out_deu0: endpoint {
remote-endpoint =
<&deu0_in_fe0>;
};
};
@@ -623,12 +620,9 @@
#size-cells = <0>;
fe1_out: port@1 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <1>;
- fe1_out_deu1: endpoint@0 {
- reg = <0>;
+ fe1_out_deu1: endpoint {
remote-endpoint =
<&deu1_in_fe1>;
};
};
@@ -666,12 +660,9 @@
};
be0_out: port@1 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <1>;
- be0_out_drc0: endpoint@0 {
- reg = <0>;
+ be0_out_drc0: endpoint {
remote-endpoint =
<&drc0_in_be0>;
};
};
@@ -709,12 +700,9 @@
};
be1_out: port@1 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <1>;
- be1_out_drc1: endpoint@0 {
- reg = <0>;
+ be1_out_drc1: endpoint {
remote-endpoint =
<&drc1_in_be1>;
};
[PATCH v2 07/13] ARM: dts: sun6i: Fix Display Engine DTC warnings
Our display engine endpoints trigger some DTC warnings due to the fact that
we're having a single endpoint that doesn't need any reg property, and
since we don't have a reg property, we don't need the address-cells and
size-cells properties anymore.
Fix those
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 12 ++--
arch/arm/boot/dts/sun6i-a31.dtsi| 12 ++--
2 files changed, 4 insertions(+), 20 deletions(-)
diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index e17a65b3561e..63b84327f4e9 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -86,31 +86,23 @@
vga-dac {
compatible = "dumb-vga-dac";
vdd-supply = <®_vga_3v3>;
- #address-cells = <1>;
- #size-cells = <0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <0>;
- vga_dac_in: endpoint@0 {
- reg = <0>;
+ vga_dac_in: endpoint {
remote-endpoint = <&tcon0_out_vga>;
};
};
port@1 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <1>;
- vga_dac_out: endpoint@0 {
- reg = <0>;
+ vga_dac_out: endpoint {
remote-endpoint = <&vga_con_in>;
};
};
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 13304b8c5139..2445b51dec14 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -491,8 +491,6 @@
};
hdmi_out: port@1 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <1>;
};
};
@@ -1229,12 +1227,9 @@
};
be0_out: port@1 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <1>;
- be0_out_drc0: endpoint@0 {
- reg = <0>;
+ be0_out_drc0: endpoint {
remote-endpoint =
<&drc0_in_be0>;
};
};
@@ -1259,12 +1254,9 @@
#size-cells = <0>;
drc0_in: port@0 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <0>;
- drc0_in_be0: endpoint@0 {
- reg = <0>;
+ drc0_in_be0: endpoint {
remote-endpoint =
<&be0_out_drc0>;
};
};
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 11/13] ARM: dts: sun8i: r40: Fix Display Engine DTC warnings
Our display engine endpoints trigger some DTC warnings due to the fact that
we're having a single endpoint that doesn't need any reg property, and
since we don't have a reg property, we don't need the address-cells and
size-cells properties anymore.
Fix those
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun8i-r40.dtsi | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi
index 06b685869f52..1061d46efafd 100644
--- a/arch/arm/boot/dts/sun8i-r40.dtsi
+++ b/arch/arm/boot/dts/sun8i-r40.dtsi
@@ -614,12 +614,9 @@
#size-cells = <0>;
tcon_top_mixer0_in: port@0 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <0>;
- tcon_top_mixer0_in_mixer0: endpoint@0 {
- reg = <0>;
+ tcon_top_mixer0_in_mixer0: endpoint {
remote-endpoint =
<&mixer0_out_tcon_top>;
};
};
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 06/13] ARM: dts: sun5i: Fix Display Engine DTC warnings
Our display engine endpoints trigger some DTC warnings due to the fact that
we're having a single endpoint that doesn't need any reg property, and
since we don't have a reg property, we don't need the address-cells and
size-cells properties anymore.
Fix those
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 2 --
arch/arm/boot/dts/sun5i-a13-q8-tablet.dts | 11 ++-
2 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
b/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
index 9409c232d48a..54ca140fc258 100644
--- a/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
+++ b/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
@@ -74,8 +74,6 @@
bridge {
compatible = "dumb-vga-dac";
- #address-cells = <1>;
- #size-cells = <0>;
ports {
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/sun5i-a13-q8-tablet.dts
b/arch/arm/boot/dts/sun5i-a13-q8-tablet.dts
index 7257f39b31ce..fde559a8b61e 100644
--- a/arch/arm/boot/dts/sun5i-a13-q8-tablet.dts
+++ b/arch/arm/boot/dts/sun5i-a13-q8-tablet.dts
@@ -53,16 +53,9 @@
power-supply = <®_vcc3v3>;
enable-gpios = <&axp_gpio 0 GPIO_ACTIVE_HIGH>; /* AXP GPIO0 */
backlight = <&backlight>;
- #address-cells = <1>;
- #size-cells = <0>;
- port@0 {
- reg = <0>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- panel_input: endpoint@0 {
- reg = <0>;
+ port {
+ panel_input: endpoint {
remote-endpoint = <&tcon0_out_lcd>;
};
};
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 02/13] drm/sun4i: mixer: Simplify the get_id logic
Using the new helpers introduced since we wrote that code, we can simplify
the code to retrieve the mixer ID significantly.
The new code will also allow us to deal nicely with endpoints that don't
have a reg property, as expected in the case where there's a single
endpoint for a given port.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 39 --
1 file changed, 11 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 30a2eff55687..bf44a601a653 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -325,38 +325,21 @@ static struct regmap_config sun8i_mixer_regmap_config = {
static int sun8i_mixer_of_get_id(struct device_node *node)
{
- struct device_node *port, *ep;
- int ret = -EINVAL;
+ struct device_node *ep, *remote;
+ struct of_endpoint of_ep;
- /* output is port 1 */
- port = of_graph_get_port_by_id(node, 1);
- if (!port)
+ /* Output port is 1, and we want the first endpoint. */
+ ep = of_graph_get_endpoint_by_regs(node, 1, -1);
+ if (!ep)
return -EINVAL;
- /* try to find downstream endpoint */
- for_each_available_child_of_node(port, ep) {
- struct device_node *remote;
- u32 reg;
-
- remote = of_graph_get_remote_endpoint(ep);
- if (!remote)
- continue;
-
- ret = of_property_read_u32(remote, "reg", ®);
- if (!ret) {
- of_node_put(remote);
- of_node_put(ep);
- of_node_put(port);
-
- return reg;
- }
-
- of_node_put(remote);
- }
-
- of_node_put(port);
+ remote = of_graph_get_remote_endpoint(ep);
+ if (!remote)
+ return -EINVAL;
- return ret;
+ of_graph_parse_endpoint(remote, &of_ep);
+ of_node_put(remote);
+ return of_ep.id;
}
static int sun8i_mixer_bind(struct device *dev, struct device *master,
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 13/13] ARM: dts: sun9i: Add missing unit address
The soc node in the A80 DTSI has a ranges property, but no matching unit
address, which results in a DTC warning. Add the unit address to remove
that warning.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun9i-a80.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index 9b15f272e5f5..7a495c84ab65 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -289,7 +289,7 @@
status = "disabled";
};
- soc {
+ soc@2 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 08/13] ARM: dts: sun8i: a23/a33: Fix Display Engine DTC warnings
Our display engine endpoints trigger some DTC warnings due to the fact that
we're having a single endpoint that doesn't need any reg property, and
since we don't have a reg property, we don't need the address-cells and
size-cells properties anymore.
Fix those
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun8i-a23-a33.dtsi | 32 +++
arch/arm/boot/dts/sun8i-a23-q8-tablet.dts | 6 -
arch/arm/boot/dts/sun8i-a33-q8-tablet.dts | 7 -
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 11 +--
arch/arm/boot/dts/sun8i-a33.dtsi | 18 +++
arch/arm/boot/dts/sun8i-q8-common.dtsi | 18 +--
6 files changed, 29 insertions(+), 63 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index 43fe215e83ea..6d2625a90a09 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -192,19 +192,14 @@
#size-cells = <0>;
tcon0_in: port@0 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <0>;
- tcon0_in_drc0: endpoint@0 {
- reg = <0>;
+ tcon0_in_drc0: endpoint {
remote-endpoint =
<&drc0_out_tcon0>;
};
};
tcon0_out: port@1 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <1>;
};
};
@@ -627,12 +622,9 @@
#size-cells = <0>;
fe0_out: port@1 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <1>;
- fe0_out_be0: endpoint@0 {
- reg = <0>;
+ fe0_out_be0: endpoint {
remote-endpoint = <&be0_in_fe0>;
};
};
@@ -654,23 +646,17 @@
#size-cells = <0>;
be0_in: port@0 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <0>;
- be0_in_fe0: endpoint@0 {
- reg = <0>;
+ be0_in_fe0: endpoint {
remote-endpoint =
<&fe0_out_be0>;
};
};
be0_out: port@1 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <1>;
- be0_out_drc0: endpoint@0 {
- reg = <0>;
+ be0_out_drc0: endpoint {
remote-endpoint =
<&drc0_in_be0>;
};
};
@@ -694,23 +680,17 @@
#size-cells = <0>;
drc0_in: port@0 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <0>;
- drc0_in_be0: endpoint@0 {
- reg = <0>;
+ drc0_in_be0: endpoint {
remote-endpoint =
<&be0_out_drc0>;
};
};
drc0_out: port@1 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <1>;
- drc0_out_tcon0: endpoint@0 {
- reg = <0>;
+ drc0_out_tcon0: endpoint {
remote-endpoint =
<&tcon0_in_drc0>;
};
};
di
[PATCH v2 09/13] ARM: dts: sun8i: v3s: Fix Display Engine DTC warnings
Our display engine endpoints trigger some DTC warnings due to the fact that
we're having a single endpoint that doesn't need any reg property, and
since we don't have a reg property, we don't need the address-cells and
size-cells properties anymore.
Fix those
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 21e1806ca509..7918064e0940 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -129,12 +129,9 @@
#size-cells = <0>;
mixer0_out: port@1 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <1>;
- mixer0_out_tcon0: endpoint@0 {
- reg = <0>;
+ mixer0_out_tcon0: endpoint {
remote-endpoint =
<&tcon0_in_mixer0>;
};
};
@@ -159,12 +156,9 @@
#size-cells = <0>;
tcon0_in: port@0 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <0>;
- tcon0_in_mixer0: endpoint@0 {
- reg = <0>;
+ tcon0_in_mixer0: endpoint {
remote-endpoint =
<&mixer0_out_tcon0>;
};
};
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 04/13] arm64: dts: allwinner: a64: Add cross links for the mixers
Unlike what the binding for multiple pipeline documents, the A64 doesn't
have the cross links between the TCON and the mixers.
Let's add them.
Signed-off-by: Maxime Ripard
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 33 ++--
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index e628d063931b..ccd143d82aea 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -251,11 +251,19 @@
#size-cells = <0>;
mixer0_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
reg = <1>;
- mixer0_out_tcon0: endpoint {
+ mixer0_out_tcon0: endpoint@0 {
+ reg = <0>;
remote-endpoint =
<&tcon0_in_mixer0>;
};
+
+ mixer0_out_tcon1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint =
<&tcon1_in_mixer0>;
+ };
};
};
};
@@ -276,7 +284,13 @@
mixer1_out: port@1 {
reg = <1>;
- mixer1_out_tcon1: endpoint {
+ mixer1_out_tcon0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&tcon0_in_mixer1>;
+ };
+
+ mixer1_out_tcon1: endpoint@1 {
+ reg = <1>;
remote-endpoint =
<&tcon1_in_mixer1>;
};
};
@@ -354,6 +368,11 @@
reg = <0>;
remote-endpoint =
<&mixer0_out_tcon0>;
};
+
+ tcon0_in_mixer1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint =
<&mixer1_out_tcon1>;
+ };
};
tcon0_out: port@1 {
@@ -379,9 +398,17 @@
#size-cells = <0>;
tcon1_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
reg = <0>;
- tcon1_in_mixer1: endpoint {
+ tcon1_in_mixer0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&mixer0_out_tcon1>;
+ };
+
+ tcon1_in_mixer1: endpoint@1 {
+ reg = <1>;
remote-endpoint =
<&mixer1_out_tcon1>;
};
};
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 00/13] ARM: dts: sunxi: Cleanup DTC warnings
Here is the rest of the series that fixes most of our DTC warnings. The number of warnings when compiled with W=1 after applying this series is now reduced to 2. The two remaining one are on the A80 and would require some change in the clock driver. Given how little activity there is on the A80, we can expect it to not happen in a near future, but I can live with two warnings. Let me know what you think, Maxime Changes from v1: - Rebased on current tree - Added some code in the DRM driver to deal with the endpoints - Fixed the DTS pipeline for the A83t and A64 Maxime Ripard (13): drm/sun4i: backend: Simplify the get_id logic drm/sun4i: mixer: Simplify the get_id logic ARM: dts: sun8i: a83t: Add cross links for the mixers arm64: dts: allwinner: a64: Add cross links for the mixers ARM: dts: sun5i: Fix display pipeline endpoint warnings in DTC ARM: dts: sun5i: Fix Display Engine DTC warnings ARM: dts: sun6i: Fix Display Engine DTC warnings ARM: dts: sun8i: a23/a33: Fix Display Engine DTC warnings ARM: dts: sun8i: v3s: Fix Display Engine DTC warnings ARM: dts: sun8i: a83t: Fix Display Engine DTC warnings ARM: dts: sun8i: r40: Fix Display Engine DTC warnings ARM: dts: sun9i: Fix Display Engine DTC warnings ARM: dts: sun9i: Add missing unit address arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 2 +- arch/arm/boot/dts/sun5i-a13-q8-tablet.dts | 11 +--- arch/arm/boot/dts/sun5i.dtsi | 25 +-- arch/arm/boot/dts/sun6i-a31-hummingbird.dts| 12 +--- arch/arm/boot/dts/sun6i-a31.dtsi | 12 +--- arch/arm/boot/dts/sun8i-a23-a33.dtsi | 32 + arch/arm/boot/dts/sun8i-a23-q8-tablet.dts | 6 ++- arch/arm/boot/dts/sun8i-a33-q8-tablet.dts | 7 ++- arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 11 +--- arch/arm/boot/dts/sun8i-a33.dtsi | 18 + arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 3 +- arch/arm/boot/dts/sun8i-a83t.dtsi | 32 +++-- arch/arm/boot/dts/sun8i-q8-common.dtsi | 18 +- arch/arm/boot/dts/sun8i-r40.dtsi | 5 +- arch/arm/boot/dts/sun8i-v3s.dtsi | 10 +--- arch/arm/boot/dts/sun9i-a80-cubieboard4.dts| 15 + arch/arm/boot/dts/sun9i-a80.dtsi | 66 +++ arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 33 +- drivers/gpu/drm/sun4i/sun4i_backend.c | 34 +++--- drivers/gpu/drm/sun4i/sun8i_mixer.c| 39 +++ 20 files changed, 140 insertions(+), 251 deletions(-) base-commit: cf08baa29613dd899954089e7cc7dba1d478b365 -- git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 01/13] drm/sun4i: backend: Simplify the get_id logic
Using the new helpers introduced since we wrote that code, we can simplify
the code to retrieve the backend ID significantly.
The new code will also allow us to deal nicely with endpoints that don't
have a reg property, as expected in the case where there's a single
endpoint for a given port.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 34 +---
1 file changed, 11 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 4c0d51f73237..02ef8e455db8 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -720,33 +720,21 @@ static int sun4i_backend_free_sat(struct device *dev) {
*/
static int sun4i_backend_of_get_id(struct device_node *node)
{
- struct device_node *port, *ep;
- int ret = -EINVAL;
+ struct device_node *ep, *remote;
+ struct of_endpoint of_ep;
- /* input is port 0 */
- port = of_graph_get_port_by_id(node, 0);
- if (!port)
+ /* Input port is 0, and we want the first endpoint. */
+ ep = of_graph_get_endpoint_by_regs(node, 0, -1);
+ if (!ep)
return -EINVAL;
- /* try finding an upstream endpoint */
- for_each_available_child_of_node(port, ep) {
- struct device_node *remote;
- u32 reg;
-
- remote = of_graph_get_remote_endpoint(ep);
- if (!remote)
- continue;
-
- ret = of_property_read_u32(remote, "reg", ®);
- if (ret)
- continue;
-
- ret = reg;
- }
-
- of_node_put(port);
+ remote = of_graph_get_remote_endpoint(ep);
+ if (!remote)
+ return -EINVAL;
- return ret;
+ of_graph_parse_endpoint(remote, &of_ep);
+ of_node_put(remote);
+ return of_ep.id;
}
/* TODO: This needs to take multiple pipelines into account */
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 10/13] ARM: dts: sun8i: a83t: Fix Display Engine DTC warnings
Our display engine endpoints trigger some DTC warnings due to the fact that
we're having a single endpoint that doesn't need any reg property, and
since we don't have a reg property, we don't need the address-cells and
size-cells properties anymore.
Fix those
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 3 +--
arch/arm/boot/dts/sun8i-a83t.dtsi | 2 --
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
index 98e8cea26dbe..4bda2f9372cb 100644
--- a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
@@ -391,8 +391,7 @@
};
&tcon0_out {
- tcon0_out_lcd: endpoint@0 {
- reg = <0>;
+ tcon0_out_lcd: endpoint {
remote-endpoint = <&panel_input>;
};
};
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 7651b6dcfd0f..7340b01c1994 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -457,8 +457,6 @@
};
tcon0_out: port@1 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <1>;
};
};
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 03/13] ARM: dts: sun8i: a83t: Add cross links for the mixers
Unlike what the binding for multiple pipeline documents, the A83t doesn't
have the cross links between the TCON and the mixers.
Let's add them.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index b099d2fbb5cd..7651b6dcfd0f 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -333,6 +333,11 @@
reg = <0>;
remote-endpoint =
<&tcon0_in_mixer0>;
};
+
+ mixer0_out_tcon1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint =
<&tcon1_in_mixer0>;
+ };
};
};
};
@@ -351,9 +356,17 @@
#size-cells = <0>;
mixer1_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
reg = <1>;
- mixer1_out_tcon1: endpoint {
+ mixer1_out_tcon0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&tcon0_in_mixer1>;
+ };
+
+ mixer1_out_tcon1: endpoint@1 {
+ reg = <1>;
remote-endpoint =
<&tcon1_in_mixer1>;
};
};
@@ -436,6 +449,11 @@
reg = <0>;
remote-endpoint =
<&mixer0_out_tcon0>;
};
+
+ tcon0_in_mixer1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint =
<&mixer1_out_tcon0>;
+ };
};
tcon0_out: port@1 {
@@ -460,9 +478,17 @@
#size-cells = <0>;
tcon1_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
reg = <0>;
- tcon1_in_mixer1: endpoint {
+ tcon1_in_mixer0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&mixer0_out_tcon1>;
+ };
+
+ tcon1_in_mixer1: endpoint@1 {
+ reg = <1>;
remote-endpoint =
<&mixer1_out_tcon1>;
};
};
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/13] ARM: dts: sun5i: Fix display pipeline endpoint warnings in DTC
Since most of the display IPs have a single endpoint, having a reg
property, a unit-address and #address-cells and #size-cells will emit a
warning.
Let's remove those.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun5i.dtsi | 25 +
1 file changed, 5 insertions(+), 20 deletions(-)
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 5497d985c54a..ccd793795e58 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -238,11 +238,8 @@
status = "disabled";
port {
- #address-cells = <1>;
- #size-cells = <0>;
- tve0_in_tcon0: endpoint@0 {
- reg = <0>;
+ tve0_in_tcon0: endpoint {
remote-endpoint = <&tcon0_out_tve0>;
};
};
@@ -285,12 +282,9 @@
#size-cells = <0>;
tcon0_in: port@0 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <0>;
- tcon0_in_be0: endpoint@0 {
- reg = <0>;
+ tcon0_in_be0: endpoint {
remote-endpoint =
<&be0_out_tcon0>;
};
};
@@ -734,12 +728,9 @@
#size-cells = <0>;
fe0_out: port@1 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <1>;
- fe0_out_be0: endpoint@0 {
- reg = <0>;
+ fe0_out_be0: endpoint {
remote-endpoint = <&be0_in_fe0>;
};
};
@@ -765,23 +756,17 @@
#size-cells = <0>;
be0_in: port@0 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <0>;
- be0_in_fe0: endpoint@0 {
- reg = <0>;
+ be0_in_fe0: endpoint {
remote-endpoint =
<&fe0_out_be0>;
};
};
be0_out: port@1 {
- #address-cells = <1>;
- #size-cells = <0>;
reg = <1>;
- be0_out_tcon0: endpoint@0 {
- reg = <0>;
+ be0_out_tcon0: endpoint {
remote-endpoint =
<&tcon0_in_be0>;
};
};
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/8] drm/bridge: dw-hdmi: Add SCDC and TMDS Scrambling support
On Thu, Mar 14, 2019 at 3:07 PM Neil Armstrong wrote: > > Hi Rob, > > Le 14/03/2019 19:55, Rob Herring a écrit : > > On Mon, Mar 11, 2019 at 3:53 AM Neil Armstrong > > wrote: > >> > >> On 08/03/2019 15:54, Rob Herring wrote: > >>> On Fri, Mar 8, 2019 at 2:05 AM Neil Armstrong > >>> wrote: > > Hi Rob, > > On 08/03/2019 00:13, Rob Herring wrote: > > On Fri, Feb 1, 2019 at 6:08 AM Neil Armstrong > > wrote: > >> > >> Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS > >> Scrambling when supported or mandatory. > >> > >> This patch also adds an helper to setup the control bit to support > >> the high TMDS Bit Period/TMDS Clock-Period Ratio as required with > >> TMDS Clock > 3.4GHz for HDMI2.0 3840x2160@60/50 modes. > >> > >> These changes were based on work done by Huicong Xu > >> > >> and Nickey Yang to support HDMI2.0 modes > >> on the Rockchip 4.4 BSP kernel at [1] > >> > >> [1] https://github.com/rockchip-linux/kernel/tree/release-4.4 > >> > >> Cc: Nickey Yang > >> Cc: Huicong Xu > >> Signed-off-by: Neil Armstrong > >> Tested-by: Heiko Stuebner > >> Reviewed-by: Andrzej Hajda > >> --- > >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 85 > >> ++- > >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 1 + > >> include/drm/bridge/dw_hdmi.h | 1 + > >> 3 files changed, 85 insertions(+), 2 deletions(-) > > > > This commit in drm-misc-next is breaking booting on the Rock960. I > > have FB and fbcon enabled. The boot hangs after this message: > > > > [3.012334] [drm:rockchip_drm_fbdev_create] FB [1920x1080]-24 > > kvaddr=(ptrval) offset=0 size=8294400 > > Could you give more details on the tree used ? did you bisect to find > this commit ? > >>> > >>> As I said above, drm-misc-next (from drm-misc tree) is the branch. I > >>> bisected between it and v5.0. Reverting it fixes booting. > >> > >> Thanks, could you give more details on the environment ? Did you test over > >> the latest linux-next ? > > > > Here's a log of the drm parts: https://pastebin.com/tFJ9Gs6h > > > > linux-next also hangs. > > > >> Can you share the EDID of your monitor ? > > > > Maybe not mode related. I tried forcing to 1280x720 and it hangs too. > > In any case, here's the parsed EDID: > > > > 256-byte EDID successfully retrieved from i2c bus 3 > > Looks like i2c was successful. Have a good day. > > Checksum Correct > > > > Section "Monitor" > > Identifier "CYS-R101" > > ModelName "CYS-R101" > > VendorName "CYX" > > # Monitor Manufactured week 28 of 2018 > > # EDID version 1.3 > > # Digital Display > > DisplaySize 220 130 > > Gamma 2.20 > > Option "DPMS" "true" > > Horizsync 30-102 > > VertRefresh 48-75 > > # Maximum pixel clock is 190MHz > > #Not giving standard mode: 1920x1080, 60Hz > > #Not giving standard mode: 1920x1080, 60Hz > > #Not giving standard mode: 1920x1080, 60Hz > > #Not giving standard mode: 1440x900, 60Hz > > #Not giving standard mode: 1400x1050, 60Hz > > #Not giving standard mode: 1280x1024, 60Hz > > #Not giving standard mode: 1280x960, 60Hz > > #Not giving standard mode: 1280x720, 60Hz > > > > #Extension block found. Parsing... > > Modeline "Mode 5" 54.00 2560 2608 2640 2720 1440 1443 1448 1481 +hsync > > +vsync > > Modeline "Mode 0" 267.81 2560 2608 2640 2720 1600 1603 1608 1641 +hsync > > +vsync > > Modeline "Mode 1" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync > > +vsync > > Modeline "Mode 2" 74.250 1920 2008 2052 2200 1080 1082 1087 1125 > > +hsync +vsync interlace > > Modeline "Mode 3" 74.250 1280 1390 1420 1650 720 725 730 750 +hsync +vsync > > Modeline "Mode 4" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync > > +vsync > > Option "PreferredMode" "Mode 5" > > EndSection > > > >> Can you check this patch : > > > > Still hangs with it. > > > Thanks for testing, the only impact would be if hdmi_info->scdc.supported > and hdmi_info->scdc.scrambling.low_rate were true. > Honestly, hdmi_info->scdc.scrambling.low_rate wasn't really tested. > > Could you dump the edid in binary format ? or parse it with > https://github.com/rpavlik/edid-decode > supporting modern HDMI EDIDs. Here's with edid-decode: EDID version: 1.3 Manufacturer: CYX Model 101 Serial Number 16843009 Made in week 28 of 2018 Digital display Maximum image size: 22 cm x 13 cm Gamma: 2.20 DPMS levels: Off Undefined display color type Default (sRGB) color space is primary color space First detailed timing is preferred timing Display x,y Chromaticity: Red: 0.6455, 0.3300 Green: 0.3095, 0.6171 Blue: 0.1523, 0.0732 White: 0.3134, 0.3291 Established timings supported: 640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz 800x600@60Hz 4:3 HorFreq: 37900 Hz Clock: 40.000 MHz 1024x768@60Hz 4:3 HorFreq: 48400 Hz Clock: 65.000 MHz Standard timings supported: 1920x1080@60Hz 16:9
Re: [PATCH v2 1/8] drm/bridge: dw-hdmi: Add SCDC and TMDS Scrambling support
Hi Rob, Le 14/03/2019 19:55, Rob Herring a écrit : > On Mon, Mar 11, 2019 at 3:53 AM Neil Armstrong > wrote: >> >> On 08/03/2019 15:54, Rob Herring wrote: >>> On Fri, Mar 8, 2019 at 2:05 AM Neil Armstrong >>> wrote: Hi Rob, On 08/03/2019 00:13, Rob Herring wrote: > On Fri, Feb 1, 2019 at 6:08 AM Neil Armstrong > wrote: >> >> Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS >> Scrambling when supported or mandatory. >> >> This patch also adds an helper to setup the control bit to support >> the high TMDS Bit Period/TMDS Clock-Period Ratio as required with >> TMDS Clock > 3.4GHz for HDMI2.0 3840x2160@60/50 modes. >> >> These changes were based on work done by Huicong Xu >> and Nickey Yang to support HDMI2.0 modes >> on the Rockchip 4.4 BSP kernel at [1] >> >> [1] https://github.com/rockchip-linux/kernel/tree/release-4.4 >> >> Cc: Nickey Yang >> Cc: Huicong Xu >> Signed-off-by: Neil Armstrong >> Tested-by: Heiko Stuebner >> Reviewed-by: Andrzej Hajda >> --- >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 85 >> ++- >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 1 + >> include/drm/bridge/dw_hdmi.h | 1 + >> 3 files changed, 85 insertions(+), 2 deletions(-) > > This commit in drm-misc-next is breaking booting on the Rock960. I > have FB and fbcon enabled. The boot hangs after this message: > > [3.012334] [drm:rockchip_drm_fbdev_create] FB [1920x1080]-24 > kvaddr=(ptrval) offset=0 size=8294400 Could you give more details on the tree used ? did you bisect to find this commit ? >>> >>> As I said above, drm-misc-next (from drm-misc tree) is the branch. I >>> bisected between it and v5.0. Reverting it fixes booting. >> >> Thanks, could you give more details on the environment ? Did you test over >> the latest linux-next ? > > Here's a log of the drm parts: https://pastebin.com/tFJ9Gs6h > > linux-next also hangs. > >> Can you share the EDID of your monitor ? > > Maybe not mode related. I tried forcing to 1280x720 and it hangs too. > In any case, here's the parsed EDID: > > 256-byte EDID successfully retrieved from i2c bus 3 > Looks like i2c was successful. Have a good day. > Checksum Correct > > Section "Monitor" > Identifier "CYS-R101" > ModelName "CYS-R101" > VendorName "CYX" > # Monitor Manufactured week 28 of 2018 > # EDID version 1.3 > # Digital Display > DisplaySize 220 130 > Gamma 2.20 > Option "DPMS" "true" > Horizsync 30-102 > VertRefresh 48-75 > # Maximum pixel clock is 190MHz > #Not giving standard mode: 1920x1080, 60Hz > #Not giving standard mode: 1920x1080, 60Hz > #Not giving standard mode: 1920x1080, 60Hz > #Not giving standard mode: 1440x900, 60Hz > #Not giving standard mode: 1400x1050, 60Hz > #Not giving standard mode: 1280x1024, 60Hz > #Not giving standard mode: 1280x960, 60Hz > #Not giving standard mode: 1280x720, 60Hz > > #Extension block found. Parsing... > Modeline "Mode 5" 54.00 2560 2608 2640 2720 1440 1443 1448 1481 +hsync +vsync > Modeline "Mode 0" 267.81 2560 2608 2640 2720 1600 1603 1608 1641 +hsync +vsync > Modeline "Mode 1" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync > +vsync > Modeline "Mode 2" 74.250 1920 2008 2052 2200 1080 1082 1087 1125 > +hsync +vsync interlace > Modeline "Mode 3" 74.250 1280 1390 1420 1650 720 725 730 750 +hsync +vsync > Modeline "Mode 4" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync > +vsync > Option "PreferredMode" "Mode 5" > EndSection > >> Can you check this patch : > > Still hangs with it. Thanks for testing, the only impact would be if hdmi_info->scdc.supported and hdmi_info->scdc.scrambling.low_rate were true. Honestly, hdmi_info->scdc.scrambling.low_rate wasn't really tested. Could you dump the edid in binary format ? or parse it with https://github.com/rpavlik/edid-decode supporting modern HDMI EDIDs. Thanks, Neil > >> >> >< >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >> index a63e5f0dae56..f33c2ac158c1 100644 >> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >> @@ -1268,8 +1268,6 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi) >> >> dw_hdmi_phy_power_off(hdmi); >> >> - dw_hdmi_set_high_tmds_clock_ratio(hdmi); >> - >> /* Leave low power consumption mode by asserting SVSRET. */ >> if (phy->has_svsret) >> dw_hdmi_phy_enable_svsret(hdmi, 1); >> >> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/v3d: Use the new shmem helpers to reduce driver boilerplate.
Rob Herring writes:
> On Thu, Mar 14, 2019 at 11:34 AM Eric Anholt wrote:
>>
>> The new shmem helpers from Noralf and Rob abstract out a bunch of our
>> BO creation and mapping code.
>>
>> v2: Use the new sgt getter, and flag pages as dirty before freeing.
>>
>> Signed-off-by: Eric Anholt
>> ---
>> drivers/gpu/drm/v3d/Kconfig | 1 +
>> drivers/gpu/drm/v3d/v3d_bo.c | 317 ++
>> drivers/gpu/drm/v3d/v3d_drv.c | 27 +--
>> drivers/gpu/drm/v3d/v3d_drv.h | 14 +-
>> drivers/gpu/drm/v3d/v3d_gem.c | 12 +-
>> drivers/gpu/drm/v3d/v3d_irq.c | 8 +-
>> drivers/gpu/drm/v3d/v3d_mmu.c | 11 +-
>> 7 files changed, 120 insertions(+), 270 deletions(-)
>
>> diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
>> index 945ed016..b84d89c7b3fb 100644
>> --- a/drivers/gpu/drm/v3d/v3d_gem.c
>> +++ b/drivers/gpu/drm/v3d/v3d_gem.c
>> @@ -201,7 +201,8 @@ v3d_attach_object_fences(struct v3d_bo **bos, int
>> bo_count,
>>
>> for (i = 0; i < bo_count; i++) {
>> /* XXX: Use shared fences for read-only objects. */
>> - reservation_object_add_excl_fence(bos[i]->base.resv, fence);
>> + reservation_object_add_excl_fence(bos[i]->base.base.resv,
>> + fence);
>
> All these 'bos[i]->base.base' occurrences are not the prettiest.
> Changing your bos array to a struct drm_gem_object ** instead would
> help. That's what I did for panfrost. Though I've not looked at were
> you actually need the v3d_bo.
Agreed that would probably be a goodcleanup, but I'm hoping I can land
the compute shaders first. I've been doing a lot of rebasing of that
series and I want to just get it done.
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8] drm: Add library for shmem backed GEM objects
Rob Herring writes: > On Wed, Mar 13, 2019 at 3:56 PM Eric Anholt wrote: >> >> Rob Herring writes: >> >> > From: Noralf Trønnes >> > >> > This adds a library for shmem backed GEM objects. >> >> I read through the whole thing, and the only bit I didn't like >> (drm_gem_shmem_create_with_handle returns an unrefcounted object >> pointer) was a copy-and-paste from CMA that we should fix in both >> places, and has no downside in the current usage since the pointer value >> is unused. Just one question left: >> >> > v7: >> > - Use write-combine for mmap instead. This is the more common >> > case. (robher) >> >> I don't actually see this in the code. Wasn't there supposed to be a: >> >>vma->vm_page_prot = >> pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); > > That's the default if you trace drm_gem_mmap() -> drm_gem_mmap_obj(). > My wording here should have been more clear. Ah, there it is! Added review to the helpers, and I've pushed both patches now. 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/8] drm/bridge: dw-hdmi: Add SCDC and TMDS Scrambling support
On Mon, Mar 11, 2019 at 3:53 AM Neil Armstrong wrote: > > On 08/03/2019 15:54, Rob Herring wrote: > > On Fri, Mar 8, 2019 at 2:05 AM Neil Armstrong > > wrote: > >> > >> Hi Rob, > >> > >> On 08/03/2019 00:13, Rob Herring wrote: > >>> On Fri, Feb 1, 2019 at 6:08 AM Neil Armstrong > >>> wrote: > > Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS > Scrambling when supported or mandatory. > > This patch also adds an helper to setup the control bit to support > the high TMDS Bit Period/TMDS Clock-Period Ratio as required with > TMDS Clock > 3.4GHz for HDMI2.0 3840x2160@60/50 modes. > > These changes were based on work done by Huicong Xu > and Nickey Yang to support HDMI2.0 modes > on the Rockchip 4.4 BSP kernel at [1] > > [1] https://github.com/rockchip-linux/kernel/tree/release-4.4 > > Cc: Nickey Yang > Cc: Huicong Xu > Signed-off-by: Neil Armstrong > Tested-by: Heiko Stuebner > Reviewed-by: Andrzej Hajda > --- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 85 > ++- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 1 + > include/drm/bridge/dw_hdmi.h | 1 + > 3 files changed, 85 insertions(+), 2 deletions(-) > >>> > >>> This commit in drm-misc-next is breaking booting on the Rock960. I > >>> have FB and fbcon enabled. The boot hangs after this message: > >>> > >>> [3.012334] [drm:rockchip_drm_fbdev_create] FB [1920x1080]-24 > >>> kvaddr=(ptrval) offset=0 size=8294400 > >> > >> Could you give more details on the tree used ? did you bisect to find this > >> commit ? > > > > As I said above, drm-misc-next (from drm-misc tree) is the branch. I > > bisected between it and v5.0. Reverting it fixes booting. > > Thanks, could you give more details on the environment ? Did you test over > the latest linux-next ? Here's a log of the drm parts: https://pastebin.com/tFJ9Gs6h linux-next also hangs. > Can you share the EDID of your monitor ? Maybe not mode related. I tried forcing to 1280x720 and it hangs too. In any case, here's the parsed EDID: 256-byte EDID successfully retrieved from i2c bus 3 Looks like i2c was successful. Have a good day. Checksum Correct Section "Monitor" Identifier "CYS-R101" ModelName "CYS-R101" VendorName "CYX" # Monitor Manufactured week 28 of 2018 # EDID version 1.3 # Digital Display DisplaySize 220 130 Gamma 2.20 Option "DPMS" "true" Horizsync 30-102 VertRefresh 48-75 # Maximum pixel clock is 190MHz #Not giving standard mode: 1920x1080, 60Hz #Not giving standard mode: 1920x1080, 60Hz #Not giving standard mode: 1920x1080, 60Hz #Not giving standard mode: 1440x900, 60Hz #Not giving standard mode: 1400x1050, 60Hz #Not giving standard mode: 1280x1024, 60Hz #Not giving standard mode: 1280x960, 60Hz #Not giving standard mode: 1280x720, 60Hz #Extension block found. Parsing... Modeline "Mode 5" 54.00 2560 2608 2640 2720 1440 1443 1448 1481 +hsync +vsync Modeline "Mode 0" 267.81 2560 2608 2640 2720 1600 1603 1608 1641 +hsync +vsync Modeline "Mode 1" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 2" 74.250 1920 2008 2052 2200 1080 1082 1087 1125 +hsync +vsync interlace Modeline "Mode 3" 74.250 1280 1390 1420 1650 720 725 730 750 +hsync +vsync Modeline "Mode 4" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync Option "PreferredMode" "Mode 5" EndSection > Can you check this patch : Still hangs with it. > > >< > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > index a63e5f0dae56..f33c2ac158c1 100644 > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > @@ -1268,8 +1268,6 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi) > > dw_hdmi_phy_power_off(hdmi); > > - dw_hdmi_set_high_tmds_clock_ratio(hdmi); > - > /* Leave low power consumption mode by asserting SVSRET. */ > if (phy->has_svsret) > dw_hdmi_phy_enable_svsret(hdmi, 1); > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2] drm/atomic-helper: Make atomic_enable/disable crtc callbacks optional
Allow atomic_enable and atomic_disable operations from
drm_crtc_helper_funcs struct optional. With this, the target display
drivers don't need to define a dummy function if they don't need one.
Changes since v2:
* Don't make funcs optional
* Update kerneldoc for atomic_enable/disable
* Replace "if (funcs->atomic_enable)" by "if (funcs->commit)"
* Improve commit message
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/drm_atomic_helper.c | 5 ++---
include/drm/drm_modeset_helper_vtables.h | 4
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 540a77a2ade9..d506e13c2945 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1034,7 +1034,7 @@ disable_outputs(struct drm_device *dev, struct
drm_atomic_state *old_state)
funcs->atomic_disable(crtc, old_crtc_state);
else if (funcs->disable)
funcs->disable(crtc);
- else
+ else if (funcs->dpms)
funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
if (!(dev->irq_enabled && dev->num_crtcs))
@@ -1277,10 +1277,9 @@ void drm_atomic_helper_commit_modeset_enables(struct
drm_device *dev,
if (new_crtc_state->enable) {
DRM_DEBUG_ATOMIC("enabling [CRTC:%d:%s]\n",
crtc->base.id, crtc->name);
-
if (funcs->atomic_enable)
funcs->atomic_enable(crtc, old_crtc_state);
- else
+ else if (funcs->commit)
funcs->commit(crtc);
}
}
diff --git a/include/drm/drm_modeset_helper_vtables.h
b/include/drm/drm_modeset_helper_vtables.h
index cfb7be40bed7..ce4de6b1e444 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -418,6 +418,8 @@ struct drm_crtc_helper_funcs {
* Drivers can use the @old_crtc_state input parameter if the operations
* needed to enable the CRTC don't depend solely on the new state but
* also on the transition between the old state and the new state.
+*
+* This function is optional.
*/
void (*atomic_enable)(struct drm_crtc *crtc,
struct drm_crtc_state *old_crtc_state);
@@ -441,6 +443,8 @@ struct drm_crtc_helper_funcs {
* parameter @old_crtc_state which could be used to access the old
* state. Atomic drivers should consider to use this one instead
* of @disable.
+*
+* This function is optional.
*/
void (*atomic_disable)(struct drm_crtc *crtc,
struct drm_crtc_state *old_crtc_state);
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/dp: Set the connector's TILE property even for DP SST connectors
Pushed to drm-misc, thanks for the patch and the review!
Regards
Manasi
On Wed, Mar 13, 2019 at 02:48:36PM -0400, Alex Deucher wrote:
> On Tue, Mar 12, 2019 at 10:15 PM Manasi Navare
> wrote:
> >
> > Current driver sets the tile property only for DP MST connectors.
> > However there are some tiled displays where each SST connector
> > carries a single tile. So we need to attach this property object
> > for every connector and set it for every connector (DP SST and MST).
> > Plus since the tile information is obtained as a result of EDID
> > parsing, the best place to update tile property is where we update
> > edid property.
> > Also now we dont need to explicitly set this now for MST connectors.
> >
> > This has been tested with xrandr --props and modetest and verified
> > that TILE property is exposed correctly.
> >
> > Cc: Dave Airlie
> > Cc: Jani Nikula
> > Cc: Daniel Vetter
> > Cc: Ville Syrjälä
> > Signed-off-by: Manasi Navare
>
> Reviewed-by: Alex Deucher
>
> > ---
> > drivers/gpu/drm/drm_connector.c | 13 -
> > drivers/gpu/drm/drm_dp_mst_topology.c | 1 -
> > 2 files changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > index 07d65a16c623..2355124849db 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -245,6 +245,7 @@ int drm_connector_init(struct drm_device *dev,
> > INIT_LIST_HEAD(&connector->modes);
> > mutex_init(&connector->mutex);
> > connector->edid_blob_ptr = NULL;
> > + connector->tile_blob_ptr = NULL;
> > connector->status = connector_status_unknown;
> > connector->display_info.panel_orientation =
> > DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
> > @@ -272,6 +273,9 @@ int drm_connector_init(struct drm_device *dev,
> > drm_object_attach_property(&connector->base,
> >config->non_desktop_property,
> >0);
> > + drm_object_attach_property(&connector->base,
> > + config->tile_property,
> > + 0);
> >
> > if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
> > drm_object_attach_property(&connector->base,
> > config->prop_crtc_id, 0);
> > @@ -1712,6 +1716,8 @@ EXPORT_SYMBOL(drm_connector_set_path_property);
> > * This looks up the tile information for a connector, and creates a
> > * property for userspace to parse if it exists. The property is of
> > * the form of 8 integers using ':' as a separator.
> > + * This is used for dual port tiled displays with DisplayPort SST
> > + * or DisplayPort MST connectors.
> > *
> > * Returns:
> > * Zero on success, errno on failure.
> > @@ -1755,6 +1761,9 @@ EXPORT_SYMBOL(drm_connector_set_tile_property);
> > *
> > * This function creates a new blob modeset object and assigns its id to
> > the
> > * connector's edid property.
> > + * Since we also parse tile information from EDID's displayID block, we
> > also
> > + * set the connector's tile property here. See
> > drm_connector_set_tile_property()
> > + * for more details.
> > *
> > * Returns:
> > * Zero on success, negative errno on failure.
> > @@ -1796,7 +1805,9 @@ int drm_connector_update_edid_property(struct
> > drm_connector *connector,
> >edid,
> >&connector->base,
> >
> > dev->mode_config.edid_property);
> > - return ret;
> > + if (ret)
> > + return ret;
> > + return drm_connector_set_tile_property(connector);
> > }
> > EXPORT_SYMBOL(drm_connector_update_edid_property);
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index dc7ac0c60547..c630ed157994 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -3022,7 +3022,6 @@ struct edid *drm_dp_mst_get_edid(struct drm_connector
> > *connector, struct drm_dp_
> > edid = drm_edid_duplicate(port->cached_edid);
> > else {
> > edid = drm_get_edid(connector, &port->aux.ddc);
> > - drm_connector_set_tile_property(connector);
> > }
> > port->has_audio = drm_detect_monitor_audio(edid);
> > drm_dp_mst_topology_put_port(port);
> > --
> > 2.19.1
> >
> > ___
> > 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
h
Re: [Patch 1/1] drm/atomic: integrate private objects with suspend/resume helpers
Hi Benoit,
Thank you for the patch.
On Thu, Mar 14, 2019 at 08:44:45AM -0500, Benoit Parrot wrote:
> During a suspend cycle the atomic state is saved to be used during the
> restore cycle.
>
> However the current state duplication logic does not duplicate private
> objects. This leads to state inconsistencies at resume time.
>
> With private objects modeset lock now integrated, we can make sure that
> private object state are properly saved and restored.
>
> Signed-off-by: Benoit Parrot
This looks good to me. I was actually wondering if private object state
was properly handled by the suspend/resume helpers no later than
yesterday. Seems you read my mind :-)
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 540a77a2ade9..b108021cc092 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3189,6 +3189,7 @@ drm_atomic_helper_duplicate_state(struct drm_device
> *dev,
> struct drm_connector_list_iter conn_iter;
> struct drm_plane *plane;
> struct drm_crtc *crtc;
> + struct drm_private_obj *privobj;
> int err = 0;
>
> state = drm_atomic_state_alloc(dev);
> @@ -3218,6 +3219,16 @@ drm_atomic_helper_duplicate_state(struct drm_device
> *dev,
> }
> }
>
> + drm_for_each_privobj(privobj, dev) {
> + struct drm_private_state *priv_state;
> +
> + priv_state = drm_atomic_get_private_obj_state(state, privobj);
> + if (IS_ERR(priv_state)) {
> + err = PTR_ERR(priv_state);
> + goto free;
> + }
> + }
> +
> drm_connector_list_iter_begin(dev, &conn_iter);
> drm_for_each_connector_iter(conn, &conn_iter) {
> struct drm_connector_state *conn_state;
> @@ -3325,12 +3336,17 @@ int drm_atomic_helper_commit_duplicated_state(struct
> drm_atomic_state *state,
> struct drm_connector_state *new_conn_state;
> struct drm_crtc *crtc;
> struct drm_crtc_state *new_crtc_state;
> + struct drm_private_obj *privobj;
> + struct drm_private_state *new_priv_state;
>
> state->acquire_ctx = ctx;
>
> for_each_new_plane_in_state(state, plane, new_plane_state, i)
> state->planes[i].old_state = plane->state;
>
> + for_each_new_private_obj_in_state(state, privobj, new_priv_state, i)
> + state->private_objs[i].old_state = privobj->state;
> +
> for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> state->crtcs[i].old_state = crtc->state;
>
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/v3d: Use the new shmem helpers to reduce driver boilerplate.
On Thu, Mar 14, 2019 at 11:34 AM Eric Anholt wrote:
>
> The new shmem helpers from Noralf and Rob abstract out a bunch of our
> BO creation and mapping code.
>
> v2: Use the new sgt getter, and flag pages as dirty before freeing.
>
> Signed-off-by: Eric Anholt
> ---
> drivers/gpu/drm/v3d/Kconfig | 1 +
> drivers/gpu/drm/v3d/v3d_bo.c | 317 ++
> drivers/gpu/drm/v3d/v3d_drv.c | 27 +--
> drivers/gpu/drm/v3d/v3d_drv.h | 14 +-
> drivers/gpu/drm/v3d/v3d_gem.c | 12 +-
> drivers/gpu/drm/v3d/v3d_irq.c | 8 +-
> drivers/gpu/drm/v3d/v3d_mmu.c | 11 +-
> 7 files changed, 120 insertions(+), 270 deletions(-)
> diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
> index 945ed016..b84d89c7b3fb 100644
> --- a/drivers/gpu/drm/v3d/v3d_gem.c
> +++ b/drivers/gpu/drm/v3d/v3d_gem.c
> @@ -201,7 +201,8 @@ v3d_attach_object_fences(struct v3d_bo **bos, int
> bo_count,
>
> for (i = 0; i < bo_count; i++) {
> /* XXX: Use shared fences for read-only objects. */
> - reservation_object_add_excl_fence(bos[i]->base.resv, fence);
> + reservation_object_add_excl_fence(bos[i]->base.base.resv,
> + fence);
All these 'bos[i]->base.base' occurrences are not the prettiest.
Changing your bos array to a struct drm_gem_object ** instead would
help. That's what I did for panfrost. Though I've not looked at were
you actually need the v3d_bo.
Either way,
Reviewed-by: Rob Herring
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/3] drm/panel: Support Rocktech jh057n00900 DSI panel
Hi, On Mon, Mar 04, 2019 at 07:05:52PM +0100, Sam Ravnborg wrote: > Hi Thierry. > > > Changes from v2 > > * As per review comments from Sam Ravnborg > > * Lowercase sentinel > > * Drop '_panel' postfix > > * DRM_DEV_ logging instead of plain DRM_ > > * Add Sam's Reviewed-by: > > * Add "panel-rocktech-" to the driver name following > > the pattern from other drm panel drivers. > > With the changes done in v2 the patch series is IMO > ready to be applied. Thanks a lot for the review. Is there anything I can do to get it applied? Cheers, -- Guido ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/sun4i: Implement gamma correction
On Thu, Mar 14, 2019 at 8:42 AM Maxime Ripard wrote:
>
> Hi Vasily,
>
> On Wed, Mar 13, 2019 at 07:58:38PM -0700, Vasily Khoruzhick wrote:
> > Add support for gamma corretion to sun4i TCON driver. Its LUT has 256
> > entries and can be updated only when gamma correction is disabled.
> >
> > Signed-off-by: Vasily Khoruzhick
>
> It's not really clear to me what you expect a comment on?
I'm not sure that I put gamma correction into right place - gamma lut
seems to be a property of CRTC, but registers are in TCON module.
Also I'm not sure if gamma correction is supported across all
Allwinner SoCs - if it doesn't, how do we handle this?
>
> Maxime
>
> > ---
> > drivers/gpu/drm/sun4i/sun4i_crtc.c | 15 ++
> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 33 ++
> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 12 ++-
> > 3 files changed, 59 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c
> > b/drivers/gpu/drm/sun4i/sun4i_crtc.c
> > index 3eedf335a935..719259d09632 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_crtc.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c
> > @@ -101,6 +101,20 @@ static void sun4i_crtc_atomic_flush(struct drm_crtc
> > *crtc,
> > drm_crtc_send_vblank_event(crtc, event);
> > spin_unlock_irq(&crtc->dev->event_lock);
> > }
> > +
> > + if (crtc->state->color_mgmt_changed) {
> > + if (crtc->state->gamma_lut) {
> > + /* LUT can be only updated when gamma correction is
> > + * disabled
> > + */
> > + sun4i_tcon_enable_gamma(scrtc->tcon, false);
> > + sun4i_tcon_load_gamma_lut(scrtc->tcon,
> > +
> > crtc->state->gamma_lut->data);
> > + sun4i_tcon_enable_gamma(scrtc->tcon, true);
> > + } else
> > + sun4i_tcon_enable_gamma(scrtc->tcon, false);
> > + }
> > +
> > }
> >
> > static void sun4i_crtc_atomic_disable(struct drm_crtc *crtc,
> > @@ -184,6 +198,7 @@ static const struct drm_crtc_funcs sun4i_crtc_funcs = {
> > .set_config = drm_atomic_helper_set_config,
> > .enable_vblank = sun4i_crtc_enable_vblank,
> > .disable_vblank = sun4i_crtc_disable_vblank,
> > + .gamma_set = drm_atomic_helper_legacy_gamma_set,
> > };
> >
> > struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm,
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > index cf45d0f940f9..3f5f9d4f54a6 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > @@ -215,6 +215,34 @@ void sun4i_tcon_enable_vblank(struct sun4i_tcon *tcon,
> > bool enable)
> > }
> > EXPORT_SYMBOL(sun4i_tcon_enable_vblank);
> >
> > +void sun4i_tcon_load_gamma_lut(struct sun4i_tcon *tcon,
> > +struct drm_color_lut *lut)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < SUN4I_TCON_GAMMA_LUT_SIZE; i++) {
> > + u32 r, g, b;
> > +
> > + r = drm_color_lut_extract(lut[i].red, 8);
> > + g = drm_color_lut_extract(lut[i].green, 8);
> > + b = drm_color_lut_extract(lut[i].blue, 8);
> > +
> > + regmap_write(tcon->regs, SUN4I_TCON_GAMMA_TABLE_REG + 4 * i,
> > + SUN4I_TCON_GAMMA_TABLE_R(r) |
> > + SUN4I_TCON_GAMMA_TABLE_G(g) |
> > + SUN4I_TCON_GAMMA_TABLE_B(b));
> > + }
> > +}
> > +EXPORT_SYMBOL(sun4i_tcon_load_gamma_lut);
> > +
> > +void sun4i_tcon_enable_gamma(struct sun4i_tcon *tcon, bool enable)
> > +{
> > + regmap_update_bits(tcon->regs, SUN4I_TCON_GCTL_REG,
> > +SUN4I_TCON_GCTL_GAMMA_ENABLE,
> > +enable ? SUN4I_TCON_GCTL_GAMMA_ENABLE : 0);
> > +}
> > +EXPORT_SYMBOL(sun4i_tcon_enable_gamma);
> > +
> > /*
> > * This function is a helper for TCON output muxing. The TCON output
> > * muxing control register in earlier SoCs (without the TCON TOP block)
> > @@ -1261,6 +1289,11 @@ static int sun4i_tcon_bind(struct device *dev,
> > struct device *master,
> >
> > list_add_tail(&tcon->list, &drv->tcon_list);
> >
> > + drm_mode_crtc_set_gamma_size(&tcon->crtc->crtc,
> > + SUN4I_TCON_GAMMA_LUT_SIZE);
> > + drm_crtc_enable_color_mgmt(&tcon->crtc->crtc, 0, false,
> > +tcon->crtc->crtc.gamma_size);
> > +
> > return 0;
> >
> > err_free_dotclock:
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> > b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> > index 84cfb1952ff7..68a29e49e426 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> > @@ -22,6 +22,7 @@
> >
> > #define SUN4I_TCON_GCTL_REG 0x0
> > #define SUN4I_TCON_GCTL_TCON_ENABLE
Re: [PATCH v2 1/5] drm/rockchip: fix fb references in async update
On 3/14/19 6:15 AM, Michel Dänzer wrote:
> On 2019-03-13 7:08 p.m., Helen Koike wrote:
>> On 3/13/19 6:58 AM, Michel Dänzer wrote:
>>> On 2019-03-13 4:42 a.m., Tomasz Figa wrote:
On Wed, Mar 13, 2019 at 12:52 AM Boris Brezillon
wrote:
> On Tue, 12 Mar 2019 12:34:45 -0300
> Helen Koike wrote:
>> On 3/12/19 3:34 AM, Boris Brezillon wrote:
>>> On Mon, 11 Mar 2019 23:21:59 -0300
>>> Helen Koike wrote:
>>>
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -912,30 +912,31 @@ static void vop_plane_atomic_async_update(struct
drm_plane *plane,
struct drm_plane_state *new_state)
{
struct vop *vop = to_vop(plane->state->crtc);
- struct drm_plane_state *plane_state;
+ struct drm_framebuffer *old_fb = plane->state->fb;
- plane_state = plane->funcs->atomic_duplicate_state(plane);
- plane_state->crtc_x = new_state->crtc_x;
- plane_state->crtc_y = new_state->crtc_y;
- plane_state->crtc_h = new_state->crtc_h;
- plane_state->crtc_w = new_state->crtc_w;
- plane_state->src_x = new_state->src_x;
- plane_state->src_y = new_state->src_y;
- plane_state->src_h = new_state->src_h;
- plane_state->src_w = new_state->src_w;
-
- if (plane_state->fb != new_state->fb)
- drm_atomic_set_fb_for_plane(plane_state, new_state->fb);
-
- swap(plane_state, plane->state);
-
- if (plane->state->fb && plane->state->fb != new_state->fb) {
+ /*
+ * A scanout can still be occurring, so we can't drop the reference
to
+ * the old framebuffer. To solve this we get a reference to old_fb
and
+ * set a worker to release it later.
>>>
>>> Hm, doesn't look like an async update to me if we have to wait for the
>>> next VBLANK to happen to get the new content on the screen. Maybe we
>>> should reject async updates when old_fb != new_fb in the rk
>>> ->async_check() hook.
>>
>> Unless I am misunderstanding this, we don't wait here, we just grab a
>> reference to the fb in case it is being still used by the hw, so it
>> doesn't get released prematurely.
>
> I was just reacting to the comment that says the new FB should stay
> around until the next VBLANK event happens. If the FB must stay around
> that probably means the HW is still using, which made me wonder if this
> HW actually supports async update (where async means "update now and
> don't care about about tearing"). Or maybe it takes some time to switch
> to the new FB and waiting for the next VBLANK to release the old FB was
> an easy solution to not wait for the flip to actually happen in
> ->async_update() (which is kind of a combination of async+non-blocking).
The hardware switches framebuffers on vblank, so whatever framebuffer
is currently being scanned out from needs to stay there until the
hardware switches to the new one in shadow registers. If that doesn't
happen, you get IOMMU faults and the display controller stops working
since we don't have any fault handling currently, just printing a
message.
>>>
>>> Sounds like your hardware doesn't actually support async flips. It's
>>> probably better for the driver not to pretend otherwise.
>>
>> I think wee need to clarify the meaning of the async_update callback
>> (and we should clarify it in the docs).
>>
>> The way I understand what the async_update callback should do is: don't
>> block (i.e. don't wait for the next vblank),
>
> Note that those are two separate things. "Async flips" are about "don't
> wait for vblank", not about "don't block".
>
>
>> and update the hw state at some point with the latest state from the
>> last call to async_update.
>>
>> Which means that: any driver can implement the async_update callback,
>> independently if it supports changing its state right away or not.
>> If hw supports, async_update can change the hw state right away, if not,
>> then changes will be applied in the next vblank (it can even amend the
>> pending commit if there is one).
>> With this, we can remove all the legacy cursor code to use the
>> async_update callback, since async_update can be called 100 times before
>> the next vblank, and the latest state will be set to the hw without
>> waiting 100 vblanks.
>>
>> Please, let me know if this is your understanding as well. If not, then
>> we need to remodel things.
>
> While this may make sense for cursor updates, I don't think it does for
> async flips. If the flip only actually takes effect during the next
> vblank, it doesn't really fit the definition and userspace expectation
> of an async flip. It's better to clearly communicate to userspace th
Re: [RFC dma-buf 0/3] Improve the dma-buf tracking
Hello Chenbo,Thank you for your RFC series.
On Wed, 27 Feb 2019 at 09:24, Chenbo Feng wrote:
>
> Currently, all dma-bufs share the same anonymous inode. While we can count
> how many dma-buf fds or mappings a process has, we can't get the size of
> the backing buffers or tell if two entries point to the same dma-buf. And
> in debugfs, we can get a per-buffer breakdown of size and reference count,
> but can't tell which processes are actually holding the references to each
> buffer.
>
> To resolve the issue above and provide better method for userspace to track
> the dma-buf usage across different processes, the following changes are
> proposed in dma-buf kernel side. First of all, replace the singleton inode
> inside the dma-buf subsystem with a mini-filesystem, and assign each
> dma-buf a unique inode out of this filesystem. With this change, calling
> stat(2) on each entry gives the caller a unique ID (st_ino), the buffer's
> size (st_size), and even the number of pages assigned to each dma-buffer.
> Secoundly, add the inode information to /sys/kernel/debug/dma_buf/bufinfo
> so in the case where a buffer is mmap()ed into a process’s address space
> but all remaining fds have been closed, we can still get the dma-buf
> information and try to accociate it with the process by searching the
> proc/pid/maps and looking for the corresponding inode number exposed in
> dma-buf debug fs. Thirdly, created an ioctl to assign names to dma-bufs
> which lets userspace assign short names (e.g., "CAMERA") to buffers. This
> information can be extremely helpful for tracking and accounting shared
> buffers based on their usage and original purpose. Last but not least, add
> dma-buf information to /proc/pid/fdinfo by adding a show_fdinfo() handler
> to dma_buf_file_operations. The handler will print the file_count and name
> of each buffer.
In general, I think I like the idea as it contributes to a much more
relevant usage analysis of dma-buf backed buffers.
I will get to doing a more detailed review soon, but immediately, we
might want to think a bit about the get/set_name IOCTLS - do we need
to think of disallowing multiple renaming of buffers once they start
getting used? It could otherwise make the whole metrics a lot
confused?
>
> Greg Hackmann (3):
> dma-buf: give each buffer a full-fledged inode
> dma-buf: add DMA_BUF_{GET,SET}_NAME ioctls
> dma-buf: add show_fdinfo handler
>
> drivers/dma-buf/dma-buf.c| 121 ---
> include/linux/dma-buf.h | 5 +-
> include/uapi/linux/dma-buf.h | 4 ++
> include/uapi/linux/magic.h | 1 +
> 4 files changed, 122 insertions(+), 9 deletions(-)
>
> --
> 2.21.0.rc2.261.ga7da99ff1b-goog
>
Best,
Sumit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH v1 00/18] add drm support for MT8183
On 14/03/2019 13:05, yongqiang@mediatek.com wrote: > From: Yongqiang Niu > > This series are based on 4.20-rc1 and provide 18 patches to > support mediatek SOC MT8183 > Resend first version > I think you send the very same series several times yesterday. Please check your config and make sure that you don't send a series more then once. If for any reason you have to resend the series then please specify in the cover letter why you resend it. Reviewing series can take a while, be patient. If nobody reacts to your series you can send a reminder email (best if you just hit reply-all on the cover letter) asking kindly for review. Sending out the same series on a daily or hourly basis will most probably lead to confusion, as people don't know which version is the "good" one. In the end it has the contrary affect from what you want to achieve (getting someone to review your series). Regards, Matthias > Yongqiang Niu (18): > drm/mediatek: update dt-bindings for mt8183 > drm/mediatek: add mutex mod and sof into ddp private data > drm/mediatek: redefine mtk_ddp_sout_sel > drm/mediatek: move rdma sout from mtk_ddp_mout_en into > mtk_ddp_sout_sel > drm/mediatek: add ddp component CCORR > drm/mediatek: add mmsys private data for ddp path config > drm/mediatek: add commponent OVL0_2L > drm/mediatek: add component OVL1_2L > drm/mediatek: add component DITHER > drm/mediatek: add gmc_bits for ovl private data > drm/medaitek: add layer_nr for ovl private data > drm/mediatek: add function to connect module with it's previous one > drm/mediatek: add ddp write register common api > drm/mediatek: add connect function for ovl > drm/mediatek: add RDMA1 fifo size into RDMA private data > drm/mediatek: add function mtk_ddp_comp_get_type > drm/mediatek: add ovl0/ovl0_2l usecase > drm/mediatek: add support for mediatek SOC MT8183 > > .../bindings/display/mediatek/mediatek,disp.txt| 11 +- > drivers/gpu/drm/mediatek/mtk_disp_ovl.c| 64 ++- > drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 23 +- > drivers/gpu/drm/mediatek/mtk_drm_crtc.c| 42 +- > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 458 > - > drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 11 + > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c| 100 + > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h| 24 ++ > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 55 +++ > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 4 + > 10 files changed, 688 insertions(+), 104 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8] drm: Add library for shmem backed GEM objects
On Wed, Mar 13, 2019 at 3:56 PM Eric Anholt wrote: > > Rob Herring writes: > > > From: Noralf Trønnes > > > > This adds a library for shmem backed GEM objects. > > I read through the whole thing, and the only bit I didn't like > (drm_gem_shmem_create_with_handle returns an unrefcounted object > pointer) was a copy-and-paste from CMA that we should fix in both > places, and has no downside in the current usage since the pointer value > is unused. Just one question left: > > > v7: > > - Use write-combine for mmap instead. This is the more common > > case. (robher) > > I don't actually see this in the code. Wasn't there supposed to be a: > >vma->vm_page_prot = > pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); That's the default if you trace drm_gem_mmap() -> drm_gem_mmap_obj(). My wording here should have been more clear. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/v3d: Use the new shmem helpers to reduce driver boilerplate.
Eric Anholt writes: > The new shmem helpers from Noralf and Rob abstract out a bunch of our > BO creation and mapping code. > > v2: Use the new sgt getter, and flag pages as dirty before freeing. > > Signed-off-by: Eric Anholt > @@ -185,83 +33,120 @@ void v3d_free_object(struct drm_gem_object *obj) > struct v3d_dev *v3d = to_v3d_dev(obj->dev); > struct v3d_bo *bo = to_v3d_bo(obj); > > + v3d_mmu_remove_ptes(bo); > + > mutex_lock(&v3d->bo_lock); > v3d->bo_stats.num_allocated--; > v3d->bo_stats.pages_allocated -= obj->size >> PAGE_SHIFT; > mutex_unlock(&v3d->bo_lock); > > - v3d_bo_put_pages(bo); > - > - if (obj->import_attach) > - drm_prime_gem_destroy(obj, bo->sgt); > - > - v3d_mmu_remove_ptes(bo); > spin_lock(&v3d->mm_lock); > drm_mm_remove_node(&bo->node); > spin_unlock(&v3d->mm_lock); > > - mutex_destroy(&bo->lock); > + drm_gem_shmem_put_pages(&bo->base); This put_pages() should be dropped -- it generated a WARN because the shared helpers already do a put_pages after freeing the sgt. The CTS had passed, so I missed it until after I'd sent the patch. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 6/6] drm/bridge: sii902x: Implement HDMI audio support
Hello Jyri, STM32MP157C-DK2 discovery boards use a SiI9022A HDMI transmitter. see: https://www.st.com/en/evaluation-tools/stm32mp157c-dk2.html On this board audio samples are sent to HDMI transmitter through the i2s link. This i2s link does not provide a master clock. internal PLL is used instead. The support of audio on this board is already available through the following patch: https://github.com/STMicroelectronics/linux/blob/v4.19-stm32mp/drivers/gpu/drm/bridge/sii902x.c I tried your patch on this STM32MP157C-DK2 board. I could get audio, after reworking the patch. However, I had to make the following changes: - make master clock configuration optional - add of graph support for audio Could you please update current patch to take these restrictions into account ? BRs Olivier On 3/14/19 12:27 PM, Jyri Sarha wrote: > Implement HDMI audio support by using ASoC HDMI codec. The commit > implements the necessary callbacks and configuration for the HDMI > codec and registers a virtual platform device for the codec to attach. > > Signed-off-by: Jyri Sarha > --- > drivers/gpu/drm/bridge/sii902x.c | 460 ++- > 1 file changed, 453 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/sii902x.c > b/drivers/gpu/drm/bridge/sii902x.c > index 1d99108440c1..39a0d25009f2 100644 > --- a/drivers/gpu/drm/bridge/sii902x.c > +++ b/drivers/gpu/drm/bridge/sii902x.c > @@ -27,12 +27,15 @@ > #include > #include > #include > +#include > > #include > #include > #include > #include > > +#include > + > #define SII902X_TPI_VIDEO_DATA 0x0 > > #define SII902X_TPI_PIXEL_REPETITION0x8 > @@ -74,6 +77,77 @@ > #define SII902X_AVI_POWER_STATE_MSK GENMASK(1, 0) > #define SII902X_AVI_POWER_STATE_D(l)((l) & > SII902X_AVI_POWER_STATE_MSK) > > +/* Audio */ > +#define SII902X_TPI_I2S_ENABLE_MAPPING_REG 0x1f > +#define SII902X_TPI_I2S_CONFIG_FIFO0 (0 << 0) > +#define SII902X_TPI_I2S_CONFIG_FIFO1 (1 << 0) > +#define SII902X_TPI_I2S_CONFIG_FIFO2 (2 << 0) > +#define SII902X_TPI_I2S_CONFIG_FIFO3 (3 << 0) > +#define SII902X_TPI_I2S_LEFT_RIGHT_SWAP (1 << 2) > +#define SII902X_TPI_I2S_AUTO_DOWNSAMPLE (1 << 3) > +#define SII902X_TPI_I2S_SELECT_SD0 (0 << 4) > +#define SII902X_TPI_I2S_SELECT_SD1 (1 << 4) > +#define SII902X_TPI_I2S_SELECT_SD2 (2 << 4) > +#define SII902X_TPI_I2S_SELECT_SD3 (3 << 4) > +#define SII902X_TPI_I2S_FIFO_ENABLE (1 << 7) > + > +#define SII902X_TPI_I2S_INPUT_CONFIG_REG 0x20 > +#define SII902X_TPI_I2S_FIRST_BIT_SHIFT_YES (0 << 0) > +#define SII902X_TPI_I2S_FIRST_BIT_SHIFT_NO (1 << 0) > +#define SII902X_TPI_I2S_SD_DIRECTION_MSB_FIRST (0 << 1) > +#define SII902X_TPI_I2S_SD_DIRECTION_LSB_FIRST (1 << 1) > +#define SII902X_TPI_I2S_SD_JUSTIFY_LEFT (0 << 2) > +#define SII902X_TPI_I2S_SD_JUSTIFY_RIGHT (1 << 2) > +#define SII902X_TPI_I2S_WS_POLARITY_LOW (0 << 3) > +#define SII902X_TPI_I2S_WS_POLARITY_HIGH (1 << 3) > +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_128 (0 << 4) > +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_256 (1 << 4) > +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_384 (2 << 4) > +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_512 (3 << 4) > +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_768 (4 << 4) > +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_1024 (5 << 4) > +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_1152 (6 << 4) > +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_192 (7 << 4) > +#define SII902X_TPI_I2S_SCK_EDGE_FALLING (0 << 7) > +#define SII902X_TPI_I2S_SCK_EDGE_RISING (1 << 7) > + > +#define SII902X_TPI_I2S_STRM_HDR_BASE0x21 > +#define SII902X_TPI_I2S_STRM_HDR_SIZE5 > + > +#define SII902X_TPI_AUDIO_CONFIG_BYTE2_REG 0x26 > +#define SII902X_TPI_AUDIO_CODING_STREAM_HEADER (0 << 0) > +#define SII902X_TPI_AUDIO_CODING_PCM (1 << 0) > +#define SII902X_TPI_AUDIO_CODING_AC3 (2 << 0) > +#define SII902X_TPI_AUDIO_CODING_MPEG1 (3 << 0) > +#define SII902X_TPI_AUDIO_CODING_MP3 (4 << 0) > +#define SII902X_TPI_AUDIO_CODING_MPEG2 (5 << 0) > +#define SII902X_TPI_AUDIO_CODING_AAC (6 << 0) > +#define SII902X_TPI_AUDIO_CODING_DTS (7 << 0) > +#define SII902X_TPI_AUDIO_CODING_ATRAC (8 << 0) > +#define SII902X_TPI_AUDIO_MUTE_DISABLE (0 << 4) > +#define SII902X_TPI_AUDIO_MUTE_ENABLE(1 << 4) > +#define SII902X_TPI_AUDIO_LAYOUT_2_CHANNELS (0 << 5) > +#define SII902X_TPI_AUDIO_LAYOUT_8_CHA
[PATCH] drm/v3d: Use the new shmem helpers to reduce driver boilerplate.
The new shmem helpers from Noralf and Rob abstract out a bunch of our
BO creation and mapping code.
v2: Use the new sgt getter, and flag pages as dirty before freeing.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/v3d/Kconfig | 1 +
drivers/gpu/drm/v3d/v3d_bo.c | 317 ++
drivers/gpu/drm/v3d/v3d_drv.c | 27 +--
drivers/gpu/drm/v3d/v3d_drv.h | 14 +-
drivers/gpu/drm/v3d/v3d_gem.c | 12 +-
drivers/gpu/drm/v3d/v3d_irq.c | 8 +-
drivers/gpu/drm/v3d/v3d_mmu.c | 11 +-
7 files changed, 120 insertions(+), 270 deletions(-)
diff --git a/drivers/gpu/drm/v3d/Kconfig b/drivers/gpu/drm/v3d/Kconfig
index 1552bf552c94..75a74c45f109 100644
--- a/drivers/gpu/drm/v3d/Kconfig
+++ b/drivers/gpu/drm/v3d/Kconfig
@@ -5,6 +5,7 @@ config DRM_V3D
depends on COMMON_CLK
depends on MMU
select DRM_SCHED
+ select DRM_GEM_SHMEM_HELPER
help
Choose this option if you have a system that has a Broadcom
V3D 3.x or newer GPU, such as BCM7268.
diff --git a/drivers/gpu/drm/v3d/v3d_bo.c b/drivers/gpu/drm/v3d/v3d_bo.c
index dff38bf36c50..82f08d861389 100644
--- a/drivers/gpu/drm/v3d/v3d_bo.c
+++ b/drivers/gpu/drm/v3d/v3d_bo.c
@@ -25,158 +25,6 @@
#include "v3d_drv.h"
#include "uapi/drm/v3d_drm.h"
-/* Pins the shmem pages, fills in the .pages and .sgt fields of the BO, and
maps
- * it for DMA.
- */
-static int
-v3d_bo_get_pages(struct v3d_bo *bo)
-{
- struct drm_gem_object *obj = &bo->base;
- struct drm_device *dev = obj->dev;
- int npages = obj->size >> PAGE_SHIFT;
- int ret = 0;
-
- mutex_lock(&bo->lock);
- if (bo->pages_refcount++ != 0)
- goto unlock;
-
- if (!obj->import_attach) {
- bo->pages = drm_gem_get_pages(obj);
- if (IS_ERR(bo->pages)) {
- ret = PTR_ERR(bo->pages);
- goto unlock;
- }
-
- bo->sgt = drm_prime_pages_to_sg(bo->pages, npages);
- if (IS_ERR(bo->sgt)) {
- ret = PTR_ERR(bo->sgt);
- goto put_pages;
- }
-
- /* Map the pages for use by the GPU. */
- dma_map_sg(dev->dev, bo->sgt->sgl,
- bo->sgt->nents, DMA_BIDIRECTIONAL);
- } else {
- bo->pages = kcalloc(npages, sizeof(*bo->pages), GFP_KERNEL);
- if (!bo->pages)
- goto put_pages;
-
- drm_prime_sg_to_page_addr_arrays(bo->sgt, bo->pages,
-NULL, npages);
-
- /* Note that dma-bufs come in mapped. */
- }
-
- mutex_unlock(&bo->lock);
-
- return 0;
-
-put_pages:
- drm_gem_put_pages(obj, bo->pages, true, true);
- bo->pages = NULL;
-unlock:
- bo->pages_refcount--;
- mutex_unlock(&bo->lock);
- return ret;
-}
-
-static void
-v3d_bo_put_pages(struct v3d_bo *bo)
-{
- struct drm_gem_object *obj = &bo->base;
-
- mutex_lock(&bo->lock);
- if (--bo->pages_refcount == 0) {
- if (!obj->import_attach) {
- dma_unmap_sg(obj->dev->dev, bo->sgt->sgl,
-bo->sgt->nents, DMA_BIDIRECTIONAL);
- sg_free_table(bo->sgt);
- kfree(bo->sgt);
- drm_gem_put_pages(obj, bo->pages, true, true);
- } else {
- kfree(bo->pages);
- }
- }
- mutex_unlock(&bo->lock);
-}
-
-static struct v3d_bo *v3d_bo_create_struct(struct drm_device *dev,
- size_t unaligned_size)
-{
- struct v3d_dev *v3d = to_v3d_dev(dev);
- struct drm_gem_object *obj;
- struct v3d_bo *bo;
- size_t size = roundup(unaligned_size, PAGE_SIZE);
- int ret;
-
- if (size == 0)
- return ERR_PTR(-EINVAL);
-
- bo = kzalloc(sizeof(*bo), GFP_KERNEL);
- if (!bo)
- return ERR_PTR(-ENOMEM);
- obj = &bo->base;
-
- INIT_LIST_HEAD(&bo->unref_head);
- mutex_init(&bo->lock);
-
- ret = drm_gem_object_init(dev, obj, size);
- if (ret)
- goto free_bo;
-
- spin_lock(&v3d->mm_lock);
- ret = drm_mm_insert_node_generic(&v3d->mm, &bo->node,
-obj->size >> PAGE_SHIFT,
-GMP_GRANULARITY >> PAGE_SHIFT, 0, 0);
- spin_unlock(&v3d->mm_lock);
- if (ret)
- goto free_obj;
-
- return bo;
-
-free_obj:
- drm_gem_object_release(obj);
-free_bo:
- kfree(bo);
- return ERR_PTR(ret);
-}
-
-struct v3d_bo *v3d_bo_create(struct drm_device *dev, struct drm_file
*file_priv,
-size_t unaligned_size)
-{
- struct v3d_dev *v3d = to_v3d_dev(dev);
- struct drm_gem_object *obj;
- struct v3d_bo *bo;
- in
Re: [PATCH 1/4] drm: Add helpers for locking an array of BO reservations.
Rob Herring writes: > On Tue, Mar 12, 2019 at 12:37 PM Eric Anholt wrote: >> >> Rob Herring writes: >> >> > On Fri, Mar 8, 2019 at 10:17 AM Eric Anholt wrote: >> >> >> >> Now that we have the reservation object in the GEM object, it's easy >> >> to provide a helper for this common case. Noticed while reviewing >> >> panfrost and lima drivers. This particular version came out of v3d, >> >> which in turn was a copy from vc4. >> >> >> >> Signed-off-by: Eric Anholt >> >> --- >> >> drivers/gpu/drm/drm_gem.c | 76 +++ >> >> include/drm/drm_gem.h | 4 +++ >> >> 2 files changed, 80 insertions(+) >> > >> > Sweet! I was about to go write this same patch. You are changing the >> > license from GPL to MIT copying the v3d version, but I guess you have >> > rights to do that. >> > >> > FWIW, >> > >> > Acked-by: Rob Herring >> >> Was this just for this one patch, or the series? I don't think I can >> merge without a consumer. > > Sure, it can be for patches 1-3. Patch 4 is dependent on me sending > out the shmem helpers again. Thanks. Pushed the first 3 now. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/38] vfs: Convert drm to fs_context
Signed-off-by: David Howells
cc: David Airlie
cc: Daniel Vetter
cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_drv.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 381581b01d48..9eead5a478de 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -413,20 +414,17 @@ static const struct super_operations drm_fs_sops = {
.statfs = simple_statfs,
};
-static struct dentry *drm_fs_mount(struct file_system_type *fs_type, int flags,
- const char *dev_name, void *data)
+static int drm_fs_init_fs_context(struct fs_context *fc)
{
- return mount_pseudo(fs_type,
- "drm:",
- &drm_fs_sops,
- &drm_fs_dops,
- 0x010203ff);
+ return vfs_init_pseudo_fs_context(fc, "drm:",
+ &drm_fs_sops, NULL,
+ &drm_fs_dops, 0x010203ff);
}
static struct file_system_type drm_fs_type = {
.name = "drm",
.owner = THIS_MODULE,
- .mount = drm_fs_mount,
+ .init_fs_context = drm_fs_init_fs_context,
.kill_sb= kill_anon_super,
};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/38] VFS: Convert trivial filesystems and more
Hi Al, Here's a set of patches that: (1) Provides a convenience member in struct fs_context that is OR'd into sb->s_iflags by sget_fc(). (2) Provides a convenience vfs_init_pseudo_fs_context() helper function for doing most of the work in mounting a pseudo filesystem. (3) Converts all the trivial filesystems that have no arguments to fs_context. (4) Converts binderfs (which was trivial before January). (5) Converts ramfs, tmpfs, rootfs and devtmpfs. (6) Kills off mount_pseudo(), mount_pseudo_xattr(), mount_ns(), sget_userns(). The patches can be found here also: https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git on branch: mount-api-viro David --- David Howells (38): vfs: Provide sb->s_iflags settings in fs_context struct vfs: Provide a mount_pseudo-replacement for fs_context vfs: Convert aio to fs_context vfs: Convert anon_inodes to fs_context vfs: Convert bdev to fs_context vfs: Convert nsfs to fs_context vfs: Convert pipe to fs_context vfs: Convert zsmalloc to fs_context vfs: Convert sockfs to fs_context vfs: Convert dax to fs_context vfs: Convert drm to fs_context vfs: Convert ia64 perfmon to fs_context vfs: Convert cxl to fs_context vfs: Convert ocxlflash to fs_context vfs: Convert virtio_balloon to fs_context vfs: Convert btrfs_test to fs_context vfs: Kill off mount_pseudo() and mount_pseudo_xattr() vfs: Use sget_fc() for pseudo-filesystems vfs: Convert binderfs to fs_context vfs: Convert nfsctl to fs_context vfs: Convert rpc_pipefs to fs_context vfs: Kill off mount_ns() vfs: Kill sget_userns() vfs: Convert binfmt_misc to fs_context vfs: Convert configfs to fs_context vfs: Convert efivarfs to fs_context vfs: Convert fusectl to fs_context vfs: Convert qib_fs/ipathfs to fs_context vfs: Convert ibmasmfs to fs_context vfs: Convert oprofilefs to fs_context vfs: Convert gadgetfs to fs_context vfs: Convert xenfs to fs_context vfs: Convert openpromfs to fs_context vfs: Convert apparmorfs to fs_context vfs: Convert securityfs to fs_context vfs: Convert selinuxfs to fs_context vfs: Convert smackfs to fs_context tmpfs, devtmpfs, ramfs, rootfs: Convert to fs_context arch/ia64/kernel/perfmon.c | 14 + drivers/android/binderfs.c | 173 +--- drivers/base/devtmpfs.c| 16 + drivers/dax/super.c| 13 + drivers/gpu/drm/drm_drv.c | 14 + drivers/infiniband/hw/qib/qib_fs.c | 26 ++ drivers/misc/cxl/api.c | 10 - drivers/misc/ibmasm/ibmasmfs.c | 21 +- drivers/oprofile/oprofilefs.c | 20 +- drivers/scsi/cxlflash/ocxl_hw.c| 21 +- drivers/usb/gadget/legacy/inode.c | 21 +- drivers/virtio/virtio_balloon.c| 19 +- drivers/xen/xenfs/super.c | 21 +- fs/aio.c | 15 + fs/anon_inodes.c | 12 + fs/binfmt_misc.c | 20 +- fs/block_dev.c | 14 + fs/btrfs/tests/btrfs-tests.c | 13 + fs/configfs/mount.c| 20 +- fs/efivarfs/super.c| 20 +- fs/fuse/control.c | 20 +- fs/libfs.c | 91 ++-- fs/nfsd/nfsctl.c | 33 ++- fs/nsfs.c | 13 + fs/openpromfs/inode.c | 20 +- fs/pipe.c | 12 + fs/ramfs/inode.c | 104 ++--- fs/super.c | 106 ++ include/linux/fs.h | 21 -- include/linux/fs_context.h |8 + include/linux/ramfs.h |6 - include/linux/shmem_fs.h |4 init/do_mounts.c | 12 - mm/shmem.c | 396 mm/zsmalloc.c | 19 +- net/socket.c | 14 + net/sunrpc/rpc_pipe.c | 34 ++- security/apparmor/apparmorfs.c | 20 +- security/inode.c | 21 +- security/selinux/selinuxfs.c | 20 +- security/smack/smackfs.c | 34 ++- 41 files changed, 902 insertions(+), 609 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] drm/vkms: Add writeback support
On 03/11, Liviu Dudau wrote: > On Sun, Mar 10, 2019 at 06:20:34PM -0300, Rodrigo Siqueira wrote: > > Hi, > > Hi Rodrigo, > > > > > In the last few weeks, I was focused on implementing the writeback on > > VKMS by using the feedback that I got from Brian Starkey and Daniel > > Vetter in my previous attempt [1]. For testing/guiding my > > implementation, I’m using a patchset made by Liviu and Brian that adds > > writeback tests to IGT [2]. This patch, already pass the basic > > requirements and some of the other tests. > > > > So, in this implementation I adopted the following design: you can use > > writeback_connector, or you can have a virtual connector, but you cannot > > have both. Should I keep the virtual connector always available and make > > it possible to add writeback connector as the secondary connector? If > > so, there's any IGT test for this? > > Given that the writeback is one-shot (i.e. no output will be generated > after the commit that provided a writeback framebuffer), how does that play > with your userspace? I think that unless you have a specific reason for it, > having both connectors available all the time makes sense, and the writeback > connector only gets used by the userspace that sets the right CAPS. Hi Liviu, First of all, thank you for the feedback. Originally, my final goal was to use writeback feature for adding a visual output for VKMS. I want to make the userspace aware of the writeback in the VKMS, and use it for displaying things. However, at this moment, I just want to make sure that VKMS can pass in all of the tests in the kms_writeback. Anyway, I agree with your point about keep both connectors enabled. I will fix it, thanks for shed lights on this issue. Also, thank you for the given ideas related to the to 'drm_writeback_signal_completion()' problem in my implementation. I will take a careful look at it; I’m suspecting that I’m making some wrong assumptions... Best Regards Rodrigo Siqueira > > > > Secondly, I’m facing problems related to > > ‘drm_writeback_signal_completion()’, for some reason that I did not know > > yet I continuously get the following error in a loop: > > > > [ +0.60] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G D W > > 5.0.0-VKMS #102 > > [ +0.04] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > > 1.12.0-20181126_142135-anatol 04/01/2014 > > [ +0.33] RIP: 0010:drm_writeback_signal_completion+0x10c/0x130 [drm] > > [ +0.06] Code: 01 00 00 48 89 43 e8 48 89 43 f0 48 8b 35 3c 67 b3 e4 > > 5b 5d 41 5c 41 5d 41 5e e9 0f 7d aa e3 4c 89 ee 4c 89 e7 e8 a4 4e 18 e4 > > <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 e8 54 2f f8 e3 eb 9a 0f 0b e9 60 > > [ +0.04] RSP: 0018:98593cb83ec0 EFLAGS: 00010082 > > [ +0.06] RAX: 80010002 RBX: 98593bbb54b0 RCX: > > > > [ +0.05] RDX: 0001 RSI: 0082 RDI: > > > > [ +0.04] RBP: 98593bbb54b0 R08: R09: > > 98593cb83e20 > > [ +0.04] R10: 98593a07d600 R11: R12: > > 98593bbb54a8 > > [ +0.04] R13: 0082 R14: R15: > > 98593cb9cd38 > > [ +0.06] FS: () GS:98593cb8() > > knlGS: > > [ +0.04] CS: 0010 DS: ES: CR0: 80050033 > > [ +0.05] CR2: 7f3cea2e8000 CR3: ba6ec000 CR4: > > 06e0 > > [ +0.10] Call Trace: > > [ +0.07] > > [ +0.13] ? vkms_disable_vblank+0x20/0x20 [vkms] > > [ +0.08] vkms_vblank_simulate+0xef/0x110 [vkms] > > [ +0.08] ? vkms_disable_vblank+0x20/0x20 [vkms] > > [ +0.07] __hrtimer_run_queues+0x100/0x2d0 > > [ +0.08] hrtimer_interrupt+0x10a/0x220 > > [ +0.08] ? kvm_sched_clock_read+0x5/0x10 > > [ +0.10] smp_apic_timer_interrupt+0x69/0x160 > > [ +0.07] apic_timer_interrupt+0xf/0x20 > > [ +0.04] > > [ +0.08] RIP: 0010:native_safe_halt+0x2/0x10 > > [ +0.05] Code: 5b ff ff ff 7f 5b c3 65 48 8b 04 25 00 5c 01 00 f0 80 > > 48 02 20 48 8b 00 a8 08 75 c3 eb 8b 90 90 90 90 90 90 90 90 90 90 fb f4 > > 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 f4 c3 90 90 90 90 90 90 > > [ +0.05] RSP: 0018:b937c06b3eb8 EFLAGS: 0202 ORIG_RAX: > > ff13 > > [ +0.05] RAX: 0003 RBX: 0003 RCX: > > 0001 > > [ +0.04] RDX: 0001 RSI: a4e6da3e RDI: > > a4e6dd30 > > [ +0.05] RBP: a51252e0 R08: a55e7438 R09: > > > > [ +0.03] R10: R11: a5049fb8 R12: > > > > [ +0.04] R13: R14: R15: > > > > [ +0.12] default_idle+0x1a/0x170 > > [ +0.10] do_idle+0x1d5/0x250 > > [ +0.07] cpu_startup_entry+0x19/0x20 > > [ +0.07] start_secondary+0x1aa/0x200 > > [ +0.08] secondary_startup_64+0xa4/0x
Re: [Patch 1/1] drm/atomic: integrate private objects with suspend/resume helpers
Ville Syrjälä wrote on Thu [2019-Mar-14
17:31:29 +0200]:
> On Thu, Mar 14, 2019 at 08:44:45AM -0500, Benoit Parrot wrote:
> > During a suspend cycle the atomic state is saved to be used during the
> > restore cycle.
> >
> > However the current state duplication logic does not duplicate private
> > objects. This leads to state inconsistencies at resume time.
> >
> > With private objects modeset lock now integrated, we can make sure that
> > private object state are properly saved and restored.
> >
> > Signed-off-by: Benoit Parrot
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 540a77a2ade9..b108021cc092 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -3189,6 +3189,7 @@ drm_atomic_helper_duplicate_state(struct drm_device
> > *dev,
> > struct drm_connector_list_iter conn_iter;
> > struct drm_plane *plane;
> > struct drm_crtc *crtc;
> > + struct drm_private_obj *privobj;
> > int err = 0;
> >
> > state = drm_atomic_state_alloc(dev);
> > @@ -3218,6 +3219,16 @@ drm_atomic_helper_duplicate_state(struct drm_device
> > *dev,
> > }
> > }
> >
> > + drm_for_each_privobj(privobj, dev) {
> > + struct drm_private_state *priv_state;
> > +
> > + priv_state = drm_atomic_get_private_obj_state(state, privobj);
> > + if (IS_ERR(priv_state)) {
> > + err = PTR_ERR(priv_state);
> > + goto free;
> > + }
> > + }
> > +
> > drm_connector_list_iter_begin(dev, &conn_iter);
> > drm_for_each_connector_iter(conn, &conn_iter) {
> > struct drm_connector_state *conn_state;
> > @@ -3325,12 +3336,17 @@ int
> > drm_atomic_helper_commit_duplicated_state(struct drm_atomic_state *state,
> > struct drm_connector_state *new_conn_state;
> > struct drm_crtc *crtc;
> > struct drm_crtc_state *new_crtc_state;
> > + struct drm_private_obj *privobj;
> > + struct drm_private_state *new_priv_state;
> >
> > state->acquire_ctx = ctx;
> >
> > for_each_new_plane_in_state(state, plane, new_plane_state, i)
> > state->planes[i].old_state = plane->state;
> >
> > + for_each_new_private_obj_in_state(state, privobj, new_priv_state, i)
> > + state->private_objs[i].old_state = privobj->state;
> > +
> > for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> > state->crtcs[i].old_state = crtc->state;
>
> Random order between crtc vs. plane vs. connector vs. priv is tickling
> my ocd nerve a bit.
These loops are independent from each other.
And even without this patch the order is different between
drm_atomic_helper_duplicate_state() and
drm_atomic_helper_commit_duplicated_state(). :)
Benoit
>
> Otherwise looks sensible to me.
> Reviewed-by: Ville Syrjälä
>
> >
> > --
> > 2.17.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/sun4i: Implement gamma correction
Hi Vasily,
On Wed, Mar 13, 2019 at 07:58:38PM -0700, Vasily Khoruzhick wrote:
> Add support for gamma corretion to sun4i TCON driver. Its LUT has 256
> entries and can be updated only when gamma correction is disabled.
>
> Signed-off-by: Vasily Khoruzhick
It's not really clear to me what you expect a comment on?
Maxime
> ---
> drivers/gpu/drm/sun4i/sun4i_crtc.c | 15 ++
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 33 ++
> drivers/gpu/drm/sun4i/sun4i_tcon.h | 12 ++-
> 3 files changed, 59 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_crtc.c
> b/drivers/gpu/drm/sun4i/sun4i_crtc.c
> index 3eedf335a935..719259d09632 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_crtc.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_crtc.c
> @@ -101,6 +101,20 @@ static void sun4i_crtc_atomic_flush(struct drm_crtc
> *crtc,
> drm_crtc_send_vblank_event(crtc, event);
> spin_unlock_irq(&crtc->dev->event_lock);
> }
> +
> + if (crtc->state->color_mgmt_changed) {
> + if (crtc->state->gamma_lut) {
> + /* LUT can be only updated when gamma correction is
> + * disabled
> + */
> + sun4i_tcon_enable_gamma(scrtc->tcon, false);
> + sun4i_tcon_load_gamma_lut(scrtc->tcon,
> + crtc->state->gamma_lut->data);
> + sun4i_tcon_enable_gamma(scrtc->tcon, true);
> + } else
> + sun4i_tcon_enable_gamma(scrtc->tcon, false);
> + }
> +
> }
>
> static void sun4i_crtc_atomic_disable(struct drm_crtc *crtc,
> @@ -184,6 +198,7 @@ static const struct drm_crtc_funcs sun4i_crtc_funcs = {
> .set_config = drm_atomic_helper_set_config,
> .enable_vblank = sun4i_crtc_enable_vblank,
> .disable_vblank = sun4i_crtc_disable_vblank,
> + .gamma_set = drm_atomic_helper_legacy_gamma_set,
> };
>
> struct sun4i_crtc *sun4i_crtc_init(struct drm_device *drm,
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index cf45d0f940f9..3f5f9d4f54a6 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -215,6 +215,34 @@ void sun4i_tcon_enable_vblank(struct sun4i_tcon *tcon,
> bool enable)
> }
> EXPORT_SYMBOL(sun4i_tcon_enable_vblank);
>
> +void sun4i_tcon_load_gamma_lut(struct sun4i_tcon *tcon,
> +struct drm_color_lut *lut)
> +{
> + int i;
> +
> + for (i = 0; i < SUN4I_TCON_GAMMA_LUT_SIZE; i++) {
> + u32 r, g, b;
> +
> + r = drm_color_lut_extract(lut[i].red, 8);
> + g = drm_color_lut_extract(lut[i].green, 8);
> + b = drm_color_lut_extract(lut[i].blue, 8);
> +
> + regmap_write(tcon->regs, SUN4I_TCON_GAMMA_TABLE_REG + 4 * i,
> + SUN4I_TCON_GAMMA_TABLE_R(r) |
> + SUN4I_TCON_GAMMA_TABLE_G(g) |
> + SUN4I_TCON_GAMMA_TABLE_B(b));
> + }
> +}
> +EXPORT_SYMBOL(sun4i_tcon_load_gamma_lut);
> +
> +void sun4i_tcon_enable_gamma(struct sun4i_tcon *tcon, bool enable)
> +{
> + regmap_update_bits(tcon->regs, SUN4I_TCON_GCTL_REG,
> +SUN4I_TCON_GCTL_GAMMA_ENABLE,
> +enable ? SUN4I_TCON_GCTL_GAMMA_ENABLE : 0);
> +}
> +EXPORT_SYMBOL(sun4i_tcon_enable_gamma);
> +
> /*
> * This function is a helper for TCON output muxing. The TCON output
> * muxing control register in earlier SoCs (without the TCON TOP block)
> @@ -1261,6 +1289,11 @@ static int sun4i_tcon_bind(struct device *dev, struct
> device *master,
>
> list_add_tail(&tcon->list, &drv->tcon_list);
>
> + drm_mode_crtc_set_gamma_size(&tcon->crtc->crtc,
> + SUN4I_TCON_GAMMA_LUT_SIZE);
> + drm_crtc_enable_color_mgmt(&tcon->crtc->crtc, 0, false,
> +tcon->crtc->crtc.gamma_size);
> +
> return 0;
>
> err_free_dotclock:
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> index 84cfb1952ff7..68a29e49e426 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> @@ -22,6 +22,7 @@
>
> #define SUN4I_TCON_GCTL_REG 0x0
> #define SUN4I_TCON_GCTL_TCON_ENABLE BIT(31)
> +#define SUN4I_TCON_GCTL_GAMMA_ENABLE BIT(30)
> #define SUN4I_TCON_GCTL_IOMAP_MASK BIT(0)
> #define SUN4I_TCON_GCTL_IOMAP_TCON1 (1 << 0)
> #define SUN4I_TCON_GCTL_IOMAP_TCON0 (0 << 0)
> @@ -215,7 +216,13 @@
> #define SUN4I_TCON1_FILL_BEG2_REG0x31c
> #define SUN4I_TCON1_FILL_END2_REG0x320
> #define SUN4I_TCON1_FILL_DATA2_REG 0x324
> -#define SUN4I_TCON1_GAMMA_TABLE_REG 0x400
> +
> +#defi
Re: [PATCH] drm/sun4i: hdmi: add support for ddc-i2c-bus property
On Mon, Mar 11, 2019 at 04:11:06PM +, Måns Rullgård wrote:
> Maxime Ripard writes:
>
> > Hi!
> >
> > On Mon, Mar 11, 2019 at 01:47:13PM +, Mans Rullgard wrote:
> >> Sometimes it is desirabled to use a separate i2c controller for ddc
> >> access. This adds support for the ddc-i2c-bus property of the
> >> hdmi-connector node, using the specified controller if provided.
> >>
> >> Signed-off-by: Mans Rullgard
> >> ---
> >> drivers/gpu/drm/sun4i/sun4i_hdmi.h | 1 +
> >> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 37 +++---
> >> 2 files changed, 35 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> >> b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> >> index b685ee11623d..b08c4453d47c 100644
> >> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> >> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> >> @@ -269,6 +269,7 @@ struct sun4i_hdmi {
> >>struct clk *tmds_clk;
> >>
> >>struct i2c_adapter *i2c;
> >> + struct i2c_adapter *ddc_i2c;
> >>
> >>/* Regmap fields for I2C adapter */
> >>struct regmap_field *field_ddc_en;
> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> >> b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> >> index 061d2e0d9011..5b2fac79f5d6 100644
> >> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> >> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> >> @@ -212,7 +212,7 @@ static int sun4i_hdmi_get_modes(struct drm_connector
> >> *connector)
> >>struct edid *edid;
> >>int ret;
> >>
> >> - edid = drm_get_edid(connector, hdmi->i2c);
> >> + edid = drm_get_edid(connector, hdmi->ddc_i2c ?: hdmi->i2c);
> >
> > You can't test whether ddc_i2c is NULL or not...
> >
> >>if (!edid)
> >>return 0;
> >>
> >> @@ -228,6 +228,28 @@ static int sun4i_hdmi_get_modes(struct drm_connector
> >> *connector)
> >>return ret;
> >> }
> >>
> >> +static struct i2c_adapter *sun4i_hdmi_get_ddc(struct device *dev)
> >> +{
> >> + struct device_node *phandle, *remote;
> >> + struct i2c_adapter *ddc;
> >> +
> >> + remote = of_graph_get_remote_node(dev->of_node, 1, -1);
> >> + if (!remote)
> >> + return ERR_PTR(-EINVAL);
> >> +
> >> + phandle = of_parse_phandle(remote, "ddc-i2c-bus", 0);
> >> + of_node_put(remote);
> >> + if (!phandle)
> >> + return NULL;
> >> +
> >> + ddc = of_get_i2c_adapter_by_node(phandle);
> >> + of_node_put(phandle);
> >> + if (!ddc)
> >> + return ERR_PTR(-EPROBE_DEFER);
> >> +
> >> + return ddc;
> >
> > ... Since even in (most) error cases you're returning a !NULL pointer.
> >
> >> +}
> >> +
> >> static const struct drm_connector_helper_funcs
> >> sun4i_hdmi_connector_helper_funcs = {
> >>.get_modes = sun4i_hdmi_get_modes,
> >> };
> >> @@ -575,6 +597,12 @@ static int sun4i_hdmi_bind(struct device *dev, struct
> >> device *master,
> >>goto err_disable_mod_clk;
> >>}
> >>
> >> + hdmi->ddc_i2c = sun4i_hdmi_get_ddc(dev);
> >> + if (IS_ERR(hdmi->ddc_i2c)) {
>
> ... which is checked here.
>
> The property is optional, so the idea was to return null in that case
> and use the built-in controller. If the property exists but some error
> occurs, we want to abort rather than proceed with the fallback which
> almost certainly won't work.
>
> Maybe I got something wrong in that logic.
Indeed, I just got confused. I guess returning ENODEV in such a case,
and testing for that, would make things more obvious.
Thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Patch 1/1] drm/atomic: integrate private objects with suspend/resume helpers
On Thu, Mar 14, 2019 at 08:44:45AM -0500, Benoit Parrot wrote:
> During a suspend cycle the atomic state is saved to be used during the
> restore cycle.
>
> However the current state duplication logic does not duplicate private
> objects. This leads to state inconsistencies at resume time.
>
> With private objects modeset lock now integrated, we can make sure that
> private object state are properly saved and restored.
>
> Signed-off-by: Benoit Parrot
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 540a77a2ade9..b108021cc092 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3189,6 +3189,7 @@ drm_atomic_helper_duplicate_state(struct drm_device
> *dev,
> struct drm_connector_list_iter conn_iter;
> struct drm_plane *plane;
> struct drm_crtc *crtc;
> + struct drm_private_obj *privobj;
> int err = 0;
>
> state = drm_atomic_state_alloc(dev);
> @@ -3218,6 +3219,16 @@ drm_atomic_helper_duplicate_state(struct drm_device
> *dev,
> }
> }
>
> + drm_for_each_privobj(privobj, dev) {
> + struct drm_private_state *priv_state;
> +
> + priv_state = drm_atomic_get_private_obj_state(state, privobj);
> + if (IS_ERR(priv_state)) {
> + err = PTR_ERR(priv_state);
> + goto free;
> + }
> + }
> +
> drm_connector_list_iter_begin(dev, &conn_iter);
> drm_for_each_connector_iter(conn, &conn_iter) {
> struct drm_connector_state *conn_state;
> @@ -3325,12 +3336,17 @@ int drm_atomic_helper_commit_duplicated_state(struct
> drm_atomic_state *state,
> struct drm_connector_state *new_conn_state;
> struct drm_crtc *crtc;
> struct drm_crtc_state *new_crtc_state;
> + struct drm_private_obj *privobj;
> + struct drm_private_state *new_priv_state;
>
> state->acquire_ctx = ctx;
>
> for_each_new_plane_in_state(state, plane, new_plane_state, i)
> state->planes[i].old_state = plane->state;
>
> + for_each_new_private_obj_in_state(state, privobj, new_priv_state, i)
> + state->private_objs[i].old_state = privobj->state;
> +
> for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> state->crtcs[i].old_state = crtc->state;
Random order between crtc vs. plane vs. connector vs. priv is tickling
my ocd nerve a bit.
Otherwise looks sensible to me.
Reviewed-by: Ville Syrjälä
>
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/vkms: Add overlay plane support
On 03/13, Mamta Shukla wrote:
> On Sun, Mar 10, 2019 at 9:00 PM Rodrigo Siqueira
> wrote:
> >
> > Hi,
> >
> > Thanks for your patch.
> >
> > You can see my comments inline.
> >
> > On 03/09, Mamta Shukla wrote:
> > > Add overlay plane support in vkms aligned with cursor and primary
> > > plane with module option 'enable_overlay' to enable/disable overlay
> > > plane while testing.
> > >
> > > This currently passes plane-position-covered-pipe-A-plane subtest
> > > from IGT kms_plane test.
> >
> > What the difference of running this test with and without your patch?
> > This test pass without your patch as well. Additionally, I briefly
> > looked at the test, and l could not get confident that
> > "plane-position-covered-pipe-A-plane" validate overlays. Did I miss
> > something?
> >
> > > Signed-off-by: Mamta Shukla
> > > ---
> > > changes in v3:
> > > -Fix spelling mistake 'palne'->'plane'
> > > -Use switch case
> > > -Use logical operator '||' in place of '|'
> > >
> > > change in v2:
> > > -Fix warning: return makes pointer from integer without a cast using
> > > ERR_PTR
> > >
> > > drivers/gpu/drm/vkms/vkms_crc.c | 42 +++
> > > drivers/gpu/drm/vkms/vkms_drv.c | 4 +++
> > > drivers/gpu/drm/vkms/vkms_drv.h | 8 ++
> > > drivers/gpu/drm/vkms/vkms_plane.c | 36 +-
> > > 4 files changed, 84 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/vkms/vkms_crc.c
> > > b/drivers/gpu/drm/vkms/vkms_crc.c
> > > index 4dd6c155363d..82bfee7c79b5 100644
> > > --- a/drivers/gpu/drm/vkms/vkms_crc.c
> > > +++ b/drivers/gpu/drm/vkms/vkms_crc.c
> > > @@ -109,6 +109,26 @@ static void blend(void *vaddr_dst, void *vaddr_src,
> > > }
> > > }
> > >
> > > +static void compose_overlay(struct vkms_crc_data *overlay_crc,
> > > + struct vkms_crc_data *primary_crc, void
> > > *vaddr_out)
> > > +{
> > > + struct drm_gem_object *overlay_obj;
> > > + struct vkms_gem_object *overlay_vkms_obj;
> > > +
> > > + overlay_obj = drm_gem_fb_get_obj(&overlay_crc->fb, 0);
> > > + overlay_vkms_obj = drm_gem_to_vkms_gem(overlay_obj);
> > > + mutex_lock(&overlay_vkms_obj->pages_lock);
> > > + if (!overlay_vkms_obj->vaddr) {
> > > + DRM_WARN("overlay plane vaddr is NULL");
> > > + goto out;
> > > + }
> > > +
> > > + blend(vaddr_out, overlay_vkms_obj->vaddr, primary_crc, overlay_crc);
> > > +
> > > +out:
> > > + mutex_unlock(&overlay_vkms_obj->pages_lock);
> > > +}
> > > +
> > > static void compose_cursor(struct vkms_crc_data *cursor_crc,
> > > struct vkms_crc_data *primary_crc, void
> > > *vaddr_out)
> > > {
> > > @@ -131,7 +151,8 @@ static void compose_cursor(struct vkms_crc_data
> > > *cursor_crc,
> > > }
> > >
> > > static uint32_t _vkms_get_crc(struct vkms_crc_data *primary_crc,
> > > - struct vkms_crc_data *cursor_crc)
> > > + struct vkms_crc_data *cursor_crc,
> > > + struct vkms_crc_data *overlay_crc)
> > > {
> > > struct drm_framebuffer *fb = &primary_crc->fb;
> > > struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
> > > @@ -154,6 +175,8 @@ static uint32_t _vkms_get_crc(struct vkms_crc_data
> > > *primary_crc,
> > > memcpy(vaddr_out, vkms_obj->vaddr, vkms_obj->gem.size);
> > > mutex_unlock(&vkms_obj->pages_lock);
> > >
> > > + if (overlay_crc)
> > > + compose_overlay(overlay_crc, primary_crc, vaddr_out);
> > > if (cursor_crc)
> > > compose_cursor(cursor_crc, primary_crc, vaddr_out);
> > >
> > > @@ -184,6 +207,7 @@ void vkms_crc_work_handle(struct work_struct *work)
> > > output);
> > > struct vkms_crc_data *primary_crc = NULL;
> > > struct vkms_crc_data *cursor_crc = NULL;
> > > + struct vkms_crc_data *overlay_crc = NULL;
> > > struct drm_plane *plane;
> > > u32 crc32 = 0;
> > > u64 frame_start, frame_end;
> > > @@ -208,14 +232,22 @@ void vkms_crc_work_handle(struct work_struct *work)
> > > if (drm_framebuffer_read_refcount(&crc_data->fb) == 0)
> > > continue;
> > >
> > > - if (plane->type == DRM_PLANE_TYPE_PRIMARY)
> > > + switch (plane->type) {
> > > + case DRM_PLANE_TYPE_PRIMARY:
> > > primary_crc = crc_data;
> > > - else
> > > + break;
> > > + case DRM_PLANE_TYPE_CURSOR:
> > > cursor_crc = crc_data;
> > > + break;
> > > + case DRM_PLANE_TYPE_OVERLAY:
> > > + overlay_crc = crc_data;
> > > + break;
> > > + }
> > > }
> > >
> > > - if (primary_crc)
> > > - crc32 = _vkms_get_crc(primary_crc, cursor_crc);
> > > + if (primary_crc) {
> > > +
[Patch 1/1] drm/atomic: integrate private objects with suspend/resume helpers
During a suspend cycle the atomic state is saved to be used during the
restore cycle.
However the current state duplication logic does not duplicate private
objects. This leads to state inconsistencies at resume time.
With private objects modeset lock now integrated, we can make sure that
private object state are properly saved and restored.
Signed-off-by: Benoit Parrot
---
drivers/gpu/drm/drm_atomic_helper.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 540a77a2ade9..b108021cc092 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3189,6 +3189,7 @@ drm_atomic_helper_duplicate_state(struct drm_device *dev,
struct drm_connector_list_iter conn_iter;
struct drm_plane *plane;
struct drm_crtc *crtc;
+ struct drm_private_obj *privobj;
int err = 0;
state = drm_atomic_state_alloc(dev);
@@ -3218,6 +3219,16 @@ drm_atomic_helper_duplicate_state(struct drm_device *dev,
}
}
+ drm_for_each_privobj(privobj, dev) {
+ struct drm_private_state *priv_state;
+
+ priv_state = drm_atomic_get_private_obj_state(state, privobj);
+ if (IS_ERR(priv_state)) {
+ err = PTR_ERR(priv_state);
+ goto free;
+ }
+ }
+
drm_connector_list_iter_begin(dev, &conn_iter);
drm_for_each_connector_iter(conn, &conn_iter) {
struct drm_connector_state *conn_state;
@@ -3325,12 +3336,17 @@ int drm_atomic_helper_commit_duplicated_state(struct
drm_atomic_state *state,
struct drm_connector_state *new_conn_state;
struct drm_crtc *crtc;
struct drm_crtc_state *new_crtc_state;
+ struct drm_private_obj *privobj;
+ struct drm_private_state *new_priv_state;
state->acquire_ctx = ctx;
for_each_new_plane_in_state(state, plane, new_plane_state, i)
state->planes[i].old_state = plane->state;
+ for_each_new_private_obj_in_state(state, privobj, new_priv_state, i)
+ state->private_objs[i].old_state = privobj->state;
+
for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
state->crtcs[i].old_state = crtc->state;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202799] amd/dc: right monitor sometimes never comes back up on dual-display setup after locking session
https://bugzilla.kernel.org/show_bug.cgi?id=202799 --- Comment #6 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) --- It might be useful to have a dmesg log from after the problem occurred with drm.debug=4 set in your kernel boot parameters. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110113] AMD Vega64 issue setting custom voltages
https://bugs.freedesktop.org/show_bug.cgi?id=110113 Bug ID: 110113 Summary: AMD Vega64 issue setting custom voltages Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: wsla...@gmail.com I have been attempting to undervolt my Vega64 to reduce power consumption. I have tested the GPU under Fedora 29, running stock kernel 4.20 and mesa 18.3, and Mint 19.1, with Kernel 5.0 and mesa 19 and the issue is identical I have set the AMDgpu mask in grub to amdgpu.ppfeaturemask=0x. I can confirm the GPU accepts custom values that I write into pp_od_clk_voltage, and the GPU run on these, but the voltage create a strange profile. The voltages abide to the new settings, but only in the hysteresis/dead band around the clock in that P state. Soon as the clocks move out of this band, the voltages go max, i.e. 1.2V. Under 2D workload, the card seems fine, but soon as it is in 3D work loads, running in P5 and up, the voltage control is a problem, esspecialy if I'm at only 1450Mhz and running at 1.2V If I set P state, P6, to 1550MHz @ 1000mV and P7 to 1620MHz @ 1050mV and the clock is around 1550MHz, I will see that it has set the voltage to 1000mV, but if that freq increase to, say, 1580MHz, the GPU will be set to 1200mV. I suspected that maybe the reading I saw was incorrect, but it cannot be incorrect, as the GPU performs worse after the tweak, generally battling to leave P5 state, where stock clocks, it will stick closer to the P6 state clocks. My GPU also unfortunately has coil whine, but this does give audio cues with load and frame rate. The GPU changes pitch when it moves in and out of the set voltage. The GPU whine will be quieter when it landed in the reduced voltage state, and immediately increases once it jumps to the 1.2V state. The issue is also that it jumps between the reduced voltage and full voltage when it is boarder line, as the GPU starts to throttle when the voltages jump to 1.2V Essentially this is how I see the GPU react to my new voltage profile (leaving the clocks at stock). P5 P6 P7 ---| |-| |--| |-1200mV |_| |_| |_| 980mV 1000mV 1050mV So far all I can really change is the power state without causing issue, and this helps with performace when I increase it, at the cost of massive heat production -- 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: [RFC PATCH] drm/panfrost: Add initial panfrost driver
On Thu, Mar 14, 2019 at 4:01 AM Neil Armstrong wrote: > > On 08/03/2019 01:24, Rob Herring wrote: > > From: "Marty E. Plummer" > > > > This adds the initial driver for panfrost which supports Arm Mali > > Midgard and Bifrost family of GPUs. Currently, only the T860 Midgard GPU > > has been tested. > > > > Cc: Maarten Lankhorst > > Cc: Maxime Ripard > > Cc: Sean Paul > > Cc: David Airlie > > Cc: Daniel Vetter > > Cc: Alyssa Rosenzweig > > Cc: Lyude Paul > > Cc: Eric Anholt > > Signed-off-by: Marty E. Plummer > > Signed-off-by: Tomeu Vizoso > > Signed-off-by: Rob Herring > > --- > > Sending this out in the spirit of release early, release often. We're > > close to parity compared to mesa + the vendor driver. There's a few > > issues Tomeu is chasing. > > > > There's still some pieces of the h/w setup we've just hardcoded. Locking > > in various places is probably missing. Error recovery is non-existent > > (other than module unload/load). There's some work to add tracepoints > > and perf counters that's not here yet. Bifrost GPUs are definitely not > > supported yet other than identifying them. Primarily the MMU setup is > > missing. [...] > > diff --git a/drivers/gpu/drm/panfrost/Kconfig > > b/drivers/gpu/drm/panfrost/Kconfig > > new file mode 100644 > > index ..eb7283149354 > > --- /dev/null > > +++ b/drivers/gpu/drm/panfrost/Kconfig > > @@ -0,0 +1,14 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > + > > +config DRM_PANFROST > > + tristate "Panfrost (DRM support for ARM Mali Midgard/Bifrost GPUs)" > > + depends on DRM > > + depends on ARCH_ROCKCHIP > > Could you switch to > + depends on ARM || ARM64 || COMPILE_TEST > instead of ARCH_ROCKHIP ? > > It will simply bringup on non-rockchip boards. Yes, certainly. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2 1/3] drm: Add support for panic message output
On 3/14/19 5:50 AM, Daniel Vetter wrote:
> On Wed, Mar 13, 2019 at 05:41:52PM +, Kazlauskas, Nicholas wrote:
>> On 3/13/19 1:33 PM, Michel Dänzer wrote:
>>> On 2019-03-13 5:16 p.m., Kazlauskas, Nicholas wrote:
On 3/13/19 11:54 AM, Christian König wrote:
> Am 13.03.19 um 16:38 schrieb Michel Dänzer:
>> On 2019-03-13 2:37 p.m., Christian König wrote:
>>> Am 13.03.19 um 14:31 schrieb Ville Syrjälä:
On Wed, Mar 13, 2019 at 10:35:08AM +0100, Michel Dänzer wrote:
> On 2019-03-12 6:15 p.m., Noralf Trønnes wrote:
>> Den 12.03.2019 17.17, skrev Ville Syrjälä:
>>> On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
> This adds support for outputting kernel messages on panic().
> A kernel message dumper is used to dump the log. The dumper
> iterates
> over each DRM device and it's crtc's to find suitable
> framebuffers.
>
> All the other dumpers are run before this one except mtdoops.
> Only atomic drivers are supported.
>
> Signed-off-by: Noralf Trønnes
> ---
> [...]
>
> diff --git a/include/drm/drm_framebuffer.h
> b/include/drm/drm_framebuffer.h
> index f0b34c977ec5..f3274798ecfe 100644
> --- a/include/drm/drm_framebuffer.h
> +++ b/include/drm/drm_framebuffer.h
> @@ -94,6 +94,44 @@ struct drm_framebuffer_funcs {
> struct drm_file *file_priv, unsigned flags,
> unsigned color, struct drm_clip_rect *clips,
> unsigned num_clips);
> +
> + /**
> + * @panic_vmap:
> + *
> + * Optional callback for panic handling.
> + *
> + * For vmapping the selected framebuffer in a panic context.
> Must
> + * be super careful about locking (only trylocking allowed).
> + *
> + * RETURNS:
> + *
> + * NULL if it didn't work out, otherwise an opaque cookie
> which is
> + * passed to @panic_draw_xy. It can be anything: vmap area,
> structure
> + * with more details, just a few flags, ...
> + */
> + void *(*panic_vmap)(struct drm_framebuffer *fb);
FWIW, the panic_vmap hook cannot work in general with the
amdgpu/radeon
drivers:
Framebuffers are normally tiled, writing to them with the CPU
results in
garbled output.
>> In which case the driver needs to support the ->panic_draw_xy
>> callback,
>> or maybe it's possible to make a generic helper for tiled buffers.
> I'm afraid that won't help, at least not without porting big chunks of
> https://gitlab.freedesktop.org/mesa/mesa/tree/master/src/amd/addrlib
> into the kernel, none of which will be used for anything else.
>
>
There would need to be a mechanism for switching scanout to a
linear,
CPU accessible framebuffer.
>>> I suppose panic_vmap() could just provide a linear temp buffer
>>> to the panic handler, and panic_unmap() could copy the contents
>>> over to the real fb.
> Copy how? Using a GPU engine?
CPU maybe? Though I suppose that won't work if the buffer isn't CPU
accesible :/
>>> Well we do have a debug path for accessing invisible memory with the
>>> CPU.
>>>
>>> E.g. three registers: DATA and auto increment OFFSET_LO/HI. So you can
>>> just read/write DATA over and over again if you want to access some
>>> memory.
>> Right. I assume that'll be very slow, but I guess it could do when the
>> memory isn't directly CPU accessible.
>
> Just made a quick test and reading 33423360 bytes (4096x2040x4) using
> that interfaces takes about 13 seconds.
>
> IIRC we don't use the auto increment optimization yet, so that can
> probably be improved by a factor of 3 or more.
>>>
>>> I'd assume only writes are needed, no reads.
>>>
>>>
>>> But turning of tilling etc is still extremely tricky when the system is
>>> already unstable.
>> Maybe we could add a little hook to the display code, which just
>> disables tiling for scanout and maybe disables non-primary planes, but
>> doesn't touch anything else. Harry / Nicholas, does that seem feasible?
>>
>>
>> I'm coming around from "this is never going to work" to "it might
>> actually work" with our hardware...
>
> Yeah, agree. It's a bit tricky, but doable.
A "disable_tiling"
Re: [PATCH v6 11/18] media: vsp1: drm: Implement writeback support
Hi Kieran,
On Thu, Mar 14, 2019 at 08:28:27AM +, Kieran Bingham wrote:
> On 13/03/2019 15:56, Laurent Pinchart wrote:
> > On Wed, Mar 13, 2019 at 11:42:34AM +, Kieran Bingham wrote:
> >> On 13/03/2019 00:05, Laurent Pinchart wrote:
> >>> Extend the vsp1_du_atomic_flush() API with writeback support by adding
> >>> format, pitch and memory addresses of the writeback framebuffer.
> >>> Writeback completion is reported through the existing frame completion
> >>> callback with a new VSP1_DU_STATUS_WRITEBACK status flag.
> >>>
> >>> Signed-off-by: Laurent Pinchart
> >>>
>
> My concerns have been addressed here:
>
> Reviewed-by: Kieran Bingham
>
> >>> ---
> >>> drivers/media/platform/vsp1/vsp1_dl.c | 14 ++
> >>> drivers/media/platform/vsp1/vsp1_dl.h | 3 ++-
> >>> drivers/media/platform/vsp1/vsp1_drm.c | 25 -
> >>> include/media/vsp1.h | 15 +++
> >>> 4 files changed, 55 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
> >>> b/drivers/media/platform/vsp1/vsp1_dl.c
> >>> index ed7cda4130f2..104b6f514536 100644
> >>> --- a/drivers/media/platform/vsp1/vsp1_dl.c
> >>> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
> >>> @@ -958,6 +958,9 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl,
> >>> unsigned int dl_flags)
> >>> *
> >>> * The VSP1_DL_FRAME_END_INTERNAL flag indicates that the display list
> >>> that just
> >>> * became active had been queued with the internal notification flag.
> >>> + *
> >>> + * The VSP1_DL_FRAME_END_WRITEBACK flag indicates that the previously
> >>> active
> >>> + * display list had been queued with the writeback flag.
> >>
> >> How does this interact with the possibility of the writeback being
> >> disabled by the WPF in the event of it failing to get a DL.
> >>
> >> It's only a small corner case, but will the 'writeback' report back as
> >> though it succeeded? (without writing to memory, and thus giving an
> >> unmodified buffer back?)
> >
> > Wrteback completion will never be reported in that case. This shouldn't
> > happen as we should never fail to get a display list. Do you think it
> > would be better to fake completion ?
>
> Would this lack of completion cause a hang while DRM waits for the
> completion to occur? I guess this would timeout after some period.
Not in the kernel as far as I can tell, but userspace could then wait
forever.
> I'm not sure what's worse. To hang / block for a timeout - or just
> return a 'bad buffer'. We would know in the VSP that the completion has
> failed, so we could signal a failure, but I think as the rest of the DRM
> model goes with a timeout if the flip_done fails to complete for
> example, we should follow that.
>
> So leave this as is, and perhaps lets make sure the core writeback
> framework will report a warning if it hits a time out.
There's no timeout handling for writeback in the core.
> If we ever fail to get a display list - we will have bigger issues which
> will propogate elsewhere :)
Yes, I think so too. This should really never happen.
> >>> */
> >>> unsigned int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
> >>> {
> >>> @@ -995,6 +998,17 @@ unsigned int vsp1_dlm_irq_frame_end(struct
> >>> vsp1_dl_manager *dlm)
> >>> if (status & VI6_STATUS_FLD_STD(dlm->index))
> >>> goto done;
> >>>
> >>> + /*
> >>> + * If the active display list has the writeback flag set, the frame
> >>> + * completion marks the end of the writeback capture. Return the
> >>> + * VSP1_DL_FRAME_END_WRITEBACK flag and reset the display list's
> >>> + * writeback flag.
> >>> + */
> >>> + if (dlm->active && (dlm->active->flags & VSP1_DL_FRAME_END_WRITEBACK)) {
> >>> + flags |= VSP1_DL_FRAME_END_WRITEBACK;
> >>> + dlm->active->flags &= ~VSP1_DL_FRAME_END_WRITEBACK;
> >>> + }
> >>> +
> >>> /*
> >>>* The device starts processing the queued display list right after the
> >>>* frame end interrupt. The display list thus becomes active.
> >>> diff --git a/drivers/media/platform/vsp1/vsp1_dl.h
> >>> b/drivers/media/platform/vsp1/vsp1_dl.h
> >>> index e0fdb145e6ed..4d7bcfdc9bd9 100644
> >>> --- a/drivers/media/platform/vsp1/vsp1_dl.h
> >>> +++ b/drivers/media/platform/vsp1/vsp1_dl.h
> >>> @@ -18,7 +18,8 @@ struct vsp1_dl_list;
> >>> struct vsp1_dl_manager;
> >>>
> >>> #define VSP1_DL_FRAME_END_COMPLETED BIT(0)
> >>> -#define VSP1_DL_FRAME_END_INTERNAL BIT(1)
> >>> +#define VSP1_DL_FRAME_END_WRITEBACK BIT(1)
> >>
> >> So below BIT(2) (code above) the flags match the externally exposed
> >> bitfield for the VSP1_DU_STATUS_
> >>
> >> While above (code below), are 'private' bitfields.
> >>
> >> Should this requirement be documented here somehow? especially the
> >> mapping of FRAME_END_{COMPLETED,WRITEBACK} to
> >> DU_STATUS_{COMPLETED,WRITEBACK}.
> >
> > I've added a comment here, as explained in my reply to your review of
> > 10/1
[PATCH] fbdev: list all pci memory bars as conflicting apertures
Simply add all pci memory bars to struct apertures_struct in
remove_conflicting_pci_framebuffers(), without depending on the
res_id parameter.
The plan is to drop the res_id parameter later on. For now keep the
parameter, use it for sanity-checking and warn on inconsistencies.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/video/fbdev/core/fbmem.c | 29 +
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index cb43a2258c51..e4e5c129a0f5 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1879,14 +1879,35 @@ int remove_conflicting_pci_framebuffers(struct pci_dev
*pdev, int res_id, const
{
struct apertures_struct *ap;
bool primary = false;
- int err;
+ int err, idx, bar;
+ bool res_id_found = false;
- ap = alloc_apertures(1);
+ for (idx = 0, bar = 0; bar < PCI_ROM_RESOURCE; bar++) {
+ if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
+ continue;
+ idx++;
+ }
+
+ ap = alloc_apertures(idx);
if (!ap)
return -ENOMEM;
- ap->ranges[0].base = pci_resource_start(pdev, res_id);
- ap->ranges[0].size = pci_resource_len(pdev, res_id);
+ for (idx = 0, bar = 0; bar < PCI_ROM_RESOURCE; bar++) {
+ if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
+ continue;
+ ap->ranges[idx].base = pci_resource_start(pdev, bar);
+ ap->ranges[idx].size = pci_resource_len(pdev, bar);
+ pci_info(pdev, "%s: bar %d: 0x%lx -> 0x%lx\n", __func__, bar,
+(unsigned long)pci_resource_start(pdev, bar),
+(unsigned long)pci_resource_end(pdev, bar));
+ idx++;
+ if (res_id == bar)
+ res_id_found = true;
+ }
+ if (!res_id_found)
+ pci_warn(pdev, "%s: passed res_id (%d) is not a memory bar\n",
+__func__, res_id);
+
#ifdef CONFIG_X86
primary = pdev->resource[PCI_ROM_RESOURCE].flags &
IORESOURCE_ROM_SHADOW;
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RfC PATCH] fbdev: list all memory bars as conflicting apertures
On Thu, Mar 14, 2019 at 11:37:13AM +0100, Daniel Vetter wrote: > On Wed, Mar 13, 2019 at 12:07:41PM +0100, Gerd Hoffmann wrote: > > Simply add all pci memory bars to struct apertures_struct in > > remove_conflicting_pci_framebuffers(). That allows to drop > > the res_id parameter. > > > > TODO: actually remove the res_id parameter. > > I think best to do that in a cleanup patch afterwards. I was just lazy and didn't want update all callers for the first patch draft. But doing a test run ... > Maybe if you want to be paranoid in the conversion add a check that we're > not skipping the pci bar requested in res_id. Then we could test this for > a kernel and remove the parameter later on. ... that way before actually dropping the parameter surely makes sense. New version on the way, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/6] dt-bindings: display: sii902x: Remove trailing white space
Remove trailing white space from sii902x display bridge binding. Signed-off-by: Jyri Sarha Reviewed-by: Laurent Pinchart --- Documentation/devicetree/bindings/display/bridge/sii902x.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt b/Documentation/devicetree/bindings/display/bridge/sii902x.txt index 72d2dc6c3e6b..c4c1855ca654 100644 --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt +++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt @@ -5,7 +5,7 @@ Required properties: - reg: i2c address of the bridge Optional properties: - - interrupts: describe the interrupt line used to inform the host + - interrupts: describe the interrupt line used to inform the host about hotplug events. - reset-gpios: OF device-tree gpio specification for RST_N pin. -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
