[Bug 200645] 4.18-rc regression bisected to e03fd3f30: amdgpu polaris11/rx460 only activates on one output/monitor of two
https://bugzilla.kernel.org/show_bug.cgi?id=200645 --- Comment #7 from Duncan (1i5t5.dun...@cox.net) --- So out of curiosity I found my old DVI-D/DisplayPort adapter and tried switching outputs. First thing I noticed is that the DVI/HDMI cable I'm using is only single-link DVI, as is the DVI/DisplayPort adapter, so if I put the 4k monitor on it, it's automatically limited to 1080p. Which means that until I go buy a new cable, the only way I have to connect the 4k monitor and /get/ 4k is via the HDMI/HDMI cable and the card's HDMI connector. That leaves the DVI or DisplayPort card connector for the 1920x1080 TV. I can connect it directly to the card DVI-D using the HDMI/DVI-D cable, as I had it when I first filed this bug, or add the DVI-D/DisplayPort adaptor as well, and connect it to the card's DisplayPort, as I have it now. Either way, connecting the 1920x1080 via DVI-D or DisplayPort, the bug still manifests -- without the cap to 8bpc, trying to boot 4.18-rc1+ blanks that monitor as soon as the drmfb code takes over from the early-boot/VGA, while the HDMI-connected 4k monitor continues to work normally (at 1080p until X starts due to the video= kernel commandline option, at native 3840x2160 in X). And the problem could also be partially due to the single-link cable I'm still using for that monitor, enough for 8bpc 1920x1080, but perhaps not enough for 10bpc, even if both ends support it (I'm not actually sure whether the 1080p limited TV does or not). -- 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
Re: [Nouveau] [PATCH v5 13/13] drm/nouveau: Call pm_runtime_get_noresume() from hpd handlers
On Tue, Aug 7, 2018 at 10:39 PM, Lyude Paul wrote:
> We can't and don't need to try resuming the device from our hotplug
> handlers, but hotplug events are generally something we'd like to keep
> the device awake for whenever possible. So, grab a PM ref safely in our
> hotplug handlers using pm_runtime_get_noresume() and mark the device as
> busy once we're finished.
>
> Signed-off-by: Lyude Paul
> Cc: sta...@vger.kernel.org
> Cc: Lukas Wunner
> Cc: Karol Herbst
> ---
> drivers/gpu/drm/nouveau/nouveau_connector.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
> b/drivers/gpu/drm/nouveau/nouveau_connector.c
> index 8409c3f2c3a1..5a8e8c1ad647 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_connector.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
> @@ -1152,6 +1152,11 @@ nouveau_connector_hotplug(struct nvif_notify *notify)
> const char *name = connector->name;
> struct nouveau_encoder *nv_encoder;
>
> + /* Resuming the device here isn't possible; but the suspend PM ops
> +* will wait for us to finish our work before disabling us so this
> +* should be enough
> +*/
> + pm_runtime_get_noresume(drm->dev->dev);
what happens when pm_runtime_get_noresume is called nd the device is
suspended already? Do we have to take care of this here as well (like
simply aborting) or is it fine as it is?
> nv_connector->hpd_task = current;
>
> if (rep->mask & NVIF_NOTIFY_CONN_V0_IRQ) {
> @@ -1171,6 +1176,9 @@ nouveau_connector_hotplug(struct nvif_notify *notify)
> }
>
> nv_connector->hpd_task = NULL;
> +
> + pm_runtime_mark_last_busy(drm->dev->dev);
> + pm_runtime_put_autosuspend(drm->dev->dev);
> return NVIF_NOTIFY_KEEP;
> }
>
> --
> 2.17.1
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH v5 05/13] drm/nouveau: Remove useless poll_enable() call in drm_load()
Patches 1-5 are Acked-by: Karol Herbst
On Tue, Aug 7, 2018 at 10:39 PM, Lyude Paul wrote:
> Again, this doesn't do anything. drm_kms_helper_poll_enable() will have
> already been called in nouveau_display_init()
>
> Signed-off-by: Lyude Paul
> Cc: Lukas Wunner
> Cc: Karol Herbst
> [omitting stable Cc, this probably doesn't fix any real bugs]
> ---
> drivers/gpu/drm/nouveau/nouveau_drm.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index 5fdc1fbe2ee5..04f704b77a3c 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -592,10 +592,8 @@ nouveau_drm_load(struct drm_device *dev, unsigned long
> flags)
> pm_runtime_allow(dev->dev);
> pm_runtime_mark_last_busy(dev->dev);
> pm_runtime_put(dev->dev);
> - } else {
> - /* enable polling for external displays */
> - drm_kms_helper_poll_enable(dev);
> }
> +
> return 0;
>
> fail_dispinit:
> --
> 2.17.1
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] fbcon: Do not takeover the console from atomic context
Hi, On 10-08-18 17:22, Bartlomiej Zolnierkiewicz wrote: On Friday, August 10, 2018 01:27:57 PM Hans de Goede wrote: Taking over the console involves allocating mem with GFP_KERNEL, talking to drm drivers, etc. So this should not be done from an atomic context. But the console-output trigger deferred console takeover may happen from an atomic context, which leads to "BUG: sleeping function called from invalid context" errors. This commit fixes these errors by doing the deferred takeover from a workqueue. Signed-off-by: Hans de Goede Patch queued for 4.19, thanks. @@ -3607,8 +3620,8 @@ static int fbcon_output_notifier(struct notifier_block *nb, deferred_takeover = false; logo_shown = FBCON_LOGO_DONTSHOW; - for_each_registered_fb(i) - fbcon_fb_registered(registered_fb[i]); + /* We may get called in atomic context */ + schedule_work(&fbcon_deferred_takeover_work); After above change gcc now complains about unused variable: drivers/video/fbdev/core/fbcon.c: In function ‘fbcon_output_notifier’: drivers/video/fbdev/core/fbcon.c:3613:6: warning: unused variable ‘i’ [-Wunused-variable] int i; ^ I fixed this while applying the patch. Ah yes, thank you for fixing this, Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100200] Default Unreal Engine 4 frag shader fails to compile
https://bugs.freedesktop.org/show_bug.cgi?id=100200 --- Comment #2 from Gert Wollny --- The according series has been pushed. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 2/4] dt-bindings: display: atmel: optional video-interface of endpoints
With bus-type/bus-width properties in the endpoint nodes, the video-
interface of the connection can be specified for cases where the
heuristic fails to select the correct output mode. This can happen
e.g. if not all RGB pins are routed on the PCB; the driver has no
way of knowing this, and needs to be told explicitly.
This is critical for the devices that have the "conflicting output
formats" issue (SAM9N12, SAM9X5, SAMA5D3), since the most significant
RGB bits move around depending on the selected output mode. For
devices that do not have the "conflicting output formats" issue
(SAMA5D2, SAMA5D4), this is completely irrelevant.
Acked-by: Boris Brezillon
Reviewed-by: Rob Herring
Reviewed-by: Jacopo Mondi
Signed-off-by: Peter Rosin
---
.../devicetree/bindings/display/atmel/hlcdc-dc.txt | 28 ++
1 file changed, 28 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
index 82f2acb3d374..d29e1e425518 100644
--- a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
+++ b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt
@@ -15,6 +15,13 @@ Required children nodes:
to external devices using the OF graph reprensentation (see ../graph.txt).
At least one port node is required.
+Optional properties in grandchild nodes:
+ Any endpoint grandchild node may specify a desired video interface
+ according to ../../media/video-interfaces.txt, specifically
+ - bus-width: recognized values are <12>, <16>, <18> and <24>, and
+ override any output mode selection heuristic, forcing "rgb444",
+ "rgb565", "rgb666" and "rgb888" respectively.
+
Example:
hlcdc: hlcdc@f003 {
@@ -50,3 +57,24 @@ Example:
#pwm-cells = <3>;
};
};
+
+Example 2: With a video interface override to force rgb565; as above
+but with these changes/additions:
+
+ &hlcdc {
+ hlcdc-display-controller {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcd_base &pinctrl_lcd_rgb565>;
+
+ port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ hlcdc_panel_output: endpoint@0 {
+ reg = <0>;
+ bus-width = <16>;
+ };
+ };
+ };
+ };
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] gpu: host1x: Ignore clients initialization failure
On Thursday, 9 August 2018 16:10:35 MSK Thierry Reding wrote: > On Thu, Aug 09, 2018 at 03:53:03PM +0300, Dmitry Osipenko wrote: > > On Thursday, 9 August 2018 13:45:41 MSK Thierry Reding wrote: > > > On Fri, Aug 03, 2018 at 02:30:47PM +0300, Dmitry Osipenko wrote: > > > > On Friday, 3 August 2018 13:50:55 MSK Thierry Reding wrote: > > > > > On Wed, Aug 01, 2018 at 06:08:07PM +0300, Dmitry Osipenko wrote: > > > > > > From time to time new bugs are popping up, causing some host1x > > > > > > client > > > > > > to > > > > > > fail its initialization. Currently a single clients initialization > > > > > > failure > > > > > > causes whole host1x device registration to fail, as a result a > > > > > > single > > > > > > DRM > > > > > > sub-device initialization failure makes whole DRM initialization > > > > > > to > > > > > > fail. > > > > > > Let's ignore clients initialization failure, as a result display > > > > > > panel > > > > > > lights up even if some DRM clients (say GR2D or VIC) fail to > > > > > > initialize. > > > > > > > > > > > > Signed-off-by: Dmitry Osipenko > > > > > > --- > > > > > > > > > > > > drivers/gpu/host1x/bus.c | 18 +++--- > > > > > > 1 file changed, 7 insertions(+), 11 deletions(-) > > > > > > > > > > This is actually done on purpose. I can't think of a case where we > > > > > would > > > > > actively like to keep a half-broken DRM device operational. The > > > > > errors > > > > > that you're talking about should only happen during development, > > > > > > > > [only in a perfect world] > > > > > > gr2d and VIC are fairly deterministic. What are the errors you are > > > seeing that cause initialization failure? > > > > Right now there are no specific errors. There is only a known trouble with > > the ARM_DMA_USE_IOMMU, but that causes to fail all of the clients. > > > > > Note that it is possible for > > > these devices to malfunction even if initialization succeeds. A failure > > > to initialize can only happen if there's something wrong in the device > > > tree, firmware is missing (in case of VIC) or a regression was > > > introduced in some subsystem that causes a failure (maybe deferred probe > > > or something similar). > > > > A missing firmware is an actual good example. Though can't VIC driver be > > changed to load firmware at the time of a its first use by userspace? It > > should be very annoying that kernel driver forces you to churn with > > initramfs. > No, that's not really how firmware loading works. There's no technical > barrier to doing it, but it'd be strange. If a device needs firmware to > work, it'd be unusual to make it available before you know that it can > be used. > > What if the firmware can't be loaded at the time of the first use? How > do you report that back to userspace? -ENOENT because the firmware file > can't be found? How is userspace to know that this is a problem with > firmware loading rather than some other error having to do with the VIC > command stream being broken, for example? You'll have to check kernels log if there is some kernel-related failure in any case for the detailed information. > Modifying the initramfs is only necessary if you have the module built- > in or the module in the initramfs. If the module is in a root > filesystem, simply put the firmware there as well and you should be > good. This is all very standard Linux behaviour, nothing new or exotic > there. Having display driver built-in usually more preferable, it's not fun if kernel can't get to FS mount stage. > > > > > and the > > > > > device not showing up is a pretty good indicator that something is > > > > > wrong > > > > > as opposed to everything booting normally and then getting some > > > > > cryptic > > > > > error at runtime because one of the clients didn't initialize. > > > > > > > > If machine doesn't have a serial port and it doesn't have ssh server > > > > running or network doesn't come up, you'll end up with a completely > > > > dysfunctional piece of hardware. Hence there is no chance for you to > > > > even > > > > check what is wrong. The argument about a cryptic error doesn't make > > > > much > > > > sense, you have to improve your runtime as well (and you'll get a > > > > error > > > > message in the kernels log). > > > > > > You make a good point here. I'm not aware of any devices we support in > > > the kernel that don't have a serial console, but that doesn't mean the > > > kernel could be used on an "unsupported" device that doesn't have one. > > > > AFAIK, enabling serial on AC100 require soldering iron. > > > > > > > From my perspective, all clients should always be operational in > > > > > whatever baseline version you use. If it isn't that's a bug that > > > > > should > > > > > be fixed. Ideally those bugs should get fixed before making it into > > > > > a > > > > > baseline version (mainline, linux-next, ...), so that this never > > > > > impacts > > > > > even developers, unless they break it themsel
Re: [PATCH 0/2] staging: vboxvideo: Add page-flip support
On 08/06/2018 01:34 AM, Daniel Vetter wrote: On Fri, Jul 20, 2018 at 10:17:29AM -0700, Steve Longerbeam wrote: Adds crtc page-flip support by passing the new requested framebuffer to vbox_crtc_do_set_base(). There is no attempt to support vblank interrupts, so this page-flip implementation does not try to sync the page-flip to vertical blanking, so expect tearing effects. Is it possible to access the host vblank intervals in VBOX? I think it'd be great to move vboxvideo over to atomic instead, which is required for destaging anyway, and would give you page flip support for free. Hi Daniel, yes I agree vboxvideo needs to move to the DRM atomic framework. Steve Steve Longerbeam (2): staging: vboxvideo: Pass a new framebuffer to vbox_crtc_do_set_base staging: vboxvideo: Add page-flip support drivers/staging/vboxvideo/vbox_mode.c | 34 +++--- 1 file changed, 31 insertions(+), 3 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 1/4] dt-bindings: display: bridge: lvds-transmitter: add ti, ds90c185
Start list of actual chips compatible with "lvds-encoder". Reviewed-by: Laurent Pinchart Reviewed-by: Rob Herring Signed-off-by: Peter Rosin --- .../devicetree/bindings/display/bridge/lvds-transmitter.txt | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt index fd39ad34c383..50220190c203 100644 --- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt +++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt @@ -22,7 +22,13 @@ among others. Required properties: -- compatible: Must be "lvds-encoder" +- compatible: Must be one or more of the following + - "ti,ds90c185" for the TI DS90C185 FPD-Link Serializer + - "lvds-encoder" for a generic LVDS encoder device + + When compatible with the generic version, nodes must list the + device-specific version corresponding to the device first + followed by the generic version. Required nodes: -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/4] drm/meson: convert to the new canvas module
This removes the meson_canvas files within the meson/drm layer
and makes use of the new canvas module that is referenced in the dts.
Canvases can be used by different IPs and modules, and it is as such
preferable to rely on a module that can safely dispatch canvases on
demand.
Signed-off-by: Maxime Jourdan
Tested-by: Neil Armstrong
---
.../bindings/display/amlogic,meson-vpu.txt| 9 +--
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 7 +-
drivers/gpu/drm/meson/Kconfig | 1 +
drivers/gpu/drm/meson/Makefile| 2 +-
drivers/gpu/drm/meson/meson_canvas.c | 70 ---
drivers/gpu/drm/meson/meson_canvas.h | 42 ---
drivers/gpu/drm/meson/meson_crtc.c| 9 ++-
drivers/gpu/drm/meson/meson_drv.c | 22 ++
drivers/gpu/drm/meson/meson_drv.h | 5 +-
drivers/gpu/drm/meson/meson_plane.c | 3 +-
drivers/gpu/drm/meson/meson_viu.c | 1 -
11 files changed, 26 insertions(+), 145 deletions(-)
delete mode 100644 drivers/gpu/drm/meson/meson_canvas.c
delete mode 100644 drivers/gpu/drm/meson/meson_canvas.h
diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
index 057b81335775..60b6e1398636 100644
--- a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
+++ b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
@@ -60,9 +60,9 @@ Required properties:
- reg: base address and size of he following memory-mapped regions :
- vpu
- hhi
- - dmc
- reg-names: should contain the names of the previous memory regions
- interrupts: should contain the VENC Vsync interrupt number
+- amlogic,canvas: should point to a meson canvas provider node
Optional properties:
- power-domains: Optional phandle to associated power domain as described in
@@ -98,13 +98,14 @@ tv-connector {
vpu: vpu@d010 {
compatible = "amlogic,meson-gxbb-vpu";
reg = <0x0 0xd010 0x0 0x10>,
- <0x0 0xc883c000 0x0 0x1000>,
- <0x0 0xc8838000 0x0 0x1000>;
- reg-names = "vpu", "hhi", "dmc";
+ <0x0 0xc883c000 0x0 0x1000>;
+ reg-names = "vpu", "hhi";
interrupts = ;
#address-cells = <1>;
#size-cells = <0>;
+ amlogic,canvas = <&canvas>;
+
/* CVBS VDAC output port */
port@0 {
reg = <0>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index c98198662ae2..8b4dfe7dd4bb 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -503,13 +503,14 @@
vpu: vpu@d010 {
compatible = "amlogic,meson-gx-vpu";
reg = <0x0 0xd010 0x0 0x10>,
- <0x0 0xc883c000 0x0 0x1000>,
- <0x0 0xc8838000 0x0 0x1000>;
- reg-names = "vpu", "hhi", "dmc";
+ <0x0 0xc883c000 0x0 0x1000>;
+ reg-names = "vpu", "hhi";
interrupts = ;
#address-cells = <1>;
#size-cells = <0>;
+ amlogic,canvas = <&canvas>;
+
/* CVBS VDAC output port */
cvbs_vdac_port: port@0 {
reg = <0>;
diff --git a/drivers/gpu/drm/meson/Kconfig b/drivers/gpu/drm/meson/Kconfig
index 3ce51d8dfe1c..c28b69f48555 100644
--- a/drivers/gpu/drm/meson/Kconfig
+++ b/drivers/gpu/drm/meson/Kconfig
@@ -7,6 +7,7 @@ config DRM_MESON
select DRM_GEM_CMA_HELPER
select VIDEOMODE_HELPERS
select REGMAP_MMIO
+ select MESON_CANVAS
config DRM_MESON_DW_HDMI
tristate "HDMI Synopsys Controller support for Amlogic Meson Display"
diff --git a/drivers/gpu/drm/meson/Makefile b/drivers/gpu/drm/meson/Makefile
index c5c4cc362f02..bd67429185ff 100644
--- a/drivers/gpu/drm/meson/Makefile
+++ b/drivers/gpu/drm/meson/Makefile
@@ -1,5 +1,5 @@
meson-drm-y := meson_drv.o meson_plane.o meson_crtc.o meson_venc_cvbs.o
-meson-drm-y += meson_viu.o meson_vpp.o meson_venc.o meson_vclk.o meson_canvas.o
+meson-drm-y += meson_viu.o meson_vpp.o meson_venc.o meson_vclk.o
obj-$(CONFIG_DRM_MESON) += meson-drm.o
obj-$(CONFIG_DRM_MESON_DW_HDMI) += meson_dw_hdmi.o
diff --git a/drivers/gpu/drm/meson/meson_canvas.c
b/drivers/gpu/drm/meson/meson_canvas.c
deleted file mode 100644
index 08f6073d967e..
--- a/drivers/gpu/drm/meson/meson_canvas.c
+++ /dev/null
@@ -1,70 +0,0 @@
-/*
- * Copyright (C) 2016 BayLibre, SAS
- * Author: Neil Armstrong
- * Copyright (C) 2015 Amlogic, Inc. All rights reserved.
- * Copyright (C) 2014 Endless Mobile
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * pub
Re: [PATCH 2/2] drm/vkms: Compute CRC with Cursor Plane
On Tue, Aug 07, 2018 at 06:33:36PM +0200, Daniel Vetter wrote:
> On Mon, Aug 06, 2018 at 06:58:29AM +0300, Haneen Mohammed wrote:
> > This patch compute CRC for output frame with cursor and primary plane.
> > Blend cursor with primary plane and compute CRC on the resulted frame.
> >
> > Signed-off-by: Haneen Mohammed
>
> Nice!
>
> I assume with this you're passing all the crc based cursor tests in igt?
> If so, please mention this in the commit message, so that there's a record
> of the testing done on this.
>
Sure, I'll update the commit message.
Is there any other change I should add/fix to this patchset?
> One fairly huge gap we iirc have in our cursor testing is that there's not
> much (if any?) alpha blending coverage. We kinda need that to make sure
> this all works correctly. The usual trick is to only check the extreme
> alpha values, i.e. fully opaque and fully transparent, since intermediate
> values are affected by hw-specific rounding modes.
> > ---
> > drivers/gpu/drm/vkms/vkms_crc.c | 149 +-
> > drivers/gpu/drm/vkms/vkms_drv.h | 5 +-
> > drivers/gpu/drm/vkms/vkms_plane.c | 10 +-
> > 3 files changed, 137 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_crc.c
> > b/drivers/gpu/drm/vkms/vkms_crc.c
> > index 37d717f38e3c..4853a739ae5a 100644
> > --- a/drivers/gpu/drm/vkms/vkms_crc.c
> > +++ b/drivers/gpu/drm/vkms/vkms_crc.c
> > @@ -1,36 +1,137 @@
> > // SPDX-License-Identifier: GPL-2.0
> > #include "vkms_drv.h"
> > #include
> > +#include
> > +#include
> > #include
> >
> > -static uint32_t _vkms_get_crc(struct vkms_crc_data *crc_data)
> > +/**
> > + * compute_crc - Compute CRC value on output frame
> > + *
> > + * @vaddr_out: address to final framebuffer
> > + * @crc_out: framebuffer's metadata
> > + *
> > + * returns CRC value computed using crc32 on the visible portion of
> > + * the final framebuffer at vaddr_out
> > + */
> > +static uint32_t compute_crc(void *vaddr_out, struct vkms_crc_data *crc_out)
> > {
> > - struct drm_framebuffer *fb = &crc_data->fb;
> > + int i, src_offset;
> > + int x_src = crc_out->src.x1 >> 16;
> > + int y_src = crc_out->src.y1 >> 16;
> > + int h_src = drm_rect_height(&crc_out->src) >> 16;
> > + int w_src = drm_rect_width(&crc_out->src) >> 16;
> > + int size_byte = w_src * crc_out->cpp;
> > + u32 crc = 0;
> > +
> > + for (i = y_src; i < y_src + h_src; i++) {
> > + src_offset = crc_out->offset
> > ++ (i * crc_out->pitch)
> > ++ (x_src * crc_out->cpp);
> > + crc = crc32_le(crc, vaddr_out + src_offset, size_byte);
> > + }
> > +
> > + return crc;
> > +}
> > +
> > +/**
> > + * blend - belnd value at vaddr_src with value at vaddr_dst
> > + * @vaddr_dst: destination address
> > + * @vaddr_src: source address
> > + * @crc_dst: destination framebuffer's metadata
> > + * @crc_src: source framebuffer's metadata
> > + *
> > + * Blend value at vaddr_src with value at vaddr_dst.
> > + * Currently, this function write value at vaddr_src on value
> > + * at vaddr_dst using buffer's metadata to locate the new values
> > + * from vaddr_src and their distenation at vaddr_dst.
> > + *
> > + * Todo: Use the alpha value to blend vaddr_src with vaddr_dst
> > + * instead of overwriting it.
>
> Another todo: We must clear the alpha channel in the result after
> blending. This also applies to the primary plane, where the XRGB for the
> pixel format mandates that we entirely ignore the alpha channel.
>
> This is also something we should probably have an igt testcase for.
>
> Since there's a few open ends: How many weeks are left in your outreachy
> internship? We need to make sure that at least all the issues are covered
> in a vkms todo file. Would be great to add that in
> Documentation/gpu/vkms.rst, like we have for other drivers.
> -Daniel
>
I've one more week! I can use this week to prepare the todo file and
finalize this patch?
Thank you,
Haneen
> > + */
> > +static void blend(void *vaddr_dst, void *vaddr_src,
> > + struct vkms_crc_data *crc_dst,
> > + struct vkms_crc_data *crc_src)
> > +{
> > + int i, j, j_dst, i_dst;
> > + int offset_src, offset_dst;
> > +
> > + int x_src = crc_src->src.x1 >> 16;
> > + int y_src = crc_src->src.y1 >> 16;
> > +
> > + int x_dst = crc_src->dst.x1;
> > + int y_dst = crc_src->dst.y1;
> > + int h_dst = drm_rect_height(&crc_src->dst);
> > + int w_dst = drm_rect_width(&crc_src->dst);
> > +
> > + int y_limit = y_src + h_dst;
> > + int x_limit = x_src + w_dst;
> > +
> > + for (i = y_src, i_dst = y_dst; i < y_limit; ++i) {
> > + for (j = x_src, j_dst = x_dst; j < x_limit; ++j) {
> > + offset_dst = crc_dst->offset
> > ++ (i_dst * crc_dst->pitch)
> > ++ (j_dst++ * crc_dst->cpp);
> > + offset_src = crc_src->offset
> > +
Re: [PATCH] drm/i915/kvmgt: Fix potential Spectre v1
Hi Zhenyu, On 8/6/18 9:26 PM, Zhenyu Wang wrote: > On 2018.08.02 22:40:19 -0500, Gustavo A. R. Silva wrote: >> info.index can be indirectly controlled by user-space, hence leading >> to a potential exploitation of the Spectre variant 1 vulnerability. >> >> This issue was detected with the help of Smatch: >> >> drivers/gpu/drm/i915/gvt/kvmgt.c:1232 intel_vgpu_ioctl() warn: >> potential spectre issue 'vgpu->vdev.region' [r] >> >> Fix this by sanitizing info.index before indirectly using it to index >> vgpu->vdev.region > > Thanks for catching this! Applied. > Glad to help. :) Thanks -- Gustavo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 0/5] drm/mxsfb: Fix runtime PM for unpowering lcdif block
Adding lcdif nodes to a power domain currently does work, it results in black/corrupted screens or hangs. While the driver does enable runtime pm it does not deal correctly with the block being unpowered. Changes since v3: * Don't set initial fb in mode_set_nofb, do it in crtc_enable * Simplify AXI clk handling to allow setting fb in crtc_enable * No functional changes Last 3 patches are identical to v3 with review tags attached. Link to v3: https://lkml.org/lkml/2018/8/6/728 Leonard Crestez (5): drm/mxsfb: Move axi clk enable/disable to crtc enable/disable drm/mxsfb: Fix initial corrupt frame when activating display drm/mxsfb: Add pm_runtime calls to pipe_enable/disable drm/mxsfb: Add PM_SLEEP support drm/mxsfb: Switch to drm_atomic_helper_commit_tail_rpm drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 53 +++--- drivers/gpu/drm/mxsfb/mxsfb_drv.c | 40 ++ 2 files changed, 74 insertions(+), 19 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/5] drm/mxsfb: Fix initial corrupt frame when activating display
LCDIF will repeatedly display data from CUR_BUF and set CUR_BUF to
NEXT_BUF when done. Since we are only ever writing to NEXT_BUF the
display will show an initial corrupt frame.
Fix by writing the FB paddr to both CUR_BUF and NEXT_BUF when
activating the CRTC.
Signed-off-by: Leonard Crestez
Tested-by: Philipp Zabel
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 45 +-
1 file changed, 32 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index e4fcbb65b969..24b1f0c1432e 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -191,10 +191,25 @@ static int mxsfb_reset_block(void __iomem *reset_addr)
return ret;
return clear_poll_bit(reset_addr, MODULE_CLKGATE);
}
+static dma_addr_t mxsfb_get_fb_paddr(struct mxsfb_drm_private *mxsfb)
+{
+ struct drm_framebuffer *fb = mxsfb->pipe.plane.state->fb;
+ struct drm_gem_cma_object *gem;
+
+ if (!fb)
+ return 0;
+
+ gem = drm_fb_cma_get_gem_obj(fb, 0);
+ if (!gem)
+ return 0;
+
+ return gem->paddr;
+}
+
static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb)
{
struct drm_display_mode *m = &mxsfb->pipe.crtc.state->adjusted_mode;
const u32 bus_flags = mxsfb->connector.display_info.bus_flags;
u32 vdctrl0, vsync_pulse_len, hsync_pulse_len;
@@ -267,12 +282,22 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
mxsfb->base + LCDC_VDCTRL4);
}
void mxsfb_crtc_enable(struct mxsfb_drm_private *mxsfb)
{
+ dma_addr_t paddr;
+
mxsfb_enable_axi_clk(mxsfb);
mxsfb_crtc_mode_set_nofb(mxsfb);
+
+ /* Write cur_buf as well to avoid an initial corrupt frame */
+ paddr = mxsfb_get_fb_paddr(mxsfb);
+ if (paddr) {
+ writel(paddr, mxsfb->base + mxsfb->devdata->cur_buf);
+ writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
+ }
+
mxsfb_enable_controller(mxsfb);
}
void mxsfb_crtc_disable(struct mxsfb_drm_private *mxsfb)
{
@@ -283,16 +308,12 @@ void mxsfb_crtc_disable(struct mxsfb_drm_private *mxsfb)
void mxsfb_plane_atomic_update(struct mxsfb_drm_private *mxsfb,
struct drm_plane_state *state)
{
struct drm_simple_display_pipe *pipe = &mxsfb->pipe;
struct drm_crtc *crtc = &pipe->crtc;
- struct drm_framebuffer *fb = pipe->plane.state->fb;
struct drm_pending_vblank_event *event;
- struct drm_gem_cma_object *gem;
-
- if (!crtc)
- return;
+ dma_addr_t paddr;
spin_lock_irq(&crtc->dev->event_lock);
event = crtc->state->event;
if (event) {
crtc->state->event = NULL;
@@ -303,14 +324,12 @@ void mxsfb_plane_atomic_update(struct mxsfb_drm_private
*mxsfb,
drm_crtc_send_vblank_event(crtc, event);
}
}
spin_unlock_irq(&crtc->dev->event_lock);
- if (!fb)
- return;
-
- gem = drm_fb_cma_get_gem_obj(fb, 0);
-
- mxsfb_enable_axi_clk(mxsfb);
- writel(gem->paddr, mxsfb->base + mxsfb->devdata->next_buf);
- mxsfb_disable_axi_clk(mxsfb);
+ paddr = mxsfb_get_fb_paddr(mxsfb);
+ if (paddr) {
+ mxsfb_enable_axi_clk(mxsfb);
+ writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
+ mxsfb_disable_axi_clk(mxsfb);
+ }
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: simple: fix -Wliteral-conversion warning
bumping for review.
On Fri, Jun 15, 2018 at 3:38 PM Nick Desaulniers
wrote:
>
> Fixes commit 8cfe83419cdb ("drm/panel: simple: Add
> support for KEO TX31D200VM0BAA")
>
> drivers/gpu/drm/panel/panel-simple.c:1250:27: warning: implicit conversion
> from
> 'double' to 'u32' (aka 'unsigned int') changes value from 33.5 to 33
> [-Wliteral-conversion]
> .vfront_porch = { 6, 21, 33.5 },
> ~^~~~
> drivers/gpu/drm/panel/panel-simple.c:1251:26: warning: implicit conversion
> from
> 'double' to 'u32' (aka 'unsigned int') changes value from 33.5 to 33
> [-Wliteral-conversion]
> .vback_porch = { 6, 21, 33.5 },
>~^~~~
>
> Signed-off-by: Nick Desaulniers
> ---
> Alternatively, should these be rounded up to 34? I'm guessing the
> current behaviour (truncation) is correct since that's how the patch was
> operating.
>
> drivers/gpu/drm/panel/panel-simple.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index cbf1ab404ee7..12bcbd1dd77b 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1247,8 +1247,8 @@ static const struct display_timing
> koe_tx31d200vm0baa_timing = {
> .hback_porch = { 16, 36, 56 },
> .hsync_len = { 8, 8, 8 },
> .vactive = { 480, 480, 480 },
> - .vfront_porch = { 6, 21, 33.5 },
> - .vback_porch = { 6, 21, 33.5 },
> + .vfront_porch = { 6, 21, 33 },
> + .vback_porch = { 6, 21, 33 },
> .vsync_len = { 8, 8, 8 },
> .flags = DISPLAY_FLAGS_DE_HIGH,
> };
> --
> 2.18.0.rc1.244.gcf134e6275-goog
>
--
Thanks,
~Nick Desaulniers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/meson: convert to the new canvas module
2018-08-10 0:41 GMT+02:00 Rob Herring : > Hi, this is an automated email from Rob's (experimental) review bot. I > found a couple of common problems with your patch. Please see below. > > On Wed, 1 Aug 2018 20:51:28 +0200, Maxime Jourdan wrote: >> This removes the meson_canvas files within the meson/drm layer >> and makes use of the new canvas module that is referenced in the dts. >> >> Canvases can be used by different IPs and modules, and it is as such >> preferable to rely on a module that can safely dispatch canvases on >> demand. >> >> Signed-off-by: Maxime Jourdan > > The preferred subject prefix is "dt-bindings: : ...". > >> --- >> .../bindings/display/amlogic,meson-vpu.txt| 9 +-- >> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 7 +- >> drivers/gpu/drm/meson/Kconfig | 1 + >> drivers/gpu/drm/meson/Makefile| 2 +- >> drivers/gpu/drm/meson/meson_canvas.c | 70 --- >> drivers/gpu/drm/meson/meson_canvas.h | 42 --- >> drivers/gpu/drm/meson/meson_crtc.c| 5 +- >> drivers/gpu/drm/meson/meson_drv.c | 35 ++ >> drivers/gpu/drm/meson/meson_drv.h | 5 +- >> drivers/gpu/drm/meson/meson_plane.c | 3 +- >> drivers/gpu/drm/meson/meson_viu.c | 1 - >> 11 files changed, 39 insertions(+), 141 deletions(-) >> delete mode 100644 drivers/gpu/drm/meson/meson_canvas.c >> delete mode 100644 drivers/gpu/drm/meson/meson_canvas.h >> > > DT bindings (including binding headers) should be a separate patch. See > Documentation/devicetree/bindings/submitting-patches.txt. > Hi, What's the standard procedure here ? The reason I kept devicetree+drm changes together is because I didn't want to have floating commits that would break the drm module. Should I split the changes anyway ? Maxime ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] gpu: host1x: Cancel only job that actually got stuck
Host1x doesn't have information about jobs inter-dependency, that is
something that will become available once host1x will get a proper
jobs scheduler implementation. Currently a hang job causes other unrelated
jobs to be canceled, that is a relic from downstream driver which is
irrelevant to upstream. Let's cancel only the hanging job and not to touch
other jobs in queue.
Signed-off-by: Dmitry Osipenko
Reviewed-by: Mikko Perttunen
---
drivers/gpu/host1x/cdma.c | 33 +++--
1 file changed, 7 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
index 91df51e631b2..75f339f5df6f 100644
--- a/drivers/gpu/host1x/cdma.c
+++ b/drivers/gpu/host1x/cdma.c
@@ -348,13 +348,11 @@ void host1x_cdma_update_sync_queue(struct host1x_cdma
*cdma,
}
/*
-* Walk the sync_queue, first incrementing with the CPU syncpts that
-* are partially executed (the first buffer) or fully skipped while
-* still in the current context (slots are also NOP-ed).
+* Increment with CPU the remaining syncpts of a partially executed job.
*
-* At the point contexts are interleaved, syncpt increments must be
-* done inline with the pushbuffer from a GATHER buffer to maintain
-* the order (slots are modified to be a GATHER of syncpt incrs).
+* Syncpt increments must be done inline with the pushbuffer from a
+* GATHER buffer to maintain the order (slots are modified to be a
+* GATHER of syncpt incrs).
*
* Note: save in restart_addr the location where the timed out buffer
* started in the PB, so we can start the refetch from there (with the
@@ -362,20 +360,15 @@ void host1x_cdma_update_sync_queue(struct host1x_cdma
*cdma,
* properly for this buffer and resources are freed.
*/
- dev_dbg(dev, "%s: perform CPU incr on pending same ctx buffers\n",
- __func__);
+ dev_dbg(dev, "%s: perform CPU incr on pending buffers\n", __func__);
if (!list_empty(&cdma->sync_queue))
restart_addr = job->first_get;
else
restart_addr = cdma->last_pos;
- /* do CPU increments as long as this context continues */
- list_for_each_entry_from(job, &cdma->sync_queue, list) {
- /* different context, gets us out of this loop */
- if (job->client != cdma->timeout.client)
- break;
-
+ /* do CPU increments for the remaining syncpts */
+ if (job) {
/* won't need a timeout when replayed */
job->timeout = 0;
@@ -388,20 +381,8 @@ void host1x_cdma_update_sync_queue(struct host1x_cdma
*cdma,
host1x_hw_cdma_timeout_cpu_incr(host1x, cdma, job->first_get,
syncpt_incrs, job->syncpt_end,
job->num_slots);
-
- syncpt_val += syncpt_incrs;
}
- /*
-* The following sumbits from the same client may be dependent on the
-* failed submit and therefore they may fail. Force a small timeout
-* to make the queue cleanup faster.
-*/
-
- list_for_each_entry_from(job, &cdma->sync_queue, list)
- if (job->client == cdma->timeout.client)
- job->timeout = min_t(unsigned int, job->timeout, 500);
-
dev_dbg(dev, "%s: finished sync_queue modification\n", __func__);
/* roll back DMAGET and start up channel again */
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 5/5] drm/mxsfb: Switch to drm_atomic_helper_commit_tail_rpm
The lcdif block is only powered on when display is active so plane
updates when not enabled are not valid. Writing to an unpowered IP block
is mostly ignored but can trigger bus errors on some chips.
Prevent this situation by switching to drm_atomic_helper_commit_tail_rpm
and having the drm core ensure atomic_plane_update is only called while
the crtc is active. This avoids having to keep track of "enabled" bits
inside the mxsfb driver.
This also requires handling the vblank event for disable from
mxsfb_pipe_update.
Signed-off-by: Leonard Crestez
Suggested-by: Stefan Agner
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index d797dfd40d98..5777e730085b 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -96,10 +96,14 @@ static const struct drm_mode_config_funcs
mxsfb_mode_config_funcs = {
.fb_create = drm_gem_fb_create,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
};
+static const struct drm_mode_config_helper_funcs mxsfb_mode_config_helpers = {
+ .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
+};
+
static void mxsfb_pipe_enable(struct drm_simple_display_pipe *pipe,
struct drm_crtc_state *crtc_state,
struct drm_plane_state *plane_state)
{
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
@@ -113,15 +117,25 @@ static void mxsfb_pipe_enable(struct
drm_simple_display_pipe *pipe,
static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
{
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
struct drm_device *drm = pipe->plane.dev;
+ struct drm_crtc *crtc = &pipe->crtc;
+ struct drm_pending_vblank_event *event;
drm_panel_disable(mxsfb->panel);
mxsfb_crtc_disable(mxsfb);
drm_panel_unprepare(mxsfb->panel);
pm_runtime_put_sync(drm->dev);
+
+ spin_lock_irq(&drm->event_lock);
+ event = crtc->state->event;
+ if (event) {
+ crtc->state->event = NULL;
+ drm_crtc_send_vblank_event(crtc, event);
+ }
+ spin_unlock_irq(&drm->event_lock);
}
static void mxsfb_pipe_update(struct drm_simple_display_pipe *pipe,
struct drm_plane_state *plane_state)
{
@@ -232,10 +246,11 @@ static int mxsfb_load(struct drm_device *drm, unsigned
long flags)
drm->mode_config.min_width = MXSFB_MIN_XRES;
drm->mode_config.min_height = MXSFB_MIN_YRES;
drm->mode_config.max_width = MXSFB_MAX_XRES;
drm->mode_config.max_height = MXSFB_MAX_YRES;
drm->mode_config.funcs = &mxsfb_mode_config_funcs;
+ drm->mode_config.helper_private = &mxsfb_mode_config_helpers;
drm_mode_config_reset(drm);
pm_runtime_get_sync(drm->dev);
ret = drm_irq_install(drm, platform_get_irq(pdev, 0));
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH v4 2/2] drm/tegra: plane: Add generic colorkey properties for older Tegra's
For the starter a minimal color keying support is implemented, which is
enough to provide userspace like Opentegra Xorg driver with ability to
support color keying by the XVideo extension. Blending controls interface
changed on newer Tegra's, this patch provides color keying support for
Tegra20/30/114 only.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/dc.c| 25 ++
drivers/gpu/drm/tegra/dc.h| 7 ++
drivers/gpu/drm/tegra/plane.c | 156 ++
3 files changed, 188 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 965088afcfad..7e90df036c48 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -162,6 +162,7 @@ static void tegra_plane_setup_blending_legacy(struct
tegra_plane *plane)
u32 foreground = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255) |
BLEND_COLOR_KEY_NONE;
u32 blendnokey = BLEND_WEIGHT1(255) | BLEND_WEIGHT0(255);
+ enum drm_plane_colorkey_mode mode;
struct tegra_plane_state *state;
u32 blending[2];
unsigned int i;
@@ -171,7 +172,15 @@ static void tegra_plane_setup_blending_legacy(struct
tegra_plane *plane)
tegra_plane_writel(plane, foreground, DC_WIN_BLEND_1WIN);
state = to_tegra_plane_state(plane->base.state);
+ mode = plane->base.state->colorkey.mode;
+ /* setup color keying */
+ if (mode == DRM_PLANE_COLORKEY_MODE_TRANSPARENT) {
+ /* color key matched areas are transparent */
+ foreground = background[0] | BLEND_COLOR_KEY_0;
+ }
+
+ /* setup alpha blending */
if (state->opaque) {
/*
* Since custom fix-weight blending isn't utilized and weight
@@ -792,6 +801,11 @@ static struct drm_plane *tegra_primary_plane_create(struct
drm_device *drm,
dev_err(dc->dev, "failed to create rotation property: %d\n",
err);
+ if (dc->soc->has_legacy_blending)
+ drm_plane_create_colorkey_properties(&plane->base,
+ BIT(DRM_PLANE_COLORKEY_MODE_DISABLED) |
+ BIT(DRM_PLANE_COLORKEY_MODE_TRANSPARENT));
+
return &plane->base;
}
@@ -1077,6 +1091,11 @@ static struct drm_plane
*tegra_dc_overlay_plane_create(struct drm_device *drm,
dev_err(dc->dev, "failed to create rotation property: %d\n",
err);
+ if (dc->soc->has_legacy_blending)
+ drm_plane_create_colorkey_properties(&plane->base,
+ BIT(DRM_PLANE_COLORKEY_MODE_DISABLED) |
+ BIT(DRM_PLANE_COLORKEY_MODE_TRANSPARENT));
+
return &plane->base;
}
@@ -1187,6 +1206,7 @@ tegra_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
copy->pclk = state->pclk;
copy->div = state->div;
copy->planes = state->planes;
+ copy->ckey = state->ckey;
return ©->base;
}
@@ -1917,6 +1937,11 @@ static void tegra_crtc_atomic_flush(struct drm_crtc
*crtc,
struct tegra_dc *dc = to_tegra_dc(crtc);
u32 value;
+ if (dc->soc->has_legacy_blending) {
+ tegra_dc_writel(dc, state->ckey.min, DC_DISP_COLOR_KEY0_LOWER);
+ tegra_dc_writel(dc, state->ckey.max, DC_DISP_COLOR_KEY0_UPPER);
+ }
+
value = state->planes << 8 | GENERAL_UPDATE;
tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
value = tegra_dc_readl(dc, DC_CMD_STATE_CONTROL);
diff --git a/drivers/gpu/drm/tegra/dc.h b/drivers/gpu/drm/tegra/dc.h
index e96f582ca692..14ed31f0ff37 100644
--- a/drivers/gpu/drm/tegra/dc.h
+++ b/drivers/gpu/drm/tegra/dc.h
@@ -18,6 +18,11 @@
struct tegra_output;
+struct tegra_dc_color_key_state {
+ u32 min;
+ u32 max;
+};
+
struct tegra_dc_state {
struct drm_crtc_state base;
@@ -26,6 +31,8 @@ struct tegra_dc_state {
unsigned int div;
u32 planes;
+
+ struct tegra_dc_color_key_state ckey;
};
static inline struct tegra_dc_state *to_dc_state(struct drm_crtc_state *state)
diff --git a/drivers/gpu/drm/tegra/plane.c b/drivers/gpu/drm/tegra/plane.c
index d068e8aa3553..0823deef8d03 100644
--- a/drivers/gpu/drm/tegra/plane.c
+++ b/drivers/gpu/drm/tegra/plane.c
@@ -465,6 +465,158 @@ static int tegra_plane_setup_transparency(struct
tegra_plane *tegra,
return 0;
}
+static u32 tegra_plane_colorkey_to_hw_format(u64 drm_ckey64)
+{
+ /* convert ARGB16161616 to ARGB */
+ u8 a = drm_colorkey_extract_component(drm_ckey64, alpha, 8);
+ u8 r = drm_colorkey_extract_component(drm_ckey64, red, 8);
+ u8 g = drm_colorkey_extract_component(drm_ckey64, green, 8);
+ u8 b = drm_colorkey_extract_component(drm_ckey64, blue, 8);
+
+ return (a << 24) | (r << 16) | (g << 8) | b;
+}
+
+static bool tegra_plane_format_valid_for_colorkey(struct drm_plane_state
*state)
+{
+ struct
[RFC PATCH v4 1/2] drm: Add generic colorkey properties for display planes
From: Laurent Pinchart
Color keying is the action of replacing pixels matching a given color
(or range of colors) with transparent pixels in an overlay when
performing blitting. Depending on the hardware capabilities, the
matching pixel can either become fully transparent or gain adjustment
of the pixels component values.
Color keying is found in a large number of devices whose capabilities
often differ, but they still have enough common features in range to
standardize color key properties. This commit adds new generic DRM plane
properties related to the color keying, providing initial color keying
support.
Signed-off-by: Laurent Pinchart
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_atomic.c | 20 +
drivers/gpu/drm/drm_blend.c | 150 +++
include/drm/drm_blend.h | 3 +
include/drm/drm_plane.h | 91 +
4 files changed, 264 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3eb061e11e2e..e97364966f6d 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -904,6 +904,16 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
state->rotation = val;
} else if (property == plane->zpos_property) {
state->zpos = val;
+ } else if (property == plane->colorkey.plane_mask_property) {
+ state->colorkey.plane_mask = val;
+ } else if (property == plane->colorkey.mode_property) {
+ state->colorkey.mode = val;
+ } else if (property == plane->colorkey.mask_property) {
+ state->colorkey.mask = val;
+ } else if (property == plane->colorkey.min_property) {
+ state->colorkey.min = val;
+ } else if (property == plane->colorkey.max_property) {
+ state->colorkey.max = val;
} else if (property == plane->color_encoding_property) {
state->color_encoding = val;
} else if (property == plane->color_range_property) {
@@ -972,6 +982,16 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->rotation;
} else if (property == plane->zpos_property) {
*val = state->zpos;
+ } else if (property == plane->colorkey.plane_mask_property) {
+ *val = state->colorkey.plane_mask;
+ } else if (property == plane->colorkey.mode_property) {
+ *val = state->colorkey.mode;
+ } else if (property == plane->colorkey.mask_property) {
+ *val = state->colorkey.mask;
+ } else if (property == plane->colorkey.min_property) {
+ *val = state->colorkey.min;
+ } else if (property == plane->colorkey.max_property) {
+ *val = state->colorkey.max;
} else if (property == plane->color_encoding_property) {
*val = state->color_encoding;
} else if (property == plane->color_range_property) {
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index a16a74d7e15e..13c61dd0d9b7 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -107,6 +107,11 @@
* planes. Without this property the primary plane is always below the
cursor
* plane, and ordering between all other planes is undefined.
*
+ * colorkey:
+ * Color keying is set up with drm_plane_create_colorkey_properties().
+ * It adds support for actions like replacing a range of colors with a
+ * transparent color in the plane. Color keying is disabled by default.
+ *
* Note that all the property extensions described here apply either to the
* plane or the CRTC (e.g. for the background color, which currently is not
* exposed and assumed to be black).
@@ -448,3 +453,148 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,
return 0;
}
EXPORT_SYMBOL(drm_atomic_normalize_zpos);
+
+static const char * const plane_colorkey_mode_name[] = {
+ [DRM_PLANE_COLORKEY_MODE_DISABLED] = "disabled",
+ [DRM_PLANE_COLORKEY_MODE_TRANSPARENT] = "transparent",
+};
+
+/**
+ * drm_plane_create_colorkey_properties - create colorkey properties
+ * @plane: drm plane
+ * @supported_modes: bitmask of supported color keying modes
+ *
+ * This function creates the generic color keying properties and attaches them
+ * to the @plane to enable color keying control for blending operations.
+ *
+ * Glossary:
+ *
+ * Destination plane:
+ * Plane to which color keying properties are applied, this planes takes
+ * the effect of color keying operation. The effect is determined by a
+ * given color keying mode.
+ *
+ * Source plane:
+ * Pixels of this plane are the source for color key matching operation.
+ *
+ * Color keying is controlled by these properties:
+ *
+ * colorkey.plane_mask:
+ * The mask property specifies which planes participate in color key
+ * matching process, these planes are the color key sources.
+ *
+ * Driv
[PATCH v4 4/5] drm/mxsfb: Add PM_SLEEP support
Since power to the lcdif block can be lost on suspend implement
PM_SLEEP_OPS using drm_mode_config_helper_suspend/resume to save/restore
the current mode.
Signed-off-by: Leonard Crestez
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 68d79f5dc0d3..d797dfd40d98 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -416,17 +416,38 @@ static int mxsfb_remove(struct platform_device *pdev)
drm_dev_unref(drm);
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int mxsfb_suspend(struct device *dev)
+{
+ struct drm_device *drm = dev_get_drvdata(dev);
+
+ return drm_mode_config_helper_suspend(drm);
+}
+
+static int mxsfb_resume(struct device *dev)
+{
+ struct drm_device *drm = dev_get_drvdata(dev);
+
+ return drm_mode_config_helper_resume(drm);
+}
+#endif
+
+static const struct dev_pm_ops mxsfb_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(mxsfb_suspend, mxsfb_resume)
+};
+
static struct platform_driver mxsfb_platform_driver = {
.probe = mxsfb_probe,
.remove = mxsfb_remove,
.id_table = mxsfb_devtype,
.driver = {
.name = "mxsfb",
.of_match_table = mxsfb_dt_ids,
+ .pm = &mxsfb_pm_ops,
},
};
module_platform_driver(mxsfb_platform_driver);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: sn65dsi86: Implement AUX channel
Hi Sean,
Thanks for your patch.
I also made this similar change as part of my PSR support changes (yet
to be posted for review). But since this patch is posted now, i will
pick this for my PSR changes.
On 2018-08-09 03:23, Sean Paul wrote:
This was hand-rolled in the first version, and will surely be useful as
we expand the driver to support more varied use cases.
Cc: Sandeep Panda
Signed-off-by: Sean Paul
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 107 --
1 file changed, 100 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 1b6e8b72be58..50aa8c3c39fc 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -7,12 +7,14 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -29,12 +31,15 @@
#define SN_DATARATE_CONFIG_REG 0x94
#define SN_PLL_ENABLE_REG 0x0D
#define SN_SCRAMBLE_CONFIG_REG 0x95
-#define SN_AUX_WDATA0_REG 0x64
+#define SN_AUX_WDATA_REG(x)(0x64 + x)
#define SN_AUX_ADDR_19_16_REG 0x74
#define SN_AUX_ADDR_15_8_REG 0x75
#define SN_AUX_ADDR_7_0_REG0x76
#define SN_AUX_LENGTH_REG 0x77
#define SN_AUX_CMD_REG 0x78
+#define AUX_CMD_SEND 0x01
+#define AUX_CMD_REQ(x)(x << 4)
+#define SN_AUX_RDATA_REG(x)(0x79 + x)
#define SN_ML_TX_MODE_REG 0x96
/* video config specific registers */
#define SN_CHA_ACTIVE_LINE_LENGTH_LOW_REG 0x20
@@ -64,6 +69,9 @@
#define SN_DP_DATA_RATE_OFFSET 5
#define SN_SYNC_POLARITY_OFFSET7
+/* Matches DP_AUX_MAX_PAYLOAD_BYTES (for now) */
+#define SN_AUX_MAX_PAYLOAD_BYTES 16
+
#define SN_ENABLE_VID_STREAM_BIT BIT(3)
#define SN_REFCLK_FREQ_BITSGENMASK(3, 1)
#define SN_DSIA_NUM_LANES_BITS GENMASK(4, 3)
@@ -76,6 +84,7 @@
struct ti_sn_bridge {
struct device *dev;
struct regmap *regmap;
+ struct drm_dp_aux aux;
struct drm_bridge bridge;
struct drm_connectorconnector;
struct device_node *host_node;
@@ -473,12 +482,7 @@ static void ti_sn_bridge_enable(struct drm_bridge
*bridge)
* authentication method. We need to enable this method in the eDP
panel
* at DisplayPort address 0x0010A prior to link training.
*/
- regmap_write(pdata->regmap, SN_AUX_WDATA0_REG, 0x01);
- regmap_write(pdata->regmap, SN_AUX_ADDR_19_16_REG, 0x00);
- regmap_write(pdata->regmap, SN_AUX_ADDR_15_8_REG, 0x01);
- regmap_write(pdata->regmap, SN_AUX_ADDR_7_0_REG, 0x0A);
- regmap_write(pdata->regmap, SN_AUX_LENGTH_REG, 0x01);
- regmap_write(pdata->regmap, SN_AUX_CMD_REG, 0x81);
+ drm_dp_dpcd_writeb(&pdata->aux, DP_EDP_CONFIGURATION_SET, 0);
I think the last argument here should be 0x1 instead of 0. or better put
it as DP_ALTERNATE_SCRAMBLER_RESET_ENABLE.
usleep_range(1, 10500); /* 10ms delay recommended by spec */
We can remove this usleep now, as you are already ensuring in the
newly added function that aux transaction is successful.
/* Semi auto link training mode */
@@ -527,6 +531,90 @@ static const struct drm_bridge_funcs
ti_sn_bridge_funcs = {
.post_disable = ti_sn_bridge_post_disable,
};
+static struct ti_sn_bridge *aux_to_ti_sn_bridge(struct drm_dp_aux
*aux)
+{
+ return container_of(aux, struct ti_sn_bridge, aux);
+}
+
+static bool ti_sn_cmd_done(struct ti_sn_bridge *pdata)
+{
+ int ret;
+ unsigned int val;
+
+ ret = regmap_read(pdata->regmap, SN_AUX_CMD_REG, &val);
Can we read back register offset 0xF4, instead of 0x78, to check if AUX
transaction was success or any error has occurred.
+ WARN_ON(ret);
+ return ret || !(val & AUX_CMD_SEND);
+}
+
+static ssize_t ti_sn_aux_transfer(struct drm_dp_aux *aux,
+ struct drm_dp_aux_msg *msg)
+{
+ struct ti_sn_bridge *pdata = aux_to_ti_sn_bridge(aux);
+ u32 request = msg->request & ~DP_AUX_I2C_MOT;
+ u32 request_val = AUX_CMD_REQ(msg->request);
+ u8 *buf = (u8 *)msg->buffer;
+ bool cmd_done;
+ int ret, i;
+
+ if (msg->size > SN_AUX_MAX_PAYLOAD_BYTES)
+ return -EINVAL;
+
+ switch (request) {
+ case DP_AUX_NATIVE_WRITE:
+ case DP_AUX_I2C_WRITE:
+ case DP_AUX_NATIVE_READ:
+ case DP_AUX_I2C_READ:
+ regmap_write(pdata->regmap, SN_AUX_CMD_REG, request_val);
This regmap_write is not needed since you will be writing it again
towards the end of this function.
+
Re: [PATCH v7 3/3] drm/atmel-hlcdc: support bus-width (12/16/18/24) in endpoint nodes
On 2018-08-04 13:14, Peter Rosin wrote:
> This beats the heuristic that the connector is involved in what format
> should be output for cases where this fails.
Sorry to reply to self, but...
> E.g. if there is a bridge that changes format between the encoder and the
> connector, or if some of the RGB pins between the lcd controller and the
> encoder are not routed on the PCB.
>
> This is critical for the devices that have the "conflicting output
> formats" issue (SAM9N12, SAM9X5, SAMA5D3), since the most significant
> RGB bits move around depending on the selected output mode. For
> devices that do not have the "conflicting output formats" issue
> (SAMA5D2, SAMA5D4), this is completely irrelevant.
>
> Acked-by: Boris Brezillon
> Reviewed-by: Jacopo Mondi
> Signed-off-by: Peter Rosin
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 70
> +---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 1 +
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 70
> +---
> 3 files changed, 114 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index d73281095fac..c38a479ada98 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> @@ -226,6 +226,55 @@ static void atmel_hlcdc_crtc_atomic_enable(struct
> drm_crtc *c,
> #define ATMEL_HLCDC_RGB888_OUTPUTBIT(3)
> #define ATMEL_HLCDC_OUTPUT_MODE_MASK GENMASK(3, 0)
>
> +static int atmel_hlcdc_connector_output_mode(struct drm_connector_state
> *state)
> +{
> + struct drm_connector *connector = state->connector;
> + struct drm_display_info *info = &connector->display_info;
> + struct drm_encoder *encoder;
> + unsigned int supported_fmts = 0;
> + int j;
> +
> + encoder = state->best_encoder;
> + if (!encoder)
> + encoder = connector->encoder;
> +
> + switch (atmel_hlcdc_encoder_get_bus_fmt(encoder)) {
> + case 0:
> + break;
> + case MEDIA_BUS_FMT_RGB444_1X12:
> + return ATMEL_HLCDC_RGB444_OUTPUT;
> + case MEDIA_BUS_FMT_RGB565_1X16:
> + return ATMEL_HLCDC_RGB565_OUTPUT;
> + case MEDIA_BUS_FMT_RGB666_1X18:
> + return ATMEL_HLCDC_RGB666_OUTPUT;
> + case MEDIA_BUS_FMT_RGB888_1X24:
> + return ATMEL_HLCDC_RGB888_OUTPUT;
> + default:
> + return -EINVAL;
> + }
> +
> + for (j = 0; j < info->num_bus_formats; j++) {
> + switch (info->bus_formats[j]) {
> + case MEDIA_BUS_FMT_RGB444_1X12:
> + supported_fmts |= ATMEL_HLCDC_RGB444_OUTPUT;
> + break;
> + case MEDIA_BUS_FMT_RGB565_1X16:
> + supported_fmts |= ATMEL_HLCDC_RGB565_OUTPUT;
> + break;
> + case MEDIA_BUS_FMT_RGB666_1X18:
> + supported_fmts |= ATMEL_HLCDC_RGB666_OUTPUT;
> + break;
> + case MEDIA_BUS_FMT_RGB888_1X24:
> + supported_fmts |= ATMEL_HLCDC_RGB888_OUTPUT;
> + break;
> + default:
> + break;
> + }
> + }
> +
> + return supported_fmts;
> +}
> +
> static int atmel_hlcdc_crtc_select_output_mode(struct drm_crtc_state *state)
> {
> unsigned int output_fmts = ATMEL_HLCDC_OUTPUT_MODE_MASK;
> @@ -238,31 +287,12 @@ static int atmel_hlcdc_crtc_select_output_mode(struct
> drm_crtc_state *state)
> crtc = drm_crtc_to_atmel_hlcdc_crtc(state->crtc);
>
> for_each_new_connector_in_state(state->state, connector, cstate, i) {
> - struct drm_display_info *info = &connector->display_info;
> unsigned int supported_fmts = 0;
> - int j;
>
> if (!cstate->crtc)
> continue;
>
> - for (j = 0; j < info->num_bus_formats; j++) {
> - switch (info->bus_formats[j]) {
> - case MEDIA_BUS_FMT_RGB444_1X12:
> - supported_fmts |= ATMEL_HLCDC_RGB444_OUTPUT;
> - break;
> - case MEDIA_BUS_FMT_RGB565_1X16:
> - supported_fmts |= ATMEL_HLCDC_RGB565_OUTPUT;
> - break;
> - case MEDIA_BUS_FMT_RGB666_1X18:
> - supported_fmts |= ATMEL_HLCDC_RGB666_OUTPUT;
> - break;
> - case MEDIA_BUS_FMT_RGB888_1X24:
> - supported_fmts |= ATMEL_HLCDC_RGB888_OUTPUT;
> - break;
> - default:
> - break;
> - }
> - }
> + supported_fmts = atmel_hlcdc_connector_output_mode(cstate);
>
> if (crtc->dc->desc->conflicting_output_fo
[RFC PATCH v4 0/2] drm: Add generic colorkey plane properties
Changes in v4: 1) In response to Ville's Syrjälä review comments: - Added new "colorkey.plane_mask" property that specifies which planes shall participate in color key matching operation. - Added short glossary-comment to drm_plane_create_colorkey_properties() that clarifies 'destination' / 'source' plane terms. - Returned "colorkey.mask" property that was dropped from v3, looks like masking is quite common among different HW and hence makes more sense to have that property by default instead of having additional color keying modes. - Changed the color keying mode name to "transparent". 2) In response to Maarten's Lankhorst review comments: - Added a drm_colorkey_extract_component() helper which is supposed to commonize color key component value extraction code among DRM drivers. 3) In response to Russell's King review comments: - The doc-comment to drm_plane_create_colorkey_properties() now explicitly states that "The converted value shall be *rounded up* to the nearest value". Hence userspace now knows what to expect when plane has a 1bpp format. Please review, thanks. v3: https://lists.freedesktop.org/archives/dri-devel/2018-June/179057.html v2: https://lists.freedesktop.org/archives/dri-devel/2018-May/178408.html v1: https://lists.freedesktop.org/archives/dri-devel/2017-December/160510.html Dmitry Osipenko (1): drm/tegra: plane: Add generic colorkey properties for older Tegra's Laurent Pinchart (1): drm: Add generic colorkey properties for display planes drivers/gpu/drm/drm_atomic.c | 20 + drivers/gpu/drm/drm_blend.c | 150 drivers/gpu/drm/tegra/dc.c| 25 ++ drivers/gpu/drm/tegra/dc.h| 7 ++ drivers/gpu/drm/tegra/plane.c | 156 ++ include/drm/drm_blend.h | 3 + include/drm/drm_plane.h | 91 7 files changed, 452 insertions(+) -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 3/4] drm/atmel-hlcdc: iterate over all output endpoints
This enables more flexible devicetrees. You can e.g. have two output
nodes where one is not enabled, without the ordering affecting things.
Prior to this patch the active node had to have endpoint id zero.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 32 ++--
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
index 8db51fb131db..16c1b2f54b42 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
@@ -31,14 +31,16 @@ static const struct drm_encoder_funcs
atmel_hlcdc_panel_encoder_funcs = {
.destroy = drm_encoder_cleanup,
};
-static int atmel_hlcdc_attach_endpoint(struct drm_device *dev, int endpoint)
+static int atmel_hlcdc_attach_endpoint(struct drm_device *dev,
+ struct of_endpoint *endpoint)
{
struct drm_encoder *encoder;
struct drm_panel *panel;
struct drm_bridge *bridge;
int ret;
- ret = drm_of_find_panel_or_bridge(dev->dev->of_node, 0, endpoint,
+ ret = drm_of_find_panel_or_bridge(dev->dev->of_node,
+ endpoint->port, endpoint->id,
&panel, &bridge);
if (ret)
return ret;
@@ -77,13 +79,29 @@ static int atmel_hlcdc_attach_endpoint(struct drm_device
*dev, int endpoint)
int atmel_hlcdc_create_outputs(struct drm_device *dev)
{
- int endpoint, ret = 0;
-
- for (endpoint = 0; !ret; endpoint++)
- ret = atmel_hlcdc_attach_endpoint(dev, endpoint);
+ struct of_endpoint endpoint;
+ struct device_node *node = NULL;
+ int count = 0;
+ int ret = 0;
+
+ for_each_endpoint_of_node(dev->dev->of_node, node) {
+ of_graph_parse_endpoint(node, &endpoint);
+
+ if (endpoint.port)
+ continue;
+
+ ret = atmel_hlcdc_attach_endpoint(dev, &endpoint);
+ if (ret == -ENODEV)
+ continue;
+ if (ret) {
+ of_node_put(node);
+ break;
+ }
+ count++;
+ }
/* At least one device was successfully attached.*/
- if (ret == -ENODEV && endpoint)
+ if (ret == -ENODEV && count)
return 0;
return ret;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/4] drm/mxsfb: Switch to drm_atomic_helper_commit_tail_rpm
On Tue, 2018-08-07 at 21:01 +0200, Stefan Agner wrote: > On 06.08.2018 21:31, Leonard Crestez wrote: > > The lcdif block is only powered on when display is active so plane > > updates when not enabled are not valid. Writing to an unpowered IP block > > is mostly ignored but can trigger bus errors on some chips. > > > > Prevent this situation by switching to drm_atomic_helper_commit_tail_rpm > > and having the drm core ensure atomic_plane_update is only called while > > the crtc is active. This avoids having to keep track of "enabled" bits > > inside the mxsfb driver. > > > > This also requires handling the vblank event for disable from > > ~~mxsfb_pipe_update~~ **mxsfb_pipe_disable**. > > Hm, I don't think this is a new requirement. Simple KMS Helper Reference > clearly states that it should be called from update. > > Probably using drm_atomic_helper_commit_tail_rpm just exacerbates an > issue which we haven't seen before... > > Since I think it is a general fix, I'd rather prefer have it in a > separate commit. I wrote the commit message wrong, what I meant is that it requires handling the vblank event from *disable*. Switching to atomic_helper_commit_tail_rpm means atomic_update is no longer called when !state->active so nobody dispatches the last vblank event for disabling the crtc. This causes a warning in drm_atomic_helper_commit_hw_done on disable. Looking through the docs there seems to be a lot of complexity behind vblank events so maybe I'm missing something. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 0/4] drm/atmel-hlcdc: bus-width override support
Hi! The background for these patches is that our PCB interface between the SAMA5D3 and the ds90c185 lvds encoder is only using 16 bits, and this has to be described somewhere, or the atmel-hlcdc driver have no chance of selecting the correct output mode. Since we have similar problems with a tda19988 HDMI encoder I added patches to override the atmel-hlcdc output format via DT properties compatible with the media video-interface binding and things start to play together. Cheers, Peter Changes since v7 https://lkml.org/lkml/2018/8/4/288 - The ep device_node was leaked in v7 patch 3/3, so add patch 3/4 which simplifies fixing this in patch 4/4 (and adds flexibility) and adjust patch 4/4 to the changes done in the new 3/4. - return -ENOMEM on allocation failure in patch 4/4 Changes since v6 https://lkml.org/lkml/2018/8/3/333 - zap bus-type from the binding in patch 2/3 Changes since (the shortened) v5 https://lkml.org/lkml/2018/8/3/182 - add reg properties (and #*-cells) to the example in patch 2/3 - prohibit bus-width 0 in the device-tree in patch 3/3 - added reviewed-by from Jacopo to patch 2/3 and 3/3 Peter Rosin (4): dt-bindings: display: bridge: lvds-transmitter: add ti,ds90c185 dt-bindings: display: atmel: optional video-interface of endpoints drm/atmel-hlcdc: iterate over all output endpoints drm/atmel-hlcdc: support bus-width (12/16/18/24) in endpoint nodes .../devicetree/bindings/display/atmel/hlcdc-dc.txt | 28 +++ .../bindings/display/bridge/lvds-transmitter.txt | 8 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 70 +++- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 1 + drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 98 ++ 5 files changed, 170 insertions(+), 35 deletions(-) -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 5/5] tinydrm: add winstar wg160160 driver
Hi Noralf.
On Tue, Aug 07, 2018 at 07:35:30PM +0200, Noralf Trønnes wrote:
>
> Den 02.08.2018 21.45, skrev Sam Ravnborg:
> >Add driver for the winstar wg160160 display.
> >The driver utilises pardata-dbi that
> >again utilise the pardata subsystem.
> >
> >Signed-off-by: Sam Ravnborg
> >---
> > MAINTAINERS| 5 +
> > drivers/gpu/drm/tinydrm/Kconfig| 10 ++
> > drivers/gpu/drm/tinydrm/Makefile | 1 +
> > drivers/gpu/drm/tinydrm/wg160160.c | 298
> > +
> > 4 files changed, 314 insertions(+)
> > create mode 100644 drivers/gpu/drm/tinydrm/wg160160.c
> >
>
> [...]
>
> >+
> >+/**
> >+ * write_reg - Write instruction on parallel bus to controller
> >+ *
> >+ * Check BUSY flag and write instruction
> >+ *
> >+ * @pdd: pardata data
> >+ * @reg: The register to write
> >+ * @value: The value of the register
> >+ *
> >+ * Returns:
> >+ * Zero on success, negative error code on failure
> >+ */
> >+int write_reg(struct pardata_data *pdd, unsigned int reg, unsigned int
> >value)
> >+{
> >+int ins[PIN_NUM];
> >+int val[PIN_NUM];
> >+int i;
> >+
> >+for (i = 0; i < PIN_NUM; i++)
> >+ins[PIN_DB0 + i] = !!BIT(reg);
> >+
> >+for (i = 0; i < PIN_NUM; i++)
> >+val[PIN_DB0 + i] = !!(value & BIT(i));
> >+
> >+gpiod_set_value_cansleep(pdd->bus->pin_rs, 1);
> >+gpiod_set_array_value_cansleep(PIN_NUM, pdd->bus->data_pins->desc, ins);
> >+wait_busy(pdd);
> >+pardata_strobe_write(pdd);
> >+
> >+gpiod_set_value_cansleep(pdd->bus->pin_rs, 0);
> >+gpiod_set_array_value_cansleep(PIN_NUM, pdd->bus->data_pins->desc, val);
> >+wait_busy(pdd);
> >+pardata_strobe_write(pdd);
> >+
> >+return 0;
> >+}
>
> If this controller has normal registers, you could do a regmap
> implementation for pardata: drivers/base/regmap.
If I understand you correct then you suggest to add a regmap implementation
on top of the registers replacing the current gpio support?
So we in regmap can optimize access to the registers better.
Or did you have something else in mind?
As speed is not the main challenge here I will likely wait with this
and continue using gpio.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Documentation/fb: corrections for fbcon.txt
From: Randy Dunlap Fix grammar, spacing, indentation, and Kconfig menu locations in fbcon.txt. Signed-off-by: Randy Dunlap Cc: Antonino Daplas Cc: Geert Uytterhoeven Cc: linux-fb...@vger.kernel.org Cc: Bartlomiej Zolnierkiewicz Cc: Jonathan Corbet Cc: dri-devel@lists.freedesktop.org Cc: linux-...@vger.kernel.org --- Documentation/fb/fbcon.txt | 29 +++-- 1 file changed, 15 insertions(+), 14 deletions(-) --- lnx-418-rc8.orig/Documentation/fb/fbcon.txt +++ lnx-418-rc8/Documentation/fb/fbcon.txt @@ -18,9 +18,10 @@ made available by the underlying graphic A. Configuration The framebuffer console can be enabled by using your favorite kernel -configuration tool. It is under Device Drivers->Graphics Support->Support for -framebuffer devices->Framebuffer Console Support. Select 'y' to compile -support statically, or 'm' for module support. The module will be fbcon. +configuration tool. It is under Device Drivers->Graphics Support->Frame +buffer Devices->Console display driver support->Framebuffer Console Support. +Select 'y' to compile support statically or 'm' for module support. The +module will be fbcon. In order for fbcon to activate, at least one framebuffer driver is required, so choose from any of the numerous drivers available. For x86 @@ -29,10 +30,10 @@ always be available. However, using a ch more speed and features, such as the ability to change the video mode dynamically. - To display the penguin logo, choose any logo available in Logo -Configuration->Boot up logo. + To display the penguin logo, choose any logo available in Graphics +support->Bootup logo. - Also, you will need to select at least one compiled-in fonts, but if + Also, you will need to select at least one compiled-in font, but if you don't do anything, the kernel configuration tool will select one for you, usually an 8x16 font. @@ -135,16 +136,16 @@ C. Boot options The angle can be changed anytime afterwards by 'echoing' the same numbers to any one of the 2 attributes found in -/sys/class/graphics/fbcon + /sys/class/graphics/fbcon: rotate - rotate the display of the active console rotate_all - rotate the display of all consoles - Console rotation will only become available if Console Rotation - Support is compiled in your kernel. + Console rotation will only become available if Framebuffer Console + Rotation support is compiled in your kernel. NOTE: This is purely console rotation. Any other applications that - use the framebuffer will remain at their 'normal'orientation. + use the framebuffer will remain at their 'normal' orientation. Actually, the underlying fb driver is totally ignorant of console rotation. @@ -157,7 +158,7 @@ C. Boot options C. Attaching, Detaching and Unloading -Before going on how to attach, detach and unload the framebuffer console, an +Before going on to how to attach, detach and unload the framebuffer console, an illustration of the dependencies may help. The console layer, as with most subsystems, needs a driver that interfaces with @@ -175,7 +176,7 @@ because fbcon is an intermediate layer b console ---> fbcon ---> fbdev drivers ---> hardware -The fbdev drivers cannot be unloaded if it's bound to fbcon, and fbcon cannot +The fbdev drivers cannot be unloaded if bound to fbcon, and fbcon cannot be unloaded if it's bound to the console layer. So to unload the fbdev drivers, one must first unbind fbcon from the console, @@ -225,7 +226,7 @@ restored properly. The following is one echo 0 > /sys/class/vtconsole/vtcon1/bind 6. That's it, you're back to VGA mode. And if you compiled fbcon as a module, - you can unload it by 'rmmod fbcon' + you can unload it by 'rmmod fbcon'. 7. To reattach fbcon: @@ -283,7 +284,7 @@ Samples: Here are 2 sample bash scripts that you can use to bind or unbind the -framebuffer console driver if you are in an X86 box: +framebuffer console driver if you are on an X86 box: --- #!/bin/bash ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] gpu: host1x: Continue CDMA execution starting with a next job
Currently gathers of a hung job are getting NOP'ed and a restarted CDMA
executes the NOP'ed gathers. There shouldn't be a reason to not restart
CDMA execution starting with a next job, avoiding the unnecessary churning
with gathers NOP'ing.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/host1x/cdma.c | 23 +++
drivers/gpu/host1x/hw/cdma_hw.c | 13 -
2 files changed, 11 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
index 6aa6fa1498e8..9e4f01c7f663 100644
--- a/drivers/gpu/host1x/cdma.c
+++ b/drivers/gpu/host1x/cdma.c
@@ -323,7 +323,7 @@ void host1x_cdma_update_sync_queue(struct host1x_cdma *cdma,
{
struct host1x *host1x = cdma_to_host1x(cdma);
u32 restart_addr, syncpt_incrs, syncpt_val;
- struct host1x_job *job;
+ struct host1x_job *job, *next_job = NULL;
syncpt_val = host1x_syncpt_load(cdma->timeout.syncpt);
@@ -341,8 +341,13 @@ void host1x_cdma_update_sync_queue(struct host1x_cdma
*cdma,
__func__);
list_for_each_entry(job, &cdma->sync_queue, list) {
- if (syncpt_val < job->syncpt_end)
+ if (syncpt_val < job->syncpt_end) {
+
+ if (!list_is_last(&job->list, &cdma->sync_queue))
+ next_job = list_next_entry(job, list);
+
goto syncpt_incr;
+ }
host1x_job_dump(dev, job);
}
@@ -355,17 +360,11 @@ void host1x_cdma_update_sync_queue(struct host1x_cdma
*cdma,
/*
* Increment with CPU the remaining syncpts of a partially executed job.
*
-* Syncpt increments must be done inline with the pushbuffer from a
-* GATHER buffer to maintain the order (slots are modified to be a
-* GATHER of syncpt incrs).
-*
-* Note: save in restart_addr the location where the timed out buffer
-* started in the PB, so we can start the refetch from there (with the
-* modified NOP-ed PB slots). This lets things appear to have completed
-* properly for this buffer and resources are freed.
+* CDMA will continue execution starting with the next job or will get
+* into idle state.
*/
- if (job)
- restart_addr = job->first_get;
+ if (next_job)
+ restart_addr = next_job->first_get;
else
restart_addr = cdma->last_pos;
diff --git a/drivers/gpu/host1x/hw/cdma_hw.c b/drivers/gpu/host1x/hw/cdma_hw.c
index ce320534cbed..bc203532ae6d 100644
--- a/drivers/gpu/host1x/hw/cdma_hw.c
+++ b/drivers/gpu/host1x/hw/cdma_hw.c
@@ -40,7 +40,6 @@ static void cdma_timeout_cpu_incr(struct host1x_cdma *cdma,
u32 getptr,
u32 syncpt_incrs, u32 syncval, u32 nr_slots)
{
struct host1x *host1x = cdma_to_host1x(cdma);
- struct push_buffer *pb = &cdma->push_buffer;
unsigned int i;
for (i = 0; i < syncpt_incrs; i++)
@@ -48,18 +47,6 @@ static void cdma_timeout_cpu_incr(struct host1x_cdma *cdma,
u32 getptr,
/* after CPU incr, ensure shadow is up to date */
host1x_syncpt_load(cdma->timeout.syncpt);
-
- /* NOP all the PB slots */
- while (nr_slots--) {
- u32 *p = (u32 *)(pb->mapped + getptr);
- *(p++) = HOST1X_OPCODE_NOP;
- *(p++) = HOST1X_OPCODE_NOP;
- dev_dbg(host1x->dev, "%s: NOP at %pad+%#x\n", __func__,
- &pb->dma, getptr);
- getptr = (getptr + 8) & (pb->size - 1);
- }
-
- wmb();
}
/*
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/7] drm/i2c: tda998x: convert to bridge driver
On Wed, Aug 08, 2018 at 03:09:30PM -0400, Sean Paul wrote:
> > -static const struct drm_encoder_helper_funcs tda998x_encoder_helper_funcs
> > = {
> > - .dpms = tda998x_encoder_dpms,
> > - .prepare = tda998x_encoder_prepare,
> > - .commit = tda998x_encoder_commit,
> > - .mode_set = tda998x_encoder_mode_set,
> > -};
>
> Now that encoder is a stub, it should really be removed from here. The encoder
> should be instantiated elsewhere and attach the bridge to itself. There are a
> bunch of examples of this in bridge/
That's not possible at present - this driver has to remain compatible
with Armada and TI LCDC, both of which expect this driver to create
the encoder.
In any case, bridges are buggy with unbinding/rebinding as I've pointed
out several times in the past, but TDA998x used with Armada and TI LCDC
as it currently stands are not. So, to do this as a full conversion to
bridge and pushing the encoders into the DRM drivers results in a
regression for these two DRM drivers. I'm not willing to accept such
a regression, sorry.
Thanks for the other cleanup suggestions, they can be done with a
later patch (these changes have already been been merged.)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: Fix vmap_count increment position
On Wed, Aug 01, 2018 at 12:08:07PM +0300, Haneen Mohammed wrote:
> Move vmap_count out of the conditional statement since it needs
> to be updated for every successful call to vkms_gem_vmap.
>
> Signed-off-by: Haneen Mohammed
> ---
> drivers/gpu/drm/vkms/vkms_gem.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
> index a52e88338c05..5c51dfde7c1e 100644
> --- a/drivers/gpu/drm/vkms/vkms_gem.c
> +++ b/drivers/gpu/drm/vkms/vkms_gem.c
> @@ -240,10 +240,9 @@ int vkms_gem_vmap(struct drm_gem_object *obj)
> vkms_obj->vaddr = vmap(pages, n_pages, VM_MAP, PAGE_KERNEL);
> if (!vkms_obj->vaddr)
> goto err_vmap;
> -
> - vkms_obj->vmap_count++;
> }
>
> + vkms_obj->vmap_count++;
> goto out;
>
> err_vmap:
> --
> 2.17.1
>
Hi Sean,
This is a fix to bb112b14af8d ("drm/vkms: Add functions to map/unmap GEM
backing storage"), should I add this to the commit message?
Thank you,
Haneen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: simple: fix -Wliteral-conversion warning
On Thu, Aug 9, 2018 at 3:00 AM Thierry Reding wrote:
>
> On Fri, Jun 15, 2018 at 03:37:49PM -0700, Nick Desaulniers wrote:
> > Fixes commit 8cfe83419cdb ("drm/panel: simple: Add
> > support for KEO TX31D200VM0BAA")
> >
> > drivers/gpu/drm/panel/panel-simple.c:1250:27: warning: implicit conversion
> > from
> > 'double' to 'u32' (aka 'unsigned int') changes value from 33.5 to 33
> > [-Wliteral-conversion]
> > .vfront_porch = { 6, 21, 33.5 },
> > ~^~~~
> > drivers/gpu/drm/panel/panel-simple.c:1251:26: warning: implicit conversion
> > from
> > 'double' to 'u32' (aka 'unsigned int') changes value from 33.5 to 33
> > [-Wliteral-conversion]
> > .vback_porch = { 6, 21, 33.5 },
> >~^~~~
> >
> > Signed-off-by: Nick Desaulniers
> > ---
> > Alternatively, should these be rounded up to 34? I'm guessing the
> > current behaviour (truncation) is correct since that's how the patch was
> > operating.
>
> Looks like this is a duplicate of what was merged as:
>
> commit c9b6be7dc13e2f87592ee4c9812cb450dba484d5
> Author: Stefan Agner
> Date: Thu Apr 19 23:20:03 2018 +0200
Ah, cool. I need to be better about checking maintainers' trees.
Just curious, how come a patch from April hasn't hit torvalds/linux yet?
--
Thanks,
~Nick Desaulniers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v4 1/2] drm: Add generic colorkey properties for display planes
On Tue, Aug 07, 2018 at 08:22:01PM +0300, Dmitry Osipenko wrote: > + * Glossary: > + * > + * Destination plane: > + * Plane to which color keying properties are applied, this planes takes > + * the effect of color keying operation. The effect is determined by a > + * given color keying mode. > + * > + * Source plane: > + * Pixels of this plane are the source for color key matching operation. ... > + /** > + * @DRM_PLANE_COLORKEY_MODE_TRANSPARENT: > + * > + * Destination plane pixels are completely transparent in areas > + * where pixels of a source plane are matching a given color key > + * range, in other cases pixels of a destination plane are unaffected. > + * In areas where two or more source planes overlap, the topmost > + * plane takes precedence. > + */ This seems confusing to me. What you seem to be saying is that the "destination" plane would be the one which is (eg0 the graphic plane, and the "source" plane would be the the plane containing (eg) the video. You seem to be saying that the colorkey matches the video and determines whether the pixels in the graphic plane are opaque or transparent. Surely that is the wrong way round - in video overlay, you want to colorkey match the contents of the graphic plane to determine which pixels from the video plane to overlay. If it's the other way around (source is the graphic, destination is the video) it makes less sense to use the "source" and "destination" terms, I can't see how you could describe a plane that is being overlaid on top of another plane as a "destination". I guess the terminology has come from a thought about using a GPU to physically do the colorkeying when combining two planes - if the GPU were to write to the "destination" plane, then this would be the wrong way around. For starters, taking the above example, the video plane may well be smaller than the graphic plane. If it's the other way around, that has other problems, like destroying the colorkey in the graphic plane when writing the video plane's contents to it. So, in summary, I don't think "destination" and "source" are particularly good terms to describe the operation, and I think you have them swapped in your description of "DRM_PLANE_COLORKEY_MODE_TRANSPARENT". -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up According to speedtest.net: 13Mbps down 490kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/4] soc: amlogic: add meson-canvas
Amlogic SoCs feature a set of 256 canvas that act as pixel buffer descriptors. Some IPs like the display and video decoders access those pixels by using canvas IDs rather than direct phy addresses. As such, allocating/manipulating canvases can be done concurrently and there is a need for a standalone, lock-aware canvas provider module. Currently, canvas code lies in the drm/meson module as it is the sole user. This patchset adds such canvas provider module and converts drm/meson to using it, stripping/moving the current canvas code. Changes since v1: [0] - Convert ops struct to a public API - Added comments - Hid the of-node probe code behind meson_canvas_get - Changed device lock to a spinlock with irqsave [0]: https://lkml.org/lkml/2018/8/1/1512 Maxime Jourdan (4): soc: amlogic: add meson-canvas driver dt-bindings: soc: amlogic: add meson-canvas documentation ARM64: dts: meson-gx: add dmcbus and canvas nodes. drm/meson: convert to the new canvas module .../bindings/display/amlogic,meson-vpu.txt| 9 +- .../soc/amlogic/amlogic,meson-canvas.txt | 36 arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 24 ++- drivers/gpu/drm/meson/Kconfig | 1 + drivers/gpu/drm/meson/Makefile| 2 +- drivers/gpu/drm/meson/meson_canvas.c | 70 --- drivers/gpu/drm/meson/meson_canvas.h | 42 drivers/gpu/drm/meson/meson_crtc.c| 9 +- drivers/gpu/drm/meson/meson_drv.c | 22 +-- drivers/gpu/drm/meson/meson_drv.h | 5 +- drivers/gpu/drm/meson/meson_plane.c | 3 +- drivers/gpu/drm/meson/meson_viu.c | 1 - drivers/soc/amlogic/Kconfig | 7 + drivers/soc/amlogic/Makefile | 1 + drivers/soc/amlogic/meson-canvas.c| 185 ++ include/linux/soc/amlogic/meson-canvas.h | 65 ++ 16 files changed, 337 insertions(+), 145 deletions(-) create mode 100644 Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-canvas.txt delete mode 100644 drivers/gpu/drm/meson/meson_canvas.c delete mode 100644 drivers/gpu/drm/meson/meson_canvas.h create mode 100644 drivers/soc/amlogic/meson-canvas.c create mode 100644 include/linux/soc/amlogic/meson-canvas.h -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/5] pardata: new bus for parallel data access
Hi Noralf. On Tue, Aug 07, 2018 at 06:40:29PM +0200, Noralf Trønnes wrote: > Hi Sam, > > Den 02.08.2018 21.45, skrev Sam Ravnborg: > >The pardata supports implement a simple bus for devices > >that are connected using a parallel bus driven by GPIOs. > >The is often used in combination with simple displays > >that is often seen in older embedded designs. > >There is a demand for this support also in the linux > >kernel for HW designs that uses these kind of displays. > > > >The pardata bus uses a platfrom_driver that when probed > >creates devices for all child nodes in the DT, > >which are then supposed to be handled by pardata_drivers. > > > >Signed-off-by: Sam Ravnborg > >--- > > From a quick look at this I have these comments: > 1. There can only be one implementation of this bus, the gpio one. > There are SOC's with parallel bus hardware so you need to allow for > more implementations. > 2. The client shouldn't do the bus signaling. This should be hidden > behind read and write functions in pardata. > 3. I would also suggest you add an address bus instead of the RS pin > 4. I don't think reset belongs in the bus. It's a device thing. Excellent feedback - I will address this in v2. > 5. You can use gpiod_set_array_value() in the gpio implementation. > Some gpio drivers can set all gpios at once. Yes, it is already used. But only for DB0 to DB7 as there are timing constraings for the others. > > I made an attempt at implementing a bus like this a while back: > https://github.com/notro/fbdbi/tree/master/i80 Thanks, very helpfull. v2 will take a while as I plan to have something that actually works before posting next version. One open question. Miguel Ojeda mentioned that there is already a limited fbdev driver made on top of parport (part of auxdisplay). Is it the correct design to come up with a new bus or should this try to build on top of parport? I did not check in details if using parport is possible, but from a quick look it is doable. But then we use parport for something that it originally was not designed for and we drag with us a lot of extra functionality. So I like the slimmer pardata bus. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/3] host1x_cdma_update_sync_queue() clean up
v2: I've added two more patches on top of "Cancel only job that actually got stuck" patch. Hence it is a patch-series now. Dmitry Osipenko (3): gpu: host1x: Cancel only job that actually got stuck gpu: host1x: Don't complete a completed job gpu: host1x: Continue CDMA execution starting with a next job drivers/gpu/host1x/cdma.c | 62 + drivers/gpu/host1x/hw/cdma_hw.c | 13 --- 2 files changed, 24 insertions(+), 51 deletions(-) -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] gpu: host1x: Don't complete a completed job
There is a chance that the last job has been completed at the time of
CDMA timeout handler invocation. In this case there is no need to complete
the completed job.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/host1x/cdma.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
index 75f339f5df6f..6aa6fa1498e8 100644
--- a/drivers/gpu/host1x/cdma.c
+++ b/drivers/gpu/host1x/cdma.c
@@ -323,7 +323,7 @@ void host1x_cdma_update_sync_queue(struct host1x_cdma *cdma,
{
struct host1x *host1x = cdma_to_host1x(cdma);
u32 restart_addr, syncpt_incrs, syncpt_val;
- struct host1x_job *job = NULL;
+ struct host1x_job *job;
syncpt_val = host1x_syncpt_load(cdma->timeout.syncpt);
@@ -342,11 +342,16 @@ void host1x_cdma_update_sync_queue(struct host1x_cdma
*cdma,
list_for_each_entry(job, &cdma->sync_queue, list) {
if (syncpt_val < job->syncpt_end)
- break;
+ goto syncpt_incr;
host1x_job_dump(dev, job);
}
+ /* all jobs have been completed */
+ job = NULL;
+
+syncpt_incr:
+
/*
* Increment with CPU the remaining syncpts of a partially executed job.
*
@@ -359,16 +364,16 @@ void host1x_cdma_update_sync_queue(struct host1x_cdma
*cdma,
* modified NOP-ed PB slots). This lets things appear to have completed
* properly for this buffer and resources are freed.
*/
-
- dev_dbg(dev, "%s: perform CPU incr on pending buffers\n", __func__);
-
- if (!list_empty(&cdma->sync_queue))
+ if (job)
restart_addr = job->first_get;
else
restart_addr = cdma->last_pos;
/* do CPU increments for the remaining syncpts */
if (job) {
+ dev_dbg(dev, "%s: perform CPU incr on pending buffers\n",
+ __func__);
+
/* won't need a timeout when replayed */
job->timeout = 0;
@@ -381,9 +386,10 @@ void host1x_cdma_update_sync_queue(struct host1x_cdma
*cdma,
host1x_hw_cdma_timeout_cpu_incr(host1x, cdma, job->first_get,
syncpt_incrs, job->syncpt_end,
job->num_slots);
- }
- dev_dbg(dev, "%s: finished sync_queue modification\n", __func__);
+ dev_dbg(dev, "%s: finished sync_queue modification\n",
+ __func__);
+ }
/* roll back DMAGET and start up channel again */
host1x_hw_cdma_resume(host1x, cdma, restart_addr);
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/5] drm/mxsfb: Move axi clk enable/disable to crtc enable/disable
The main axi clk is disabled at the end of mxsfb_crtc_mode_set_nofb and
immediately reenabled in mxsfb_enable_controller.
Avoid this by moving the handling of axi clk one level up to
mxsfb_crtc_enable. Do the same for mxsfb_crtc_disable for simmetry
This shouldn't have any functional effect.
Signed-off-by: Leonard Crestez
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index 0abe77675b76..e4fcbb65b969 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -127,11 +127,10 @@ static void mxsfb_enable_controller(struct
mxsfb_drm_private *mxsfb)
u32 reg;
if (mxsfb->clk_disp_axi)
clk_prepare_enable(mxsfb->clk_disp_axi);
clk_prepare_enable(mxsfb->clk);
- mxsfb_enable_axi_clk(mxsfb);
/* If it was disabled, re-enable the mode again */
writel(CTRL_DOTCLK_MODE, mxsfb->base + LCDC_CTRL + REG_SET);
/* Enable the SYNC signals first, then the DMA engine */
@@ -157,12 +156,10 @@ static void mxsfb_disable_controller(struct
mxsfb_drm_private *mxsfb)
reg = readl(mxsfb->base + LCDC_VDCTRL4);
reg &= ~VDCTRL4_SYNC_SIGNALS_ON;
writel(reg, mxsfb->base + LCDC_VDCTRL4);
- mxsfb_disable_axi_clk(mxsfb);
-
clk_disable_unprepare(mxsfb->clk);
if (mxsfb->clk_disp_axi)
clk_disable_unprepare(mxsfb->clk_disp_axi);
}
@@ -206,11 +203,10 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
/*
* It seems, you can't re-program the controller if it is still
* running. This may lead to shifted pictures (FIFO issue?), so
* first stop the controller and drain its FIFOs.
*/
- mxsfb_enable_axi_clk(mxsfb);
/* Mandatory eLCDIF reset as per the Reference Manual */
err = mxsfb_reset_block(mxsfb->base);
if (err)
return;
@@ -267,23 +263,23 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
SET_VERT_WAIT_CNT(m->crtc_vtotal - m->crtc_vsync_start),
mxsfb->base + LCDC_VDCTRL3);
writel(SET_DOTCLK_H_VALID_DATA_CNT(m->hdisplay),
mxsfb->base + LCDC_VDCTRL4);
-
- mxsfb_disable_axi_clk(mxsfb);
}
void mxsfb_crtc_enable(struct mxsfb_drm_private *mxsfb)
{
+ mxsfb_enable_axi_clk(mxsfb);
mxsfb_crtc_mode_set_nofb(mxsfb);
mxsfb_enable_controller(mxsfb);
}
void mxsfb_crtc_disable(struct mxsfb_drm_private *mxsfb)
{
mxsfb_disable_controller(mxsfb);
+ mxsfb_disable_axi_clk(mxsfb);
}
void mxsfb_plane_atomic_update(struct mxsfb_drm_private *mxsfb,
struct drm_plane_state *state)
{
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/5] drm/mxsfb: Add pm_runtime calls to pipe_enable/disable
Adding lcdif nodes to a power domain currently results in
black/corrupted screens or hangs because power is not correctly enabled
when required.
Ensure power is on when display is active by adding
pm_runtime_get/put_sync to mxsfb_pipe_enable/disable.
Signed-off-by: Leonard Crestez
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index ffe5137ccaf8..68d79f5dc0d3 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -101,23 +101,27 @@ static const struct drm_mode_config_funcs
mxsfb_mode_config_funcs = {
static void mxsfb_pipe_enable(struct drm_simple_display_pipe *pipe,
struct drm_crtc_state *crtc_state,
struct drm_plane_state *plane_state)
{
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
+ struct drm_device *drm = pipe->plane.dev;
+ pm_runtime_get_sync(drm->dev);
drm_panel_prepare(mxsfb->panel);
mxsfb_crtc_enable(mxsfb);
drm_panel_enable(mxsfb->panel);
}
static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
{
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
+ struct drm_device *drm = pipe->plane.dev;
drm_panel_disable(mxsfb->panel);
mxsfb_crtc_disable(mxsfb);
drm_panel_unprepare(mxsfb->panel);
+ pm_runtime_put_sync(drm->dev);
}
static void mxsfb_pipe_update(struct drm_simple_display_pipe *pipe,
struct drm_plane_state *plane_state)
{
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/tilcdc: Convert drm_atomic_helper_suspend/resume()
convert drm_atomic_helper_suspend/resume() to use
drm_mode_config_helper_suspend/resume().
saved_state in tilcdc_drm_private will not be used
anymore, so it can be removed.
Signed-off-by: Ajit Negi
Signed-off-by: Souptick Joarder
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 14 --
drivers/gpu/drm/tilcdc/tilcdc_drv.h | 3 ---
2 files changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 0fb300d..33e5332 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -554,29 +554,23 @@ static int tilcdc_debugfs_init(struct drm_minor *minor)
static int tilcdc_pm_suspend(struct device *dev)
{
struct drm_device *ddev = dev_get_drvdata(dev);
- struct tilcdc_drm_private *priv = ddev->dev_private;
+ int ret = 0;
- priv->saved_state = drm_atomic_helper_suspend(ddev);
+ ret = drm_mode_config_helper_suspend(ddev);
/* Select sleep pin state */
pinctrl_pm_select_sleep_state(dev);
- return 0;
+ return ret;
}
static int tilcdc_pm_resume(struct device *dev)
{
struct drm_device *ddev = dev_get_drvdata(dev);
- struct tilcdc_drm_private *priv = ddev->dev_private;
- int ret = 0;
/* Select default pin state */
pinctrl_pm_select_default_state(dev);
-
- if (priv->saved_state)
- ret = drm_atomic_helper_resume(ddev, priv->saved_state);
-
- return ret;
+ return drm_mode_config_helper_resume(ddev);
}
#endif
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index ead5122..62cea5f 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -70,9 +70,6 @@ struct tilcdc_drm_private {
const uint32_t *pixelformats;
uint32_t num_pixelformats;
- /* The context for pm susped/resume cycle is stored here */
- struct drm_atomic_state *saved_state;
-
#ifdef CONFIG_CPU_FREQ
struct notifier_block freq_transition;
#endif
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] gpu: host1x: Ignore clients initialization failure
On Thursday, 9 August 2018 13:45:41 MSK Thierry Reding wrote: > On Fri, Aug 03, 2018 at 02:30:47PM +0300, Dmitry Osipenko wrote: > > On Friday, 3 August 2018 13:50:55 MSK Thierry Reding wrote: > > > On Wed, Aug 01, 2018 at 06:08:07PM +0300, Dmitry Osipenko wrote: > > > > From time to time new bugs are popping up, causing some host1x client > > > > to > > > > fail its initialization. Currently a single clients initialization > > > > failure > > > > causes whole host1x device registration to fail, as a result a single > > > > DRM > > > > sub-device initialization failure makes whole DRM initialization to > > > > fail. > > > > Let's ignore clients initialization failure, as a result display panel > > > > lights up even if some DRM clients (say GR2D or VIC) fail to > > > > initialize. > > > > > > > > Signed-off-by: Dmitry Osipenko > > > > --- > > > > > > > > drivers/gpu/host1x/bus.c | 18 +++--- > > > > 1 file changed, 7 insertions(+), 11 deletions(-) > > > > > > This is actually done on purpose. I can't think of a case where we would > > > actively like to keep a half-broken DRM device operational. The errors > > > that you're talking about should only happen during development, > > > > [only in a perfect world] > > gr2d and VIC are fairly deterministic. What are the errors you are > seeing that cause initialization failure? Right now there are no specific errors. There is only a known trouble with the ARM_DMA_USE_IOMMU, but that causes to fail all of the clients. > Note that it is possible for > these devices to malfunction even if initialization succeeds. A failure > to initialize can only happen if there's something wrong in the device > tree, firmware is missing (in case of VIC) or a regression was > introduced in some subsystem that causes a failure (maybe deferred probe > or something similar). A missing firmware is an actual good example. Though can't VIC driver be changed to load firmware at the time of a its first use by userspace? It should be very annoying that kernel driver forces you to churn with initramfs. > > > and the > > > device not showing up is a pretty good indicator that something is wrong > > > as opposed to everything booting normally and then getting some cryptic > > > error at runtime because one of the clients didn't initialize. > > > > If machine doesn't have a serial port and it doesn't have ssh server > > running or network doesn't come up, you'll end up with a completely > > dysfunctional piece of hardware. Hence there is no chance for you to even > > check what is wrong. The argument about a cryptic error doesn't make much > > sense, you have to improve your runtime as well (and you'll get a error > > message in the kernels log). > > You make a good point here. I'm not aware of any devices we support in > the kernel that don't have a serial console, but that doesn't mean the > kernel could be used on an "unsupported" device that doesn't have one. AFAIK, enabling serial on AC100 require soldering iron. > > > From my perspective, all clients should always be operational in > > > whatever baseline version you use. If it isn't that's a bug that should > > > be fixed. Ideally those bugs should get fixed before making it into a > > > baseline version (mainline, linux-next, ...), so that this never impacts > > > even developers, unless they break it themselves, in which case refusing > > > to register the DRM device is a pretty good incentive to fix it. > > > > Sounds like you're assuming that only kernel developers are supposed to > > use > > Tegra, though at least (for now) for upstream it is kinda true. Of course > > that could be changed ;-) > > That's not at all what I'm saying. What I am saying is that we should > make it difficult for developers to break the kernel in a way that would > put users into a position that is difficult to get themselves out of. If > we refuse to register the complete DRM device in case some subdevice > fails to initialize we increase the chances of developers noticing and > fixing it. > > If all we do on failure is output an error message, it's very likely to > go unnoticed. Developers are likely to check specifically the > functionality that they're working on and ignore failures that they may > have caused in other parts of the code as a side-effect of their current > work. I can try to help with improving of your automated testing suite, if you'll make it accessible to the public. > Perhaps a good middle ground would be to turn initialization failures > into WARN_ON() to increase the chances of them getting notified and then > continue on a best effort basis in the hopes of having enough > initialized to get a message to users. Good to me, I'll make v2. > Another alternative would be to > mark essential subdevices (such as the display controller) so that only > they will cause failure to register the whole DRM device. I don't think that making some subdevice more valuable than the others is a feasible appr
Re: [PATCH v2 4/7] drm/i2c: tda998x: convert to bridge driver
On Fri, Aug 10, 2018 at 01:02:29PM -0400, Sean Paul wrote: > On Fri, Aug 10, 2018 at 05:50:37PM +0100, Russell King - ARM Linux wrote: > > Almost none of my DRM specific patches on dri-devel this time around > > received any feedback what so ever, even after myself and David chasing > > them up. Over the Armada changes, David Airlie eventually said to me > > "if it works for you, send it to me I suppose". > > > > David also tried poking the tda998x/component discussion thread as well > > from the beginning of July (or so David told me), with seemingly the > > same result. > > > > So, in summary, it's been almost impossible to get any feedback on any > > of the patches and discussions I've sent - I think extracting blood > > from a rock might be easier! ;) > > Yeah, I suspect a lot of people have blinders wrt tda given that it's off in > i2c/. Feel free to ping me on irc in future if you're looking for a review. > Once > tda moves to bridge/ and drm-misc, it'll likely be much easier to get people > engaged. I suspect that those who actually use it don't have such blinders, yet they also have ignored the patches despite being copied with them. I can't see that the location of the driver would make any difference for them. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up According to speedtest.net: 13Mbps down 490kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] gpu: host1x: Ignore clients initialization failure
From time to time new bugs are popping up, causing some host1x client to
fail its initialization. Currently a single clients initialization failure
causes whole host1x device registration to fail, as a result a single DRM
sub-device initialization failure makes whole DRM initialization to fail.
Let's ignore clients initialization failure, as a result display panel
lights up even if some DRM clients (say GR2D or VIC) fail to initialize.
Actually VIC fails if initramfs misses the firmware file, so with this
change a serial console isn't needed anymore to figure out why display
isn't working.
Signed-off-by: Dmitry Osipenko
---
Changelog:
v2: Added WARN_ON() that should get more attention than just a error message.
Made clients_lock to lock around the lists modification, that is in line
with the rest of the code.
drivers/gpu/host1x/bus.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index 815bdb42e3f0..07bb6b6c1260 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -199,19 +199,23 @@ static void host1x_subdev_unregister(struct host1x_device
*device,
*/
int host1x_device_init(struct host1x_device *device)
{
- struct host1x_client *client;
+ struct host1x_client *client, *cl;
int err;
mutex_lock(&device->clients_lock);
- list_for_each_entry(client, &device->clients, list) {
+ list_for_each_entry_safe(client, cl, &device->clients, list) {
if (client->ops && client->ops->init) {
err = client->ops->init(client);
- if (err < 0) {
+ if (WARN_ON(err < 0)) {
dev_err(&device->dev,
"failed to initialize %s: %d\n",
dev_name(client->dev), err);
- goto teardown;
+
+ /* add the client to the list of idle clients */
+ mutex_lock(&clients_lock);
+ list_add_tail(&client->list, &clients);
+ mutex_unlock(&clients_lock);
}
}
}
@@ -219,14 +223,6 @@ int host1x_device_init(struct host1x_device *device)
mutex_unlock(&device->clients_lock);
return 0;
-
-teardown:
- list_for_each_entry_continue_reverse(client, &device->clients, list)
- if (client->ops->exit)
- client->ops->exit(client);
-
- mutex_unlock(&device->clients_lock);
- return err;
}
EXPORT_SYMBOL(host1x_device_init);
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v4 1/2] drm: Add generic colorkey properties for display planes
On Wednesday, 8 August 2018 11:16:09 MSK Russell King - ARM Linux wrote: > On Tue, Aug 07, 2018 at 08:22:01PM +0300, Dmitry Osipenko wrote: > > + * Glossary: > > + * > > + * Destination plane: > > + * Plane to which color keying properties are applied, this planes takes > > + * the effect of color keying operation. The effect is determined by a > > + * given color keying mode. > > + * > > + * Source plane: > > + * Pixels of this plane are the source for color key matching operation. > > ... > > > + /** > > +* @DRM_PLANE_COLORKEY_MODE_TRANSPARENT: > > +* > > +* Destination plane pixels are completely transparent in areas > > +* where pixels of a source plane are matching a given color key > > +* range, in other cases pixels of a destination plane are unaffected. > > +* In areas where two or more source planes overlap, the topmost > > +* plane takes precedence. > > +*/ > > This seems confusing to me. > > What you seem to be saying is that the "destination" plane would be the > one which is (eg0 the graphic plane, and the "source" plane would be the > the plane containing (eg) the video. You seem to be saying that the > colorkey matches the video and determines whether the pixels in the > graphic plane are opaque or transparent. Your example is correct. With the "plane_mask" property we can specify any plane as the "source" for color key, so it can been either a video plane or graphic plane and even both at the same time. > Surely that is the wrong way round - in video overlay, you want to > colorkey match the contents of the graphic plane to determine which > pixels from the video plane to overlay. The "transparent" mode makes the color-matched pixels to become transparent, you want the inversion effect and hence that should be called something like a "transparent-inverted" mode. Maarten Lankhorst was asking for that mode in his comment to v3, I'm leaving for somebody else to add that mode later since there is no real use for it on Tegra right now. So in your case the graphic plane will be the "source" plane (specified via the colorkey.plane_mask property), video plane will be the "destination" plane (plane to which the colorkey properties are applied) and the colorkey.mode will be "transparent-inverted". Pixels of the "source" plane are being matched and "destination" plane takes the effect of color keying operation, i.e. the color-matched pixels of graphic plane leave the video plane pixels unaffected and the unmatched pixels make the video plane pixels transparent. > If it's the other way around (source is the graphic, destination is the > video) it makes less sense to use the "source" and "destination" terms, > I can't see how you could describe a plane that is being overlaid on > top of another plane as a "destination". Tegra has a bit annoying limitations in regard to a reduced plane blending functionality when color keying is enabled. I found that the best variant to work around the limitations is to move the graphic plane on top of the video plane and to make the graphic plane to match itself. I.e. the matched pixels of graphic plane become transparent and hence poked by video plane. > I guess the terminology has come from a thought about using a GPU to > physically do the colorkeying when combining two planes - if the GPU > were to write to the "destination" plane, then this would be the wrong > way around. For starters, taking the above example, the video plane > may well be smaller than the graphic plane. If it's the other way > around, that has other problems, like destroying the colorkey in the > graphic plane when writing the video plane's contents to it. It all depends on a use-case scenario. It won't be easy for userspace to generalize the usage of color keying, at best the color keying interface could be generalized and then userspace may choose the best fitting variant based on available HW capabilities. > So, in summary, I don't think "destination" and "source" are > particularly good terms to describe the operation, and I think you have > them swapped in your description of > "DRM_PLANE_COLORKEY_MODE_TRANSPARENT". Maybe the DRM_PLANE_COLORKEY_MODE_TRANSPARENT should become DRM_PLANE_COLORKEY_MODE_TRANSPARENT_INVERTED? Any more opinions? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/gvt: fix memory leak in intel_vgpu_ioctl()
> On 2018.08.03 08:41:19 +0800, Yi Wang wrote:
> > The 'sparse' variable may leak when return in function
> > intel_vgpu_ioctl(), and this patch fixes this.
> >
> > Signed-off-by: Yi Wang
> > Reviewed-by: Jiang Biao
> > ---
> > drivers/gpu/drm/i915/gvt/kvmgt.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> > b/drivers/gpu/drm/i915/gvt/kvmgt.c
> > index df4e4a0..6a6f199 100644
> > --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> > +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> > @@ -1200,6 +1200,7 @@ static long intel_vgpu_ioctl(struct mdev_device
> > *mdev, unsigned int cmd,
> > return ret;
> > break;
> > default:
> > +kfree(sparse);
> > return -EINVAL;
> > }
> > }
> > @@ -1215,6 +1216,7 @@ static long intel_vgpu_ioctl(struct mdev_device
> > *mdev, unsigned int cmd,
> >sizeof(info), caps.buf,
> >caps.size)) {
> > kfree(caps.buf);
> > +kfree(sparse);
> > return -EFAULT;
> > }
> > info.cap_offset = sizeof(info);
> > @@ -1223,6 +1225,7 @@ static long intel_vgpu_ioctl(struct mdev_device
> > *mdev, unsigned int cmd,
> > kfree(caps.buf);
> > }
> >
> > +kfree(sparse);
>
> Unfortunately this would cause a double-free error in normal path, as we
> tried to free sparse after use to add caps. So may be better to fix free
> in error path and move normal free of sparse in final point, e.g
Yeah, that's right! Thanks a lot for your advice. I will send a v2 patch.
---
Best wishes
Yi Wang___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 4/4] drm/atmel-hlcdc: support bus-width (12/16/18/24) in endpoint nodes
This beats the heuristic that the connector is involved in what format
should be output for cases where this fails.
E.g. if there is a bridge that changes format between the encoder and the
connector, or if some of the RGB pins between the lcd controller and the
encoder are not routed on the PCB.
This is critical for the devices that have the "conflicting output
formats" issue (SAM9N12, SAM9X5, SAMA5D3), since the most significant
RGB bits move around depending on the selected output mode. For
devices that do not have the "conflicting output formats" issue
(SAMA5D2, SAMA5D4), this is completely irrelevant.
Acked-by: Boris Brezillon
Reviewed-by: Jacopo Mondi
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 70 +---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 1 +
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 66 +++---
3 files changed, 110 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index d73281095fac..c38a479ada98 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -226,6 +226,55 @@ static void atmel_hlcdc_crtc_atomic_enable(struct drm_crtc
*c,
#define ATMEL_HLCDC_RGB888_OUTPUT BIT(3)
#define ATMEL_HLCDC_OUTPUT_MODE_MASK GENMASK(3, 0)
+static int atmel_hlcdc_connector_output_mode(struct drm_connector_state *state)
+{
+ struct drm_connector *connector = state->connector;
+ struct drm_display_info *info = &connector->display_info;
+ struct drm_encoder *encoder;
+ unsigned int supported_fmts = 0;
+ int j;
+
+ encoder = state->best_encoder;
+ if (!encoder)
+ encoder = connector->encoder;
+
+ switch (atmel_hlcdc_encoder_get_bus_fmt(encoder)) {
+ case 0:
+ break;
+ case MEDIA_BUS_FMT_RGB444_1X12:
+ return ATMEL_HLCDC_RGB444_OUTPUT;
+ case MEDIA_BUS_FMT_RGB565_1X16:
+ return ATMEL_HLCDC_RGB565_OUTPUT;
+ case MEDIA_BUS_FMT_RGB666_1X18:
+ return ATMEL_HLCDC_RGB666_OUTPUT;
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ return ATMEL_HLCDC_RGB888_OUTPUT;
+ default:
+ return -EINVAL;
+ }
+
+ for (j = 0; j < info->num_bus_formats; j++) {
+ switch (info->bus_formats[j]) {
+ case MEDIA_BUS_FMT_RGB444_1X12:
+ supported_fmts |= ATMEL_HLCDC_RGB444_OUTPUT;
+ break;
+ case MEDIA_BUS_FMT_RGB565_1X16:
+ supported_fmts |= ATMEL_HLCDC_RGB565_OUTPUT;
+ break;
+ case MEDIA_BUS_FMT_RGB666_1X18:
+ supported_fmts |= ATMEL_HLCDC_RGB666_OUTPUT;
+ break;
+ case MEDIA_BUS_FMT_RGB888_1X24:
+ supported_fmts |= ATMEL_HLCDC_RGB888_OUTPUT;
+ break;
+ default:
+ break;
+ }
+ }
+
+ return supported_fmts;
+}
+
static int atmel_hlcdc_crtc_select_output_mode(struct drm_crtc_state *state)
{
unsigned int output_fmts = ATMEL_HLCDC_OUTPUT_MODE_MASK;
@@ -238,31 +287,12 @@ static int atmel_hlcdc_crtc_select_output_mode(struct
drm_crtc_state *state)
crtc = drm_crtc_to_atmel_hlcdc_crtc(state->crtc);
for_each_new_connector_in_state(state->state, connector, cstate, i) {
- struct drm_display_info *info = &connector->display_info;
unsigned int supported_fmts = 0;
- int j;
if (!cstate->crtc)
continue;
- for (j = 0; j < info->num_bus_formats; j++) {
- switch (info->bus_formats[j]) {
- case MEDIA_BUS_FMT_RGB444_1X12:
- supported_fmts |= ATMEL_HLCDC_RGB444_OUTPUT;
- break;
- case MEDIA_BUS_FMT_RGB565_1X16:
- supported_fmts |= ATMEL_HLCDC_RGB565_OUTPUT;
- break;
- case MEDIA_BUS_FMT_RGB666_1X18:
- supported_fmts |= ATMEL_HLCDC_RGB666_OUTPUT;
- break;
- case MEDIA_BUS_FMT_RGB888_1X24:
- supported_fmts |= ATMEL_HLCDC_RGB888_OUTPUT;
- break;
- default:
- break;
- }
- }
+ supported_fmts = atmel_hlcdc_connector_output_mode(cstate);
if (crtc->dc->desc->conflicting_output_formats)
output_fmts &= supported_fmts;
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
index
[PATCH v2] drm/i915/gvt: fix memory leak in intel_vgpu_ioctl()
The 'sparse' variable may leak when return in function
intel_vgpu_ioctl(), and this patch fix this.
Signed-off-by: Yi Wang
Reviewed-by: Jiang Biao
---
v2: fix a double-free error. Thanks to Zhenyu Wang.
drivers/gpu/drm/i915/gvt/kvmgt.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index df4e4a0..bce60cc 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1195,11 +1195,13 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev,
unsigned int cmd,
&sparse->header, sizeof(*sparse) +
(sparse->nr_areas *
sizeof(*sparse->areas)));
- kfree(sparse);
- if (ret)
+ if (ret) {
+ kfree(sparse);
return ret;
+ }
break;
default:
+ kfree(sparse);
return -EINVAL;
}
}
@@ -1215,6 +1217,7 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev,
unsigned int cmd,
sizeof(info), caps.buf,
caps.size)) {
kfree(caps.buf);
+ kfree(sparse);
return -EFAULT;
}
info.cap_offset = sizeof(info);
@@ -1223,6 +1226,7 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev,
unsigned int cmd,
kfree(caps.buf);
}
+ kfree(sparse);
return copy_to_user((void __user *)arg, &info, minsz) ?
-EFAULT : 0;
} else if (cmd == VFIO_DEVICE_GET_IRQ_INFO) {
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/7] drm/i2c: tda998x: convert to bridge driver
On Fri, Aug 10, 2018 at 12:11:05PM -0400, Sean Paul wrote: > On Wed, Aug 08, 2018 at 11:15:47PM +0100, Russell King - ARM Linux wrote: > > In any case, bridges are buggy with unbinding/rebinding as I've pointed > > out several times in the past, but TDA998x used with Armada and TI LCDC > > as it currently stands are not. So, to do this as a full conversion to > > bridge and pushing the encoders into the DRM drivers results in a > > regression for these two DRM drivers. I'm not willing to accept such > > a regression, sorry. > > > > Thanks for the other cleanup suggestions, they can be done with a > > later patch (these changes have already been been merged.) > > I still think you should get review from a bridge maintainer before it goes to > drm-next. They are free to review them any time they wish, all the patches are on dri-devel. However "before it goes to drm-next" has been impossible for a while now because David has already pulled it in. Almost none of my DRM specific patches on dri-devel this time around received any feedback what so ever, even after myself and David chasing them up. Over the Armada changes, David Airlie eventually said to me "if it works for you, send it to me I suppose". David also tried poking the tda998x/component discussion thread as well from the beginning of July (or so David told me), with seemingly the same result. So, in summary, it's been almost impossible to get any feedback on any of the patches and discussions I've sent - I think extracting blood from a rock might be easier! ;) I sent a patch about the "broadcast rgb" property - there are no replies to that email, and it was only in a completely different thread that I happened to notice a comment about that patch - it is not a sign of a healthy community to be providing feedback on patches by sending replies to other threads! Yet that seems to be happening on dri-devel! I guess everyone could've gone to the beach (lucky them) because of the hot weather for the last couple of months, and now that it's cooled down in some parts, people are starting to re-engage... If the bridge maintainers eventually get around to reviewing the changes, then, as I've said, any necessary changes can be made later, but what you ask is now impossible - they've been in drm-next since Tuesday evening, and by implication they've been in linux-next too - including last night's linux-next which is the final one before the merge window opens assuming it opens on Sunday. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up According to speedtest.net: 13Mbps down 490kbps up ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200621] Freezing with amdgpu driver
https://bugzilla.kernel.org/show_bug.cgi?id=200621 --- Comment #3 from Jon (jon...@gmail.com) --- Still experiencing this issue with the latest fedora kernel (4.17.12). Not sure if this is helpful (from journalctl): Aug 11 10:10:14 pc003 kernel: [drm] DM_MST: stopping TM on aconnector: b031b72e [id: 52] Aug 11 10:10:18 pc003 kernel: [drm] DM_MST: Disabling connector: 8afd1668 [id: 112] [master: b031b72e] Aug 11 10:10:18 pc003 kernel: [drm] DM_MST: Disabling connector: 0afea3b8 [id: 109] [master: b031b72e] Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) event3 - SteelSeries Sensei Raw Gaming Mouse: SYN_DROPPED event - some input events have been lost. Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): EDID vendor "DEL", prod id 41146 Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): Using hsync ranges from config file Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): Using vrefresh ranges from config file Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): Printing DDC gathered Modelines: Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): Modeline "1920x1200"x0.0 154.00 1920 1968 2000 2080 1200 1203 1209 1235 +hsync +vsync (74.0 kHz eP) Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): Modeline "1920x1080"x0.0 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync (67.5 kHz e) Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): Modeline "1920x1080i"x0.0 74.25 1920 2008 2052 2200 1080 1084 1094 1125 interlace +hsync +vsync (33.8 kHz e) Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): Modeline "1280x720"x0.0 74.25 1280 1390 1430 1650 720 725 730 750 +hsync +vsync (45.0 kHz e) Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): Modeline "720x480"x0.0 27.00 720 736 798 858 480 489 495 525 -hsync -vsync (31.5 kHz e) Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz e) Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e) Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz e) Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz e) Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz e) Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz e) Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz e) Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz e) Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): Modeline "1600x1200"x0.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz e) Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): Modeline "1920x1080"x60.0 172.80 1920 2040 2248 2576 1080 1081 1084 1118 -hsync +vsync (67.1 kHz e) Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): Modeline "1920x1200"x0.0 154.00 1920 1968 2000 2080 1200 1203 1209 1235 +hsync -vsync (74.0 kHz e) Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): Modeline "1440x480i"x0.0 27.00 1440 1478 1602 1716 480 488 494 525 interlace -hsync -vsync (15.7 kHz e) Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): Modeline "1440x576i"x0.0 27.00 1440 1464 1590 1728 576 580 586 625 interlace -hsync -vsync (15.6 kHz e) Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): Modeline "1920x1080i"x0.0 74.25 1920 2448 2492 2640 1080 1084 1094 1125 interlace +hsync +vsync (28.1 kHz e) Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-session[2003]: (II) modeset(0): Modeline "1920x1080"x0.0 148.50 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync (56.2 kHz e) Aug 11 10:10:18 pc003 /usr/libexec/gdm-x-s
[PATCH] [v3] drm: amd: dc: don't use FP math when Kcov is enabled
Building the DCN 1.0 Raven display driver with CONFIG_KCOV_INSTRUMENT_ALL=y and CONFIG_KCOV_ENABLE_COMPARISONS=y results in warnings about many functions that do a comparison of floating-point variables: drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function `dcn_bw_calc_rq_dlg_ttu': dcn_calcs.c:(.text+0x263): undefined reference to `__sanitizer_cov_trace_cmpf' drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function `hack_force_pipe_split': dcn_calcs.c:(.text+0x155b): undefined reference to `__sanitizer_cov_trace_cmpf' drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function `dcn_find_dcfclk_suits_all': dcn_calcs.c:(.text+0x190e): undefined reference to `__sanitizer_cov_trace_cmpf' drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function `dcn_validate_bandwidth': dcn_calcs.c:(.text+0xe121): undefined reference to `__sanitizer_cov_trace_cmpd' drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function `dcn_bw_mod': dcn_calc_math.c:(.text+0x22): undefined reference to `__sanitizer_cov_trace_cmpf' drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function `dcn_bw_min2': dcn_calc_math.c:(.text+0xb2): undefined reference to `__sanitizer_cov_trace_cmpf' drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function `dcn_bw_ceil2': dcn_calc_math.c:(.text+0x2a0): undefined reference to `__sanitizer_cov_trace_cmpd' drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function `dcn_bw_max3': dcn_calc_math.c:(.text+0x325): undefined reference to `__sanitizer_cov_trace_cmpf' drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function `dcn_bw_max5': dcn_calc_math.c:(.text+0x3c3): undefined reference to `__sanitizer_cov_trace_cmpf' drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_math.o: In function `dcn_bw_log': dcn_calc_math.c:(.text+0x54e): undefined reference to `__sanitizer_cov_trace_cmpd' dcn_calc_math.c:(.text+0x57c): undefined reference to `__sanitizer_cov_trace_cmpd' drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function `scaler_settings_calculation': dcn_calc_auto.c:(.text+0x5c5): undefined reference to `__sanitizer_cov_trace_cmpf' drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function `mode_support_and_system_configuration': dcn_calc_auto.c:(.text+0x137c): undefined reference to `__sanitizer_cov_trace_cmpd' drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function `mode_support_and_system_configuration': dcn_calc_auto.c:(.text+0x9233): undefined reference to `__sanitizer_cov_trace_cmpd' drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function `mode_support_and_system_configuration': dcn_calc_auto.c:(.text+0xb70f): undefined reference to `__sanitizer_cov_trace_cmpd' drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function `mode_support_and_system_configuration': dcn_calc_auto.c:(.text+0x121fd): undefined reference to `__sanitizer_cov_trace_cmpd' drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function `display_pipe_configuration': dcn_calc_auto.c:(.text+0x15a2f): undefined reference to `__sanitizer_cov_trace_cmpd' drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function `dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation': dcn_calc_auto.c:(.text+0x17c2d): undefined reference to `__sanitizer_cov_trace_cmpf' drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function `dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation': dcn_calc_auto.c:(.text+0x19362): undefined reference to `__sanitizer_cov_trace_cmpd' drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function `dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation': dcn_calc_auto.c:(.text+0x25575): undefined reference to `__sanitizer_cov_trace_cmpd' drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.o: In function `dispclkdppclkdcfclk_deep_sleep_prefetch_parameters_watermarks_and_performance_calculation': dcn_calc_auto.c:(.text+0x27f33): undefined reference to `__sanitizer_cov_trace_cmpd' drivers/gpu/drm/amd/display/dc/dml/display_rq_dlg_calc.o: In function `get_refcyc_per_delivery': display_rq_dlg_calc.c:(.text+0xb5): undefined reference to `__sanitizer_cov_trace_cmpd' drivers/gpu/drm/amd/display/dc/dml/display_rq_dlg_calc.o: In function `calculate_ttu_cursor.isra.1': display_rq_dlg_calc.c:(.text+0x9f6): undefined reference to `__sanitizer_cov_trace_cmpd' drivers/gpu/drm/amd/display/dc/dml/display_rq_dlg_calc.o: In function `dml_rq_dlg_get_dlg_params': display_rq_dlg_calc.c:(.text+0x82cc): undefined reference to `__sanitizer_cov_trace_cmpf' drivers/gpu/drm/amd/display/dc/dml/dml1_display_rq_dlg_calc.o: In function `get_refcyc_per_delivery.isra.0': dml1_display_rq_dlg_calc.c:(.text+0x6c4): undefined reference to `__sanitizer_cov_trace_cmpd' drivers/gpu/drm/amd/display/dc/dml/dml1_display_rq_dlg_calc.o: In function `get_vratio_pre.isra.2': dml1_display_rq_dlg_calc.c:(.text+0x957): undef
[Bug 104206] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:2!
https://bugs.freedesktop.org/show_bug.cgi?id=104206 --- Comment #19 from Brad Walker --- I updated to the latest version of Fedora 28 and still this problem.. FYI... -- 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 105046] Screen resolution reset to 1368x768 when turning monitor off
https://bugs.freedesktop.org/show_bug.cgi?id=105046 --- Comment #14 from Michael Zapf --- Anything new? The problem is still there, although now it falls back to a higher resolution (1920x1080), still causing a mess on my desktop. I would like to emphasize that this issue does not appear with amdgpu.dc=0. I tested it several times to make sure. I tried it with an own EDID file; picked it from the xrandr, then saved it to a file /lib/firmware/edid/mizapfmon.bin. Then I added a kernel parameter "drm.edid_firmware=edid/mizapfmon.bin". (drm_kms_helper is deprecated) During boot: Aug 12 01:07:08 capella kernel: platform HDMI-A-2: Direct firmware load for edid/mizapfmon.bin failed with error -2 Aug 12 01:07:08 capella kernel: [drm:drm_load_edid_firmware [drm]] *ERROR* Requesting EDID firmware "edid/mizapfmon.bin" failed (err=-2) I don't know whether something is missing, maybe I have to add the firmware to the initrd. But it is not required at boot time; the screen is OK at that time. When I turn the monitor off and on again, I'm getting the following lines in /var/log/messages, and the screen resolution is again reset to 1920x1080. Aug 12 01:08:27 capella kdeinit5[2024]: kscreen: canBeAppled: There are no enabled screens, at least one required Aug 12 01:08:27 capella kdeinit5[2024]: kscreen.kded: Config does not have at least one screen enabled, WILL NOT save this config, this is not what user wants. Aug 12 01:08:27 capella kernel: [drm] Got external EDID base block and 1 extension from "edid/mizapfmon.bin" for connector "HDMI-A-2" Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xcb.helper: RRNotify_OutputChange Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xcb.helper: Output: 88 Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xcb.helper: CRTC: 0 Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xcb.helper: Mode: 0 Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xcb.helper: Rotation: "Rotate_0" Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xcb.helper: Connection: "Connected" Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xcb.helper: Subpixel Order: 0 Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xcb.helper: RRScreenChangeNotify Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xcb.helper: Window: 48234501 Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xcb.helper: Root: 1728 Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xcb.helper: Rotation: "Rotate_0" Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xcb.helper: Size ID: 65535 Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xcb.helper: Size: 1920 1200 Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xcb.helper: SizeMM: 508 317 Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xcb.helper: RRNotify_OutputChange Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xcb.helper: Output: 88 Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xcb.helper: CRTC: 0 Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xcb.helper: Mode: 0 Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xcb.helper: Rotation: "Rotate_0" Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xcb.helper: Connection: "Connected" Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xcb.helper: Subpixel Order: 0 Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xrandr: XRandROutput 88 update Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xrandr: m_connected: 1 Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xrandr: m_crtc QObject(0x0) Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xrandr: CRTC: 0 Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xrandr: MODE: 0 Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xrandr: Connection: 0 Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xrandr: Primary: false Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xrandr: Output 88 : connected = true , enabled = false Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xrandr: XRandROutput 88 update Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xrandr: m_connected: 0 Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xrandr: m_crtc QObject(0x0) Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xrandr: CRTC: 0 Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xrandr: MODE: 0 Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xrandr: Connection: 0 Aug 12 01:08:27 capella kscreen_backend_launcher[2116]: kscreen.xrandr:
Re: [PATCH 2/2] arm64: dts: sdm845: Add gpu and gmu device nodes
Hi Jordan, Thank you for the patch! Yet something to improve: [auto build test ERROR on robclark/msm-next] [also build test ERROR on v4.18-rc8 next-20180810] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jordan-Crouse/arm64-dts-Add-sdm845-GPU-GMU-and-SMMU/20180811-082810 base: git://people.freedesktop.org/~robclark/linux msm-next config: arm64-defconfig (attached as .config) compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=arm64 All errors (new ones prefixed by >>): >> Error: arch/arm64/boot/dts/qcom/sdm845.dtsi:342.25-26 syntax error FATAL ERROR: Unable to parse input tree --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200621] Freezing with amdgpu driver
https://bugzilla.kernel.org/show_bug.cgi?id=200621 --- Comment #4 from Jon (jon...@gmail.com) --- Here's another example of a crash Aug 11 20:46:59 pc003 kernel: [drm] DM_MST: stopping TM on aconnector: cd25cb02 [id: 52] Aug 11 20:47:03 pc003 kernel: [drm] DM_MST: Disabling connector: 060f78e9 [id: 112] [master: cd25cb02] Aug 11 20:47:03 pc003 kernel: [drm] DM_MST: Disabling connector: 96e35190 [id: 109] [master: cd25cb02] Aug 11 20:47:03 pc003 /usr/libexec/gdm-x-session[2021]: (II) event3 - SteelSeries Sensei Raw Gaming Mouse: SYN_DROPPED event - some input events have been lost. Aug 11 20:47:03 pc003 /usr/libexec/gdm-x-session[2021]: (II) modeset(0): EDID vendor "DEL", prod id 41146 Aug 11 20:47:03 pc003 /usr/libexec/gdm-x-session[2021]: (II) modeset(0): Using hsync ranges from config file Aug 11 20:47:03 pc003 /usr/libexec/gdm-x-session[2021]: (II) modeset(0): Using vrefresh ranges from config file Aug 11 20:47:03 pc003 /usr/libexec/gdm-x-session[2021]: (II) modeset(0): Printing DDC gathered Modelines: Aug 11 20:47:03 pc003 /usr/libexec/gdm-x-session[2021]: (II) modeset(0): Modeline "1920x1200"x0.0 154.00 1920 1968 2000 2080 1200 1203 1209 1235 +hsync +vsync (74.0 kHz eP) Aug 11 20:47:03 pc003 /usr/libexec/gdm-x-session[2021]: (II) modeset(0): Modeline "1920x1080"x0.0 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync (67.5 kHz e) Aug 11 20:47:03 pc003 /usr/libexec/gdm-x-session[2021]: (II) modeset(0): Modeline "1920x1080i"x0.0 74.25 1920 2008 2052 2200 1080 1084 1094 1125 interlace +hsync +vsync (33.8 kHz e) Aug 11 20:47:03 pc003 /usr/libexec/gdm-x-session[2021]: (II) modeset(0): Modeline "1280x720"x0.0 74.25 1280 1390 1430 1650 720 725 730 750 +hsync +vsync (45.0 kHz e) Aug 11 20:47:03 pc003 /usr/libexec/gdm-x-session[2021]: (II) modeset(0): Modeline "720x480"x0.0 27.00 720 736 798 858 480 489 495 525 -hsync -vsync (31.5 kHz e) Aug 11 20:47:03 pc003 /usr/libexec/gdm-x-session[2021]: (II) modeset(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) Aug 11 20:47:03 pc003 /usr/libexec/gdm-x-session[2021]: (II) modeset(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz e) Aug 11 20:47:03 pc003 /usr/libexec/gdm-x-session[2021]: (II) modeset(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e) Aug 11 20:47:03 pc003 /usr/libexec/gdm-x-session[2021]: (II) modeset(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz e) Aug 11 20:47:03 pc003 /usr/libexec/gdm-x-session[2021]: (II) modeset(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz e) Aug 11 20:47:03 pc003 /usr/libexec/gdm-x-session[2021]: (II) modeset(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz e) Aug 11 20:47:03 pc003 /usr/libexec/gdm-x-session[2021]: (II) modeset(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) Aug 11 20:47:03 pc003 /usr/libexec/gdm-x-session[2021]: (II) modeset(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz e) Aug 11 20:47:03 pc003 /usr/libexec/gdm-x-session[2021]: (II) modeset(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz e) Aug 11 20:47:03 pc003 /usr/libexec/gdm-x-session[2021]: (II) modeset(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz e) Aug 11 20:47:03 pc003 /usr/libexec/gdm-x-session[2021]: (II) modeset(0): Modeline "1600x1200"x0.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz e) Aug 11 20:47:03 pc003 /usr/libexec/gdm-x-session[2021]: (II) modeset(0): Modeline "1920x1080"x60.0 172.80 1920 2040 2248 2576 1080 1081 1084 1118 -hsync +vsync (67.1 kHz e) Aug 11 20:47:03 pc003 /usr/libexec/gdm-x-session[2021]: (II) modeset(0): Modeline "1920x1200"x0.0 154.00 1920 1968 2000 2080 1200 1203 1209 1235 +hsync -vsync (74.0 kHz e) Aug 11 20:47:03 pc003 /usr/libexec/gdm-x-session[2021]: (II) modeset(0): Modeline "1440x480i"x0.0 27.00 1440 1478 1602 1716 480 488 494 525 interlace -hsync -vsync (15.7 kHz e) Aug 11 20:47:03 pc003 /usr/libexec/gdm-x-session
