Re: [PATCH 2/6] drm/exynos: dsi: Use drm_bridge_detach
19. 3. 15. 오후 10:08에 Jagan Teki 이(가) 쓴 글:
> drm_bridge_detach now available to use while detaching
> bridge, use this core wrapper instead of explicitly
> pointing the bridge funcs.
>
> Cc: Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Signed-off-by: Jagan Teki
Acked-by: Inki Dae
Thanks,
Inki Dae
> ---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index a4253dd55f86..5daf43d02768 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1583,8 +1583,7 @@ static int exynos_dsi_host_detach(struct mipi_dsi_host
> *host,
> dsi->connector.status = connector_status_disconnected;
> mutex_unlock(>mode_config.mutex);
> } else {
> - if (dsi->out_bridge->funcs->detach)
> - dsi->out_bridge->funcs->detach(dsi->out_bridge);
> + drm_bridge_detach(dsi->out_bridge);
> dsi->out_bridge = NULL;
> }
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110142] "Oops: Kernel access of bad area sig 7" on Kernel 5.0.0 PPC64LE when loading amdgpu, xorg hangs after being unable to load after OS boots.
https://bugs.freedesktop.org/show_bug.cgi?id=110142 --- Comment #6 from Peter Easton --- Whoops, hit return too quickly. (In reply to Michel Dänzer from comment #3) > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > ?id=c713a461459202504050305242cd854bad57837c seems the most likely > candidate, it's the only significant change to gmc_v9_0_late_init between > 4.20 and 5.0. Sure. I'll go and give this one a try first, actually. I'm out of time for the night but I can hop back on it first thing tomorrow. -- 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 110142] "Oops: Kernel access of bad area sig 7" on Kernel 5.0.0 PPC64LE when loading amdgpu, xorg hangs after being unable to load after OS boots.
https://bugs.freedesktop.org/show_bug.cgi?id=110142 --- Comment #5 from Peter Easton --- I'm going to try to see if I can narrow things down a bit by finding the last commit that worked before the bug happened and then bisect the kernel there. I'm going to try to compile the kernels, install them, and then try rebooting and starting xfce4 one by one until I find the one that won't start. I apologize in advance for the sluggishness, there are a lot of commits here and the computer boots very slowly, so this puts a bit of a bottleneck on how many kernels I can test in a given timeframe. I'll try to hurry as best I can and I'll try to keep this thread updated as I make progress on it. Right now I think I'll start at commit af0df68432f65915b2a316aa99eeeb588d4c65a2 since that one works, and I'll start working my way towards 5.0.0 from there to see if I can narrow down the right commit that borked the driver. > I guess the problem is actually in gmc_v9_0_allocate_vm_inv_eng though. > Peter, what does...[truncated] Sure. 5.0.2, which gave us that dmesg output, returned to this message when I tried to enter the commands as followed, this is what the screen looks like: > captain@morgans-revenge /usr/src/linux-5.0.2-gentoo/scripts $ ./faddr2line > ../drivers/gpu/drm/amd/amdgpu/amdgpu.ko > gmc_v9_0_late_init+0x114/0x500 > gmc_v9_0_late_init+0x114/0x500: > gmc_v9_0_late_init at gmc_v9_0.c:? > captain@morgans-revenge /usr/src/linux-5.0.2-gentoo/scripts $ I hope this might be what you are looking for? I wasn't sure what to enter so I looked for the drivers folder and then typed the rest in as it was. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Aw: Re: [PATCH 2/2] drm/mediatek: Add Mediatek framebuffer device
Hi, Frank: My platform's fbcon works correctly, so I've applied this series to [1]. If you have another patch, I'd treat it as a bug-fix. [1] https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-fixes-5.1 Regards, CK On Sun, 2019-01-20 at 14:36 +0100, Frank Wunderlich wrote: > Tested with mmsys-Patch, but same result, no fbcon, tft is switched on but i > see no kernel-log > > after boot is finished, i see X-server, until this point i see only black > screen > > regards Frank > > > > Gesendet: Freitag, 18. Januar 2019 um 09:39 Uhr > > Von: "Matthias Brugger" > > may it be the not yet fixed mmsys compatible problem? > > Frank, did you test with my last series [1]? > > [1] https://patchwork.kernel.org/cover/10686345/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH 5/6] drm/bridge: Add Chipone ICN6211 MIPI-DSI/RGB convertor bridge
On Tue, Mar 19, 2019 at 1:59 AM Jagan Teki wrote:
>
> On Fri, Mar 15, 2019 at 7:03 PM Maxime Ripard
> wrote:
> >
> > On Fri, Mar 15, 2019 at 06:38:24PM +0530, Jagan Teki wrote:
> > > ICN6211 is MIPI-DSI/RGB converter bridge from chipone.
> > > It has a flexible configuration of MIPI DSI signal input
> > > and produce RGB565, RGB666, RGB888 output format.
> > >
> > > Add bridge driver for it.
> > >
> > > Signed-off-by: Jagan Teki
> > > ---
> > > MAINTAINERS | 6 +
> > > drivers/gpu/drm/bridge/Kconfig | 10 +
> > > drivers/gpu/drm/bridge/Makefile | 1 +
> > > drivers/gpu/drm/bridge/chipone-icn6211.c | 275 +++
> > > 4 files changed, 292 insertions(+)
> > > create mode 100644 drivers/gpu/drm/bridge/chipone-icn6211.c
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 4de80222cffb..e529addd30f5 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -4897,6 +4897,12 @@ T: git
> > > git://anongit.freedesktop.org/drm/drm-misc
> > > S: Maintained
> > > F: drivers/gpu/drm/bochs/
> > >
> > > +DRM DRIVER FOR CHIPONE ICN6211 MIPI-DSI to RGB CONVERTOR BRIDGE
> > > +M: Jagan Teki
> > > +S: Maintained
> > > +F: drivers/gpu/drm/bridge/chipone-icn6211.c
> > > +F: Documentation/devicetree/bindings/display/bridge/chipone,icn6211.txt
> > > +
> > > DRM DRIVER FOR FARADAY TVE200 TV ENCODER
> > > M: Linus Walleij
> > > T: git git://anongit.freedesktop.org/drm/drm-misc
> > > diff --git a/drivers/gpu/drm/bridge/Kconfig
> > > b/drivers/gpu/drm/bridge/Kconfig
> > > index 8840f396a7b6..cd314572e4ed 100644
> > > --- a/drivers/gpu/drm/bridge/Kconfig
> > > +++ b/drivers/gpu/drm/bridge/Kconfig
> > > @@ -36,6 +36,16 @@ config DRM_CDNS_DSI
> > > Support Cadence DPI to DSI bridge. This is an internal
> > > bridge and is meant to be directly embedded in a SoC.
> > >
> > > +config DRM_CHIPONE_ICN6211
> > > + tristate "Chipone ICN6211 MIPI-DSI/RGB converter bridge"
> > > + depends on DRM && DRM_PANEL
> > > + depends on OF
> > > + select DRM_MIPI_DSI
> > > + help
> > > + ICN6211 is MIPI-DSI/RGB converter bridge from chipone.
> > > + It has a flexible configuration of MIPI DSI signal input
> > > + and produce RGB565, RGB666, RGB888 output format.
> > > +
> > > config DRM_DUMB_VGA_DAC
> > > tristate "Dumb VGA DAC Bridge support"
> > > depends on OF
> > > diff --git a/drivers/gpu/drm/bridge/Makefile
> > > b/drivers/gpu/drm/bridge/Makefile
> > > index 4934fcf5a6f8..541fdccad10b 100644
> > > --- a/drivers/gpu/drm/bridge/Makefile
> > > +++ b/drivers/gpu/drm/bridge/Makefile
> > > @@ -1,6 +1,7 @@
> > > # SPDX-License-Identifier: GPL-2.0
> > > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> > > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> > > +obj-$(CONFIG_DRM_CHIPONE_ICN6211) += chipone-icn6211.o
> > > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
> > > obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
> > > obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
> > > megachips-stdp-ge-b850v3-fw.o
> > > diff --git a/drivers/gpu/drm/bridge/chipone-icn6211.c
> > > b/drivers/gpu/drm/bridge/chipone-icn6211.c
> > > new file mode 100644
> > > index ..cd2f3505f845
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/bridge/chipone-icn6211.c
> > > @@ -0,0 +1,275 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * Copyright (C) 2018 Amarula Solutions
> > > + * Author: Jagan Teki
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +#define ICN6211_INIT_CMD_LEN 2
> > > +
> > > +struct chipone {
> > > + struct device *dev;
> > > + struct drm_bridge bridge;
> > > + struct drm_connector connector;
> > > + struct drm_panel *panel;
> > > +
> > > + struct gpio_desc *reset;
> > > +};
> > > +
> > > +static inline struct chipone *bridge_to_chipone(struct drm_bridge
> > > *bridge)
> > > +{
> > > + return container_of(bridge, struct chipone, bridge);
> > > +}
> > > +
> > > +static inline
> > > +struct chipone *connector_to_chipone(struct drm_connector *connector)
> > > +{
> > > + return container_of(connector, struct chipone, connector);
> > > +}
> > > +
> > > +struct icn6211_init_cmd {
> > > + u8 data[ICN6211_INIT_CMD_LEN];
> > > +};
> > > +
> > > +static const struct icn6211_init_cmd icn6211_init_cmds[] = {
> > > + { .data = { 0x7A, 0xC1 } },
> > > + { .data = { 0x20, 0x20 } },
> > > + { .data = { 0x21, 0xE0 } },
> > > + { .data = { 0x22, 0x13 } },
> > > + { .data = { 0x23, 0x28 } },
> > > + { .data = { 0x24, 0x30 } },
> > > + { .data = { 0x25, 0x28 } },
> > > + { .data = { 0x26, 0x00 } },
> > > + { .data = { 0x27, 0x0D } },
> > > + { .data = { 0x28, 0x03 } },
> > > + { .data = {
Re: [linux-sunxi] Re: [PATCH 4/6] dt-bindings: display: bridge: Add ICN6211 MIPI-DSI to RGB convertor bridge
On Tue, Mar 19, 2019 at 12:58 AM Jagan Teki wrote: > > On Fri, Mar 15, 2019 at 7:04 PM Maxime Ripard > wrote: > > > > On Fri, Mar 15, 2019 at 06:38:23PM +0530, Jagan Teki wrote: > > > ICN6211 is MIPI-DSI/RGB converter bridge from chipone. > > > It has a flexible configuration of MIPI DSI signal input > > > and produce RGB565, RGB666, RGB888 output format. > > > > > > Add dt-bingings for it. > > > > > > Signed-off-by: Jagan Teki > > > --- > > > .../display/bridge/chipone,icn6211.txt| 36 +++ > > > 1 file changed, 36 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/display/bridge/chipone,icn6211.txt > > > > > > diff --git > > > a/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.txt > > > b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.txt > > > new file mode 100644 > > > index ..7f13efd7ee7f > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.txt > > > @@ -0,0 +1,36 @@ > > > +Chipone ICN6211 MIPI-DSI to RGB Convertor Bridge > > > + > > > +ICN6211 is MIPI-DSI/RGB converter bridge from chipone. > > > +It has a flexible configuration of MIPI DSI signal input > > > +and produce RGB565, RGB666, RGB888 output format. > > > + > > > +Required properties for RGB: > > > +- compatible: must be "chipone,icn6211" and one of: > > > + * "bananapi,icn6211" > > > > Why is that compatible needed? > > chipone,icn6211 - generic compatible bridge controller IC > bananapi,icn6211 - compatible for icn6211 bridge using on bananapi panel > > I hope this would be proper bindings in terms of controller IC with > associate device, anything wrong? Infact I used similar reference from > Ilitek Bananapi panel from here > Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt > > This is what I understood based on dt-binding, correct if I'm wrong. > > ilitek,ili9881c - generic ilitek,ili9881c compatable > bananapi,lhr050h41 - compatible for bananapi panel associated with > this ilitek IC ili9881c is an LCD driver chip with a MIPI DSI interface. It directly drives the LCD panel, not outputting some RGB stuff. So it is a binding and driver for a panel, not a bridge in your case. > > > > > +- reg: the virtual channel number of a DSI peripheral > > > +- reset-gpios: a GPIO phandle for the reset pin > > > + > > > +The device node can contain following 'port' child nodes, > > > +according to the OF graph bindings defined in [1]: > > > + 0: DSI Input, not required, if the bridge is DSI controlled > > > + 1: RGB Output, mandatory > > > > Your example doesn't have that input port > > Yes, I intentionally did this by referring existing bridge binding. > Documentation/devicetree/bindings/display/bridge/toshiba,tc35876*.txt > > Do we really need? since the input port can be part of panel binding. How could the input port of _your_ _bridge_ be part of the panel binding? ChenYu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110184] kernel BUG at drivers/dma-buf/reservation.c:172 (kernel 5.0.2)
https://bugs.freedesktop.org/show_bug.cgi?id=110184 Bug ID: 110184 Summary: kernel BUG at drivers/dma-buf/reservation.c:172 (kernel 5.0.2) Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: jane...@ucw.cz Created attachment 143730 --> https://bugs.freedesktop.org/attachment.cgi?id=143730=edit dmesg kernel BUG at drivers/dma-buf/reservation.c:172! invalid opcode: [#1] SMP PTI CPU: 2 PID: 2228 Comm: Compiz:rcs0 Not tainted 5.0.2 #18 Hardware name: /DG45ID, BIOS IDG4510H.86A.0135.2011.0225.1100 02/25/2011 RIP: 0010:reservation_object_add_shared_fence+0x166/0x180 Code: e0 9c 9f 79 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e 41 5f c3 89 e8 41 8b 4d 14 48 8d 04 c5 18 00 00 00 83 c5 01 41 39 4d 10 72 aa <0f> 0b b8 18 00 00 00 e9 7c ff ff ff 31 c0 eb db 66 2e 0f 1f 84 00 RSP: 0018:a141c1d779d0 EFLAGS: 00010246 RAX: 0028 RBX: 8cbb1875c240 RCX: 0002 RDX: 0003 RSI: 8cbc18cb0078 RDI: 8cbbe7542e30 RBP: 0003 R08: R09: 8cbc18cb0078 R10: 8cbbe7542e08 R11: 8cbbe7542500 R12: 8cbb1875c840 R13: 8cbbebaa95c0 R14: 8cbbebaa95e8 R15: 0002 FS: 7fa698127700() GS:8cbc23b0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 5556808cc000 CR3: 0001e743a000 CR4: 000406e0 Call Trace: ttm_eu_fence_buffer_objects+0x90/0x110 [ttm] radeon_cs_parser_fini+0x10f/0x120 [radeon] radeon_cs_ioctl+0x113/0x7d0 [radeon] ? radeon_cs_parser_init+0x20/0x20 [radeon] drm_ioctl_kernel+0xaa/0xf0 [drm] drm_ioctl+0x2e6/0x3a0 [drm] ? radeon_cs_parser_init+0x20/0x20 [radeon] radeon_drm_ioctl+0x49/0x80 [radeon] do_vfs_ioctl+0xa5/0x6e0 ? __fget+0xb2/0xe0 ksys_ioctl+0x70/0x80 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x55/0x170 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fa6b6cd85d7 Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 f7 d8 64 89 01 48 RSP: 002b:7fa698126db8 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 555680704d20 RCX: 7fa6b6cd85d7 RDX: 555680714d28 RSI: c0206466 RDI: 000d RBP: 555680714d28 R08: R09: R10: R11: 0246 R12: c0206466 R13: 000d R14: R15: 55568076aa30 Modules linked in: snd_hda_codec_idt snd_hda_codec_generic ipmi_devintf ipmi_msghandler binfmt_misc uvcvideo xfs videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common snd_usb_audio videodev snd_usbmidi_lib snd_hda_codec_hdmi snd_hda_intel snd_hda_codec coretemp snd_hwdep snd_hda_core snd_pcm kvm_intel kvm snd_seq_midi radeon snd_seq_midi_event irqbypass ttm snd_rawmidi drm_kms_helper serio_raw snd_seq syscopyarea sysfillrect snd_seq_device sysimgblt fb_sys_fops snd_timer drm drm_panel_orientation_quirks i2c_algo_bit snd lpc_ich mfd_core video soundcore sch_fq_codel cuse ip_tables x_tables autofs4 hid_generic usbhid hid e1000e ptp pps_core -- 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 103430] vbithyd.ac.in/contactus/spell
https://bugs.freedesktop.org/show_bug.cgi?id=103430 Andre Klapper changed: What|Removed |Added Group||spam Component|DRM/amdkfd |Two Version|DRI git |unspecified Product|DRI |Spam -- 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
linux-next: manual merge of the drm-misc tree with the drm-intel tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/intel_hdmi.c
between commit:
fbf08556ed43 ("drm/i915: Precompute HDMI infoframes")
from the drm-intel tree and commit:
2f146b78d5a9 ("drm/i915: Attach colorspace property and enable modeset")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/i915/intel_hdmi.c
index ecfec5d3292e,765718b606d8..
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@@ -638,70 -469,39 +638,72 @@@ static void intel_write_infoframe(struc
buffer[3] = 0;
len++;
- intel_dig_port->write_infoframe(encoder,
- crtc_state,
- frame->any.type, buffer, len);
+ intel_dig_port->write_infoframe(encoder, crtc_state, type, buffer, len);
}
-static void intel_hdmi_set_avi_infoframe(struct intel_encoder *encoder,
- const struct intel_crtc_state
*crtc_state,
- const struct drm_connector_state
*conn_state)
+void intel_read_infoframe(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state,
+enum hdmi_infoframe_type type,
+union hdmi_infoframe *frame)
{
+ struct intel_digital_port *intel_dig_port =
enc_to_dig_port(>base);
+ u8 buffer[VIDEO_DIP_DATA_SIZE];
+ int ret;
+
+ if ((crtc_state->infoframes.enable &
+ intel_hdmi_infoframe_enable(type)) == 0)
+ return;
+
+ intel_dig_port->read_infoframe(encoder, crtc_state,
+ type, buffer, sizeof(buffer));
+
+ /* Fill the 'hole' (see big comment above) at position 3 */
+ memmove([1], [0], 3);
+
+ /* see comment above for the reason for this offset */
+ ret = hdmi_infoframe_unpack(frame, buffer + 1, sizeof(buffer) - 1);
+ if (ret) {
+ DRM_DEBUG_KMS("Failed to unpack infoframe type 0x%02x\n", type);
+ return;
+ }
+
+ if (frame->any.type != type)
+ DRM_DEBUG_KMS("Found the wrong infoframe type 0x%x (expected
0x%02x)\n",
+frame->any.type, type);
+}
+
+static bool
+intel_hdmi_compute_avi_infoframe(struct intel_encoder *encoder,
+ struct intel_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state)
+{
+ struct hdmi_avi_infoframe *frame = _state->infoframes.avi.avi;
const struct drm_display_mode *adjusted_mode =
_state->base.adjusted_mode;
- union hdmi_infoframe frame;
+ struct drm_connector *connector = conn_state->connector;
int ret;
- ret = drm_hdmi_avi_infoframe_from_display_mode(,
- conn_state->connector,
+ if (!crtc_state->has_infoframe)
+ return true;
+
+ crtc_state->infoframes.enable |=
+ intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_AVI);
+
+ ret = drm_hdmi_avi_infoframe_from_display_mode(frame, connector,
adjusted_mode);
- if (ret < 0) {
- DRM_ERROR("couldn't fill AVI infoframe\n");
- return;
- }
+ if (ret)
+ return false;
if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
- frame.avi.colorspace = HDMI_COLORSPACE_YUV420;
+ frame->colorspace = HDMI_COLORSPACE_YUV420;
else if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444)
- frame.avi.colorspace = HDMI_COLORSPACE_YUV444;
+ frame->colorspace = HDMI_COLORSPACE_YUV444;
else
- frame.avi.colorspace = HDMI_COLORSPACE_RGB;
+ frame->colorspace = HDMI_COLORSPACE_RGB;
- drm_hdmi_avi_infoframe_colorspace(, conn_state);
++ drm_hdmi_avi_infoframe_colorspace(frame, conn_state);
+
- drm_hdmi_avi_infoframe_quant_range(,
- conn_state->connector,
+ drm_hdmi_avi_infoframe_quant_range(frame, connector,
adjusted_mode,
crtc_state->limited_color_range ?
HDMI_QUANTIZATION_RANGE_LIMITED :
pgp3dIDahDXoZ.pgp
Description: OpenPGP digital signature
[Bug 109370] [Runelite GPU plugin] Enabling GPU plugin produces incorrect rendering
https://bugs.freedesktop.org/show_bug.cgi?id=109370 --- Comment #5 from Tom Seewald --- Have the LLVM developers been notified of this, and if so, can you provide a link to the report? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 01/10] drm/fourcc: Add AFBC yuv fourccs for Mali
On Mon, Mar 18, 2019 at 07:12:24PM +0100, Maarten Lankhorst wrote: > Op 18-03-2019 om 16:40 schreef Brian Starkey: > > Hi, > > > > On Mon, Mar 18, 2019 at 11:17:55AM +0100, Maarten Lankhorst wrote: > > > > > > > >> Hey.. > >> > >> There's a conflict with this patch and the merge of topic/hdr-formats, > >> resulting in double definitions for Y210, Y410 and P010. > >> > >> Worse still is that one has set has_alpha to true for Y41x and other to > >> false. > >> > >> ~Maarten > >> > > Oh that's sad :-( I think this fell through the cracks on our side > > when someone left our team. Also turns out I'm not subscribed to > > igt-dev. > > > > I see you commented the same on one of the previous patches, and that > > there was some discussion of this on the test patches too. > > > > I have been referring to Microsoft's page[1] as "the" source for these > > formats, which does indeed call out Y410 as having 2 bits of alpha. > > Our GPU expects alpha. > > Ah. Yeah there has been discussion on whether there was supposed to be alpha > or not, but the original discussion on HDR formats has been completely > ignored by arm. > > The patch had originally a few arm devs on cc and was sent to dri-devel with > linux-media cc'd. Was sad to see it completely ignored so after having been > sent twice I pushed it. Apologies, I see that I was cc-ed in the mail 'drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc' sent by swati2.sha...@intel.com. It got lost in my pile of unread mails. :( About this patch, I had tagged you in irc channel (https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel_names==2019-03-11_html=true) for reviewing this seies. Did not hear back from you then ? > > > Was there a specific reason for opting to change the test instead of > > the definition? Any way to get this changed now? > > > > It doesn't seem that sensible for the kernel to call something Y410 > > which doesn't match an "existing" definition by the same name. If > > alpha needs to be ignored on scanout, the alpha blend mode property > > can be used (more archaeology - I see that was still giving CRC > > failures, but that might be a "known issue" for all YUV on your HW?) > > Were a few bugs, but should be fixed now. :) > > Well only that we didn't have hw supporting alpha, and didn't hear back from > others so we went without alpha. In light of the suggestions made by brian.star...@arm.com, I think changing the format from Y410 to X410 (in your case) might make sense as the alpha bits are absent. If this suggestion looks reasonable to you, I can volunteer myself to make this change in topic/hdr-formats. > > > -Brian > > > > [1] > > https://docs.microsoft.com/en-us/windows/desktop/medfound/10-bit-and-16-bit-yuv-video-formats#444-formats > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107296] WARNING: CPU: 0 PID: 370 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1355 dcn_bw_update_from_pplib+0x16b/0x280 [amdgpu]
https://bugs.freedesktop.org/show_bug.cgi?id=107296 --- Comment #10 from jzahra...@gmail.com --- Testing Linux 5.1-rc1, error still present. -- 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 103430] vbithyd.ac.in/contactus/spell
https://bugs.freedesktop.org/show_bug.cgi?id=103430 lonelywoolf changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED -- 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 106571] Stoney [Radeon R5 Graphics] [1002:98E4] hangs on hibernate
https://bugs.freedesktop.org/show_bug.cgi?id=106571 --- Comment #2 from lonelywoolf --- suspend works ok. Only hibernate hanging. -- 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 106571] Stoney [Radeon R5 Graphics] [1002:98E4] hangs on hibernate
https://bugs.freedesktop.org/show_bug.cgi?id=106571 lonelywoolf changed: What|Removed |Added Component|DRM/AMDgpu |DRM/amdkfd Severity|normal |major --- Comment #1 from lonelywoolf --- Still not working on 5.1-rc1. Also tested 4.18, 4.19. 5.0. I tried some debug, and as I can see, system freezes after error = dpm_suspend(PMSG_FREEZE); in hibernate.c System is A10-9600p + R7 M440. With nomodeset or without amdgpu system hibernates, but completely unusable. Same bug searched with AMD FX-9830P + RX560, and AMD A10-8700P. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: randr: Virtual monitor not present with MST display
Dear Harry, On 18.03.19 21:55, Wentland, Harry wrote: On 2019-03-08 4:11 a.m., Michel Dänzer wrote: On 2019-03-06 5:35 p.m., Paul Menzel wrote: On 03/06/19 15:55, Michel Dänzer wrote: On 2019-03-06 1:41 p.m., Paul Menzel wrote: On 03/05/19 20:07, Alex Deucher wrote: On Tue, Mar 5, 2019 at 1:16 PM Paul Menzel wrote: Using the MST display Dell UP3214Q (two panels) with an AMD system, the virtual monitor object is not created. GDM and Xfce consider both panels as separate screens (`xrandr --listmonitors`). [...] I didn’t provide the output of xrandr in my previous message. $ xrandr --listmonitors Monitors: 2 0: +DisplayPort-9 1920/698x2160/392+0+0 DisplayPort-9 1: +DisplayPort-10 1920/698x2160/392+1920+0 DisplayPort-10 Please find the X.Org X Server log attached. With an Intel system, the monitor object is shown. To clarify, the modesetting driver is used with the Intel hardware. Does this work better with the modesetting driver on the AMD system? With Linux 4.19.19, there was the same problem with the modesetting driver during my limited testing. Updating to Linux 4.20.13, it worked with the modesetting driver, but the AMDGPU driver still failed to properly utilize the MST monitor. Does https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/32 help? Michel, do you know if this is supposed to work with xf86-video-amdgpu? When I've tried it before I didn't have any luck but didn't have time to look into it. Sorry, what is your question. With the commit from the merge request applied it works here. Also, the commit was added to the master branch in the mean time. Kind regards, Paul ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: randr: Virtual monitor not present with MST display
On 2019-03-08 4:11 a.m., Michel Dänzer wrote: > On 2019-03-06 5:35 p.m., Paul Menzel wrote: >> On 03/06/19 15:55, Michel Dänzer wrote: >>> On 2019-03-06 1:41 p.m., Paul Menzel wrote: On 03/05/19 20:07, Alex Deucher wrote: > On Tue, Mar 5, 2019 at 1:16 PM Paul Menzel wrote: >> Using the MST display Dell UP3214Q (two panels) with an AMD system, >> the virtual monitor object is not created. GDM and Xfce consider both >> panels as separate screens (`xrandr --listmonitors`). >> >> [...] I didn’t provide the output of xrandr in my previous message. $ xrandr --listmonitors Monitors: 2 0: +DisplayPort-9 1920/698x2160/392+0+0 DisplayPort-9 1: +DisplayPort-10 1920/698x2160/392+1920+0 DisplayPort-10 Please find the X.Org X Server log attached. >> With an Intel system, the monitor object is shown. To clarify, the modesetting driver is used with the Intel hardware. >>> >>> Does this work better with the modesetting driver on the AMD system? >> >> With Linux 4.19.19, there was the same problem with the modesetting driver >> during my limited testing. >> >> Updating to Linux 4.20.13, it worked with the modesetting driver, but the >> AMDGPU driver still failed to properly utilize the MST monitor. > > Does > https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/merge_requests/32 > help? > Michel, do you know if this is supposed to work with xf86-video-amdgpu? When I've tried it before I didn't have any luck but didn't have time to look into it. Harry > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/msm: Cleanup A6XX opp-level reading
Hi,
On Wed, Jan 16, 2019 at 10:46 AM Douglas Anderson wrote:
>
> The patch ("OPP: Add support for parsing the 'opp-level' property")
> adds an API enabling a cleaner way to read the opp-level. Let's use
> the new API.
>
> Signed-off-by: Douglas Anderson
> Reviewed-by: Jordan Crouse
> ---
> Obviously this can't land until we have a tree that contains the patch
> adding the API. I believe that means we'll want to target this patch
> for 5.2. Luckily it's fine to wait since this patch has no functional
> changes--it's all cleanup.
>
> Changes in v2:
> - Split into two patches to facilitate landing.
>
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 17 ++---
> 1 file changed, 6 insertions(+), 11 deletions(-)
FWIW I think this patch is ready to land any time. That commit
5b93ac542301 ("OPP: Add support for parsing the 'opp-level' property")
is now in linux/master.
-Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 6/6] clk: hi6220: use CLK_OF_DECLARE_DRIVER
Quoting Peter Griffin (2019-03-18 12:38:51) > As now we also need to probe in the reset driver as well. > > Signed-off-by: Peter Griffin > --- > drivers/clk/hisilicon/clk-hi6220.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Doesn't this need to be squashed with the reset driver bits so we don't have a bisection hole? > > diff --git a/drivers/clk/hisilicon/clk-hi6220.c > b/drivers/clk/hisilicon/clk-hi6220.c > index a87809d..952ffe2 100644 > --- a/drivers/clk/hisilicon/clk-hi6220.c > +++ b/drivers/clk/hisilicon/clk-hi6220.c > @@ -89,7 +89,7 @@ static void __init hi6220_clk_ao_init(struct device_node > *np) > hisi_clk_register_gate_sep(hi6220_separated_gate_clks_ao, > ARRAY_SIZE(hi6220_separated_gate_clks_ao), > clk_data_ao); > } > -CLK_OF_DECLARE(hi6220_clk_ao, "hisilicon,hi6220-aoctrl", hi6220_clk_ao_init); > +CLK_OF_DECLARE_DRIVER(hi6220_clk_ao, "hisilicon,hi6220-aoctrl", > hi6220_clk_ao_init); Can you also add a comment indicating why/what is the other driver that is probing the same device node? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109763] [radeonsi] Enable framerate capping
https://bugs.freedesktop.org/show_bug.cgi?id=109763 --- Comment #14 from Shmerl --- (In reply to Kristoffer from comment #13) > I believe Chill might be encumbered by patents so I'm not sure an open > source implementation is legally possible. > > https://patents.google.com/patent/US20080055318A1/ > > It's also quite a bit more complicated than a static framerate limiter, > requiring monitoring of on-screen movement and input events to constantly > evaluate what framerate is appropriate in each moment. > > A static framerate limiter would be nice though, but we already have > libstrangle for that which works well most of the time. I'd day better to have it upstream than separate, besides it's not always working, especially for Vulkan. In regards to patents, that's something that always can happen - you can never be sure. If you are worried about that specific one from AMD, AMD can be contacted about it. After all it's in their interest not to cause troubles to Linux graphics stack. -- 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 107731] radeon (amdgpu) DisplayPort loss of max-resolution on DP monitor (after monitor power saving / idle)
https://bugs.freedesktop.org/show_bug.cgi?id=107731 --- Comment #6 from Harry Wentland --- Thanks. This is definitely a link training failure. Can you see if your monitor is set to auto-select the input and force it to select the DP input? Some monitors don't respond well to link training when auto-cycling the inputs? -- 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 109763] [radeonsi] Enable framerate capping
https://bugs.freedesktop.org/show_bug.cgi?id=109763 Kristoffer changed: What|Removed |Added CC||bri...@outlook.com --- Comment #13 from Kristoffer --- I believe Chill might be encumbered by patents so I'm not sure an open source implementation is legally possible. https://patents.google.com/patent/US20080055318A1/ It's also quite a bit more complicated than a static framerate limiter, requiring monitoring of on-screen movement and input events to constantly evaluate what framerate is appropriate in each moment. A static framerate limiter would be nice though, but we already have libstrangle for that which works well most of the time. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vkms: Solve bug on kms_crc_cursor tests
On 03/15, Ville Syrjälä wrote:
> On Fri, Mar 15, 2019 at 08:51:57AM -0300, Rodrigo Siqueira wrote:
> > On 03/11, Ville Syrjälä wrote:
> > > On Sun, Mar 10, 2019 at 05:35:05PM -0300, Rodrigo Siqueira wrote:
> > > > On 03/01, Ville Syrjälä wrote:
> > > > > On Fri, Mar 01, 2019 at 03:35:35PM -0300, Shayenne Moura wrote:
> > > > > > Em sex, 1 de mar de 2019 às 12:26, Ville Syrjälä
> > > > > > escreveu:
> > > > > > >
> > > > > > > On Fri, Mar 01, 2019 at 11:55:11AM -0300, Shayenne Moura wrote:
> > > > > > > > Em qui, 28 de fev de 2019 às 11:03, Ville Syrjälä
> > > > > > > > escreveu:
> > > > > > > > >
> > > > > > > > > On Thu, Feb 28, 2019 at 11:11:07AM +0100, Daniel Vetter wrote:
> > > > > > > > > > On Mon, Feb 25, 2019 at 11:26:06AM -0300, Shayenne Moura
> > > > > > > > > > wrote:
> > > > > > > > > > > vkms_crc_work_handle needs the value of the actual frame
> > > > > > > > > > > to
> > > > > > > > > > > schedule the workqueue that calls periodically the vblank
> > > > > > > > > > > handler and the destroy state functions. However, the
> > > > > > > > > > > frame
> > > > > > > > > > > value returned from vkms_vblank_simulate is updated and
> > > > > > > > > > > diminished in vblank_get_timestamp because it is not in a
> > > > > > > > > > > vblank interrupt, and return an inaccurate value.
> > > > > > > > > > >
> > > > > > > > > > > Solve this getting the actual vblank frame directly from
> > > > > > > > > > > the
> > > > > > > > > > > vblank->count inside the `struct drm_crtc`, instead of
> > > > > > > > > > > using
> > > > > > > > > > > the `drm_accurate_vblank_count` function.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Shayenne Moura
> > > > > > > > > >
> > > > > > > > > > Sorry for the delay, I'm a bit swamped right now :-/
> > > > > > > > > >
> > > > > > > > > > Debug work you're doing here is really impressive! But I
> > > > > > > > > > have no idea
> > > > > > > > > > what's going on. It doesn't look like it's just papering
> > > > > > > > > > over a bug (like
> > > > > > > > > > the in_vblank_irq check we've discussed on irc), but I also
> > > > > > > > > > have no idea
> > > > > > > > > > why it works.
> > > > > > > > > >
> > > > > > > > > > I'll pull in Ville, he understands this better than me.
> > > > > > > > >
> > > > > > > > > It's not entirely clear what we're trying to fix. From what I
> > > > > > > > > can see
> > > > > > > > > the crc work seems to be in no way synchronized with page
> > > > > > > > > flips, so
> > > > > > > > > I'm not sure how all this is really supposed to work.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Hi, Ville!
> > > > > > > >
> > > > > > > > Thank you for the review! :)
> > > > > > > >
> > > > > > > > I do not understand well what crc code is doing, but the issue
> > > > > > > > that I found
> > > > > > > > is related to the vblank timestamp and frame count.
> > > > > > > >
> > > > > > > > When vkms handles the crc_cursor it uses the start frame and
> > > > > > > > end frame
> > > > > > > > values to verify if it needs to call the function
> > > > > > > > 'drm_crtc_add_crc_entry()'
> > > > > > > > for each frame.
> > > > > > > >
> > > > > > > > However, when getting the frame count, the code is calling the
> > > > > > > > function
> > > > > > > > drm_update_vblank_count(dev, pipe, false) and, because of the
> > > > > > > > 'false',
> > > > > > > > subtracting the actual vblank timestamp (consequently, the
> > > > > > > > frame count
> > > > > > > > value), causing conflicts.
> > > > > > >
> > > > > > > The in_vblank_irq behavour looks sane to me. What are these
> > > > > > > conflicts?
> > > > > > >
> > > > > >
> > > > > > The entire history was:
> > > > > > - I sent the patch with bugfix for vblank extra frame. The patch
> > > > > > changed
> > > > > >our function vkms_get_vblank_timestamp() to look like this:
> > > > > >
> > > > > > bool vkms_get_vblank_timestamp(struct drm_device *dev, unsigned int
> > > > > > pipe,
> > > > > >int *max_error, ktime_t *vblank_time,
> > > > > >bool in_vblank_irq)
> > > > > > {
> > > > > > struct vkms_device *vkmsdev = drm_device_to_vkms_device(dev);
> > > > > > struct vkms_output *output = >output;
> > > > > >
> > > > > > *vblank_time = output->vblank_hrtimer.node.expires;
> > > > > >
> > > > > > + if (!in_vblank_irq)
> > > > > > +*vblank_time -= output->period_ns;
> > > > > >
> > > > > > return true;
> > > > > > }
> > > > > >
> > > > > > - This patch solve the issue that I was looking for (extra vblank
> > > > > > frames on kms_flip).
> > > > > >
> > > > > > - However, kms_cursor_crc tests, which passed before my patch,
> > > > > > started to fail.
> > > > > >
> > > > > > - Debugging them, I found that the problem was inside of function
> > > > > > `vkms_vblank_simulate()`
> > > > > > when it was handling the crc_enabled (inside if (state &&
> > > > > > output->crc_enabled))
> > > > > > and inside the
Re: [PATCH v4 01/10] drm/fourcc: Add AFBC yuv fourccs for Mali
On Mon, Mar 18, 2019 at 07:06:39PM +, Brian Starkey wrote: > > [1] > > https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/commit/0ac7d1187b234e86157ad74937c249a3c016807c > > Eh. I'm not familiar enough with the gitlab UI. Looks like this didn't > merge in GStreamer so far. Gah! Still wrong. It's in 1.16, with Alpha: https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-GstVideo.html#GstVideoFormat > > > > > > > > -Brian > > > > > > > > [1] > > > > https://docs.microsoft.com/en-us/windows/desktop/medfound/10-bit-and-16-bit-yuv-video-formats#444-formats > > > > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 01/10] drm/fourcc: Add AFBC yuv fourccs for Mali
On Mon, Mar 18, 2019 at 07:00:57PM +, Brian Starkey wrote: > On Mon, Mar 18, 2019 at 07:12:24PM +0100, Maarten Lankhorst wrote: > > Op 18-03-2019 om 16:40 schreef Brian Starkey: > > > Hi, > > > > > > On Mon, Mar 18, 2019 at 11:17:55AM +0100, Maarten Lankhorst wrote: > > > > > > > > > > > >> Hey.. > > >> > > >> There's a conflict with this patch and the merge of topic/hdr-formats, > > >> resulting in double definitions for Y210, Y410 and P010. > > >> > > >> Worse still is that one has set has_alpha to true for Y41x and other to > > >> false. > > >> > > >> ~Maarten > > >> > > > Oh that's sad :-( I think this fell through the cracks on our side > > > when someone left our team. Also turns out I'm not subscribed to > > > igt-dev. > > > > > > I see you commented the same on one of the previous patches, and that > > > there was some discussion of this on the test patches too. > > > > > > I have been referring to Microsoft's page[1] as "the" source for these > > > formats, which does indeed call out Y410 as having 2 bits of alpha. > > > Our GPU expects alpha. > > > > Ah. Yeah there has been discussion on whether there was supposed to be > > alpha or not, but the original discussion on HDR formats has been > > completely ignored by arm. > > > > The patch had originally a few arm devs on cc and was sent to dri-devel > > with linux-media cc'd. Was sad to see it completely ignored so after having > > been sent twice I pushed it. > > That's the kernel patch(es)? It looks like I did receive them via > dri-devel, and Ayan was Cc'd on two of the series', but it's > disingenuous to say they had "a few Arm devs". > > I first submitted this patch with Y410 to dri-devel back in August, > and since then it's been sent 8 times by my count (with you on Cc on > all of them!), and all have been similarly completely ignored; so I'm > sorry but I don't think you can put the blame entirely with Arm here. > > > > > > Was there a specific reason for opting to change the test instead of > > > the definition? Any way to get this changed now? > > > > > > It doesn't seem that sensible for the kernel to call something Y410 > > > which doesn't match an "existing" definition by the same name. If > > > alpha needs to be ignored on scanout, the alpha blend mode property > > > can be used (more archaeology - I see that was still giving CRC > > > failures, but that might be a "known issue" for all YUV on your HW?) > > > > Were a few bugs, but should be fixed now. :) > > > > Well only that we didn't have hw supporting alpha, and didn't hear back > > from others so we went without alpha. > > So what do you suggest? Can we change it, or we need to forever live > with divergent definitions in DRM vs elsewhere? > > Gstreamer appears to have a Y410 definition including alpha[1], and > there's the aforementioned Microsoft page too. > > To me it looks like we should change DRM, and if your HW supports > something that's "almost but not quite" Y410 then you need a different > name or only allow alpha-blend-mode "none". > > Thanks, > -Brian > > [1] > https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/commit/0ac7d1187b234e86157ad74937c249a3c016807c Eh. I'm not familiar enough with the gitlab UI. Looks like this didn't merge in GStreamer so far. > > > > > -Brian > > > > > > [1] > > > https://docs.microsoft.com/en-us/windows/desktop/medfound/10-bit-and-16-bit-yuv-video-formats#444-formats > > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 01/10] drm/fourcc: Add AFBC yuv fourccs for Mali
On Mon, Mar 18, 2019 at 07:12:24PM +0100, Maarten Lankhorst wrote: > Op 18-03-2019 om 16:40 schreef Brian Starkey: > > Hi, > > > > On Mon, Mar 18, 2019 at 11:17:55AM +0100, Maarten Lankhorst wrote: > > > > > > > >> Hey.. > >> > >> There's a conflict with this patch and the merge of topic/hdr-formats, > >> resulting in double definitions for Y210, Y410 and P010. > >> > >> Worse still is that one has set has_alpha to true for Y41x and other to > >> false. > >> > >> ~Maarten > >> > > Oh that's sad :-( I think this fell through the cracks on our side > > when someone left our team. Also turns out I'm not subscribed to > > igt-dev. > > > > I see you commented the same on one of the previous patches, and that > > there was some discussion of this on the test patches too. > > > > I have been referring to Microsoft's page[1] as "the" source for these > > formats, which does indeed call out Y410 as having 2 bits of alpha. > > Our GPU expects alpha. > > Ah. Yeah there has been discussion on whether there was supposed to be alpha > or not, but the original discussion on HDR formats has been completely > ignored by arm. > > The patch had originally a few arm devs on cc and was sent to dri-devel with > linux-media cc'd. Was sad to see it completely ignored so after having been > sent twice I pushed it. That's the kernel patch(es)? It looks like I did receive them via dri-devel, and Ayan was Cc'd on two of the series', but it's disingenuous to say they had "a few Arm devs". I first submitted this patch with Y410 to dri-devel back in August, and since then it's been sent 8 times by my count (with you on Cc on all of them!), and all have been similarly completely ignored; so I'm sorry but I don't think you can put the blame entirely with Arm here. > > > Was there a specific reason for opting to change the test instead of > > the definition? Any way to get this changed now? > > > > It doesn't seem that sensible for the kernel to call something Y410 > > which doesn't match an "existing" definition by the same name. If > > alpha needs to be ignored on scanout, the alpha blend mode property > > can be used (more archaeology - I see that was still giving CRC > > failures, but that might be a "known issue" for all YUV on your HW?) > > Were a few bugs, but should be fixed now. :) > > Well only that we didn't have hw supporting alpha, and didn't hear back from > others so we went without alpha. So what do you suggest? Can we change it, or we need to forever live with divergent definitions in DRM vs elsewhere? Gstreamer appears to have a Y410 definition including alpha[1], and there's the aforementioned Microsoft page too. To me it looks like we should change DRM, and if your HW supports something that's "almost but not quite" Y410 then you need a different name or only allow alpha-blend-mode "none". Thanks, -Brian [1] https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/commit/0ac7d1187b234e86157ad74937c249a3c016807c > > > -Brian > > > > [1] > > https://docs.microsoft.com/en-us/windows/desktop/medfound/10-bit-and-16-bit-yuv-video-formats#444-formats > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdkfd: Fix unchecked return value
On 3/18/19 1:25 PM, Kuehling, Felix wrote: > Alex already applied an equivalent patch by Colin King (attached for > reference). > Oh, that's great. Good to know. Thanks, Felix. -- Gustavo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 0/5] drm/sun4i: sun6i_mipi_dsi: Fixes/updates
Hi, On Sun, Mar 3, 2019 at 11:06 PM Jagan Teki wrote: > > Unfortunately due to various reasons[3] the previous fixes[1] and burst[2] > changes are failed to apply. > > So, this series is filtered version of previous [1] and [2] changes on top > of drm-misc. > > patch-1: Fix for burst mode instruction delay computation > > patch-2: Fix for TCOn DRQ set bits > > patch-3: Support vblk timing for 4-lane devices > > patch-4: GENERIC_SHORT_WRITE_2 dsi transfer support > > patch-5: Code simplification for dsi timings > > Changes for v9: > - rebase on drm-misc > - update commit messages > - add hsync_porch overflow patch > Changes for v8: > - rebase on master > - rework on commit messages > - rework video start delay > - include drq changes from previous version > Changes for v7: > - rebase on master > - collect Merlijn Wajer Tested-by credits. > Changes for v6: > - fixed all burst mode patches as per previous version comments > - rebase on master > - update proper commit message > - dropped unneeded comments > - order the patches that make review easy > Changes for v5, v4, v3, v2: > - use existing driver code construct for hblk computation > - create separate function for vblk computation > - cleanup commit messages > - update proper commit messages > - fixed checkpatch warnings/errors > - use proper return value for tcon0 probe > - add logic to get tcon0 divider values > - simplify timings code to support burst mode > - fix drq computation return values > - rebase on master > > [1] https://patchwork.kernel.org/cover/10813573/ > [2] https://patchwork.kernel.org/cover/10813623/ > [3] https://patchwork.kernel.org/cover/10805995/ > > Any inputs? > Jagan. Any further comments on this series? Can I send next version with some changes? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdkfd: Fix unchecked return value
Assign return value of function amdgpu_bo_sync_wait() to variable ret
for its further check.
Addresses-Coverity-ID: 1443914 ("Logically dead code")
Fixes: c60cd590cb7d ("drm/amdgpu: Replace ttm_bo_wait with amdgpu_bo_sync_wait")
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 1921dec3df7a..fb621abcb006 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -906,7 +906,8 @@ static int init_kfd_vm(struct amdgpu_vm *vm, void
**process_info,
pr_err("validate_pt_pd_bos() failed\n");
goto validate_pd_fail;
}
- amdgpu_bo_sync_wait(vm->root.base.bo, AMDGPU_FENCE_OWNER_KFD, false);
+ ret = amdgpu_bo_sync_wait(vm->root.base.bo, AMDGPU_FENCE_OWNER_KFD,
+ false);
if (ret)
goto wait_pd_fail;
amdgpu_bo_fence(vm->root.base.bo,
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdkfd: Fix unchecked return value
Alex already applied an equivalent patch by Colin King (attached for
reference).
Regards,
Felix
On 3/18/2019 2:05 PM, Gustavo A. R. Silva wrote:
> Assign return value of function amdgpu_bo_sync_wait() to variable ret
> for its further check.
>
> Addresses-Coverity-ID: 1443914 ("Logically dead code")
> Fixes: c60cd590cb7d ("drm/amdgpu: Replace ttm_bo_wait with
> amdgpu_bo_sync_wait")
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> index 1921dec3df7a..fb621abcb006 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> @@ -906,7 +906,8 @@ static int init_kfd_vm(struct amdgpu_vm *vm, void
> **process_info,
> pr_err("validate_pt_pd_bos() failed\n");
> goto validate_pd_fail;
> }
> - amdgpu_bo_sync_wait(vm->root.base.bo, AMDGPU_FENCE_OWNER_KFD, false);
> + ret = amdgpu_bo_sync_wait(vm->root.base.bo, AMDGPU_FENCE_OWNER_KFD,
> + false);
> if (ret)
> goto wait_pd_fail;
> amdgpu_bo_fence(vm->root.base.bo,
--- Begin Message ---
From: Colin Ian King
An earlier commit replaced ttm_bo_wait with amdgpu_bo_sync_wait and
removed the error return assignment to variable ret. Fix this by adding
the assignment back. Also break line to clean up checkpatch overly
long line warning.
Detected by CoverityScan, CID#1477327 ("Logically dead code")
Fixes: c60cd590cb7d ("drm/amdgpu: Replace ttm_bo_wait with amdgpu_bo_sync_wait")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 1921dec3df7a..92993baac91a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -906,7 +906,8 @@ static int init_kfd_vm(struct amdgpu_vm *vm, void
**process_info,
pr_err("validate_pt_pd_bos() failed\n");
goto validate_pd_fail;
}
- amdgpu_bo_sync_wait(vm->root.base.bo, AMDGPU_FENCE_OWNER_KFD, false);
+ ret = amdgpu_bo_sync_wait(vm->root.base.bo,
+ AMDGPU_FENCE_OWNER_KFD, false);
if (ret)
goto wait_pd_fail;
amdgpu_bo_fence(vm->root.base.bo,
--
2.20.1
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx--- End Message ---
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 02/15] drm/sun4i: tcon: Compute DCLK dividers based on format, lanes
On Mon, Mar 11, 2019 at 9:36 PM Jagan Teki wrote: > > On Mon, Mar 11, 2019 at 9:08 PM Maxime Ripard > wrote: > > > > On Mon, Mar 11, 2019 at 07:06:24PM +0530, Jagan Teki wrote: > > > pll-video => pll-mipi => tcon0 => tcon0-pixel-clock is the typical > > > MIPI clock topology in Allwinner DSI controller. > > > > > > TCON dotclock driver is computing the desired DCLK divider based on > > > panel pixel clock along with input DCLK min, max divider values from > > > tcon driver and that would eventually set the pll-mipi clock rate. > > > > > > The current code allows the TCON clock divider to have a default 4 > > > for min, max ranges that would fail to compute the desired pll-mipi > > > rate while supporting new panels. > > > > > > So, add the computation logic 'format/lanes' to dclk min and max dividers > > > and instead of default 4. This computation logic align with Allwinner A64 > > > BSP, hoping that would work even for A33. > > > > Last time we discussed this, we found out that this wasn't the case, > > even in the BSP. > > This was the case for BSP to compute pll-mipi not for TCON_DSI clock > register, SUN4I_TCON0_DCLK_REG, which marked the divider 4 by default. > > > > > What compelling evidence have you found that makes you say otherwise? > > divider 4 isn't worked, this I would mentioned before as well. > > Tested this on 4 different panels, and below are the desired divider values > and pll-mipi clock rate with respect to pixel clock frequency. > > - 55MHz pixel clock with 4-lane panel, and the desired DSI clock divider > is 6 with the output parent clock rate of 330MHz. > - 30MHz pixel clock with 4-lane panel, and the desired DSI clock divider > is 6 with parent clock rate of 180MHz. > - 27.5Mhz pixel clock with 2-lane pane, and the desired DSI clock divider > is 12 with the output parent clock rate of 330MHz. > - 147MHz pixel clock with 4-lane panel, and the desired DSI clock divider > is 6 with the output parent clock rate of 882MHz. > > BSP trying to use this format/lane to compute dsi divider that in-turn > using pll-mipi set_rate but TCON0_DCLK_REG keep constant 4. Any comments? For more information, I have even tying to get the dump here to show the pll_rate set in BSP code [1], please have a look at this gist[2] where the bpp/lanes value of 6 is computed for pll_rate and let me know what do you think? DSI rate is 148.5Mhz Panel Pixel clock is 148Mhz PLL set rate is 888Mhz (which is bpp/lanes = 6 * 148 Mhz) [1] https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L793 [2] https://gist.github.com/openedev/9bae2d87d2fcc06b999fe48c998b7043 https://gist.github.com/openedev/700de2e3701b2bf3ad1aa0f0fa862c9a ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/9] drm/syncobj: add support for timeline point wait v8
On 18/03/2019 17:20, Koenig, Christian wrote:
- if (dma_fence_is_signaled(entries[i].fence)) {
+ if (fence)
+ entries[i].fence = fence;
+ else
+ entries[i].fence = dma_fence_get_stub();
+
+ if ((flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE) ||
Hey David,
Could you remind me what DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE is used
for?
I didn't have a use for it in userspace,
The flag is used to wait for fences for a sequence number to show up.
Christian.
Thanks Christian.
I guess I missed the additive nature of WAIT_FOR_SUBMIT.
It feels like WAIT_AVAILABLE almost deserves its own commit as it
affects both timelines & binary syncobjs.
-Lionel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/fourcc: add ARM GPU tile modifier
Hello Qiang,
Sorry for weighing in late on this, I've quite a backlog to work
through.
Since your first patch set, I did raise this internally. The request
has been making it's way through:
- GPU engineering, to determine what exactly this format is, and
what other variants there might be which are supported on different
GPU generations, so that we can determine a sane naming convention.
- Our legal team, to determine what detail we are happy to share from
an IP perspective. I can't imagine there being an issue here, but
process is process, and there's not a lot I can do to move that
along.
There was talk on the legal side last week. I will ask for an update.
I realise this is taking a very long time, and for that I can only
apologise; I really am trying to get you an answer.
On Thu, Mar 14, 2019 at 07:13:48PM +0800, Qiang Yu wrote:
> v2: separate AFBC and GPU encoding
>
> v3: rename device to type and GPU modifer name
>
> Cc: Brian Starkey
> Cc: Rob Herring
> Cc: Alyssa Rosenzweig
> Cc: Ayan Halder
> Signed-off-by: Qiang Yu
> ---
> include/uapi/drm/drm_fourcc.h | 31 ++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 9fa7cf7bb274..f80a675cb09a 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -601,6 +601,19 @@ extern "C" {
> */
> #define DRM_FORMAT_MOD_BROADCOM_UIF fourcc_mod_code(BROADCOM, 6)
>
> +/*
> + * Arm Buffer Layout Type Code
> + *
> + * Arm has multiple types of buffer layout which are not totally shared
> + * across devices, so add a type field at the MSB of the format field
> + * to separate each type's encoding.
> + */
> +#define DRM_FORMAT_MOD_ARM_TYPE_AFBC 0x00
> +#define DRM_FORMAT_MOD_ARM_TYPE_AGTB 0x01
> +
I don't think we need a whole byte here. We can just keep adding
individual bits as needed.
In any case, I'm not that keen on adding this "AGTB" category. That
effectively reserves 55 (or 47) bits just to describe a single layout.
We don't know if this is a "category" per-se, or just a single Utgard
tiling format - as discussed I'm trying to get an answer for that.
AFBC only uses bit-fields and the "__afbc_mode" helper macro because
it has many different "features" which can be combined quite freely.
That leads to combinatorial expansion, so when a new feature is
introduced, this can approximately double the list of possible AFBC
modifiers. That's rather unmanageable if we list them all
exhaustively.
For other layouts which don't have this kind of combinatorial effect,
I'd rather have #defines for the specific layouts, all individually
setting the top bit, without giving that top bit any kind of "name".
The top bit would effectively mean "not AFBC", rather than meaning
"AGTB", allowing us to use the lower bits more freely.
In the future, maybe Arm comes up with another layout with tons of
combinatorial variants (let's call it "AFBC2") - in which case I think
we'd add a new "__afbc2_mode" helper macro, which sets the top *two*
bits - but *only* if listing all of the AFBC2 variants directly wasn't
practical.
If you can hang on a while longer, I hope Arm can push a patch which
you can just use directly, and then handling the bit assignments will
be our mess rather than yours :-)
Thanks,
-Brian
> +#define DRM_FORMAT_MOD_ARM_CODE(type, val) \
> + fourcc_mod_code(ARM, ((__u64)type << 48) | ((val) &
> 0xULL))
> +
> /*
> * Arm Framebuffer Compression (AFBC) modifiers
> *
> @@ -615,7 +628,8 @@ extern "C" {
> * Further information on the use of AFBC modifiers can be found in
> * Documentation/gpu/afbc.rst
> */
> -#define DRM_FORMAT_MOD_ARM_AFBC(__afbc_mode) fourcc_mod_code(ARM,
> __afbc_mode)
> +#define DRM_FORMAT_MOD_ARM_AFBC(__afbc_mode) \
> + DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_AFBC, __afbc_mode)
>
> /*
> * AFBC superblock size
> @@ -709,6 +723,21 @@ extern "C" {
> */
> #define AFBC_FORMAT_MOD_BCH (1ULL << 11)
>
> +/*
> + * Arm Graphics Tiled Buffer (AGTB) modifiers
> + */
> +#define DRM_FORMAT_MOD_ARM_AGTB(mode) \
> + DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_AGTB, mode)
> +
> +/*
> + * AGTB mode 0 modifier
> + *
> + * This is used by ARM Mali Utgard/Midgard GPU. It divides buffer into
> + * 16x16 pixel blocks. Blocks are stored linearly in order, but pixels
> + * in the block are reordered.
> + */
> +#define DRM_FORMAT_MOD_ARM_AGTB_MODE0 DRM_FORMAT_MOD_ARM_AGTB(1)
> +
> /*
> * Allwinner tiled modifier
> *
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 01/10] drm/fourcc: Add AFBC yuv fourccs for Mali
Op 18-03-2019 om 16:40 schreef Brian Starkey: > Hi, > > On Mon, Mar 18, 2019 at 11:17:55AM +0100, Maarten Lankhorst wrote: > > > >> Hey.. >> >> There's a conflict with this patch and the merge of topic/hdr-formats, >> resulting in double definitions for Y210, Y410 and P010. >> >> Worse still is that one has set has_alpha to true for Y41x and other to >> false. >> >> ~Maarten >> > Oh that's sad :-( I think this fell through the cracks on our side > when someone left our team. Also turns out I'm not subscribed to > igt-dev. > > I see you commented the same on one of the previous patches, and that > there was some discussion of this on the test patches too. > > I have been referring to Microsoft's page[1] as "the" source for these > formats, which does indeed call out Y410 as having 2 bits of alpha. > Our GPU expects alpha. Ah. Yeah there has been discussion on whether there was supposed to be alpha or not, but the original discussion on HDR formats has been completely ignored by arm. The patch had originally a few arm devs on cc and was sent to dri-devel with linux-media cc'd. Was sad to see it completely ignored so after having been sent twice I pushed it. > Was there a specific reason for opting to change the test instead of > the definition? Any way to get this changed now? > > It doesn't seem that sensible for the kernel to call something Y410 > which doesn't match an "existing" definition by the same name. If > alpha needs to be ignored on scanout, the alpha blend mode property > can be used (more archaeology - I see that was still giving CRC > failures, but that might be a "known issue" for all YUV on your HW?) Were a few bugs, but should be fixed now. :) Well only that we didn't have hw supporting alpha, and didn't hear back from others so we went without alpha. > -Brian > > [1] > https://docs.microsoft.com/en-us/windows/desktop/medfound/10-bit-and-16-bit-yuv-video-formats#444-formats ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110183] check out
https://bugs.freedesktop.org/show_bug.cgi?id=110183 Bug ID: 110183 Summary: check out Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: critical Priority: medium Component: IGT Assignee: dri-devel@lists.freedesktop.org Reporter: lokeshggc...@gmail.com please login url xyz.com please product search please product add to cart check out feature is not working -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/17] drm/rockchip: Convert to using __drm_atomic_helper_crtc_reset() for reset.
Am Freitag, 1. März 2019, 13:56:23 CET schrieb Maarten Lankhorst: > Convert rockchip to using __drm_atomic_helper_crtc_reset(), instead of > writing its own version. Instead of open coding > destroy_state(), call it directly for freeing the old state. > > Signed-off-by: Maarten Lankhorst > Cc: Sandy Huang > Cc: "Heiko Stübner" > Cc: linux-rockc...@lists.infradead.org so I've looked up the patch2 that introduces __drm_atomic_helper_crtc_reset in patchwork and compared results and everything looks as it should be I think ;-) , so Reviewed-by: Heiko Stuebner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: vop: reset scale mode when win is disabled
Hi Jonas,
Am Mittwoch, 20. Februar 2019, 23:40:06 CET schrieb Jonas Karlman:
> NV12 framebuffers produced by the VPU shows distorted on RK3288
> after win has been disabled when scaling is active.
>
> This issue can be reproduced using a 1080p modeset by:
> - Scale a 1280x720 NV12 framebuffer to 1920x1080 on win0
> - Disable win0
> - Display a 1920x1080 NV12 framebuffer without scaling on win0
> - Output will now show the framebuffer distorted
>
> And by:
> - Scale a 1280x720 NV12 framebuffer to 1920x1080
> - Change to a 720p modeset (win gets disabled and scaling reset to none)
> - Output will now show the framebuffer distorted
>
> Fix this by setting scale mode to none when win is disabled.
>
> Fixes: 4c156c21c794 ("drm/rockchip: vop: support plane scale")
> Signed-off-by: Jonas Karlman
applied to drm-misc-fixes - sorry it took so long to test and apply.
Thanks
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] drm/amd/display: Rework vrr flip throttling for late vblank irq.
On 3/18/19 1:19 PM, Mario Kleiner wrote:
> For throttling to work correctly, we always need a baseline vblank
> count last_flip_vblank that increments at start of front-porch.
>
> This is the case for drm_crtc_vblank_count() in non-VRR mode, where
> the vblank irq fires at start of front-porch and triggers DRM core
> vblank handling, but it is no longer the case in VRR mode, where
> core vblank handling is done later, after end of front-porch.
>
> Therefore drm_crtc_vblank_count() is no longer useful for this.
> We also can't use drm_crtc_accurate_vblank_count(), as that would
> screw up vblank timestamps in VRR mode when called in front-porch.
>
> To solve this, use the cooked hardware vblank counter returned by
> amdgpu_get_vblank_counter_kms() instead, as that one is cooked to
> always increment at start of front-porch, independent of when
> vblank related irq's fire.
>
> This patch allows vblank irq handling to happen anywhere within
> vblank of even after it, without a negative impact on flip
> throttling, so followup patches can shift the vblank core
> handling trigger point wherever they need it.
>
> Signed-off-by: Mario Kleiner
Reviewed-by: Nicholas Kazlauskas
Functionally drm_crtc_accurate_vblank_count is the same as
amdgpu_get_vblank_counter_kms for querying purposes, so this works.
It's a nice cleanup for commit planes too since we no longer grab the
DRM vblank count only to immediately subtract it off again.
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 2 +-
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 23
> +--
> 2 files changed, 14 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index 889e443..add238f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> @@ -406,7 +406,7 @@ struct amdgpu_crtc {
> struct amdgpu_flip_work *pflip_works;
> enum amdgpu_flip_status pflip_status;
> int deferred_flip_completion;
> - u64 last_flip_vblank;
> + u32 last_flip_vblank;
> /* pll sharing */
> struct amdgpu_atom_ss ss;
> bool ss_enabled;
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index c1c3815..85e4f87 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -286,7 +286,7 @@ static void dm_pflip_high_irq(void *interrupt_params)
> }
>
> /* Update to correct count(s) if racing with vblank irq */
> - amdgpu_crtc->last_flip_vblank =
> drm_crtc_accurate_vblank_count(_crtc->base);
> + drm_crtc_accurate_vblank_count(_crtc->base);
>
> /* wake up userspace */
> if (amdgpu_crtc->event) {
> @@ -298,6 +298,14 @@ static void dm_pflip_high_irq(void *interrupt_params)
> } else
> WARN_ON(1);
>
> + /* Keep track of vblank of this flip for flip throttling. We use the
> + * cooked hw counter, as that one incremented at start of this vblank
> + * of pageflip completion, so last_flip_vblank is the forbidden count
> + * for queueing new pageflips if vsync + VRR is enabled.
> + */
> + amdgpu_crtc->last_flip_vblank =
> amdgpu_get_vblank_counter_kms(adev->ddev,
> + amdgpu_crtc->crtc_id);
> +
> amdgpu_crtc->pflip_status = AMDGPU_FLIP_NONE;
> spin_unlock_irqrestore(>ddev->event_lock, flags);
>
> @@ -4769,9 +4777,8 @@ static void amdgpu_dm_commit_planes(struct
> drm_atomic_state *state,
> unsigned long flags;
> struct amdgpu_bo *abo;
> uint64_t tiling_flags;
> - uint32_t target, target_vblank;
> - uint64_t last_flip_vblank;
> - bool vrr_active = acrtc_state->freesync_config.state ==
> VRR_STATE_ACTIVE_VARIABLE;
> + uint32_t target_vblank, last_flip_vblank;
> + bool vrr_active = amdgpu_dm_vrr_active(acrtc_state);
> bool pflip_present = false;
>
> struct {
> @@ -4918,7 +4925,7 @@ static void amdgpu_dm_commit_planes(struct
> drm_atomic_state *state,
>* clients using the GLX_OML_sync_control extension or
>* DRI3/Present extension with defined target_msc.
>*/
> - last_flip_vblank = drm_crtc_vblank_count(pcrtc);
> + last_flip_vblank =
> amdgpu_get_vblank_counter_kms(dm->ddev, acrtc_attach->crtc_id);
> }
> else {
> /* For variable refresh rate mode only:
> @@ -4934,11 +4941,7 @@ static void amdgpu_dm_commit_planes(struct
> drm_atomic_state *state,
> spin_unlock_irqrestore(>dev->event_lock, flags);
> }
>
> - target = (uint32_t)last_flip_vblank + wait_for_vblank;
> -
> - /* Prepare wait for target vblank early - before
Re: [PATCH 5/6] drm/bridge: Add Chipone ICN6211 MIPI-DSI/RGB convertor bridge
On Fri, Mar 15, 2019 at 7:03 PM Maxime Ripard wrote:
>
> On Fri, Mar 15, 2019 at 06:38:24PM +0530, Jagan Teki wrote:
> > ICN6211 is MIPI-DSI/RGB converter bridge from chipone.
> > It has a flexible configuration of MIPI DSI signal input
> > and produce RGB565, RGB666, RGB888 output format.
> >
> > Add bridge driver for it.
> >
> > Signed-off-by: Jagan Teki
> > ---
> > MAINTAINERS | 6 +
> > drivers/gpu/drm/bridge/Kconfig | 10 +
> > drivers/gpu/drm/bridge/Makefile | 1 +
> > drivers/gpu/drm/bridge/chipone-icn6211.c | 275 +++
> > 4 files changed, 292 insertions(+)
> > create mode 100644 drivers/gpu/drm/bridge/chipone-icn6211.c
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 4de80222cffb..e529addd30f5 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -4897,6 +4897,12 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
> > S: Maintained
> > F: drivers/gpu/drm/bochs/
> >
> > +DRM DRIVER FOR CHIPONE ICN6211 MIPI-DSI to RGB CONVERTOR BRIDGE
> > +M: Jagan Teki
> > +S: Maintained
> > +F: drivers/gpu/drm/bridge/chipone-icn6211.c
> > +F: Documentation/devicetree/bindings/display/bridge/chipone,icn6211.txt
> > +
> > DRM DRIVER FOR FARADAY TVE200 TV ENCODER
> > M: Linus Walleij
> > T: git git://anongit.freedesktop.org/drm/drm-misc
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index 8840f396a7b6..cd314572e4ed 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -36,6 +36,16 @@ config DRM_CDNS_DSI
> > Support Cadence DPI to DSI bridge. This is an internal
> > bridge and is meant to be directly embedded in a SoC.
> >
> > +config DRM_CHIPONE_ICN6211
> > + tristate "Chipone ICN6211 MIPI-DSI/RGB converter bridge"
> > + depends on DRM && DRM_PANEL
> > + depends on OF
> > + select DRM_MIPI_DSI
> > + help
> > + ICN6211 is MIPI-DSI/RGB converter bridge from chipone.
> > + It has a flexible configuration of MIPI DSI signal input
> > + and produce RGB565, RGB666, RGB888 output format.
> > +
> > config DRM_DUMB_VGA_DAC
> > tristate "Dumb VGA DAC Bridge support"
> > depends on OF
> > diff --git a/drivers/gpu/drm/bridge/Makefile
> > b/drivers/gpu/drm/bridge/Makefile
> > index 4934fcf5a6f8..541fdccad10b 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -1,6 +1,7 @@
> > # SPDX-License-Identifier: GPL-2.0
> > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> > obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> > +obj-$(CONFIG_DRM_CHIPONE_ICN6211) += chipone-icn6211.o
> > obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
> > obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
> > obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) +=
> > megachips-stdp-ge-b850v3-fw.o
> > diff --git a/drivers/gpu/drm/bridge/chipone-icn6211.c
> > b/drivers/gpu/drm/bridge/chipone-icn6211.c
> > new file mode 100644
> > index ..cd2f3505f845
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/chipone-icn6211.c
> > @@ -0,0 +1,275 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2018 Amarula Solutions
> > + * Author: Jagan Teki
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define ICN6211_INIT_CMD_LEN 2
> > +
> > +struct chipone {
> > + struct device *dev;
> > + struct drm_bridge bridge;
> > + struct drm_connector connector;
> > + struct drm_panel *panel;
> > +
> > + struct gpio_desc *reset;
> > +};
> > +
> > +static inline struct chipone *bridge_to_chipone(struct drm_bridge *bridge)
> > +{
> > + return container_of(bridge, struct chipone, bridge);
> > +}
> > +
> > +static inline
> > +struct chipone *connector_to_chipone(struct drm_connector *connector)
> > +{
> > + return container_of(connector, struct chipone, connector);
> > +}
> > +
> > +struct icn6211_init_cmd {
> > + u8 data[ICN6211_INIT_CMD_LEN];
> > +};
> > +
> > +static const struct icn6211_init_cmd icn6211_init_cmds[] = {
> > + { .data = { 0x7A, 0xC1 } },
> > + { .data = { 0x20, 0x20 } },
> > + { .data = { 0x21, 0xE0 } },
> > + { .data = { 0x22, 0x13 } },
> > + { .data = { 0x23, 0x28 } },
> > + { .data = { 0x24, 0x30 } },
> > + { .data = { 0x25, 0x28 } },
> > + { .data = { 0x26, 0x00 } },
> > + { .data = { 0x27, 0x0D } },
> > + { .data = { 0x28, 0x03 } },
> > + { .data = { 0x29, 0x1D } },
> > + { .data = { 0x34, 0x80 } },
> > + { .data = { 0x36, 0x28 } },
> > + { .data = { 0xB5, 0xA0 } },
> > + { .data = { 0x5C, 0xFF } },
> > + { .data = { 0x2A, 0x01 } },
> > + { .data = { 0x56, 0x92 } },
> > + { .data = { 0x6B, 0x71 } },
> > + { .data = { 0x69, 0x2B } },
> > + { .data = {
[Bug 202445] amdgpu/dc: framerate dropping below adaptive sync range causes screen flickering
https://bugzilla.kernel.org/show_bug.cgi?id=202445 --- Comment #28 from Clément Guérin (li...@protonmail.com) --- Nevermind. This commit was merged right before 5.0 was released. So yes, it was in the tree. What I suspect is happening is that a couple or more frames are scheduled by the BTR code, but for some reason they are displayed at the max refresh rate (144Hz in my case), then the monitor times out on the last frame and that produces flickering. Which is what I pointed out in comment 16. EDIT: I just realized that the link in that comment is outdated because code moved around. This is what it originally pointed to: https://github.com/torvalds/linux/blob/672e78c/drivers/gpu/drm/amd/display/modules/freesync/freesync.c#L980 /* TODO: pass in flag for Pre-DCE12 ASIC * in order for frame variable duration to take affect, * it needs to be done one VSYNC early, which is at * frameCounter == 1. * For DCE12 and newer updates to V_TOTAL_MIN/MAX * will take affect on current frame */ As far as I know that will only affect pre-Vega GPUs, and I'm running Fiji. -- 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: [PATCH 1/4] drm/amd/display: Prevent vblank irq disable while VRR is active.
On 3/18/19 1:19 PM, Mario Kleiner wrote:
> During VRR mode we can not allow vblank irq dis-/enable
> transitions, as an enable after a disable can happen at
> an arbitrary time during the video refresh cycle, e.g.,
> with a high likelyhood inside vblank front-porch. An
> enable during front-porch would cause vblank timestamp
> updates/calculations which are completely bogus, given
> the code can't know when the vblank will end as long
> as we are in front-porch with no page flip completed.
>
> Hold a permanent vblank reference on the crtc while
> in active VRR mode to prevent a vblank disable, and
> drop the reference again when switching back to fixed
> refresh rate non-VRR mode.
>
> Signed-off-by: Mario Kleiner
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 35
> +++
> 1 file changed, 35 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index a718ac2..c1c3815 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -251,6 +251,12 @@ get_crtc_by_otg_inst(struct amdgpu_device *adev,
> return NULL;
> }
>
> +static inline bool amdgpu_dm_vrr_active(struct dm_crtc_state *dm_state)
> +{
> + return dm_state->freesync_config.state == VRR_STATE_ACTIVE_VARIABLE ||
> +dm_state->freesync_config.state == VRR_STATE_ACTIVE_FIXED;
> +}
> +
> static void dm_pflip_high_irq(void *interrupt_params)
> {
> struct amdgpu_crtc *amdgpu_crtc;
> @@ -4716,6 +4722,32 @@ static void update_freesync_state_on_stream(
> (int)vrr_params.state);
> }
>
> +static void amdgpu_dm_handle_vrr_transition(struct dm_crtc_state *old_state,
> + struct dm_crtc_state *new_state)
> +{
> + bool old_vrr_active = amdgpu_dm_vrr_active(old_state);
> + bool new_vrr_active = amdgpu_dm_vrr_active(new_state);
> +
> + if (!old_vrr_active && new_vrr_active) {
> + /* Transition VRR inactive -> active:
> + * While VRR is active, we must not disable vblank irq, as a
> + * reenable after disable would compute bogus vblank/pflip
> + * timestamps if it likely happened inside display front-porch.
> + */
> + drm_crtc_vblank_get(new_state->base.crtc);
> + DRM_DEBUG_DRIVER("%s: crtc=%u VRR off->on: Get vblank ref\n",
> + __func__, new_state->base.crtc->base.id);
> + }
> + else if (old_vrr_active && !new_vrr_active) {
> + /* Transition VRR active -> inactive:
> + * Allow vblank irq disable again for fixed refresh rate.
> + */
> + drm_crtc_vblank_put(new_state->base.crtc);
> + DRM_DEBUG_DRIVER("%s: crtc=%u VRR on->off: Drop vblank ref\n",
> + __func__, new_state->base.crtc->base.id);
> + }
> +}
> +
> static void amdgpu_dm_commit_planes(struct drm_atomic_state *state,
> struct dc_state *dc_state,
> struct drm_device *dev,
> @@ -4757,6 +4789,9 @@ static void amdgpu_dm_commit_planes(struct
> drm_atomic_state *state,
> goto cleanup;
> }
>
> + /* Take care to hold extra vblank ref for a crtc in VRR mode */
> + amdgpu_dm_handle_vrr_transition(dm_old_crtc_state, acrtc_state);
I think this forgets to drop the extra reference in the case where the
stream is being disabled at the same time VRR is -
amdgpu_dm_commit_planes is only called when when the stream is non-NULL.
I think the logic will work if simply moved outside of the function into
the loop that calls this.
Nicholas Kazlauskas
> +
> /* update planes when needed */
> for_each_oldnew_plane_in_state(state, plane, old_plane_state,
> new_plane_state, i) {
> struct drm_crtc *crtc = new_plane_state->crtc;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/9] drm/syncobj: add support for timeline point wait v8
Am 18.03.19 um 17:59 schrieb Lionel Landwerlin:
> On 15/03/2019 12:09, Chunming Zhou wrote:
>> points array is one-to-one match with syncobjs array.
>> v2:
>> add seperate ioctl for timeline point wait, otherwise break uapi.
>> v3:
>> userspace can specify two kinds waits::
>> a. Wait for time point to be completed.
>> b. and wait for time point to become available
>> v4:
>> rebase
>> v5:
>> add comment for xxx_WAIT_AVAILABLE
>> v6: rebase and rework on new container
>> v7: drop _WAIT_COMPLETED, it is the default anyway
>> v8: correctly handle garbage collected fences
>>
>> Signed-off-by: Chunming Zhou
>> Signed-off-by: Christian König
>> Cc: Daniel Rakos
>> Cc: Jason Ekstrand
>> Cc: Bas Nieuwenhuizen
>> Cc: Dave Airlie
>> Cc: Chris Wilson
>> ---
>> drivers/gpu/drm/drm_internal.h | 2 +
>> drivers/gpu/drm/drm_ioctl.c | 2 +
>> drivers/gpu/drm/drm_syncobj.c | 153 ++---
>> include/uapi/drm/drm.h | 15
>> 4 files changed, 143 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_internal.h
>> b/drivers/gpu/drm/drm_internal.h
>> index 251d67e04c2d..331ac6225b58 100644
>> --- a/drivers/gpu/drm/drm_internal.h
>> +++ b/drivers/gpu/drm/drm_internal.h
>> @@ -182,6 +182,8 @@ int drm_syncobj_fd_to_handle_ioctl(struct
>> drm_device *dev, void *data,
>> struct drm_file *file_private);
>> int drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
>> struct drm_file *file_private);
>> +int drm_syncobj_timeline_wait_ioctl(struct drm_device *dev, void *data,
>> + struct drm_file *file_private);
>> int drm_syncobj_reset_ioctl(struct drm_device *dev, void *data,
>> struct drm_file *file_private);
>> int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
>> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
>> index 687943df58e1..c984654646fa 100644
>> --- a/drivers/gpu/drm/drm_ioctl.c
>> +++ b/drivers/gpu/drm/drm_ioctl.c
>> @@ -688,6 +688,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_WAIT, drm_syncobj_wait_ioctl,
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> + DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT,
>> drm_syncobj_timeline_wait_ioctl,
>> + DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_RESET, drm_syncobj_reset_ioctl,
>> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>> DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_SIGNAL, drm_syncobj_signal_ioctl,
>> diff --git a/drivers/gpu/drm/drm_syncobj.c
>> b/drivers/gpu/drm/drm_syncobj.c
>> index 19a9ce638119..eae51978cda4 100644
>> --- a/drivers/gpu/drm/drm_syncobj.c
>> +++ b/drivers/gpu/drm/drm_syncobj.c
>> @@ -61,6 +61,7 @@ struct syncobj_wait_entry {
>> struct task_struct *task;
>> struct dma_fence *fence;
>> struct dma_fence_cb fence_cb;
>> + u64 point;
>> };
>> static void syncobj_wait_syncobj_func(struct drm_syncobj *syncobj,
>> @@ -95,6 +96,8 @@ EXPORT_SYMBOL(drm_syncobj_find);
>> static void drm_syncobj_fence_add_wait(struct drm_syncobj *syncobj,
>> struct syncobj_wait_entry *wait)
>> {
>> + struct dma_fence *fence;
>> +
>> if (wait->fence)
>> return;
>> @@ -103,11 +106,15 @@ static void drm_syncobj_fence_add_wait(struct
>> drm_syncobj *syncobj,
>> * have the lock, try one more time just to be sure we don't add a
>> * callback when a fence has already been set.
>> */
>> - if (syncobj->fence)
>> - wait->fence = dma_fence_get(
>> - rcu_dereference_protected(syncobj->fence, 1));
>> - else
>> + fence = dma_fence_get(rcu_dereference_protected(syncobj->fence,
>> 1));
>> + if (!fence || dma_fence_chain_find_seqno(, wait->point)) {
>> + dma_fence_put(fence);
>> list_add_tail(>node, >cb_list);
>> + } else if (!fence) {
>> + wait->fence = dma_fence_get_stub();
>> + } else {
>> + wait->fence = fence;
>> + }
>> spin_unlock(>lock);
>> }
>> @@ -149,10 +156,8 @@ void drm_syncobj_add_point(struct drm_syncobj
>> *syncobj,
>> dma_fence_chain_init(chain, prev, fence, point);
>> rcu_assign_pointer(syncobj->fence, >base);
>> - list_for_each_entry_safe(cur, tmp, >cb_list, node) {
>> - list_del_init(>node);
>> + list_for_each_entry_safe(cur, tmp, >cb_list, node)
>> syncobj_wait_syncobj_func(syncobj, cur);
>> - }
>> spin_unlock(>lock);
>> /* Walk the chain once to trigger garbage collection */
>> @@ -184,10 +189,8 @@ void drm_syncobj_replace_fence(struct
>> drm_syncobj *syncobj,
>> rcu_assign_pointer(syncobj->fence, fence);
>> if (fence != old_fence) {
>> - list_for_each_entry_safe(cur, tmp, >cb_list, node) {
>> - list_del_init(>node);
>> + list_for_each_entry_safe(cur, tmp,
[PATCH 4/4] drm/amd/display: Make pageflip event delivery compatible with VRR.
We want vblank counts and timestamps of flip completion as sent
in pageflip completion events to be consistent with the vblank
count and timestamp of the vblank of flip completion, like in non
VRR mode.
In VRR mode, drm_update_vblank_count() - and thereby vblank
count and timestamp updates - must be delayed until after the
end of front-porch of each vblank, as it is only safe to
calculate vblank timestamps outside of the front-porch, when
we actually know when the vblank will end or has ended.
The function drm_update_vblank_count() which updates timestamps
and counts gets called by drm_crtc_accurate_vblank_count() or by
drm_crtc_handle_vblank().
Therefore we must make sure that pageflip events for a completed
flip are only sent out after drm_crtc_accurate_vblank_count() or
drm_crtc_handle_vblank() is executed, after end of front-porch
for the vblank of flip completion.
Two cases:
a) Pageflip irq handler executes inside front-porch:
In this case we must defer sending pageflip events until
drm_crtc_handle_vblank() executes after end of front-porch,
and thereby calculates proper vblank count and timestamp.
Iow. the pflip irq handler must just arm a pageflip event
to be sent out by drm_crtc_handle_vblank() later on.
b) Pageflip irq handler executes after end of front-porch, e.g.,
after flip completion in back-porch or due to a massively
delayed handler invocation into the active scanout of the new
frame. In this case we can call drm_crtc_accurate_vblank_count()
to safely force calculation of a proper vblank count and
timestamp, and must send the pageflip completion event
ourselves from the pageflip irq handler.
This is the same behaviour as needed for standard fixed refresh
rate mode.
To decide from within pageflip handler if we are in case a) or b),
we check the current scanout position against the boundary of
front-porch. In non-VRR mode we just do what we did in the past.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 68 ++-
1 file changed, 55 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 555d9e9f..499284d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -263,6 +263,10 @@ static void dm_pflip_high_irq(void *interrupt_params)
struct common_irq_params *irq_params = interrupt_params;
struct amdgpu_device *adev = irq_params->adev;
unsigned long flags;
+ struct drm_pending_vblank_event *e;
+ struct dm_crtc_state *acrtc_state;
+ uint32_t vpos, hpos, v_blank_start, v_blank_end;
+ bool vrr_active;
amdgpu_crtc = get_crtc_by_otg_inst(adev, irq_params->irq_src -
IRQ_TYPE_PFLIP);
@@ -285,18 +289,57 @@ static void dm_pflip_high_irq(void *interrupt_params)
return;
}
- /* Update to correct count(s) if racing with vblank irq */
- drm_crtc_accurate_vblank_count(_crtc->base);
+ /* page flip completed. */
+ e = amdgpu_crtc->event;
+ amdgpu_crtc->event = NULL;
- /* wake up userspace */
- if (amdgpu_crtc->event) {
- drm_crtc_send_vblank_event(_crtc->base,
amdgpu_crtc->event);
+ if (!e)
+ WARN_ON(1);
- /* page flip completed. clean up */
- amdgpu_crtc->event = NULL;
+ acrtc_state = to_dm_crtc_state(amdgpu_crtc->base.state);
+ vrr_active = amdgpu_dm_vrr_active(acrtc_state);
+
+ /* Fixed refresh rate, or VRR scanout position outside front-porch? */
+ if (!vrr_active ||
+ !dc_stream_get_scanoutpos(acrtc_state->stream, _blank_start,
+ _blank_end, , ) ||
+ (vpos < v_blank_start)) {
+ /* Update to correct count and vblank timestamp if racing with
+* vblank irq. This also updates to the correct vblank timestamp
+* even in VRR mode, as scanout is past the front-porch atm.
+*/
+ drm_crtc_accurate_vblank_count(_crtc->base);
- } else
- WARN_ON(1);
+ /* Wake up userspace by sending the pageflip event with proper
+* count and timestamp of vblank of flip completion.
+*/
+ if (e) {
+ drm_crtc_send_vblank_event(_crtc->base, e);
+
+ /* Event sent, so done with vblank for this flip */
+ drm_crtc_vblank_put(_crtc->base);
+ }
+ } else if (e) {
+ /* VRR active and inside front-porch: vblank count and
+* timestamp for pageflip event will only be up to date after
+* drm_crtc_handle_vblank() has been executed from late vblank
+* irq handler after start of back-porch (vline 0). We queue the
+
[PATCH 3/4] drm/amd/display: In VRR mode, do DRM core vblank handling at end of vblank.
In VRR mode, proper vblank/pageflip timestamps can only be computed
after the display scanout position has left front-porch. Therefore
delay calls to drm_crtc_handle_vblank(), and thereby calls to
drm_update_vblank_count() and pageflip event delivery, to after the
end of front-porch when in VRR mode.
We add a new vupdate irq, which triggers at the end of the vupdate
interval, ie. at the end of vblank, and calls the core vblank handler
function. The new irq handler is not executed in standard non-VRR
mode, so vblank handling for fixed refresh rate mode is identical
to the past implementation.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 129 -
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 9 ++
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 22
.../amd/display/dc/irq/dce110/irq_service_dce110.c | 7 +-
.../amd/display/dc/irq/dce120/irq_service_dce120.c | 7 +-
.../amd/display/dc/irq/dce80/irq_service_dce80.c | 6 +-
.../amd/display/dc/irq/dcn10/irq_service_dcn10.c | 40 +--
8 files changed, 205 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index f88761a..64167dd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -827,6 +827,7 @@ struct amdgpu_device {
/* For pre-DCE11. DCE11 and later are in "struct amdgpu_device->dm" */
struct work_struct hotplug_work;
struct amdgpu_irq_src crtc_irq;
+ struct amdgpu_irq_src vupdate_irq;
struct amdgpu_irq_src pageflip_irq;
struct amdgpu_irq_src hpd_irq;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 85e4f87..555d9e9f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -315,6 +315,32 @@ static void dm_pflip_high_irq(void *interrupt_params)
drm_crtc_vblank_put(_crtc->base);
}
+static void dm_vupdate_high_irq(void *interrupt_params)
+{
+ struct common_irq_params *irq_params = interrupt_params;
+ struct amdgpu_device *adev = irq_params->adev;
+ struct amdgpu_crtc *acrtc;
+ struct dm_crtc_state *acrtc_state;
+
+ acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src -
IRQ_TYPE_VUPDATE);
+
+ if (acrtc) {
+ acrtc_state = to_dm_crtc_state(acrtc->base.state);
+
+ DRM_DEBUG_DRIVER("crtc:%d, vupdate-vrr:%d\n", acrtc->crtc_id,
+amdgpu_dm_vrr_active(acrtc_state));
+
+ /* Core vblank handling is done here after end of front-porch in
+* vrr mode, as vblank timestamping will give valid results
+* while now done after front-porch. This will also deliver
+* page-flip completion events that have been queued to us
+* if a pageflip happened inside front-porch.
+*/
+ if (amdgpu_dm_vrr_active(acrtc_state))
+ drm_crtc_handle_vblank(>base);
+ }
+}
+
static void dm_crtc_high_irq(void *interrupt_params)
{
struct common_irq_params *irq_params = interrupt_params;
@@ -325,11 +351,24 @@ static void dm_crtc_high_irq(void *interrupt_params)
acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src -
IRQ_TYPE_VBLANK);
if (acrtc) {
- drm_crtc_handle_vblank(>base);
- amdgpu_dm_crtc_handle_crc_irq(>base);
-
acrtc_state = to_dm_crtc_state(acrtc->base.state);
+ DRM_DEBUG_DRIVER("crtc:%d, vupdate-vrr:%d\n", acrtc->crtc_id,
+amdgpu_dm_vrr_active(acrtc_state));
+
+ /* Core vblank handling at start of front-porch is only possible
+* in non-vrr mode, as only there vblank timestamping will give
+* valid results while done in front-porch. Otherwise defer it
+* to dm_vupdate_high_irq after end of front-porch.
+*/
+ if (!amdgpu_dm_vrr_active(acrtc_state))
+ drm_crtc_handle_vblank(>base);
+
+ /* Following stuff must happen at start of vblank, for crc
+* computation and below-the-range btr support in vrr mode.
+*/
+ amdgpu_dm_crtc_handle_crc_irq(>base);
+
if (acrtc_state->stream &&
acrtc_state->vrr_params.supported &&
acrtc_state->freesync_config.state ==
VRR_STATE_ACTIVE_VARIABLE) {
@@ -1447,6 +1486,27 @@ static int dce110_register_irq_handlers(struct
amdgpu_device *adev)
dm_crtc_high_irq, c_irq_params);
}
+ /* Use VUPDATE interrupt */
+ for (i =
[PATCH 2/4] drm/amd/display: Rework vrr flip throttling for late vblank irq.
For throttling to work correctly, we always need a baseline vblank
count last_flip_vblank that increments at start of front-porch.
This is the case for drm_crtc_vblank_count() in non-VRR mode, where
the vblank irq fires at start of front-porch and triggers DRM core
vblank handling, but it is no longer the case in VRR mode, where
core vblank handling is done later, after end of front-porch.
Therefore drm_crtc_vblank_count() is no longer useful for this.
We also can't use drm_crtc_accurate_vblank_count(), as that would
screw up vblank timestamps in VRR mode when called in front-porch.
To solve this, use the cooked hardware vblank counter returned by
amdgpu_get_vblank_counter_kms() instead, as that one is cooked to
always increment at start of front-porch, independent of when
vblank related irq's fire.
This patch allows vblank irq handling to happen anywhere within
vblank of even after it, without a negative impact on flip
throttling, so followup patches can shift the vblank core
handling trigger point wherever they need it.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 2 +-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 23 +--
2 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
index 889e443..add238f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
@@ -406,7 +406,7 @@ struct amdgpu_crtc {
struct amdgpu_flip_work *pflip_works;
enum amdgpu_flip_status pflip_status;
int deferred_flip_completion;
- u64 last_flip_vblank;
+ u32 last_flip_vblank;
/* pll sharing */
struct amdgpu_atom_ss ss;
bool ss_enabled;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index c1c3815..85e4f87 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -286,7 +286,7 @@ static void dm_pflip_high_irq(void *interrupt_params)
}
/* Update to correct count(s) if racing with vblank irq */
- amdgpu_crtc->last_flip_vblank =
drm_crtc_accurate_vblank_count(_crtc->base);
+ drm_crtc_accurate_vblank_count(_crtc->base);
/* wake up userspace */
if (amdgpu_crtc->event) {
@@ -298,6 +298,14 @@ static void dm_pflip_high_irq(void *interrupt_params)
} else
WARN_ON(1);
+ /* Keep track of vblank of this flip for flip throttling. We use the
+* cooked hw counter, as that one incremented at start of this vblank
+* of pageflip completion, so last_flip_vblank is the forbidden count
+* for queueing new pageflips if vsync + VRR is enabled.
+*/
+ amdgpu_crtc->last_flip_vblank =
amdgpu_get_vblank_counter_kms(adev->ddev,
+ amdgpu_crtc->crtc_id);
+
amdgpu_crtc->pflip_status = AMDGPU_FLIP_NONE;
spin_unlock_irqrestore(>ddev->event_lock, flags);
@@ -4769,9 +4777,8 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
unsigned long flags;
struct amdgpu_bo *abo;
uint64_t tiling_flags;
- uint32_t target, target_vblank;
- uint64_t last_flip_vblank;
- bool vrr_active = acrtc_state->freesync_config.state ==
VRR_STATE_ACTIVE_VARIABLE;
+ uint32_t target_vblank, last_flip_vblank;
+ bool vrr_active = amdgpu_dm_vrr_active(acrtc_state);
bool pflip_present = false;
struct {
@@ -4918,7 +4925,7 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
* clients using the GLX_OML_sync_control extension or
* DRI3/Present extension with defined target_msc.
*/
- last_flip_vblank = drm_crtc_vblank_count(pcrtc);
+ last_flip_vblank =
amdgpu_get_vblank_counter_kms(dm->ddev, acrtc_attach->crtc_id);
}
else {
/* For variable refresh rate mode only:
@@ -4934,11 +4941,7 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
spin_unlock_irqrestore(>dev->event_lock, flags);
}
- target = (uint32_t)last_flip_vblank + wait_for_vblank;
-
- /* Prepare wait for target vblank early - before the
fence-waits */
- target_vblank = target - (uint32_t)drm_crtc_vblank_count(pcrtc)
+
- amdgpu_get_vblank_counter_kms(pcrtc->dev,
acrtc_attach->crtc_id);
+ target_vblank = last_flip_vblank + wait_for_vblank;
/*
* Wait until we're out of the vertical blank period before the
one
--
2.7.4
___
dri-devel mailing list
[PATCH 1/4] drm/amd/display: Prevent vblank irq disable while VRR is active.
During VRR mode we can not allow vblank irq dis-/enable
transitions, as an enable after a disable can happen at
an arbitrary time during the video refresh cycle, e.g.,
with a high likelyhood inside vblank front-porch. An
enable during front-porch would cause vblank timestamp
updates/calculations which are completely bogus, given
the code can't know when the vblank will end as long
as we are in front-porch with no page flip completed.
Hold a permanent vblank reference on the crtc while
in active VRR mode to prevent a vblank disable, and
drop the reference again when switching back to fixed
refresh rate non-VRR mode.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index a718ac2..c1c3815 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -251,6 +251,12 @@ get_crtc_by_otg_inst(struct amdgpu_device *adev,
return NULL;
}
+static inline bool amdgpu_dm_vrr_active(struct dm_crtc_state *dm_state)
+{
+ return dm_state->freesync_config.state == VRR_STATE_ACTIVE_VARIABLE ||
+ dm_state->freesync_config.state == VRR_STATE_ACTIVE_FIXED;
+}
+
static void dm_pflip_high_irq(void *interrupt_params)
{
struct amdgpu_crtc *amdgpu_crtc;
@@ -4716,6 +4722,32 @@ static void update_freesync_state_on_stream(
(int)vrr_params.state);
}
+static void amdgpu_dm_handle_vrr_transition(struct dm_crtc_state *old_state,
+ struct dm_crtc_state *new_state)
+{
+ bool old_vrr_active = amdgpu_dm_vrr_active(old_state);
+ bool new_vrr_active = amdgpu_dm_vrr_active(new_state);
+
+ if (!old_vrr_active && new_vrr_active) {
+ /* Transition VRR inactive -> active:
+* While VRR is active, we must not disable vblank irq, as a
+* reenable after disable would compute bogus vblank/pflip
+* timestamps if it likely happened inside display front-porch.
+*/
+ drm_crtc_vblank_get(new_state->base.crtc);
+ DRM_DEBUG_DRIVER("%s: crtc=%u VRR off->on: Get vblank ref\n",
+__func__, new_state->base.crtc->base.id);
+ }
+ else if (old_vrr_active && !new_vrr_active) {
+ /* Transition VRR active -> inactive:
+* Allow vblank irq disable again for fixed refresh rate.
+*/
+ drm_crtc_vblank_put(new_state->base.crtc);
+ DRM_DEBUG_DRIVER("%s: crtc=%u VRR on->off: Drop vblank ref\n",
+__func__, new_state->base.crtc->base.id);
+ }
+}
+
static void amdgpu_dm_commit_planes(struct drm_atomic_state *state,
struct dc_state *dc_state,
struct drm_device *dev,
@@ -4757,6 +4789,9 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
goto cleanup;
}
+ /* Take care to hold extra vblank ref for a crtc in VRR mode */
+ amdgpu_dm_handle_vrr_transition(dm_old_crtc_state, acrtc_state);
+
/* update planes when needed */
for_each_oldnew_plane_in_state(state, plane, old_plane_state,
new_plane_state, i) {
struct drm_crtc *crtc = new_plane_state->crtc;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
AMD Freesync patches for proper vblank and pageflip timestamping in VRR mode.
Hi This series implements properly working vblank and pageflip completion timestamping for amdgpu in VRR / FreeSync mode. Now pageflip timestamps for pageflip events always carry the vblank timestamp of the vblank in which the flip completed, and the vblank timestamp is as accurate as in fixed refresh rate mode. It was successfully tested on a DCE-8 gpu by myself, and also lightly tested on a DCN-1 gpu by Nicholas Kazlauskas. I want to thank Nicholas for helpful discussions, testing and feedback on this patch series. The series applies cleanly to current agd5f/drm-next-5.2-wip, against which it was tested. It also applies against current amd-staging-drm-next with a trivial fix to patch 2/4 like shown in the diff below: Thanks, -mario @@ -80,2 +80,3 @@ - uint32_t target, target_vblank; + bool pflip_present = false; - uint64_t last_flip_vblank; @@ -84,3 +85,2 @@ + bool vrr_active = amdgpu_dm_vrr_active(acrtc_state); - bool pflip_present = false; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110182] igt/gem_sync
https://bugs.freedesktop.org/show_bug.cgi?id=110182 chanchal changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |singhals...@gmail.com |.org| -- 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 110182] igt/gem_sync
https://bugs.freedesktop.org/show_bug.cgi?id=110182 chanchal changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from chanchal --- indiver -- 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 110182] igt/gem_sync
https://bugs.freedesktop.org/show_bug.cgi?id=110182 Bug ID: 110182 Summary: igt/gem_sync Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: IGT Assignee: dri-devel@lists.freedesktop.org Reporter: singhals...@gmail.com igt/gem_sync -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 1/6] drm/bridge: Export drm_bridge_detach
On Mon, Mar 18, 2019 at 10:27 PM Paul Kocialkowski wrote: > > Hi, > > Le lundi 18 mars 2019 à 22:18 +0530, Jagan Teki a écrit : > > Hi Paul, > > > > On Fri, Mar 15, 2019 at 6:58 PM Paul Kocialkowski > > wrote: > > > Hi Jakan, > > > > > > On Fri, 2019-03-15 at 18:38 +0530, Jagan Teki wrote: > > > > Export drm_bridge_detach from drm bridge core so-that it > > > > can use on respective interface or bridge driver while > > > > detaching the bridge. > > > > > > I don't see why this change is required based on the commit log. The > > > DRM bridge code clearly indicates that drm_bridge_attach should *not* > > > be balanced with a drm_bridge_detach call in the driver, so this seems > > > quite wrong. > > > > > > The DRM core itself should handle detaching the bridge, not the driver. > > > Is there any reason why you need to do things differently for DSI? > > > > Yes, you are correct the detach of bridge is being taking care via > > drm_encoder_cleanup. This patch exported explicitly, since we need to > > taken care bridge detach during unbind even exynos_drm_dsi in other > > patch seems using detach by explicitly pointing. > > I can see that from your patches, but you are not explaining why you > need the change. And if the framework doesn't work for your case, you > should certainly try and fix the framework instead of working around > the issue. Please see below comments. > > Anyway, you should probably look into using drm_panel_bridge_add, it > might fix the underlying issue on its own. > > > so I think the better approach is to use drm_encoder_cleanup in > > unbind, what do you say? > > I any case, you need to state what your problem is (in the commit log, > and not even in subsequent discussions) so that we can have a chance to > understand it and provide some feedback about what is an appropriate > fix and what is not. We can't understand the fix if we can't understand > the underlying issue. True, if my intentions is trying to fix some issue, but as I said in previous mail since the other dsi (exynos_drm_dsi) driver is explicitly detaching I presume it require or missed the export, not thought about fix and neither I mentioned on the commit head. Anyway thanks for the review, will update the code accordingly in next version. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/9] drm/syncobj: add support for timeline point wait v8
On 15/03/2019 12:09, Chunming Zhou wrote:
points array is one-to-one match with syncobjs array.
v2:
add seperate ioctl for timeline point wait, otherwise break uapi.
v3:
userspace can specify two kinds waits::
a. Wait for time point to be completed.
b. and wait for time point to become available
v4:
rebase
v5:
add comment for xxx_WAIT_AVAILABLE
v6: rebase and rework on new container
v7: drop _WAIT_COMPLETED, it is the default anyway
v8: correctly handle garbage collected fences
Signed-off-by: Chunming Zhou
Signed-off-by: Christian König
Cc: Daniel Rakos
Cc: Jason Ekstrand
Cc: Bas Nieuwenhuizen
Cc: Dave Airlie
Cc: Chris Wilson
---
drivers/gpu/drm/drm_internal.h | 2 +
drivers/gpu/drm/drm_ioctl.c| 2 +
drivers/gpu/drm/drm_syncobj.c | 153 ++---
include/uapi/drm/drm.h | 15
4 files changed, 143 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 251d67e04c2d..331ac6225b58 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -182,6 +182,8 @@ int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev,
void *data,
struct drm_file *file_private);
int drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
+int drm_syncobj_timeline_wait_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
int drm_syncobj_reset_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 687943df58e1..c984654646fa 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -688,6 +688,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_WAIT, drm_syncobj_wait_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT,
drm_syncobj_timeline_wait_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_RESET, drm_syncobj_reset_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_SIGNAL, drm_syncobj_signal_ioctl,
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 19a9ce638119..eae51978cda4 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -61,6 +61,7 @@ struct syncobj_wait_entry {
struct task_struct *task;
struct dma_fence *fence;
struct dma_fence_cb fence_cb;
+ u64point;
};
static void syncobj_wait_syncobj_func(struct drm_syncobj *syncobj,
@@ -95,6 +96,8 @@ EXPORT_SYMBOL(drm_syncobj_find);
static void drm_syncobj_fence_add_wait(struct drm_syncobj *syncobj,
struct syncobj_wait_entry *wait)
{
+ struct dma_fence *fence;
+
if (wait->fence)
return;
@@ -103,11 +106,15 @@ static void drm_syncobj_fence_add_wait(struct drm_syncobj *syncobj,
* have the lock, try one more time just to be sure we don't add a
* callback when a fence has already been set.
*/
- if (syncobj->fence)
- wait->fence = dma_fence_get(
- rcu_dereference_protected(syncobj->fence, 1));
- else
+ fence = dma_fence_get(rcu_dereference_protected(syncobj->fence, 1));
+ if (!fence || dma_fence_chain_find_seqno(, wait->point)) {
+ dma_fence_put(fence);
list_add_tail(>node, >cb_list);
+ } else if (!fence) {
+ wait->fence = dma_fence_get_stub();
+ } else {
+ wait->fence = fence;
+ }
spin_unlock(>lock);
}
@@ -149,10 +156,8 @@ void drm_syncobj_add_point(struct drm_syncobj *syncobj,
dma_fence_chain_init(chain, prev, fence, point);
rcu_assign_pointer(syncobj->fence, >base);
- list_for_each_entry_safe(cur, tmp, >cb_list, node) {
- list_del_init(>node);
+ list_for_each_entry_safe(cur, tmp, >cb_list, node)
syncobj_wait_syncobj_func(syncobj, cur);
- }
spin_unlock(>lock);
/* Walk the chain once to trigger garbage collection */
@@ -184,10 +189,8 @@ void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
rcu_assign_pointer(syncobj->fence, fence);
if (fence != old_fence) {
- list_for_each_entry_safe(cur, tmp, >cb_list, node) {
- list_del_init(>node);
+ list_for_each_entry_safe(cur, tmp, >cb_list, node)
syncobj_wait_syncobj_func(syncobj, cur);
- }
}
spin_unlock(>lock);
@@ -644,13 +647,27 @@
Re: [PATCH v5 07/19] media: vsp1: dl: Support one-shot entries in the display list
Hi Laurent, Sorry for the delay, I was travelling last week and didn't find a chance to digest your diagrams (thanks for all the detail!) On Fri, Mar 08, 2019 at 02:24:40PM +0200, Laurent Pinchart wrote: > Hi Brian, > > On Thu, Mar 07, 2019 at 12:28:08PM +, Brian Starkey wrote: > > On Wed, Mar 06, 2019 at 08:22:44PM +0200, Laurent Pinchart wrote: > > > > [snip] > > > > > I can always queue a new one, but I have no way of telling if the newly > > > queued list raced with the frame end interrupt. > > > > > > There's another register I'm not using that contains a shadow copy of > > > the registers list DMA address. It mirrors the address programmed by the > > > driver when there is no DMA of the registers list in progress, and > > > contains the address the of registers list being DMA'ed when a DMA is in > > > progress. I don't think I can do much with it, as reading it either > > > before or after reprogramming (to check if I can reprogram or if the > > > reprogram has been taken into account) is racy. > > > > When you say it mirrors the address programmed, is that latched when > > the update is accepted, or it will update the moment you program the > > address register? > > It is latched when the update is processed, at the next vblank following > the address programming. The timing diagram below shows vblank, the UPD > bit I use for synchronization, the registers list address register > exposed to the CPU, and the internal address used to DMA the registers > list. The address register is written four times to show how the > hardware reacts, but in practice there will be a single write per frame, > right after the beginning of vblank. > > DMA starts > | DMA ends > | | > V V > ___ > VBLANK __| | > > UPD_||___| >_ __ _ ___ > ADDR register __A__X__B___X__C__X___DX___E___ >__ > ADDR internal ___A__X__C_ > > I can reprogram the address any number of times I want before the > vblank, but the update bit mechanism only lets me protect the race > related to the first write. For any subsequent write I won't be able to > tell whether it was complete before the hardware started the frame, or > arrived too late. > > > I assume the latter or you would have thought of this yourself (that > > seems like a really strange/not-useful behaviour!). But if it is the > > former you could: > > > > - In writeback start-of-frame, create a copy of the register list, > >disabling writeback. > > - Write the address of this copy to the register > > > > If/when an atomic commit comes in before you service the next > > end-of-frame: > > > > - Write the address of the new register list > > - Check the status register. If the "pending" bit is zero, you know > >you had a potential race. > > - Check the DMA address register. If it corresponds to the new > > scene, the new commit won the race, otherwise it's been delayed > > by a frame. > > The issue here is that there's a potential race if the pending (UPD) bit > is one too. If the commit arrives just before vblank, but the address is > written just after vblank, after the UPD bit has been reset to 0 by the > hardware, but before the vblank interrupt is processed, then the commit > won't be applied yet, and I will have no way to know. Compare the two > following scenarios: > > [1] [2] [3] [4] [5] > | | | | | > | V V | V > V __ V __ > VBLANK ___| || |__ > _ ___ > UPD_| |___| |_ >_ _ _ ___ > ADDR register __A__X__B__X__C__X___D___ >___ _ > ADDR internal ___A___X__BX__D__ > > [1] Atomic commit, registers list address write, with writeback enabled > [2] DMA starts for first atomic commit > [3] Writeback disable registers list address write > [4] Next atomic commit, with writeback disabled > [5] DMA starts for second atomic commit > > [1] [2] [3] [4][5] > | | | | | > | V V
Re: [PATCH, RESEND] drm/vmwgfx: Don't double-free the mode stored in par->set_mode
Hi Thomas,
Thanks for doing this and somehow I missed the last patch, sorry about
that. Have some questions below otherwise the patch looks good to me.
Reviewed-by: Deepak Rawat
I will include your changes in vmwgfx-next and run tests.
On Mon, 2019-03-18 at 15:47 +0100, Thomas Zimmermann wrote:
> When calling vmw_fb_set_par(), the mode stored in par->set_mode gets
> free'd
> twice. The first free is in vmw_fb_kms_detach(), the second is near
> the
> end of vmw_fb_set_par() under the name of 'old_mode'. The mode-
> setting code
> only works correctly if the mode doesn't actually change.
You mean to say that without your patch vmwgfx fb driver fail to change
the mode?
> Removing 'old_mode'
> in favor of using par->set_mode directly fixes the problem.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 12 +++-
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> index b913a56f3426..2a9112515f46 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> @@ -564,11 +564,9 @@ static int vmw_fb_set_par(struct fb_info *info)
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC)
> };
> - struct drm_display_mode *old_mode;
> struct drm_display_mode *mode;
> int ret;
>
> - old_mode = par->set_mode;
> mode = drm_mode_duplicate(vmw_priv->dev, _mode);
> if (!mode) {
> DRM_ERROR("Could not create new fb mode.\n");
> @@ -579,11 +577,7 @@ static int vmw_fb_set_par(struct fb_info *info)
> mode->vdisplay = var->yres;
> vmw_guess_mode_timing(mode);
>
> - if (old_mode && drm_mode_equal(old_mode, mode)) {
> - drm_mode_destroy(vmw_priv->dev, mode);
> - mode = old_mode;
> - old_mode = NULL;
I am having hard time understanding original intention for this piece
of code. Was there a restriction to send pointer to old mode if mode
were same and that restriction don't hold anymore. Sorry I am not
familiar with this code area.
> - } else if (!vmw_kms_validate_mode_vram(vmw_priv,
> + if (!vmw_kms_validate_mode_vram(vmw_priv,
> mode->hdisplay *
> DIV_ROUND_UP(var-
> >bits_per_pixel, 8),
> mode->vdisplay)) {
> @@ -620,8 +614,8 @@ static int vmw_fb_set_par(struct fb_info *info)
> schedule_delayed_work(>local_work, 0);
>
> out_unlock:
> - if (old_mode)
> - drm_mode_destroy(vmw_priv->dev, old_mode);
> + if (par->set_mode)
> + drm_mode_destroy(vmw_priv->dev, par->set_mode);
> par->set_mode = mode;
>
> mutex_unlock(>bo_mutex);
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-develdata=02%7C01%7Cdrawat%40vmware.com%7Cb1508247a3954fb0b08b08d6abb0bcd0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636885172908359973sdata=AN6UTrMzxcVK7MC6bX3OxNbcyq0j4HdKt0dk1yyHOHc%3Dreserved=0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] dt-bindings: display: bridge: Add ICN6211 MIPI-DSI to RGB convertor bridge
On Fri, Mar 15, 2019 at 7:04 PM Maxime Ripard wrote: > > On Fri, Mar 15, 2019 at 06:38:23PM +0530, Jagan Teki wrote: > > ICN6211 is MIPI-DSI/RGB converter bridge from chipone. > > It has a flexible configuration of MIPI DSI signal input > > and produce RGB565, RGB666, RGB888 output format. > > > > Add dt-bingings for it. > > > > Signed-off-by: Jagan Teki > > --- > > .../display/bridge/chipone,icn6211.txt| 36 +++ > > 1 file changed, 36 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/chipone,icn6211.txt > > > > diff --git > > a/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.txt > > b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.txt > > new file mode 100644 > > index ..7f13efd7ee7f > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/bridge/chipone,icn6211.txt > > @@ -0,0 +1,36 @@ > > +Chipone ICN6211 MIPI-DSI to RGB Convertor Bridge > > + > > +ICN6211 is MIPI-DSI/RGB converter bridge from chipone. > > +It has a flexible configuration of MIPI DSI signal input > > +and produce RGB565, RGB666, RGB888 output format. > > + > > +Required properties for RGB: > > +- compatible: must be "chipone,icn6211" and one of: > > + * "bananapi,icn6211" > > Why is that compatible needed? chipone,icn6211 - generic compatible bridge controller IC bananapi,icn6211 - compatible for icn6211 bridge using on bananapi panel I hope this would be proper bindings in terms of controller IC with associate device, anything wrong? Infact I used similar reference from Ilitek Bananapi panel from here Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.txt This is what I understood based on dt-binding, correct if I'm wrong. ilitek,ili9881c - generic ilitek,ili9881c compatable bananapi,lhr050h41 - compatible for bananapi panel associated with this ilitek IC > > > +- reg: the virtual channel number of a DSI peripheral > > +- reset-gpios: a GPIO phandle for the reset pin > > + > > +The device node can contain following 'port' child nodes, > > +according to the OF graph bindings defined in [1]: > > + 0: DSI Input, not required, if the bridge is DSI controlled > > + 1: RGB Output, mandatory > > Your example doesn't have that input port Yes, I intentionally did this by referring existing bridge binding. Documentation/devicetree/bindings/display/bridge/toshiba,tc35876*.txt Do we really need? since the input port can be part of panel binding. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 1/6] drm/bridge: Export drm_bridge_detach
Hi, Le lundi 18 mars 2019 à 22:18 +0530, Jagan Teki a écrit : > Hi Paul, > > On Fri, Mar 15, 2019 at 6:58 PM Paul Kocialkowski > wrote: > > Hi Jakan, > > > > On Fri, 2019-03-15 at 18:38 +0530, Jagan Teki wrote: > > > Export drm_bridge_detach from drm bridge core so-that it > > > can use on respective interface or bridge driver while > > > detaching the bridge. > > > > I don't see why this change is required based on the commit log. The > > DRM bridge code clearly indicates that drm_bridge_attach should *not* > > be balanced with a drm_bridge_detach call in the driver, so this seems > > quite wrong. > > > > The DRM core itself should handle detaching the bridge, not the driver. > > Is there any reason why you need to do things differently for DSI? > > Yes, you are correct the detach of bridge is being taking care via > drm_encoder_cleanup. This patch exported explicitly, since we need to > taken care bridge detach during unbind even exynos_drm_dsi in other > patch seems using detach by explicitly pointing. I can see that from your patches, but you are not explaining why you need the change. And if the framework doesn't work for your case, you should certainly try and fix the framework instead of working around the issue. Anyway, you should probably look into using drm_panel_bridge_add, it might fix the underlying issue on its own. > so I think the better approach is to use drm_encoder_cleanup in > unbind, what do you say? I any case, you need to state what your problem is (in the commit log, and not even in subsequent discussions) so that we can have a chance to understand it and provide some feedback about what is an appropriate fix and what is not. We can't understand the fix if we can't understand the underlying issue. Cheers, Paul -- Paul Kocialkowski, Bootlin Embedded Linux and kernel engineering https://bootlin.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH 1/6] drm/bridge: Export drm_bridge_detach
Hi Paul, On Fri, Mar 15, 2019 at 6:58 PM Paul Kocialkowski wrote: > > Hi Jakan, > > On Fri, 2019-03-15 at 18:38 +0530, Jagan Teki wrote: > > Export drm_bridge_detach from drm bridge core so-that it > > can use on respective interface or bridge driver while > > detaching the bridge. > > I don't see why this change is required based on the commit log. The > DRM bridge code clearly indicates that drm_bridge_attach should *not* > be balanced with a drm_bridge_detach call in the driver, so this seems > quite wrong. > > The DRM core itself should handle detaching the bridge, not the driver. > Is there any reason why you need to do things differently for DSI? Yes, you are correct the detach of bridge is being taking care via drm_encoder_cleanup. This patch exported explicitly, since we need to taken care bridge detach during unbind even exynos_drm_dsi in other patch seems using detach by explicitly pointing. so I think the better approach is to use drm_encoder_cleanup in unbind, what do you say? Jagan. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC dma-buf 0/3] Improve the dma-buf tracking
Hi Daniel,
On Fri, 15 Mar 2019 at 16:36, Daniel Vetter wrote:
>
> On Thu, Mar 14, 2019 at 6:49 PM Sumit Semwal wrote:
> >
> > Hello Chenbo,Thank you for your RFC series.
> >
> > On Wed, 27 Feb 2019 at 09:24, Chenbo Feng wrote:
> > >
> > > Currently, all dma-bufs share the same anonymous inode. While we can count
> > > how many dma-buf fds or mappings a process has, we can't get the size of
> > > the backing buffers or tell if two entries point to the same dma-buf. And
> > > in debugfs, we can get a per-buffer breakdown of size and reference count,
> > > but can't tell which processes are actually holding the references to each
> > > buffer.
> > >
> > > To resolve the issue above and provide better method for userspace to
> > > track
> > > the dma-buf usage across different processes, the following changes are
> > > proposed in dma-buf kernel side. First of all, replace the singleton inode
> > > inside the dma-buf subsystem with a mini-filesystem, and assign each
> > > dma-buf a unique inode out of this filesystem. With this change, calling
> > > stat(2) on each entry gives the caller a unique ID (st_ino), the buffer's
> > > size (st_size), and even the number of pages assigned to each dma-buffer.
> > > Secoundly, add the inode information to /sys/kernel/debug/dma_buf/bufinfo
> > > so in the case where a buffer is mmap()ed into a process’s address space
> > > but all remaining fds have been closed, we can still get the dma-buf
> > > information and try to accociate it with the process by searching the
> > > proc/pid/maps and looking for the corresponding inode number exposed in
> > > dma-buf debug fs. Thirdly, created an ioctl to assign names to dma-bufs
> > > which lets userspace assign short names (e.g., "CAMERA") to buffers. This
> > > information can be extremely helpful for tracking and accounting shared
> > > buffers based on their usage and original purpose. Last but not least, add
> > > dma-buf information to /proc/pid/fdinfo by adding a show_fdinfo() handler
> > > to dma_buf_file_operations. The handler will print the file_count and name
> > > of each buffer.
> >
> > In general, I think I like the idea as it contributes to a much more
> > relevant usage analysis of dma-buf backed buffers.
> > I will get to doing a more detailed review soon, but immediately, we
> > might want to think a bit about the get/set_name IOCTLS - do we need
> > to think of disallowing multiple renaming of buffers once they start
> > getting used? It could otherwise make the whole metrics a lot
> > confused?
> >
> > >
> > > Greg Hackmann (3):
> > > dma-buf: give each buffer a full-fledged inode
> > > dma-buf: add DMA_BUF_{GET,SET}_NAME ioctls
> > > dma-buf: add show_fdinfo handler
>
> I'm not seeing the patches, so just quick comment here: Some drivers
> (at least vc4) already have the concept of buffer names. Would be neat
> to integrate this between dma-buf and drm_gem in prime.
>
FYI, here's the patch series - https://patchwork.freedesktop.org/series/57282/
Best,
Sumit.
> Aside from that sounds like a good idea overall, but I can't see any details.
> -Daniel
>
> > >
> > > drivers/dma-buf/dma-buf.c| 121 ---
> > > include/linux/dma-buf.h | 5 +-
> > > include/uapi/linux/dma-buf.h | 4 ++
> > > include/uapi/linux/magic.h | 1 +
> > > 4 files changed, 122 insertions(+), 9 deletions(-)
> > >
> > > --
> > > 2.21.0.rc2.261.ga7da99ff1b-goog
> > >
> >
> > Best,
> > Sumit.
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Thanks and regards,
Sumit Semwal
Linaro Consumer Group - Kernel Team Lead
Linaro.org │ Open source software for ARM SoCs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/sun4i: hdmi: add support for ddc-i2c-bus property
On Thu, Mar 14, 2019 at 04:09:13PM +, Måns Rullgård wrote:
> Maxime Ripard writes:
>
> > On Mon, Mar 11, 2019 at 04:11:06PM +, Måns Rullgård wrote:
> >> Maxime Ripard writes:
> >>
> >> > Hi!
> >> >
> >> > On Mon, Mar 11, 2019 at 01:47:13PM +, Mans Rullgard wrote:
> >> >> Sometimes it is desirabled to use a separate i2c controller for ddc
> >> >> access. This adds support for the ddc-i2c-bus property of the
> >> >> hdmi-connector node, using the specified controller if provided.
> >> >>
> >> >> Signed-off-by: Mans Rullgard
> >> >> ---
> >> >> drivers/gpu/drm/sun4i/sun4i_hdmi.h | 1 +
> >> >> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 37 +++---
> >> >> 2 files changed, 35 insertions(+), 3 deletions(-)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> >> >> b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> >> >> index b685ee11623d..b08c4453d47c 100644
> >> >> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> >> >> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> >> >> @@ -269,6 +269,7 @@ struct sun4i_hdmi {
> >> >> struct clk *tmds_clk;
> >> >>
> >> >> struct i2c_adapter *i2c;
> >> >> + struct i2c_adapter *ddc_i2c;
> >> >>
> >> >> /* Regmap fields for I2C adapter */
> >> >> struct regmap_field *field_ddc_en;
> >> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> >> >> b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> >> >> index 061d2e0d9011..5b2fac79f5d6 100644
> >> >> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> >> >> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> >> >> @@ -212,7 +212,7 @@ static int sun4i_hdmi_get_modes(struct
> >> >> drm_connector *connector)
> >> >> struct edid *edid;
> >> >> int ret;
> >> >>
> >> >> - edid = drm_get_edid(connector, hdmi->i2c);
> >> >> + edid = drm_get_edid(connector, hdmi->ddc_i2c ?: hdmi->i2c);
> >> >
> >> > You can't test whether ddc_i2c is NULL or not...
> >> >
> >> >> if (!edid)
> >> >> return 0;
> >> >>
> >> >> @@ -228,6 +228,28 @@ static int sun4i_hdmi_get_modes(struct
> >> >> drm_connector *connector)
> >> >> return ret;
> >> >> }
> >> >>
> >> >> +static struct i2c_adapter *sun4i_hdmi_get_ddc(struct device *dev)
> >> >> +{
> >> >> + struct device_node *phandle, *remote;
> >> >> + struct i2c_adapter *ddc;
> >> >> +
> >> >> + remote = of_graph_get_remote_node(dev->of_node, 1, -1);
> >> >> + if (!remote)
> >> >> + return ERR_PTR(-EINVAL);
> >> >> +
> >> >> + phandle = of_parse_phandle(remote, "ddc-i2c-bus", 0);
> >> >> + of_node_put(remote);
> >> >> + if (!phandle)
> >> >> + return NULL;
> >> >> +
> >> >> + ddc = of_get_i2c_adapter_by_node(phandle);
> >> >> + of_node_put(phandle);
> >> >> + if (!ddc)
> >> >> + return ERR_PTR(-EPROBE_DEFER);
> >> >> +
> >> >> + return ddc;
> >> >
> >> > ... Since even in (most) error cases you're returning a !NULL pointer.
> >> >
> >> >> +}
> >> >> +
> >> >> static const struct drm_connector_helper_funcs
> >> >> sun4i_hdmi_connector_helper_funcs = {
> >> >> .get_modes = sun4i_hdmi_get_modes,
> >> >> };
> >> >> @@ -575,6 +597,12 @@ static int sun4i_hdmi_bind(struct device *dev,
> >> >> struct device *master,
> >> >> goto err_disable_mod_clk;
> >> >> }
> >> >>
> >> >> + hdmi->ddc_i2c = sun4i_hdmi_get_ddc(dev);
> >> >> + if (IS_ERR(hdmi->ddc_i2c)) {
> >>
> >> ... which is checked here.
> >>
> >> The property is optional, so the idea was to return null in that case
> >> and use the built-in controller. If the property exists but some error
> >> occurs, we want to abort rather than proceed with the fallback which
> >> almost certainly won't work.
> >>
> >> Maybe I got something wrong in that logic.
> >
> > Indeed, I just got confused. I guess returning ENODEV in such a case,
> > and testing for that, would make things more obvious.
>
> There's also a case I hadn't thought of: property exists but isn't a
> valid phandle. What do you think is the correct action in that case?
I think we would have that one covered. of_parse_phandle will return
!NULL, but then of_get_i2c_adapter_by_node will return NULL since we
wouldn't have an associated i2c adapter to the bogus phandle, and you
are checking for that already.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 01/10] drm/fourcc: Add AFBC yuv fourccs for Mali
Hi, On Mon, Mar 18, 2019 at 11:17:55AM +0100, Maarten Lankhorst wrote: > Hey.. > > There's a conflict with this patch and the merge of topic/hdr-formats, > resulting in double definitions for Y210, Y410 and P010. > > Worse still is that one has set has_alpha to true for Y41x and other to false. > > ~Maarten > Oh that's sad :-( I think this fell through the cracks on our side when someone left our team. Also turns out I'm not subscribed to igt-dev. I see you commented the same on one of the previous patches, and that there was some discussion of this on the test patches too. I have been referring to Microsoft's page[1] as "the" source for these formats, which does indeed call out Y410 as having 2 bits of alpha. Our GPU expects alpha. Was there a specific reason for opting to change the test instead of the definition? Any way to get this changed now? It doesn't seem that sensible for the kernel to call something Y410 which doesn't match an "existing" definition by the same name. If alpha needs to be ignored on scanout, the alpha blend mode property can be used (more archaeology - I see that was still giving CRC failures, but that might be a "known issue" for all YUV on your HW?) -Brian [1] https://docs.microsoft.com/en-us/windows/desktop/medfound/10-bit-and-16-bit-yuv-video-formats#444-formats ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL FOR v5.2] R-Car DU changes
Hi Dave, The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b: Linux 5.1-rc1 (2019-03-17 14:22:26 -0700) are available in the Git repository at: git://linuxtv.org/pinchartl/media.git tags/du-next-20190318 for you to fetch changes up to 12e32f554d8ddd121f179cda25d0be612af9: drm: rcar-du: Add writeback support for R-Car Gen3 (2019-03-18 17:24:51 +0200) Please note that the series includes changes to the VSP driver, part of the Linux media tree. They have all been acked by Mauro for merge through your tree. Renesas display drivers changes for v5.2: - Display writeback (includes VSP changes and DRM/KMS API changes) Kieran Bingham (1): Revert "[media] v4l: vsp1: Supply frames to the DU continuously" Laurent Pinchart (17): media: vsp1: wpf: Fix partition configuration for display pipelines media: vsp1: Replace leftover occurrence of fragment with body media: vsp1: Fix addresses of display-related registers for VSP-DL media: vsp1: Replace the display list internal flag with a flags field media: vsp1: Add vsp1_dl_list argument to .configure_stream() operation media: vsp1: dl: Allow chained display lists for display pipelines media: vsp1: wpf: Add writeback support media: vsp1: drm: Split RPF format setting to separate function media: vsp1: drm: Extend frame completion API to the DU driver media: vsp1: drm: Implement writeback support drm: writeback: Cleanup job ownership handling when queuing job drm: writeback: Fix leak of writeback job drm: writeback: Add job prepare and cleanup operations drm: rcar-du: Fix rcar_du_crtc structure documentation drm: rcar-du: Store V4L2 fourcc in rcar_du_format_info structure drm: rcar-du: vsp: Extract framebuffer (un)mapping to separate functions drm: rcar-du: Add writeback support for R-Car Gen3 drivers/gpu/drm/arm/malidp_mw.c | 3 +- drivers/gpu/drm/drm_atomic_helper.c | 11 ++ drivers/gpu/drm/drm_atomic_state_helper.c | 4 + drivers/gpu/drm/drm_atomic_uapi.c | 31 +--- drivers/gpu/drm/drm_writeback.c | 73 - drivers/gpu/drm/rcar-du/Kconfig | 4 + drivers/gpu/drm/rcar-du/Makefile| 3 +- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 7 +- drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 9 +- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 37 + drivers/gpu/drm/rcar-du/rcar_du_kms.h | 1 + drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 122 +++--- drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 17 ++ drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 243 drivers/gpu/drm/rcar-du/rcar_du_writeback.h | 39 + drivers/gpu/drm/vc4/vc4_txp.c | 2 +- drivers/media/platform/vsp1/vsp1_brx.c | 1 + drivers/media/platform/vsp1/vsp1_clu.c | 1 + drivers/media/platform/vsp1/vsp1_dl.c | 84 ++ drivers/media/platform/vsp1/vsp1_dl.h | 6 +- drivers/media/platform/vsp1/vsp1_drm.c | 94 --- drivers/media/platform/vsp1/vsp1_drm.h | 2 +- drivers/media/platform/vsp1/vsp1_entity.c | 3 +- drivers/media/platform/vsp1/vsp1_entity.h | 7 +- drivers/media/platform/vsp1/vsp1_hgo.c | 1 + drivers/media/platform/vsp1/vsp1_hgt.c | 1 + drivers/media/platform/vsp1/vsp1_hsit.c | 1 + drivers/media/platform/vsp1/vsp1_lif.c | 1 + drivers/media/platform/vsp1/vsp1_lut.c | 1 + drivers/media/platform/vsp1/vsp1_regs.h | 6 +- drivers/media/platform/vsp1/vsp1_rpf.c | 1 + drivers/media/platform/vsp1/vsp1_rwpf.h | 1 + drivers/media/platform/vsp1/vsp1_sru.c | 1 + drivers/media/platform/vsp1/vsp1_uds.c | 1 + drivers/media/platform/vsp1/vsp1_uif.c | 1 + drivers/media/platform/vsp1/vsp1_video.c| 16 +- drivers/media/platform/vsp1/vsp1_wpf.c | 83 -- include/drm/drm_modeset_helper_vtables.h| 7 + include/drm/drm_writeback.h | 30 +++- include/media/vsp1.h| 19 ++- 40 files changed, 775 insertions(+), 200 deletions(-) create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_writeback.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_writeback.h -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202445] amdgpu/dc: framerate dropping below adaptive sync range causes screen flickering
https://bugzilla.kernel.org/show_bug.cgi?id=202445 --- Comment #27 from Clément Guérin (li...@protonmail.com) --- I'm sorry, I assumed this particular commit had been backported to Linux 5.0, and it's apparently not the case. I will try with both when I find some time tonight. -- 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: [PULL] topic/hdr-formats
Quoting Maarten Lankhorst (2019-03-13 13:21:46) > Hey Sean and Joonas, > > One more pull request for the hdr-formats topic branch. FP16 support > is now also implemented. > > Can this be pulled to drm-misc-next and dinq? Pulled to drm-intel-next-queued. Regards, Joonas > > ~Maarten > > topic/hdr-formats-2019-03-13: > Add support for floating point half-width formats. > The following changes since commit 296e9b19eff6157e1e4f130fa436e105c45725e9: > > drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for universal > planes (2019-03-05 12:49:00 +0100) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc tags/topic/hdr-formats-2019-03-13 > > for you to fetch changes up to a94bed60cb73962f344ead14b2ee7613280432c6: > > drm/i915/icl: Implement half float formats (2019-03-13 11:23:12 +0100) > > > Add support for floating point half-width formats. > > > Kevin Strasser (3): > drm/fourcc: Add 64 bpp half float formats > drm/i915: Refactor icl_is_hdr_plane > drm/i915/icl: Implement half float formats > > drivers/gpu/drm/drm_fourcc.c | 4 ++ > drivers/gpu/drm/i915/intel_atomic.c | 3 +- > drivers/gpu/drm/i915/intel_display.c | 29 +- > drivers/gpu/drm/i915/intel_drv.h | 7 ++-- > drivers/gpu/drm/i915/intel_sprite.c | 78 > +--- > include/uapi/drm/drm_fourcc.h| 11 + > 6 files changed, 120 insertions(+), 12 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH, RESEND] drm/vmwgfx: Don't double-free the mode stored in par->set_mode
When calling vmw_fb_set_par(), the mode stored in par->set_mode gets free'd
twice. The first free is in vmw_fb_kms_detach(), the second is near the
end of vmw_fb_set_par() under the name of 'old_mode'. The mode-setting code
only works correctly if the mode doesn't actually change. Removing 'old_mode'
in favor of using par->set_mode directly fixes the problem.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
index b913a56f3426..2a9112515f46 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
@@ -564,11 +564,9 @@ static int vmw_fb_set_par(struct fb_info *info)
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC)
};
- struct drm_display_mode *old_mode;
struct drm_display_mode *mode;
int ret;
- old_mode = par->set_mode;
mode = drm_mode_duplicate(vmw_priv->dev, _mode);
if (!mode) {
DRM_ERROR("Could not create new fb mode.\n");
@@ -579,11 +577,7 @@ static int vmw_fb_set_par(struct fb_info *info)
mode->vdisplay = var->yres;
vmw_guess_mode_timing(mode);
- if (old_mode && drm_mode_equal(old_mode, mode)) {
- drm_mode_destroy(vmw_priv->dev, mode);
- mode = old_mode;
- old_mode = NULL;
- } else if (!vmw_kms_validate_mode_vram(vmw_priv,
+ if (!vmw_kms_validate_mode_vram(vmw_priv,
mode->hdisplay *
DIV_ROUND_UP(var->bits_per_pixel, 8),
mode->vdisplay)) {
@@ -620,8 +614,8 @@ static int vmw_fb_set_par(struct fb_info *info)
schedule_delayed_work(>local_work, 0);
out_unlock:
- if (old_mode)
- drm_mode_destroy(vmw_priv->dev, old_mode);
+ if (par->set_mode)
+ drm_mode_destroy(vmw_priv->dev, par->set_mode);
par->set_mode = mode;
mutex_unlock(>bo_mutex);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 00/18] R-Car DU display writeback support
Em Mon, 18 Mar 2019 16:31:03 +0200 Laurent Pinchart escreveu: > Hello everybody, > > This is the latest and greatest version of the patch series that > implements display writeback support for the R-Car Gen3 platforms in the > VSP1 and DU drivers. All patches have been reviewed, all comments > incorporated, and the result rebased on top ov v5.1-rc1. > > Patches 01/18 to 11/18 prepare the VSP1 driver for writeback support > with all the necessary plumbing, including extensions of the API between > the VSP1 and DU drivers. > > The most significant change compared to v6 is the rebase on top of > v5.1-rc1. This was done to ease merging, as the VSP and DU parts would > normally go through different trees. I usually ask Mauro or Dave their > permission to merge the whole series through a single tree, and doing > the same this time I would select the DRM tree given that I hope to get > more DU patches merged in this development cycle. There is no foreseen > conflicting patch for the VSP in v5.2, but if a need arises, I will > them on top of the 11 first patches of this series and send a pull > request to Mauro to avoid conflicts. > > Mauro, I plan to send a pull request to Dave by the end of this week, so > if you'd like to have a look at the VSP patches, now would be a good > time :-) It's only driver changes, and they have been reviewed already, > so I don't expect any problem. > > Compared to v5 the major change is the usage of chained display lists in > the VSP to disable writeback after one frame, instead of patching the > active display list in memory. This should solve the potential DMA to > released buffer issue that could occur when the frame start interrupt > was delayed after frame end. Patch 06/18 and 07/18 are new in this > version to support usage of chained display pipelines. > > Compared to v4 the major change is the move from V4L2 to DRM writeback > connectors for the userspace API. This has caused a few issues with > writeback support to be uncovered, and they are addressed by patches > 12/18 to 14/18. > > Patches 15/18 to 17/18 then perform refactoring of the DU driver, to > finally add writeback support in patch 18/18. > > The writeback pixel format is restricted to RGB, due to the VSP1 > outputting RGB to the display and lacking a separate colour space > conversion unit for writeback. The writeback framebuffer size must match > the active mode, writeback scaling is not supported by the hardware. > > Writeback requests being part of atomic commits, they're queued to the > hardware when they are received, become active at the next vblank, and > complete on the following vblank. The display list chaining mechanism > ensures that writeback will be enabled for a single frame only, unless > the next atomic commit contains a separate writeback request. > > For convenience patches can be found at > > git://linuxtv.org/pinchartl/media.git drm/du/writeback > > Kieran Bingham (1): > Revert "[media] v4l: vsp1: Supply frames to the DU continuously" > > Laurent Pinchart (17): > media: vsp1: wpf: Fix partition configuration for display pipelines > media: vsp1: Replace leftover occurrence of fragment with body > media: vsp1: Fix addresses of display-related registers for VSP-DL > media: vsp1: Replace the display list internal flag with a flags field > media: vsp1: Add vsp1_dl_list argument to .configure_stream() > operation > media: vsp1: dl: Allow chained display lists for display pipelines > media: vsp1: wpf: Add writeback support > media: vsp1: drm: Split RPF format setting to separate function > media: vsp1: drm: Extend frame completion API to the DU driver > media: vsp1: drm: Implement writeback support For the media patches: Reviewed-by: Mauro Carvalho Chehab If those are the only changes at media side, feel free to push it via DRM tree. > drm: writeback: Cleanup job ownership handling when queuing job > drm: writeback: Fix leak of writeback job > drm: writeback: Add job prepare and cleanup operations > drm: rcar-du: Fix rcar_du_crtc structure documentation > drm: rcar-du: Store V4L2 fourcc in rcar_du_format_info structure > drm: rcar-du: vsp: Extract framebuffer (un)mapping to separate > functions > drm: rcar-du: Add writeback support for R-Car Gen3 > > drivers/gpu/drm/arm/malidp_mw.c | 3 +- > drivers/gpu/drm/drm_atomic_helper.c | 11 + > drivers/gpu/drm/drm_atomic_state_helper.c | 4 + > drivers/gpu/drm/drm_atomic_uapi.c | 31 +-- > drivers/gpu/drm/drm_writeback.c | 73 +- > drivers/gpu/drm/rcar-du/Kconfig | 4 + > drivers/gpu/drm/rcar-du/Makefile| 3 +- > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 7 +- > drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 9 +- > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 37 +++ > drivers/gpu/drm/rcar-du/rcar_du_kms.h | 1 + > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 122 +- >
[PATCH v7 16/18] drm: rcar-du: Store V4L2 fourcc in rcar_du_format_info structure
The mapping between DRM and V4L2 fourcc's is stored in two separate
tables in rcar_du_vsp.c. In order to make it reusable to implement
writeback support, move it to the rcar_du_format_info structure.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 25 +++
drivers/gpu/drm/rcar-du/rcar_du_kms.h | 1 +
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 44 ---
3 files changed, 32 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 3b7d50a8fb9b..3a5e719a6b66 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -34,60 +34,70 @@
static const struct rcar_du_format_info rcar_du_format_infos[] = {
{
.fourcc = DRM_FORMAT_RGB565,
+ .v4l2 = V4L2_PIX_FMT_RGB565,
.bpp = 16,
.planes = 1,
.pnmr = PnMR_SPIM_TP | PnMR_DDDF_16BPP,
.edf = PnDDCR4_EDF_NONE,
}, {
.fourcc = DRM_FORMAT_ARGB1555,
+ .v4l2 = V4L2_PIX_FMT_ARGB555,
.bpp = 16,
.planes = 1,
.pnmr = PnMR_SPIM_ALP | PnMR_DDDF_ARGB,
.edf = PnDDCR4_EDF_NONE,
}, {
.fourcc = DRM_FORMAT_XRGB1555,
+ .v4l2 = V4L2_PIX_FMT_XRGB555,
.bpp = 16,
.planes = 1,
.pnmr = PnMR_SPIM_ALP | PnMR_DDDF_ARGB,
.edf = PnDDCR4_EDF_NONE,
}, {
.fourcc = DRM_FORMAT_XRGB,
+ .v4l2 = V4L2_PIX_FMT_XBGR32,
.bpp = 32,
.planes = 1,
.pnmr = PnMR_SPIM_TP | PnMR_DDDF_16BPP,
.edf = PnDDCR4_EDF_RGB888,
}, {
.fourcc = DRM_FORMAT_ARGB,
+ .v4l2 = V4L2_PIX_FMT_ABGR32,
.bpp = 32,
.planes = 1,
.pnmr = PnMR_SPIM_ALP | PnMR_DDDF_16BPP,
.edf = PnDDCR4_EDF_ARGB,
}, {
.fourcc = DRM_FORMAT_UYVY,
+ .v4l2 = V4L2_PIX_FMT_UYVY,
.bpp = 16,
.planes = 1,
.pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
.edf = PnDDCR4_EDF_NONE,
}, {
.fourcc = DRM_FORMAT_YUYV,
+ .v4l2 = V4L2_PIX_FMT_YUYV,
.bpp = 16,
.planes = 1,
.pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
.edf = PnDDCR4_EDF_NONE,
}, {
.fourcc = DRM_FORMAT_NV12,
+ .v4l2 = V4L2_PIX_FMT_NV12M,
.bpp = 12,
.planes = 2,
.pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
.edf = PnDDCR4_EDF_NONE,
}, {
.fourcc = DRM_FORMAT_NV21,
+ .v4l2 = V4L2_PIX_FMT_NV21M,
.bpp = 12,
.planes = 2,
.pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
.edf = PnDDCR4_EDF_NONE,
}, {
.fourcc = DRM_FORMAT_NV16,
+ .v4l2 = V4L2_PIX_FMT_NV16M,
.bpp = 16,
.planes = 2,
.pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
@@ -99,62 +109,77 @@ static const struct rcar_du_format_info
rcar_du_format_infos[] = {
*/
{
.fourcc = DRM_FORMAT_RGB332,
+ .v4l2 = V4L2_PIX_FMT_RGB332,
.bpp = 8,
.planes = 1,
}, {
.fourcc = DRM_FORMAT_ARGB,
+ .v4l2 = V4L2_PIX_FMT_ARGB444,
.bpp = 16,
.planes = 1,
}, {
.fourcc = DRM_FORMAT_XRGB,
+ .v4l2 = V4L2_PIX_FMT_XRGB444,
.bpp = 16,
.planes = 1,
}, {
.fourcc = DRM_FORMAT_BGR888,
+ .v4l2 = V4L2_PIX_FMT_RGB24,
.bpp = 24,
.planes = 1,
}, {
.fourcc = DRM_FORMAT_RGB888,
+ .v4l2 = V4L2_PIX_FMT_BGR24,
.bpp = 24,
.planes = 1,
}, {
.fourcc = DRM_FORMAT_BGRA,
+ .v4l2 = V4L2_PIX_FMT_ARGB32,
.bpp = 32,
.planes = 1,
}, {
.fourcc = DRM_FORMAT_BGRX,
+ .v4l2 = V4L2_PIX_FMT_XRGB32,
.bpp = 32,
.planes = 1,
}, {
.fourcc = DRM_FORMAT_YVYU,
+ .v4l2 = V4L2_PIX_FMT_YVYU,
.bpp = 16,
.planes = 1,
}, {
.fourcc = DRM_FORMAT_NV61,
+ .v4l2 = V4L2_PIX_FMT_NV61M,
.bpp = 16,
.planes = 2,
}, {
.fourcc = DRM_FORMAT_YUV420,
+ .v4l2 = V4L2_PIX_FMT_YUV420M,
.bpp = 12,
[PATCH v7 12/18] drm: writeback: Cleanup job ownership handling when queuing job
The drm_writeback_queue_job() function takes ownership of the passed job
and requires the caller to manually set the connector state
writeback_job pointer to NULL. To simplify drivers and avoid errors
(such as the missing NULL set in the vc4 driver), pass the connector
state pointer to the function instead of the job pointer, and set the
writeback_job pointer to NULL internally.
Signed-off-by: Laurent Pinchart
Reviewed-by: Brian Starkey
Acked-by: Eric Anholt
Acked-by: Liviu Dudau
Reviewed-by: Kieran Bingham
---
drivers/gpu/drm/arm/malidp_mw.c | 3 +--
drivers/gpu/drm/drm_writeback.c | 15 ++-
drivers/gpu/drm/vc4/vc4_txp.c | 2 +-
include/drm/drm_writeback.h | 2 +-
4 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
index 041a64dc7167..87627219ce3b 100644
--- a/drivers/gpu/drm/arm/malidp_mw.c
+++ b/drivers/gpu/drm/arm/malidp_mw.c
@@ -252,8 +252,7 @@ void malidp_mw_atomic_commit(struct drm_device *drm,
_state->addrs[0],
mw_state->format);
- drm_writeback_queue_job(mw_conn, conn_state->writeback_job);
- conn_state->writeback_job = NULL;
+ drm_writeback_queue_job(mw_conn, conn_state);
hwdev->hw->enable_memwrite(hwdev, mw_state->addrs,
mw_state->pitches,
mw_state->n_planes,
fb->width, fb->height,
mw_state->format,
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index c20e6fe00cb3..338b993d7c9f 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -242,11 +242,12 @@ EXPORT_SYMBOL(drm_writeback_connector_init);
/**
* drm_writeback_queue_job - Queue a writeback job for later signalling
* @wb_connector: The writeback connector to queue a job on
- * @job: The job to queue
+ * @conn_state: The connector state containing the job to queue
*
- * This function adds a job to the job_queue for a writeback connector. It
- * should be considered to take ownership of the writeback job, and so any
other
- * references to the job must be cleared after calling this function.
+ * This function adds the job contained in @conn_state to the job_queue for a
+ * writeback connector. It takes ownership of the writeback job and sets the
+ * @conn_state->writeback_job to NULL, and so no access to the job may be
+ * performed by the caller after this function returns.
*
* Drivers must ensure that for a given writeback connector, jobs are queued in
* exactly the same order as they will be completed by the hardware (and
@@ -258,10 +259,14 @@ EXPORT_SYMBOL(drm_writeback_connector_init);
* See also: drm_writeback_signal_completion()
*/
void drm_writeback_queue_job(struct drm_writeback_connector *wb_connector,
-struct drm_writeback_job *job)
+struct drm_connector_state *conn_state)
{
+ struct drm_writeback_job *job;
unsigned long flags;
+ job = conn_state->writeback_job;
+ conn_state->writeback_job = NULL;
+
spin_lock_irqsave(_connector->job_lock, flags);
list_add_tail(>list_entry, _connector->job_queue);
spin_unlock_irqrestore(_connector->job_lock, flags);
diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
index aa279b5b0de7..5dabd91f2d7e 100644
--- a/drivers/gpu/drm/vc4/vc4_txp.c
+++ b/drivers/gpu/drm/vc4/vc4_txp.c
@@ -327,7 +327,7 @@ static void vc4_txp_connector_atomic_commit(struct
drm_connector *conn,
TXP_WRITE(TXP_DST_CTRL, ctrl);
- drm_writeback_queue_job(>connector, conn_state->writeback_job);
+ drm_writeback_queue_job(>connector, conn_state);
}
static const struct drm_connector_helper_funcs vc4_txp_connector_helper_funcs
= {
diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
index 23df9d463003..47662c362743 100644
--- a/include/drm/drm_writeback.h
+++ b/include/drm/drm_writeback.h
@@ -123,7 +123,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
const u32 *formats, int n_formats);
void drm_writeback_queue_job(struct drm_writeback_connector *wb_connector,
-struct drm_writeback_job *job);
+struct drm_connector_state *conn_state);
void drm_writeback_cleanup_job(struct drm_writeback_job *job);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 09/18] media: vsp1: drm: Split RPF format setting to separate function
The code that initializes the RPF format-related fields for display
pipelines will also be useful for the WPF to implement writeback
support. Split it from vsp1_du_atomic_update() to a new
vsp1_du_pipeline_set_rwpf_format() function.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_drm.c | 55 --
1 file changed, 35 insertions(+), 20 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
b/drivers/media/platform/vsp1/vsp1_drm.c
index e28a742a7575..d1c88e8aee52 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -566,6 +566,36 @@ static void vsp1_du_pipeline_configure(struct
vsp1_pipeline *pipe)
vsp1_dl_list_commit(dl, dl_flags);
}
+static int vsp1_du_pipeline_set_rwpf_format(struct vsp1_device *vsp1,
+ struct vsp1_rwpf *rwpf,
+ u32 pixelformat, unsigned int pitch)
+{
+ const struct vsp1_format_info *fmtinfo;
+ unsigned int chroma_hsub;
+
+ fmtinfo = vsp1_get_format_info(vsp1, pixelformat);
+ if (!fmtinfo) {
+ dev_dbg(vsp1->dev, "Unsupported pixel format %08x\n",
+ pixelformat);
+ return -EINVAL;
+ }
+
+ /*
+* Only formats with three planes can affect the chroma planes pitch.
+* All formats with two planes have a horizontal subsampling value of 2,
+* but combine U and V in a single chroma plane, which thus results in
+* the luma plane and chroma plane having the same pitch.
+*/
+ chroma_hsub = (fmtinfo->planes == 3) ? fmtinfo->hsub : 1;
+
+ rwpf->fmtinfo = fmtinfo;
+ rwpf->format.num_planes = fmtinfo->planes;
+ rwpf->format.plane_fmt[0].bytesperline = pitch;
+ rwpf->format.plane_fmt[1].bytesperline = pitch / chroma_hsub;
+
+ return 0;
+}
+
/*
-
* DU Driver API
*/
@@ -773,9 +803,8 @@ int vsp1_du_atomic_update(struct device *dev, unsigned int
pipe_index,
{
struct vsp1_device *vsp1 = dev_get_drvdata(dev);
struct vsp1_drm_pipeline *drm_pipe = >drm->pipe[pipe_index];
- const struct vsp1_format_info *fmtinfo;
- unsigned int chroma_hsub;
struct vsp1_rwpf *rpf;
+ int ret;
if (rpf_index >= vsp1->info->rpf_count)
return -EINVAL;
@@ -808,25 +837,11 @@ int vsp1_du_atomic_update(struct device *dev, unsigned
int pipe_index,
* Store the format, stride, memory buffer address, crop and compose
* rectangles and Z-order position and for the input.
*/
- fmtinfo = vsp1_get_format_info(vsp1, cfg->pixelformat);
- if (!fmtinfo) {
- dev_dbg(vsp1->dev, "Unsupported pixel format %08x for RPF\n",
- cfg->pixelformat);
- return -EINVAL;
- }
+ ret = vsp1_du_pipeline_set_rwpf_format(vsp1, rpf, cfg->pixelformat,
+ cfg->pitch);
+ if (ret < 0)
+ return ret;
- /*
-* Only formats with three planes can affect the chroma planes pitch.
-* All formats with two planes have a horizontal subsampling value of 2,
-* but combine U and V in a single chroma plane, which thus results in
-* the luma plane and chroma plane having the same pitch.
-*/
- chroma_hsub = (fmtinfo->planes == 3) ? fmtinfo->hsub : 1;
-
- rpf->fmtinfo = fmtinfo;
- rpf->format.num_planes = fmtinfo->planes;
- rpf->format.plane_fmt[0].bytesperline = cfg->pitch;
- rpf->format.plane_fmt[1].bytesperline = cfg->pitch / chroma_hsub;
rpf->alpha = cfg->alpha;
rpf->mem.addr[0] = cfg->mem[0];
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 14/18] drm: writeback: Add job prepare and cleanup operations
As writeback jobs contain a framebuffer, drivers may need to prepare and
cleanup them the same way they can prepare and cleanup framebuffers for
planes. Add two new optional connector helper operations,
.prepare_writeback_job() and .cleanup_writeback_job() to support this.
The job prepare operation is called from
drm_atomic_helper_prepare_planes() to avoid a new atomic commit helper
that would need to be called by all drivers not using
drm_atomic_helper_commit(). The job cleanup operation is called from the
existing drm_writeback_cleanup_job() function, invoked both when
destroying the job as part of a aborted commit, or when the job
completes.
The drm_writeback_job structure is extended with a priv field to let
drivers store per-job data, such as mappings related to the writeback
framebuffer.
For internal plumbing reasons the drm_writeback_job structure needs to
store a back-pointer to the drm_writeback_connector. To avoid pushing
too much writeback-specific knowledge to drm_atomic_uapi.c, create a
drm_writeback_set_fb() function, move the writeback job setup code
there, and set the connector backpointer. The prepare_signaling()
function doesn't need to allocate writeback jobs and can ignore
connectors without a job, as it is called after the writeback jobs are
allocated to store framebuffers, and a writeback fence with a
framebuffer is an invalid configuration that gets rejected by the commit
check.
Signed-off-by: Laurent Pinchart
Reviewed-by: Liviu Dudau
---
Changes since v5:
- Export drm_writeback_prepare_job()
- Check for .prepare_writeback_job() in drm_writeback_prepare_job()
---
drivers/gpu/drm/drm_atomic_helper.c | 11 ++
drivers/gpu/drm/drm_atomic_uapi.c| 31 +
drivers/gpu/drm/drm_writeback.c | 44
include/drm/drm_modeset_helper_vtables.h | 7
include/drm/drm_writeback.h | 28 ++-
5 files changed, 97 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 40ac19848034..f89641216a44 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2261,10 +2261,21 @@ EXPORT_SYMBOL(drm_atomic_helper_commit_cleanup_done);
int drm_atomic_helper_prepare_planes(struct drm_device *dev,
struct drm_atomic_state *state)
{
+ struct drm_connector *connector;
+ struct drm_connector_state *new_conn_state;
struct drm_plane *plane;
struct drm_plane_state *new_plane_state;
int ret, i, j;
+ for_each_new_connector_in_state(state, connector, new_conn_state, i) {
+ if (!new_conn_state->writeback_job)
+ continue;
+
+ ret = drm_writeback_prepare_job(new_conn_state->writeback_job);
+ if (ret < 0)
+ return ret;
+ }
+
for_each_new_plane_in_state(state, plane, new_plane_state, i) {
const struct drm_plane_helper_funcs *funcs;
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 0aabd401d3ca..8fa77def577f 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -647,28 +647,15 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
return 0;
}
-static struct drm_writeback_job *
-drm_atomic_get_writeback_job(struct drm_connector_state *conn_state)
-{
- WARN_ON(conn_state->connector->connector_type !=
DRM_MODE_CONNECTOR_WRITEBACK);
-
- if (!conn_state->writeback_job)
- conn_state->writeback_job =
- kzalloc(sizeof(*conn_state->writeback_job), GFP_KERNEL);
-
- return conn_state->writeback_job;
-}
-
static int drm_atomic_set_writeback_fb_for_connector(
struct drm_connector_state *conn_state,
struct drm_framebuffer *fb)
{
- struct drm_writeback_job *job =
- drm_atomic_get_writeback_job(conn_state);
- if (!job)
- return -ENOMEM;
+ int ret;
- drm_framebuffer_assign(>fb, fb);
+ ret = drm_writeback_set_fb(conn_state, fb);
+ if (ret < 0)
+ return ret;
if (fb)
DRM_DEBUG_ATOMIC("Set [FB:%d] for connector state %p\n",
@@ -1158,19 +1145,17 @@ static int prepare_signaling(struct drm_device *dev,
for_each_new_connector_in_state(state, conn, conn_state, i) {
struct drm_writeback_connector *wb_conn;
- struct drm_writeback_job *job;
struct drm_out_fence_state *f;
struct dma_fence *fence;
s32 __user *fence_ptr;
+ if (!conn_state->writeback_job)
+ continue;
+
fence_ptr = get_out_fence_for_connector(state, conn);
if (!fence_ptr)
continue;
- job =
[PATCH v7 15/18] drm: rcar-du: Fix rcar_du_crtc structure documentation
The rcar_du_crtc structure index field contains the CRTC hardware index,
not the hardware and software index. Update the documentation
accordingly.
Fixes: 5361cc7f8e91 ("drm: rcar-du: Split CRTC handling to support hardware
indexing")
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index 11814eafef77..af9527c1d238 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -28,7 +28,7 @@ struct rcar_du_vsp;
* @clock: the CRTC functional clock
* @extclock: external pixel dot clock (optional)
* @mmio_offset: offset of the CRTC registers in the DU MMIO block
- * @index: CRTC software and hardware index
+ * @index: CRTC hardware index
* @initialized: whether the CRTC has been initialized and clocks enabled
* @dsysr: cached value of the DSYSR register
* @vblank_enable: whether vblank events are enabled on this CRTC
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 03/18] media: vsp1: Replace leftover occurrence of fragment with body
Display list fragments have been renamed to bodies. Replace one last occurrence of the word fragment in the documentation. Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham --- drivers/media/platform/vsp1/vsp1_dl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/vsp1/vsp1_dl.c b/drivers/media/platform/vsp1/vsp1_dl.c index 26289adaf658..64af449791b0 100644 --- a/drivers/media/platform/vsp1/vsp1_dl.c +++ b/drivers/media/platform/vsp1/vsp1_dl.c @@ -699,8 +699,8 @@ struct vsp1_dl_body *vsp1_dl_list_get_body0(struct vsp1_dl_list *dl) * which bodies are added. * * Adding a body to a display list passes ownership of the body to the list. The - * caller retains its reference to the fragment when adding it to the display - * list, but is not allowed to add new entries to the body. + * caller retains its reference to the body when adding it to the display list, + * but is not allowed to add new entries to the body. * * The reference must be explicitly released by a call to vsp1_dl_body_put() * when the body isn't needed anymore. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 10/18] media: vsp1: drm: Extend frame completion API to the DU driver
The VSP1 driver will need to pass extra flags to the DU through the
frame completion API. Replace the completed bool flag by a bitmask to
support this.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
Changes since v6:
- Add a comment to keep VSP1_DU_STATUS_* and VSP1_DL_FRAME_END_* in sync
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 4 ++--
drivers/media/platform/vsp1/vsp1_dl.h | 1 +
drivers/media/platform/vsp1/vsp1_drm.c | 4 ++--
drivers/media/platform/vsp1/vsp1_drm.h | 2 +-
include/media/vsp1.h | 4 +++-
5 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index f6deea90dcce..520929389666 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -27,14 +27,14 @@
#include "rcar_du_kms.h"
#include "rcar_du_vsp.h"
-static void rcar_du_vsp_complete(void *private, bool completed, u32 crc)
+static void rcar_du_vsp_complete(void *private, unsigned int status, u32 crc)
{
struct rcar_du_crtc *crtc = private;
if (crtc->vblank_enable)
drm_crtc_handle_vblank(>crtc);
- if (completed)
+ if (status & VSP1_DU_STATUS_COMPLETE)
rcar_du_crtc_finish_page_flip(crtc);
drm_crtc_add_crc_entry(>crtc, false, 0, );
diff --git a/drivers/media/platform/vsp1/vsp1_dl.h
b/drivers/media/platform/vsp1/vsp1_dl.h
index e0fdb145e6ed..079ba5af0315 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.h
+++ b/drivers/media/platform/vsp1/vsp1_dl.h
@@ -17,6 +17,7 @@ struct vsp1_dl_body_pool;
struct vsp1_dl_list;
struct vsp1_dl_manager;
+/* Keep these flags in sync with VSP1_DU_STATUS_* in include/media/vsp1.h. */
#define VSP1_DL_FRAME_END_COMPLETEDBIT(0)
#define VSP1_DL_FRAME_END_INTERNAL BIT(1)
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
b/drivers/media/platform/vsp1/vsp1_drm.c
index d1c88e8aee52..bd95683c1cd9 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -34,14 +34,14 @@ static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline
*pipe,
unsigned int completion)
{
struct vsp1_drm_pipeline *drm_pipe = to_vsp1_drm_pipeline(pipe);
- bool complete = completion & VSP1_DL_FRAME_END_COMPLETED;
if (drm_pipe->du_complete) {
struct vsp1_entity *uif = drm_pipe->uif;
+ unsigned int status = completion & VSP1_DU_STATUS_COMPLETE;
u32 crc;
crc = uif ? vsp1_uif_get_crc(to_uif(>subdev)) : 0;
- drm_pipe->du_complete(drm_pipe->du_private, complete, crc);
+ drm_pipe->du_complete(drm_pipe->du_private, status, crc);
}
if (completion & VSP1_DL_FRAME_END_INTERNAL) {
diff --git a/drivers/media/platform/vsp1/vsp1_drm.h
b/drivers/media/platform/vsp1/vsp1_drm.h
index 8dfd274a59e2..e85ad4366fbb 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.h
+++ b/drivers/media/platform/vsp1/vsp1_drm.h
@@ -42,7 +42,7 @@ struct vsp1_drm_pipeline {
struct vsp1_du_crc_config crc;
/* Frame synchronisation */
- void (*du_complete)(void *data, bool completed, u32 crc);
+ void (*du_complete)(void *data, unsigned int status, u32 crc);
void *du_private;
};
diff --git a/include/media/vsp1.h b/include/media/vsp1.h
index 1cf868360701..877496936487 100644
--- a/include/media/vsp1.h
+++ b/include/media/vsp1.h
@@ -17,6 +17,8 @@ struct device;
int vsp1_du_init(struct device *dev);
+#define VSP1_DU_STATUS_COMPLETEBIT(0)
+
/**
* struct vsp1_du_lif_config - VSP LIF configuration
* @width: output frame width
@@ -32,7 +34,7 @@ struct vsp1_du_lif_config {
unsigned int height;
bool interlaced;
- void (*callback)(void *data, bool completed, u32 crc);
+ void (*callback)(void *data, unsigned int status, u32 crc);
void *callback_data;
};
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 17/18] drm: rcar-du: vsp: Extract framebuffer (un)mapping to separate functions
The rcar_du_vsp_plane_prepare_fb() and rcar_du_vsp_plane_cleanup_fb()
functions implement the DRM plane .prepare_fb() and .cleanup_fb()
operations. They map and unmap the framebuffer to/from the VSP
internally, which will be useful to implement writeback support. Split
the mapping and unmapping out to separate functions.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 69 ---
drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 17 +++
2 files changed, 59 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index ddfe4de64915..7e25e9bc7829 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -174,26 +175,16 @@ static void rcar_du_vsp_plane_setup(struct
rcar_du_vsp_plane *plane)
plane->index, );
}
-static int rcar_du_vsp_plane_prepare_fb(struct drm_plane *plane,
- struct drm_plane_state *state)
+int rcar_du_vsp_map_fb(struct rcar_du_vsp *vsp, struct drm_framebuffer *fb,
+ struct sg_table sg_tables[3])
{
- struct rcar_du_vsp_plane_state *rstate = to_rcar_vsp_plane_state(state);
- struct rcar_du_vsp *vsp = to_rcar_vsp_plane(plane)->vsp;
struct rcar_du_device *rcdu = vsp->dev;
unsigned int i;
int ret;
- /*
-* There's no need to prepare (and unprepare) the framebuffer when the
-* plane is not visible, as it will not be displayed.
-*/
- if (!state->visible)
- return 0;
-
- for (i = 0; i < rstate->format->planes; ++i) {
- struct drm_gem_cma_object *gem =
- drm_fb_cma_get_gem_obj(state->fb, i);
- struct sg_table *sgt = >sg_tables[i];
+ for (i = 0; i < fb->format->num_planes; ++i) {
+ struct drm_gem_cma_object *gem = drm_fb_cma_get_gem_obj(fb, i);
+ struct sg_table *sgt = _tables[i];
ret = dma_get_sgtable(rcdu->dev, sgt, gem->vaddr, gem->paddr,
gem->base.size);
@@ -208,15 +199,11 @@ static int rcar_du_vsp_plane_prepare_fb(struct drm_plane
*plane,
}
}
- ret = drm_gem_fb_prepare_fb(plane, state);
- if (ret)
- goto fail;
-
return 0;
fail:
while (i--) {
- struct sg_table *sgt = >sg_tables[i];
+ struct sg_table *sgt = _tables[i];
vsp1_du_unmap_sg(vsp->vsp, sgt);
sg_free_table(sgt);
@@ -225,22 +212,50 @@ static int rcar_du_vsp_plane_prepare_fb(struct drm_plane
*plane,
return ret;
}
+static int rcar_du_vsp_plane_prepare_fb(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ struct rcar_du_vsp_plane_state *rstate = to_rcar_vsp_plane_state(state);
+ struct rcar_du_vsp *vsp = to_rcar_vsp_plane(plane)->vsp;
+ int ret;
+
+ /*
+* There's no need to prepare (and unprepare) the framebuffer when the
+* plane is not visible, as it will not be displayed.
+*/
+ if (!state->visible)
+ return 0;
+
+ ret = rcar_du_vsp_map_fb(vsp, state->fb, rstate->sg_tables);
+ if (ret < 0)
+ return ret;
+
+ return drm_gem_fb_prepare_fb(plane, state);
+}
+
+void rcar_du_vsp_unmap_fb(struct rcar_du_vsp *vsp, struct drm_framebuffer *fb,
+ struct sg_table sg_tables[3])
+{
+ unsigned int i;
+
+ for (i = 0; i < fb->format->num_planes; ++i) {
+ struct sg_table *sgt = _tables[i];
+
+ vsp1_du_unmap_sg(vsp->vsp, sgt);
+ sg_free_table(sgt);
+ }
+}
+
static void rcar_du_vsp_plane_cleanup_fb(struct drm_plane *plane,
struct drm_plane_state *state)
{
struct rcar_du_vsp_plane_state *rstate = to_rcar_vsp_plane_state(state);
struct rcar_du_vsp *vsp = to_rcar_vsp_plane(plane)->vsp;
- unsigned int i;
if (!state->visible)
return;
- for (i = 0; i < rstate->format->planes; ++i) {
- struct sg_table *sgt = >sg_tables[i];
-
- vsp1_du_unmap_sg(vsp->vsp, sgt);
- sg_free_table(sgt);
- }
+ rcar_du_vsp_unmap_fb(vsp, state->fb, rstate->sg_tables);
}
static int rcar_du_vsp_plane_atomic_check(struct drm_plane *plane,
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
index db232037f24a..9b4724159378 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
@@ -12,8 +12,10 @@
#include
+struct drm_framebuffer;
struct rcar_du_format_info;
struct rcar_du_vsp;
+struct
[PATCH v7 06/18] media: vsp1: Add vsp1_dl_list argument to .configure_stream() operation
The WPF needs access to the current display list to configure writeback.
Add a display list pointer to the VSP1 entity .configure_stream()
operation.
Only display pipelines can make use of the display list there as
mem-to-mem pipelines don't have access to a display list at stream
configuration time. This is not an issue as writeback is only used for
display pipelines.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_brx.c| 1 +
drivers/media/platform/vsp1/vsp1_clu.c| 1 +
drivers/media/platform/vsp1/vsp1_drm.c| 2 +-
drivers/media/platform/vsp1/vsp1_entity.c | 3 ++-
drivers/media/platform/vsp1/vsp1_entity.h | 7 +--
drivers/media/platform/vsp1/vsp1_hgo.c| 1 +
drivers/media/platform/vsp1/vsp1_hgt.c| 1 +
drivers/media/platform/vsp1/vsp1_hsit.c | 1 +
drivers/media/platform/vsp1/vsp1_lif.c| 1 +
drivers/media/platform/vsp1/vsp1_lut.c| 1 +
drivers/media/platform/vsp1/vsp1_rpf.c| 1 +
drivers/media/platform/vsp1/vsp1_sru.c| 1 +
drivers/media/platform/vsp1/vsp1_uds.c| 1 +
drivers/media/platform/vsp1/vsp1_uif.c| 1 +
drivers/media/platform/vsp1/vsp1_video.c | 3 ++-
drivers/media/platform/vsp1/vsp1_wpf.c| 1 +
16 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_brx.c
b/drivers/media/platform/vsp1/vsp1_brx.c
index 58ad248cd7f7..2d86c718a5cf 100644
--- a/drivers/media/platform/vsp1/vsp1_brx.c
+++ b/drivers/media/platform/vsp1/vsp1_brx.c
@@ -283,6 +283,7 @@ static const struct v4l2_subdev_ops brx_ops = {
static void brx_configure_stream(struct vsp1_entity *entity,
struct vsp1_pipeline *pipe,
+struct vsp1_dl_list *dl,
struct vsp1_dl_body *dlb)
{
struct vsp1_brx *brx = to_brx(>subdev);
diff --git a/drivers/media/platform/vsp1/vsp1_clu.c
b/drivers/media/platform/vsp1/vsp1_clu.c
index 942fc14c19d1..a47b23bf5abf 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -171,6 +171,7 @@ static const struct v4l2_subdev_ops clu_ops = {
static void clu_configure_stream(struct vsp1_entity *entity,
struct vsp1_pipeline *pipe,
+struct vsp1_dl_list *dl,
struct vsp1_dl_body *dlb)
{
struct vsp1_clu *clu = to_clu(>subdev);
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
b/drivers/media/platform/vsp1/vsp1_drm.c
index e8f83d4b7a39..e28a742a7575 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -558,7 +558,7 @@ static void vsp1_du_pipeline_configure(struct vsp1_pipeline
*pipe)
}
vsp1_entity_route_setup(entity, pipe, dlb);
- vsp1_entity_configure_stream(entity, pipe, dlb);
+ vsp1_entity_configure_stream(entity, pipe, dl, dlb);
vsp1_entity_configure_frame(entity, pipe, dl, dlb);
vsp1_entity_configure_partition(entity, pipe, dl, dlb);
}
diff --git a/drivers/media/platform/vsp1/vsp1_entity.c
b/drivers/media/platform/vsp1/vsp1_entity.c
index a54ab528b060..aa9d2286056e 100644
--- a/drivers/media/platform/vsp1/vsp1_entity.c
+++ b/drivers/media/platform/vsp1/vsp1_entity.c
@@ -71,10 +71,11 @@ void vsp1_entity_route_setup(struct vsp1_entity *entity,
void vsp1_entity_configure_stream(struct vsp1_entity *entity,
struct vsp1_pipeline *pipe,
+ struct vsp1_dl_list *dl,
struct vsp1_dl_body *dlb)
{
if (entity->ops->configure_stream)
- entity->ops->configure_stream(entity, pipe, dlb);
+ entity->ops->configure_stream(entity, pipe, dl, dlb);
}
void vsp1_entity_configure_frame(struct vsp1_entity *entity,
diff --git a/drivers/media/platform/vsp1/vsp1_entity.h
b/drivers/media/platform/vsp1/vsp1_entity.h
index 97acb7795cf1..a1ceb37bb837 100644
--- a/drivers/media/platform/vsp1/vsp1_entity.h
+++ b/drivers/media/platform/vsp1/vsp1_entity.h
@@ -67,7 +67,9 @@ struct vsp1_route {
* struct vsp1_entity_operations - Entity operations
* @destroy: Destroy the entity.
* @configure_stream: Setup the hardware parameters for the stream which do
- * not vary between frames (pipeline, formats).
+ * not vary between frames (pipeline, formats). Note that
+ * the vsp1_dl_list argument is only valid for display
+ * pipeline and will be NULL for mem-to-mem pipelines.
* @configure_frame: Configure the runtime parameters for each frame.
* @configure_partition: Configure partition specific parameters.
* @max_width: Return the max supported width of data that the entity can
@@ -78,7 +80,7 @@ struct vsp1_route {
struct vsp1_entity_operations {
void
[PATCH v7 13/18] drm: writeback: Fix leak of writeback job
Writeback jobs are allocated when the WRITEBACK_FB_ID is set, and
deleted when the jobs complete. This results in both a memory leak of
the job and a leak of the framebuffer if the atomic commit returns
before the job is queued for processing, for instance if the atomic
check fails or if the commit runs in test-only mode.
Fix this by implementing the drm_writeback_cleanup_job() function and
calling it from __drm_atomic_helper_connector_destroy_state(). As
writeback jobs are removed from the state when they're queued for
processing, any job left in the state when the state gets destroyed
needs to be cleaned up.
The existing declaration of the drm_writeback_cleanup_job() function
without an implementation hints that this problem was considered, but
never addressed.
Signed-off-by: Laurent Pinchart
Reviewed-by: Brian Starkey
Acked-by: Liviu Dudau
---
Changes since v5:
- Export drm_writeback_cleanup_job()
---
drivers/gpu/drm/drm_atomic_state_helper.c | 4
drivers/gpu/drm/drm_writeback.c | 14 +++---
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
b/drivers/gpu/drm/drm_atomic_state_helper.c
index 4985384e51f6..59ffb6b9c745 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
@@ -412,6 +413,9 @@ __drm_atomic_helper_connector_destroy_state(struct
drm_connector_state *state)
if (state->commit)
drm_crtc_commit_put(state->commit);
+
+ if (state->writeback_job)
+ drm_writeback_cleanup_job(state->writeback_job);
}
EXPORT_SYMBOL(__drm_atomic_helper_connector_destroy_state);
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index 338b993d7c9f..1b497d3530b5 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -273,6 +273,15 @@ void drm_writeback_queue_job(struct
drm_writeback_connector *wb_connector,
}
EXPORT_SYMBOL(drm_writeback_queue_job);
+void drm_writeback_cleanup_job(struct drm_writeback_job *job)
+{
+ if (job->fb)
+ drm_framebuffer_put(job->fb);
+
+ kfree(job);
+}
+EXPORT_SYMBOL(drm_writeback_cleanup_job);
+
/*
* @cleanup_work: deferred cleanup of a writeback job
*
@@ -285,10 +294,9 @@ static void cleanup_work(struct work_struct *work)
struct drm_writeback_job *job = container_of(work,
struct drm_writeback_job,
cleanup_work);
- drm_framebuffer_put(job->fb);
- kfree(job);
-}
+ drm_writeback_cleanup_job(job);
+}
/**
* drm_writeback_signal_completion - Signal the completion of a writeback job
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 18/18] drm: rcar-du: Add writeback support for R-Car Gen3
Implement writeback support for R-Car Gen3 by exposing writeback
connectors. Behind the scene the calls are forwarded to the VSP
backend.
Using writeback connectors will allow implemented writeback support for
R-Car Gen2 with a consistent API if desired.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
Changes since v6:
- Rename rcar_du_writeback_atomic_flush() to rcar_du_writeback_setup()
Changes since v5:
- Skip writeback connector when configuring output routing
- Implement writeback connector atomic state operations
---
drivers/gpu/drm/rcar-du/Kconfig | 4 +
drivers/gpu/drm/rcar-du/Makefile| 3 +-
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 7 +-
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 7 +-
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 12 +
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 5 +
drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 243
drivers/gpu/drm/rcar-du/rcar_du_writeback.h | 39
8 files changed, 317 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_writeback.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_writeback.h
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 7c36e2777a15..1529849e217e 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -36,3 +36,7 @@ config DRM_RCAR_VSP
depends on VIDEO_RENESAS_VSP1=y || (VIDEO_RENESAS_VSP1 && DRM_RCAR_DU=m)
help
Enable support to expose the R-Car VSP Compositor as KMS planes.
+
+config DRM_RCAR_WRITEBACK
+ bool
+ default y if ARM64
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 2a3b8d7972b5..6c2ed9c46467 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -4,7 +4,7 @@ rcar-du-drm-y := rcar_du_crtc.o \
rcar_du_encoder.o \
rcar_du_group.o \
rcar_du_kms.o \
-rcar_du_plane.o
+rcar_du_plane.o \
rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_of.o \
rcar_du_of_lvds_r8a7790.dtb.o \
@@ -13,6 +13,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_of.o \
rcar_du_of_lvds_r8a7795.dtb.o \
rcar_du_of_lvds_r8a7796.dtb.o
rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
+rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o
obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 471ce464654a..2da46e3dc4ae 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -647,8 +647,13 @@ static int rcar_du_crtc_atomic_check(struct drm_crtc *crtc,
rstate->outputs = 0;
drm_for_each_encoder_mask(encoder, crtc->dev, state->encoder_mask) {
- struct rcar_du_encoder *renc = to_rcar_encoder(encoder);
+ struct rcar_du_encoder *renc;
+ /* Skip the writeback encoder. */
+ if (encoder->encoder_type == DRM_MODE_ENCODER_VIRTUAL)
+ continue;
+
+ renc = to_rcar_encoder(encoder);
rstate->outputs |= BIT(renc->output);
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index af9527c1d238..3b7fc668996f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -15,6 +15,7 @@
#include
#include
+#include
#include
@@ -40,6 +41,7 @@ struct rcar_du_vsp;
* @group: CRTC group this CRTC belongs to
* @vsp: VSP feeding video to this CRTC
* @vsp_pipe: index of the VSP pipeline feeding video to this CRTC
+ * @writeback: the writeback connector
*/
struct rcar_du_crtc {
struct drm_crtc crtc;
@@ -67,9 +69,12 @@ struct rcar_du_crtc {
const char *const *sources;
unsigned int sources_count;
+
+ struct drm_writeback_connector writeback;
};
-#define to_rcar_crtc(c)container_of(c, struct rcar_du_crtc, crtc)
+#define to_rcar_crtc(c)container_of(c, struct rcar_du_crtc,
crtc)
+#define wb_to_rcar_crtc(c) container_of(c, struct rcar_du_crtc, writeback)
/**
* struct rcar_du_crtc_state - Driver-specific CRTC state
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 3a5e719a6b66..f8f7fff34dff 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -26,6 +26,7 @@
#include "rcar_du_kms.h"
#include "rcar_du_regs.h"
#include "rcar_du_vsp.h"
+#include "rcar_du_writeback.h"
/*
-
* Format helpers
@@ -664,6
[PATCH v7 11/18] media: vsp1: drm: Implement writeback support
Extend the vsp1_du_atomic_flush() API with writeback support by adding
format, pitch and memory addresses of the writeback framebuffer.
Writeback completion is reported through the existing frame completion
callback with a new VSP1_DU_STATUS_WRITEBACK status flag.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
Changes since v6:
- Remove the has_writeback check
---
drivers/media/platform/vsp1/vsp1_dl.c | 14 ++
drivers/media/platform/vsp1/vsp1_dl.h | 3 ++-
drivers/media/platform/vsp1/vsp1_drm.c | 25 -
include/media/vsp1.h | 15 +++
4 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index ed7cda4130f2..104b6f514536 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -958,6 +958,9 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl, unsigned
int dl_flags)
*
* The VSP1_DL_FRAME_END_INTERNAL flag indicates that the display list that
just
* became active had been queued with the internal notification flag.
+ *
+ * The VSP1_DL_FRAME_END_WRITEBACK flag indicates that the previously active
+ * display list had been queued with the writeback flag.
*/
unsigned int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
{
@@ -995,6 +998,17 @@ unsigned int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager
*dlm)
if (status & VI6_STATUS_FLD_STD(dlm->index))
goto done;
+ /*
+* If the active display list has the writeback flag set, the frame
+* completion marks the end of the writeback capture. Return the
+* VSP1_DL_FRAME_END_WRITEBACK flag and reset the display list's
+* writeback flag.
+*/
+ if (dlm->active && (dlm->active->flags & VSP1_DL_FRAME_END_WRITEBACK)) {
+ flags |= VSP1_DL_FRAME_END_WRITEBACK;
+ dlm->active->flags &= ~VSP1_DL_FRAME_END_WRITEBACK;
+ }
+
/*
* The device starts processing the queued display list right after the
* frame end interrupt. The display list thus becomes active.
diff --git a/drivers/media/platform/vsp1/vsp1_dl.h
b/drivers/media/platform/vsp1/vsp1_dl.h
index 079ba5af0315..bebe16483ca5 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.h
+++ b/drivers/media/platform/vsp1/vsp1_dl.h
@@ -19,7 +19,8 @@ struct vsp1_dl_manager;
/* Keep these flags in sync with VSP1_DU_STATUS_* in include/media/vsp1.h. */
#define VSP1_DL_FRAME_END_COMPLETEDBIT(0)
-#define VSP1_DL_FRAME_END_INTERNAL BIT(1)
+#define VSP1_DL_FRAME_END_WRITEBACKBIT(1)
+#define VSP1_DL_FRAME_END_INTERNAL BIT(2)
/**
* struct vsp1_dl_ext_cmd - Extended Display command
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
b/drivers/media/platform/vsp1/vsp1_drm.c
index bd95683c1cd9..a4a45d68a6ef 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -37,7 +37,9 @@ static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline
*pipe,
if (drm_pipe->du_complete) {
struct vsp1_entity *uif = drm_pipe->uif;
- unsigned int status = completion & VSP1_DU_STATUS_COMPLETE;
+ unsigned int status = completion
+ & (VSP1_DU_STATUS_COMPLETE |
+ VSP1_DU_STATUS_WRITEBACK);
u32 crc;
crc = uif ? vsp1_uif_get_crc(to_uif(>subdev)) : 0;
@@ -541,6 +543,8 @@ static void vsp1_du_pipeline_configure(struct vsp1_pipeline
*pipe)
if (drm_pipe->force_brx_release)
dl_flags |= VSP1_DL_FRAME_END_INTERNAL;
+ if (pipe->output->writeback)
+ dl_flags |= VSP1_DL_FRAME_END_WRITEBACK;
dl = vsp1_dl_list_get(pipe->output->dlm);
dlb = vsp1_dl_list_get_body0(dl);
@@ -870,12 +874,31 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned
int pipe_index,
struct vsp1_device *vsp1 = dev_get_drvdata(dev);
struct vsp1_drm_pipeline *drm_pipe = >drm->pipe[pipe_index];
struct vsp1_pipeline *pipe = _pipe->pipe;
+ int ret;
drm_pipe->crc = cfg->crc;
mutex_lock(>drm->lock);
+
+ if (cfg->writeback.pixelformat) {
+ const struct vsp1_du_writeback_config *wb_cfg = >writeback;
+
+ ret = vsp1_du_pipeline_set_rwpf_format(vsp1, pipe->output,
+ wb_cfg->pixelformat,
+ wb_cfg->pitch);
+ if (WARN_ON(ret < 0))
+ goto done;
+
+ pipe->output->mem.addr[0] = wb_cfg->mem[0];
+ pipe->output->mem.addr[1] = wb_cfg->mem[1];
+ pipe->output->mem.addr[2] = wb_cfg->mem[2];
+ pipe->output->writeback = true;
+ }
+
vsp1_du_pipeline_setup_inputs(vsp1,
[PATCH v7 08/18] media: vsp1: wpf: Add writeback support
Add support for the writeback feature of the WPF, to enable capturing
frames at the WPF output for display pipelines. To enable writeback the
vsp1_rwpf structure mem field must be set to the address of the
writeback buffer and the writeback field set to true before the WPF
.configure_stream() and .configure_partition() are called. The WPF will
enable writeback in the display list for a single frame, and writeback
will then be automatically disabled.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
Changes since v6:
- Remove the vsp1_rwpf has_writeback field
---
drivers/media/platform/vsp1/vsp1_rwpf.h | 1 +
drivers/media/platform/vsp1/vsp1_wpf.c | 66 +
2 files changed, 58 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.h
b/drivers/media/platform/vsp1/vsp1_rwpf.h
index 70742ecf766f..2f3582590618 100644
--- a/drivers/media/platform/vsp1/vsp1_rwpf.h
+++ b/drivers/media/platform/vsp1/vsp1_rwpf.h
@@ -61,6 +61,7 @@ struct vsp1_rwpf {
} flip;
struct vsp1_rwpf_memory mem;
+ bool writeback;
struct vsp1_dl_manager *dlm;
};
diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c
b/drivers/media/platform/vsp1/vsp1_wpf.c
index fc5c1b0f6633..208498fa6ed7 100644
--- a/drivers/media/platform/vsp1/vsp1_wpf.c
+++ b/drivers/media/platform/vsp1/vsp1_wpf.c
@@ -232,6 +232,27 @@ static void vsp1_wpf_destroy(struct vsp1_entity *entity)
vsp1_dlm_destroy(wpf->dlm);
}
+static int wpf_configure_writeback_chain(struct vsp1_rwpf *wpf,
+struct vsp1_dl_list *dl)
+{
+ unsigned int index = wpf->entity.index;
+ struct vsp1_dl_list *dl_next;
+ struct vsp1_dl_body *dlb;
+
+ dl_next = vsp1_dl_list_get(wpf->dlm);
+ if (!dl_next) {
+ dev_err(wpf->entity.vsp1->dev,
+ "Failed to obtain a dl list, disabling writeback\n");
+ return -ENOMEM;
+ }
+
+ dlb = vsp1_dl_list_get_body0(dl_next);
+ vsp1_dl_body_write(dlb, VI6_WPF_WRBCK_CTRL(index), 0);
+ vsp1_dl_list_add_chain(dl, dl_next);
+
+ return 0;
+}
+
static void wpf_configure_stream(struct vsp1_entity *entity,
struct vsp1_pipeline *pipe,
struct vsp1_dl_list *dl,
@@ -241,9 +262,11 @@ static void wpf_configure_stream(struct vsp1_entity
*entity,
struct vsp1_device *vsp1 = wpf->entity.vsp1;
const struct v4l2_mbus_framefmt *source_format;
const struct v4l2_mbus_framefmt *sink_format;
+ unsigned int index = wpf->entity.index;
unsigned int i;
u32 outfmt = 0;
u32 srcrpf = 0;
+ int ret;
sink_format = vsp1_entity_get_pad_format(>entity,
wpf->entity.config,
@@ -251,8 +274,9 @@ static void wpf_configure_stream(struct vsp1_entity *entity,
source_format = vsp1_entity_get_pad_format(>entity,
wpf->entity.config,
RWPF_PAD_SOURCE);
+
/* Format */
- if (!pipe->lif) {
+ if (!pipe->lif || wpf->writeback) {
const struct v4l2_pix_format_mplane *format = >format;
const struct vsp1_format_info *fmtinfo = wpf->fmtinfo;
@@ -277,8 +301,7 @@ static void wpf_configure_stream(struct vsp1_entity *entity,
vsp1_wpf_write(wpf, dlb, VI6_WPF_DSWAP, fmtinfo->swap);
- if (vsp1_feature(vsp1, VSP1_HAS_WPF_HFLIP) &&
- wpf->entity.index == 0)
+ if (vsp1_feature(vsp1, VSP1_HAS_WPF_HFLIP) && index == 0)
vsp1_wpf_write(wpf, dlb, VI6_WPF_ROT_CTRL,
VI6_WPF_ROT_CTRL_LN16 |
(256 << VI6_WPF_ROT_CTRL_LMEM_WD_SHIFT));
@@ -289,11 +312,9 @@ static void wpf_configure_stream(struct vsp1_entity
*entity,
wpf->outfmt = outfmt;
- vsp1_dl_body_write(dlb, VI6_DPR_WPF_FPORCH(wpf->entity.index),
+ vsp1_dl_body_write(dlb, VI6_DPR_WPF_FPORCH(index),
VI6_DPR_WPF_FPORCH_FP_WPFN);
- vsp1_dl_body_write(dlb, VI6_WPF_WRBCK_CTRL(wpf->entity.index), 0);
-
/*
* Sources. If the pipeline has a single input and BRx is not used,
* configure it as the master layer. Otherwise configure all
@@ -319,9 +340,26 @@ static void wpf_configure_stream(struct vsp1_entity
*entity,
vsp1_wpf_write(wpf, dlb, VI6_WPF_SRCRPF, srcrpf);
/* Enable interrupts. */
- vsp1_dl_body_write(dlb, VI6_WPF_IRQ_STA(wpf->entity.index), 0);
- vsp1_dl_body_write(dlb, VI6_WPF_IRQ_ENB(wpf->entity.index),
+ vsp1_dl_body_write(dlb, VI6_WPF_IRQ_STA(index), 0);
+ vsp1_dl_body_write(dlb, VI6_WPF_IRQ_ENB(index),
VI6_WFP_IRQ_ENB_DFEE);
+
+ /*
+* Configure writeback for display
[PATCH v7 02/18] media: vsp1: wpf: Fix partition configuration for display pipelines
When configuring partitions for memory-to-memory pipelines, the WPF
accesses data of the current partition through pipe->partition.
Writeback support will require full configuration of the WPF while not
providing a valid pipe->partition. Rework the configuration code to fall
back to the full image width in that case, as is already done for the
part of the configuration currently relevant for display pipelines.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_wpf.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c
b/drivers/media/platform/vsp1/vsp1_wpf.c
index 32bb207b2007..a07c5944b598 100644
--- a/drivers/media/platform/vsp1/vsp1_wpf.c
+++ b/drivers/media/platform/vsp1/vsp1_wpf.c
@@ -362,6 +362,7 @@ static void wpf_configure_partition(struct vsp1_entity
*entity,
const struct vsp1_format_info *fmtinfo = wpf->fmtinfo;
unsigned int width;
unsigned int height;
+ unsigned int left;
unsigned int offset;
unsigned int flip;
unsigned int i;
@@ -371,13 +372,16 @@ static void wpf_configure_partition(struct vsp1_entity
*entity,
RWPF_PAD_SINK);
width = sink_format->width;
height = sink_format->height;
+ left = 0;
/*
* Cropping. The partition algorithm can split the image into
* multiple slices.
*/
- if (pipe->partitions > 1)
+ if (pipe->partitions > 1) {
width = pipe->partition->wpf.width;
+ left = pipe->partition->wpf.left;
+ }
vsp1_wpf_write(wpf, dlb, VI6_WPF_HSZCLIP, VI6_WPF_SZCLIP_EN |
(0 << VI6_WPF_SZCLIP_OFST_SHIFT) |
@@ -408,13 +412,11 @@ static void wpf_configure_partition(struct vsp1_entity
*entity,
flip = wpf->flip.active;
if (flip & BIT(WPF_CTRL_HFLIP) && !wpf->flip.rotate)
- offset = format->width - pipe->partition->wpf.left
- - pipe->partition->wpf.width;
+ offset = format->width - left - width;
else if (flip & BIT(WPF_CTRL_VFLIP) && wpf->flip.rotate)
- offset = format->height - pipe->partition->wpf.left
- - pipe->partition->wpf.width;
+ offset = format->height - left - width;
else
- offset = pipe->partition->wpf.left;
+ offset = left;
for (i = 0; i < format->num_planes; ++i) {
unsigned int hsub = i > 0 ? fmtinfo->hsub : 1;
@@ -436,7 +438,7 @@ static void wpf_configure_partition(struct vsp1_entity
*entity,
* image height.
*/
if (wpf->flip.rotate)
- height = pipe->partition->wpf.width;
+ height = width;
else
height = format->height;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 07/18] media: vsp1: dl: Allow chained display lists for display pipelines
Refactor the display list header setup to allow chained display lists
with display pipelines. Chain the display lists as for mem-to-mem
pipelines, but enable the frame end interrupt for every list as display
pipelines have a single list per frame.
This feature will be used to disable writeback exactly one frame after
enabling it by chaining a writeback disable display list.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_dl.c | 35 ++-
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index 886b3a69d329..ed7cda4130f2 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -770,17 +770,35 @@ static void vsp1_dl_list_fill_header(struct vsp1_dl_list
*dl, bool is_last)
}
dl->header->num_lists = num_lists;
+ dl->header->flags = 0;
- if (!list_empty(>chain) && !is_last) {
+ /*
+* Enable the interrupt for the end of each frame. In continuous mode
+* chained lists are used with one list per frame, so enable the
+* interrupt for each list. In singleshot mode chained lists are used
+* to partition a single frame, so enable the interrupt for the last
+* list only.
+*/
+ if (!dlm->singleshot || is_last)
+ dl->header->flags |= VSP1_DLH_INT_ENABLE;
+
+ /*
+* In continuous mode enable auto-start for all lists, as the VSP must
+* loop on the same list until a new one is queued. In singleshot mode
+* enable auto-start for all lists but the last to chain processing of
+* partitions without software intervention.
+*/
+ if (!dlm->singleshot || !is_last)
+ dl->header->flags |= VSP1_DLH_AUTO_START;
+
+ if (!is_last) {
/*
-* If this display list's chain is not empty, we are on a list,
-* and the next item is the display list that we must queue for
-* automatic processing by the hardware.
+* If this is not the last display list in the chain, queue the
+* next item for automatic processing by the hardware.
*/
struct vsp1_dl_list *next = list_next_entry(dl, chain);
dl->header->next_header = next->dma;
- dl->header->flags = VSP1_DLH_AUTO_START;
} else if (!dlm->singleshot) {
/*
* if the display list manager works in continuous mode, the VSP
@@ -788,13 +806,6 @@ static void vsp1_dl_list_fill_header(struct vsp1_dl_list
*dl, bool is_last)
* instructed to do otherwise.
*/
dl->header->next_header = dl->dma;
- dl->header->flags = VSP1_DLH_INT_ENABLE | VSP1_DLH_AUTO_START;
- } else {
- /*
-* Otherwise, in mem-to-mem mode, we work in single-shot mode
-* and the next display list must not be started automatically.
-*/
- dl->header->flags = VSP1_DLH_INT_ENABLE;
}
if (!dl->extension)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 04/18] media: vsp1: Fix addresses of display-related registers for VSP-DL
The VSP-DL instances have two LIFs, and thus two copies of the VI6_DISP_IRQ_ENB, VI6_DISP_IRQ_STA and VI6_WPF_WRBCK_CTRL registers. Fix the corresponding macros accordingly. Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham --- drivers/media/platform/vsp1/vsp1_drm.c | 4 ++-- drivers/media/platform/vsp1/vsp1_regs.h | 6 +++--- drivers/media/platform/vsp1/vsp1_wpf.c | 2 +- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/media/platform/vsp1/vsp1_drm.c b/drivers/media/platform/vsp1/vsp1_drm.c index 84895385d2e5..f5e810ca1f13 100644 --- a/drivers/media/platform/vsp1/vsp1_drm.c +++ b/drivers/media/platform/vsp1/vsp1_drm.c @@ -700,8 +700,8 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int pipe_index, drm_pipe->du_private = cfg->callback_data; /* Disable the display interrupts. */ - vsp1_write(vsp1, VI6_DISP_IRQ_STA, 0); - vsp1_write(vsp1, VI6_DISP_IRQ_ENB, 0); + vsp1_write(vsp1, VI6_DISP_IRQ_STA(pipe_index), 0); + vsp1_write(vsp1, VI6_DISP_IRQ_ENB(pipe_index), 0); /* Configure all entities in the pipeline. */ vsp1_du_pipeline_configure(pipe); diff --git a/drivers/media/platform/vsp1/vsp1_regs.h b/drivers/media/platform/vsp1/vsp1_regs.h index f6e4157095cc..1bb1d39c60d9 100644 --- a/drivers/media/platform/vsp1/vsp1_regs.h +++ b/drivers/media/platform/vsp1/vsp1_regs.h @@ -39,12 +39,12 @@ #define VI6_WFP_IRQ_STA_DFE(1 << 1) #define VI6_WFP_IRQ_STA_FRE(1 << 0) -#define VI6_DISP_IRQ_ENB 0x0078 +#define VI6_DISP_IRQ_ENB(n)(0x0078 + (n) * 60) #define VI6_DISP_IRQ_ENB_DSTE (1 << 8) #define VI6_DISP_IRQ_ENB_MAEE (1 << 5) #define VI6_DISP_IRQ_ENB_LNEE(n) (1 << (n)) -#define VI6_DISP_IRQ_STA 0x007c +#define VI6_DISP_IRQ_STA(n)(0x007c + (n) * 60) #define VI6_DISP_IRQ_STA_DST (1 << 8) #define VI6_DISP_IRQ_STA_MAE (1 << 5) #define VI6_DISP_IRQ_STA_LNE(n)(1 << (n)) @@ -307,7 +307,7 @@ #define VI6_WPF_DSTM_ADDR_C0 0x1028 #define VI6_WPF_DSTM_ADDR_C1 0x102c -#define VI6_WPF_WRBCK_CTRL 0x1034 +#define VI6_WPF_WRBCK_CTRL(n) (0x1034 + (n) * 0x100) #define VI6_WPF_WRBCK_CTRL_WBMD(1 << 0) /* - diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c b/drivers/media/platform/vsp1/vsp1_wpf.c index a07c5944b598..18c49e3a7875 100644 --- a/drivers/media/platform/vsp1/vsp1_wpf.c +++ b/drivers/media/platform/vsp1/vsp1_wpf.c @@ -291,7 +291,7 @@ static void wpf_configure_stream(struct vsp1_entity *entity, vsp1_dl_body_write(dlb, VI6_DPR_WPF_FPORCH(wpf->entity.index), VI6_DPR_WPF_FPORCH_FP_WPFN); - vsp1_dl_body_write(dlb, VI6_WPF_WRBCK_CTRL, 0); + vsp1_dl_body_write(dlb, VI6_WPF_WRBCK_CTRL(wpf->entity.index), 0); /* * Sources. If the pipeline has a single input and BRx is not used, -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 05/18] media: vsp1: Replace the display list internal flag with a flags field
To prepare for addition of more flags to the display list, replace the
'internal' flag field by a bitmask 'flags' field.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
Changes since v4:
- Fix check for the completed flag in vsp1_du_pipeline_frame_end()
---
drivers/media/platform/vsp1/vsp1_dl.c| 31 +---
drivers/media/platform/vsp1/vsp1_dl.h| 2 +-
drivers/media/platform/vsp1/vsp1_drm.c | 8 --
drivers/media/platform/vsp1/vsp1_video.c | 2 +-
4 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index 64af449791b0..886b3a69d329 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -178,7 +178,7 @@ struct vsp1_dl_cmd_pool {
* @post_cmd: post command to be issued through extended dl header
* @has_chain: if true, indicates that there's a partition chain
* @chain: entry in the display list partition chain
- * @internal: whether the display list is used for internal purpose
+ * @flags: display list flags, a combination of VSP1_DL_FRAME_END_*
*/
struct vsp1_dl_list {
struct list_head list;
@@ -197,7 +197,7 @@ struct vsp1_dl_list {
bool has_chain;
struct list_head chain;
- bool internal;
+ unsigned int flags;
};
/**
@@ -861,13 +861,15 @@ static void vsp1_dl_list_commit_continuous(struct
vsp1_dl_list *dl)
*
* If a display list is already pending we simply drop it as the new
* display list is assumed to contain a more recent configuration. It is
-* an error if the already pending list has the internal flag set, as
-* there is then a process waiting for that list to complete. This
-* shouldn't happen as the waiting process should perform proper
-* locking, but warn just in case.
+* an error if the already pending list has the
+* VSP1_DL_FRAME_END_INTERNAL flag set, as there is then a process
+* waiting for that list to complete. This shouldn't happen as the
+* waiting process should perform proper locking, but warn just in
+* case.
*/
if (vsp1_dl_list_hw_update_pending(dlm)) {
- WARN_ON(dlm->pending && dlm->pending->internal);
+ WARN_ON(dlm->pending &&
+ (dlm->pending->flags & VSP1_DL_FRAME_END_INTERNAL));
__vsp1_dl_list_put(dlm->pending);
dlm->pending = dl;
return;
@@ -897,7 +899,7 @@ static void vsp1_dl_list_commit_singleshot(struct
vsp1_dl_list *dl)
dlm->active = dl;
}
-void vsp1_dl_list_commit(struct vsp1_dl_list *dl, bool internal)
+void vsp1_dl_list_commit(struct vsp1_dl_list *dl, unsigned int dl_flags)
{
struct vsp1_dl_manager *dlm = dl->dlm;
struct vsp1_dl_list *dl_next;
@@ -912,7 +914,7 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl, bool
internal)
vsp1_dl_list_fill_header(dl_next, last);
}
- dl->internal = internal;
+ dl->flags = dl_flags & ~VSP1_DL_FRAME_END_COMPLETED;
spin_lock_irqsave(>lock, flags);
@@ -941,9 +943,10 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl, bool
internal)
* set in single-shot mode as display list processing is then not continuous
and
* races never occur.
*
- * The VSP1_DL_FRAME_END_INTERNAL flag indicates that the previous display list
- * has completed and had been queued with the internal notification flag.
- * Internal notification is only supported for continuous mode.
+ * The following flags are only supported for continuous mode.
+ *
+ * The VSP1_DL_FRAME_END_INTERNAL flag indicates that the display list that
just
+ * became active had been queued with the internal notification flag.
*/
unsigned int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
{
@@ -986,9 +989,9 @@ unsigned int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager
*dlm)
* frame end interrupt. The display list thus becomes active.
*/
if (dlm->queued) {
- if (dlm->queued->internal)
+ if (dlm->queued->flags & VSP1_DL_FRAME_END_INTERNAL)
flags |= VSP1_DL_FRAME_END_INTERNAL;
- dlm->queued->internal = false;
+ dlm->queued->flags &= ~VSP1_DL_FRAME_END_INTERNAL;
__vsp1_dl_list_put(dlm->active);
dlm->active = dlm->queued;
diff --git a/drivers/media/platform/vsp1/vsp1_dl.h
b/drivers/media/platform/vsp1/vsp1_dl.h
index 125750dc8b5c..e0fdb145e6ed 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.h
+++ b/drivers/media/platform/vsp1/vsp1_dl.h
@@ -61,7 +61,7 @@ struct vsp1_dl_list *vsp1_dl_list_get(struct vsp1_dl_manager
*dlm);
void vsp1_dl_list_put(struct vsp1_dl_list *dl);
struct vsp1_dl_body *vsp1_dl_list_get_body0(struct vsp1_dl_list *dl);
struct vsp1_dl_ext_cmd *vsp1_dl_get_pre_cmd(struct vsp1_dl_list *dl);
-void
[PATCH v7 00/18] R-Car DU display writeback support
Hello everybody, This is the latest and greatest version of the patch series that implements display writeback support for the R-Car Gen3 platforms in the VSP1 and DU drivers. All patches have been reviewed, all comments incorporated, and the result rebased on top ov v5.1-rc1. Patches 01/18 to 11/18 prepare the VSP1 driver for writeback support with all the necessary plumbing, including extensions of the API between the VSP1 and DU drivers. The most significant change compared to v6 is the rebase on top of v5.1-rc1. This was done to ease merging, as the VSP and DU parts would normally go through different trees. I usually ask Mauro or Dave their permission to merge the whole series through a single tree, and doing the same this time I would select the DRM tree given that I hope to get more DU patches merged in this development cycle. There is no foreseen conflicting patch for the VSP in v5.2, but if a need arises, I will them on top of the 11 first patches of this series and send a pull request to Mauro to avoid conflicts. Mauro, I plan to send a pull request to Dave by the end of this week, so if you'd like to have a look at the VSP patches, now would be a good time :-) It's only driver changes, and they have been reviewed already, so I don't expect any problem. Compared to v5 the major change is the usage of chained display lists in the VSP to disable writeback after one frame, instead of patching the active display list in memory. This should solve the potential DMA to released buffer issue that could occur when the frame start interrupt was delayed after frame end. Patch 06/18 and 07/18 are new in this version to support usage of chained display pipelines. Compared to v4 the major change is the move from V4L2 to DRM writeback connectors for the userspace API. This has caused a few issues with writeback support to be uncovered, and they are addressed by patches 12/18 to 14/18. Patches 15/18 to 17/18 then perform refactoring of the DU driver, to finally add writeback support in patch 18/18. The writeback pixel format is restricted to RGB, due to the VSP1 outputting RGB to the display and lacking a separate colour space conversion unit for writeback. The writeback framebuffer size must match the active mode, writeback scaling is not supported by the hardware. Writeback requests being part of atomic commits, they're queued to the hardware when they are received, become active at the next vblank, and complete on the following vblank. The display list chaining mechanism ensures that writeback will be enabled for a single frame only, unless the next atomic commit contains a separate writeback request. For convenience patches can be found at git://linuxtv.org/pinchartl/media.git drm/du/writeback Kieran Bingham (1): Revert "[media] v4l: vsp1: Supply frames to the DU continuously" Laurent Pinchart (17): media: vsp1: wpf: Fix partition configuration for display pipelines media: vsp1: Replace leftover occurrence of fragment with body media: vsp1: Fix addresses of display-related registers for VSP-DL media: vsp1: Replace the display list internal flag with a flags field media: vsp1: Add vsp1_dl_list argument to .configure_stream() operation media: vsp1: dl: Allow chained display lists for display pipelines media: vsp1: wpf: Add writeback support media: vsp1: drm: Split RPF format setting to separate function media: vsp1: drm: Extend frame completion API to the DU driver media: vsp1: drm: Implement writeback support drm: writeback: Cleanup job ownership handling when queuing job drm: writeback: Fix leak of writeback job drm: writeback: Add job prepare and cleanup operations drm: rcar-du: Fix rcar_du_crtc structure documentation drm: rcar-du: Store V4L2 fourcc in rcar_du_format_info structure drm: rcar-du: vsp: Extract framebuffer (un)mapping to separate functions drm: rcar-du: Add writeback support for R-Car Gen3 drivers/gpu/drm/arm/malidp_mw.c | 3 +- drivers/gpu/drm/drm_atomic_helper.c | 11 + drivers/gpu/drm/drm_atomic_state_helper.c | 4 + drivers/gpu/drm/drm_atomic_uapi.c | 31 +-- drivers/gpu/drm/drm_writeback.c | 73 +- drivers/gpu/drm/rcar-du/Kconfig | 4 + drivers/gpu/drm/rcar-du/Makefile| 3 +- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 7 +- drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 9 +- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 37 +++ drivers/gpu/drm/rcar-du/rcar_du_kms.h | 1 + drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 122 +- drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 17 ++ drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 243 drivers/gpu/drm/rcar-du/rcar_du_writeback.h | 39 drivers/gpu/drm/vc4/vc4_txp.c | 2 +- drivers/media/platform/vsp1/vsp1_brx.c | 1 + drivers/media/platform/vsp1/vsp1_clu.c | 1 + drivers/media/platform/vsp1/vsp1_dl.c | 84
[PATCH v7 01/18] Revert "[media] v4l: vsp1: Supply frames to the DU continuously"
From: Kieran Bingham
This reverts commit 3299ba5c0b21 ("[media] v4l: vsp1: Supply frames to
the DU continuously")
The DU output mode does not rely on frames being supplied on the WPF as
its pipeline is supplied from DRM. For the upcoming WPF writeback
functionality, we will choose to enable writeback mode if there is an
output buffer, or disable it (leaving the existing display pipeline
unharmed) otherwise.
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_video.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_video.c
b/drivers/media/platform/vsp1/vsp1_video.c
index 7ceaf3222145..328d686189be 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -307,11 +307,6 @@ static int vsp1_video_pipeline_setup_partitions(struct
vsp1_pipeline *pipe)
* This function completes the current buffer by filling its sequence number,
* time stamp and payload size, and hands it back to the videobuf core.
*
- * When operating in DU output mode (deep pipeline to the DU through the LIF),
- * the VSP1 needs to constantly supply frames to the display. In that case, if
- * no other buffer is queued, reuse the one that has just been processed
instead
- * of handing it back to the videobuf core.
- *
* Return the next queued buffer or NULL if the queue is empty.
*/
static struct vsp1_vb2_buffer *
@@ -333,12 +328,6 @@ vsp1_video_complete_buffer(struct vsp1_video *video)
done = list_first_entry(>irqqueue,
struct vsp1_vb2_buffer, queue);
- /* In DU output mode reuse the buffer if the list is singular. */
- if (pipe->lif && list_is_singular(>irqqueue)) {
- spin_unlock_irqrestore(>irqlock, flags);
- return done;
- }
-
list_del(>queue);
if (!list_empty(>irqqueue))
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC 07/15] dt-bindings: display: renesas: lvds: Add renesas,companion property
Hi Geert, On Mon, Mar 18, 2019 at 11:21:15AM +0100, Geert Uytterhoeven wrote: > On Thu, Mar 7, 2019 at 12:24 AM Laurent Pinchart wrote: > > Add a new optional renesas,companion property to point to the companion > > LVDS encoder. This is used to support dual-link operation where the main > > LVDS encoder splits even-numbered and odd-numbered pixels between the > > two LVDS encoders. > > Note that Documentation/devicetree/bindings/usb/generic.txt already > describes a "companion" property without vendor prefix. > > > The new property doesn't control the mode of operation, it only > > describes the relationship between the master and companion LVDS > > encoders. > > > > Signed-off-by: Laurent Pinchart > > --- > > .../devicetree/bindings/display/bridge/renesas,lvds.txt | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt > > b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt > > index 900a884ad9f5..a720dbb5de69 100644 > > --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt > > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt > > @@ -45,6 +45,12 @@ OF graph bindings specified in > > Documentation/devicetree/bindings/graph.txt. > > > > Each port shall have a single endpoint. > > > > +Optional properties: > > + > > +- renesas,companion : phandle to the companion LVDS encoder. This property > > is > > + valid for the first LVDS encoder D3 and E3 SoCs only, and points to the > > ... on D3 ... > > > + second encoder to be used as a companion in dual-link mode. > > Why restrict this to the first LVDS decoder, and not have a backlink in the > other node, Because there's no need to ? :-) Furthermore there's a need for the master to know its a master, so have a link in a single direction is pretty convenient. Otherwise I'd need an extra property to identify the master. > like for USB? I'm not sure what USB does in that regard. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109607] [CI][DRMTIP] Time is passing at a different rate between IGT machines and the controller
https://bugs.freedesktop.org/show_bug.cgi?id=109607
--- Comment #9 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- fi-kbl-7560u fi-icl-u2, fi-icl-u3: random tests - incomplete -}
{+ fi-kbl-7560u fi-icl-u2, fi-icl-u3: random tests - incomplete +}
New failures caught by the filter:
*
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_243/fi-icl-u3/igt@kms_flip@2x-blocking-wf_vblank.html
--
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 201795] [Regression] Wrong 4k resolution detected with DisplayPort to HDMI adapter on amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=201795 --- Comment #22 from thomas.lassdiesonner...@gmx.de --- I investigated further and the culprit seems to be that kernel =4.14 ignores what xrandr *wrongly* detects and sets the connected TV correctly to its native 3840x2160@60hz without black bars. Xrandr detects only 30hz in both 4k resolutions on all kernels. Kernel 4.14 still manages somehow to give me 3840x2160@60hz without black bars. So could this be a xrandr-bug? Kernel >4.14 seems to respect xrandr and sets: 4096x2160@30hz without black bars - maybe my HDMI2.0-to-DP adapter is reporting this setting. I also can get 3840x2160@30hz without black bars with your xrandr workaround, but not 60hz. In more detail: kernel =4.14 - xrandr --props reports that scale-mode is "None". But still no black bars, because the *native* resolution of the TV is 3840x2160 (listed in the panel specs here: https://www.lg.com/us/support-product/lg-OLED65B7P) So if I change to 4096er resolution the desktop is bigger than the screen. Also I have 60hz on both displays, while xrandr *wrongly* reports only 30hz available on the TV. The difference between 60 and 30hz is very visible when moving the mouse and e.g. supertuxkart confirms 60hz in the FPS-overlay. kernel >4.14 -- The TV sets only 30hz, on 4096 and 3840 res. When I force a 60hz-modeline via xorg.conf.d like described here https://wiki.archlinux.org/index.php/xrandr#Adding_undetected_resolutions I get no signal or a switch back to 30hz, when cloning in the GUI. Then the 3840-black-bar workaround only works if I create this file: cat /etc/xdg/autostart/Scaling.desktop [Desktop Entry] Type=Application Name=Scaling Exec=xrandr --output DisplayPort-0 --set "scaling mode" "Full" Putting it in xorg.conf had no effect. This is what my xorg.conf now looks like. Note that the VRR Option works as expected, so its not as if the file is completely ignored: cat /etc/X11/xorg.conf.d/10-monitor.conf Section "Monitor" Identifier "DisplayPort-0" Option "scaling mode" "Full" Option "PreferredMode" "3840x2160" EndSection Section "Screen" Identifier "Screen0" Device "AMD" EndSection Section "Device" Identifier "AMD" Driver "amdgpu" Option "DRI" "3" Option "TearFree""true" Option "VariableRefresh" "true" EndSection -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110031] Failure to configure monitors with dc enabled
https://bugs.freedesktop.org/show_bug.cgi?id=110031 --- Comment #5 from Nicholas Kazlauskas --- Ah, those were both dmesg logs. Those are sufficient then, thanks! -- 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 110031] Failure to configure monitors with dc enabled
https://bugs.freedesktop.org/show_bug.cgi?id=110031 --- Comment #4 from Tom Hughes --- Doesn't the drm.debug=6 that I used before already include 4 as it's a bitmask? -- 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 110031] Failure to configure monitors with dc enabled
https://bugs.freedesktop.org/show_bug.cgi?id=110031 --- Comment #3 from Nicholas Kazlauskas --- Please post a dmesg log after booting (preferably after the commit failure occurs) with drm.debug=4 as part of your kernel boot parameters. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] android: libdrm_platform: add liblog shared dependency
On 3/18/19 3:25 PM, Robert Foss wrote: Hey, On 3/18/19 2:11 PM, Mauro Rossi wrote: Hi, On Mon, Mar 18, 2019 at 10:58 AM Robert Foss wrote: Hey Mauro, On 3/18/19 9:38 AM, Mauro Rossi wrote: Hi Robert, On Mon, Mar 18, 2019 at 9:21 AM Robert Foss wrote: On a second note, this does not apply on libdrm/master due to: LOCAL_SHARED_LIBRARIES := \ libcutils Sorry, we have an additional Google patch, not present in libdrm/master that adds libdrm_platform module, but it is for a specific Google issue. [1] However with libdrm module we have both liblog and libcutils shared dependencies [1] http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=commit;h=8ccbfeab9fb2bddf4585339a0bcbea2f1e3ffa1e Do you know if [1] causes incompatibility issues with earlier android verions? If not I would suggest upstreaming it too. I used those patches to build with nougat-x86 and there was no issue. To be precise I did a double rookie mistake, because __android_log_vprint not used in upstream libdrm and libdrm_platform not used either. Now starting from my mistakes, let's see if there is anything useful to libdrm project In our builds Chih-Wei Huang said that libdrm_platform is not used, meaning not added to packages list, however with oreo-x86 the build error appeared and the liblog dependency. __android_log_vprint is used with __ANDROID__ braces in a special patch [2] by Chih-Wei Huang which adds capability to print logs in logcat If it's not too invasive in libdrm, it could be useful. Cheers Mauro [2] http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=commitdiff;h=bcee43063ffd52a8677029c9ae6f4203563460f4;hp=81d7264033db4946a3bf1ee82eb6c21260f9 [2] Seems like a good idea to me. Logcat really is the only intended path for logging on Android, and redirecting our logs there does make sense to me. But, I'm not sure about I like the way [2] disregards log-levels in drmMsg(). Yeah, I think it's a good idea. I see that in mesa we include "android/log.h", not "log/log.h", will need to make sure we get that correctly, maybe older versions did "log/log.h"? // Tapani ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] android: libdrm_platform: add liblog shared dependency
Hey, On 3/18/19 2:11 PM, Mauro Rossi wrote: Hi, On Mon, Mar 18, 2019 at 10:58 AM Robert Foss wrote: Hey Mauro, On 3/18/19 9:38 AM, Mauro Rossi wrote: Hi Robert, On Mon, Mar 18, 2019 at 9:21 AM Robert Foss wrote: On a second note, this does not apply on libdrm/master due to: LOCAL_SHARED_LIBRARIES := \ libcutils Sorry, we have an additional Google patch, not present in libdrm/master that adds libdrm_platform module, but it is for a specific Google issue. [1] However with libdrm module we have both liblog and libcutils shared dependencies [1] http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=commit;h=8ccbfeab9fb2bddf4585339a0bcbea2f1e3ffa1e Do you know if [1] causes incompatibility issues with earlier android verions? If not I would suggest upstreaming it too. I used those patches to build with nougat-x86 and there was no issue. To be precise I did a double rookie mistake, because __android_log_vprint not used in upstream libdrm and libdrm_platform not used either. Now starting from my mistakes, let's see if there is anything useful to libdrm project In our builds Chih-Wei Huang said that libdrm_platform is not used, meaning not added to packages list, however with oreo-x86 the build error appeared and the liblog dependency. __android_log_vprint is used with __ANDROID__ braces in a special patch [2] by Chih-Wei Huang which adds capability to print logs in logcat If it's not too invasive in libdrm, it could be useful. Cheers Mauro [2] http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=commitdiff;h=bcee43063ffd52a8677029c9ae6f4203563460f4;hp=81d7264033db4946a3bf1ee82eb6c21260f9 [2] Seems like a good idea to me. Logcat really is the only intended path for logging on Android, and redirecting our logs there does make sense to me. But, I'm not sure about I like the way [2] disregards log-levels in drmMsg(). Rob. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] android: libdrm_platform: add liblog shared dependency
Hi, On Mon, Mar 18, 2019 at 10:58 AM Robert Foss wrote: > > Hey Mauro, > > On 3/18/19 9:38 AM, Mauro Rossi wrote: > > Hi Robert, > > > > On Mon, Mar 18, 2019 at 9:21 AM Robert Foss > > wrote: > >> > >> On a second note, this does not apply on libdrm/master due > >> to: > >> > >> LOCAL_SHARED_LIBRARIES := \ > >> libcutils > > > > Sorry, we have an additional Google patch, not present in libdrm/master > > that adds libdrm_platform module, but it is for a specific Google issue. [1] > > > > However with libdrm module we have both liblog and libcutils shared > > dependencies > > > > [1] > > http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=commit;h=8ccbfeab9fb2bddf4585339a0bcbea2f1e3ffa1e > > Do you know if [1] causes incompatibility issues with earlier android verions? > If not I would suggest upstreaming it too. I used those patches to build with nougat-x86 and there was no issue. To be precise I did a double rookie mistake, because __android_log_vprint not used in upstream libdrm and libdrm_platform not used either. Now starting from my mistakes, let's see if there is anything useful to libdrm project In our builds Chih-Wei Huang said that libdrm_platform is not used, meaning not added to packages list, however with oreo-x86 the build error appeared and the liblog dependency. __android_log_vprint is used with __ANDROID__ braces in a special patch [2] by Chih-Wei Huang which adds capability to print logs in logcat If it's not too invasive in libdrm, it could be useful. Cheers Mauro [2] http://git.osdn.net/view?p=android-x86/external-libdrm.git;a=commitdiff;h=bcee43063ffd52a8677029c9ae6f4203563460f4;hp=81d7264033db4946a3bf1ee82eb6c21260f9 > > > > > Mauro > > > >> > >> My thinking is that libcutils probably can be replaced with liblog, > >> but I'm not 100% sure. > >> > >> > >> Rob. > >> > >> On 3/18/19 9:09 AM, Robert Foss wrote: > >>> This is probably a good idea! > >>> > >>> > >>> Reviewed-by: Robert Foss > >>> > >>> On 3/17/19 9:54 PM, Mauro Rossi wrote: > Hi, > I used the option --subject-prefix="PATCH libdrm" > but it did not go as expected. > > Anyway, the patch is for Android build of mesa/drm > Mauro > > On Sun, Mar 17, 2019 at 9:50 PM Mauro Rossi > wrote: > > > > Fixes the following building error: > > > > FAILED: > > $(OUT)/obj/SHARED_LIBRARIES/libdrm_platform_intermediates/LINKED/libdrm_platform.so > > > > ... > > external/libdrm/xf86drm.c:146: error: undefined reference to > > '__android_log_vprint' > > clang.real: error: linker command failed with exit code 1 (use -v to see > > invocation) > > > > Signed-off-by: Mauro Rossi > > --- > >Android.mk | 3 +++ > >1 file changed, 3 insertions(+) > > > > diff --git a/Android.mk b/Android.mk > > index f2c78bc1..f832b24e 100644 > > --- a/Android.mk > > +++ b/Android.mk > > @@ -61,6 +61,9 @@ LOCAL_EXPORT_C_INCLUDE_DIRS := \ > > $(LOCAL_PATH) \ > > $(LOCAL_PATH)/include/drm > > > > +LOCAL_SHARED_LIBRARIES := \ > > + liblog > > + > >LOCAL_C_INCLUDES := \ > > $(LOCAL_PATH)/include/drm > > > > -- > > 2.19.1 > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110140] Green bottom half of video frame when using JPEG acceleration (vcn_v1_0_jpeg_ring_emit_fence() WARNING)
https://bugs.freedesktop.org/show_bug.cgi?id=110140 --- Comment #9 from leoxs...@gmail.com --- It makes more sense now, we'll take a look. But the thing is we don't got Raven system with a camera, so it's probably hard to reproduce. -- 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 202445] amdgpu/dc: framerate dropping below adaptive sync range causes screen flickering
https://bugzilla.kernel.org/show_bug.cgi?id=202445 --- Comment #26 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) --- Was "drm/amd/display: Use vrr friendly pageflip throttling in DC." also in the tree you built? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110138] Adaptive Sync, VRR, FreeSync out of range
https://bugs.freedesktop.org/show_bug.cgi?id=110138 --- Comment #3 from Nicholas Kazlauskas --- Created attachment 143724 --> https://bugs.freedesktop.org/attachment.cgi?id=143724=edit 0001-drm-amd-display-Only-allow-VRR-when-vrefresh-is-with.patch I think this patch should fix your issue. We previously blocked enabling it if vrefresh < min supported range, but we didn't cover vrefresh > max supported range. -- 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 110137] drirc adaptive sync, vrr, freesync blacklisting documentation
https://bugs.freedesktop.org/show_bug.cgi?id=110137 --- Comment #1 from Nicholas Kazlauskas --- AFAIK, the matching should just be done based on the executable name. See: src/util/u_process.c The process name likely differs for the content processes for the browser. You might need both qutebrowser and QtWebEngineProcess blacklisted: -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] drm/virtio: Add window server support
[Tomasz wants to comment, adding him to CC] On 2/5/18 9:19 AM, Tomeu Vizoso wrote: On 1 February 2018 at 17:36, Gerd Hoffmann wrote: Hi, Sorry for joining the party late. Had a broken finger and was offline for a bunch of weeks (and a buif backlog afterwards ...). Hi, no problem, hope it's fine now. This is to allow clients running within VMs to be able to communicate with a compositor in the host. Clients will use the communication protocol that the compositor supports, and virtio-gpu will assist with making buffers available in both sides, and copying content as needed. Why not use virtio-vsock to run the wayland protocol? I don't like the idea to duplicate something with very simliar functionality in virtio-gpu. The reason for abandoning that approach was the type of objects that could be shared via virtio-vsock would be extremely limited. Besides that being potentially confusing to users, it would mean from the implementation side that either virtio-vsock would gain a dependency on the drm subsystem, or an appropriate abstraction for shareable buffers would need to be added for little gain. Another factor that was taken into account was that the complexity required for implementing passing protocol data around was very small when compared with the buffer sharing mechanism. It is expected that a service in the guest will act as a proxy, interacting with virtio-gpu to support unmodified clients. If you have a guest proxy anyway using virtio-sock for the protocol stream and virtio-gpu for buffer sharing (and some day 3d rendering too) should work fine I think. If I understand correctly your proposal, virtio-gpu would be used for creating buffers that could be shared across domains, but something equivalent to SCM_RIGHTS would still be needed in virtio-vsock? If so, that's what was planned initially, with the concern being that we would be adding a bunch of complexity to virtio-vsock that would be only used in this specific use case. Then we would also need to figure out how virtio-vsock would be able to work with buffers from virtio-gpu (either direct dependency or a new abstraction). If the mechanics of passing presentation data were very complex, I think this approach would have more merit. But as you can see from the code, it isn't that bad. When the client notifies the compositor that it can read from that buffer, the proxy should copy the contents from the SHM region to the virtio-gpu resource and call DRM_VIRTGPU_TRANSFER_TO_HOST. What is the plan for the host side? I see basically two options. Either implement the host wayland proxy directly in qemu. Or implement it as separate process, which then needs some help from qemu to get access to the buffers. The later would allow qemu running independant from the desktop session. Regarding synchronizing buffers, this will stop becoming needed in subsequent commits as all shared memory is allocated in the host and mapped to the guest via KVM_SET_USER_MEMORY_REGION. This is already the case for buffers passed from the compositor to the clients (see patch 2/2), and I'm working on the equivalent for buffers from the guest to the host (clients still have to create buffers with DRM_VIRTGPU_RESOURCE_CREATE but they will be only backend by host memory so no calls to DRM_VIRTGPU_TRANSFER_TO_HOST are needed). But in the case that we still need a proxy for some reason on the host side, I think it would be better to have it in the same process where virtio-gpu is implemented. In crosvm's case it would be in a process separate from the main VMM, as device processes are isolated from each other with minijail (see https://chromium.googlesource.com/chromiumos/platform/crosvm/ ). Regards, Tomeu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/sun4i: Implement gamma correction
Hi, On Thu, Mar 14, 2019 at 10:54:26AM -0700, Vasily Khoruzhick wrote: > On Thu, Mar 14, 2019 at 8:42 AM Maxime Ripard > wrote: > > > > Hi Vasily, > > > > On Wed, Mar 13, 2019 at 07:58:38PM -0700, Vasily Khoruzhick wrote: > > > Add support for gamma corretion to sun4i TCON driver. Its LUT has 256 > > > entries and can be updated only when gamma correction is disabled. > > > > > > Signed-off-by: Vasily Khoruzhick > > > > It's not really clear to me what you expect a comment on? > > I'm not sure that I put gamma correction into right place - gamma lut > seems to be a property of CRTC, but registers are in TCON module. The TCON loosely maps to the CRTC, so that's ok. > Also I'm not sure if gamma correction is supported across all > Allwinner SoCs - if it doesn't, how do we handle this? I don't really know if that's supported on all of them, but the way to handle this would be to associate it with the compatible and add a quirk if that's relevant. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] android: libdrm_platform: add liblog shared dependency
It seems like there is no usage of __android_log_vprint in upstream libdrm. Perhaps this was against libdrm with some android specific changes on top? On 3/17/19 10:50 PM, Mauro Rossi wrote: Fixes the following building error: FAILED: $(OUT)/obj/SHARED_LIBRARIES/libdrm_platform_intermediates/LINKED/libdrm_platform.so ... external/libdrm/xf86drm.c:146: error: undefined reference to '__android_log_vprint' clang.real: error: linker command failed with exit code 1 (use -v to see invocation) Signed-off-by: Mauro Rossi --- Android.mk | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Android.mk b/Android.mk index f2c78bc1..f832b24e 100644 --- a/Android.mk +++ b/Android.mk @@ -61,6 +61,9 @@ LOCAL_EXPORT_C_INCLUDE_DIRS := \ $(LOCAL_PATH) \ $(LOCAL_PATH)/include/drm +LOCAL_SHARED_LIBRARIES := \ + liblog + LOCAL_C_INCLUDES := \ $(LOCAL_PATH)/include/drm ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
