[PATCH] drm/virtio: fix possible leak/unlock virtio_gpu_object_array
virtio_gpu_object array is not freed or unlocked in some
failed cases.
Signed-off-by: xndcn
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_object.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 23eb6d772e..669f2ee395 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -174,7 +174,7 @@ static int virtio_gpu_execbuffer_ioctl(struct drm_device
*dev, void *data,
if (!sync_file) {
dma_fence_put(&out_fence->f);
ret = -ENOMEM;
- goto out_memdup;
+ goto out_unresv;
}
exbuf->fence_fd = out_fence_fd;
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
b/drivers/gpu/drm/virtio/virtgpu_object.c
index d69a5b6da5..4ff1ec28e6 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -248,6 +248,7 @@ int virtio_gpu_object_create(struct virtio_gpu_device
*vgdev,
ret = virtio_gpu_object_shmem_init(vgdev, bo, &ents, &nents);
if (ret != 0) {
+ virtio_gpu_array_put_free(objs);
virtio_gpu_free_object(&shmem_obj->base);
return ret;
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/2] dt-bindings: usb: add analogix,anx7688.yaml
Hello Dafna, On Fri, Mar 05, 2021 at 04:14:03PM +0100, Dafna Hirschfeld wrote: > Hi > > On 05.03.21 15:34, Laurent Pinchart wrote: > > Hi Dafna, > > > > Thank you for the patch. > > > > On Fri, Mar 05, 2021 at 01:43:50PM +0100, Dafna Hirschfeld wrote: > > > ANX7688 is a USB Type-C port controller with a MUX. It converts HDMI 2.0 > > > to > > > DisplayPort 1.3 Ultra-HDi (4096x2160p60). > > > The integrated crosspoint switch (the MUX) supports USB 3.1 data transfer > > > along with the DisplayPort Alternate Mode signaling over USB Type-C. > > > Additionally, an on-chip microcontroller (OCM) is available to manage the > > > signal switching, Channel Configuration (CC) detection, USB Power > > > Delivery (USB-PD), Vendor Defined Message (VDM) protocol support and other > > > functions as defined in the USB TypeC and USB Power Delivery > > > specifications. > > > > > > ANX7688 is found on Acer Chromebook R13 (elm) and on > > > Pine64 PinePhone. Thanks for your work on the bindings. :) It would be great to find something acceptable for mainlining. A few comments based on my experience implementing the USB-PD part for PinePhone are bellow. > > > +properties: > > > + compatible: > > > +const: analogix,anx7688 > > > + > > > + reg: > > > +maxItems: 1 > > > + > > > + avdd33-supply: > > > +description: 3.3V Analog core supply voltage. > > > + > > > + dvdd18-supply: > > > +description: 1.8V Digital I/O supply voltage. > > > + > > > + avdd18-supply: > > > +description: 1.8V Analog core power supply voltage. > > > + > > > + avdd10-supply: > > > +description: 1.0V Analog core power supply voltage. > > > + > > > + dvdd10-supply: > > > +description: 1.0V Digital core supply voltage. > > > + > > > > That's lots of supplies. If there's a reasonable chance that some of > > them will always be driven by the same regulator (especially if the > > ANX7688 documentation requires that), then they could be grouped. For > > instance dvdd18-supply and avdd18-supply could be grouped into > > vdd18-supply. It would still allow us to extend the bindings in a > > backward compatible way later if a system uses different regulators. You > > have more information about the hardware than I do, so it's your call. On PinePhone, AVDD and DVDD for 1.0V are just separately fitlered outputs from the same regulator. So it would work there to just use vdd18 and vdd10. The same is true for reference design, so it's probably safe to assume this can be simplified. > > > + hdmi5v-supply: > > > +description: 5V power supply for the HDMI. > > > + > > > + hdmi_vt-supply: > > > +description: Termination voltage for HDMI input. > > > > Maybe hdmi-vt-supply ? > > > > > + > > > + clocks: > > > +description: The input clock specifier. > > > +maxItems: 1 > > > > How about > > > > items: > >- description: The input clock specifier. > > > > > + > > > + clock-names: > > > +items: > > > + - const: xtal > > > + > > > + hpd-gpios: > > > +description: | > > > + In USB Type-C applications, DP_HPD has no use. In standard > > > DisplayPort > > > + applications, DP_HPD is used as DP hot-plug. > > > +maxItems: 1 On PinePhone this is wired to a HDMI port on the SoC, and HPD is handled by the sun4i HDMI DRM driver. Seems like HPD will be handled by HDMI controller on many/all? other platforms too. Why have it here? > > > + enable-gpios: > > > +description: Chip power down control. No internal pull-down or > > > pull-up resistor. > > > +maxItems: 1 > > > + > > > + reset-gpios: > > > +description: Reset input signal. Active low. > > > +maxItems: 1 > > > + > > > + vbus-det-gpios: > > > +description: | > > > + An input gpio for VBUS detection and high voltage detection, > > > + external resistance divide VBUS voltage to 1/8. > > > +maxItems: 1 Why have this in the bindings? It seems that this is handled internally by the ANX7688 via OCM firmware. And it's not really gpio either, it's an analog input with AD converter hooked to it internally. > > > + interrupts: > > > +description: | > > > + The interrupt notifies 4 possible events - TCPC ALERT int, PD int, > > > DP int, HDMI int. > > > +maxItems: 1 > > > + > > > + cabledet-gpios: > > > +description: An output gpio, indicates by the device that a cable is > > > plugged. > > > +maxItems: 1 > > > + > > > + vbus-ctrl-gpios: > > > +description: > > > + External VBUS power path. Enable VBUS source and disable VBUS sink > > > or vice versa. > > > +maxItems: 1 VBUS control seems to be already modelled by the usb-connector bindings. Why have this here? > > > + vconn-en1-gpios: > > > +description: Controls the VCONN switch on the CC1 pin. > > > +maxItems: 1 > > > + > > > + vconn-en2-gpios: > > > +description: Controls the VCONN switch on the CC2 pin. > > > +maxItems: 1 VCONN is a voltage regulator that can be enabled either on C
Re: [PATCH v13 1/2] drm/tegra: dc: Support memory bandwidth management
On Fri, Mar 05, 2021 at 12:45:51AM +0300, Dmitry Osipenko wrote: > 04.03.2021 02:08, Michał Mirosław пишет: > > On Tue, Mar 02, 2021 at 03:44:44PM +0300, Dmitry Osipenko wrote: > >> Display controller (DC) performs isochronous memory transfers, and thus, > >> has a requirement for a minimum memory bandwidth that shall be fulfilled, > >> otherwise framebuffer data can't be fetched fast enough and this results > >> in a DC's data-FIFO underflow that follows by a visual corruption. [...] > >> + /* > >> + * Horizontal downscale takes extra bandwidth which roughly depends > >> + * on the scaled width. > >> + */ > >> + if (src_w > dst_w) > >> + mul = (src_w - dst_w) * bpp / 2048 + 1; > >> + else > >> + mul = 1; > > > > Does it really need more bandwidth to scale down? Does it read the same > > data multiple times just to throw it away? > The hardware isn't optimized for downscale, it indeed takes more > bandwidth. You'll witness a severe underflow of plane's memory FIFO > buffer on trying to downscale 1080p plane to 50x50. [...] In your example, does it really need 16x the bandwidth compared to no scaling case? The naive way to implement downscaling would be to read all the pixels and only take every N-th. Maybe the problem is that in downscaling mode the latency requirements are tighter? Why would bandwidth required be proportional to a difference between the widths (instead e.g. to src/dst or dst*cacheline_size)? Best Regards Michał Mirosław ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: cleanup unused or almost unused IOMMU APIs and the FSL PAMU driver
On Mon, Mar 1, 2021 at 2:44 AM Christoph Hellwig wrote: > > Hi all, > > there are a bunch of IOMMU APIs that are entirely unused, or only used as > a private communication channel between the FSL PAMU driver and it's only > consumer, the qbman portal driver. > > So this series drops a huge chunk of entirely unused FSL PAMU > functionality, then drops all kinds of unused IOMMU APIs, and then > replaces what is left of the iommu_attrs with properly typed, smaller > and easier to use specific APIs. It looks like the unused APIs were added for functionality that were never completed later on. So Acked-by: Li Yang > > Diffstat: > arch/powerpc/include/asm/fsl_pamu_stash.h | 12 > drivers/gpu/drm/msm/adreno/adreno_gpu.c |2 > drivers/iommu/amd/iommu.c | 23 > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 85 --- > drivers/iommu/arm/arm-smmu/arm-smmu.c | 122 +--- > drivers/iommu/dma-iommu.c |8 > drivers/iommu/fsl_pamu.c| 264 -- > drivers/iommu/fsl_pamu.h| 10 > drivers/iommu/fsl_pamu_domain.c | 694 > ++-- > drivers/iommu/fsl_pamu_domain.h | 46 - > drivers/iommu/intel/iommu.c | 55 -- > drivers/iommu/iommu.c | 75 --- > drivers/soc/fsl/qbman/qman_portal.c | 56 -- > drivers/vfio/vfio_iommu_type1.c | 31 - > drivers/vhost/vdpa.c| 10 > include/linux/iommu.h | 81 --- > 16 files changed, 214 insertions(+), 1360 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: remove duplicate include in amdgpu_dm.c
From: Zhang Yunkai 'drm/drm_hdcp.h' included in 'amdgpu_dm.c' is duplicated. It is also included in the 79th line. Signed-off-by: Zhang Yunkai --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 - 1 file changed, 1 deletion(-) 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 3e1fd1e7d09f..fee46fbcb0b7 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -44,7 +44,6 @@ #include "amdgpu_dm.h" #ifdef CONFIG_DRM_AMD_DC_HDCP #include "amdgpu_dm_hdcp.h" -#include #endif #include "amdgpu_pm.h" -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/uapi: document kernel capabilities
On Friday, March 5th, 2021 at 9:28 AM, Pekka Paalanen wrote: > > +/** > > + * DRM_CAP_DUMB_PREFERRED_DEPTH > > + * > > + * The preferred depth (in bits) for dumb buffers. > > this is literally depth, not bits per pixel, right? "Depth" is pretty ambiguous [1]. Maybe we should be more explicit here and say that it's the number of bits used to indicate the color of a single pixel? And maybe add a note that it's different from bits per pixel? [1]: https://en.wikipedia.org/wiki/Color_depth > > + */ > > #define DRM_CAP_DUMB_PREFERRED_DEPTH 0x3 > > +/** > > + * DRM_CAP_DUMB_PREFER_SHADOW > > + * > > + * If set to 1, the driver prefers userspace to render to a shadow buffer > > + * instead of directly rendering to a dumb buffer. > > Maybe add something like: > > For best speed, userspace should do streaming ordered memory copies > into the dumb buffer and never read from it. > > Isn't that correct? Good call, will add. > > + */ > > #define DRM_CAP_DUMB_PREFER_SHADOW 0x4 > > +/** > > + * DRM_CAP_PRIME > > + * > > + * Bitfield of supported PRIME sharing capabilities. See > > &DRM_PRIME_CAP_IMPORT > > + * and &DRM_PRIME_CAP_EXPORT. > > + */ > > #define DRM_CAP_PRIME 0x5 > > +/** > > + * DRM_PRIME_CAP_IMPORT > > + * > > + * If this bit is set in &DRM_CAP_PRIME, the driver supports importing > > PRIME > > + * buffers. > > What are PRIME buffers? Will add something like: PRIME buffers are exposed as dma-buf file descriptors. See Documentation/gpu/drm-mm.rst, section "PRIME Buffer Sharing". > > + */ > > #define DRM_PRIME_CAP_IMPORT 0x1 > > +/** > > + * DRM_PRIME_CAP_EXPORT > > + * > > + * If this bit is set in &DRM_CAP_PRIME, the driver supports exporting > > PRIME > > + * buffers. > > What's the export API? HandleToFD()? Yes. Will add a note about it. Same for import. > > + */ > > #define DRM_PRIME_CAP_EXPORT 0x2 > > +/** > > + * DRM_CAP_TIMESTAMP_MONOTONIC > > + * > > + * If set to 0, the kernel will report timestamps with the realtime clock > > in > > + * struct drm_event_vblank. If set to 1, the kernel will report timestamps > > with > > + * the monotonic clock. > > I think it would be more explicit to say CLOCK_REALTIME and > CLOCK_MONOTONIC, because there are things like CLOCK_MONOTONIC_RAW > which is different. Mention clock_gettime()? Ack, better be explicit here. > > + */ > > #define DRM_CAP_TIMESTAMP_MONOTONIC0x6 > > +/** > > + * DRM_CAP_ASYNC_PAGE_FLIP > > + * > > + * If set to 1, the driver supports &DRM_MODE_PAGE_FLIP_ASYNC. > > Does this apply equally to both legacy and atomic KMS API? Yes (it's included in DRM_MODE_ATOMIC_FLAGS), but I heard that some drivers get it wrong. > > + */ > > #define DRM_CAP_ASYNC_PAGE_FLIP0x7 > > -/* > > - * The CURSOR_WIDTH and CURSOR_HEIGHT capabilities return a valid > > widthxheight > > - * combination for the hardware cursor. The intention is that a hardware > > - * agnostic userspace can query a cursor plane size to use. > > +/** > > + * DRM_CAP_CURSOR_WIDTH > > + * > > + * The ``CURSOR_WIDTH`` and ``CURSOR_HEIGHT`` capabilities return a valid > > + * width x height combination for the hardware cursor. The intention is > > that a > > + * hardware agnostic userspace can query a cursor plane size to use. > > * > > * Note that the cross-driver contract is to merely return a valid size; > > * drivers are free to attach another meaning on top, eg. i915 returns the > > * maximum plane size. > > */ > > #define DRM_CAP_CURSOR_WIDTH 0x8 > > +/** > > + * DRM_CAP_CURSOR_HEIGHT > > + * > > + * See &DRM_CAP_CURSOR_WIDTH. > > + */ > > #define DRM_CAP_CURSOR_HEIGHT 0x9 > > +/** > > + * DRM_CAP_ADDFB2_MODIFIERS > > + * > > + * If set to 1, the driver supports supplying modifiers in the > > + * &DRM_IOCTL_MODE_ADDFB2 ioctl. > > + */ > > #define DRM_CAP_ADDFB2_MODIFIERS 0x10 > > +/** > > + * DRM_CAP_PAGE_FLIP_TARGET > > + * > > + * If set to 1, the driver supports the > > &DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE and > > + * &DRM_MODE_PAGE_FLIP_TARGET_RELATIVE flags in > > + * &drm_mode_crtc_page_flip_target.flags for the &DRM_IOCTL_MODE_PAGE_FLIP > > + * ioctl. > > + */ > > #define DRM_CAP_PAGE_FLIP_TARGET 0x11 > > +/** > > + * DRM_CAP_CRTC_IN_VBLANK_EVENT > > + * > > + * If set to 1, the kernel supports reporting the CRTC ID in > > + * &drm_event_vblank.crtc_id. > > Does this not apply also to the pageflip / atomic completion event? Both DRM_EVENT_VBLANK and DRM_EVENT_FLIP_COMPLETE use the struct drm_event_vblank, so yes. I'll mention these two events explicitly. > > + */ > > #define DRM_CAP_CRTC_IN_VBLANK_EVENT 0x12 > > +/** > > + * DRM_CAP_SYNCOBJ > > + * > > + * If set to 1, the driver supports sync objects. See > > + * Documentation/gpu/drm-mm.rst, section "DRM Sync Objects". > > + */ > > #define DRM_CAP_SYNCOBJ0x13 > > +/** > > + * DRM_CAP_SYNCOBJ_TIMELINE > > + * > > + * If set to 1, the driver supports timeli
[PATCH] drm/amd/display: remove duplicate include in dcn21 and gpio
From: Zhang Yunkai 'dce110_resource.h' included in 'dcn21_resource.c' is duplicated. 'hw_gpio.h' included in 'hw_factory_dce110.c' is duplicated. Signed-off-by: Zhang Yunkai --- drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 1 - .../gpu/drm/amd/display/dc/gpio/dce110/hw_factory_dce110.c| 4 2 files changed, 5 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c index 072f8c880924..8a6a965751e8 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c +++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c @@ -61,7 +61,6 @@ #include "dcn21/dcn21_dccg.h" #include "dcn21_hubbub.h" #include "dcn10/dcn10_resource.h" -#include "dce110/dce110_resource.h" #include "dce/dce_panel_cntl.h" #include "dcn20/dcn20_dwb.h" diff --git a/drivers/gpu/drm/amd/display/dc/gpio/dce110/hw_factory_dce110.c b/drivers/gpu/drm/amd/display/dc/gpio/dce110/hw_factory_dce110.c index 66e4841f41e4..ca335ea60412 100644 --- a/drivers/gpu/drm/amd/display/dc/gpio/dce110/hw_factory_dce110.c +++ b/drivers/gpu/drm/amd/display/dc/gpio/dce110/hw_factory_dce110.c @@ -48,10 +48,6 @@ #define REGI(reg_name, block, id)\ mm ## block ## id ## _ ## reg_name -#include "../hw_gpio.h" -#include "../hw_ddc.h" -#include "../hw_hpd.h" - #include "reg_helper.h" #include "../hpd_regs.h" -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: remove duplicate include in nouveau_dmem and base
From: Zhang Yunkai 'if000c.h' included in 'nouveau_dmem.c' is duplicated. 'priv.h' included in 'base.c' is duplicated. Signed-off-by: Zhang Yunkai --- drivers/gpu/drm/nouveau/nouveau_dmem.c | 1 - drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c | 2 -- 2 files changed, 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c b/drivers/gpu/drm/nouveau/nouveau_dmem.c index 92987daa5e17..f5cc057b123b 100644 --- a/drivers/gpu/drm/nouveau/nouveau_dmem.c +++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c @@ -33,7 +33,6 @@ #include #include #include -#include #include diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c b/drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c index c39e797dc7c9..09524168431c 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c @@ -20,8 +20,6 @@ * OTHER DEALINGS IN THE SOFTWARE. */ #include "priv.h" - -#include "priv.h" #include static void * -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211033] [bisected][regression] amdgpu: *ERROR* Restoring old state failed with -12
https://bugzilla.kernel.org/show_bug.cgi?id=211033 Jan Klos (honza.k...@gmail.com) changed: What|Removed |Added CC||honza.k...@gmail.com --- Comment #17 from Jan Klos (honza.k...@gmail.com) --- I don't think this is limited just to KVMs and such. On my Vega 64 + 5.11.3-arch1 (had the same problem with 5.11.2, 5.10 etc.), sometimes, when I return to PC after a while and my 2 monitors are sleeping, only one monitor wakes up, the other one remains in sleep mode. Dmesg shows this: [bře 6 14:22] [drm] perform_link_training_with_retries: Link training attempt 1 of 4 failed [bře 6 14:23] [drm] perform_link_training_with_retries: Link training attempt 2 of 4 failed [ +0,473352] [drm] perform_link_training_with_retries: Link training attempt 3 of 4 failed [ +0,437753] [drm] enabling link 0 failed: 15 [ +0,432276] [drm] perform_link_training_with_retries: Link training attempt 1 of 4 failed [ +0,405827] [drm] perform_link_training_with_retries: Link training attempt 2 of 4 failed [ +0,476172] [drm] perform_link_training_with_retries: Link training attempt 3 of 4 failed [ +0,415466] [drm] enabling link 1 failed: 15 Switching to terminal and waiting a sec or two makes both monitors work, switching back to X11 and everything is OK. It seems to me that there might be some kind of bug where if the first link training attempt fails, the subsequent ones ALWAYS fail as well, so there is actually only a single actual link training attempt that has a chance to succeed. -- You may reply to this email to add a comment. 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 211425] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 20secs aborting
https://bugzilla.kernel.org/show_bug.cgi?id=211425 Andreas (icedragon...@web.de) changed: What|Removed |Added Kernel Version|5.11.2 |5.11.3 Severity|blocking|normal --- Comment #12 from Andreas (icedragon...@web.de) --- Back to normal regression in 5.11.3 (bisection in comment 9). Current state: until 5.10.20 - 2x errors and suspended screen for 2x20sec from 5.11.0 to 5.11.2 - freezing !!! from 5.11.3 - back to 2x errors and suspended screen for 2x20sec Error output from 5.11.3: [Sa Mär 6 17:34:08 2021] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 20secs aborting [Sa Mär 6 17:34:08 2021] [drm:amdgpu_atom_execute_table_locked] *ERROR* atombios stuck executing B228 (len 3608, WS 8, PS 0) @ 0xB376 [Sa Mär 6 17:34:08 2021] [drm:amdgpu_atom_execute_table_locked] *ERROR* atombios stuck executing B11C (len 268, WS 4, PS 0) @ 0xB16F [Sa Mär 6 17:34:08 2021] [drm:dcn10_link_encoder_enable_dp_output] *ERROR* dcn10_link_encoder_enable_dp_output: Failed to execute VBIOS command table! [Sa Mär 6 17:34:09 2021] [drm] amdgpu_dm_irq_schedule_work FAILED src 2 ... -- You may reply to this email to add a comment. 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: Is LLVM 13 (git) really ready for testing/development? libclc didn't compile
Not Marek, but hope this answer will help. libclc uses clang CLC preprocessor on .ll files, llvm/clang-13 started including clc declarations by default (clang cf3ef15a6ec5e5b45c6c54e8fbe3769255e815ce), thus corrupting any .ll assembly files that are used by libclc. Inclusion of the default declarations can be turned off using a cmdline switch but that remains to be implemented in the libclc build system. manually adding '-cl-no-stdinc' should work as a workaround. Jan On Thu, Mar 4, 2021 at 10:27 PM Dieter Nützel wrote: > Hello Marek, > > can't compile anything, here. > Poor Intel Nehalem X3470. > > Trying LLVM 12-rc2 later. > > Greetings, > Dieter > > llvm-project/libclc> cd build && cmake ../ > -- The CXX compiler identification is GNU 10.2.1 > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Check for working CXX compiler: /usr/bin/c++ - skipped > -- Detecting CXX compile features > -- Detecting CXX compile features - done > LLVM version: 13.0.0git > LLVM system libs: > LLVM libs: -lLLVM-13git > LLVM libdir: /usr/local/lib > LLVM bindir: /usr/local/bin > LLVM ld flags: -L/usr/local/lib > LLVM cxx flags: > > -I/usr/local/include;-std=c++14;;;-fno-exceptions;-D_GNU_SOURCE;-D__STDC_CONSTANT_MACROS;-D__STDC_FORMAT_MACROS;-D__STDC_LIMIT_MACROS;-fno-rtti;-fno-exceptions > > clang: /usr/local/bin/clang > llvm-as: /usr/local/bin/llvm-as > llvm-link: /usr/local/bin/llvm-link > opt: /usr/local/bin/opt > llvm-spirv: /usr/local/bin/llvm-spirv > > -- Check for working CLC compiler: /usr/local/bin/clang > -- Check for working CLC compiler: /usr/local/bin/clang -- works > -- Check for working LLAsm compiler: /usr/local/bin/llvm-as > -- Check for working LLAsm compiler: /usr/local/bin/llvm-as -- broken > CMake Error at cmake/CMakeTestLLAsmCompiler.cmake:40 (message): >The LLAsm compiler "/usr/local/bin/llvm-as" is not able to compile a > simple >test program. > >It fails with the following output: > > Change Dir: /opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp > > > >Run Build Command(s):/usr/bin/gmake cmTC_87af9/fast && /usr/bin/gmake > -f >CMakeFiles/cmTC_87af9.dir/build.make CMakeFiles/cmTC_87af9.dir/build > >gmake[1]: Verzeichnis >„/opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp“ wird betreten > >Building LLAsm object CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc > >/usr/local/bin/clang -E -P -x cl > > /opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp/testLLAsmCompiler.ll > -o >CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc.temp > >/usr/local/bin/llvm-as -o > CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc >CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc.temp > >/usr/local/bin/llvm-as: >CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc.temp:1:1: error: > expected >top-level entity > >typedef unsigned char uchar; > >^ > >gmake[1]: *** [CMakeFiles/cmTC_87af9.dir/build.make:86: >CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc] Fehler 1 > >gmake[1]: Verzeichnis >„/opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp“ wird verlassen > >gmake: *** [Makefile:140: cmTC_87af9/fast] Fehler 2 > > > > > > > >CMake will not be able to correctly generate this project. > Call Stack (most recent call first): >CMakeLists.txt:127 (enable_language) > > > -- Configuring incomplete, errors occurred! > See also "/opt/llvm-project/libclc/build/CMakeFiles/CMakeOutput.log". > See also "/opt/llvm-project/libclc/build/CMakeFiles/CMakeError.log". > > > CMakeError.log > Determining if the LLAsm compiler works failed with the following > output: > Change Dir: /opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp > > Run Build Command(s):/usr/bin/gmake cmTC_87af9/fast && /usr/bin/gmake > -f CMakeFiles/cmTC_87af9.dir/build.make CMakeFiles/cmTC_87af9.dir/build > gmake[1]: Verzeichnis > „/opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp“ wird betreten > Building LLAsm object CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc > /usr/local/bin/clang -E -P -x cl > /opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp/testLLAsmCompiler.ll > -o CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc.temp > /usr/local/bin/llvm-as -o CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc > CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc.temp > /usr/local/bin/llvm-as: > CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc.temp:1:1: error: expected > top-level entity > typedef unsigned char uchar; > ^ > gmake[1]: *** [CMakeFiles/cmTC_87af9.dir/build.make:86: > CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc] Fehler 1 > gmake[1]: Verzeichnis > „/opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp“ wird verlassen > gmake: *** [Makefile:140: cmTC_87af9/fast] Fehler 2 > ___ > 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.freede
[Bug 212077] AMD GPU discrete card memory at highest frequency even while not in use
https://bugzilla.kernel.org/show_bug.cgi?id=212077 Bat Malin (bat_ma...@abv.bg) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |PATCH_ALREADY_AVAILABLE --- Comment #3 from Bat Malin (bat_ma...@abv.bg) --- Thank you Alex! -- You may reply to this email to add a comment. 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 v2 1/9] dt-bindings: Add Jenson Display vendor prefix
On Sat, 06 Mar 2021 00:44:18 +0100, Giulio Benetti wrote: > From: Giulio Benetti > > Update Documentation/devicetree/bindings/vendor-prefixes.yaml to > include "jenson" as a vendor prefix for "Jenson Display". > Company website: http://www.jensondisplay.com/ > > Signed-off-by: Giulio Benetti > --- > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Please add Acked-by/Reviewed-by tags when posting new versions. However, there's no need to repost patches *only* to add the tags. The upstream maintainer will do that for acks received on the version they apply. If a tag was not added on purpose, please state why and what changed. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv1 1/6] rtc: m41t80: add support for protected clock
On Tue, Feb 23, 2021 at 02:26:57AM +0100, Sebastian Reichel wrote: > Hi, > > On Mon, Feb 22, 2021 at 10:26:26PM +0100, Alexandre Belloni wrote: > > On 22/02/2021 22:20:47+0100, Alexandre Belloni wrote: > > > On 22/02/2021 18:12:42+0100, Sebastian Reichel wrote: > > > > Congatec's QMX6 system on module (SoM) uses a m41t62 as RTC. The > > > > modules SQW clock output defaults to 32768 Hz. This behaviour is > > > > used to provide the i.MX6 CKIL clock. Once the RTC driver is probed, > > > > the clock is disabled and all i.MX6 functionality depending on > > > > the 32 KHz clock has undefined behaviour. On systems using hardware > > > > watchdog it seems to likely trigger a lot earlier than configured. > > > > > > > > The proper solution would be to describe this dependency in DT, > > > > but that will result in a deadlock. The kernel will see, that > > > > i.MX6 system clock needs the RTC clock and do probe deferral. > > > > But the i.MX6 I2C module never becomes usable without the i.MX6 > > > > CKIL clock and thus the RTC's clock will not be probed. So from > > > > the kernel's perspective this is a chicken-and-egg problem. > > > > > > > > > > Reading the previous paragraph, I was going to suggest describing the > > > dependency and wondering whether this would cause a circular dependency. > > > I guess this will keep being an issue for clocks on an I2C or SPI bus... > > Yes, it is a circular dependency on this particular system on > module. It only works because the RTC enables the clock by > default. The i.MX6 CKIL is expected to be always enabled. I think you should describe the circular clocking and then provide a way to break the dependency. It's a somewhat common issue. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv1 3/6] dt-bindings: vendor-prefixes: add congatec
On Mon, 22 Feb 2021 18:12:44 +0100, Sebastian Reichel wrote: > Document binding for congatec. > > Signed-off-by: Sebastian Reichel > --- > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv1 4/6] dt-bindings: arm: fsl: add GE B1x5pv2 boards
On Mon, 22 Feb 2021 18:12:45 +0100, Sebastian Reichel wrote: > Document the compatible for GE B1x5pv2 boards. > > Signed-off-by: Sebastian Reichel > --- > Documentation/devicetree/bindings/arm/fsl.yaml | 11 +++ > 1 file changed, 11 insertions(+) > Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/mediatek: dsi: Fix EoTp flag
Hi, Jitao: Jitao Shi 於 2021年2月1日 週一 上午11:36寫道： > > SoC will transmit the EoTp (End of Transmission packet) when > MIPI_DSI_MODE_EOT_PACKET flag is set. I've modified the title and message as: drm/mediatek: dsi: Use symbolized register definition For HSTX_CKLP_EN and DIS_EOT, use symbolized register definition instead of magic number. And applied to mediatek-drm-next [1], thanks. https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next Regards, Chun-Kuang. > > Signed-off-by: Jitao Shi > --- > drivers/gpu/drm/mediatek/mtk_dsi.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c > b/drivers/gpu/drm/mediatek/mtk_dsi.c > index 65fd99c528af..2bc46f2350f1 100644 > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c > @@ -401,8 +401,11 @@ static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi) > break; > } > > - tmp_reg |= (dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) << 6; > - tmp_reg |= (dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET) >> 3; > + if (dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) > + tmp_reg |= HSTX_CKLP_EN; > + > + if (!(dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET)) > + tmp_reg |= DIS_EOT; > > writel(tmp_reg, dsi->regs + DSI_TXRX_CTRL); > } > -- > 2.12.5 > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/mediatek: dsi: fine tune the line time cause by EOTp
Hi, Jitao: Jitao Shi 於 2021年2月1日 週一 上午11:36寫道： > > Enabling EoTp will make the line time larger, so the hfp and > hbp should be reduced to keep line time. Applied to mediatek-drm-next [1], thanks. [1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next Regards, Chun-Kuang. > > Signed-off-by: Jitao Shi > --- > drivers/gpu/drm/mediatek/mtk_dsi.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c > b/drivers/gpu/drm/mediatek/mtk_dsi.c > index 2bc46f2350f1..8c70ec39bfe1 100644 > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c > @@ -481,6 +481,7 @@ static void mtk_dsi_config_vdo_timing(struct mtk_dsi *dsi) > timing->da_hs_zero + timing->da_hs_exit + 3; > > delta = dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST ? 18 : 12; > + delta += dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET ? 2 : 0; > > horizontal_frontporch_byte = vm->hfront_porch * dsi_tmp_buf_bpp; > horizontal_front_back_byte = horizontal_frontporch_byte + > horizontal_backporch_byte; > -- > 2.12.5 > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/3] dt-bindings: mediatek, dpi: add mt8192 to mediatek, dpi
Hi, Jitao: Rob Herring 於 2021年2月11日 週四 上午4:19寫道： > > On Mon, 08 Feb 2021 09:42:21 +0800, Jitao Shi wrote: > > Add compatible "mediatek,mt8192-dpi" for the mt8192 dpi. > > > > Signed-off-by: Jitao Shi > > --- > > .../devicetree/bindings/display/mediatek/mediatek,dpi.yaml | 1 + > > 1 file changed, 1 insertion(+) > > > > Acked-by: Rob Herring Applied to mediatek-drm-next [1], thanks. [1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next Regards, Chun-Kuang. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm: xlnx: zynqmp_dpsub: Fix plane handling
Hello, This small patch series fixes two issues related to plane handling and blending, and add global alpha support to the overlay plane. There isn't much to say here, please refer to individual patches for details. Laurent Pinchart (3): drm: xlnx: zynqmp_dpsub: Fix plane ordering drm: xlnx: zynqmp_dpsub: Fix graphics layer blending drm: xlnx: zynqmp_dpsub: Add global alpha support drivers/gpu/drm/xlnx/zynqmp_disp.c | 22 ++ 1 file changed, 18 insertions(+), 4 deletions(-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm: xlnx: zynqmp_dpsub: Fix plane ordering
The DPSUB has a fixed plane order, with the video plane being at the
bottom and the graphics plane at the top. Register the video plane as
the primary plane, as a bottom overlay plane doesn't make sense.
While at it, add immutable zorder properties to the planes to report
this information to userspace.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 148add0ca1d6..6296f6d5acbc 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -1236,8 +1236,11 @@ static int zynqmp_disp_create_planes(struct zynqmp_disp
*disp)
for (j = 0; j < layer->info->num_formats; ++j)
drm_formats[j] = layer->info->formats[j].drm_fmt;
- /* Graphics layer is primary, and video layer is overlay. */
- type = i == ZYNQMP_DISP_LAYER_GFX
+ /*
+* The video layer is at the bottom of the stack and the
+* graphics layer at the top.
+*/
+ type = i == ZYNQMP_DISP_LAYER_VID
? DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY;
ret = drm_universal_plane_init(disp->drm, &layer->plane, 0,
&zynqmp_disp_plane_funcs,
@@ -1249,6 +1252,8 @@ static int zynqmp_disp_create_planes(struct zynqmp_disp
*disp)
drm_plane_helper_add(&layer->plane,
&zynqmp_disp_plane_helper_funcs);
+
+ drm_plane_create_zpos_immutable_property(&layer->plane, i);
}
return 0;
@@ -1573,7 +1578,7 @@ static const struct drm_crtc_funcs zynqmp_disp_crtc_funcs
= {
static int zynqmp_disp_create_crtc(struct zynqmp_disp *disp)
{
- struct drm_plane *plane = &disp->layers[ZYNQMP_DISP_LAYER_GFX].plane;
+ struct drm_plane *plane = &disp->layers[ZYNQMP_DISP_LAYER_VID].plane;
int ret;
ret = drm_crtc_init_with_planes(disp->drm, &disp->crtc, plane,
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm: xlnx: zynqmp_dpsub: Add global alpha support
The top (graphics) plane has a global alpha setting. Expose it through the plane's alpha property. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/xlnx/zynqmp_disp.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c b/drivers/gpu/drm/xlnx/zynqmp_disp.c index 4c23ffc75343..991dd6bebdc7 100644 --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c @@ -1173,7 +1173,7 @@ zynqmp_disp_plane_atomic_disable(struct drm_plane *plane, if (layer->id == ZYNQMP_DISP_LAYER_GFX) zynqmp_disp_blend_set_global_alpha(&layer->disp->blend, false, - 0); + plane->state->alpha >> 8); } static void @@ -1203,7 +1203,7 @@ zynqmp_disp_plane_atomic_update(struct drm_plane *plane, if (layer->id == ZYNQMP_DISP_LAYER_GFX) zynqmp_disp_blend_set_global_alpha(&layer->disp->blend, true, - 255); + plane->state->alpha >> 8); /* Enable or re-enable the plane is the format has changed. */ if (format_changed) @@ -1262,6 +1262,8 @@ static int zynqmp_disp_create_planes(struct zynqmp_disp *disp) &zynqmp_disp_plane_helper_funcs); drm_plane_create_zpos_immutable_property(&layer->plane, i); + if (type == DRM_PLANE_TYPE_OVERLAY) + drm_plane_create_alpha_property(&layer->plane); } return 0; -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm: xlnx: zynqmp_dpsub: Fix graphics layer blending
To display the graphics layer, the global alpha needs to be enabled. Enable it when the graphics plane is enabled (with full opacity), and disable it otherwise. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/xlnx/zynqmp_disp.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c b/drivers/gpu/drm/xlnx/zynqmp_disp.c index 6296f6d5acbc..4c23ffc75343 100644 --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c @@ -1170,6 +1170,10 @@ zynqmp_disp_plane_atomic_disable(struct drm_plane *plane, return; zynqmp_disp_layer_disable(layer); + + if (layer->id == ZYNQMP_DISP_LAYER_GFX) + zynqmp_disp_blend_set_global_alpha(&layer->disp->blend, false, + 0); } static void @@ -1197,6 +1201,10 @@ zynqmp_disp_plane_atomic_update(struct drm_plane *plane, zynqmp_disp_layer_update(layer, plane->state); + if (layer->id == ZYNQMP_DISP_LAYER_GFX) + zynqmp_disp_blend_set_global_alpha(&layer->disp->blend, true, + 255); + /* Enable or re-enable the plane is the format has changed. */ if (format_changed) zynqmp_disp_layer_enable(layer); @@ -1463,7 +1471,6 @@ zynqmp_disp_crtc_atomic_enable(struct drm_crtc *crtc, zynqmp_disp_blend_set_output_format(&disp->blend, ZYNQMP_DPSUB_FORMAT_RGB); zynqmp_disp_blend_set_bg_color(&disp->blend, 0, 0, 0); - zynqmp_disp_blend_set_global_alpha(&disp->blend, false, 0); zynqmp_disp_enable(disp); -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
