Re: [PATCH v3 2/2] drm/bridge: Add tc358768 driver
On 27.01.2020 11:56, Peter Ujfalusi wrote: > Add basic support for the Toshiba TC358768 RGB to DSI bridge. > Not all the features of the TC358768 is implemented by the initial driver: > MIPI_DSI_MODE_VIDEO and MIPI_DSI_FMT_RGB888 is only supported and tested. > > Only write is implemented for mipi_dsi_host_ops.transfer. > > Signed-off-by: Peter Ujfalusi > --- > drivers/gpu/drm/bridge/Kconfig| 10 + > drivers/gpu/drm/bridge/Makefile |1 + > drivers/gpu/drm/bridge/tc358768.c | 1040 + > 3 files changed, 1051 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/tc358768.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index 0b9ca5862455..3fef3513bdd0 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -122,6 +122,16 @@ config DRM_TOSHIBA_TC358767 > ---help--- > Toshiba TC358767 eDP bridge chip driver. > > +config DRM_TOSHIBA_TC358768 > + tristate "Toshiba TC358768 MIPI DSI bridge" > + depends on OF > + select DRM_KMS_HELPER > + select REGMAP_I2C > + select DRM_PANEL > + select DRM_MIPI_DSI > + help > + Toshiba TC358768AXBG/TC358778XBG DSI bridge chip driver. > + > config DRM_TI_TFP410 > tristate "TI TFP410 DVI/HDMI bridge" > depends on OF > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index cd16ce830270..06fc265de0ef 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -11,6 +11,7 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o > obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o > obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o > obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o > +obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o > obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ > obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o > obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o > diff --git a/drivers/gpu/drm/bridge/tc358768.c > b/drivers/gpu/drm/bridge/tc358768.c > new file mode 100644 > index ..244309c1112e > --- /dev/null > +++ b/drivers/gpu/drm/bridge/tc358768.c > @@ -0,0 +1,1040 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com > + * Author: Peter Ujfalusi > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* Global (16-bit addressable) */ > +#define TC358768_CHIPID 0x > +#define TC358768_SYSCTL 0x0002 > +#define TC358768_CONFCTL 0x0004 > +#define TC358768_VSDLY 0x0006 > +#define TC358768_DATAFMT 0x0008 > +#define TC358768_GPIOEN 0x000E > +#define TC358768_GPIODIR 0x0010 > +#define TC358768_GPIOIN 0x0012 > +#define TC358768_GPIOOUT 0x0014 > +#define TC358768_PLLCTL0 0x0016 > +#define TC358768_PLLCTL1 0x0018 > +#define TC358768_CMDBYTE 0x0022 > +#define TC358768_PP_MISC 0x0032 > +#define TC358768_DSITX_DT0x0050 > +#define TC358768_FIFOSTATUS 0x00F8 > + > +/* Debug (16-bit addressable) */ > +#define TC358768_VBUFCTRL0x00E0 > +#define TC358768_DBG_WIDTH 0x00E2 > +#define TC358768_DBG_VBLANK 0x00E4 > +#define TC358768_DBG_DATA0x00E8 > + > +/* TX PHY (32-bit addressable) */ > +#define TC358768_CLW_DPHYCONTTX 0x0100 > +#define TC358768_D0W_DPHYCONTTX 0x0104 > +#define TC358768_D1W_DPHYCONTTX 0x0108 > +#define TC358768_D2W_DPHYCONTTX 0x010C > +#define TC358768_D3W_DPHYCONTTX 0x0110 > +#define TC358768_CLW_CNTRL 0x0140 > +#define TC358768_D0W_CNTRL 0x0144 > +#define TC358768_D1W_CNTRL 0x0148 > +#define TC358768_D2W_CNTRL 0x014C > +#define TC358768_D3W_CNTRL 0x0150 > + > +/* TX PPI (32-bit addressable) */ > +#define TC358768_STARTCNTRL 0x0204 > +#define TC358768_DSITXSTATUS 0x0208 > +#define TC358768_LINEINITCNT 0x0210 > +#define TC358768_LPTXTIMECNT 0x0214 > +#define TC358768_TCLK_HEADERCNT 0x0218 > +#define TC358768_TCLK_TRAILCNT 0x021C > +#define TC358768_THS_HEADERCNT 0x0220 > +#define TC358768_TWAKEUP 0x0224 > +#define TC358768_TCLK_POSTCNT0x0228 > +#define TC358768_THS_TRAILCNT0x022C > +#define TC358768_HSTXVREGCNT 0x0230 > +#define TC358768_HSTXVREGEN 0x0234 > +#define TC358768_TXOPTIONCNTRL 0x0238 > +#define TC358768_BTACNTRL1 0x023C > + > +/* TX CTRL (32-bit addressable) */ > +#define TC358768_DSI_CONTROL 0x040C > +#define TC358768_DSI_ST
[PATCH libdrm 1/2] xf86drm: generalize the device subsystem type parsing code
From: Vasyl Vavrychuk
Move the code, which used to get the device subsystem type from a device
path in sysfs, to a separate function to be reusable.
Signed-off-by: Vasyl Vavrychuk
Signed-off-by: Mikhail Golubev
---
xf86drm.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 7ae41c37..b1479128 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2964,10 +2964,10 @@ sysfs_uevent_get(const char *path, const char *fmt, ...)
/* Little white lie to avoid major rework of the existing code */
#define DRM_BUS_VIRTIO 0x10
-static int drmParseSubsystemType(int maj, int min)
-{
#ifdef __linux__
-char path[PATH_MAX + 1];
+static int get_subsystem_type(const char *device_path)
+{
+char path[PATH_MAX + 1] = "";
char link[PATH_MAX + 1] = "";
char *name;
struct {
@@ -2982,8 +2982,8 @@ static int drmParseSubsystemType(int maj, int min)
{ "/virtio", DRM_BUS_VIRTIO },
};
-snprintf(path, PATH_MAX, "/sys/dev/char/%d:%d/device/subsystem",
- maj, min);
+strncpy(path, device_path, PATH_MAX);
+strncat(path, "/subsystem", PATH_MAX);
if (readlink(path, link, PATH_MAX) < 0)
return -errno;
@@ -2998,6 +2998,17 @@ static int drmParseSubsystemType(int maj, int min)
}
return -EINVAL;
+}
+#endif
+
+static int drmParseSubsystemType(int maj, int min)
+{
+#ifdef __linux__
+char path[PATH_MAX + 1] = "";
+
+snprintf(path, PATH_MAX, "/sys/dev/char/%d:%d/device", maj, min);
+
+return get_subsystem_type(path);
#elif defined(__OpenBSD__) || defined(__DragonFly__)
return DRM_BUS_PCI;
#else
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm 2/2] xf86drm: fix subsystem type lookup for virtio mmio-based devices
From: Vasyl Vavrychuk
Currently the code assumes that a virtio based device is always located
on the PCI bus.
Modify the parser to make it check the device's parent directory to
determine on which bus it is located.
Output for virtio-pci is the PCI bus.
Output for virtio-mmio is the Platform bus.
Signed-off-by: Vasyl Vavrychuk
Signed-off-by: Mikhail Golubev
---
xf86drm.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index b1479128..1b22efe4 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -3005,10 +3005,20 @@ static int drmParseSubsystemType(int maj, int min)
{
#ifdef __linux__
char path[PATH_MAX + 1] = "";
+char real_path[PATH_MAX + 1] = "";
+int subsystem_type;
snprintf(path, PATH_MAX, "/sys/dev/char/%d:%d/device", maj, min);
+if (!realpath(path, real_path))
+return -errno;
+strncpy(path, real_path, PATH_MAX);
-return get_subsystem_type(path);
+subsystem_type = get_subsystem_type(path);
+if (subsystem_type == DRM_BUS_VIRTIO) {
+strncat(path, "/..", PATH_MAX);
+subsystem_type = get_subsystem_type(path);
+}
+return subsystem_type;
#elif defined(__OpenBSD__) || defined(__DragonFly__)
return DRM_BUS_PCI;
#else
@@ -3710,7 +3720,6 @@ process_device(drmDevicePtr *device, const char *d_name,
switch (subsystem_type) {
case DRM_BUS_PCI:
-case DRM_BUS_VIRTIO:
return drmProcessPciDevice(device, node, node_type, maj, min,
fetch_deviceinfo, flags);
case DRM_BUS_USB:
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu: Fix implicit enum conversion in gfx_v9_4_ras_error_inject
Clang warns:
../drivers/gpu/drm/amd/amdgpu/gfx_v9_4.c:967:35: warning: implicit
conversion from enumeration type 'enum amdgpu_ras_block' to different
enumeration type 'enum ta_ras_block' [-Wenum-conversion]
block_info.block_id = info->head.block;
~ ~~~^
1 warning generated.
Use the function added in commit 828cfa29093f ("drm/amdgpu: Fix amdgpu
ras to ta enums conversion") that handles this conversion explicitly.
Fixes: 4c461d89db4f ("drm/amdgpu: add RAS support for the gfx block of
Arcturus")
Link: https://github.com/ClangBuiltLinux/linux/issues/849
Signed-off-by: Nathan Chancellor
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_4.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_4.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_4.c
index e19d275f3f7d..f099f13d7f1e 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_4.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_4.c
@@ -964,7 +964,7 @@ int gfx_v9_4_ras_error_inject(struct amdgpu_device *adev,
void *inject_if)
if (!amdgpu_ras_is_supported(adev, AMDGPU_RAS_BLOCK__GFX))
return -EINVAL;
- block_info.block_id = info->head.block;
+ block_info.block_id = amdgpu_ras_block_to_ta(info->head.block);
block_info.sub_block_index = info->head.sub_block_index;
block_info.inject_error_type = amdgpu_ras_error_to_ta(info->head.type);
block_info.address = info->address;
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm RESEND 2/2] xf86drm: fix subsystem type lookup for virtio mmio-based devices
From: Vasyl Vavrychuk
Currently the code assumes that a virtio based device is always located
on the PCI bus.
Modify the parser to make it check the device's parent directory to
determine on which bus it is located.
Output for virtio-pci is the PCI bus.
Output for virtio-mmio is the Platform bus.
Signed-off-by: Vasyl Vavrychuk
Signed-off-by: Mikhail Golubev
---
xf86drm.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index b1479128..1b22efe4 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -3005,10 +3005,20 @@ static int drmParseSubsystemType(int maj, int min)
{
#ifdef __linux__
char path[PATH_MAX + 1] = "";
+char real_path[PATH_MAX + 1] = "";
+int subsystem_type;
snprintf(path, PATH_MAX, "/sys/dev/char/%d:%d/device", maj, min);
+if (!realpath(path, real_path))
+return -errno;
+strncpy(path, real_path, PATH_MAX);
-return get_subsystem_type(path);
+subsystem_type = get_subsystem_type(path);
+if (subsystem_type == DRM_BUS_VIRTIO) {
+strncat(path, "/..", PATH_MAX);
+subsystem_type = get_subsystem_type(path);
+}
+return subsystem_type;
#elif defined(__OpenBSD__) || defined(__DragonFly__)
return DRM_BUS_PCI;
#else
@@ -3710,7 +3720,6 @@ process_device(drmDevicePtr *device, const char *d_name,
switch (subsystem_type) {
case DRM_BUS_PCI:
-case DRM_BUS_VIRTIO:
return drmProcessPciDevice(device, node, node_type, maj, min,
fetch_deviceinfo, flags);
case DRM_BUS_USB:
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Regression 5.5-rc1] Extremely low GPU performance on NVIDIA Tegra20/30
29.01.2020 15:39, Thierry Reding пишет: > On Mon, Jan 20, 2020 at 05:53:03AM +0300, Dmitry Osipenko wrote: >> 13.12.2019 18:35, Dmitry Osipenko пишет: ... >> Hello Thierry, >> >> I took another look at the problem and here what was found: >> >> 1) The "Optionally attach clients to the IOMMU" patch is wrong because: >> >> 1. host1x_drm_probe() is invoked *before* any of the >>host1x_client_iommu_attach() happens, so there is no way >>on earth the 'use_explicit_iommu' could ever be true. > > That's not correct. host1x_client_iommu_attach() happens during > host1x_device_init(), which is called during host1x_drm_probe(). Looks like I previously got confused by accident, my bad. > The idea is that host1x_drm_probe() sets up the minimum IOMMU so that all > devices can attach, if they want to. If any of them connect (because > they aren't already attached via something like the DMA/IOMMU glue) > then the tegra->use_explicit_iommu is set to true, in which case the > IOMMU domain setup for explicit IOMMU API usage is completed. If, on > the other hand, none of the clients have a need for the explicit IOMMU > domain, there's no need to set it up and host1x_drm_probe() will just > discard it. This matches my understanding of what you wanted to achieve, thanks. >> 2. Not attaching DRM clients to IOMMU if HOST1x isn't >>attached is wrong because it never attached in the case >>of CONFIG_TEGRA_HOST1X_FIREWALL=y [1] and this also >>makes no sense for T20/30 that do not support LPAE. > > It's not at all wrong. Take for example the case of Tegra124 and > Tegra210 where host1x and its clients can address 34 bits. In those > cases, allocating individual pages via shmem has a high probability of > hitting physical addresses beyond the 32-bit range, which means that the > host1x can not access them unless it is also attached to an IOMMU where > physical addresses to >= 4 GiB addresses can be translated into < 4 GiB > virtual addresses. This is a very real problem that I was running into > when testing on Tegra124 and Tegra210. Why not to set the DMA mask to 32bits if IOMMU is unavailable? I'm a bit puzzled by the actual need to support the case where Host1x is backed by IOMMU and clients not.. How we could ever end up with this scenario in the upstream kernel? What about the reverse scenario? You won't be able to patch cmdstream properly for >32bit addresses. The root of the problem is that Tegra DRM UAPI doesn't support 64bit addresses, so you can't use "wide" opcodes and can't patch cmdstream. Perhaps it is better not to add any new things or quirks to the Host1x / Tegra DRM for now. The drivers need a serious clean up, otherwise mess only continues to grow up. Don't you think so? > But I agree that this shouldn't be necessary on Tegra20 and Tegra30. We > should be able to remedy the situation on Tegra20 and Tegra30 by adding > another check, based on the DMA mask. Something like the below should > work: > > --- >8 --- [snip] > --- >8 --- This works, thanks. >> [1] >> https://elixir.bootlin.com/linux/v5.5-rc6/source/drivers/gpu/host1x/dev.c#L205 >> >> 2) Because of the above problems, the DRM clients are erroneously not >> getting attached to IOMMU at all and thus CMA is getting used for the BO >> allocations. Here comes the problems introduced by the "gpu: host1x: >> Support DMA mapping of buffers" patch, which makes DMA API to perform >> CPU cache maintenance on each job submission and apparently this is >> super bad for performance. This also makes no sense in comparison to the >> case of enabled IOMMU, where cache maintenance isn't performed at all >> (like it should be). > > It actually does make a lot of sense. Very strictly speaking we were > violating the DMA API prior to the above patch because we were not DMA > mapping the buffers at all. Whenever you pass a buffer to hardware you > need to map it for the device. At that point, the kernel does not know > whether or not the buffer is dirty, so it has to perform a cache flush. > Similarily, when the hardware is done with a buffer, we need to unmap it > so that the CPU can access it again. This typically requires a cache > invalidate. > > That things even worked to begin with more by accident than by design. > > So yes, this is different from what we were doing before, but it's > actually the right thing to do. That said, I'm sure we can find ways to > optimize this. For example, as part of the DMA API conversion series I > added the possibility to set direction flags for relocation buffers. In > cases where it is known that a certain buffer will only be used for > reading, we should be able to avoid at least the cache invalidate > operation after a job is done, since the hardware won't have modified > the contents (when using an SMMU this can even be enforced). It's > slightly trickier to avoid cache flushes. For buffers that are only > going to be written, there's no need to flush the cache because t
Re: [PATCH v3 1/1] drm: sun4i: hdmi: Add support for sun4i HDMI encoder audio
Hi,
On Tue, Jan 28, 2020 at 04:06:42PM +0200, Stefan Mavrodiev wrote:
> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> index 68d4644ac2dc..4cd35c97c503 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> @@ -23,6 +23,8 @@
> #include
> #include
>
> +#include
> +
> #include "sun4i_backend.h"
> #include "sun4i_crtc.h"
> #include "sun4i_drv.h"
> @@ -87,6 +89,10 @@ static void sun4i_hdmi_disable(struct drm_encoder *encoder)
>
> DRM_DEBUG_DRIVER("Disabling the HDMI Output\n");
>
> +#ifdef CONFIG_DRM_SUN4I_HDMI_AUDIO
> + sun4i_hdmi_audio_destroy(hdmi);
> +#endif
> +
> val = readl(hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
> val &= ~SUN4I_HDMI_VID_CTRL_ENABLE;
> writel(val, hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
> @@ -114,6 +120,11 @@ static void sun4i_hdmi_enable(struct drm_encoder
> *encoder)
> val |= SUN4I_HDMI_VID_CTRL_HDMI_MODE;
>
> writel(val, hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
> +
> +#ifdef CONFIG_DRM_SUN4I_HDMI_AUDIO
> + if (hdmi->hdmi_audio && sun4i_hdmi_audio_create(hdmi))
> + DRM_ERROR("Couldn't create the HDMI audio adapter\n");
> +#endif
I really don't think we should be creating / removing the audio card
at enable / disable time.
To fix the drvdata pointer, you just need to use the card pointer in
the unbind, and that's it.
Maxime
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KASAN: slab-out-of-bounds Write in vgacon_scroll
A fbcon bug found that allocation size was wrong. https://groups.google.com/d/msg/syzkaller-bugs/TVGAFDeUKJo/uchTlvbFAQAJ You can try adding printk() for examining values because you have reproducers. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
memory leak in snd_pcm_hw_params
Hello, syzbot found the following crash on: HEAD commit:b3a60822 Merge branch 'for-v5.6' of git://git.kernel.org:/.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1351cf66e0 kernel config: https://syzkaller.appspot.com/x/.config?x=e97a1bc78afb77f dashboard link: https://syzkaller.appspot.com/bug?extid=30edd0f34bfcdc548ac4 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14e97735e0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13cd9bc9e0 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+30edd0f34bfcdc548...@syzkaller.appspotmail.com executing program executing program executing program BUG: memory leak unreferenced object 0x888108fdefc0 (size 64): comm "syz-executor222", pid 7310, jiffies 4294946025 (age 13.660s) hex dump (first 32 bytes): 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 33 02 00 c9 ff ff 00 00 00 00 00 00 00 00 ..3. backtrace: [] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline] [ ] slab_post_alloc_hook mm/slab.h:586 [inline] [ ] slab_alloc mm/slab.c:3320 [inline] [ ] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3549 [<478172ce>] kmalloc include/linux/slab.h:556 [inline] [<478172ce>] kzalloc include/linux/slab.h:670 [inline] [<478172ce>] snd_pcm_lib_malloc_pages+0x12b/0x200 sound/core/pcm_memory.c:404 [<91532e16>] snd_pcm_hw_params+0x720/0x830 sound/core/pcm_native.c:691 [<2070a986>] snd_pcm_kernel_ioctl+0xb5/0x170 sound/core/pcm_native.c:3238 [<394e99f4>] snd_pcm_oss_change_params_locked+0x745/0x1140 sound/core/oss/pcm_oss.c:944 [ ] snd_pcm_oss_change_params+0x43/0x80 sound/core/oss/pcm_oss.c:1087 [<7710a1c0>] snd_pcm_oss_make_ready+0x55/0xc0 sound/core/oss/pcm_oss.c:1146 [<69305204>] snd_pcm_oss_sync.isra.0+0xb8/0x310 sound/core/oss/pcm_oss.c:1707 [<692460c8>] snd_pcm_oss_release+0xef/0x100 sound/core/oss/pcm_oss.c:2545 [<13ba02c9>] __fput+0xed/0x300 fs/file_table.c:280 [<80810f18>] fput+0x16/0x20 fs/file_table.c:313 [ ] task_work_run+0x9d/0xc0 kernel/task_work.c:113 [ ] exit_task_work include/linux/task_work.h:22 [inline] [ ] do_exit+0x3fa/0xe20 kernel/exit.c:801 [<45ce7ad3>] do_group_exit+0x4b/0xe0 kernel/exit.c:899 [ ] __do_sys_exit_group kernel/exit.c:910 [inline] [ ] __se_sys_exit_group kernel/exit.c:908 [inline] [ ] __x64_sys_exit_group+0x1c/0x20 kernel/exit.c:908 [<8b12db16>] do_syscall_64+0x73/0x220 arch/x86/entry/common.c:294 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm RESEND 1/2] xf86drm: generalize the device subsystem type parsing code
From: Vasyl Vavrychuk
Move the code, which used to get the device subsystem type from a device
path in sysfs, to a separate function to be reusable.
Signed-off-by: Vasyl Vavrychuk
Signed-off-by: Mikhail Golubev
---
xf86drm.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 7ae41c37..b1479128 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2964,10 +2964,10 @@ sysfs_uevent_get(const char *path, const char *fmt, ...)
/* Little white lie to avoid major rework of the existing code */
#define DRM_BUS_VIRTIO 0x10
-static int drmParseSubsystemType(int maj, int min)
-{
#ifdef __linux__
-char path[PATH_MAX + 1];
+static int get_subsystem_type(const char *device_path)
+{
+char path[PATH_MAX + 1] = "";
char link[PATH_MAX + 1] = "";
char *name;
struct {
@@ -2982,8 +2982,8 @@ static int drmParseSubsystemType(int maj, int min)
{ "/virtio", DRM_BUS_VIRTIO },
};
-snprintf(path, PATH_MAX, "/sys/dev/char/%d:%d/device/subsystem",
- maj, min);
+strncpy(path, device_path, PATH_MAX);
+strncat(path, "/subsystem", PATH_MAX);
if (readlink(path, link, PATH_MAX) < 0)
return -errno;
@@ -2998,6 +2998,17 @@ static int drmParseSubsystemType(int maj, int min)
}
return -EINVAL;
+}
+#endif
+
+static int drmParseSubsystemType(int maj, int min)
+{
+#ifdef __linux__
+char path[PATH_MAX + 1] = "";
+
+snprintf(path, PATH_MAX, "/sys/dev/char/%d:%d/device", maj, min);
+
+return get_subsystem_type(path);
#elif defined(__OpenBSD__) || defined(__DragonFly__)
return DRM_BUS_PCI;
#else
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/1] drm: sun4i: hdmi: Add support for sun4i HDMI encoder audio
Hi,
On 1/29/20 6:43 PM, Maxime Ripard wrote:
Hi,
On Tue, Jan 28, 2020 at 04:06:42PM +0200, Stefan Mavrodiev wrote:
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 68d4644ac2dc..4cd35c97c503 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -23,6 +23,8 @@
#include
#include
+#include
+
#include "sun4i_backend.h"
#include "sun4i_crtc.h"
#include "sun4i_drv.h"
@@ -87,6 +89,10 @@ static void sun4i_hdmi_disable(struct drm_encoder *encoder)
DRM_DEBUG_DRIVER("Disabling the HDMI Output\n");
+#ifdef CONFIG_DRM_SUN4I_HDMI_AUDIO
+ sun4i_hdmi_audio_destroy(hdmi);
+#endif
+
val = readl(hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
val &= ~SUN4I_HDMI_VID_CTRL_ENABLE;
writel(val, hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
@@ -114,6 +120,11 @@ static void sun4i_hdmi_enable(struct drm_encoder *encoder)
val |= SUN4I_HDMI_VID_CTRL_HDMI_MODE;
writel(val, hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
+
+#ifdef CONFIG_DRM_SUN4I_HDMI_AUDIO
+ if (hdmi->hdmi_audio && sun4i_hdmi_audio_create(hdmi))
+ DRM_ERROR("Couldn't create the HDMI audio adapter\n");
+#endif
I really don't think we should be creating / removing the audio card
at enable / disable time.
For me it's unnatural to have sound card all the time, even when the HDMI
is not plugged-in.
I'll follow your suggestion. Besides it's easier for me just to drop this
register/unregister mechanism.
Best regards,
Stefan Mavrodiev
To fix the drvdata pointer, you just need to use the card pointer in
the unbind, and that's it.
Maxime
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] dt-bindings: one file of all simple DSI panels
Le mer. 29 janv. 2020 à 20:47, Sam Ravnborg a écrit : > > Hi Benjamin. > > > > > > > > Here's the problem. If it is not required, then panels with multiple > > > > supplies will get added here because they didn't care to begin with. > > > > Then when someone decides to think about the supplies it will have to > > > > be moved. Bindings need to be complete from the start. > > > > > > Fair enough, I will add fixed supply in dts files. > > > If reset-gpios could be added in this schema then we could include > > > oristech panel here. > > > > Does this patch has been merged ? > > I was sidetracked by other things. > Maybe you can move it forward? Yes I will send a v3. Benjamin > > Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv5 00/34] Add AFBC support for Rockchip
Hi All, A gentle reminder. Please also see inline: W dniu 17.12.2019 o 15:49, Andrzej Pietrasiewicz pisze: This series adds AFBC support for Rockchip. It is inspired by: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/factory-gru-9017.B-chromeos-4.4/drivers/gpu/drm/rockchip/rockchip_drm_vop.c This is the fifth iteration of the afbc series. Between v3 and v4 a lot of rework has been done, the main goal of which was to move all afbc-related checks to helpers, so that core does not deal with it. A new struct drm_afbc_framebuffer is added, which stores afbc-related driver-specific data. Because of that, in drivers that wish to use this feature, the struct must be allocated directly in the driver code rather than inside helpers, so the first portion of the patchset does the necessary refactoring. Then, there are 3 users of afbc: komeda, malidp and, finally, rockchip, the latter being the ultimate purpose of this work and the 3 subsequent portions of the patchset move komeda and malidp to generic helpers and add afbc support to rockchip. If changes in komeda and malidp is too much to digest at a time I can focus on rockchip only. This would amount to patches 1-4 and 33-34. After all the ultimate purpose of this work and time spent on it is landing afbc support for rockchip. Regards, Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206351] New: RX 5600 XT Not Correctly Recognized, Max Memory Frequency Below Where it Should Be
https://bugzilla.kernel.org/show_bug.cgi?id=206351 Bug ID: 206351 Summary: RX 5600 XT Not Correctly Recognized, Max Memory Frequency Below Where it Should Be Product: Drivers Version: 2.5 Kernel Version: 5.5.0, 5.4.14 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: gardotd...@gmail.com Regression: No Created attachment 287033 --> https://bugzilla.kernel.org/attachment.cgi?id=287033&action=edit glxinfo output NOTE: I hope DRI- non-intel is the correct component for this bug. I wasn't sure whether to file it under that, or under console/framebuffers My 5600 XT is not correctly recognized as such by my Arch Linux system. Some applications and system utilities report it as "UNKNOWN AMD GPU," Some report it just as "RADV/NAVI10 GPU," "AMD NAVI10" by glxinfo, and others, such as inxi, report it as a "RADEON RX 5700 / 5700 XT." This occurs regardless of vBIOS version, on both performance and silent vBIOS, also on both the original vBIOS and the "upgraded" one AMD pushed out right before launch. Also, the max memory frequency on this card is supposed to be 1500MHz, which it shows in Windows, but on Linux the memory range is shown as 625-930MHz (and that's with amdgpu.ppfeaturemask set). There are also multiple rendering issues, but I've filed a report with mesa for those. I know there's supposed to be a new firmware release that's supposed to fix the performance issues with the new vBIOS, but this isn't a performance issue, and it's present even with the original vBIOS (that had no reported performance issues). It seems this is a matter of the 5600 XT's compatibility not properly being built into the kernel yet (which is to be expected since it's so new). However I will say that with my 3200G Ryzen processor that I got within a month of it's launch, it was properly recognized and it's frequency limits were also properly recognized and implemented. inxi -Gxxz: Graphics: Device-1: AMD Navi 10 [Radeon RX 5700 / 5700 XT] vendor: Sapphire Limited driver: amdgpu v: kernel bus ID: 09:00.0 chip ID: 1002:731f Display: x11 server: X.Org 1.20.7 driver: amdgpu compositor: kwin_x11 resolution: 1366x768~60Hz, 1920x1080~60Hz OpenGL: renderer: AMD NAVI10 (DRM 3.36.0 5.5.0-3-tkg-pds LLVM 9.0.1) v: 4.6 Mesa 20.0.0-devel (git-6e1411c9e8) direct render: Yes sudo cat /sys/class/drm/card0/device/pp_od_clk_voltage: OD_SCLK: 0: 800Mhz 1: 1780Mhz OD_MCLK: 1: 900MHz OD_VDDC_CURVE: 0: 800MHz @ 0mV 1: 1290MHz @ 0mV 2: 1780MHz @ 0mV OD_RANGE: SCLK: 800Mhz 1820Mhz MCLK: 625Mhz930Mhz VDDC_CURVE_SCLK[0]: 800Mhz 1820Mhz VDDC_CURVE_VOLT[0]: 800mV1050mV VDDC_CURVE_SCLK[1]: 800Mhz 1820Mhz VDDC_CURVE_VOLT[1]: 800mV1050mV VDDC_CURVE_SCLK[2]: 800Mhz 1820Mhz VDDC_CURVE_VOLT[2]: 800mV1050mV vulkaninfo | grep -i "AMD GPU": GPU id : 0 (Unknown AMD GPU) GPU id : 1 (Unknown AMD GPU) GPU id : 0 (Unknown AMD GPU) GPU id : 1 (Unknown AMD GPU) GPU id : 0 (Unknown AMD GPU) GPU id : 1 (Unknown AMD GPU) GPU id : 0 (Unknown AMD GPU) GPU id : 1 (Unknown AMD GPU) GPU id : 0 (Unknown AMD GPU) GPU id : 1 (Unknown AMD GPU) GPU id : 0 (Unknown AMD GPU) GPU id : 1 (Unknown AMD GPU) GPU id : 0 (Unknown AMD GPU) GPU id : 1 (Unknown AMD GPU) GPU id : 0 (Unknown AMD GPU) GPU id : 1 (Unknown AMD GPU) GPU id : 0 (Unknown AMD GPU) GPU id : 1 (Unknown AMD GPU) GPU id : 0 (Unknown AMD GPU) GPU id : 1 (Unknown AMD GPU) GPU id : 0 (Unknown AMD GPU) GPU id : 1 (Unknown AMD GPU) GPU id : 0 (Unknown AMD GPU) GPU id : 1 (Unknown AMD GPU) GPU id : 0 (Unknown AMD GPU) GPU id : 1 (Unknown AMD GPU) GPU id : 0 (Unknown AMD GPU): GPU id : 1 (Unknown AMD GPU): GPU id : 0 (Unknown AMD GPU): GPU id : 1 (Unknown AMD GPU): Unknown AMD GPU (ID: 0) Unknown AMD GPU (ID: 0) Unknown AMD GPU (ID: 0) Unknown AMD GPU (ID: 0) Unknown AMD GPU (ID: 0) Unknown AMD GPU (ID: 0) deviceName = Unknown AMD GPU deviceName = Unknown AMD GPU sudo pacman -Q linux-firmware: linux-firmware 20191220.6871bff-1 Kernels: issue persists across at least 5 different kernels. linux-zen-5.4.14, linux-fsync-5.4.14, linux-5.4.14,
[Bug 206351] RX 5600 XT Not Correctly Recognized, Max Memory Frequency Below Where it Should Be
https://bugzilla.kernel.org/show_bug.cgi?id=206351 --- Comment #1 from Matt McDonald (gardotd...@gmail.com) --- Actually, the new vBIOS memory clock should be 1750MHz, not 1500. Either way it's far to low on Linux, and this was not an issue with the Polaris cards, they correctly set memory frequencies in line with the vBIOS. -- 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
[PATCH v2] drm/ast: Allocate initial CRTC state of the correct size
The ast driver inherits from DRM's CRTC state, but still uses the atomic
helper for struct drm_crtc_funcs.reset, drm_atomic_helper_crtc_reset().
The helper only allocates enough memory for the core CRTC state. That
results in an out-ouf-bounds access when duplicating the initial CRTC
state. Simplified backtrace shown below:
[ 21.469321]
==
[ 21.469434] BUG: KASAN: slab-out-of-bounds in
ast_crtc_atomic_duplicate_state+0x84/0x100 [ast]
[ 21.469445] Read of size 8 at addr 888036c1c5f8 by task systemd-udevd/382
[ 21.469451]
[ 21.469464] CPU: 2 PID: 382 Comm: systemd-udevd Tainted: GE
5.5.0-rc6-1-default+ #214
[ 21.469473] Hardware name: Sun Microsystems SUN FIRE X2270 M2/SUN FIRE X2270
M2, BIOS 2.0507/01/2010
[ 21.469480] Call Trace:
[ 21.469501] dump_stack+0xb8/0x110
[ 21.469528] print_address_description.constprop.0+0x1b/0x1e0
[ 21.469557] ? ast_crtc_atomic_duplicate_state+0x84/0x100 [ast]
[ 21.469581] ? ast_crtc_atomic_duplicate_state+0x84/0x100 [ast]
[ 21.469597] __kasan_report.cold+0x1a/0x35
[ 21.469640] ? ast_crtc_atomic_duplicate_state+0x84/0x100 [ast]
[ 21.469665] kasan_report+0xe/0x20
[ 21.469693] ast_crtc_atomic_duplicate_state+0x84/0x100 [ast]
[ 21.469733] drm_atomic_get_crtc_state+0xbf/0x1c0
[ 21.469768] __drm_atomic_helper_set_config+0x81/0x5a0
[ 21.469803] ? drm_atomic_plane_check+0x690/0x690
[ 21.469843] ? drm_client_rotation+0xae/0x240
[ 21.469876] drm_client_modeset_commit_atomic+0x230/0x390
[ 21.469888] ? __mutex_lock+0x8f0/0xbe0
[ 21.469929] ? drm_client_firmware_config.isra.0+0xa60/0xa60
[ 21.469948] ? drm_client_modeset_commit_force+0x28/0x230
[ 21.470031] ? memset+0x20/0x40
[ 21.470078] drm_client_modeset_commit_force+0x90/0x230
[ 21.470110] drm_fb_helper_restore_fbdev_mode_unlocked+0x5f/0xc0
[ 21.470132] drm_fb_helper_set_par+0x59/0x70
[ 21.470155] fbcon_init+0x61d/0xad0
[ 21.470185] ? drm_fb_helper_restore_fbdev_mode_unlocked+0xc0/0xc0
[ 21.470232] visual_init+0x187/0x240
[ 21.470266] do_bind_con_driver+0x2e3/0x460
[ 21.470321] do_take_over_console+0x20a/0x290
[ 21.470371] do_fbcon_takeover+0x85/0x100
[ 21.470402] register_framebuffer+0x2fd/0x490
[ 21.470425] ? kzalloc.constprop.0+0x10/0x10
[ 21.470503] __drm_fb_helper_initial_config_and_unlock+0xf2/0x140
[ 21.470533] drm_fbdev_client_hotplug+0x162/0x250
[ 21.470563] drm_fbdev_generic_setup+0xd2/0x155
[ 21.470602] ast_driver_load+0x688/0x850 [ast]
<...>
[ 21.472625]
==
Allocating enough memory for struct ast_crtc_state in a custom ast CRTC
reset handler fixes the problem.
v2:
* implement according to drm_atomic_helper_crtc_reset()
* update state with __drm_atomic_helper_crtc_reset()
Signed-off-by: Thomas Zimmermann
Fixes: 83be6a3ceb11 ("drm/ast: Introduce struct ast_crtc_state")
Reviewed-by: Daniel Vetter
Cc: Gerd Hoffmann
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Alex Deucher
Cc: "Noralf Trønnes"
Cc: Sam Ravnborg
Cc: Laurent Pinchart
---
drivers/gpu/drm/ast/ast_mode.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 34608f0499eb..6e71cc797109 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -882,6 +882,17 @@ static const struct drm_crtc_helper_funcs
ast_crtc_helper_funcs = {
.atomic_disable = ast_crtc_helper_atomic_disable,
};
+static void ast_crtc_reset(struct drm_crtc *crtc)
+{
+ struct ast_crtc_state *ast_state =
+ kzalloc(sizeof(*ast_state), GFP_KERNEL);
+
+ if (crtc->state)
+ crtc->funcs->atomic_destroy_state(crtc, crtc->state);
+
+ __drm_atomic_helper_crtc_reset(crtc, &ast_state->base);
+}
+
static void ast_crtc_destroy(struct drm_crtc *crtc)
{
drm_crtc_cleanup(crtc);
@@ -920,7 +931,7 @@ static void ast_crtc_atomic_destroy_state(struct drm_crtc
*crtc,
}
static const struct drm_crtc_funcs ast_crtc_funcs = {
- .reset = drm_atomic_helper_crtc_reset,
+ .reset = ast_crtc_reset,
.set_config = drm_crtc_helper_set_config,
.gamma_set = drm_atomic_helper_legacy_gamma_set,
.destroy = ast_crtc_destroy,
--
2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/amd/dm/mst: Ignore payload update failures on disable
[AMD Public Use] Hi Lyude, Thanks for the patch! I'm wondering if this error still occurs with this patch applied https://patchwork.kernel.org/patch/11274363/ I tried to clean up all mgr->proposed_vcpis[] in this patch so drm_dp_update_payload_part1() will skip all invalid ports. However, I'm also thinking to improve this patch. Maybe it is better to do cleaning proposed_vcpis[] in dm_helpers_dp_mst_write_payload_allocation_table() due to it is the actual place that DC try to update the status for a specific VC stream. If it's reasonable then I'll do that in the future :) > -Original Message- > From: Lyude Paul > Sent: Saturday, January 25, 2020 2:57 AM > To: Lipski, Mikita ; Wentland, Harry > ; amd-...@lists.freedesktop.org > Cc: sta...@vger.kernel.org; Wentland, Harry ; Li, > Sun peng (Leo) ; Deucher, Alexander > ; Koenig, Christian > ; Zhou, David(ChunMing) > ; David Airlie ; Daniel Vetter > ; Lakha, Bhawanpreet ; > Lipski, Mikita ; Sam Ravnborg ; > David Francis ; Tsai, Martin > ; Chris Wilson ; Lee, Alvin > ; Jean Delvare ; > dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org; Lin, Wayne > > Subject: Re: [PATCH] drm/amd/dm/mst: Ignore payload update failures on > disable > > > > On Fri, 2020-01-24 at 11:39 -0500, Mikita Lipski wrote: > > > > On 1/24/20 9:55 AM, Harry Wentland wrote: > > > On 2020-01-23 7:06 p.m., Lyude Paul wrote: > > > > Disabling a display on MST can potentially happen after the entire > > > > MST topology has been removed, which means that we can't > > > > communicate with the topology at all in this scenario. Likewise, > > > > this also means that we can't properly update payloads on the > > > > topology and as such, it's a good idea to ignore payload update failures > when disabling displays. > > > > Currently, amdgpu makes the mistake of halting the payload update > > > > process when any payload update failures occur, resulting in > > > > leaving DC's local copies of the payload tables out of date. > > > > > > > > This ends up causing problems with hotplugging MST topologies, and > > > > causes modesets on the second hotplug to fail like so: > > > > > > > > [drm] Failed to updateMST allocation table forpipe idx:1 > > > > [ cut here ] > > > > WARNING: CPU: 5 PID: 1511 at > > > > drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:2677 > > > > update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] Modules linked > > > > in: cdc_ether usbnet fuse xt_conntrack nf_conntrack > > > > nf_defrag_ipv6 libcrc32c nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 > > > > nft_counter nft_compat nf_tables nfnetlink tun bridge stp llc > > > > sunrpc vfat fat wmi_bmof uvcvideo snd_hda_codec_realtek > > > > snd_hda_codec_generic snd_hda_codec_hdmi videobuf2_vmalloc > > > > snd_hda_intel videobuf2_memops > > > > videobuf2_v4l2 snd_intel_dspcfg videobuf2_common crct10dif_pclmul > > > > snd_hda_codec videodev crc32_pclmul snd_hwdep snd_hda_core > > > > ghash_clmulni_intel snd_seq mc joydev pcspkr snd_seq_device > > > > snd_pcm sp5100_tco k10temp i2c_piix4 snd_timer thinkpad_acpi > > > > ledtrig_audio snd wmi soundcore video i2c_scmi acpi_cpufreq > > > > ip_tables amdgpu(O) rtsx_pci_sdmmc amd_iommu_v2 gpu_sched > mmc_core > > > > i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt > > > > fb_sys_fops cec drm crc32c_intel serio_raw hid_multitouch r8152 > > > > mii nvme r8169 nvme_core rtsx_pci pinctrl_amd > > > > CPU: 5 PID: 1511 Comm: gnome-shell Tainted: G O > 5.5.0- > > > > rc7Lyude-Test+ #4 > > > > Hardware name: LENOVO FA495SIT26/FA495SIT26, BIOS > R12ET22W(0.22 ) > > > > 01/31/2019 > > > > RIP: 0010:update_mst_stream_alloc_table+0x11e/0x130 [amdgpu] > > > > Code: 28 00 00 00 75 2b 48 8d 65 e0 5b 41 5c 41 5d 41 5e 5d c3 0f > > > > b6 06 > > > > 49 89 1c 24 41 88 44 24 08 0f b6 46 01 41 88 44 24 09 eb 93 <0f> > > > > 0b e9 2f ff ff ff e8 a6 82 a3 c2 66 0f 1f 44 00 00 0f 1f 44 00 > > > > RSP: 0018:ac428127f5b0 EFLAGS: 00010202 > > > > RAX: 0002 RBX: 8d1e166eee80 RCX: > > > > > RDX: ac428127f668 RSI: 8d1e166eee80 RDI: ac428127f610 > > > > RBP: ac428127f640 R08: c03d94a8 R09: > > > > R10: 8d1e24b02000 R11: ac428127f5b0 R12: 8d1e1b83d000 > > > > R13: 8d1e1bea0b08 R14: 0002 R15: > 0002 > > > > FS: 7fab23ffcd80() GS:8d1e28b4() > > > > knlGS: > > > > CS: 0010 DS: ES: CR0: 80050033 > > > > CR2: 7f151f1711e8 CR3: 0005997c CR4: > 003406e0 > > > > Call Trace: > > > > ? mutex_lock+0xe/0x30 > > > > dc_link_allocate_mst_payload+0x9a/0x210 [amdgpu] > > > > ? dm_read_reg_func+0x39/0xb0 [amdgpu] > > > > ? core_link_enable_stream+0x656/0x730 [amdgpu] > > > > core_link_enable_stream+0x656/0x730 [amdgpu] > > > > dce110_apply_ctx_to_hw+0x58e/0x5d0 [amdgpu] > > > > ? dcn10_verify_allow_pstate_change_high+0x1d/0x280 [amdgpu] > > > > ? dcn10_wait
Re: [PATCH] drm/mst: Fix possible NULL pointer dereference in drm_dp_mst_process_up_req()
On Wed, 2020-01-29 at 15:24 -0800, José Roberto de Souza wrote:
> According to DP specification, DP_SINK_EVENT_NOTIFY is also a
> broadcast message but as this function only handles
> DP_CONNECTION_STATUS_NOTIFY I will only make the static
> analyzer that caught this issue happy by not calling
> drm_dp_get_mst_branch_device_by_guid() with a NULL guid, causing
> drm_dp_mst_process_up_req() to return in the "if (!mstb)" right
> bellow.
>
> Fixes: 9408cc94eb04 ("drm/dp_mst: Handle UP requests asynchronously")
> Cc: Lyude Paul
> Cc: Sean Paul
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 23cf46bfef74..a811247cecfe 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3829,7 +3829,8 @@ drm_dp_mst_process_up_req(struct
> drm_dp_mst_topology_mgr *mgr,
> else if (msg->req_type == DP_RESOURCE_STATUS_NOTIFY)
> guid = msg->u.resource_stat.guid;
>
> - mstb = drm_dp_get_mst_branch_device_by_guid(mgr, guid);
> + if (guid)
> + mstb =
> drm_dp_get_mst_branch_device_by_guid(mgr, guid);
> } else {
> mstb = drm_dp_get_mst_branch_device(mgr, hdr->lct, hdr-
> >rad);
> }
Been fixing something similar in dp mst topology a while ago, was also
similar NULL pointer dereference. Fix seems to be correct, however I
would still have a look at least, how it affects overall logic then.
I mean now we don't call drm_dp_get_mst_branch_device_by_guid if guid
is NULL - that's ok, however it means that mstb will not get
initialized and how this is going to affect the code flow then?
SHould we may be still try to initialize mstb somehow and check
guid actually inside of this drm_dp_get_mst_branch_device_by_guid
function? Or call drm_dp_get_mst_branch_device?
I'm not stating anything here, just asking question to
make the overall picture bit more clear.
Anyways, even wrong logic to me is better than crashing so,
Reviewed-by: Stanislav Lisovskiy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv5 00/34] Add AFBC support for Rockchip
Hi Andrzej, Sorry for the delay in reviewing the patches. I am hoping to get through the review early next week if that is OK with you. Best regards, Liviu On Thu, Jan 30, 2020 at 10:08:15AM +0100, Andrzej Pietrasiewicz wrote: > Hi All, > > A gentle reminder. > > Please also see inline: > > W dniu 17.12.2019 o 15:49, Andrzej Pietrasiewicz pisze: > > This series adds AFBC support for Rockchip. It is inspired by: > > > > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/factory-gru-9017.B-chromeos-4.4/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > > > > This is the fifth iteration of the afbc series. Between v3 and v4 a lot of > > rework has been done, the main goal of which was to move all afbc-related > > checks to helpers, so that core does not deal with it. > > > > A new struct drm_afbc_framebuffer is added, which stores afbc-related > > driver-specific data. Because of that, in drivers that wish to > > use this feature, the struct must be allocated directly in the driver > > code rather than inside helpers, so the first portion of the patchset > > does the necessary refactoring. > > > > Then, there are 3 users of afbc: komeda, malidp and, finally, rockchip, > > the latter being the ultimate purpose of this work and the 3 subsequent > > portions of the patchset move komeda and malidp to generic helpers and add > > afbc support to rockchip. > > If changes in komeda and malidp is too much to digest at a time I can > focus on rockchip only. This would amount to patches 1-4 and 33-34. > After all the ultimate purpose of this work and time spent on it > is landing afbc support for rockchip. > > Regards, > > Andrzej -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv5 00/34] Add AFBC support for Rockchip
Hi Liviu, W dniu 30.01.2020 o 12:44, Liviu Dudau pisze: Hi Andrzej, Sorry for the delay in reviewing the patches. I am hoping to get through the review early next week if that is OK with you. Thanks, that would be great. Andrzej Best regards, Liviu On Thu, Jan 30, 2020 at 10:08:15AM +0100, Andrzej Pietrasiewicz wrote: Hi All, A gentle reminder. Please also see inline: W dniu 17.12.2019 o 15:49, Andrzej Pietrasiewicz pisze: This series adds AFBC support for Rockchip. It is inspired by: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/factory-gru-9017.B-chromeos-4.4/drivers/gpu/drm/rockchip/rockchip_drm_vop.c This is the fifth iteration of the afbc series. Between v3 and v4 a lot of rework has been done, the main goal of which was to move all afbc-related checks to helpers, so that core does not deal with it. A new struct drm_afbc_framebuffer is added, which stores afbc-related driver-specific data. Because of that, in drivers that wish to use this feature, the struct must be allocated directly in the driver code rather than inside helpers, so the first portion of the patchset does the necessary refactoring. Then, there are 3 users of afbc: komeda, malidp and, finally, rockchip, the latter being the ultimate purpose of this work and the 3 subsequent portions of the patchset move komeda and malidp to generic helpers and add afbc support to rockchip. If changes in komeda and malidp is too much to digest at a time I can focus on rockchip only. This would amount to patches 1-4 and 33-34. After all the ultimate purpose of this work and time spent on it is landing afbc support for rockchip. Regards, Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] MAINTAINERS: Add Thomas as drm-misc co-maintainer
Daniel asked me to serve as co-maintainer of the drm-misc tree. Signed-off-by: Thomas Zimmermann --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 32ed67fe516f..3e6bc3681d2f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5444,6 +5444,7 @@ F:include/linux/vga* DRM DRIVERS AND MISC GPU PATCHES M: Maarten Lankhorst M: Maxime Ripard +M: Thomas Zimmermann W: https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html S: Maintained T: git git://anongit.freedesktop.org/drm/drm-misc -- 2.25.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Regression 5.5-rc1] Extremely low GPU performance on NVIDIA Tegra20/30
On Thu, Jan 30, 2020 at 07:36:36AM +0300, Dmitry Osipenko wrote: > 29.01.2020 15:39, Thierry Reding пишет: > > On Mon, Jan 20, 2020 at 05:53:03AM +0300, Dmitry Osipenko wrote: > >> 13.12.2019 18:35, Dmitry Osipenko пишет: > ... > >> Hello Thierry, > >> > >> I took another look at the problem and here what was found: > >> > >> 1) The "Optionally attach clients to the IOMMU" patch is wrong because: > >> > >> 1. host1x_drm_probe() is invoked *before* any of the > >>host1x_client_iommu_attach() happens, so there is no way > >>on earth the 'use_explicit_iommu' could ever be true. > > > > That's not correct. host1x_client_iommu_attach() happens during > > host1x_device_init(), which is called during host1x_drm_probe(). > > Looks like I previously got confused by accident, my bad. > > > The idea is that host1x_drm_probe() sets up the minimum IOMMU so that all > > devices can attach, if they want to. If any of them connect (because > > they aren't already attached via something like the DMA/IOMMU glue) > > then the tegra->use_explicit_iommu is set to true, in which case the > > IOMMU domain setup for explicit IOMMU API usage is completed. If, on > > the other hand, none of the clients have a need for the explicit IOMMU > > domain, there's no need to set it up and host1x_drm_probe() will just > > discard it. > > This matches my understanding of what you wanted to achieve, thanks. > > >> 2. Not attaching DRM clients to IOMMU if HOST1x isn't > >>attached is wrong because it never attached in the case > >>of CONFIG_TEGRA_HOST1X_FIREWALL=y [1] and this also > >>makes no sense for T20/30 that do not support LPAE. > > > > It's not at all wrong. Take for example the case of Tegra124 and > > Tegra210 where host1x and its clients can address 34 bits. In those > > cases, allocating individual pages via shmem has a high probability of > > hitting physical addresses beyond the 32-bit range, which means that the > > host1x can not access them unless it is also attached to an IOMMU where > > physical addresses to >= 4 GiB addresses can be translated into < 4 GiB > > virtual addresses. This is a very real problem that I was running into > > when testing on Tegra124 and Tegra210. > > Why not to set the DMA mask to 32bits if IOMMU is unavailable? We already do that. If you look at host1x_iommu_init() in drivers/gpu/host1x/dev.c, you'll see that when no IOMMU support is available and the host1x doesn't support wide GATHER opcodes, then we limit the DMA Mask to 32 bits. But that's not enough, see below. > I'm a bit puzzled by the actual need to support the case where Host1x is > backed by IOMMU and clients not.. How we could ever end up with this > scenario in the upstream kernel? That's not what we're doing here. The fundamental problem is that we have a couple of generations where the hardware is mismatched in that clients support 34-bit addresses while host1x can only use 32-bit addresses in the GATHER opcode. The only way to get around this mismatch is by using an IOMMU. However, with an IOMMU enabled for clients, we can run into the case where sparse pages would be allocated via shmem and end up beyond the 32-bit boundary. If the host1x is not attached to an IOMMU, there's no way for it to access these pages with standard GATHER opcodes. This is what used to happen prior to this change when the host1x firewall was enabled. Since we were not attaching it to an IOMMU in that case, we would end up with sparse buffers allocated from pages that the host1x couldn't address. > What about the reverse scenario? You won't be able to patch cmdstream > properly for >32bit addresses. I don't think that scenario exists. I'm not aware of a Tegra device that has system memory outside of the CPU-addressable region. > The root of the problem is that Tegra DRM UAPI doesn't support 64bit > addresses, so you can't use "wide" opcodes and can't patch cmdstream. There's nothing in the UAPI that deals with addresses directly. We only pass around handles and these are resolved to buffer objects in the kernel where the address of the buffers can be 32-bit or 64-bit. And we do in fact support wide opcodes and patch command streams just fine on 64-bit systems. I mean, it's not like I've been doing this just for the fun of it. There are actual configurations where this is needed in order for it to work. > Perhaps it is better not to add any new things or quirks to the Host1x / > Tegra DRM for now. The drivers need a serious clean up, otherwise mess > only continues to grow up. Don't you think so? This isn't anything new or a quirk. This is bug fixes to ensure that the driver works in (now hopefully) all configurations. Previously it was a matter of getting the configuration just right in order for it to work. All the work I did here (starting with the wide opcode support and then the DMA API and IOMMU work) was to make sure it would safely work in any setup. And I do consider these changes
[PATCH v2 2/2] drm/panel: simple: Add EDT panel support
EDT ET043080DH6-GP is a 4.3" WQVGA 480x272 RGB LCD panel used on the iWave
Generic SODIMM Development Platform.
Changes in v2:
-added mandatory .connector_type field
-changed the .bus_format MEDIA_BUS_FMT_RGB666_1X18
Signed-off-by: Marian-Cristian Rotariu
Reviewed-by: Lad Prabhakar
---
drivers/gpu/drm/panel/panel-simple.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index a0dd84e..b8e0d88e 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1301,6 +1301,37 @@ static const struct panel_desc edt_et035012dm6 = {
.bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_NEGEDGE,
};
+static const struct drm_display_mode edt_etm043080dh6gp_mode = {
+ .clock = 10870,
+ .hdisplay = 480,
+ .hsync_start = 480 + 8,
+ .hsync_end = 480 + 8 + 4,
+ .htotal = 480 + 8 + 4 + 41,
+
+ /*
+* IWG22M: Y resolution changed for "dc_linuxfb" module crashing while
+* fb_align
+*/
+
+ .vdisplay = 288,
+ .vsync_start = 288 + 2,
+ .vsync_end = 288 + 2 + 4,
+ .vtotal = 288 + 2 + 4 + 10,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc edt_etm043080dh6gp = {
+ .modes = &edt_etm043080dh6gp_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 100,
+ .height = 65,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
static const struct drm_display_mode edt_etm0430g0dh6_mode = {
.clock = 9000,
.hdisplay = 480,
@@ -3371,6 +3402,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "edt,et035012dm6",
.data = &edt_et035012dm6,
}, {
+ .compatible = "edt,etm043080dh6gp",
+ .data = &edt_etm043080dh6gp,
+ }, {
.compatible = "edt,etm0430g0dh6",
.data = &edt_etm0430g0dh6,
}, {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/2] Add support for EDT ETM043080DH6-GP
Second version of patch-set that adds support for EDT ETM043080DH6-GP. This is a 480x272 TFT Display with capacitive touchscreen and it is compatible with the simple panel driver. We have tested it with our iWave-G22D Generic SODIMM Development Board. In v2, after Sam Ravnborg's review, I've rebased the patches against drm-misc-next and modified the proper bindings file for the simple panels. I have also added the mandatory connector-type field and corrected the bus type as it is a 18bbp, therefore an RGB666. Unfortunately, we do not have access to the datasheet, therefore we could not use the display_timings format. Marian-Cristian Rotariu (2): dt-bindings: display: Add bindings for EDT panel drm/panel: simple: Add EDT panel support .../bindings/display/panel/panel-simple.yaml | 2 ++ drivers/gpu/drm/panel/panel-simple.c | 34 ++ 2 files changed, 36 insertions(+) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] dt-bindings: display: Add bindings for EDT panel
Document the Emerging Display Technology Corp. (EDT) ETM043080DH6-GP display, which is a 480x272 4.3" TFT display with capacitive touchscreen. Changes in v2: -modify proper bindings file Signed-off-by: Marian-Cristian Rotariu Reviewed-by: Lad Prabhakar --- Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index bdf4d0b..cf23b0a 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -89,6 +89,8 @@ properties: - dlc,dlc1010gig # Emerging Display Technology Corp. 3.5" QVGA TFT LCD panel - edt,et035012dm6 +# Emerging Display Technology Corp. 480x272 TFT Display with capacitive touch + - edt,etm043080dh6gp # Emerging Display Technology Corp. 480x272 TFT Display - edt,etm0430g0dh6 # Emerging Display Technology Corp. 5.7" VGA TFT LCD panel -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: Add Thomas as drm-misc co-maintainer
(cc'ing Maxime with the corrrect email addrees) Am 30.01.20 um 13:06 schrieb Thomas Zimmermann: > Daniel asked me to serve as co-maintainer of the drm-misc tree. > > Signed-off-by: Thomas Zimmermann > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 32ed67fe516f..3e6bc3681d2f 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5444,6 +5444,7 @@ F: include/linux/vga* > DRM DRIVERS AND MISC GPU PATCHES > M: Maarten Lankhorst > M: Maxime Ripard > +M: Thomas Zimmermann > W: https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html > S: Maintained > T: git git://anongit.freedesktop.org/drm/drm-misc > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/9] mm, drm/ttm, drm/vmwgfx: Support huge TTM pagefaults
On 1/29/20 3:55 PM, Christian König wrote:
Am 24.01.20 um 10:09 schrieb Thomas Hellström (VMware):
From: Thomas Hellstrom
Support huge (PMD-size and PUD-size) page-table entries by providing a
huge_fault() callback.
We still support private mappings and write-notify by splitting the huge
page-table entries on write-access.
Note that for huge page-faults to occur, either the kernel needs to be
compiled with trans-huge-pages always enabled, or the kernel needs to be
compiled with trans-huge-pages enabled using madvise, and the user-space
app needs to call madvise() to enable trans-huge pages on a per-mapping
basis.
Furthermore huge page-faults will not succeed unless buffer objects and
user-space addresses are aligned on huge page size boundaries.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Matthew Wilcox (Oracle)"
Cc: "Kirill A. Shutemov"
Cc: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: "Christian König"
Cc: Dan Williams
Signed-off-by: Thomas Hellstrom
Reviewed-by: Roland Scheidegger
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 145 -
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 2 +-
include/drm/ttm/ttm_bo_api.h | 3 +-
3 files changed, 145 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 389128b8c4dd..49704261a00d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -156,6 +156,89 @@ vm_fault_t ttm_bo_vm_reserve(struct
ttm_buffer_object *bo,
}
EXPORT_SYMBOL(ttm_bo_vm_reserve);
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+/**
+ * ttm_bo_vm_insert_huge - Insert a pfn for PUD or PMD faults
+ * @vmf: Fault data
+ * @bo: The buffer object
+ * @page_offset: Page offset from bo start
+ * @fault_page_size: The size of the fault in pages.
+ * @pgprot: The page protections.
+ * Does additional checking whether it's possible to insert a PUD or
PMD
+ * pfn and performs the insertion.
+ *
+ * Return: VM_FAULT_NOPAGE on successful insertion,
VM_FAULT_FALLBACK if
+ * a huge fault was not possible, and a VM_FAULT_ERROR code otherwise.
+ */
+static vm_fault_t ttm_bo_vm_insert_huge(struct vm_fault *vmf,
+ struct ttm_buffer_object *bo,
+ pgoff_t page_offset,
+ pgoff_t fault_page_size,
+ pgprot_t pgprot)
+{
+ pgoff_t i;
+ vm_fault_t ret;
+ unsigned long pfn;
+ pfn_t pfnt;
+ struct ttm_tt *ttm = bo->ttm;
+ bool write = vmf->flags & FAULT_FLAG_WRITE;
+
+ /* Fault should not cross bo boundary. */
+ page_offset &= ~(fault_page_size - 1);
+ if (page_offset + fault_page_size > bo->num_pages)
+ goto out_fallback;
+
+ if (bo->mem.bus.is_iomem)
+ pfn = ttm_bo_io_mem_pfn(bo, page_offset);
+ else
+ pfn = page_to_pfn(ttm->pages[page_offset]);
+
+ /* pfn must be fault_page_size aligned. */
+ if ((pfn & (fault_page_size - 1)) != 0)
+ goto out_fallback;
+
+ /* Check that memory is contiguous. */
+ if (!bo->mem.bus.is_iomem)
+ for (i = 1; i < fault_page_size; ++i) {
+ if (page_to_pfn(ttm->pages[page_offset + i]) != pfn + i)
+ goto out_fallback;
+ }
+ /* IO mem without the io_mem_pfn callback is always contiguous. */
+ else if (bo->bdev->driver->io_mem_pfn)
+ for (i = 1; i < fault_page_size; ++i) {
+ if (ttm_bo_io_mem_pfn(bo, page_offset + i) != pfn + i)
+ goto out_fallback;
+ }
Maybe add {} to the if to make clear where things start/end.
+
+ pfnt = __pfn_to_pfn_t(pfn, PFN_DEV);
+ if (fault_page_size == (HPAGE_PMD_SIZE >> PAGE_SHIFT))
+ ret = vmf_insert_pfn_pmd_prot(vmf, pfnt, pgprot, write);
+#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
+ else if (fault_page_size == (HPAGE_PUD_SIZE >> PAGE_SHIFT))
+ ret = vmf_insert_pfn_pud_prot(vmf, pfnt, pgprot, write);
+#endif
+ else
+ WARN_ON_ONCE(ret = VM_FAULT_FALLBACK);
+
+ if (ret != VM_FAULT_NOPAGE)
+ goto out_fallback;
+
+ return VM_FAULT_NOPAGE;
+out_fallback:
+ count_vm_event(THP_FAULT_FALLBACK);
+ return VM_FAULT_FALLBACK;
This doesn't seem to match the function documentation since we never
return ret here as far as I can see.
Apart from those comments it looks like that should work,
Christian.
Thanks for reviewing, Christian. I'll update the next version with your
feedback.
/Thomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: Add Thomas as drm-misc co-maintainer
Op 30-01-2020 om 13:06 schreef Thomas Zimmermann: > Daniel asked me to serve as co-maintainer of the drm-misc tree. > > Signed-off-by: Thomas Zimmermann > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 32ed67fe516f..3e6bc3681d2f 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5444,6 +5444,7 @@ F: include/linux/vga* > DRM DRIVERS AND MISC GPU PATCHES > M: Maarten Lankhorst > M: Maxime Ripard > +M: Thomas Zimmermann > W: https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html > S: Maintained > T: git git://anongit.freedesktop.org/drm/drm-misc Acked-by: Maarten Lankhorst ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] dt-bindings: one file of all simple DSI panels
On Thu, Jan 30, 2020 at 2:45 AM Benjamin Gaignard
wrote:
>
> From: Sam Ravnborg
>
> To complement panel-simple.yaml, create panel-simple-dsi.yaml.
> panel-simple-dsi-yaml are for all simple DSP panels with a single
> power-supply and optional backlight / enable GPIO / reset GPIO.
>
> Migrate panasonic,vvx10f034n00, orisetech,otm8009a and raydium,rm68200 over
> to the new file.
>
> The objectives with one file for all the simple DSI panels are:
> - Make it simpler to add bindings for simple DSI panels
> - Keep the number of bindings file lower
> - Keep the binding documentation for simple DSI panels more consistent
>
> Signed-off-by: Sam Ravnborg
> Signed-off-by: Benjamin Gaignard
> Cc: Thierry Reding
> Cc: Rob Herring
> Cc: Maxime Ripard
> Cc: Yannick Fertre
> Cc: Mark Rutland
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Cc: devicet...@vger.kernel.org
> ---
> version 3:
> - add orisetech,otm8009a and raydium,rm68200 compatibles
> - add reset-gpios optional property
> - fix indentation on compatible enumeration
> => Rob had reviewed the second version but, given the changes in version 3
>I haven't added here.
> .../bindings/display/panel/orisetech,otm8009a.txt | 23 ---
> .../display/panel/panasonic,vvx10f034n00.txt | 20 --
> .../bindings/display/panel/panel-simple-dsi.yaml | 74
> ++
> .../bindings/display/panel/raydium,rm68200.txt | 25
> 4 files changed, 74 insertions(+), 68 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.txt
> delete mode 100644
> Documentation/devicetree/bindings/display/panel/panasonic,vvx10f034n00.txt
> create mode 100644
> Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
> delete mode 100644
> Documentation/devicetree/bindings/display/panel/raydium,rm68200.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.txt
> b/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.txt
> deleted file mode 100644
> index 203b03eefb68..
> --- a/Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.txt
> +++ /dev/null
> @@ -1,23 +0,0 @@
> -Orise Tech OTM8009A 3.97" 480x800 TFT LCD panel (MIPI-DSI video mode)
> -
> -The Orise Tech OTM8009A is a 3.97" 480x800 TFT LCD panel connected using
> -a MIPI-DSI video interface. Its backlight is managed through the DSI link.
> -
> -Required properties:
> - - compatible: "orisetech,otm8009a"
> - - reg: the virtual channel number of a DSI peripheral
> -
> -Optional properties:
> - - reset-gpios: a GPIO spec for the reset pin (active low).
> - - power-supply: phandle of the regulator that provides the supply voltage.
> -
> -Example:
> -&dsi {
> - ...
> - panel@0 {
> - compatible = "orisetech,otm8009a";
> - reg = <0>;
> - reset-gpios = <&gpioh 7 GPIO_ACTIVE_LOW>;
> - power-supply = <&v1v8>;
> - };
> -};
> diff --git
> a/Documentation/devicetree/bindings/display/panel/panasonic,vvx10f034n00.txt
> b/Documentation/devicetree/bindings/display/panel/panasonic,vvx10f034n00.txt
> deleted file mode 100644
> index 37dedf6a6702..
> ---
> a/Documentation/devicetree/bindings/display/panel/panasonic,vvx10f034n00.txt
> +++ /dev/null
> @@ -1,20 +0,0 @@
> -Panasonic 10" WUXGA TFT LCD panel
> -
> -Required properties:
> -- compatible: should be "panasonic,vvx10f034n00"
> -- reg: DSI virtual channel of the peripheral
> -- power-supply: phandle of the regulator that provides the supply voltage
> -
> -Optional properties:
> -- backlight: phandle of the backlight device attached to the panel
> -
> -Example:
> -
> - mdss_dsi@fd922800 {
> - panel@0 {
> - compatible = "panasonic,vvx10f034n00";
> - reg = <0>;
> - power-supply = <&vreg_vsp>;
> - backlight = <&lp8566_wled>;
> - };
> - };
> diff --git
> a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
> b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
> new file mode 100644
> index ..1168b8186490
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/panel-simple-dsi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Simple DSI panels with a single power-supply
> +
> +maintainers:
> + - Thierry Reding
> + - Sam Ravnborg
> +
> +description: |
> + This binding file is a collection of the DSI panels that
> + requires only a single power-supply.
> + There are optionally a backlight and an enable GPIO.
> + The panel may use an OF graph binding for the association to the display,
> + or it may be a
Re: [PATCH libdrm RESEND 1/2] xf86drm: generalize the device subsystem type parsing code
Hi Mikhail, thanks for the patches. Please create a merge request by clicking the "Fork" button on https://gitlab.freedesktop.org/mesa/drm, pushing the two commits to a new branch in the newly created repository, and opening the URL in the "git push" output. Thanks, -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for 5.6-rc1
On Wed, Jan 29, 2020 at 9:58 PM Dave Airlie wrote:
>
> It has two known conflicts, one in i915_gem_gtt, where you should juat
> take what's in the pull (it looks messier than it is),
That doesn't seem right. If I do that, I lose the added GEM_BUG_ON()'s.
I think the proper merge resolution does this:
diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
index f10b2c41571c..f4fec7eb4064 100644
--- a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
@@ -131,6 +131,7 @@ static void gen6_ppgtt_insert_entries(struct
i915_address_space *vm,
vaddr = kmap_atomic_px(i915_pt_entry(pd, act_pt));
do {
+ GEM_BUG_ON(iter.sg->length < I915_GTT_PAGE_SIZE);
vaddr[act_pte] = pte_encode | GEN6_PTE_ADDR_ENCODE(iter.dma);
iter.dma += I915_GTT_PAGE_SIZE;
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 077b8f7cf6cb..4d1de2d97d5c 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -379,6 +379,7 @@ gen8_ppgtt_insert_pte(struct i915_ppgtt *ppgtt,
pd = i915_pd_entry(pdp, gen8_pd_index(idx, 2));
vaddr = kmap_atomic_px(i915_pt_entry(pd, gen8_pd_index(idx, 1)));
do {
+ GEM_BUG_ON(iter->sg->length < I915_GTT_PAGE_SIZE);
vaddr[gen8_pd_index(idx, 0)] = pte_encode | iter->dma;
iter->dma += I915_GTT_PAGE_SIZE;
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 79096722ce16..531d501be01f 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -787,7 +787,7 @@ static int ggtt_probe_common(struct i915_ggtt
*ggtt, u64 size)
* readback check when writing GTT PTE entries.
*/
if (IS_GEN9_LP(i915) || INTEL_GEN(i915) >= 10)
- ggtt->gsm = ioremap_nocache(phys_addr, size);
+ ggtt->gsm = ioremap(phys_addr, size);
else
ggtt->gsm = ioremap_wc(phys_addr, size);
if (!ggtt->gsm) {
since those ppgtt_insert_entries functions had moved to their
gen-specific files.
No?
Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for 5.6-rc1
On Thu, Jan 30, 2020 at 8:13 AM Linus Torvalds
wrote:
>
> That doesn't seem right. If I do that, I lose the added GEM_BUG_ON()'s.
Just for your ref: see commit ecc4d2a52df6 ("drm/i915/userptr: fix
size calculation") for the source of those debug statements, and then
2c86e55d2ab5 ("drm/i915/gtt: split up i915_gem_gtt") on the other side
that just moved the functions..
Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for 5.6-rc1
Quoting Linus Torvalds (2020-01-30 16:13:24)
> On Wed, Jan 29, 2020 at 9:58 PM Dave Airlie wrote:
> >
> > It has two known conflicts, one in i915_gem_gtt, where you should juat
> > take what's in the pull (it looks messier than it is),
>
> That doesn't seem right. If I do that, I lose the added GEM_BUG_ON()'s.
>
> I think the proper merge resolution does this:
>
> diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
> b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
> index f10b2c41571c..f4fec7eb4064 100644
> --- a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
> +++ b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
> @@ -131,6 +131,7 @@ static void gen6_ppgtt_insert_entries(struct
> i915_address_space *vm,
>
> vaddr = kmap_atomic_px(i915_pt_entry(pd, act_pt));
> do {
> + GEM_BUG_ON(iter.sg->length < I915_GTT_PAGE_SIZE);
> vaddr[act_pte] = pte_encode | GEN6_PTE_ADDR_ENCODE(iter.dma);
>
> iter.dma += I915_GTT_PAGE_SIZE;
> diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> index 077b8f7cf6cb..4d1de2d97d5c 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
> @@ -379,6 +379,7 @@ gen8_ppgtt_insert_pte(struct i915_ppgtt *ppgtt,
> pd = i915_pd_entry(pdp, gen8_pd_index(idx, 2));
> vaddr = kmap_atomic_px(i915_pt_entry(pd, gen8_pd_index(idx, 1)));
> do {
> + GEM_BUG_ON(iter->sg->length < I915_GTT_PAGE_SIZE);
> vaddr[gen8_pd_index(idx, 0)] = pte_encode | iter->dma;
>
> iter->dma += I915_GTT_PAGE_SIZE;
Yes, that matches the code in drm-intel-next-queued.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 3/4] drm/i915/display: Remove useless call intel_dp_mst_encoder_cleanup()
On Thu, Jan 16, 2020 at 05:58:36PM -0800, José Roberto de Souza wrote:
> This is a eDP function and it will always returns true for non-eDP
> ports.
>
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 4074d83b1a5f..a50b5b6dd009 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -7537,7 +7537,6 @@ intel_dp_init_connector(struct intel_digital_port
> *intel_dig_port,
>
> if (!intel_edp_init_connector(intel_dp, intel_connector)) {
> intel_dp_aux_fini(intel_dp);
> - intel_dp_mst_encoder_cleanup(intel_dig_port);
This makes the unwind look incomplete to the causual reader. The cleanup
function does both anyway so cross checking is harder if they're not
consistent. So not sure I like it. Hmm. The ordering of these two also
looks off here.
Maybe nicer to just move the whole onion to the end of function
(we alredy have one layer there)?
> goto fail;
> }
>
> --
> 2.25.0
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/i915/display: Set TRANS_DDI_MODE_SELECT to default value when disabling TRANS_DDI
On Thu, Jan 16, 2020 at 05:58:37PM -0800, José Roberto de Souza wrote:
> TGL timeouts when disabling MST transcoder and fifo underruns over MST
> transcoders are fixed when setting TRANS_DDI_MODE_SELECT to 0(HDMI
> mode) during the disable sequence.
>
> Although BSpec disable sequence don't require this step it is a
> harmless change and it is also done by Windows driver.
> Anyhow HW team was notified about that but it can take some time to
> documentation to be updated.
>
> A case that always lead to those issues is:
> - do a modeset enabling pipe A and pipe B in the same MST stream
> leaving A as master
> - disable pipe A, promote B as master doing a full modeset in A
> - enable pipe A, changing the master transcoder back to A(doing a
> full modeset in B)
> - Pow: underruns and timeouts
>
> The transcoders involved will only work again when complete disabled
> and their power wells turned off causing a reset in their registers.
>
> Cc: Ville Syrjälä
> Cc: Matt Roper
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 32ea3c7e8b62..82e90f271974 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -1997,6 +1997,7 @@ void intel_ddi_disable_transcoder_func(const struct
> intel_crtc_state *crtc_state
>
> val = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
> val &= ~TRANS_DDI_FUNC_ENABLE;
> + val &= ~TRANS_DDI_MODE_SELECT_MASK;
Feels a bit early since IIRC we still leave a bunch of other stuff
enabled/selected here. In fact we don't seem to be clearing the DDI select
anywhere at all? That one I would be more suspicious of than the mode.
But maybe we should just clear both somewhere? I would suggest it should
be when we clear the port select finally.
>
> if (INTEL_GEN(dev_priv) >= 12) {
> if (!intel_dp_mst_is_master_trans(crtc_state))
> --
> 2.25.0
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm for 5.6-rc1
The pull request you sent on Thu, 30 Jan 2020 15:58:11 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-next-2020-01-30 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/9f68e3655aae6d49d6ba05dd263f99f33c2567af Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206351] RX 5600 XT Not Correctly Recognized, Max Memory Frequency Below Where it Should Be
https://bugzilla.kernel.org/show_bug.cgi?id=206351 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #2 from Alex Deucher (alexdeuc...@gmail.com) --- The only thing missing is the marketing strings. See this libdrm merge request: https://gitlab.freedesktop.org/mesa/drm/merge_requests/44 that will provide a proper string for mesa libraries like OpenGL or vulkan. Tools like lspci and inxi use the pci ids database (http://pci-ids.ucw.cz/) to get their strings. However the strings on that site are tied to the device ids. The marketing names for AMD parts vary based on the device id and the revision id as well as the subsystem ids in some cases. the pci ids database does not provide a way to provide a string based on a combination of ids. If you want the newer smc firmware, it's available here: https://people.freedesktop.org/~agd5f/radeon_ucode/navi10/new/navi10_smc.bin it will be upstreamed to linux-firmware once it's finished it's internal QA cycle. As to the clocks, they are provided in the vbios. That is where the driver gets them. Can you provide more information about what OEM product this is? -- 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/2] dt-bindings: display/panel: add bindings for S6E88A0-AMS452EF01
Hi Michael.
Thanks for the quick feedback and the conversion.
There is a few things you need to improve as noted below.
Sam
On Thu, Jan 30, 2020 at 06:11:27PM +0100, michael.s...@seznam.cz wrote:
> From: Michael Srba
>
> This patch adds dts bindings for Samsung AMS452EF01 AMOLED panel, which makes
> use of their S6E88A0 controller.
>
> Signed-off-by: Michael Srba
> ---
> Hi,
> Thanks for the review. I believe I've fixed everything, and I tested that
> I get image on drm-next with these patches applied.
>
> Changes since v1: use yaml format for the binding
> ---
> .../panel/samsung,s6e88a0-ams452ef01.yaml | 49 +++
> 1 file changed, 49 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/samsung,s6e88a0-ams452ef01.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/samsung,s6e88a0-ams452ef01.yaml
>
> b/Documentation/devicetree/bindings/display/panel/samsung,s6e88a0-ams452ef01.yaml
> new file mode 100644
> index ..3d9b480ec706
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/panel/samsung,s6e88a0-ams452ef01.yaml
> @@ -0,0 +1,49 @@
> +# SPDX-License-Identifier: GPL-2.0-only
For new bindings please use: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/sony,acx424akp.yaml#
Filename must match
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Samsung AMS452EF01 AMOLED panel with S6E88A0 video mode DSI controller
> +
> +maintainers:
> + - Michael Srba
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +const: samsung,s6e88a0-ams452ef01
> + reg: true
> + reset-gpios: true
> + vdd3-supply:
> + description: core voltage supply
> + vci-supply:
> + description: voltage supply for analog circuits
> + enforce-video-mode: true
enforce-video-mode is not referenced in the driver - is it relevant?
> +
> +required:
> + - compatible
> + - reg
> + - vdd3-supply
> + - vci-supply
> + - reset-gpios
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +panel@0 {
> + reg = <0>;
> +
> + compatible = "samsung,s6e88a0-ams452ef01";
> +
> + vdd3-supply = <&pm8916_l17>;
> + vci-supply = <®_vlcd_vci>;
> + reset-gpios = <&msmgpio 25 GPIO_ACTIVE_HIGH>;
> + };
No tabs in yaml files. And fix indent so it matches.
Closing '}' below 'p' in ports.
> +
> +...
Drop - not needed.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/panel: Add a driver for Samsung s6e88a0-ams452ef01 panel
Hi Micahel.
Thanks for the quick feedback.
Please address checkpatch warnings.
be2b44c76320 (HEAD -> drm-misc-next) drm/panel: Add a driver for Samsung
s6e88a0-ams452ef01 panel
-:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one
-:40: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#40:
new file mode 100644
-:69: WARNING:LONG_LINE: line over 80 characters
#69: FILE: drivers/gpu/drm/panel/panel-samsung-s6e88a0-ams452ef01.c:25:
+static inline struct s6e88a0_ams452ef01 *to_s6e88a0_ams452ef01(struct
drm_panel *panel)
-:74: WARNING:MACRO_WITH_FLOW_CONTROL: Macros with flow control statements
should be avoided
#74: FILE: drivers/gpu/drm/panel/panel-samsung-s6e88a0-ams452ef01.c:30:
+#define dsi_dcs_write_seq(dsi, seq...) do {\
+ static const u8 d[] = { seq }; \
+ int ret;\
+ ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d)); \
+ if (ret < 0)\
+ return ret; \
+ } while (0)
-:122: WARNING:LONG_LINE_COMMENT: line over 80 characters
#122: FILE: drivers/gpu/drm/panel/panel-samsung-s6e88a0-ams452ef01.c:78:
+ dsi_dcs_write_seq(dsi, 0xb2, 0x40, 0x0a, 0x17, 0x00, 0x0a); // set
default Amoled Off Ratio
-:183: WARNING:LONG_LINE: line over 80 characters
#183: FILE: drivers/gpu/drm/panel/panel-samsung-s6e88a0-ams452ef01.c:139:
+ regulator_bulk_disable(ARRAY_SIZE(ctx->supplies),
ctx->supplies);
-:226: WARNING:LONG_LINE: line over 80 characters
#226: FILE: drivers/gpu/drm/panel/panel-samsung-s6e88a0-ams452ef01.c:182:
+static int s6e88a0_ams452ef01_get_modes(struct drm_panel *panel, struct
drm_connector *connector)
total: 0 errors, 7 warnings, 0 checks, 308 lines checked
Use: dim checkpatch" if you have dim.
Otherwise use checkpatch -q --emacs --strict --show-types
Ignore the warning "MACRO_WITH_FLOW_CONTROL" - as this seems legit in this
use-case.
Sam
On Thu, Jan 30, 2020 at 06:11:28PM +0100, michael.s...@seznam.cz wrote:
> From: Michael Srba
>
> Signed-off-by: Michael Srba
> ---
> Changes since v1: reorder includes; remove empty functions; fix after rebasing
> ---
> drivers/gpu/drm/panel/Kconfig | 6 +
> drivers/gpu/drm/panel/Makefile| 1 +
> .../panel/panel-samsung-s6e88a0-ams452ef01.c | 289 ++
> 3 files changed, 296 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e88a0-ams452ef01.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index ae44ac2ec106..0c7d61f32b0e 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -275,6 +275,12 @@ config DRM_PANEL_SAMSUNG_S6E63M0
> Say Y here if you want to enable support for Samsung S6E63M0
> AMOLED LCD panel.
>
> +config DRM_PANEL_SAMSUNG_S6E88A0_AMS452EF01
> + tristate "Samsung AMS452EF01 panel with S6E88A0 DSI video mode
> controller"
> + depends on OF
> + select DRM_MIPI_DSI
> + select VIDEOMODE_HELPERS
> +
> config DRM_PANEL_SAMSUNG_S6E8AA0
> tristate "Samsung S6E8AA0 DSI video mode panel"
> depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 7c4d3c581fd4..5b622fbe4014 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -28,6 +28,7 @@ obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6D16D0) +=
> panel-samsung-s6d16d0.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03) += panel-samsung-s6e63j0x03.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63M0) += panel-samsung-s6e63m0.o
> +obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E88A0_AMS452EF01) +=
> panel-samsung-s6e88a0-ams452ef01.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
> obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
> diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e88a0-ams452ef01.c
> b/drivers/gpu/drm/panel/panel-samsung-s6e88a0-ams452ef01.c
> new file mode 100644
> index ..49d3f6d0f137
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-samsung-s6e88a0-ams452ef01.c
> @@ -0,0 +1,289 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +// Copyright (C) 2019, Michael Srba
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +#include
> +
> +struct s6e88a0_ams452ef01 {
> + struct drm_panel panel;
> + struct mipi_dsi_device *dsi;
> + struct regulator_bulk_data supplies[2];
> + struct gpio_desc *reset_gpio;
> +
> + bool prepared;
> +};
> +
> +static inline struct s6e88a0_ams452ef01 *to_s6e88a0_ams452ef01(struct
> drm_pane
Re: [PATCH] radeon: completely remove lut leftovers
On Wed, Jan 29, 2020 at 4:28 AM Michel Dänzer wrote: > > On 2020-01-29 9:09 a.m., Daniel Vetter wrote: > > This is an oversight from > > > > commit 42585395ebc1034a98937702849669f17eadb35f > > Author: Peter Rosin > > Date: Thu Jul 13 18:25:36 2017 +0200 > > > > drm: radeon: remove dead code and pointless local lut storage > > > > v2: Also remove leftover local variable. > > > > Cc: Peter Rosin > > Cc: Alex Deucher > > Cc: Michel Dänzer > > I don't think this e-mail address works anymore. > > > Signed-off-by: Daniel Vetter > > Reviewed-by: Michel Dänzer > Applied. Thanks! Alex > > -- > Earthling Michel Dänzer | https://redhat.com > Libre software enthusiast | Mesa and X developer > ___ > 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] drm/amdgpu: Fix implicit enum conversion in gfx_v9_4_ras_error_inject
On Thu, Jan 30, 2020 at 3:33 AM Nathan Chancellor
wrote:
>
> Clang warns:
>
> ../drivers/gpu/drm/amd/amdgpu/gfx_v9_4.c:967:35: warning: implicit
> conversion from enumeration type 'enum amdgpu_ras_block' to different
> enumeration type 'enum ta_ras_block' [-Wenum-conversion]
> block_info.block_id = info->head.block;
> ~ ~~~^
> 1 warning generated.
>
> Use the function added in commit 828cfa29093f ("drm/amdgpu: Fix amdgpu
> ras to ta enums conversion") that handles this conversion explicitly.
>
> Fixes: 4c461d89db4f ("drm/amdgpu: add RAS support for the gfx block of
> Arcturus")
> Link: https://github.com/ClangBuiltLinux/linux/issues/849
> Signed-off-by: Nathan Chancellor
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v9_4.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_4.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v9_4.c
> index e19d275f3f7d..f099f13d7f1e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_4.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_4.c
> @@ -964,7 +964,7 @@ int gfx_v9_4_ras_error_inject(struct amdgpu_device *adev,
> void *inject_if)
> if (!amdgpu_ras_is_supported(adev, AMDGPU_RAS_BLOCK__GFX))
> return -EINVAL;
>
> - block_info.block_id = info->head.block;
> + block_info.block_id = amdgpu_ras_block_to_ta(info->head.block);
> block_info.sub_block_index = info->head.sub_block_index;
> block_info.inject_error_type =
> amdgpu_ras_error_to_ta(info->head.type);
> block_info.address = info->address;
> --
> 2.25.0
>
> ___
> 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 0/2] Add support for EDT ETM043080DH6-GP
Hi Marian-Christian. Thanks for the quick reponse. On Thu, Jan 30, 2020 at 12:08:36PM +, Marian-Cristian Rotariu wrote: > Second version of patch-set that adds support for EDT ETM043080DH6-GP. This > is a 480x272 TFT Display with capacitive touchscreen and it is compatible > with the simple panel driver. > > We have tested it with our iWave-G22D Generic SODIMM Development Board. > > In v2, after Sam Ravnborg's review, I've rebased the patches against > drm-misc-next and modified the proper bindings file for the simple panels. > > I have also added the mandatory connector-type field and corrected the bus > type as it is a 18bbp, therefore an RGB666. > > Unfortunately, we do not have access to the datasheet, therefore we could > not use the display_timings format. > > Marian-Cristian Rotariu (2): > dt-bindings: display: Add bindings for EDT panel > drm/panel: simple: Add EDT panel support Applied to drm-misc-next and pushed out. Note: Will hit next merge window, as it is too late for the current merge window. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206351] RX 5600 XT Not Correctly Recognized, Max Memory Frequency Below Where it Should Be
https://bugzilla.kernel.org/show_bug.cgi?id=206351 --- Comment #3 from Matt McDonald (gardotd...@gmail.com) --- This is the card and its specifications from the official website: https://www.sapphiretech.com/en/consumer/pulse-radeon-rx-5600-xt-6g-gddr6#Specification As you'll see, memory clock is supposed to be 14Gbps on the new vBIOS, which is equal to 1750MHz, which is exactly what GPU-z reports on Windows (as does every other piece of GPU monitoring software like MSI Afterburner and Radeon Wattman). And if you look at the specs for the card with the old performance vBIOS, it was 12Gbps effective which is 1500MHz, and again GPU-z and every other windows utility correctly reports this. Also, Linux correctly reports memory clock frequency for older cards like the RX 580, my XFX GTS XXX model was correctly reported at memory clock boosting to 1750 MHz However with the 5600 XT, even with overclocking enabled, the powerplay tables range is only 930MHz at the maximum end. -- 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
[PATCH] drm/mediatek: Ensure the cursor plane is on top of other overlays
From: Sean Paul
Currently the cursor is placed on the first overlay plane, which means
it will be at the bottom of the stack when the hw does the compositing
with anything other than primary plane. Since mtk doesn't support plane
zpos, change the cursor location to the top-most plane.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 0dfcd1787e651..4ac76b9613926 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -689,11 +689,12 @@ static int mtk_drm_crtc_num_comp_planes(struct
mtk_drm_crtc *mtk_crtc,
}
static inline
-enum drm_plane_type mtk_drm_crtc_plane_type(unsigned int plane_idx)
+enum drm_plane_type mtk_drm_crtc_plane_type(unsigned int plane_idx,
+ unsigned int num_planes)
{
if (plane_idx == 0)
return DRM_PLANE_TYPE_PRIMARY;
- else if (plane_idx == 1)
+ else if (plane_idx == (num_planes - 1))
return DRM_PLANE_TYPE_CURSOR;
else
return DRM_PLANE_TYPE_OVERLAY;
@@ -712,7 +713,8 @@ static int mtk_drm_crtc_init_comp_planes(struct drm_device
*drm_dev,
ret = mtk_plane_init(drm_dev,
&mtk_crtc->planes[mtk_crtc->layer_nr],
BIT(pipe),
- mtk_drm_crtc_plane_type(mtk_crtc->layer_nr),
+ mtk_drm_crtc_plane_type(mtk_crtc->layer_nr,
+ num_planes),
mtk_ddp_comp_supported_rotations(comp));
if (ret)
return ret;
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/panel: Add a driver for Samsung s6e88a0-ams452ef01 panel
Hi Michael.
On Thu, Jan 30, 2020 at 08:02:31PM +0100, Michael Srba wrote:
> Sending this with thunderbird, fingers crossed for no formatting issues
Readable...
>
> Hi,
> I've taken about two weeks to send zinitix v2, and haven't heard about
> that or
> v3 yet, so combined with how easy it was to address the issues, I didn't
> want
> to risk that was the reason :)
> I'm not sure how I should make the subject shorter, it's already pretty
> barebones, so if it has to be done, I assume you would have a suggestion
> on what
> is not as important as it seems to me?
> I'm also not sure if splitting the comment on line 78 to three lines
> (two seem
> to not suffice) wouldn't be even worse than leaving it like this? Or
> should I
> have it more to the left so that it fits on just two lines?
> Similarly, I'm not sure what the convention for splitting would be on
> line 25,
> since I saw the line breaks placed mostly after a whole function parameter.
> Actually, for all of the above-80 lines except the one that I missed when
> updating it today I don't really know how to handle them... except maybe
> line
> 139, I guess I missed that since it's off-by-one
Address what you think needs to be addressed.
If I feel strong about some of the remaining warnings I
will fix when applying.
And let you know what I did if this is the case.
Sam
>
> On 30. 01. 20 19:28, Sam Ravnborg wrote:
> > Hi Micahel.
> >
> > Thanks for the quick feedback.
> >
> > Please address checkpatch warnings.
> >
> > be2b44c76320 (HEAD -> drm-misc-next) drm/panel: Add a driver for Samsung
> > s6e88a0-ams452ef01 panel
> > -:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an
> > appropriate one
> >
> > -:40: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
> > MAINTAINERS need updating?
> > #40:
> > new file mode 100644
> >
> > -:69: WARNING:LONG_LINE: line over 80 characters
> > #69: FILE: drivers/gpu/drm/panel/panel-samsung-s6e88a0-ams452ef01.c:25:
> > +static inline struct s6e88a0_ams452ef01 *to_s6e88a0_ams452ef01(struct
> > drm_panel *panel)
> >
> > -:74: WARNING:MACRO_WITH_FLOW_CONTROL: Macros with flow control statements
> > should be avoided
> > #74: FILE: drivers/gpu/drm/panel/panel-samsung-s6e88a0-ams452ef01.c:30:
> > +#define dsi_dcs_write_seq(dsi, seq...) do {
> > \
> > + static const u8 d[] = { seq }; \
> > + int ret;\
> > + ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d)); \
> > + if (ret < 0)\
> > + return ret; \
> > + } while (0)
> >
> > -:122: WARNING:LONG_LINE_COMMENT: line over 80 characters
> > #122: FILE: drivers/gpu/drm/panel/panel-samsung-s6e88a0-ams452ef01.c:78:
> > + dsi_dcs_write_seq(dsi, 0xb2, 0x40, 0x0a, 0x17, 0x00, 0x0a); // set
> > default Amoled Off Ratio
> >
> > -:183: WARNING:LONG_LINE: line over 80 characters
> > #183: FILE: drivers/gpu/drm/panel/panel-samsung-s6e88a0-ams452ef01.c:139:
> > + regulator_bulk_disable(ARRAY_SIZE(ctx->supplies),
> > ctx->supplies);
> >
> > -:226: WARNING:LONG_LINE: line over 80 characters
> > #226: FILE: drivers/gpu/drm/panel/panel-samsung-s6e88a0-ams452ef01.c:182:
> > +static int s6e88a0_ams452ef01_get_modes(struct drm_panel *panel, struct
> > drm_connector *connector)
> >
> > total: 0 errors, 7 warnings, 0 checks, 308 lines checked
> >
> >
> >
> > Use: dim checkpatch" if you have dim.
> > Otherwise use checkpatch -q --emacs --strict --show-types
> >
> > Ignore the warning "MACRO_WITH_FLOW_CONTROL" - as this seems legit in this
> > use-case.
> >
> > Sam
> >
> > On Thu, Jan 30, 2020 at 06:11:28PM +0100, michael.s...@seznam.cz wrote:
> >> From: Michael Srba
> >>
> >> Signed-off-by: Michael Srba
> >> ---
> >> Changes since v1: reorder includes; remove empty functions; fix after
> >> rebasing
> >> ---
> >> drivers/gpu/drm/panel/Kconfig | 6 +
> >> drivers/gpu/drm/panel/Makefile| 1 +
> >> .../panel/panel-samsung-s6e88a0-ams452ef01.c | 289 ++
> >> 3 files changed, 296 insertions(+)
> >> create mode 100644
> >> drivers/gpu/drm/panel/panel-samsung-s6e88a0-ams452ef01.c
> >>
> >> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> >> index ae44ac2ec106..0c7d61f32b0e 100644
> >> --- a/drivers/gpu/drm/panel/Kconfig
> >> +++ b/drivers/gpu/drm/panel/Kconfig
> >> @@ -275,6 +275,12 @@ config DRM_PANEL_SAMSUNG_S6E63M0
> >> Say Y here if you want to enable support for Samsung S6E63M0
> >> AMOLED LCD panel.
> >>
> >> +config DRM_PANEL_SAMSUNG_S6E88A0_AMS452EF01
> >> + tristate "Samsung AMS452EF01 panel with S6E88A0 DSI video mode
> >> controller"
> >> + depends on OF
> >> + select DRM_MIPI_DSI
> >> + select VIDEOMODE_HELPERS
> >> +
> >> config DRM_PANEL_SAMSUNG_S6E8AA0
> >>tristate "Samsung S
Re: [PATCH 4/4] drm/i915/display: Set TRANS_DDI_MODE_SELECT to default value when disabling TRANS_DDI
On Thu, 2020-01-30 at 19:25 +0200, Ville Syrjälä wrote:
> On Thu, Jan 16, 2020 at 05:58:37PM -0800, José Roberto de Souza
> wrote:
> > TGL timeouts when disabling MST transcoder and fifo underruns over
> > MST
> > transcoders are fixed when setting TRANS_DDI_MODE_SELECT to 0(HDMI
> > mode) during the disable sequence.
> >
> > Although BSpec disable sequence don't require this step it is a
> > harmless change and it is also done by Windows driver.
> > Anyhow HW team was notified about that but it can take some time to
> > documentation to be updated.
> >
> > A case that always lead to those issues is:
> > - do a modeset enabling pipe A and pipe B in the same MST stream
> > leaving A as master
> > - disable pipe A, promote B as master doing a full modeset in A
> > - enable pipe A, changing the master transcoder back to A(doing a
> > full modeset in B)
> > - Pow: underruns and timeouts
> >
> > The transcoders involved will only work again when complete
> > disabled
> > and their power wells turned off causing a reset in their
> > registers.
> >
> > Cc: Ville Syrjälä
> > Cc: Matt Roper
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 32ea3c7e8b62..82e90f271974 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -1997,6 +1997,7 @@ void intel_ddi_disable_transcoder_func(const
> > struct intel_crtc_state *crtc_state
> >
> > val = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
> > val &= ~TRANS_DDI_FUNC_ENABLE;
> > + val &= ~TRANS_DDI_MODE_SELECT_MASK;
>
> Feels a bit early since IIRC we still leave a bunch of other stuff
> enabled/selected here. In fact we don't seem to be clearing the DDI
> select
> anywhere at all? That one I would be more suspicious of than the
> mode.
> But maybe we should just clear both somewhere? I would suggest it
> should
> be when we clear the port select finally.
We are clearing DDI select, in our code it is named as
TGL_TRANS_DDI_PORT_MASK/TRANS_DDI_PORT_MASK.
For TGL in MST mode we clear DDI select in the block below for MST
slaves and then in intel_ddi_post_disable_dp() for MST master as
instructed by Display port sequences.
>
> >
> > if (INTEL_GEN(dev_priv) >= 12) {
> > if (!intel_dp_mst_is_master_trans(crtc_state))
> > --
> > 2.25.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] drm/amd/display: REFERENCE for srm interface patches
Thanks for providing more documentation and this reference. The patch set (1-5) is Reviewed-by: Harry Wentland Harry On 2020-01-22 4:05 p.m., Bhawanpreet Lakha wrote: > This is just a reference for the patches. not to be merged > > Signed-off-by: Bhawanpreet Lakha > --- > REFERENCE | 49 + > 1 file changed, 49 insertions(+) > create mode 100644 REFERENCE > > diff --git a/REFERENCE b/REFERENCE > new file mode 100644 > index ..2e53f9cc82ff > --- /dev/null > +++ b/REFERENCE > @@ -0,0 +1,49 @@ > +SRM interface Reference Usermode scripts for ubuntu. > +These are just reference sciprts to facilitate the SRM interface for amdgpu. > + > ++-+ > +| Main script, this is called on boot/shutdown/suspend/resume , it calls the > sysfs to get/set the SRM | > +| FILE: /home/amdgpu_hdcp_srm_script.sh > | > ++-+ > +#!/bin/bash > + > +SRMFILE="/home/SRM" > +sudo cat "$SRMFILE" > /sys/class/drm/card0/device/hdcp_srm > +sudo cat /sys/class/drm/card0/device/hdcp_srm > "$SRMFILE" > + > + > + > + > + > ++-+ > +| .service file, This is placed into /etc/systemd/system/ so it runs the > main script on boot/shutdown | > +| FILE: /etc/systemd/system/amdgpu_hdc_srm_boot_shutdown.service > | > ++-+ > +[Unit] > +Description=HDCP SRM boot and shutdown save/load > + > +[Service] > +Type=simple > +ExecStart=/home/amdgpu_hdcp_srm_script.sh > +ExecStop=/home/amdgpu_hdcp_srm_script.sh > + > +[Install] > +WantedBy=multi-user.target > + > + > + > ++-+ > +| To run the script on boot/start run > | > ++-+ > +sudo systemctl start amdgpu_hdc_srm_boot_shutdown > +sudo systemctl enable amdgpu_hdc_srm_boot_shutdown > + > + > + > ++-+ > +| To symlnk the files (adding to these directory will run the script on > suspend/resume| > ++-+ > +sudo ln -s $SCRIPTFILE /lib/systemd/system-sleep/amdgpu_hdcp_srm > +sudo ln -s $SCRIPTFILE /usr/lib/pm-utils/sleep.d/95amdgpu_hdcp_srm > + > + > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mst: Fix possible NULL pointer dereference in drm_dp_mst_process_up_req()
On Thu, 2020-01-30 at 10:49 +, Lisovskiy, Stanislav wrote:
> On Wed, 2020-01-29 at 15:24 -0800, José Roberto de Souza wrote:
> > According to DP specification, DP_SINK_EVENT_NOTIFY is also a
> > broadcast message but as this function only handles
> > DP_CONNECTION_STATUS_NOTIFY I will only make the static
> > analyzer that caught this issue happy by not calling
> > drm_dp_get_mst_branch_device_by_guid() with a NULL guid, causing
> > drm_dp_mst_process_up_req() to return in the "if (!mstb)" right
> > bellow.
> >
> > Fixes: 9408cc94eb04 ("drm/dp_mst: Handle UP requests
> > asynchronously")
> > Cc: Lyude Paul
> > Cc: Sean Paul
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 23cf46bfef74..a811247cecfe 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -3829,7 +3829,8 @@ drm_dp_mst_process_up_req(struct
> > drm_dp_mst_topology_mgr *mgr,
> > else if (msg->req_type == DP_RESOURCE_STATUS_NOTIFY)
> > guid = msg->u.resource_stat.guid;
> >
> > - mstb = drm_dp_get_mst_branch_device_by_guid(mgr, guid);
> > + if (guid)
> > + mstb =
> > drm_dp_get_mst_branch_device_by_guid(mgr, guid);
> > } else {
> > mstb = drm_dp_get_mst_branch_device(mgr, hdr->lct, hdr-
> > > rad);
> > }
>
> Been fixing something similar in dp mst topology a while ago, was
> also
> similar NULL pointer dereference. Fix seems to be correct, however I
> would still have a look at least, how it affects overall logic then.
> I mean now we don't call drm_dp_get_mst_branch_device_by_guid if guid
> is NULL - that's ok, however it means that mstb will not get
> initialized and how this is going to affect the code flow then?
>
> SHould we may be still try to initialize mstb somehow and check
> guid actually inside of this drm_dp_get_mst_branch_device_by_guid
> function? Or call drm_dp_get_mst_branch_device?
>
> I'm not stating anything here, just asking question to
> make the overall picture bit more clear.
Well it do not matters if it set mstb if on the next block it will only
handle messages of DP_CONNECTION_STATUS_NOTIFY type but for sure we
should handle this two other message types.
>
> Anyways, even wrong logic to me is better than crashing so,
>
> Reviewed-by: Stanislav Lisovskiy
Thanks
>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] dt-bindings: display/panel: add bindings for S6E88A0-AMS452EF01
Hi Michael.
I fixed the following:
- added .yaml extension to $id
- added a dsi node to the example, and added #address-cells/size-cells
to fix dt_binding_check warnings
With these fixes - applied to drm-misc-next.
Sam
On Thu, Jan 30, 2020 at 09:35:54PM +0100, michael.s...@seznam.cz wrote:
> From: Michael Srba
>
> This patch adds dts bindings for Samsung AMS452EF01 AMOLED panel, which makes
> use of their S6E88A0 controller.
>
> Signed-off-by: Michael Srba
> ---
> Hi,
> I recall now that tabs cause a syntax error in yaml, should be easy to check
> in checkpatch.pl?
> I hope there are no more embarassing oversights left.
>
> Changes in v2: use yaml format for the binding
> Changes in v3: fix oversights too embarassing to admit here
> ---
> .../panel/samsung,s6e88a0-ams452ef01.yaml | 46 +++
> 1 file changed, 46 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/samsung,s6e88a0-ams452ef01.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/samsung,s6e88a0-ams452ef01.yaml
>
> b/Documentation/devicetree/bindings/display/panel/samsung,s6e88a0-ams452ef01.yaml
> new file mode 100644
> index ..298fc9a78297
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/panel/samsung,s6e88a0-ams452ef01.yaml
> @@ -0,0 +1,46 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/samsung,s6e88a0-ams452ef01#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Samsung AMS452EF01 AMOLED panel with S6E88A0 video mode DSI controller
> +
> +maintainers:
> + - Michael Srba
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +const: samsung,s6e88a0-ams452ef01
> + reg: true
> + reset-gpios: true
> + vdd3-supply:
> + description: core voltage supply
> + vci-supply:
> + description: voltage supply for analog circuits
> +
> +required:
> + - compatible
> + - reg
> + - vdd3-supply
> + - vci-supply
> + - reset-gpios
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +panel@0 {
> +reg = <0>;
> +
> +compatible = "samsung,s6e88a0-ams452ef01";
> +
> +vdd3-supply = <&pm8916_l17>;
> +vci-supply = <®_vlcd_vci>;
> +reset-gpios = <&msmgpio 25 GPIO_ACTIVE_HIGH>;
> +};
> --
> 2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/2] drm/panel: Add a driver for Samsung s6e88a0-ams452ef01 panel
Hi Michael.
I fixed a few too long lines warnings.
static inline struct s6e88a0_ams452ef01 *to_s6e88a0_ams452ef01(struct drm_panel
*panel)
became:
static inline struct
s6e88a0_ams452ef01 *to_s6e88a0_ams452ef01(struct drm_panel *panel)
And another long line where the comment was moved one line up.
And finally I added a proper changelog.
With this fixed - applied to drm-misc-next.
Sam
On Thu, Jan 30, 2020 at 09:35:55PM +0100, michael.s...@seznam.cz wrote:
> From: Michael Srba
>
> Signed-off-by: Michael Srba
> ---
> Changes in v2: reorder includes; remove empty functions; fix after rebasing
> Changes in v3: fix straightforward line-over-80-chars issues
> ---
> drivers/gpu/drm/panel/Kconfig | 6 +
> drivers/gpu/drm/panel/Makefile| 1 +
> .../panel/panel-samsung-s6e88a0-ams452ef01.c | 291 ++
> 3 files changed, 298 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e88a0-ams452ef01.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index ae44ac2ec106..0c7d61f32b0e 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -275,6 +275,12 @@ config DRM_PANEL_SAMSUNG_S6E63M0
> Say Y here if you want to enable support for Samsung S6E63M0
> AMOLED LCD panel.
>
> +config DRM_PANEL_SAMSUNG_S6E88A0_AMS452EF01
> + tristate "Samsung AMS452EF01 panel with S6E88A0 DSI video mode
> controller"
> + depends on OF
> + select DRM_MIPI_DSI
> + select VIDEOMODE_HELPERS
> +
> config DRM_PANEL_SAMSUNG_S6E8AA0
> tristate "Samsung S6E8AA0 DSI video mode panel"
> depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index 7c4d3c581fd4..5b622fbe4014 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -28,6 +28,7 @@ obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6D16D0) +=
> panel-samsung-s6d16d0.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03) += panel-samsung-s6e63j0x03.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63M0) += panel-samsung-s6e63m0.o
> +obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E88A0_AMS452EF01) +=
> panel-samsung-s6e88a0-ams452ef01.o
> obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
> obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o
> obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
> diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e88a0-ams452ef01.c
> b/drivers/gpu/drm/panel/panel-samsung-s6e88a0-ams452ef01.c
> new file mode 100644
> index ..14d983f70226
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-samsung-s6e88a0-ams452ef01.c
> @@ -0,0 +1,291 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +// Copyright (C) 2019, Michael Srba
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +#include
> +
> +struct s6e88a0_ams452ef01 {
> + struct drm_panel panel;
> + struct mipi_dsi_device *dsi;
> + struct regulator_bulk_data supplies[2];
> + struct gpio_desc *reset_gpio;
> +
> + bool prepared;
> +};
> +
> +static inline struct s6e88a0_ams452ef01 *to_s6e88a0_ams452ef01(struct
> drm_panel *panel)
> +{
> + return container_of(panel, struct s6e88a0_ams452ef01, panel);
> +}
> +
> +#define dsi_dcs_write_seq(dsi, seq...) do { \
> + static const u8 d[] = { seq }; \
> + int ret;\
> + ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d)); \
> + if (ret < 0)\
> + return ret; \
> + } while (0)
> +
> +static void s6e88a0_ams452ef01_reset(struct s6e88a0_ams452ef01 *ctx)
> +{
> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> + usleep_range(5000, 6000);
> + gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> + usleep_range(1000, 2000);
> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> + usleep_range(1, 11000);
> +}
> +
> +static int s6e88a0_ams452ef01_on(struct s6e88a0_ams452ef01 *ctx)
> +{
> + struct mipi_dsi_device *dsi = ctx->dsi;
> + struct device *dev = &dsi->dev;
> + int ret;
> +
> + dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> +
> + dsi_dcs_write_seq(dsi, 0xf0, 0x5a, 0x5a); // enable LEVEL2 commands
> + dsi_dcs_write_seq(dsi, 0xcc, 0x4c); // set Pixel Clock Divider polarity
> +
> + ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
> + if (ret < 0) {
> + dev_err(dev, "Failed to exit sleep mode: %d\n", ret);
> + return ret;
> + }
> + msleep(120);
> +
> + // set default brightness/gama
> + dsi_dcs_write_seq(dsi, 0xca,
> + 0x01, 0x00, 0x01, 0x00, 0x01, 0x00, // V255 RR,GG,BB
> +
[Bug 206351] RX 5600 XT Not Correctly Recognized, Max Memory Frequency Below Where it Should Be
https://bugzilla.kernel.org/show_bug.cgi?id=206351 --- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) --- (In reply to Matt McDonald from comment #3) > This is the card and its specifications from the official website: > https://www.sapphiretech.com/en/consumer/pulse-radeon-rx-5600-xt-6g- > gddr6#Specification > The 1750 Mhz clock on the webpage is the engine boost clock which is inline with the settings for your card. OD_SCLK: 1: 1780Mhz With respect to the memory clock, The default clock on your board is 900Mhz and it has a 192 bit interface. GDDR6 sends data on the rising and falling edge of the wave, so you multiply it by two. Hence: OD_MCLK: 1: 900MHz 900 Mhz * 192 bit * 2 = 345,600 Mbps = 337.5 Gbps Which is right in line with the bandwidth for your card. -- 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] drm/mst: Fix possible NULL pointer dereference in drm_dp_mst_process_up_req()
Reviewed-by: Lyude Paul
I'll go ahead and push this now, thanks!
On Wed, 2020-01-29 at 15:24 -0800, José Roberto de Souza wrote:
> According to DP specification, DP_SINK_EVENT_NOTIFY is also a
> broadcast message but as this function only handles
> DP_CONNECTION_STATUS_NOTIFY I will only make the static
> analyzer that caught this issue happy by not calling
> drm_dp_get_mst_branch_device_by_guid() with a NULL guid, causing
> drm_dp_mst_process_up_req() to return in the "if (!mstb)" right
> bellow.
>
> Fixes: 9408cc94eb04 ("drm/dp_mst: Handle UP requests asynchronously")
> Cc: Lyude Paul
> Cc: Sean Paul
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 23cf46bfef74..a811247cecfe 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3829,7 +3829,8 @@ drm_dp_mst_process_up_req(struct
> drm_dp_mst_topology_mgr *mgr,
> else if (msg->req_type == DP_RESOURCE_STATUS_NOTIFY)
> guid = msg->u.resource_stat.guid;
>
> - mstb = drm_dp_get_mst_branch_device_by_guid(mgr, guid);
> + if (guid)
> + mstb = drm_dp_get_mst_branch_device_by_guid(mgr,
> guid);
> } else {
> mstb = drm_dp_get_mst_branch_device(mgr, hdr->lct, hdr->rad);
> }
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/dp_mst: Fix W=1 warnings
On Mon, 2020-01-27 at 14:08 +0100, Benjamin Gaignard wrote:
> Le ven. 24 janv. 2020 à 23:08, Lyude Paul a écrit :
> > On Tue, 2020-01-07 at 14:11 +0100, Benjamin Gaignard wrote:
> > > Le ven. 20 déc. 2019 à 15:03, Benjamin Gaignard
> > > a écrit :
> > > > Le lun. 16 déc. 2019 à 09:28, Benjamin Gaignard
> > > > a écrit :
> > > > > Le mer. 4 déc. 2019 à 17:47, Jani Nikula <
> > > > > jani.nik...@linux.intel.com> a
> > > > > écrit :
> > > > > > On Thu, 28 Nov 2019, Benjamin Gaignard
> > > > > > wrote:
> > > > > > > Fix the warnings that show up with W=1.
> > > > > > > They are all about unused but set variables.
> > > > > > > If functions returns are not used anymore make them void.
> > > > > > >
> > > > > > > Signed-off-by: Benjamin Gaignard
> > > > > > > ---
> > > > > > > CC: Jani Nikula
> > > > > > >
> > > > > > > changes in version 3:
> > > > > > > - remove the hunk that may conflict with c485e2c97dae
> > > > > > > ("drm/dp_mst: Refactor pdt setup/teardown, add more locking")
> > > > > > >
> > > > > > > changes in version 2:
> > > > > > > - fix indentations
> > > > > > > - when possible change functions prototype to void
> > > > > > >
> > > > > > > drivers/gpu/drm/drm_dp_mst_topology.c | 83 +--
> > > > > > >
> > > > > > >
> > > > > > > 1 file changed, 31 insertions(+), 52 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > > > index 1437bc46368b..d5cb5688b5dd 100644
> > > > > > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > > > > @@ -674,7 +674,6 @@ static bool drm_dp_sideband_msg_build(struct
> > > > > > > drm_dp_sideband_msg_rx *msg,
> > > > > > > u8 *replybuf, u8
> > > > > > > replybuflen,
> > > > > > > bool hdr)
> > > > > > > {
> > > > > > > int ret;
> > > > > > > - u8 crc4;
> > > > > > >
> > > > > > > if (hdr) {
> > > > > > > u8 hdrlen;
> > > > > > > @@ -716,8 +715,6 @@ static bool drm_dp_sideband_msg_build(struct
> > > > > > > drm_dp_sideband_msg_rx *msg,
> > > > > > > }
> > > > > > >
> > > > > > > if (msg->curchunk_idx >= msg->curchunk_len) {
> > > > > > > - /* do CRC */
> > > > > > > - crc4 = drm_dp_msg_data_crc4(msg->chunk, msg-
> > > > > > > > curchunk_len - 1);
> > > > > >
> > > > > > Again, someone needs to check if crc4 should be *used* instead of
> > > > > > thrown
> > > > > > away. Blindly throwing stuff out is not the way to go.
> > > > >
> > > > > Hi Dave,
> > > > >
> > > >
> > > > + Lyude who has been hacking in this code recently
> > >
> > > gentle ping for the reviewers,
> > >
> > hi-actually yes, we should probably be using this instead of just dropping
> > this. Also, I didn't write this code originally I just refactored a bunch
> > of
> > it - Dave Airlied is the original author, but the original version of this
> > code was written ages ago. tbh, I think it's a safe bet to say that they
> > probably did mean to use this but forgot to and no one noticed until now.
>
> Hi,
>
> Any clue about how to use crc value ? Does it have to be checked
> against something else ?
> If crc are not matching what should we do of the data copied just before ?
We should be able to just take the CRC value from the sideband message and
then generate our own CRC value using the sideband message contents, and check
if the two are equal. If they aren't, something went wrong and we didn't
receive the message properly.
Now as to what we should do when we have CRC mismatches? That's a bit more
difficult. If you have access to the DP MST spec, I suppose a place to start
figuring that out would be checking if there's a way for us to request that a
branch device resend whatever message it sent previously. If there isn't, I
guess we should just print an error in dmesg (possibly with a hexdump of the
failed message as well) and not forward the message to the driver. Not sure of
any better way of handling it then that
>
> Benjamin
>
> > > Thanks,
> > > Benjamin
> > > > > Your are the original writer of this code, could you tell us if we
> > > > > can
> > > > > drop crc4
> > > > > ao if there is something else that I have misunderstood ?
> > > > >
> > > > > Thanks,
> > > > > Benjamin
> > > > >
> > > > > > BR,
> > > > > > Jani.
> > > > > >
> > > > > > > /* copy chunk into bigger msg */
> > > > > > > memcpy(&msg->msg[msg->curlen], msg->chunk, msg-
> > > > > > > > curchunk_len - 1);
> > > > > > > msg->curlen += msg->curchunk_len - 1;
> > > > > > > @@ -1014,7 +1011,7 @@ static bool
> > > > > > > drm_dp_sideband_parse_req(struct
> > > > > > > drm_dp_sideband_msg_rx *raw,
> > > > > > > }
> > > > > > > }
> > > > > > >
> > > > > > > -static int build_dpcd_write(struct drm_dp_sideband_msg_tx *msg,
> > > > > > > u8
> > > > > > > port_num, u32 of
Re: [PATCH v3] drm/dp_mst: Fix W=1 warnings
> > > > > > > hi-actually yes, we should probably be using this instead of just dropping > > > this. Also, I didn't write this code originally I just refactored a bunch > > > of > > > it - Dave Airlied is the original author, but the original version of this > > > code was written ages ago. tbh, I think it's a safe bet to say that they > > > probably did mean to use this but forgot to and no one noticed until now. > > > > Hi, > > > > Any clue about how to use crc value ? Does it have to be checked > > against something else ? > > If crc are not matching what should we do of the data copied just before ? > > We should be able to just take the CRC value from the sideband message and > then generate our own CRC value using the sideband message contents, and check > if the two are equal. If they aren't, something went wrong and we didn't > receive the message properly. > > Now as to what we should do when we have CRC mismatches? That's a bit more > difficult. If you have access to the DP MST spec, I suppose a place to start > figuring that out would be checking if there's a way for us to request that a > branch device resend whatever message it sent previously. If there isn't, I > guess we should just print an error in dmesg (possibly with a hexdump of the > failed message as well) and not forward the message to the driver. Not sure of > any better way of handling it then that Yeah I think this reflects what I wanted to do, I've no memory of a retransmit option in the spec, but I've away from it for a while. But we'd want to compare the CRC with what we got to make sure the are the same. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] Security mitigation for Intel Gen7/7.5 HWs
Intel ID: PSIRT-TA-201910-001 CVEID: CVE-2019-14615 Summary of Vulnerability Insufficient control flow in certain data structures for some Intel(R) Processors with Intel Processor Graphics may allow an unauthenticated user to potentially enable information disclosure via local access Products affected: -- Intel CPU’s with Gen7, Gen7.5 and Gen9 Graphics. Mitigation Summary -- This patch provides mitigation for Gen7 and Gen7.5 hardware only. Patch for Gen9 devices have been provided and merged to Linux mainline, and backported to stable kernels. Note that Gen8 is not impacted due to a previously implemented workaround. The mitigation involves submitting a custom EU kernel prior to every context restore, in order to forcibly clear down residual EU and URB resources. This security mitigation change does not trigger any known performance regression. Performance is on par with current mainline/drm-tip. Note on Address Space Isolation (Full PPGTT) Isolation of EU kernel assets should be considered complementary to the existing support for address space isolation (aka Full PPGTT), since without address space isolation there is minimal value in preventing leakage between EU contexts. Full PPGTT has long been supported on Gen Gfx devices since Gen8, and protection against EU residual leakage is a welcome addition for these newer platforms. By contrast, Gen7 and Gen7.5 device introduced Full PPGTT support only as a hardware development feature for anticipated Gen8 productization. Support was never intended for, or provided to the Linux kernels for these platforms. Recent work (still ongoing) to the mainline kernel is retroactively providing this support, but due to the level of complexity it is not practical to attempt to backport this to earlier stable kernels. Since without Full PPGTT, EU residuals protection has questionable benefit, *there are no plans to provide stable kernel backports for this patch series.* Mika Kuoppala (1): drm/i915: Add mechanism to submit a context WA on ring submission Prathap Kumar Valsan (1): drm/i915/gen7: Clear all EU/L3 residual contexts drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gt/gen7_renderclear.c| 535 ++ drivers/gpu/drm/i915/gt/gen7_renderclear.h| 15 + drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 17 +- .../gpu/drm/i915/gt/intel_ring_submission.c | 133 - drivers/gpu/drm/i915/i915_utils.h | 5 + 6 files changed, 700 insertions(+), 6 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.c create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.h -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/i915/gen7: Clear all EU/L3 residual contexts
From: Prathap Kumar Valsan
On gen7 and gen7.5 devices, there could be leftover data residuals in
EU/L3 from the retiring context. This patch introduces workaround to clear
that residual contexts, by submitting a batch buffer with dedicated HW
context to the GPU with ring allocation for each context switching.
This security mitigation change does not trigger any performance
regression. Performance is on par with current mainline/drm-tip.
Signed-off-by: Mika Kuoppala
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Akeem G Abodunrin
Cc: Chris Wilson
Cc: Balestrieri Francesco
Cc: Bloomfield Jon
Cc: Dutt Sudeep
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/gen7_renderclear.c| 535 ++
drivers/gpu/drm/i915/gt/gen7_renderclear.h| 15 +
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 17 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 3 +-
drivers/gpu/drm/i915/i915_utils.h | 5 +
6 files changed, 572 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.c
create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 3c88d7d8c764..f96bae664a03 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -78,6 +78,7 @@ gt-y += \
gt/debugfs_gt.o \
gt/debugfs_gt_pm.o \
gt/gen6_ppgtt.o \
+ gt/gen7_renderclear.o \
gt/gen8_ppgtt.o \
gt/intel_breadcrumbs.o \
gt/intel_context.o \
diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.c
b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
new file mode 100644
index ..a6f5f1602e33
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
@@ -0,0 +1,535 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include "gen7_renderclear.h"
+#include "i915_drv.h"
+#include "i915_utils.h"
+#include "intel_gpu_commands.h"
+
+#define MAX_URB_ENTRIES 64
+#define STATE_SIZE (4 * 1024)
+#define GT3_INLINE_DATA_DELAYS 0x1E00
+#define batch_advance(Y, CS) GEM_BUG_ON((Y)->end != (CS))
+
+/*
+ * Media CB Kernel for gen7 devices
+ * TODO: Add comments to kernel, indicating what each array of hex does or
+ * include header file, which has assembly source and support in igt to be
+ * able to generate kernel in this same format
+ */
+static const u32 cb7_kernel[][4] = {
+ { 0x0001, 0x26020128, 0x0024, 0x },
+ { 0x0040, 0x20280c21, 0x0028, 0x0001 },
+ { 0x0110, 0x2c20, 0x002c, 0x },
+ { 0x00010220, 0x34001c00, 0x1400, 0x002c },
+ { 0x0061, 0x20600061, 0x, 0x },
+ { 0x0008, 0x20601c85, 0x0e00, 0x000c },
+ { 0x0005, 0x20601ca5, 0x0060, 0x0001 },
+ { 0x0008, 0x20641c85, 0x0e00, 0x000d },
+ { 0x0005, 0x20641ca5, 0x0064, 0x0003 },
+ { 0x0041, 0x207424a5, 0x0064, 0x0034 },
+ { 0x0040, 0x206014a5, 0x0060, 0x0074 },
+ { 0x0008, 0x20681c85, 0x0e00, 0x0008 },
+ { 0x0005, 0x20681ca5, 0x0068, 0x000f },
+ { 0x0041, 0x20701ca5, 0x0060, 0x0010 },
+ { 0x0040, 0x206814a5, 0x0068, 0x0070 },
+ { 0x0061, 0x20a00061, 0x, 0x },
+ { 0x0005, 0x206c1c85, 0x0e00, 0x0007 },
+ { 0x0041, 0x206c1ca5, 0x006c, 0x0004 },
+ { 0x0061, 0x20800021, 0x008d, 0x },
+ { 0x0001, 0x20800021, 0x006c, 0x },
+ { 0x0001, 0x20840021, 0x0068, 0x },
+ { 0x0001, 0x20880061, 0x, 0x0003 },
+ { 0x0005, 0x208c0d21, 0x0086, 0x },
+ { 0x05600032, 0x20a01fa1, 0x008d0080, 0x02190001 },
+ { 0x0040, 0x20a01ca5, 0x00a0, 0x0001 },
+ { 0x05600032, 0x20a01fa1, 0x008d0080, 0x040a8001 },
+ { 0x0240, 0x20281c21, 0x0028, 0x },
+ { 0x00010220, 0x34001c00, 0x1400, 0xfffc },
+ { 0x0001, 0x26020128, 0x0024, 0x },
+ { 0x0001, 0x22e4, 0x, 0x },
+ { 0x0001, 0x220801ec, 0x, 0x007f007f },
+ { 0x0061, 0x20400021, 0x008d, 0x },
+ { 0x0061, 0x2fe00021, 0x008d, 0x },
+ { 0x0021, 0x20400121, 0x00450020, 0x },
+ { 0x0001, 0x20480061, 0x, 0x000f000f },
+ { 0x0005, 0x204c0d21, 0x0046, 0xffef },
+ { 0x0081, 0x20600061, 0x, 0x },
+ { 0x0081, 0x20800061, 0x, 0x },
+ { 0x0081, 0x20a00061, 0x, 0x },
+ { 0x0081, 0x20c00061, 0x, 0x },
+ { 0x0081, 0x20e00061, 0x, 0x },
+ { 0x0081, 0x2161, 0x, 0x },
+ { 0x0081, 0x21
[PATCH 1/2] drm/i915: Add mechanism to submit a context WA on ring submission
From: Mika Kuoppala
This patch adds framework to submit an arbitrary batchbuffer on each
context switch to clear residual state for render engine on Gen7/7.5
devices.
The idea of always emitting the context and vm setup around each request
is primary to make reset recovery easy, and not require rewriting the
ringbuffer. As each request would set up its own context, leaving it to
the HW to notice and elide no-op context switches, we could restart the
ring at any point, and reorder the requests freely.
However, to avoid emitting clear_residuals() between consecutive requests
in the ringbuffer of the same context, we do want to track the current
context in the ring. In doing so, we need to be careful to only record a
context switch when we are sure the next request will be emitted.
This security mitigation change does not trigger any performance
regression. Performance is on par with current mainline/drm-tip.
Signed-off-by: Mika Kuoppala
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Akeem G Abodunrin
Cc: Chris Wilson
Cc: Balestrieri Francesco
Cc: Bloomfield Jon
Cc: Dutt Sudeep
---
.../gpu/drm/i915/gt/intel_ring_submission.c | 132 +-
1 file changed, 129 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 9aa86ba15ce7..9f3bfe499446 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -1385,7 +1385,9 @@ static int load_pd_dir(struct i915_request *rq,
return rq->engine->emit_flush(rq, EMIT_FLUSH);
}
-static inline int mi_set_context(struct i915_request *rq, u32 flags)
+static inline int mi_set_context(struct i915_request *rq,
+struct intel_context *ce,
+u32 flags)
{
struct drm_i915_private *i915 = rq->i915;
struct intel_engine_cs *engine = rq->engine;
@@ -1460,7 +1462,7 @@ static inline int mi_set_context(struct i915_request *rq,
u32 flags)
*cs++ = MI_NOOP;
*cs++ = MI_SET_CONTEXT;
- *cs++ = i915_ggtt_offset(rq->context->state) | flags;
+ *cs++ = i915_ggtt_offset(ce->state) | flags;
/*
* w/a: MI_SET_CONTEXT must always be followed by MI_NOOP
* WaMiSetContext_Hang:snb,ivb,vlv
@@ -1575,13 +1577,56 @@ static int switch_mm(struct i915_request *rq, struct
i915_address_space *vm)
return rq->engine->emit_flush(rq, EMIT_INVALIDATE);
}
+static int clear_residuals(struct i915_request *rq)
+{
+ struct intel_engine_cs *engine = rq->engine;
+ int ret;
+
+ GEM_BUG_ON(!engine->kernel_context->state);
+
+ ret = switch_mm(rq, vm_alias(engine->kernel_context));
+ if (ret)
+ return ret;
+
+ ret = mi_set_context(rq,
+engine->kernel_context,
+MI_MM_SPACE_GTT | MI_RESTORE_INHIBIT);
+ if (ret)
+ return ret;
+
+ ret = engine->emit_bb_start(rq,
+ engine->wa_ctx.vma->node.start, 0,
+ 0);
+ if (ret)
+ return ret;
+
+ ret = engine->emit_flush(rq, EMIT_FLUSH);
+ if (ret)
+ return ret;
+
+ /* Always invalidate before the next switch_mm() */
+ return engine->emit_flush(rq, EMIT_INVALIDATE);
+}
+
static int switch_context(struct i915_request *rq)
{
+ struct intel_engine_cs *engine = rq->engine;
struct intel_context *ce = rq->context;
+ void **residuals = NULL;
int ret;
GEM_BUG_ON(HAS_EXECLISTS(rq->i915));
+ if (engine->wa_ctx.vma && ce != engine->kernel_context) {
+ if (engine->wa_ctx.vma->private != ce) {
+ ret = clear_residuals(rq);
+ if (ret)
+ return ret;
+
+ residuals = &engine->wa_ctx.vma->private;
+ }
+ }
+
ret = switch_mm(rq, vm_alias(ce));
if (ret)
return ret;
@@ -1601,7 +1646,7 @@ static int switch_context(struct i915_request *rq)
else
flags |= MI_RESTORE_INHIBIT;
- ret = mi_set_context(rq, flags);
+ ret = mi_set_context(rq, ce, flags);
if (ret)
return ret;
}
@@ -1610,6 +1655,20 @@ static int switch_context(struct i915_request *rq)
if (ret)
return ret;
+ /*
+* Now past the point of no return, this request _will_ be emitted.
+*
+* Or at least this preamble will be emitted, the request may be
+* interrupted prior to submitting the user payload. If so, we
+* still submit the "empty" request in order to preserve global
+* state tracking such as this, our tracking of the current
+* dirty context.
+*/
+ if (resid
Re: [Intel-gfx] [PATCH 3/4] drm/i915/display: Remove useless call intel_dp_mst_encoder_cleanup()
On Thu, 2020-01-30 at 19:16 +0200, Ville Syrjälä wrote:
> On Thu, Jan 16, 2020 at 05:58:36PM -0800, José Roberto de Souza
> wrote:
> > This is a eDP function and it will always returns true for non-eDP
> > ports.
> >
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 4074d83b1a5f..a50b5b6dd009 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -7537,7 +7537,6 @@ intel_dp_init_connector(struct
> > intel_digital_port *intel_dig_port,
> >
> > if (!intel_edp_init_connector(intel_dp, intel_connector)) {
> > intel_dp_aux_fini(intel_dp);
> > - intel_dp_mst_encoder_cleanup(intel_dig_port);
>
> This makes the unwind look incomplete to the causual reader. The
> cleanup
> function does both anyway so cross checking is harder if they're not
> consistent. So not sure I like it. Hmm. The ordering of these two
> also
> looks off here.
>
> Maybe nicer to just move the whole onion to the end of function
> (we alredy have one layer there)?
If I need to rework the 4/4 patch I will do that, otherwise I will just
ignore this patch.
Please check my answer to your comment.
>
> > goto fail;
> > }
> >
> > --
> > 2.25.0
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206351] RX 5600 XT Not Correctly Recognized, Max Memory Frequency Below Where it Should Be
https://bugzilla.kernel.org/show_bug.cgi?id=206351 --- Comment #5 from Matt McDonald (gardotd...@gmail.com) --- I'm not referring to the 1750MHz boost clock. I'm referring to the 14Gbps Memory clock on the same page. Which is 1750MHz (1750Mhz * 8 octopumped GDDR6 = 14Gbps or 14GT/s, which is the stated memory frequency of the card) . Which is how it's reported in Windows as well. Like explained on here: https://forums.tomshardware.com/threads/effective-memory-clock-speed-confusions.3518637/ and here: https://www.techpowerup.com/forums/threads/how-to-calculate-gddr6-speed-from-gpu-z.250747/ Literally everything I can find has said to calculate the GDDR6 clock frequency as DOUBLE(DoubleDataRate, so x2) rate and Quad(x4) pumped, so 1750 * 2 * 4 = 14000, or 14Gbps. The specs for the card itself show it's memory frequency at 14Gbps, which fits everything I've seen. Windows reports the Memory clock (no, not the Boost clock, they're listed separately) as 1750MHz which also lines up. Am I missing something? If I am, I apologize but literally everything I can find says otherwise. If I am missing something, how does 14Gbps (which is the official memory clock frequency of the card) end up being 900MHz? -- 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] drm/mediatek: Ensure the cursor plane is on top of other overlays
Hi, Sean:
On Thu, 2020-01-30 at 14:24 -0500, Sean Paul wrote:
> From: Sean Paul
>
> Currently the cursor is placed on the first overlay plane, which means
> it will be at the bottom of the stack when the hw does the compositing
> with anything other than primary plane. Since mtk doesn't support plane
> zpos, change the cursor location to the top-most plane.
>
Reviewed-by: CK Hu
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 0dfcd1787e651..4ac76b9613926 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -689,11 +689,12 @@ static int mtk_drm_crtc_num_comp_planes(struct
> mtk_drm_crtc *mtk_crtc,
> }
>
> static inline
> -enum drm_plane_type mtk_drm_crtc_plane_type(unsigned int plane_idx)
> +enum drm_plane_type mtk_drm_crtc_plane_type(unsigned int plane_idx,
> + unsigned int num_planes)
> {
> if (plane_idx == 0)
> return DRM_PLANE_TYPE_PRIMARY;
> - else if (plane_idx == 1)
> + else if (plane_idx == (num_planes - 1))
> return DRM_PLANE_TYPE_CURSOR;
> else
> return DRM_PLANE_TYPE_OVERLAY;
> @@ -712,7 +713,8 @@ static int mtk_drm_crtc_init_comp_planes(struct
> drm_device *drm_dev,
> ret = mtk_plane_init(drm_dev,
> &mtk_crtc->planes[mtk_crtc->layer_nr],
> BIT(pipe),
> - mtk_drm_crtc_plane_type(mtk_crtc->layer_nr),
> + mtk_drm_crtc_plane_type(mtk_crtc->layer_nr,
> + num_planes),
> mtk_ddp_comp_supported_rotations(comp));
> if (ret)
> return ret;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: Possible divide by zero in set_speed()
If "speed" is zero then we use it as a divisor to find "prescale". It's
better to move the check for zero to the very start of the function.
Fixes: 9eeec26a1339 ("drm/amd/display: Refine i2c frequency calculating
sequence")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/amd/display/dc/dce/dce_i2c_hw.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_i2c_hw.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_i2c_hw.c
index 066188ba7949..24adec407972 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_i2c_hw.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_i2c_hw.c
@@ -267,6 +267,9 @@ static void set_speed(
uint32_t xtal_ref_div = 0;
uint32_t prescale = 0;
+ if (speed == 0)
+ return;
+
REG_GET(MICROSECOND_TIME_BASE_DIV, XTAL_REF_DIV, &xtal_ref_div);
if (xtal_ref_div == 0)
@@ -274,17 +277,15 @@ static void set_speed(
prescale = ((dce_i2c_hw->reference_frequency * 2) / xtal_ref_div) /
speed;
- if (speed) {
- if (dce_i2c_hw->masks->DC_I2C_DDC1_START_STOP_TIMING_CNTL)
- REG_UPDATE_N(SPEED, 3,
-FN(DC_I2C_DDC1_SPEED,
DC_I2C_DDC1_PRESCALE), prescale,
-FN(DC_I2C_DDC1_SPEED,
DC_I2C_DDC1_THRESHOLD), 2,
-FN(DC_I2C_DDC1_SPEED,
DC_I2C_DDC1_START_STOP_TIMING_CNTL), speed > 50 ? 2:1);
- else
- REG_UPDATE_N(SPEED, 2,
-FN(DC_I2C_DDC1_SPEED,
DC_I2C_DDC1_PRESCALE), prescale,
-FN(DC_I2C_DDC1_SPEED,
DC_I2C_DDC1_THRESHOLD), 2);
- }
+ if (dce_i2c_hw->masks->DC_I2C_DDC1_START_STOP_TIMING_CNTL)
+ REG_UPDATE_N(SPEED, 3,
+FN(DC_I2C_DDC1_SPEED, DC_I2C_DDC1_PRESCALE),
prescale,
+FN(DC_I2C_DDC1_SPEED, DC_I2C_DDC1_THRESHOLD), 2,
+FN(DC_I2C_DDC1_SPEED,
DC_I2C_DDC1_START_STOP_TIMING_CNTL), speed > 50 ? 2:1);
+ else
+ REG_UPDATE_N(SPEED, 2,
+FN(DC_I2C_DDC1_SPEED, DC_I2C_DDC1_PRESCALE),
prescale,
+FN(DC_I2C_DDC1_SPEED, DC_I2C_DDC1_THRESHOLD), 2);
}
static bool setup_engine(
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Nerf drm_global_mutex BKL for good drivers
This catches the majority of drivers (unfortunately not if we take
users into account, because all the big drivers have at least a
lastclose hook).
With the prep patches out of the way all drm state is fully protected
and either prevents or can deal with the races from dropping the BKL
around open/close. The only thing left to audit are the various driver
hooks - by keeping the BKL around if any of them are set we have a
very simple cop-out!
Note that one of the biggest prep pieces to get here was making
dev->open_count atomic, which was done in
commit 7e13ad896484a0165a68197a2e64091ea28c9602
Author: Chris Wilson
Date: Fri Jan 24 13:01:07 2020 +
drm: Avoid drm_global_mutex for simple inc/dec of dev->open_count
v2:
- Rebase and fix locking in drm_open() (Chris)
- Indentation fix in drm_release
- Typo fix in the commit message (Sam)
Cc: Chris Wilson
Cc: Sam Ravnborg
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 6 +++--
drivers/gpu/drm/drm_file.c | 48 +-
drivers/gpu/drm/drm_internal.h | 1 +
3 files changed, 47 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 05bdf0b9d2b3..9fcd6ab3c154 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -946,7 +946,8 @@ int drm_dev_register(struct drm_device *dev, unsigned long
flags)
struct drm_driver *driver = dev->driver;
int ret;
- mutex_lock(&drm_global_mutex);
+ if (drm_dev_needs_global_mutex(dev))
+ mutex_lock(&drm_global_mutex);
if (dev->driver->load) {
if (!drm_core_check_feature(dev, DRIVER_LEGACY))
@@ -992,7 +993,8 @@ int drm_dev_register(struct drm_device *dev, unsigned long
flags)
drm_minor_unregister(dev, DRM_MINOR_PRIMARY);
drm_minor_unregister(dev, DRM_MINOR_RENDER);
out_unlock:
- mutex_unlock(&drm_global_mutex);
+ if (drm_dev_needs_global_mutex(dev))
+ mutex_unlock(&drm_global_mutex);
return ret;
}
EXPORT_SYMBOL(drm_dev_register);
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 80d556402ab4..c4c704e01961 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -51,6 +51,37 @@
/* from BKL pushdown */
DEFINE_MUTEX(drm_global_mutex);
+bool drm_dev_needs_global_mutex(struct drm_device *dev)
+{
+ /*
+* Legacy drivers rely on all kinds of BKL locking semantics, don't
+* bother. They also still need BKL locking for their ioctls, so better
+* safe than sorry.
+*/
+ if (drm_core_check_feature(dev, DRIVER_LEGACY))
+ return true;
+
+ /*
+* The deprecated ->load callback must be called after the driver is
+* already registered. This means such drivers rely on the BKL to make
+* sure an open can't proceed until the driver is actually fully set up.
+* Similar hilarity holds for the unload callback.
+*/
+ if (dev->driver->load || dev->driver->unload)
+ return true;
+
+ /*
+* Drivers with the lastclose callback assume that it's synchronized
+* against concurrent opens, which again needs the BKL. The proper fix
+* is to use the drm_client infrastructure with proper locking for each
+* client.
+*/
+ if (dev->driver->lastclose)
+ return true;
+
+ return false;
+}
+
/**
* DOC: file operations
*
@@ -378,9 +409,10 @@ int drm_open(struct inode *inode, struct file *filp)
if (IS_ERR(minor))
return PTR_ERR(minor);
- mutex_lock(&drm_global_mutex);
-
dev = minor->dev;
+ if (drm_dev_needs_global_mutex(dev))
+ mutex_lock(&drm_global_mutex);
+
if (!atomic_fetch_inc(&dev->open_count))
need_setup = 1;
@@ -398,13 +430,15 @@ int drm_open(struct inode *inode, struct file *filp)
}
}
- mutex_unlock(&drm_global_mutex);
+ if (drm_dev_needs_global_mutex(dev))
+ mutex_unlock(&drm_global_mutex);
return 0;
err_undo:
atomic_dec(&dev->open_count);
- mutex_unlock(&drm_global_mutex);
+ if (drm_dev_needs_global_mutex(dev))
+ mutex_unlock(&drm_global_mutex);
drm_minor_release(minor);
return retcode;
}
@@ -444,7 +478,8 @@ int drm_release(struct inode *inode, struct file *filp)
struct drm_minor *minor = file_priv->minor;
struct drm_device *dev = minor->dev;
- mutex_lock(&drm_global_mutex);
+ if (drm_dev_needs_global_mutex(dev))
+ mutex_lock(&drm_global_mutex);
DRM_DEBUG("open_count = %d\n", atomic_read(&dev->open_count));
@@ -453,7 +488,8 @@ int drm_release(struct inode *inode, struct file *filp)
if (atomic_dec_and_test(&dev->open_count))
drm_lastclose(dev);
- mutex_unlock(&drm_global_mutex);
+ i
[PATCH] drm: Push drm_global_mutex locking in drm_open
We want to only take the BKL on crap drivers, but to know whether
we have a crap driver we first need to look it up. Split this shuffle
out from the main BKL-disabling patch, for more clarity. Historical
aside: When the kernel-wide BKL was removed, it was replaced by
drm_global_mutex within the scope of the drm subsystem hence why these
two things are (almost) interchangeable as concepts here.
Since the minors are refcounted drm_minor_acquire is purely internal
and this does not have a driver visible effect.
v2: Push the locking even further into drm_open(), suggested by Chris.
This gives us more symmetry with drm_release(), and maybe a futuer
avenue where we make drm_global_mutex locking (partially) opt-in like
with drm_release_noglobal().
v3:
- Actually push this stuff correctly, don't unlock twice (Chris)
- Fix typo on commit message, plus explain why BKL = drm_global_mutex
(Sam)
Cc: Sam Ravnborg
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 14 +-
drivers/gpu/drm/drm_file.c | 6 ++
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 8deff75b484c..05bdf0b9d2b3 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -1085,17 +1085,14 @@ static int drm_stub_open(struct inode *inode, struct
file *filp)
DRM_DEBUG("\n");
- mutex_lock(&drm_global_mutex);
minor = drm_minor_acquire(iminor(inode));
- if (IS_ERR(minor)) {
- err = PTR_ERR(minor);
- goto out_unlock;
- }
+ if (IS_ERR(minor))
+ return PTR_ERR(minor);
new_fops = fops_get(minor->dev->driver->fops);
if (!new_fops) {
err = -ENODEV;
- goto out_release;
+ goto out;
}
replace_fops(filp, new_fops);
@@ -1104,10 +1101,9 @@ static int drm_stub_open(struct inode *inode, struct
file *filp)
else
err = 0;
-out_release:
+out:
drm_minor_release(minor);
-out_unlock:
- mutex_unlock(&drm_global_mutex);
+
return err;
}
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 1075b3a8b5b1..80d556402ab4 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -378,6 +378,8 @@ int drm_open(struct inode *inode, struct file *filp)
if (IS_ERR(minor))
return PTR_ERR(minor);
+ mutex_lock(&drm_global_mutex);
+
dev = minor->dev;
if (!atomic_fetch_inc(&dev->open_count))
need_setup = 1;
@@ -395,10 +397,14 @@ int drm_open(struct inode *inode, struct file *filp)
goto err_undo;
}
}
+
+ mutex_unlock(&drm_global_mutex);
+
return 0;
err_undo:
atomic_dec(&dev->open_count);
+ mutex_unlock(&drm_global_mutex);
drm_minor_release(minor);
return retcode;
}
--
2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/dp_mst: Convert drm_dp_mst_topology_mgr.is_waiting_for_dwn_reply to bitfield
[AMD Public Use]
Reviewed-by: Wayne Lin
Thanks!
> -Original Message-
> From: Lyude Paul
> Sent: Thursday, January 23, 2020 3:49 AM
> To: dri-devel@lists.freedesktop.org
> Cc: Lin, Wayne ; Maarten Lankhorst
> ; Maxime Ripard ;
> David Airlie ; Daniel Vetter ;
> linux-ker...@vger.kernel.org
> Subject: [PATCH] drm/dp_mst: Convert
> drm_dp_mst_topology_mgr.is_waiting_for_dwn_reply to bitfield
>
> Small nitpick that I noticed a second ago - we can save some space in the
> struct by making this a bitfield and sticking it with the rest of the
> bitfields. Also,
> some small cleanup to the kdocs for this member.
>
> There should be no functional changes in this patch.
>
> Signed-off-by: Lyude Paul
> Cc: Wayne Lin
> ---
> include/drm/drm_dp_mst_helper.h | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/include/drm/drm_dp_mst_helper.h
> b/include/drm/drm_dp_mst_helper.h index bcb39da9adb4..58bbab3684b5
> 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -590,6 +590,11 @@ struct drm_dp_mst_topology_mgr {
>*/
> bool payload_id_table_cleared : 1;
>
> + /**
> + * @is_waiting_for_dwn_reply: whether we're waiting for a down reply.
> + */
> + bool is_waiting_for_dwn_reply : 1;
> +
> /**
>* @mst_primary: Pointer to the primary/first branch device.
>*/
> @@ -619,11 +624,6 @@ struct drm_dp_mst_topology_mgr {
>*/
> struct mutex qlock;
>
> - /**
> - * @is_waiting_for_dwn_reply: indicate whether is waiting for down
> reply
> - */
> - bool is_waiting_for_dwn_reply;
> -
> /**
>* @tx_msg_downq: List of pending down replies.
>*/
> --
> 2.24.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
On Thu, 5 Jul 2018 at 11:21, Daniel Vetter wrote: > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to > pull in arbitrary other resources, including CRTCs (e.g. when > reconfiguring global resources). > > But in nonblocking mode userspace has then no idea this happened, > which can lead to spurious EBUSY calls, both: > - when that other CRTC is currently busy doing a page_flip the > ALLOW_MODESET commit can fail with an EBUSY > - on the other CRTC a normal atomic flip can fail with EBUSY because > of the additional commit inserted by the kernel without userspace's > knowledge > > For blocking commits this isn't a problem, because everyone else will > just block until all the CRTC are reconfigured. Only thing userspace > can notice is the dropped frames without any reason for why frames got > dropped. > > Consensus is that we need new uapi to handle this properly, but no one > has any idea what exactly the new uapi should look like. As a stop-gap > plug this problem by demoting nonblocking commits which might cause > issues by including CRTCs not in the original request to blocking > commits. Thanks for writing this up Daniel, and for reminding me about it some time later as well ... Reviewed-by: Daniel Stone Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
