Re: [PATCH] drm: add drm device name
On Mon, 16 Sep 2019, Marek Olšák wrote: > The purpose is to get rid of all PCI ID tables for all drivers in > userspace. (or at least stop updating them) > > Mesa common code and modesetting will use this. I'd think this would warrant a high level description of what you want to achieve in the commit message. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111236] VA-API radeonsi SIGSEGV __memmove_avx_unaligned
https://bugs.freedesktop.org/show_bug.cgi?id=111236 --- Comment #15 from Julien Isorce --- https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2005 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204885] ryzen 2500U cause graphics glitch in all browsers with kernel version 5.2.x+
https://bugzilla.kernel.org/show_bug.cgi?id=204885 --- Comment #3 from no2stable (pro...@outlook.com) --- Created attachment 285023 --> https://bugzilla.kernel.org/attachment.cgi?id=285023=edit anathor picture of the graphic glitch -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204885] ryzen 2500U cause graphics glitch in all browsers with kernel version 5.2.x+
https://bugzilla.kernel.org/show_bug.cgi?id=204885 --- Comment #2 from no2stable (pro...@outlook.com) --- Created attachment 285021 --> https://bugzilla.kernel.org/attachment.cgi?id=285021=edit a picture of the graphic glitch -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204885] ryzen 2500U cause graphics glitch in all browsers with kernel version 5.2.x+
https://bugzilla.kernel.org/show_bug.cgi?id=204885 --- Comment #1 from no2stable (pro...@outlook.com) --- Created attachment 285019 --> https://bugzilla.kernel.org/attachment.cgi?id=285019=edit 5.3.0 kernel config -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204885] New: ryzen 2500U cause graphics glitch in all browsers with kernel version 5.2.x+
https://bugzilla.kernel.org/show_bug.cgi?id=204885 Bug ID: 204885 Summary: ryzen 2500U cause graphics glitch in all browsers with kernel version 5.2.x+ Product: Drivers Version: 2.5 Kernel Version: 5.3.0 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: pro...@outlook.com Regression: No Created attachment 285017 --> https://bugzilla.kernel.org/attachment.cgi?id=285017=edit dmesg I have a ryzen 2500U laptop running archlinux, after I upgrade the kernel from 5.1.16 to 5.2.x, firefox start to have those wired lines graphic glitch when browsing web pages, especially when browsing a page contain video. This graphic glitch happens to every browser I tried: Chromium, qutebrowser(webkit engine), I tried to turn off hardware acceleration, it dose helped on Chromium, but not on firefox, so I guess it is a bug related to driver. Currently I have 2 kernel installed on my laptop, one is the official kernel package from arhclinux with kernel version 5.1.16. I also compiled a 5.3.0 kernel using the archlinux official 5.3.0 kernel .config file. I am new to linux, so I dont really know hot to debug this problem, but I'm willing to learn how if somebody give me a hint. -- 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
nouveau-next-5.4
Hey Dave, A couple of fixes from Thierry fixing issues as a result of the reservation object rework in this cycle, as well as a fix from Lyude to allow the driver to load on Thinkpad P71. Thanks, Ben. The following changes since commit 9a60b2990d6c2b7ab935fe0a5cc274de67d98bed: Merge branch 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux into drm-next (2019-09-06 16:58:10 +1000) are available in the Git repository at: git://github.com/skeggsb/linux linux-5.4 for you to fetch changes up to b568db62c5c46c8d859f1b9538495ea0fcbe7000: drm/nouveau/bar/gm20b: Avoid BAR1 teardown during init (2019-09-17 14:50:16 +1000) Lyude Paul (1): drm/nouveau/kms/nv50-: Don't create MSTMs for eDP connectors Thierry Reding (4): drm/nouveau: Fix fallout from reservation object rework drm/nouveau/prime: Extend DMA reservation object lock drm/nouveau: Fix ordering between TTM and GEM release drm/nouveau/bar/gm20b: Avoid BAR1 teardown during init drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 ++- drivers/gpu/drm/nouveau/nouveau_bo.c| 26 +++- drivers/gpu/drm/nouveau/nouveau_bo.h| 4 ++-- drivers/gpu/drm/nouveau/nouveau_gem.c | 7 ++- drivers/gpu/drm/nouveau/nouveau_prime.c | 27 - drivers/gpu/drm/nouveau/nvkm/subdev/bar/gm20b.c | 1 - 6 files changed, 41 insertions(+), 27 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: DRM Driver implementation question
Hi Gareth, > From: Gareth Williams, Sent: Monday, September 16, 2019 10:56 PM > > Hi Laurent/Kieran, > > I need to upstream a driver for a display controller that within its > registers memory region contains registers related > to a PWM device. The PWM device is for controlling the backlight of the > display. > Ideally, I would like to create a separated driver for the PWM, so that I can > re-use "pwm-backlight", but since the registers > for the PWM are right in the middle of the registers for the display > controller I would need to ioremap the memory region > for the PWM registers region twice, once from the display controller driver, > and once from the PWM driver. > Do you think that the double ioremap would be acceptable upstream? I think that an MFD driver can support such hardware. I checked Documentation/devicetree/bindings/mfd roughly, and then atmel-hlcdc.txt seems to have a display controller and a PWM device. Best regards, Yoshihiro Shimoda
Re: [PATCH 03/11] drm/nouveau: secboot: Read WPR configuration from GPU registers
On Tue, 17 Sep 2019 at 01:04, Thierry Reding wrote:
>
> From: Thierry Reding
>
> The GPUs found on Tegra SoCs have registers that can be used to read the
> WPR configuration. Use these registers instead of reaching into the
> memory controller's register space to read the same information.
>
> Signed-off-by: Thierry Reding
> ---
> .../drm/nouveau/nvkm/subdev/secboot/gm200.h | 2 +-
> .../drm/nouveau/nvkm/subdev/secboot/gm20b.c | 81 ---
> .../drm/nouveau/nvkm/subdev/secboot/gp10b.c | 4 +-
> 3 files changed, 53 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm200.h
> b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm200.h
> index 62c5e162099a..280b1448df88 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm200.h
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm200.h
> @@ -41,6 +41,6 @@ int gm200_secboot_run_blob(struct nvkm_secboot *, struct
> nvkm_gpuobj *,
>struct nvkm_falcon *);
>
> /* Tegra-only */
> -int gm20b_secboot_tegra_read_wpr(struct gm200_secboot *, u32);
> +int gm20b_secboot_tegra_read_wpr(struct gm200_secboot *);
>
> #endif
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c
> index df8b919dcf09..f8a543122219 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c
> @@ -23,39 +23,65 @@
> #include "acr.h"
> #include "gm200.h"
>
> -#define TEGRA210_MC_BASE 0x70019000
> -
> #ifdef CONFIG_ARCH_TEGRA
> -#define MC_SECURITY_CARVEOUT2_CFG0 0xc58
> -#define MC_SECURITY_CARVEOUT2_BOM_00xc5c
> -#define MC_SECURITY_CARVEOUT2_BOM_HI_0 0xc60
> -#define MC_SECURITY_CARVEOUT2_SIZE_128K0xc64
> -#define TEGRA_MC_SECURITY_CARVEOUT_CFG_LOCKED (1 << 1)
> /**
> * gm20b_secboot_tegra_read_wpr() - read the WPR registers on Tegra
> *
> - * On dGPU, we can manage the WPR region ourselves, but on Tegra the WPR
> region
> - * is reserved from system memory by the bootloader and irreversibly locked.
> - * This function reads the address and size of the pre-configured WPR region.
> + * On dGPU, we can manage the WPR region ourselves, but on Tegra this region
> + * is allocated from system memory by the secure firmware. The region is then
> + * marked as a "secure carveout" and irreversibly locked. Furthermore, the
> WPR
> + * secure carveout is also configured to be sent to the GPU via a dedicated
> + * serial bus between the memory controller and the GPU. The GPU requests
> this
> + * information upon leaving reset and exposes it through a FIFO register at
> + * offset 0x100cd4.
> + *
> + * The FIFO register's lower 4 bits can be used to set the read index into
> the
> + * FIFO. After each read of the FIFO register, the read index is incremented.
> + *
> + * Indices 2 and 3 contain the lower and upper addresses of the WPR. These
> are
> + * stored in units of 256 B. The WPR is inclusive of both addresses.
> + *
> + * Unfortunately, for some reason the WPR info register doesn't contain the
> + * correct values for the secure carveout. It seems like the upper address is
> + * always too small by 128 KiB - 1. Given that the secure carvout size in the
> + * memory controller configuration is specified in units of 128 KiB, it's
> + * possible that the computation of the upper address of the WPR is wrong and
> + * causes this difference.
> */
> int
> -gm20b_secboot_tegra_read_wpr(struct gm200_secboot *gsb, u32 mc_base)
> +gm20b_secboot_tegra_read_wpr(struct gm200_secboot *gsb)
> {
> + struct nvkm_device *device = gsb->base.subdev.device;
> struct nvkm_secboot *sb = >base;
> - void __iomem *mc;
> - u32 cfg;
> + u64 base, limit;
> + u32 value;
>
> - mc = ioremap(mc_base, 0xd00);
> - if (!mc) {
> - nvkm_error(>subdev, "Cannot map Tegra MC registers\n");
> - return -ENOMEM;
> - }
> - sb->wpr_addr = ioread32_native(mc + MC_SECURITY_CARVEOUT2_BOM_0) |
> - ((u64)ioread32_native(mc + MC_SECURITY_CARVEOUT2_BOM_HI_0) <<
> 32);
> - sb->wpr_size = ioread32_native(mc + MC_SECURITY_CARVEOUT2_SIZE_128K)
> - << 17;
> - cfg = ioread32_native(mc + MC_SECURITY_CARVEOUT2_CFG0);
> - iounmap(mc);
> + /* set WPR info register to point at WPR base address register */
> + value = nvkm_rd32(device, 0x100cd4);
> + value &= ~0xf;
> + value |= 0x2;
> + nvkm_wr32(device, 0x100cd4, value);
> +
> + /* read base address */
> + value = nvkm_rd32(device, 0x100cd4);
> + base = (u64)(value >> 4) << 12;
> +
> + /* read limit */
> + value = nvkm_rd32(device, 0x100cd4);
> + limit = (u64)(value >> 4) << 12;
acr_r352_wpr_is_set() does a similar readout to confirm the HS
firmware did its job on dGPU, perhaps this part of it
Re: [Nouveau] [PATCH 2/6] drm/nouveau: fault: Widen engine field
On Tue, 17 Sep 2019 at 01:18, Thierry Reding wrote: > > From: Thierry Reding > > The engine field in the FIFO fault information registers is actually 9 > bits wide. Looks like this is true for fault buffer parsing too. > > Signed-off-by: Thierry Reding > --- > drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.c > b/drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.c > index b5e32295237b..28306c5f6651 100644 > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.c > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.c > @@ -137,8 +137,8 @@ gv100_fault_intr_fault(struct nvkm_fault *fault) > info.addr = ((u64)addrhi << 32) | addrlo; > info.inst = ((u64)insthi << 32) | (info0 & 0xf000); > info.time = 0; > - info.engine = (info0 & 0x00ff); > info.aperture = (info0 & 0x0c00) >> 10; > + info.engine = (info0 & 0x01ff); > info.valid = (info1 & 0x8000) >> 31; > info.gpc= (info1 & 0x1f00) >> 24; > info.hub= (info1 & 0x0010) >> 20; > -- > 2.23.0 > > ___ > Nouveau mailing list > nouv...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH 1/6] drm/nouveau: fault: Store aperture in fault information
On Tue, 17 Sep 2019 at 01:18, Thierry Reding wrote:
>
> From: Thierry Reding
>
> The fault information register contains data about the aperture that
> caused the failure. This can be useful in debugging aperture related
> programming bugs.
Should this be parsed for fault buffer entries too?
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/nouveau/include/nvkm/subdev/fault.h | 1 +
> drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c| 3 ++-
> drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.c | 1 +
> 3 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/fault.h
> b/drivers/gpu/drm/nouveau/include/nvkm/subdev/fault.h
> index 97322f95b3ee..1cc862bc1122 100644
> --- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/fault.h
> +++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/fault.h
> @@ -21,6 +21,7 @@ struct nvkm_fault_data {
> u64 addr;
> u64 inst;
> u64 time;
> + u8 aperture;
> u8 engine;
> u8 valid;
> u8gpc;
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
> index 5d4b695cab8e..81cbe1cc4804 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
> @@ -519,9 +519,10 @@ gk104_fifo_fault(struct nvkm_fifo *base, struct
> nvkm_fault_data *info)
> chan = nvkm_fifo_chan_inst_locked(>base, info->inst);
>
> nvkm_error(subdev,
> - "fault %02x [%s] at %016llx engine %02x [%s] client %02x "
> + "fault %02x [%s] at %016llx aperture %02x engine %02x [%s]
> client %02x "
>"[%s%s] reason %02x [%s] on channel %d [%010llx %s]\n",
>info->access, ea ? ea->name : "", info->addr,
> + info->aperture,
>info->engine, ee ? ee->name : en,
>info->client, ct, ec ? ec->name : "",
>info->reason, er ? er->name : "", chan ? chan->chid : -1,
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.c
> index 6747f09c2dc3..b5e32295237b 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.c
> @@ -138,6 +138,7 @@ gv100_fault_intr_fault(struct nvkm_fault *fault)
> info.inst = ((u64)insthi << 32) | (info0 & 0xf000);
> info.time = 0;
> info.engine = (info0 & 0x00ff);
> + info.aperture = (info0 & 0x0c00) >> 10;
> info.valid = (info1 & 0x8000) >> 31;
> info.gpc= (info1 & 0x1f00) >> 24;
> info.hub= (info1 & 0x0010) >> 20;
> --
> 2.23.0
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH 3/6] drm/nouveau: Remove bogus gk20a aperture callback
On Tue, 17 Sep 2019 at 01:18, Thierry Reding wrote:
>
> From: Thierry Reding
>
> The gk20a (as well as all subsequent Tegra instantiations of the GPU) do
> in fact use the same apertures as regular GPUs. Prior to gv11b there are
> no checks in hardware for the aperture, so we get away with setting VRAM
> as the aperture for buffers that are actually in system memory.
Can GK20A take comptags with aperture set to system memory? For some
reason I can recall, I was under the impression PTEs needed to be
pointed at "vidmem" (despite them actually accessing system memory
anyway) on Tegra parts for compression to work? I could be mistaken
though.
Ben.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 1 -
> drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk20a.c | 10 --
> drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgm20b.c | 4 ++--
> drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp10b.c | 2 +-
> 4 files changed, 3 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
> b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
> index fb3a9e8bb9cd..9862f44ac8b5 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
> @@ -212,7 +212,6 @@ void gf100_vmm_flush(struct nvkm_vmm *, int);
> void gf100_vmm_invalidate(struct nvkm_vmm *, u32 type);
> void gf100_vmm_invalidate_pdb(struct nvkm_vmm *, u64 addr);
>
> -int gk20a_vmm_aper(enum nvkm_memory_target);
> int gk20a_vmm_valid(struct nvkm_vmm *, void *, u32, struct nvkm_vmm_map *);
>
> int gm200_vmm_new_(const struct nvkm_vmm_func *, const struct nvkm_vmm_func
> *,
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk20a.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk20a.c
> index 16d7bf727292..999b953505b3 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk20a.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk20a.c
> @@ -25,16 +25,6 @@
>
> #include
>
> -int
> -gk20a_vmm_aper(enum nvkm_memory_target target)
> -{
> - switch (target) {
> - case NVKM_MEM_TARGET_NCOH: return 0;
> - default:
> - return -EINVAL;
> - }
> -}
> -
> int
> gk20a_vmm_valid(struct nvkm_vmm *vmm, void *argv, u32 argc,
> struct nvkm_vmm_map *map)
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgm20b.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgm20b.c
> index 7a6066d886cd..f5d7819c4a40 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgm20b.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgm20b.c
> @@ -25,7 +25,7 @@ static const struct nvkm_vmm_func
> gm20b_vmm_17 = {
> .join = gm200_vmm_join,
> .part = gf100_vmm_part,
> - .aper = gk20a_vmm_aper,
> + .aper = gf100_vmm_aper,
> .valid = gk20a_vmm_valid,
> .flush = gf100_vmm_flush,
> .invalidate_pdb = gf100_vmm_invalidate_pdb,
> @@ -41,7 +41,7 @@ static const struct nvkm_vmm_func
> gm20b_vmm_16 = {
> .join = gm200_vmm_join,
> .part = gf100_vmm_part,
> - .aper = gk20a_vmm_aper,
> + .aper = gf100_vmm_aper,
> .valid = gk20a_vmm_valid,
> .flush = gf100_vmm_flush,
> .invalidate_pdb = gf100_vmm_invalidate_pdb,
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp10b.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp10b.c
> index 180c8f006e32..ffe84ea2f7d9 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp10b.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp10b.c
> @@ -43,7 +43,7 @@ static const struct nvkm_vmm_func
> gp10b_vmm = {
> .join = gp100_vmm_join,
> .part = gf100_vmm_part,
> - .aper = gk20a_vmm_aper,
> + .aper = gf100_vmm_aper,
> .valid = gp10b_vmm_valid,
> .flush = gp100_vmm_flush,
> .mthd = gp100_vmm_mthd,
> --
> 2.23.0
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 93652] Random crashes/freezing with amdgpu Fury X mesa 11.1
https://bugs.freedesktop.org/show_bug.cgi?id=93652 Timothy Arceri changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #21 from Timothy Arceri --- It seems most if not all of the original reported problems were fixed a while ago. I'm going to close this bug for now. Please open a new bug report if you are still experiencing other issues. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100638] Shadow of mordor crash Mesa: User error: GL_INVALID_VALUE in glFlushMappedBufferRange(offset 2097060 + length 480 > mapped length 2097152)
https://bugs.freedesktop.org/show_bug.cgi?id=100638 Timothy Arceri changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #2 from Timothy Arceri --- Was this fixed for you with newer mesa/kernels? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103743] Nier:Automata - "if" in fragment shader incorrectly evaluated, causes artifacts
https://bugs.freedesktop.org/show_bug.cgi?id=103743 Timothy Arceri changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: manual merge of the drm tree with the drm-misc-fixes tree
On Mon, Sep 16, 2019 at 1:30 PM Vasily Khoruzhick wrote:
>
> On Sun, Sep 15, 2019 at 2:18 PM Mark Brown wrote:
> >
> > Hi all,
>
> Hi Mark,
>
> > Today's linux-next merge of the drm tree got a conflict in:
> >
> > drivers/gpu/drm/lima/lima_gem.c
> >
> > between commit:
> >
> > 21670bd78a25001cf8e ("drm/lima: fix lima_gem_wait() return value")
> >
> > from the drm-misc-fixes tree and commit:
> >
> > 52791eeec1d9f4a7e7f ("dma-buf: rename reservation_object to dma_resv")
> >
> > from the drm tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
>
> Fix looks correct to me. Sorry for not testing my patch with
> linux-next, I'll make sure it at least compiles next time.
This is merge conflict, not compile fail, because linux-next and drm-misc-fixes
are based on different code base, so drm-misc-fixes do not contain latest drm
commits.
This conflict solve change is also OK for me.
Thanks,
Qiang
>
> > diff --cc drivers/gpu/drm/lima/lima_gem.c
> > index b609dc030d6ca,ff3d9acc24fcf..0
> > --- a/drivers/gpu/drm/lima/lima_gem.c
> > +++ b/drivers/gpu/drm/lima/lima_gem.c
> > @@@ -341,8 -341,8 +341,8 @@@ int lima_gem_wait(struct drm_file *file
> >
> > timeout = drm_timeout_abs_to_jiffies(timeout_ns);
> >
> > - ret = drm_gem_reservation_object_wait(file, handle, write, timeout);
> > + ret = drm_gem_dma_resv_wait(file, handle, write, timeout);
> > - if (ret == 0)
> > + if (ret == -ETIME)
> > ret = timeout ? -ETIMEDOUT : -EBUSY;
> >
> > return ret;
[Bug 100239] Incorrect rendering in CS:GO
https://bugs.freedesktop.org/show_bug.cgi?id=100239 --- Comment #27 from Timothy Arceri --- (In reply to Bruno Jacquet (Xaapyks) from comment #26) > (In reply to Michel Dänzer from comment #25) > > (In reply to Bruno Jacquet (Xaapyks) from comment #23) > > > So I'd say the issue is still there. > > > > Maybe you have a ~/.drirc or other drirc file which gets picked up and > > disables radeonsi_zerovram? (E.g. due to ever starting the old "driconf" > > application with a driver which supported the option) > > ~/.drirc and /etc/drirc do not exist on my fs. > /usr/share/drirc.d only contains 00-mesa-defaults.conf which is not modified > from what the mesa build provides and is packaged in Arch. > > strace seems to confirm it is not loading any other "drirc" file any and I > don't have any "*MESA*" or "*GL*" env var. I just tested the trace from comment 16 on my Vega 64 and using the environment variable fixed the issue for me. Do you have an old kernel? radeonsi_zeroram=true will do nothing on pre 4.9 kernels. If you have at least 4.9 can you try closing steam then running it from the command line with: radeonsi_zeroram=true steam And then run CS:GO. This should force the setting even if your system is not picking up the right config file. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111669] Navi GPU hang in Minecraft
https://bugs.freedesktop.org/show_bug.cgi?id=111669 --- Comment #6 from Doug Ty --- Unfortunately I'm still getting the hang with the kernel patch + AMD_DEBUG=nongg, both ingame as well as replaying the apitraces. Same messages in journalctl Not sure how useful it'll be but I've made another apitrace with patch + nongg https://drive.google.com/open?id=1NSMBW-GKHMAMOjrHS_cD-CvvUkvviqx5 Is there anything more I can do to help debug this? A specific firmware I should be using? Currently using: Linux 5.3 (both rc8 and now stable release, compiled with the patch) llvm-git 10.0.0_r326744.bfb5b0cb86c-1 mesa-git 1:19.3.0_devel.115313.f812cbfd884-1 Latest firmware (9/13) from https://people.freedesktop.org/~agd5f/radeon_ucode/navi10/ (was previously using 7/14 from Fedora's linux-firmware) Only AMD_DEBUG=nodma stops the hang for me No luck with amdgpu.vm_update_mode=3 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/11] Add support for software nodes to gpiolib
On Thu, Sep 12, 2019 at 10:55:47AM +0100, Linus Walleij wrote: > On Wed, Sep 11, 2019 at 8:52 AM Dmitry Torokhov > wrote: > > > If we agree in principle, I would like to have the very first 3 patches > > in an immutable branch off maybe -rc8 so that it can be pulled into > > individual subsystems so that patches switching various drivers to > > fwnode_gpiod_get_index() could be applied. > > I think it seems a bit enthusiastic to have non-GPIO subsystems > pick up these changes this close to the merge window so my plan > is to merge patches 1.2.3 (1 already merged) and then you could > massage the other subsystems in v5.4-rc1. > > But if other subsystems say "hey we want do fix this in like 3 days" > then I'm game for an immutable branch as well. No, if it is still has a chance for -rc1 then I'm good. I was thinking if it does not go into -rc1 I could convince some of them merge a targeted immutable branch off -rc8 or 5.3 final and then apply patches relevant to their subsystems so we do not have to wait till 5.6 to land everything. Thanks. -- Dmitry
Re: [PATCH] drm: add drm device name
The purpose is to get rid of all PCI ID tables for all drivers in
userspace. (or at least stop updating them)
Mesa common code and modesetting will use this.
Marek
On Sat, Sep 7, 2019 at 3:48 PM Daniel Vetter wrote:
> On Sat, Sep 7, 2019 at 3:18 AM Rob Clark wrote:
> >
> > On Fri, Sep 6, 2019 at 3:16 PM Marek Olšák wrote:
> > >
> > > + dri-devel
> > >
> > > On Tue, Sep 3, 2019 at 5:41 PM Jiang, Sonny
> wrote:
> > >>
> > >> Add DRM device name and use DRM_IOCTL_VERSION ioctl drmVersion::desc
> passing it to user space
> > >> instead of unused DRM driver name descriptor.
> > >>
> > >> Change-Id: I809f6d3e057111417efbe8fa7cab8f0113ba4b21
> > >> Signed-off-by: Sonny Jiang
> > >> ---
> > >> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 ++
> > >> drivers/gpu/drm/drm_drv.c | 17 +
> > >> drivers/gpu/drm/drm_ioctl.c| 2 +-
> > >> include/drm/drm_device.h | 3 +++
> > >> include/drm/drm_drv.h | 1 +
> > >> 5 files changed, 24 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > >> index 67b09cb2a9e2..8f0971cea363 100644
> > >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > >> @@ -2809,6 +2809,8 @@ int amdgpu_device_init(struct amdgpu_device
> *adev,
> > >> /* init the mode config */
> > >> drm_mode_config_init(adev->ddev);
> > >>
> > >> + drm_dev_set_name(adev->ddev,
> amdgpu_asic_name[adev->asic_type]);
> > >> +
> > >> r = amdgpu_device_ip_init(adev);
> > >> if (r) {
> > >> /* failed in exclusive mode due to timeout */
> > >> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > >> index 862621494a93..6c33879bb538 100644
> > >> --- a/drivers/gpu/drm/drm_drv.c
> > >> +++ b/drivers/gpu/drm/drm_drv.c
> > >> @@ -802,6 +802,7 @@ void drm_dev_fini(struct drm_device *dev)
> > >> mutex_destroy(>struct_mutex);
> > >> drm_legacy_destroy_members(dev);
> > >> kfree(dev->unique);
> > >> + kfree(dev->name);
> > >> }
> > >> EXPORT_SYMBOL(drm_dev_fini);
> > >>
> > >> @@ -1078,6 +1079,22 @@ int drm_dev_set_unique(struct drm_device *dev,
> const char *name)
> > >> }
> > >> EXPORT_SYMBOL(drm_dev_set_unique);
> > >>
> > >> +/**
> > >> + * drm_dev_set_name - Set the name of a DRM device
> > >> + * @dev: device of which to set the name
> > >> + * @name: name to be set
> > >> + *
> > >> + * Return: 0 on success or a negative error code on failure.
> > >> + */
> > >> +int drm_dev_set_name(struct drm_device *dev, const char *name)
> > >> +{
> > >> + kfree(dev->name);
> > >> + dev->name = kstrdup(name, GFP_KERNEL);
> > >> +
> > >> + return dev->name ? 0 : -ENOMEM;
> > >> +}
> > >> +EXPORT_SYMBOL(drm_dev_set_name);
> > >> +
> > >> /*
> > >> * DRM Core
> > >> * The DRM core module initializes all global DRM objects and makes
> them
> > >> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> > >> index 2263e3ddd822..61f02965106b 100644
> > >> --- a/drivers/gpu/drm/drm_ioctl.c
> > >> +++ b/drivers/gpu/drm/drm_ioctl.c
> > >> @@ -506,7 +506,7 @@ int drm_version(struct drm_device *dev, void
> *data,
> > >> dev->driver->date);
> > >> if (!err)
> > >> err = drm_copy_field(version->desc,
> >desc_len,
> > >> - dev->driver->desc);
> > >> + dev->name);
> >
> > I suspect this needs to be something like dev->name ? dev->name :
> > dev->driver->desc
> >
> > Or somewhere something needs to arrange for dev->name to default to
> > dev->driver->desc
> >
> > And maybe this should be dev->desc instead of dev->name.. that at
> > least seems less confusing to me.
> >
> > other than that, I don't see a big problem
>
> (recap from irc)
>
> I thought we're using this as essentially an uapi identifier, so that
> you know which kind of ioctl set a driver supports. Not so big deal on
> pci, where we match against pci ids anyway, kinda bigger deal where
> that's not around. Listing codenames and or something else that
> changes all the time feels a bit silly for that. Imo if you just want
> to expose this to userspace, stuff it into an amdgpu info/query ioctl.
>
> So what do you need this for exactly, where's the userspace that needs
> this?
> -Daniel
>
> >
> > BR,
> > -R
> >
> > >>
> > >> return err;
> > >> }
> > >> diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> > >> index 7f9ef709b2b6..e29912c484e4 100644
> > >> --- a/include/drm/drm_device.h
> > >> +++ b/include/drm/drm_device.h
> > >> @@ -123,6 +123,9 @@ struct drm_device {
> > >> /** @unique: Unique name of the device */
> > >> char *unique;
> > >>
> > >> + /** @name: device name */
> > >> + char *name;
> > >> +
> > >> /**
> > >>
[PATCH] drm: Handle connector tile support only for modes that match tile size
DRM Fb driver expects multiple CRTCs if it sees connector->has_tile
is set, but we need to handle tile support and look for multiple CRTCs
only for the modes that match the tile size. The other modes should
be able to be displayed without tile support or uisng single CRTC.
This patch adds the check to match the tile size with requested mode
to handle the tile support.
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Jani Nikula
Cc: Dave Airlie
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/drm_fb_helper.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index a7ba5b4902d6..ab11e86dd6d5 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1613,7 +1613,9 @@ static int drm_fb_helper_single_fb_probe(struct
drm_fb_helper *fb_helper,
for (j = 0; j < mode_set->num_connectors; j++) {
struct drm_connector *connector =
mode_set->connectors[j];
- if (connector->has_tile) {
+ if (connector->has_tile &&
+ desired_mode->hdisplay == connector->tile_h_size &&
+ desired_mode->vdisplay == connector->tile_v_size) {
lasth = (connector->tile_h_loc ==
(connector->num_h_tile - 1));
lastv = (connector->tile_v_loc ==
(connector->num_v_tile - 1));
/* cloning to multiple tiles is just
crazy-talk, so: */
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panfrost: Prevent race when handling page fault
On Fri, Sep 13, 2019 at 12:25 PM Alyssa Rosenzweig
wrote:
>
> I'm conflicted on this series.
>
> On the one hand, userspace should obviously not be able to crash the
> kernel. So the crash should be fixed in one way or another.
>
> On the other hand, userspace really has to supply all the BOs it uses
> for correctness. I realize the DDK doesn't do this but... it probably
> should, umm...
>
> Would it be possible to check for the NULL pointer in the kernel and
> skip printing information that would require a dereference? (Without
> having to play games with reference counts). Presumably that might fix
> crashes in other corner cases.
I don't think that prevents the use after free. I think the NULL is a
pointer within the BO, not the BO. So we'd still be retrieving the
NULL ptr from a freed object.
Rob
>
> On Thu, Sep 05, 2019 at 01:11:41PM +0100, Steven Price wrote:
> > When handling a GPU page fault addr_to_drm_mm_node() is used to
> > translate the GPU address to a buffer object. However it is possible for
> > the buffer object to be freed after the function has returned resulting
> > in a use-after-free of the BO.
> >
> > Change addr_to_drm_mm_node to return the panfrost_gem_object with an
> > extra reference on it, preventing the BO from being freed until after
> > the page fault has been handled.
> >
> > Signed-off-by: Steven Price
> > ---
> >
> > I've managed to trigger this, generating the following stack trace.
> >
> > Unable to handle kernel NULL pointer dereference at virtual address 0090
> > pgd = 33a6a181
> > [0090] *pgd=
> > Internal error: Oops: 5 [#1] SMP ARM
> > Modules linked in:
> > CPU: 0 PID: 81 Comm: irq/60-mmu Not tainted 5.3.0-rc1+ #4
> > Hardware name: Rockchip (Device Tree)
> > PC is at panfrost_mmu_map_fault_addr+0x140/0x3a0
> > LR is at _raw_spin_unlock+0x20/0x3c
> > pc : []lr : []psr: 20030013
> > sp : ec643e88 ip : ea70ce24 fp : ec5fe840
> > r10: 0001 r9 : r8 : 000178c9
> > r7 : r6 : 178c9f00 r5 : ec5fe940 r4 : ea70ce08
> > r3 : r2 : r1 : ec640e00 r0 : ec5fe940
> > Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> > Control: 10c5387d Table: 29f8406a DAC: 0051
> > Process irq/60-mmu (pid: 81, stack limit = 0x4b907106)
> > Stack: (0xec643e88 to 0xec644000)
> > 3e80: ec640e00 c07cede0 c0c0b200 ec640e00
> >
> > 3ea0: 000178c9 c0c0b200 c07cede0 eef91040 ec5fe840 0001
> >
> > 3ec0: 00010001 010003c3 00c3 0001 178c9f00 c0508c98 eef91050
> >
> > 3ee0: ec643f34 c07c9188 0001 c0167854 ec643ef8 c0c08448
> > c07c933c
> > 3f00: ec643f04 fffefffe 3d182b17 ee193468 ee193400 ec5db3c0
> > ec5db3c0
> > 3f20: c0183840 ec5db3e4 c0cb2874 c0183b08 0001 c018385c e000
> > ee193400
> > 3f40: ec5db3c0 c0183b8c c0c08448 6013 c01839b8
> > 3d182b17
> > 3f60: e000 ec5d0500 ec5db380 ec642000 ec5db3c0 c0183a64
> > ed025cd8
> > 3f80: ec5d0538 c0146cfc ec642000 ec5db380 c0146bc0
> >
> > 3fa0: c01010b4
> >
> > 3fc0:
> >
> > 3fe0: 0013
> >
> > [] (panfrost_mmu_map_fault_addr) from []
> > (panfrost_mmu_irq_handler_thread+0xf4/0x248)
> > [] (panfrost_mmu_irq_handler_thread) from []
> > (irq_thread_fn+0x1c/0x58)
> > [] (irq_thread_fn) from [] (irq_thread+0x128/0x240)
> > [] (irq_thread) from [] (kthread+0x13c/0x154)
> > [] (kthread) from [] (ret_from_fork+0x14/0x20)
> > Exception stack(0xec643fb0 to 0xec643ff8)
> > 3fa0:
> >
> > 3fc0:
> >
> > 3fe0: 0013
> > Code: 1aec eae8 e5143004 e59d2014 (e5933090)
> > ---[ end trace 04eadc3009b8f507 ]---
> > ---
> > drivers/gpu/drm/panfrost/panfrost_mmu.c | 38 -
> > 1 file changed, 24 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> > b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> > index 842bdd7cf6be..115925e7460a 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
> > +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
> > @@ -392,9 +392,11 @@ void panfrost_mmu_pgtable_free(struct
> > panfrost_file_priv *priv)
> > free_io_pgtable_ops(mmu->pgtbl_ops);
> > }
> >
> > -static struct drm_mm_node *addr_to_drm_mm_node(struct panfrost_device
> > *pfdev, int as, u64 addr)
> > +static struct panfrost_gem_object *
> > +addr_to_drm_mm_node(struct panfrost_device *pfdev, int as, u64 addr)
> > {
> > - struct drm_mm_node *node = NULL;
> > + struct panfrost_gem_object *bo = NULL;
> > + struct drm_mm_node *node;
> > u64
Re: [PATCH 2/2] drm/panfrost: Simplify devfreq utilisation tracking
On Fri, Sep 13, 2019 at 12:43 PM Alyssa Rosenzweig wrote: > > Patch 1 is: > > Acked-by: Alyssa Rosenzweig > > Patch 2 is: > > Reviewed-by: Alyssa Rosenzweig In the future, please reply to each patch with your tag. The reason being is patchwork will automatically add them instead of me doing it manually. For a tag on a whole series, replying to patch #0 is fine. Patchwork doesn't handle that, but I view that as a patchwork limitation. Rob
Re: [PATCH] drm/amd/display: Fix compile error due to 'endif' missing
On Tue, Sep 17, 2019 at 02:46:48AM +0900, Masahiro Yamada wrote: > On Mon, Sep 16, 2019 at 1:46 PM Austin Kim wrote: > > gcc throws compile error with below message: > GNU Make throws ... Xinpeng Liu via Nick Desaulniers sent a description of the problem and a patch so I think I'll be able to fix this. However... > This is probably a merge mistake in linux-next. > If so, this should be directly fixed in the linux-next. > If it is not fixed in time, > please inform Linus to *not* follow the linux-next. ...as I said before I think you definitely need to coordinate with the DRM people - Nick Desaulniers' patch 0f0727d971f6f (drm/amd/display: readd -msse2 to prevent Clang from emitting libcalls to undefined SW FP routines) breaks in places that don't have merge conflicts due to this change. I wouldn't rely on the merge going well if things are sent as-is, the only reason this one showed up was that other people were adding new files to the Makefile. I've CCed Nick. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/connector: Share with non-atomic drivers the function to get the single encoder
Thanks for the patch and reviews, pushed to drm-misc Regards Manasi On Mon, Sep 16, 2019 at 02:12:14PM -0700, Souza, Jose wrote: > On Mon, 2019-09-16 at 12:39 -0700, Manasi Navare wrote: > > On Mon, Sep 16, 2019 at 07:34:32PM +, Souza, Jose wrote: > > > Someone with drm-misc commit access could push this? > > > > > > > Sure will push this series. > > Thanks Manasi > > > > > Manasi > > > > > Thanks > > > > > > On Sun, 2019-09-15 at 11:36 +, Patchwork wrote: > > > > == Series Details == > > > > > > > > Series: series starting with [CI,1/2] drm/connector: Share with > > > > non- > > > > atomic drivers the function to get the single encoder > > > > URL : https://patchwork.freedesktop.org/series/66701/ > > > > State : success > > > > > > > > == Summary == > > > > > > > > CI Bug Log - changes from CI_DRM_6894_full -> > > > > Patchwork_14412_full > > > > > > > > > > > > Summary > > > > --- > > > > > > > > **SUCCESS** > > > > > > > > No regressions found. > > > > > > > > > > > > > > > > Known issues > > > > > > > > > > > > Here are the changes found in Patchwork_14412_full that come > > > > from > > > > known issues: > > > > > > > > ### IGT changes ### > > > > > > > > Issues hit > > > > > > > > * igt@gem_exec_schedule@preempt-contexts-bsd2: > > > > - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276]) > > > > +14 > > > > similar issues > > > >[1]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-iclb1/igt@gem_exec_sched...@preempt-contexts-bsd2.html > > > >[2]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-iclb7/igt@gem_exec_sched...@preempt-contexts-bsd2.html > > > > > > > > * igt@gem_exec_schedule@preemptive-hang-bsd: > > > > - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) > > > > +3 > > > > similar issues > > > >[3]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-iclb6/igt@gem_exec_sched...@preemptive-hang-bsd.html > > > >[4]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-iclb4/igt@gem_exec_sched...@preemptive-hang-bsd.html > > > > > > > > * igt@i915_pm_rpm@modeset-stress-extra-wait: > > > > - shard-glk: [PASS][5] -> [DMESG-WARN][6] > > > > ([fdo#105763] > > > > / [fdo#106538]) > > > >[5]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-glk7/igt@i915_pm_...@modeset-stress-extra-wait.html > > > >[6]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-glk8/igt@i915_pm_...@modeset-stress-extra-wait.html > > > > > > > > * igt@i915_suspend@fence-restore-tiled2untiled: > > > > - shard-apl: [PASS][7] -> [DMESG-WARN][8] > > > > ([fdo#108566]) > > > > +3 similar issues > > > >[7]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl1/igt@i915_susp...@fence-restore-tiled2untiled.html > > > >[8]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl7/igt@i915_susp...@fence-restore-tiled2untiled.html > > > > > > > > * igt@kms_cursor_crc@pipe-b-cursor-alpha-transparent: > > > > - shard-snb: [PASS][9] -> [SKIP][10] ([fdo#109271]) > > > >[9]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-snb5/igt@kms_cursor_...@pipe-b-cursor-alpha-transparent.html > > > >[10]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-snb7/igt@kms_cursor_...@pipe-b-cursor-alpha-transparent.html > > > > > > > > * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: > > > > - shard-hsw: [PASS][11] -> [FAIL][12] ([fdo#105767]) > > > >[11]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html > > > >[12]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html > > > > > > > > * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: > > > > - shard-glk: [PASS][13] -> [FAIL][14] ([fdo#105363]) > > > >[13]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-glk8/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html > > > >[14]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-glk2/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html > > > > > > > > * igt@kms_flip@basic-flip-vs-modeset: > > > > - shard-apl: [PASS][15] -> [INCOMPLETE][16] > > > > ([fdo#103927]) > > > >[15]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl7/igt@kms_f...@basic-flip-vs-modeset.html > > > >[16]: > > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl3/igt@kms_f...@basic-flip-vs-modeset.html > > > > > > > > * igt@kms_flip@flip-vs-expired-vblank-interruptible: > > > > - shard-apl: [PASS][17] -> [FAIL][18]
Re: [PATCH 1/2] drm/panfrost: Allow passing extra information about BOs used by a job
On Fri, Sep 13, 2019 at 8:44 AM Steven Price wrote:
>
> On 13/09/2019 12:17, Boris Brezillon wrote:
> > The READ/WRITE flags are particularly useful if we want to avoid
> > serialization of jobs that read from the same BO but never write to it.
> > The NO_IMPLICIT_FENCE might be useful when the user knows the BO is
> > shared but jobs are using different portions of the buffer.
> >
> > Signed-off-by: Boris Brezillon
>
> Good feature - we could do with an (easy) way of the user driver
> detecting this - so it might be worth bumping the driver version for this?
>
> Some more comments below.
>
> > ---
> > drivers/gpu/drm/panfrost/panfrost_drv.c | 72 +--
> > drivers/gpu/drm/panfrost/panfrost_job.c | 164 +++-
> > drivers/gpu/drm/panfrost/panfrost_job.h | 11 +-
> > include/uapi/drm/panfrost_drm.h | 41 ++
> > 4 files changed, 247 insertions(+), 41 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> > b/drivers/gpu/drm/panfrost/panfrost_drv.c
> > index d74442d71048..08082fd557c3 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> > +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> > @@ -119,20 +119,76 @@ panfrost_lookup_bos(struct drm_device *dev,
> > struct drm_panfrost_submit *args,
> > struct panfrost_job *job)
> > {
> > - job->bo_count = args->bo_handle_count;
> > + struct drm_panfrost_submit_bo *bo_descs = NULL;
> > + u32 *handles = NULL;
> > + u32 i, bo_count;
> > + int ret = 0;
> >
> > - if (!job->bo_count)
> > + bo_count = args->bo_desc_count ?
> > +args->bo_desc_count : args->bo_handle_count;
> > + if (!bo_count)
> > return 0;
> >
> > - job->implicit_fences = kvmalloc_array(job->bo_count,
> > - sizeof(struct dma_fence *),
> > + job->bos = kvmalloc_array(bo_count, sizeof(*job->bos),
> > GFP_KERNEL | __GFP_ZERO);
> > - if (!job->implicit_fences)
> > + if (!job->bos)
> > return -ENOMEM;
> >
> > - return drm_gem_objects_lookup(file_priv,
> > - (void __user
> > *)(uintptr_t)args->bo_handles,
> > - job->bo_count, >bos);
> > + job->bo_count = bo_count;
> > + bo_descs = kvmalloc_array(bo_count, sizeof(*bo_descs),
> > + GFP_KERNEL | __GFP_ZERO);
> > + if (!bo_descs) {
> > + ret = -ENOMEM;
> > + goto out;
>
> This can be just "return -ENOMEM" - both handles and bo_descs will be NULL.
>
> > + }
> > +
> > + if (!args->bo_desc_count) {
> > + handles = kvmalloc_array(bo_count, sizeof(*handles),
> > + GFP_KERNEL);
> > + if (!handles) {
> > + ret =-ENOMEM;
> > + goto out;
> > + }
> > +
> > + if (copy_from_user(handles,
> > +(void __user *)(uintptr_t)args->bo_handles,
> > +job->bo_count * sizeof(*handles))) {
> > + ret = -EFAULT;
> > + goto out;
> > + }
> > +
> > + for (i = 0; i < job->bo_count; i++) {
> > + bo_descs[i].handle = handles[i];
> > + bo_descs[i].flags = PANFROST_SUBMIT_BO_WRITE |
> > + PANFROST_SUBMIT_BO_READ;
>
> You can use PANFROST_SUBMIT_BO_RW here.
>
> > + }
> > + } else if (copy_from_user(bo_descs,
> > + (void __user *)(uintptr_t)args->bo_descs,
> > + job->bo_count * sizeof(*bo_descs))) {
> > + ret = -EFAULT;
> > + goto out;
> > + }
> > +
> > + for (i = 0; i < job->bo_count; i++) {
> > + if ((bo_descs[i].flags & ~PANFROST_SUBMIT_BO_VALID_FLAGS) ||
> > +!(bo_descs[i].flags & PANFROST_SUBMIT_BO_RW)) {
> > + ret = -EINVAL;
> > + goto out;
> > + }
> > +
> > + job->bos[i].flags = bo_descs[i].flags;
> > + job->bos[i].obj = drm_gem_object_lookup(file_priv,
> > + bo_descs[i].handle);
> > + if (!job->bos[i].obj) {
> > + ret = -ENOENT;
> > + goto out;
> > + }
> > + }
> > +
> > +out:
> > + kvfree(handles);
> > + kvfree(bo_descs);
> > + return ret;
> > }
> >
> > /**
> > diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
> > b/drivers/gpu/drm/panfrost/panfrost_job.c
> > index 05c85f45a0de..e4b74fde9339 100644
> > --- a/drivers/gpu/drm/panfrost/panfrost_job.c
> > +++ b/drivers/gpu/drm/panfrost/panfrost_job.c
> > @@ -193,24 +193,116 @@ static void panfrost_job_hw_submit(struct
> > panfrost_job *job, int js)
> >
Re: [PATCH 1/2] drm/panfrost: Allow passing extra information about BOs used by a job
On Fri, Sep 13, 2019 at 6:17 AM Boris Brezillon wrote: > > The READ/WRITE flags are particularly useful if we want to avoid > serialization of jobs that read from the same BO but never write to it. Any data on performance differences? > The NO_IMPLICIT_FENCE might be useful when the user knows the BO is > shared but jobs are using different portions of the buffer. Why don't we add this when it is useful rather than might be? > > Signed-off-by: Boris Brezillon ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111691] hardware cursor corruption w/ AMD 5700 XT
https://bugs.freedesktop.org/show_bug.cgi?id=111691 --- Comment #9 from Michael Haworth --- I updated to the 5.3 release but has not fixed the issue -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: manual merge of the drm tree with the kbuild tree
On Mon, Sep 16, 2019 at 02:06:46PM -0700, Nick Desaulniers wrote:
> On Sun, Sep 15, 2019 at 2:47 PM Mark Brown wrote:
> > 0f0727d971f6fdf ("drm/amd/display: readd -msse2 to prevent Clang from
> > emitting libcalls to undefined SW FP routines")
> ^ this patch is now broken due to the SHA above it.
Right, all the sites that didn't conflict are broken. Like I say I
think there needs to be some coordination with the Kbuild changes here.
> b/drivers/gpu/drm/amd/display/dc/dcn20/Makefile
> index 2b399cfa72e6..ddb8d5649e79 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn20/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dcn20/Makefile
> @@ -19,7 +19,7 @@ endif
> CFLAGS_$(AMDDALPATH)/dc/dcn20/dcn20_resource.o := -mhard-float -msse
> $(cc_stack_align)
I can't do anything with patches without signoffs so I'm not going to
apply this as a workaround.
> > + ifdef CONFIG_DRM_AMD_DC_DCN2_1
> > -CFLAGS_display_mode_vba_21.o := $(dml_ccflags)
> > -CFLAGS_display_rq_dlg_calc_21.o := $(dml_ccflags)
> > -endif
>
> ^ this endif should not be removed.
There's an endif left there? Someone sent a patch, I'm going to apply
that.
signature.asc
Description: PGP signature
Re: [PATCH 3/8] drm/shmem: drop DEFINE_DRM_GEM_SHMEM_FOPS
On Fri, Sep 13, 2019 at 7:29 AM Gerd Hoffmann wrote: > Version? Pretty sure this is not v1. > DEFINE_DRM_GEM_SHMEM_FOPS is identical > to DEFINE_DRM_GEM_FOPS now, drop it. > > Signed-off-by: Gerd Hoffmann > --- > include/drm/drm_gem_shmem_helper.h | 26 - > drivers/gpu/drm/cirrus/cirrus.c | 2 +- > drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +- > drivers/gpu/drm/tiny/gm12u320.c | 2 +- > drivers/gpu/drm/v3d/v3d_drv.c | 2 +- > drivers/gpu/drm/virtio/virtgpu_drv.c| 2 +- > 6 files changed, 5 insertions(+), 31 deletions(-) Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v4] video: hyperv: hyperv_fb: Obtain screen resolution from Hyper-V host
> From: Dexuan Cui > Sent: Monday, September 16, 2019 2:46 PM > To: Michael Kelley ; Wei Hu ; > b.zolnier...@samsung.com; linux-hyp...@vger.kernel.org; > dri-devel@lists.freedesktop.org; linux-fb...@vger.kernel.org; > linux-ker...@vger.kernel.org; Stephen Hemminger > ; sas...@kernel.org; Haiyang Zhang > ; KY Srinivasan > Cc: Iouri Tarassov > Subject: RE: [PATCH v4] video: hyperv: hyperv_fb: Obtain screen resolution > from Hyper-V host > > > From: linux-hyperv-ow...@vger.kernel.org > > On Behalf Of Dexuan Cui > > Sent: Thursday, September 12, 2019 11:39 PM > > To: Michael Kelley ; Wei Hu > ; > > b.zolnier...@samsung.com; linux-hyp...@vger.kernel.org; > > dri-devel@lists.freedesktop.org; linux-fb...@vger.kernel.org; > > linux-ker...@vger.kernel.org; Stephen Hemminger > > ; sas...@kernel.org; Haiyang Zhang > > ; KY Srinivasan > > Cc: Iouri Tarassov > > Subject: RE: [PATCH v4] video: hyperv: hyperv_fb: Obtain screen resolution > > from Hyper-V host > > > > > From: Michael Kelley > > > Sent: Thursday, September 5, 2019 7:06 AM > > > > > > From: Wei Hu Sent: Thursday, September 5, 2019 > > 2:12 > > > AM > > > > > > > > Beginning from Windows 10 RS5+, VM screen resolution is obtained from > > > host. > > > > The "video=hyperv_fb" boot time option is not needed, but still can be > > > > used to overwrite what the host specifies. The VM resolution on the host > > > > could be set by executing the powershell "set-vmvideo" command. > > > > > > > > Signed-off-by: Iouri Tarassov > > > > Signed-off-by: Wei Hu > > > > --- > > > > v2: > > > > - Implemented fallback when version negotiation failed. > > > > - Defined full size for supported_resolution array. > > > > > > > > v3: > > > > - Corrected the synthvid major and minor version comparison > > problem. > > > > > > > > v4: > > > > - Changed function name to synthvid_ver_ge(). > > > > > > > > drivers/video/fbdev/hyperv_fb.c | 159 > > > +--- > > > > 1 file changed, 147 insertions(+), 12 deletions(-) > > > > > > > > > > Reviewed-by: Michael Kelley > > > > Looks good to me. > > > > Reviewed-by: Dexuan Cui > > Hi Wei, > It turns out we need to make a further fix. :-) > > The patch forgets to take par->update into consideration. > > When the VM Connection window is closed (or minimized?), > the host sends a message to the guest, and the guest sets > par->update to false in synthvid_recv_sub(). > > If par->update is false, the guest doesn't need to call > synthvid_update(). > > Thanks, > -- Dexuan Please ignore the last reply from me. It was meant to reply another mail: RE: [PATCH v5] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver Sorry for the confusion. Thanks, -- Dexuan
RE: [PATCH v5] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver
Thanks, -- Dexuan > -Original Message- > From: linux-hyperv-ow...@vger.kernel.org > On Behalf Of Dexuan Cui > Sent: Thursday, September 12, 2019 11:38 PM > To: Wei Hu ; Michael Kelley ; > rdun...@infradead.org; shc_w...@mail.ru; gre...@linuxfoundation.org; > lee.jo...@linaro.org; alexandre.bell...@bootlin.com; > baijiaju1...@gmail.com; fth...@telegraphics.com.au; i...@metux.net; > linux-hyp...@vger.kernel.org; dri-devel@lists.freedesktop.org; > linux-fb...@vger.kernel.org; linux-ker...@vger.kernel.org; sas...@kernel.org; > Stephen Hemminger ; Haiyang Zhang > ; KY Srinivasan > Subject: RE: [PATCH v5] video: hyperv: hyperv_fb: Support deferred IO for > Hyper-V frame buffer driver > > > From: Wei Hu > > Sent: Thursday, September 12, 2019 11:03 PM > > > > Without deferred IO support, hyperv_fb driver informs the host to refresh > > the entire guest frame buffer at fixed rate, e.g. at 20Hz, no matter there > > is screen update or not. This patch supports deferred IO for screens in > > graphics mode and also enables the frame buffer on-demand refresh. The > > highest refresh rate is still set at 20Hz. > > > > Currently Hyper-V only takes a physical address from guest as the starting > > address of frame buffer. This implies the guest must allocate contiguous > > physical memory for frame buffer. In addition, Hyper-V Gen 2 VMs only > > accept address from MMIO region as frame buffer address. Due to these > > limitations on Hyper-V host, we keep a shadow copy of frame buffer > > in the guest. This means one more copy of the dirty rectangle inside > > guest when doing the on-demand refresh. This can be optimized in the > > future with help from host. For now the host performance gain from deferred > > IO outweighs the shadow copy impact in the guest. > > > > Signed-off-by: Wei Hu > > --- > > v2: Incorporated review comments from Michael Kelley > > - Increased dirty rectangle by one row in deferred IO case when sending > > to Hyper-V. > > - Corrected the dirty rectangle size in the text mode. > > - Added more comments. > > - Other minor code cleanups. > > > > v3: Incorporated more review comments > > - Removed a few unnecessary variable tests > > > > v4: Incorporated test and review feedback from Dexuan Cui > > - Not disable interrupt while acquiring docopy_lock in > > hvfb_update_work(). This avoids significant bootup delay in > > large vCPU count VMs. > > > > v5: Completely remove the unnecessary docopy_lock after discussing > > with Dexuan Cui. > > Thanks! Looks good to me. > > Reviewed-by: Dexuan Cui Hi Wei, It turns out we need to make a further fix. :-) The patch forgets to take par->update into consideration. When the VM Connection window is closed (or minimized?), the host sends a message to the guest, and the guest sets par->update to false in synthvid_recv_sub(). If par->update is false, the guest doesn't need to call synthvid_update(). Thanks, -- Dexuan
RE: [PATCH v4] video: hyperv: hyperv_fb: Obtain screen resolution from Hyper-V host
> From: linux-hyperv-ow...@vger.kernel.org > On Behalf Of Dexuan Cui > Sent: Thursday, September 12, 2019 11:39 PM > To: Michael Kelley ; Wei Hu ; > b.zolnier...@samsung.com; linux-hyp...@vger.kernel.org; > dri-devel@lists.freedesktop.org; linux-fb...@vger.kernel.org; > linux-ker...@vger.kernel.org; Stephen Hemminger > ; sas...@kernel.org; Haiyang Zhang > ; KY Srinivasan > Cc: Iouri Tarassov > Subject: RE: [PATCH v4] video: hyperv: hyperv_fb: Obtain screen resolution > from Hyper-V host > > > From: Michael Kelley > > Sent: Thursday, September 5, 2019 7:06 AM > > > > From: Wei Hu Sent: Thursday, September 5, 2019 > 2:12 > > AM > > > > > > Beginning from Windows 10 RS5+, VM screen resolution is obtained from > > host. > > > The "video=hyperv_fb" boot time option is not needed, but still can be > > > used to overwrite what the host specifies. The VM resolution on the host > > > could be set by executing the powershell "set-vmvideo" command. > > > > > > Signed-off-by: Iouri Tarassov > > > Signed-off-by: Wei Hu > > > --- > > > v2: > > > - Implemented fallback when version negotiation failed. > > > - Defined full size for supported_resolution array. > > > > > > v3: > > > - Corrected the synthvid major and minor version comparison > problem. > > > > > > v4: > > > - Changed function name to synthvid_ver_ge(). > > > > > > drivers/video/fbdev/hyperv_fb.c | 159 > > +--- > > > 1 file changed, 147 insertions(+), 12 deletions(-) > > > > > > > Reviewed-by: Michael Kelley > > Looks good to me. > > Reviewed-by: Dexuan Cui Hi Wei, It turns out we need to make a further fix. :-) The patch forgets to take par->update into consideration. When the VM Connection window is closed (or minimized?), the host sends a message to the guest, and the guest sets par->update to false in synthvid_recv_sub(). If par->update is false, the guest doesn't need to call synthvid_update(). Thanks, -- Dexuan
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/connector: Share with non-atomic drivers the function to get the single encoder
On Mon, 2019-09-16 at 12:39 -0700, Manasi Navare wrote: > On Mon, Sep 16, 2019 at 07:34:32PM +, Souza, Jose wrote: > > Someone with drm-misc commit access could push this? > > > > Sure will push this series. Thanks Manasi > > Manasi > > > Thanks > > > > On Sun, 2019-09-15 at 11:36 +, Patchwork wrote: > > > == Series Details == > > > > > > Series: series starting with [CI,1/2] drm/connector: Share with > > > non- > > > atomic drivers the function to get the single encoder > > > URL : https://patchwork.freedesktop.org/series/66701/ > > > State : success > > > > > > == Summary == > > > > > > CI Bug Log - changes from CI_DRM_6894_full -> > > > Patchwork_14412_full > > > > > > > > > Summary > > > --- > > > > > > **SUCCESS** > > > > > > No regressions found. > > > > > > > > > > > > Known issues > > > > > > > > > Here are the changes found in Patchwork_14412_full that come > > > from > > > known issues: > > > > > > ### IGT changes ### > > > > > > Issues hit > > > > > > * igt@gem_exec_schedule@preempt-contexts-bsd2: > > > - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276]) > > > +14 > > > similar issues > > >[1]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-iclb1/igt@gem_exec_sched...@preempt-contexts-bsd2.html > > >[2]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-iclb7/igt@gem_exec_sched...@preempt-contexts-bsd2.html > > > > > > * igt@gem_exec_schedule@preemptive-hang-bsd: > > > - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) > > > +3 > > > similar issues > > >[3]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-iclb6/igt@gem_exec_sched...@preemptive-hang-bsd.html > > >[4]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-iclb4/igt@gem_exec_sched...@preemptive-hang-bsd.html > > > > > > * igt@i915_pm_rpm@modeset-stress-extra-wait: > > > - shard-glk: [PASS][5] -> [DMESG-WARN][6] > > > ([fdo#105763] > > > / [fdo#106538]) > > >[5]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-glk7/igt@i915_pm_...@modeset-stress-extra-wait.html > > >[6]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-glk8/igt@i915_pm_...@modeset-stress-extra-wait.html > > > > > > * igt@i915_suspend@fence-restore-tiled2untiled: > > > - shard-apl: [PASS][7] -> [DMESG-WARN][8] > > > ([fdo#108566]) > > > +3 similar issues > > >[7]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl1/igt@i915_susp...@fence-restore-tiled2untiled.html > > >[8]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl7/igt@i915_susp...@fence-restore-tiled2untiled.html > > > > > > * igt@kms_cursor_crc@pipe-b-cursor-alpha-transparent: > > > - shard-snb: [PASS][9] -> [SKIP][10] ([fdo#109271]) > > >[9]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-snb5/igt@kms_cursor_...@pipe-b-cursor-alpha-transparent.html > > >[10]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-snb7/igt@kms_cursor_...@pipe-b-cursor-alpha-transparent.html > > > > > > * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: > > > - shard-hsw: [PASS][11] -> [FAIL][12] ([fdo#105767]) > > >[11]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html > > >[12]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html > > > > > > * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: > > > - shard-glk: [PASS][13] -> [FAIL][14] ([fdo#105363]) > > >[13]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-glk8/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html > > >[14]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-glk2/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html > > > > > > * igt@kms_flip@basic-flip-vs-modeset: > > > - shard-apl: [PASS][15] -> [INCOMPLETE][16] > > > ([fdo#103927]) > > >[15]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl7/igt@kms_f...@basic-flip-vs-modeset.html > > >[16]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl3/igt@kms_f...@basic-flip-vs-modeset.html > > > > > > * igt@kms_flip@flip-vs-expired-vblank-interruptible: > > > - shard-apl: [PASS][17] -> [FAIL][18] ([fdo#105363]) > > >[17]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html > > >[18]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl3/igt@kms_f...@flip-vs-expired-vblank-interruptible.html > > > > > > * igt@kms > > >
Re: linux-next: manual merge of the drm tree with the kbuild tree
On Sun, Sep 15, 2019 at 2:47 PM Mark Brown wrote:
>
> Hi all,
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/amd/display/dc/dml/Makefile
>
> between commit:
>
> 54b8ae66ae1a345 ("kbuild: change *FLAGS_.o to take the path
> relative to $(obj)")
>
> from the kbuild tree and commits:
>
> 0f0727d971f6fdf ("drm/amd/display: readd -msse2 to prevent Clang from
> emitting libcalls to undefined SW FP routines")
^ this patch is now broken due to the SHA above it.
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/Makefile
b/drivers/gpu/drm/amd/display/dc/dcn20/Makefile
index 2b399cfa72e6..ddb8d5649e79 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/Makefile
@@ -19,7 +19,7 @@ endif
CFLAGS_$(AMDDALPATH)/dc/dcn20/dcn20_resource.o := -mhard-float -msse
$(cc_stack_align)
ifdef CONFIG_CC_IS_CLANG
-CFLAGS_dcn20_resource.o += -msse2
+CFLAGS_$(AMDDALPATH)/dc/dcn20/dcn20_resource.o += -msse2
endif
AMD_DAL_DCN20 = $(addprefix $(AMDDALPATH)/dc/dcn20/,$(DCN20))
> 542816ff168d8a3 ("drm/amd/display: Add DCN2.1 changes to DML")
> b04641a3f4c54b0 ("drm/amd/display: Add Renoir DML")
> 057fc695e934a77 ("drm/amd/display: support "dummy pstate"")
>
> from the drm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc drivers/gpu/drm/amd/display/dc/dml/Makefile
> index 83792e2c0f0e4,af2a864a6da05..0
> --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
> @@@ -32,16 -32,29 +32,25 @@@ endi
>
> dml_ccflags := -mhard-float -msse $(cc_stack_align)
>
> + ifdef CONFIG_CC_IS_CLANG
> + dml_ccflags += -msse2
> + endif
> +
> -CFLAGS_display_mode_lib.o := $(dml_ccflags)
> +CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_lib.o := $(dml_ccflags)
>
> ifdef CONFIG_DRM_AMD_DC_DCN2_0
> -CFLAGS_display_mode_vba.o := $(dml_ccflags)
> -CFLAGS_display_mode_vba_20.o := $(dml_ccflags)
> -CFLAGS_display_rq_dlg_calc_20.o := $(dml_ccflags)
> -CFLAGS_display_mode_vba_20v2.o := $(dml_ccflags)
> -CFLAGS_display_rq_dlg_calc_20v2.o := $(dml_ccflags)
> -endif
> +CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_vba.o := $(dml_ccflags)
> +CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20.o := $(dml_ccflags)
> +CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_rq_dlg_calc_20.o := $(dml_ccflags)
> ++CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20v2.o := $(dml_ccflags)
> ++CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_rq_dlg_calc_20v2.o :=
> $(dml_ccflags)
> + ifdef CONFIG_DRM_AMD_DC_DCN2_1
> -CFLAGS_display_mode_vba_21.o := $(dml_ccflags)
> -CFLAGS_display_rq_dlg_calc_21.o := $(dml_ccflags)
> -endif
^ this endif should not be removed.
> -ifdef CONFIG_DRM_AMD_DCN3AG
> -CFLAGS_display_mode_vba_3ag.o := $(dml_ccflags)
> ++CFLAGS_$(AMDDALPATH)/dc/dml/dcn21/display_mode_vba_21.o := $(dml_ccflags)
> ++CFLAGS_$(AMDDALPATH)/dc/dml/dcn21/display_rq_dlg_calc_21.o := $(dml_ccflags)
> endif
> -CFLAGS_dml1_display_rq_dlg_calc.o := $(dml_ccflags)
> -CFLAGS_display_rq_dlg_helpers.o := $(dml_ccflags)
> -CFLAGS_dml_common_defs.o := $(dml_ccflags)
> +CFLAGS_$(AMDDALPATH)/dc/dml/dml1_display_rq_dlg_calc.o := $(dml_ccflags)
> +CFLAGS_$(AMDDALPATH)/dc/dml/display_rq_dlg_helpers.o := $(dml_ccflags)
> +CFLAGS_$(AMDDALPATH)/dc/dml/dml_common_defs.o := $(dml_ccflags)
>
> DML = display_mode_lib.o display_rq_dlg_helpers.o
> dml1_display_rq_dlg_calc.o \
> dml_common_defs.o
--
Thanks,
~Nick Desaulniers
Re: [PATCH] drm/msm: Remove unused function arguments
On Mon, Sep 16, 2019 at 1:12 PM Drew Davenport wrote:
>
> The arguments related to IOMMU port name have been unused since
> commit 944fc36c31ed ("drm/msm: use upstream iommu") and can be removed.
>
> Signed-off-by: Drew Davenport
> ---
> Rob, in the original commit the port name stuff was left intentionally.
> Would it be alright to remove it now?
Upstream support for snapdragon has improved considerably since then,
it's been at least a couple years since I've had to backport drm to a
downstream android vendor kernel. (And I think the downstream vendor
kernel is getting closer to upstream.) So I think we can drop things
that were originally left in place to simplify backporting to vendor
kernel.
(Also, some of the regulator usage falls into this category.. at one
point the downstream kernel modeled gdsc's as regulators, but upstream
uses genpd.)
BR,
-R
>
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 10 ++
> drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 10 ++
> drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 10 ++
> drivers/gpu/drm/msm/msm_gpu.c| 5 ++---
> drivers/gpu/drm/msm/msm_gpummu.c | 6 ++
> drivers/gpu/drm/msm/msm_iommu.c | 6 ++
> drivers/gpu/drm/msm/msm_mmu.h| 4 ++--
> 7 files changed, 14 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> index 58b0485dc375..3165c2db2541 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> @@ -30,10 +30,6 @@
> #define CREATE_TRACE_POINTS
> #include "dpu_trace.h"
>
> -static const char * const iommu_ports[] = {
> - "mdp_0",
> -};
> -
> /*
> * To enable overall DRM driver logging
> * # echo 0x2 > /sys/module/drm/parameters/debug
> @@ -725,8 +721,7 @@ static void _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms)
>
> mmu = dpu_kms->base.aspace->mmu;
>
> - mmu->funcs->detach(mmu, (const char **)iommu_ports,
> - ARRAY_SIZE(iommu_ports));
> + mmu->funcs->detach(mmu);
> msm_gem_address_space_put(dpu_kms->base.aspace);
>
> dpu_kms->base.aspace = NULL;
> @@ -752,8 +747,7 @@ static int _dpu_kms_mmu_init(struct dpu_kms *dpu_kms)
> return PTR_ERR(aspace);
> }
>
> - ret = aspace->mmu->funcs->attach(aspace->mmu, iommu_ports,
> - ARRAY_SIZE(iommu_ports));
> + ret = aspace->mmu->funcs->attach(aspace->mmu);
> if (ret) {
> DPU_ERROR("failed to attach iommu %d\n", ret);
> msm_gem_address_space_put(aspace);
> diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
> b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
> index 50711ccc8691..dda05436f716 100644
> --- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
> +++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
> @@ -157,10 +157,6 @@ static long mdp4_round_pixclk(struct msm_kms *kms,
> unsigned long rate,
> }
> }
>
> -static const char * const iommu_ports[] = {
> - "mdp_port0_cb0", "mdp_port1_cb0",
> -};
> -
> static void mdp4_destroy(struct msm_kms *kms)
> {
> struct mdp4_kms *mdp4_kms = to_mdp4_kms(to_mdp_kms(kms));
> @@ -172,8 +168,7 @@ static void mdp4_destroy(struct msm_kms *kms)
> drm_gem_object_put_unlocked(mdp4_kms->blank_cursor_bo);
>
> if (aspace) {
> - aspace->mmu->funcs->detach(aspace->mmu,
> - iommu_ports, ARRAY_SIZE(iommu_ports));
> + aspace->mmu->funcs->detach(aspace->mmu);
> msm_gem_address_space_put(aspace);
> }
>
> @@ -524,8 +519,7 @@ struct msm_kms *mdp4_kms_init(struct drm_device *dev)
>
> kms->aspace = aspace;
>
> - ret = aspace->mmu->funcs->attach(aspace->mmu, iommu_ports,
> - ARRAY_SIZE(iommu_ports));
> + ret = aspace->mmu->funcs->attach(aspace->mmu);
> if (ret)
> goto fail;
> } else {
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> index 91cd76a2bab1..f8bd0bfcf4b0 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> @@ -19,10 +19,6 @@
> #include "msm_mmu.h"
> #include "mdp5_kms.h"
>
> -static const char *iommu_ports[] = {
> - "mdp_0",
> -};
> -
> static int mdp5_hw_init(struct msm_kms *kms)
> {
> struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
> @@ -233,8 +229,7 @@ static void mdp5_kms_destroy(struct msm_kms *kms)
> mdp5_pipe_destroy(mdp5_kms->hwpipes[i]);
>
> if (aspace) {
> - aspace->mmu->funcs->detach(aspace->mmu,
> - iommu_ports, ARRAY_SIZE(iommu_ports));
> + aspace->mmu->funcs->detach(aspace->mmu);
> msm_gem_address_space_put(aspace);
> }
> }
> @@
[Bug 111691] hardware cursor corruption w/ AMD 5700 XT
https://bugs.freedesktop.org/show_bug.cgi?id=111691 --- Comment #8 from Michael Haworth --- Thanks for the explanation. I only recently bought the graphics card and the bug occurred the first time I used it on linux -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111691] hardware cursor corruption w/ AMD 5700 XT
https://bugs.freedesktop.org/show_bug.cgi?id=111691 --- Comment #7 from Felix Schwarz --- >> If this is a regression, can you bisect? > do not know how to answer your question, this is my first bug report. Regression: Was the bug always present (as far as you know) or did it work in the past? If it worked previously you can do a "git bisection" to find the problematic change. This increases the likelihood that AMD's driver developers can build a fix quickly. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: Remove unused function arguments
The arguments related to IOMMU port name have been unused since
commit 944fc36c31ed ("drm/msm: use upstream iommu") and can be removed.
Signed-off-by: Drew Davenport
---
Rob, in the original commit the port name stuff was left intentionally.
Would it be alright to remove it now?
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 10 ++
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 10 ++
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 10 ++
drivers/gpu/drm/msm/msm_gpu.c| 5 ++---
drivers/gpu/drm/msm/msm_gpummu.c | 6 ++
drivers/gpu/drm/msm/msm_iommu.c | 6 ++
drivers/gpu/drm/msm/msm_mmu.h| 4 ++--
7 files changed, 14 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 58b0485dc375..3165c2db2541 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -30,10 +30,6 @@
#define CREATE_TRACE_POINTS
#include "dpu_trace.h"
-static const char * const iommu_ports[] = {
- "mdp_0",
-};
-
/*
* To enable overall DRM driver logging
* # echo 0x2 > /sys/module/drm/parameters/debug
@@ -725,8 +721,7 @@ static void _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms)
mmu = dpu_kms->base.aspace->mmu;
- mmu->funcs->detach(mmu, (const char **)iommu_ports,
- ARRAY_SIZE(iommu_ports));
+ mmu->funcs->detach(mmu);
msm_gem_address_space_put(dpu_kms->base.aspace);
dpu_kms->base.aspace = NULL;
@@ -752,8 +747,7 @@ static int _dpu_kms_mmu_init(struct dpu_kms *dpu_kms)
return PTR_ERR(aspace);
}
- ret = aspace->mmu->funcs->attach(aspace->mmu, iommu_ports,
- ARRAY_SIZE(iommu_ports));
+ ret = aspace->mmu->funcs->attach(aspace->mmu);
if (ret) {
DPU_ERROR("failed to attach iommu %d\n", ret);
msm_gem_address_space_put(aspace);
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index 50711ccc8691..dda05436f716 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -157,10 +157,6 @@ static long mdp4_round_pixclk(struct msm_kms *kms,
unsigned long rate,
}
}
-static const char * const iommu_ports[] = {
- "mdp_port0_cb0", "mdp_port1_cb0",
-};
-
static void mdp4_destroy(struct msm_kms *kms)
{
struct mdp4_kms *mdp4_kms = to_mdp4_kms(to_mdp_kms(kms));
@@ -172,8 +168,7 @@ static void mdp4_destroy(struct msm_kms *kms)
drm_gem_object_put_unlocked(mdp4_kms->blank_cursor_bo);
if (aspace) {
- aspace->mmu->funcs->detach(aspace->mmu,
- iommu_ports, ARRAY_SIZE(iommu_ports));
+ aspace->mmu->funcs->detach(aspace->mmu);
msm_gem_address_space_put(aspace);
}
@@ -524,8 +519,7 @@ struct msm_kms *mdp4_kms_init(struct drm_device *dev)
kms->aspace = aspace;
- ret = aspace->mmu->funcs->attach(aspace->mmu, iommu_ports,
- ARRAY_SIZE(iommu_ports));
+ ret = aspace->mmu->funcs->attach(aspace->mmu);
if (ret)
goto fail;
} else {
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 91cd76a2bab1..f8bd0bfcf4b0 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -19,10 +19,6 @@
#include "msm_mmu.h"
#include "mdp5_kms.h"
-static const char *iommu_ports[] = {
- "mdp_0",
-};
-
static int mdp5_hw_init(struct msm_kms *kms)
{
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
@@ -233,8 +229,7 @@ static void mdp5_kms_destroy(struct msm_kms *kms)
mdp5_pipe_destroy(mdp5_kms->hwpipes[i]);
if (aspace) {
- aspace->mmu->funcs->detach(aspace->mmu,
- iommu_ports, ARRAY_SIZE(iommu_ports));
+ aspace->mmu->funcs->detach(aspace->mmu);
msm_gem_address_space_put(aspace);
}
}
@@ -737,8 +732,7 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
kms->aspace = aspace;
- ret = aspace->mmu->funcs->attach(aspace->mmu, iommu_ports,
- ARRAY_SIZE(iommu_ports));
+ ret = aspace->mmu->funcs->attach(aspace->mmu);
if (ret) {
DRM_DEV_ERROR(>dev, "failed to attach iommu:
%d\n",
ret);
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index a052364a5d74..122199af0381 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -838,7 +838,7 @@ msm_gpu_create_address_space(struct msm_gpu *gpu, struct
platform_device *pdev,
return ERR_CAST(aspace);
Re: [Intel-gfx] [PATCH 15/19] drm/i915: Simplify skl_max_scale()
Patches 13, 14 and this 15 look ok to me. Those num/den combos in 13 I
cannot bet my head on but the plumbing look all ok.
Also if on 1..8 some patch wasn't pushed yet, those are all
Reviewed-by: Juha-Pekka Heikkila
Ville Syrjala kirjoitti 8.7.2019 klo 15.53:
From: Ville Syrjälä
Now that the planes declare their minimum cdclk requirements properly
we don't need to check the cdclk in skl_max_scale() anymore. Just check
against the maximum downscale ratio, and move the code next to it's
only caller.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 38
drivers/gpu/drm/i915/display/intel_sprite.c | 12 ++-
drivers/gpu/drm/i915/intel_drv.h | 2 --
3 files changed, 11 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 1e67fbe50476..489620ef476b 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14525,44 +14525,6 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
mutex_unlock(_priv->drm.struct_mutex);
}
-int
-skl_max_scale(const struct intel_crtc_state *crtc_state,
- const struct drm_format_info *format)
-{
- struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- int max_scale;
- int crtc_clock, max_dotclk, tmpclk1, tmpclk2;
-
- if (!crtc_state->base.enable)
- return DRM_PLANE_HELPER_NO_SCALING;
-
- crtc_clock = crtc_state->base.adjusted_mode.crtc_clock;
- max_dotclk =
to_intel_atomic_state(crtc_state->base.state)->cdclk.logical.cdclk;
-
- if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 10)
- max_dotclk *= 2;
-
- if (WARN_ON_ONCE(!crtc_clock || max_dotclk < crtc_clock))
- return DRM_PLANE_HELPER_NO_SCALING;
-
- /*
-* skl max scale is lower of:
-*close to 3 but not 3, -1 is for that purpose
-*or
-*cdclk/crtc_clock
-*/
- if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv) ||
- !drm_format_info_is_yuv_semiplanar(format))
- tmpclk1 = 0x3 - 1;
- else
- tmpclk1 = 0x2 - 1;
- tmpclk2 = (1 << 8) * ((max_dotclk << 8) / crtc_clock);
- max_scale = min(tmpclk1, tmpclk2);
-
- return max_scale;
-}
-
static void intel_begin_crtc_commit(struct intel_atomic_state *state,
struct intel_crtc *crtc)
{
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index a07887279e1a..0ffbec8291ee 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -2089,6 +2089,16 @@ static int skl_plane_check_nv12_rotation(const struct
intel_plane_state *plane_s
return 0;
}
+static int skl_plane_max_scale(struct drm_i915_private *dev_priv,
+ const struct drm_framebuffer *fb)
+{
+ if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv) ||
+ !drm_format_info_is_yuv_semiplanar(fb->format))
+ return 0x3 - 1;
+ else
+ return 0x2 - 1;
+}
+
static int skl_plane_check(struct intel_crtc_state *crtc_state,
struct intel_plane_state *plane_state)
{
@@ -2106,7 +2116,7 @@ static int skl_plane_check(struct intel_crtc_state
*crtc_state,
/* use scaler when colorkey is not required */
if (!plane_state->ckey.flags && intel_fb_scalable(fb)) {
min_scale = 1;
- max_scale = skl_max_scale(crtc_state, fb->format);
+ max_scale = skl_plane_max_scale(dev_priv, fb);
}
ret = drm_atomic_helper_check_plane_state(_state->base,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 999ad3166cd1..02eeaec86997 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1620,8 +1620,6 @@ void intel_crtc_arm_fifo_underrun(struct intel_crtc *crtc,
u16 skl_scaler_calc_phase(int sub, int scale, bool chroma_center);
int skl_update_scaler_crtc(struct intel_crtc_state *crtc_state);
-int skl_max_scale(const struct intel_crtc_state *crtc_state,
- const struct drm_format_info *format);
static inline u32 intel_plane_ggtt_offset(const struct intel_plane_state *state)
{
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 2/2] drm/mm: Pack allocated/scanned boolean into a bitfield
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
>Of Chris Wilson
>Sent: Sunday, September 15, 2019 2:46 PM
>To: dri-devel@lists.freedesktop.org
>Cc: intel-...@lists.freedesktop.org
>Subject: [PATCH 2/2] drm/mm: Pack allocated/scanned boolean into a bitfield
>
>The ulterior motive to switching the booleans over to bitops is to
>allow use of the allocated flag as a bitlock.
>
>Signed-off-by: Chris Wilson
>---
> drivers/gpu/drm/drm_mm.c | 36 +++
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 6 ++--
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 2 +-
> drivers/gpu/drm/i915/i915_gem.c | 16 -
> drivers/gpu/drm/i915/i915_gem_evict.c | 2 +-
> drivers/gpu/drm/i915/i915_vma.c | 2 +-
> drivers/gpu/drm/i915/i915_vma.h | 4 +--
> drivers/gpu/drm/selftests/test-drm_mm.c | 14
> drivers/gpu/drm/vc4/vc4_crtc.c| 2 +-
> drivers/gpu/drm/vc4/vc4_hvs.c | 2 +-
> drivers/gpu/drm/vc4/vc4_plane.c | 4 +--
> include/drm/drm_mm.h | 7 ++--
> 12 files changed, 52 insertions(+), 45 deletions(-)
>
>diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
>index 4581c5387372..211967006cec 100644
>--- a/drivers/gpu/drm/drm_mm.c
>+++ b/drivers/gpu/drm/drm_mm.c
>@@ -174,7 +174,7 @@ static void drm_mm_interval_tree_add_node(struct
>drm_mm_node *hole_node,
>
> node->__subtree_last = LAST(node);
>
>- if (hole_node->allocated) {
>+ if (drm_mm_node_allocated(hole_node)) {
> rb = _node->rb;
> while (rb) {
> parent = rb_entry(rb, struct drm_mm_node, rb);
>@@ -424,9 +424,9 @@ int drm_mm_reserve_node(struct drm_mm *mm,
>struct drm_mm_node *node)
>
> node->mm = mm;
>
>+ __set_bit(DRM_MM_NODE_ALLOCATED_BIT, >flags);
Maybe a silly question(s), but you appear to be mixing atomic bit ops
(clear_ and test_) with non-atomic bit ops __xxx_bit().
Should that be a concern? Should that be mention in the commit?
Mike
> list_add(>node_list, >node_list);
> drm_mm_interval_tree_add_node(hole, node);
>- node->allocated = true;
> node->hole_size = 0;
>
> rm_hole(hole);
>@@ -543,9 +543,9 @@ int drm_mm_insert_node_in_range(struct drm_mm *
>const mm,
> node->color = color;
> node->hole_size = 0;
>
>+ __set_bit(DRM_MM_NODE_ALLOCATED_BIT, >flags);
> list_add(>node_list, >node_list);
> drm_mm_interval_tree_add_node(hole, node);
>- node->allocated = true;
>
> rm_hole(hole);
> if (adj_start > hole_start)
>@@ -561,6 +561,11 @@ int drm_mm_insert_node_in_range(struct drm_mm
>* const mm,
> }
> EXPORT_SYMBOL(drm_mm_insert_node_in_range);
>
>+static inline bool drm_mm_node_scanned_block(const struct
>drm_mm_node *node)
>+{
>+ return test_bit(DRM_MM_NODE_SCANNED_BIT, >flags);
>+}
>+
> /**
> * drm_mm_remove_node - Remove a memory node from the allocator.
> * @node: drm_mm_node to remove
>@@ -574,8 +579,8 @@ void drm_mm_remove_node(struct drm_mm_node
>*node)
> struct drm_mm *mm = node->mm;
> struct drm_mm_node *prev_node;
>
>- DRM_MM_BUG_ON(!node->allocated);
>- DRM_MM_BUG_ON(node->scanned_block);
>+ DRM_MM_BUG_ON(!drm_mm_node_allocated(node));
>+ DRM_MM_BUG_ON(drm_mm_node_scanned_block(node));
>
> prev_node = list_prev_entry(node, node_list);
>
>@@ -584,11 +589,12 @@ void drm_mm_remove_node(struct
>drm_mm_node *node)
>
> drm_mm_interval_tree_remove(node, >interval_tree);
> list_del(>node_list);
>- node->allocated = false;
>
> if (drm_mm_hole_follows(prev_node))
> rm_hole(prev_node);
> add_hole(prev_node);
>+
>+ clear_bit_unlock(DRM_MM_NODE_ALLOCATED_BIT, >flags);
> }
> EXPORT_SYMBOL(drm_mm_remove_node);
>
>@@ -605,7 +611,7 @@ void drm_mm_replace_node(struct drm_mm_node
>*old, struct drm_mm_node *new)
> {
> struct drm_mm *mm = old->mm;
>
>- DRM_MM_BUG_ON(!old->allocated);
>+ DRM_MM_BUG_ON(!drm_mm_node_allocated(old));
>
> *new = *old;
>
>@@ -622,8 +628,7 @@ void drm_mm_replace_node(struct drm_mm_node
>*old, struct drm_mm_node *new)
> >holes_addr);
> }
>
>- old->allocated = false;
>- new->allocated = true;
>+ clear_bit_unlock(DRM_MM_NODE_ALLOCATED_BIT, >flags);
> }
> EXPORT_SYMBOL(drm_mm_replace_node);
>
>@@ -731,9 +736,9 @@ bool drm_mm_scan_add_block(struct drm_mm_scan
>*scan,
> u64 adj_start, adj_end;
>
> DRM_MM_BUG_ON(node->mm != mm);
>- DRM_MM_BUG_ON(!node->allocated);
>- DRM_MM_BUG_ON(node->scanned_block);
>- node->scanned_block = true;
>+ DRM_MM_BUG_ON(!drm_mm_node_allocated(node));
>+ DRM_MM_BUG_ON(drm_mm_node_scanned_block(node));
>+ __set_bit(DRM_MM_NODE_SCANNED_BIT, >flags);
>
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/connector: Share with non-atomic drivers the function to get the single encoder
On Mon, Sep 16, 2019 at 07:34:32PM +, Souza, Jose wrote: > Someone with drm-misc commit access could push this? > Sure will push this series. Manasi > Thanks > > On Sun, 2019-09-15 at 11:36 +, Patchwork wrote: > > == Series Details == > > > > Series: series starting with [CI,1/2] drm/connector: Share with non- > > atomic drivers the function to get the single encoder > > URL : https://patchwork.freedesktop.org/series/66701/ > > State : success > > > > == Summary == > > > > CI Bug Log - changes from CI_DRM_6894_full -> Patchwork_14412_full > > > > > > Summary > > --- > > > > **SUCCESS** > > > > No regressions found. > > > > > > > > Known issues > > > > > > Here are the changes found in Patchwork_14412_full that come from > > known issues: > > > > ### IGT changes ### > > > > Issues hit > > > > * igt@gem_exec_schedule@preempt-contexts-bsd2: > > - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276]) +14 > > similar issues > >[1]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-iclb1/igt@gem_exec_sched...@preempt-contexts-bsd2.html > >[2]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-iclb7/igt@gem_exec_sched...@preempt-contexts-bsd2.html > > > > * igt@gem_exec_schedule@preemptive-hang-bsd: > > - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +3 > > similar issues > >[3]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-iclb6/igt@gem_exec_sched...@preemptive-hang-bsd.html > >[4]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-iclb4/igt@gem_exec_sched...@preemptive-hang-bsd.html > > > > * igt@i915_pm_rpm@modeset-stress-extra-wait: > > - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([fdo#105763] > > / [fdo#106538]) > >[5]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-glk7/igt@i915_pm_...@modeset-stress-extra-wait.html > >[6]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-glk8/igt@i915_pm_...@modeset-stress-extra-wait.html > > > > * igt@i915_suspend@fence-restore-tiled2untiled: > > - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) > > +3 similar issues > >[7]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl1/igt@i915_susp...@fence-restore-tiled2untiled.html > >[8]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl7/igt@i915_susp...@fence-restore-tiled2untiled.html > > > > * igt@kms_cursor_crc@pipe-b-cursor-alpha-transparent: > > - shard-snb: [PASS][9] -> [SKIP][10] ([fdo#109271]) > >[9]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-snb5/igt@kms_cursor_...@pipe-b-cursor-alpha-transparent.html > >[10]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-snb7/igt@kms_cursor_...@pipe-b-cursor-alpha-transparent.html > > > > * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: > > - shard-hsw: [PASS][11] -> [FAIL][12] ([fdo#105767]) > >[11]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html > >[12]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html > > > > * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: > > - shard-glk: [PASS][13] -> [FAIL][14] ([fdo#105363]) > >[13]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-glk8/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html > >[14]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-glk2/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html > > > > * igt@kms_flip@basic-flip-vs-modeset: > > - shard-apl: [PASS][15] -> [INCOMPLETE][16] > > ([fdo#103927]) > >[15]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl7/igt@kms_f...@basic-flip-vs-modeset.html > >[16]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl3/igt@kms_f...@basic-flip-vs-modeset.html > > > > * igt@kms_flip@flip-vs-expired-vblank-interruptible: > > - shard-apl: [PASS][17] -> [FAIL][18] ([fdo#105363]) > >[17]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html > >[18]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl3/igt@kms_f...@flip-vs-expired-vblank-interruptible.html > > > > * igt@kms > > _frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite: > > - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +7 > > similar issues > >[19]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html > >[20]: > >
Re: ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/connector: Share with non-atomic drivers the function to get the single encoder
Someone with drm-misc commit access could push this? Thanks On Sun, 2019-09-15 at 11:36 +, Patchwork wrote: > == Series Details == > > Series: series starting with [CI,1/2] drm/connector: Share with non- > atomic drivers the function to get the single encoder > URL : https://patchwork.freedesktop.org/series/66701/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_6894_full -> Patchwork_14412_full > > > Summary > --- > > **SUCCESS** > > No regressions found. > > > > Known issues > > > Here are the changes found in Patchwork_14412_full that come from > known issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_exec_schedule@preempt-contexts-bsd2: > - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276]) +14 > similar issues >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-iclb1/igt@gem_exec_sched...@preempt-contexts-bsd2.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-iclb7/igt@gem_exec_sched...@preempt-contexts-bsd2.html > > * igt@gem_exec_schedule@preemptive-hang-bsd: > - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +3 > similar issues >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-iclb6/igt@gem_exec_sched...@preemptive-hang-bsd.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-iclb4/igt@gem_exec_sched...@preemptive-hang-bsd.html > > * igt@i915_pm_rpm@modeset-stress-extra-wait: > - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([fdo#105763] > / [fdo#106538]) >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-glk7/igt@i915_pm_...@modeset-stress-extra-wait.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-glk8/igt@i915_pm_...@modeset-stress-extra-wait.html > > * igt@i915_suspend@fence-restore-tiled2untiled: > - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) > +3 similar issues >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl1/igt@i915_susp...@fence-restore-tiled2untiled.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl7/igt@i915_susp...@fence-restore-tiled2untiled.html > > * igt@kms_cursor_crc@pipe-b-cursor-alpha-transparent: > - shard-snb: [PASS][9] -> [SKIP][10] ([fdo#109271]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-snb5/igt@kms_cursor_...@pipe-b-cursor-alpha-transparent.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-snb7/igt@kms_cursor_...@pipe-b-cursor-alpha-transparent.html > > * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: > - shard-hsw: [PASS][11] -> [FAIL][12] ([fdo#105767]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html > > * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: > - shard-glk: [PASS][13] -> [FAIL][14] ([fdo#105363]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-glk8/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-glk2/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html > > * igt@kms_flip@basic-flip-vs-modeset: > - shard-apl: [PASS][15] -> [INCOMPLETE][16] > ([fdo#103927]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl7/igt@kms_f...@basic-flip-vs-modeset.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl3/igt@kms_f...@basic-flip-vs-modeset.html > > * igt@kms_flip@flip-vs-expired-vblank-interruptible: > - shard-apl: [PASS][17] -> [FAIL][18] ([fdo#105363]) >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-apl1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-apl3/igt@kms_f...@flip-vs-expired-vblank-interruptible.html > > * igt@kms > _frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite: > - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +7 > similar issues >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6894/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14412/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html > > * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: > - shard-skl: [PASS][21] -> [INCOMPLETE][22] > ([fdo#104108]) >[21]: >
[Bug 111691] hardware cursor corruption w/ AMD 5700 XT
https://bugs.freedesktop.org/show_bug.cgi?id=111691 --- Comment #6 from Michael Haworth --- I have attached the logs but do not know how to answer your question, this is my first bug report. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111691] hardware cursor corruption w/ AMD 5700 XT
https://bugs.freedesktop.org/show_bug.cgi?id=111691 --- Comment #5 from Michael Haworth --- Created attachment 145383 --> https://bugs.freedesktop.org/attachment.cgi?id=145383=edit Xorg log after booting with HW cursor enabled -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111691] hardware cursor corruption w/ AMD 5700 XT
https://bugs.freedesktop.org/show_bug.cgi?id=111691 --- Comment #4 from Michael Haworth --- Created attachment 145382 --> https://bugs.freedesktop.org/attachment.cgi?id=145382=edit dmesg output after booting with HW cursor enabled -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111691] hardware cursor corruption w/ AMD 5700 XT
https://bugs.freedesktop.org/show_bug.cgi?id=111691 --- Comment #3 from Alex Deucher --- Please attach your xorg log (if using X) and your dmesg output. If this is a regression, can you bisect? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111682] use-after-free in amdgpu_vm_update_directories
https://bugs.freedesktop.org/show_bug.cgi?id=111682 --- Comment #2 from Pierre-Eric Pelloux-Prayer --- (In reply to Andrey Grodzovsky from comment #1) > Which kernel branch are you using ? I couldn't find > amdgpu_vm_update_directories in latest code in amd-staging-drm-next and > turns out it was renamed to amdgpu_vm_update_pdes in > 78b20c2ee6788ba0df8b36b1369bc7e264262d3b back in March so seems like this is > very outdated code. I'm using amd-staging-drm-next from a few days ago. But 78b20c2ee6788ba0df8b36b1369bc7e264262d3b (drm/amdgpu: allow direct submission of PDE updates v2) has been pushed in this branch recently and indeed it renamed the function. I'll rebuild a kernel and test if the issue is still there. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #47 from Mathieu Belanger --- Naa, Random crash still occur with FileZilla, so there not totally gone for me. I put nodma back because I use that system for work. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111232] 3200 Memory Crash My System
https://bugs.freedesktop.org/show_bug.cgi?id=111232 --- Comment #9 from Andrey Grodzovsky --- I noticed IOMMU page fault in the log - is disabling iommu helps ? (from grub cmdline add iommu=off) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Fix compile error due to 'endif' missing
On Tue, Sep 17, 2019 at 02:46:48AM +0900, Masahiro Yamada wrote: > (+CC Stephen Rothwell, Mark Brown) > > On Mon, Sep 16, 2019 at 1:46 PM Austin Kim wrote: > > > > gcc throws compile error with below message: > > GNU Make throws ... > > I don't have the original patch so I don't know what the issue being reported is :/ Whatever it is it wasn't caught by any of the builds done during the process of building -next and nothing is jumping out at me on KernelCI. > This is probably a merge mistake in linux-next. > If so, this should be directly fixed in the linux-next. > If it is not fixed in time, > please inform Linus to *not* follow the linux-next. It's probably worth coordinating this merge with DRM, it's not *super* complex but clearly there's some potential for error here and it was definitely annoyingly fiddly. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111682] use-after-free in amdgpu_vm_update_directories
https://bugs.freedesktop.org/show_bug.cgi?id=111682 --- Comment #1 from Andrey Grodzovsky --- Which kernel branch are you using ? I couldn't find amdgpu_vm_update_directories in latest code in amd-staging-drm-next and turns out it was renamed to amdgpu_vm_update_pdes in 78b20c2ee6788ba0df8b36b1369bc7e264262d3b back in March so seems like this is very outdated code. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/tegra: switch to using devm_gpiod_get_optional
On Mon, Sep 16, 2019 at 03:59:04PM +0200, Thierry Reding wrote: > On Sun, Sep 15, 2019 at 12:13:23AM -0700, Dmitry Torokhov wrote: > > We do not really need to use API that fetches GPIO data from an > > arbitrary device tree node, as we are dealing with device tree node > > assigned to the device structure. We can easily switch to > > devm_gpiod_get_optional() plus gpiod_set_consumer_name() and clean up > > the code. > > > > Note this is part of efforts to get rid of [devm_]gpiod_get_from_of_node > > in drivers so that gpiolib can be cleaned up. > > > > Signed-off-by: Dmitry Torokhov > > --- > > drivers/gpu/drm/tegra/output.c | 18 +++--- > > 1 file changed, 7 insertions(+), 11 deletions(-) > > We can't do that. There's a special case in rgb.c that sets > output->of_node to something different than output->dev, so we actually > need to pass the struct device_node * separately. Ugh, brainfart on my part. I totally read it is output->dev.of_node, similar to another driver I was looking at... Please discard, there will be another patch changing devm_gpiod_get_from_of_node() to devm_fwnode_gpiod_get() once Linus merges this new GPIO method. Thanks. -- Dmitry
Re: [PATCH 08/11] drm/nouveau: tegra: Skip IOMMU initialization if already attached
On 16/09/2019 16:57, Thierry Reding wrote:
On Mon, Sep 16, 2019 at 04:29:18PM +0100, Robin Murphy wrote:
Hi Thierry,
On 16/09/2019 16:04, Thierry Reding wrote:
From: Thierry Reding
If the GPU is already attached to an IOMMU, don't detach it and setup an
explicit IOMMU domain. Since Nouveau can now properly handle the case of
the DMA API being backed by an IOMMU, just continue using the DMA API.
Signed-off-by: Thierry Reding
---
.../drm/nouveau/nvkm/engine/device/tegra.c| 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
index d0d52c1d4aee..fc652aaa41c7 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
@@ -23,10 +23,6 @@
#ifdef CONFIG_NOUVEAU_PLATFORM_DRIVER
#include "priv.h"
-#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
-#include
-#endif
-
static int
nvkm_device_tegra_power_up(struct nvkm_device_tegra *tdev)
{
@@ -109,14 +105,13 @@ nvkm_device_tegra_probe_iommu(struct nvkm_device_tegra
*tdev)
unsigned long pgsize_bitmap;
int ret;
-#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
- if (dev->archdata.mapping) {
- struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
-
- arm_iommu_detach_device(dev);
- arm_iommu_release_mapping(mapping);
- }
-#endif
+ /*
+* Skip explicit IOMMU initialization if the GPU is already attached
+* to an IOMMU domain. This can happen if the DMA API is backed by an
+* IOMMU.
+*/
+ if (iommu_get_domain_for_dev(dev))
+ return;
Beware of "iommu.passthrough=1" - you could get a valid default domain here
yet still have direct/SWIOTLB DMA ops. I guess you probably want to
double-check the domain type as well.
Good point. An earlier version of this patch had an additional check for
IOMMU_DOMAIN_DMA, but then that failed on 32-bit ARM because there the
DMA API can also use IOMMU_DOMAIN_UNMANAGED type domains. Checking for
IOMMU_DOMAIN_IDENTIFY should be safe, though. That doesn't seem to
appear in arch/arm, arch/arm64 or drivers/iommu/dma-iommu.c.
Right, "domain && domain->type != IOMMU_DOMAIN_IDENTITY" should be
sufficient to answer "is the DMA layer managing my address space for
me?" unless and until some massive API change happens (which I certainly
don't foresee).
Robin.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/11] drm/nouveau: tegra: Skip IOMMU initialization if already attached
On Mon, Sep 16, 2019 at 04:29:18PM +0100, Robin Murphy wrote:
> Hi Thierry,
>
> On 16/09/2019 16:04, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > If the GPU is already attached to an IOMMU, don't detach it and setup an
> > explicit IOMMU domain. Since Nouveau can now properly handle the case of
> > the DMA API being backed by an IOMMU, just continue using the DMA API.
> >
> > Signed-off-by: Thierry Reding
> > ---
> > .../drm/nouveau/nvkm/engine/device/tegra.c| 19 +++
> > 1 file changed, 7 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
> > b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
> > index d0d52c1d4aee..fc652aaa41c7 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
> > @@ -23,10 +23,6 @@
> > #ifdef CONFIG_NOUVEAU_PLATFORM_DRIVER
> > #include "priv.h"
> > -#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
> > -#include
> > -#endif
> > -
> > static int
> > nvkm_device_tegra_power_up(struct nvkm_device_tegra *tdev)
> > {
> > @@ -109,14 +105,13 @@ nvkm_device_tegra_probe_iommu(struct
> > nvkm_device_tegra *tdev)
> > unsigned long pgsize_bitmap;
> > int ret;
> > -#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
> > - if (dev->archdata.mapping) {
> > - struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
> > -
> > - arm_iommu_detach_device(dev);
> > - arm_iommu_release_mapping(mapping);
> > - }
> > -#endif
> > + /*
> > +* Skip explicit IOMMU initialization if the GPU is already attached
> > +* to an IOMMU domain. This can happen if the DMA API is backed by an
> > +* IOMMU.
> > +*/
> > + if (iommu_get_domain_for_dev(dev))
> > + return;
>
> Beware of "iommu.passthrough=1" - you could get a valid default domain here
> yet still have direct/SWIOTLB DMA ops. I guess you probably want to
> double-check the domain type as well.
Good point. An earlier version of this patch had an additional check for
IOMMU_DOMAIN_DMA, but then that failed on 32-bit ARM because there the
DMA API can also use IOMMU_DOMAIN_UNMANAGED type domains. Checking for
IOMMU_DOMAIN_IDENTIFY should be safe, though. That doesn't seem to
appear in arch/arm, arch/arm64 or drivers/iommu/dma-iommu.c.
Thierry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/11] drm/nouveau: gp10b: Add custom L2 cache implementation
On Mon, Sep 16, 2019 at 05:49:46PM +0200, Thierry Reding wrote:
> On Mon, Sep 16, 2019 at 04:35:30PM +0100, Ben Dooks wrote:
> > On 16/09/2019 16:04, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > There are extra registers that need to be programmed to make the level 2
> > > cache work on GP10B, such as the stream ID register that is used when an
> > > SMMU is used to translate memory addresses.
> > >
> > > Signed-off-by: Thierry Reding
> > > ---
> > > .../gpu/drm/nouveau/include/nvkm/subdev/ltc.h | 1 +
> > > .../gpu/drm/nouveau/nvkm/engine/device/base.c | 2 +-
> > > .../gpu/drm/nouveau/nvkm/subdev/ltc/Kbuild| 1 +
> > > .../gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c | 69 +++
> > > .../gpu/drm/nouveau/nvkm/subdev/ltc/priv.h| 2 +
> > > 5 files changed, 74 insertions(+), 1 deletion(-)
> > > create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c
> > >
> > > diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/ltc.h
> > > b/drivers/gpu/drm/nouveau/include/nvkm/subdev/ltc.h
> > > index 644d527c3b96..d76f60d7d29a 100644
> > > --- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/ltc.h
> > > +++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/ltc.h
> > > @@ -40,4 +40,5 @@ int gm107_ltc_new(struct nvkm_device *, int, struct
> > > nvkm_ltc **);
> > > int gm200_ltc_new(struct nvkm_device *, int, struct nvkm_ltc **);
> > > int gp100_ltc_new(struct nvkm_device *, int, struct nvkm_ltc **);
> > > int gp102_ltc_new(struct nvkm_device *, int, struct nvkm_ltc **);
> > > +int gp10b_ltc_new(struct nvkm_device *, int, struct nvkm_ltc **);
> > > #endif
> > > diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> > > b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> > > index c3c7159f3411..d2d6d5f4028a 100644
> > > --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> > > +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> > > @@ -2380,7 +2380,7 @@ nv13b_chipset = {
> > > .fuse = gm107_fuse_new,
> > > .ibus = gp10b_ibus_new,
> > > .imem = gk20a_instmem_new,
> > > - .ltc = gp102_ltc_new,
> > > + .ltc = gp10b_ltc_new,
> > > .mc = gp10b_mc_new,
> > > .mmu = gp10b_mmu_new,
> > > .secboot = gp10b_secboot_new,
> > > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/Kbuild
> > > b/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/Kbuild
> > > index 2b6d36ea7067..728d75010847 100644
> > > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/Kbuild
> > > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/Kbuild
> > > @@ -6,3 +6,4 @@ nvkm-y += nvkm/subdev/ltc/gm107.o
> > > nvkm-y += nvkm/subdev/ltc/gm200.o
> > > nvkm-y += nvkm/subdev/ltc/gp100.o
> > > nvkm-y += nvkm/subdev/ltc/gp102.o
> > > +nvkm-y += nvkm/subdev/ltc/gp10b.o
> > > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c
> > > b/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c
> > > new file mode 100644
> > > index ..4d27c6ea1552
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c
> > > @@ -0,0 +1,69 @@
> > > +/*
> > > + * Copyright (c) 2019 NVIDIA Corporation.
> > > + *
> > > + * Permission is hereby granted, free of charge, to any person obtaining
> > > a
> > > + * copy of this software and associated documentation files (the
> > > "Software"),
> > > + * to deal in the Software without restriction, including without
> > > limitation
> > > + * the rights to use, copy, modify, merge, publish, distribute,
> > > sublicense,
> > > + * and/or sell copies of the Software, and to permit persons to whom the
> > > + * Software is furnished to do so, subject to the following conditions:
> > > + *
> > > + * The above copyright notice and this permission notice shall be
> > > included in
> > > + * all copies or substantial portions of the Software.
> > > + *
> > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > > EXPRESS OR
> > > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > > MERCHANTABILITY,
> > > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
> > > SHALL
> > > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES
> > > OR
> > > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> > > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > > + * OTHER DEALINGS IN THE SOFTWARE.
> > > + *
> > > + * Authors: Thierry Reding
> > > + */
> > > +
> > > +#include "priv.h"
> > > +
> > > +static void
> > > +gp10b_ltc_init(struct nvkm_ltc *ltc)
> > > +{
> > > + struct nvkm_device *device = ltc->subdev.device;
> > > +#ifdef CONFIG_IOMMU_API
> > > + struct iommu_fwspec *spec;
> > > +#endif
> > > +
> > > + nvkm_wr32(device, 0x17e27c, ltc->ltc_nr);
> > > + nvkm_wr32(device, 0x17e000, ltc->ltc_nr);
> > > + nvkm_wr32(device, 0x100800, ltc->ltc_nr);
> > > +
> > > +#ifdef CONFIG_IOMMU_API
> > > + spec = dev_iommu_fwspec_get(device->dev);
> > > + if (spec) {
> > > +
Re: [PATCH 04/11] drm/nouveau: gp10b: Add custom L2 cache implementation
On Mon, Sep 16, 2019 at 04:35:30PM +0100, Ben Dooks wrote:
> On 16/09/2019 16:04, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > There are extra registers that need to be programmed to make the level 2
> > cache work on GP10B, such as the stream ID register that is used when an
> > SMMU is used to translate memory addresses.
> >
> > Signed-off-by: Thierry Reding
> > ---
> > .../gpu/drm/nouveau/include/nvkm/subdev/ltc.h | 1 +
> > .../gpu/drm/nouveau/nvkm/engine/device/base.c | 2 +-
> > .../gpu/drm/nouveau/nvkm/subdev/ltc/Kbuild| 1 +
> > .../gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c | 69 +++
> > .../gpu/drm/nouveau/nvkm/subdev/ltc/priv.h| 2 +
> > 5 files changed, 74 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c
> >
> > diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/ltc.h
> > b/drivers/gpu/drm/nouveau/include/nvkm/subdev/ltc.h
> > index 644d527c3b96..d76f60d7d29a 100644
> > --- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/ltc.h
> > +++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/ltc.h
> > @@ -40,4 +40,5 @@ int gm107_ltc_new(struct nvkm_device *, int, struct
> > nvkm_ltc **);
> > int gm200_ltc_new(struct nvkm_device *, int, struct nvkm_ltc **);
> > int gp100_ltc_new(struct nvkm_device *, int, struct nvkm_ltc **);
> > int gp102_ltc_new(struct nvkm_device *, int, struct nvkm_ltc **);
> > +int gp10b_ltc_new(struct nvkm_device *, int, struct nvkm_ltc **);
> > #endif
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> > b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> > index c3c7159f3411..d2d6d5f4028a 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> > @@ -2380,7 +2380,7 @@ nv13b_chipset = {
> > .fuse = gm107_fuse_new,
> > .ibus = gp10b_ibus_new,
> > .imem = gk20a_instmem_new,
> > - .ltc = gp102_ltc_new,
> > + .ltc = gp10b_ltc_new,
> > .mc = gp10b_mc_new,
> > .mmu = gp10b_mmu_new,
> > .secboot = gp10b_secboot_new,
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/Kbuild
> > b/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/Kbuild
> > index 2b6d36ea7067..728d75010847 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/Kbuild
> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/Kbuild
> > @@ -6,3 +6,4 @@ nvkm-y += nvkm/subdev/ltc/gm107.o
> > nvkm-y += nvkm/subdev/ltc/gm200.o
> > nvkm-y += nvkm/subdev/ltc/gp100.o
> > nvkm-y += nvkm/subdev/ltc/gp102.o
> > +nvkm-y += nvkm/subdev/ltc/gp10b.o
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c
> > b/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c
> > new file mode 100644
> > index ..4d27c6ea1552
> > --- /dev/null
> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c
> > @@ -0,0 +1,69 @@
> > +/*
> > + * Copyright (c) 2019 NVIDIA Corporation.
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> > + * copy of this software and associated documentation files (the
> > "Software"),
> > + * to deal in the Software without restriction, including without
> > limitation
> > + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice shall be included
> > in
> > + * all copies or substantial portions of the Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> > OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > + * OTHER DEALINGS IN THE SOFTWARE.
> > + *
> > + * Authors: Thierry Reding
> > + */
> > +
> > +#include "priv.h"
> > +
> > +static void
> > +gp10b_ltc_init(struct nvkm_ltc *ltc)
> > +{
> > + struct nvkm_device *device = ltc->subdev.device;
> > +#ifdef CONFIG_IOMMU_API
> > + struct iommu_fwspec *spec;
> > +#endif
> > +
> > + nvkm_wr32(device, 0x17e27c, ltc->ltc_nr);
> > + nvkm_wr32(device, 0x17e000, ltc->ltc_nr);
> > + nvkm_wr32(device, 0x100800, ltc->ltc_nr);
> > +
> > +#ifdef CONFIG_IOMMU_API
> > + spec = dev_iommu_fwspec_get(device->dev);
> > + if (spec) {
> > + u32 sid = spec->ids[0] & 0x;
> > +
> > + /* stream ID */
> > + nvkm_wr32(device, 0x16, sid << 2);
> > + }
> > +#endif
>
> Could we get rid of the #ifdef blocks here if there was a NULL
> inline version of dev_iommu_fwspec_get() in the include/linux/iommu.h
> header? The compiler should then
Re: [PATCH v5 0/8] add driver for boe, tv101wum-nl6, boe, tv101wum-n53, auo, kd101n80-45na and auo, b101uan08.3 panels
Hi Jitao. > Changes since v4: You are hit by some of the progress made in the kernel. New dispaly bindings are preferred to be in meta-schma formal (.yaml files). This allows more formals checks and this is the format that we hope all display bindigns will migrate over to use once someone steps up and do a mass conversion. This is a bit extra work now, but much better to have it done by someone who knows the HW. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/11] drm/nouveau: tegra: Skip IOMMU initialization if already attached
Hi Thierry,
On 16/09/2019 16:04, Thierry Reding wrote:
From: Thierry Reding
If the GPU is already attached to an IOMMU, don't detach it and setup an
explicit IOMMU domain. Since Nouveau can now properly handle the case of
the DMA API being backed by an IOMMU, just continue using the DMA API.
Signed-off-by: Thierry Reding
---
.../drm/nouveau/nvkm/engine/device/tegra.c| 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
index d0d52c1d4aee..fc652aaa41c7 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
@@ -23,10 +23,6 @@
#ifdef CONFIG_NOUVEAU_PLATFORM_DRIVER
#include "priv.h"
-#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
-#include
-#endif
-
static int
nvkm_device_tegra_power_up(struct nvkm_device_tegra *tdev)
{
@@ -109,14 +105,13 @@ nvkm_device_tegra_probe_iommu(struct nvkm_device_tegra
*tdev)
unsigned long pgsize_bitmap;
int ret;
-#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
- if (dev->archdata.mapping) {
- struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
-
- arm_iommu_detach_device(dev);
- arm_iommu_release_mapping(mapping);
- }
-#endif
+ /*
+* Skip explicit IOMMU initialization if the GPU is already attached
+* to an IOMMU domain. This can happen if the DMA API is backed by an
+* IOMMU.
+*/
+ if (iommu_get_domain_for_dev(dev))
+ return;
Beware of "iommu.passthrough=1" - you could get a valid default domain
here yet still have direct/SWIOTLB DMA ops. I guess you probably want to
double-check the domain type as well.
Robin.
if (!tdev->func->iommu_bit)
return;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/6] drm/nouveau: fault: Store aperture in fault information
From: Thierry Reding
The fault information register contains data about the aperture that
caused the failure. This can be useful in debugging aperture related
programming bugs.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/include/nvkm/subdev/fault.h | 1 +
drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c| 3 ++-
drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.c | 1 +
3 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/fault.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/fault.h
index 97322f95b3ee..1cc862bc1122 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/fault.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/fault.h
@@ -21,6 +21,7 @@ struct nvkm_fault_data {
u64 addr;
u64 inst;
u64 time;
+ u8 aperture;
u8 engine;
u8 valid;
u8gpc;
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
index 5d4b695cab8e..81cbe1cc4804 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
@@ -519,9 +519,10 @@ gk104_fifo_fault(struct nvkm_fifo *base, struct
nvkm_fault_data *info)
chan = nvkm_fifo_chan_inst_locked(>base, info->inst);
nvkm_error(subdev,
- "fault %02x [%s] at %016llx engine %02x [%s] client %02x "
+ "fault %02x [%s] at %016llx aperture %02x engine %02x [%s]
client %02x "
"[%s%s] reason %02x [%s] on channel %d [%010llx %s]\n",
info->access, ea ? ea->name : "", info->addr,
+ info->aperture,
info->engine, ee ? ee->name : en,
info->client, ct, ec ? ec->name : "",
info->reason, er ? er->name : "", chan ? chan->chid : -1,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.c
index 6747f09c2dc3..b5e32295237b 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.c
@@ -138,6 +138,7 @@ gv100_fault_intr_fault(struct nvkm_fault *fault)
info.inst = ((u64)insthi << 32) | (info0 & 0xf000);
info.time = 0;
info.engine = (info0 & 0x00ff);
+ info.aperture = (info0 & 0x0c00) >> 10;
info.valid = (info1 & 0x8000) >> 31;
info.gpc= (info1 & 0x1f00) >> 24;
info.hub= (info1 & 0x0010) >> 20;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/6] drm/nouveau: Preparatory work for GV11B support
From: Thierry Reding Hi Ben, these are a couple of patches that are in preparation for adding GV11B support. The fundamental issue that these are trying to solve is that the GV11B is the first Tegra incarnation of the GPU where the aperture really matters. All prior generations would accept any of them. For dGPUs we usually allocate memory in VRAM, so the default aperture (0) is correct. However, on Tegra the buffers are allocated in system memory, and since the GPU actually cares about the aperture, we need to ensure that the aperture field is written in all the necessary places. This series of patches does three things: the first two patches make it easier to debug aperture related faults by actually reading the aperture information from the fault information registers. The second patch is actually only a small cleanup. Patches 3-5 unify the aperture values. All generations have the same definitions for these, so there's little use in separating them out into callbacks. Finally, patch 6 writes the aperture field in the places where required. I've used these patches to test my initial support for GV11B. This is enough to get me through the driver probe without any faults, but I have not made much progress on secboot support yet, so I can't use the GV11B to do anything very interesting yet. I should also note that this is completely untested on dGPU because I don't currently have a way of testing them. I'm working on that, but in the meantime it'd be great if somebody could give this set a quick spin on a dGPU to confirm that these don't break. Thierry Thierry Reding (6): drm/nouveau: fault: Store aperture in fault information drm/nouveau: fault: Widen engine field drm/nouveau: Remove bogus gk20a aperture callback drm/nouveau: Implement nvkm_memory_aperture() drm/nouveau: Remove unused nvkm_vmm_func->aper() implementations drm/nouveau: Program aperture field where necessary .../drm/nouveau/include/nvkm/core/memory.h| 28 +++ .../drm/nouveau/include/nvkm/subdev/fault.h | 1 + .../gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 3 +- .../nouveau/nvkm/engine/fifo/gpfifogk104.c| 7 +++-- .../nouveau/nvkm/engine/fifo/gpfifogv100.c| 5 ++-- .../gpu/drm/nouveau/nvkm/engine/fifo/gv100.c | 7 - .../gpu/drm/nouveau/nvkm/subdev/bar/gf100.c | 3 +- .../gpu/drm/nouveau/nvkm/subdev/fault/gv100.c | 3 +- drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 3 -- .../drm/nouveau/nvkm/subdev/mmu/vmmgf100.c| 21 ++ .../drm/nouveau/nvkm/subdev/mmu/vmmgk104.c| 2 -- .../drm/nouveau/nvkm/subdev/mmu/vmmgk20a.c| 12 .../drm/nouveau/nvkm/subdev/mmu/vmmgm200.c| 2 -- .../drm/nouveau/nvkm/subdev/mmu/vmmgm20b.c| 2 -- .../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c| 8 ++ .../drm/nouveau/nvkm/subdev/mmu/vmmgp10b.c| 1 - .../drm/nouveau/nvkm/subdev/mmu/vmmgv100.c| 1 - .../drm/nouveau/nvkm/subdev/mmu/vmmtu102.c| 1 - 18 files changed, 55 insertions(+), 55 deletions(-) -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] drm/nouveau: Program aperture field where necessary
From: Thierry Reding
Some registers and instance block entries need the aperture to be
programmed correctly. This is important on recent Tegra GPUs where
the GPU actually checks the value of this field and faults if an
invalid aperture is programmed.
For example GV11B no longer supports VRAM and all memory is already
allocated from system (coherent or non-coherent), so make sure to
also program the right aperture.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogk104.c | 7 +--
drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogv100.c | 5 +++--
drivers/gpu/drm/nouveau/nvkm/engine/fifo/gv100.c | 7 ++-
drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c| 3 ++-
4 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogk104.c
b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogk104.c
index 728a1edbf98c..843ebb41dbc6 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogk104.c
@@ -201,6 +201,7 @@ gk104_fifo_gpfifo_fini(struct nvkm_fifo_chan *base)
void
gk104_fifo_gpfifo_init(struct nvkm_fifo_chan *base)
{
+ u32 aperture = nvkm_memory_aperture(base->inst->memory) << 28;
struct gk104_fifo_chan *chan = gk104_fifo_chan(base);
struct gk104_fifo *fifo = chan->fifo;
struct nvkm_device *device = fifo->base.engine.subdev.device;
@@ -208,7 +209,7 @@ gk104_fifo_gpfifo_init(struct nvkm_fifo_chan *base)
u32 coff = chan->base.chid * 8;
nvkm_mask(device, 0x84 + coff, 0x000f, chan->runl << 16);
- nvkm_wr32(device, 0x80 + coff, 0x8000 | addr);
+ nvkm_wr32(device, 0x80 + coff, 0x8000 | aperture | addr);
if (list_empty(>head) && !chan->killed) {
gk104_fifo_runlist_insert(fifo, chan);
@@ -250,6 +251,7 @@ gk104_fifo_gpfifo_new_(struct gk104_fifo *fifo, u64
*runlists, u16 *chid,
unsigned long engm;
u64 subdevs = 0;
u64 usermem;
+ u32 target;
if (!vmm || runlist < 0 || runlist >= fifo->runlist_nr)
return -EINVAL;
@@ -303,10 +305,11 @@ gk104_fifo_gpfifo_new_(struct gk104_fifo *fifo, u64
*runlists, u16 *chid,
nvkm_wo32(fifo->user.mem, usermem + i, 0x);
nvkm_done(fifo->user.mem);
usermem = nvkm_memory_addr(fifo->user.mem) + usermem;
+ target = nvkm_memory_aperture(fifo->user.mem);
/* RAMFC */
nvkm_kmap(chan->base.inst);
- nvkm_wo32(chan->base.inst, 0x08, lower_32_bits(usermem));
+ nvkm_wo32(chan->base.inst, 0x08, lower_32_bits(usermem) | target);
nvkm_wo32(chan->base.inst, 0x0c, upper_32_bits(usermem));
nvkm_wo32(chan->base.inst, 0x10, 0xface);
nvkm_wo32(chan->base.inst, 0x30, 0xf902);
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogv100.c
b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogv100.c
index a7462cf59d65..97d084ffcfd5 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogv100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogv100.c
@@ -132,7 +132,7 @@ gv100_fifo_gpfifo_new_(const struct nvkm_fifo_chan_func
*func,
unsigned long engm;
u64 subdevs = 0;
u64 usermem, mthd;
- u32 size;
+ u32 size, target;
if (!vmm || runlist < 0 || runlist >= fifo->runlist_nr)
return -EINVAL;
@@ -183,6 +183,7 @@ gv100_fifo_gpfifo_new_(const struct nvkm_fifo_chan_func
*func,
nvkm_wo32(fifo->user.mem, usermem + i, 0x);
nvkm_done(fifo->user.mem);
usermem = nvkm_memory_addr(fifo->user.mem) + usermem;
+ target = nvkm_memory_target(fifo->user.mem);
/* Allocate fault method buffer (magics come from nvgpu). */
size = nvkm_rd32(device, 0x104028); /* NV_PCE_PCE_MAP */
@@ -200,7 +201,7 @@ gv100_fifo_gpfifo_new_(const struct nvkm_fifo_chan_func
*func,
/* RAMFC */
nvkm_kmap(chan->base.inst);
- nvkm_wo32(chan->base.inst, 0x008, lower_32_bits(usermem));
+ nvkm_wo32(chan->base.inst, 0x008, lower_32_bits(usermem) | target);
nvkm_wo32(chan->base.inst, 0x00c, upper_32_bits(usermem));
nvkm_wo32(chan->base.inst, 0x010, 0xface);
nvkm_wo32(chan->base.inst, 0x030, 0x7902);
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gv100.c
b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gv100.c
index 6ee1bb32a071..449f669f43b0 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gv100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gv100.c
@@ -32,11 +32,16 @@ void
gv100_fifo_runlist_chan(struct gk104_fifo_chan *chan,
struct nvkm_memory *memory, u32 offset)
{
+ struct nvkm_memory *instmem = chan->base.inst->memory;
struct nvkm_memory *usermem = chan->fifo->user.mem;
const u64 user = nvkm_memory_addr(usermem) + (chan->base.chid * 0x200);
const u64 inst =
[PATCH 5/6] drm/nouveau: Remove unused nvkm_vmm_func->aper() implementations
From: Thierry Reding
These implementations are now all unused. Remove them.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 2 --
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c | 14 --
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk104.c | 2 --
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk20a.c | 2 --
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgm200.c | 2 --
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgm20b.c | 2 --
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 1 -
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp10b.c | 1 -
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgv100.c | 1 -
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmtu102.c | 1 -
10 files changed, 28 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
index 9862f44ac8b5..767870c2d24c 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
@@ -140,7 +140,6 @@ struct nvkm_vmm_func {
int (*join)(struct nvkm_vmm *, struct nvkm_memory *inst);
void (*part)(struct nvkm_vmm *, struct nvkm_memory *inst);
- int (*aper)(enum nvkm_memory_target);
int (*valid)(struct nvkm_vmm *, void *argv, u32 argc,
struct nvkm_vmm_map *);
void (*flush)(struct nvkm_vmm *, int depth);
@@ -206,7 +205,6 @@ int gf100_vmm_new_(const struct nvkm_vmm_func *, const
struct nvkm_vmm_func *,
int gf100_vmm_join_(struct nvkm_vmm *, struct nvkm_memory *, u64 base);
int gf100_vmm_join(struct nvkm_vmm *, struct nvkm_memory *);
void gf100_vmm_part(struct nvkm_vmm *, struct nvkm_memory *);
-int gf100_vmm_aper(enum nvkm_memory_target);
int gf100_vmm_valid(struct nvkm_vmm *, void *, u32, struct nvkm_vmm_map *);
void gf100_vmm_flush(struct nvkm_vmm *, int);
void gf100_vmm_invalidate(struct nvkm_vmm *, u32 type);
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c
index ffa64c0d3eda..ccf5a92d7b54 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c
@@ -318,18 +318,6 @@ gf100_vmm_valid(struct nvkm_vmm *vmm, void *argv, u32 argc,
return 0;
}
-int
-gf100_vmm_aper(enum nvkm_memory_target target)
-{
- switch (target) {
- case NVKM_MEM_TARGET_VRAM: return 0;
- case NVKM_MEM_TARGET_HOST: return 2;
- case NVKM_MEM_TARGET_NCOH: return 3;
- default:
- return -EINVAL;
- }
-}
-
void
gf100_vmm_part(struct nvkm_vmm *vmm, struct nvkm_memory *inst)
{
@@ -370,7 +358,6 @@ static const struct nvkm_vmm_func
gf100_vmm_17 = {
.join = gf100_vmm_join,
.part = gf100_vmm_part,
- .aper = gf100_vmm_aper,
.valid = gf100_vmm_valid,
.flush = gf100_vmm_flush,
.invalidate_pdb = gf100_vmm_invalidate_pdb,
@@ -385,7 +372,6 @@ static const struct nvkm_vmm_func
gf100_vmm_16 = {
.join = gf100_vmm_join,
.part = gf100_vmm_part,
- .aper = gf100_vmm_aper,
.valid = gf100_vmm_valid,
.flush = gf100_vmm_flush,
.invalidate_pdb = gf100_vmm_invalidate_pdb,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk104.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk104.c
index 0b59c01fd146..8efd147fa930 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk104.c
@@ -68,7 +68,6 @@ static const struct nvkm_vmm_func
gk104_vmm_17 = {
.join = gf100_vmm_join,
.part = gf100_vmm_part,
- .aper = gf100_vmm_aper,
.valid = gf100_vmm_valid,
.flush = gf100_vmm_flush,
.invalidate_pdb = gf100_vmm_invalidate_pdb,
@@ -83,7 +82,6 @@ static const struct nvkm_vmm_func
gk104_vmm_16 = {
.join = gf100_vmm_join,
.part = gf100_vmm_part,
- .aper = gf100_vmm_aper,
.valid = gf100_vmm_valid,
.flush = gf100_vmm_flush,
.invalidate_pdb = gf100_vmm_invalidate_pdb,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk20a.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk20a.c
index 999b953505b3..774b6fe9d4a9 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk20a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk20a.c
@@ -45,7 +45,6 @@ static const struct nvkm_vmm_func
gk20a_vmm_17 = {
.join = gf100_vmm_join,
.part = gf100_vmm_part,
- .aper = gf100_vmm_aper,
.valid = gk20a_vmm_valid,
.flush = gf100_vmm_flush,
.invalidate_pdb = gf100_vmm_invalidate_pdb,
@@ -60,7 +59,6 @@ static const struct nvkm_vmm_func
gk20a_vmm_16 = {
.join = gf100_vmm_join,
.part = gf100_vmm_part,
- .aper = gf100_vmm_aper,
.valid = gk20a_vmm_valid,
.flush = gf100_vmm_flush,
.invalidate_pdb = gf100_vmm_invalidate_pdb,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgm200.c
[PATCH 2/6] drm/nouveau: fault: Widen engine field
From: Thierry Reding The engine field in the FIFO fault information registers is actually 9 bits wide. Signed-off-by: Thierry Reding --- drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.c b/drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.c index b5e32295237b..28306c5f6651 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.c @@ -137,8 +137,8 @@ gv100_fault_intr_fault(struct nvkm_fault *fault) info.addr = ((u64)addrhi << 32) | addrlo; info.inst = ((u64)insthi << 32) | (info0 & 0xf000); info.time = 0; - info.engine = (info0 & 0x00ff); info.aperture = (info0 & 0x0c00) >> 10; + info.engine = (info0 & 0x01ff); info.valid = (info1 & 0x8000) >> 31; info.gpc= (info1 & 0x1f00) >> 24; info.hub= (info1 & 0x0010) >> 20; -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/6] drm/nouveau: Implement nvkm_memory_aperture()
From: Thierry Reding
The aperture of a buffer is always specific to where its memory was
allocated from. Furthermore, the encoding of the aperture is always
the same, regardless of GPU generation.
Implement the memory target to aperture conversion in one central
place and make the aperture independent of the VMM.
Note that we no longer return a negative error code for unsupported
apertures. First, this should never happen to begin with and is a
programming error, which is why we have a WARN already. Second, the
standard aperture (0, VRAM) should be correct for the vast majority
of memory objects. Lastly, the aperture also needs to be programmed
into many registers and instance blocks. Having to check for error
codes at every step of the way would make this very unwieldy. If in
any case there is ever a problem with the aperture being wrong, let
us rely on the WARN to tell us about it.
Signed-off-by: Thierry Reding
---
.../drm/nouveau/include/nvkm/core/memory.h| 28 +++
.../drm/nouveau/nvkm/subdev/mmu/vmmgf100.c| 7 ++---
.../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c| 7 ++---
3 files changed, 34 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/core/memory.h
b/drivers/gpu/drm/nouveau/include/nvkm/core/memory.h
index b23bf6109f2d..29c60fbed167 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/core/memory.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/core/memory.h
@@ -64,6 +64,34 @@ void nvkm_memory_tags_put(struct nvkm_memory *, struct
nvkm_device *,
#define nvkm_memory_map(p,o,vm,va,av,ac)
\
(p)->func->map((p),(o),(vm),(va),(av),(ac))
+static inline u32
+nvkm_memory_aperture(struct nvkm_memory *mem)
+{
+ enum nvkm_memory_target target = nvkm_memory_target(mem);
+
+ switch (target) {
+ case NVKM_MEM_TARGET_VRAM:
+ return 0;
+
+ case NVKM_MEM_TARGET_HOST:
+ return 2;
+
+ case NVKM_MEM_TARGET_NCOH:
+ return 3;
+
+ default:
+ break;
+ }
+
+ /*
+* This is invalid, so warn about this loudly. However, return 0 to
+* avoid writing garbage into registers. 0 is the VRAM aperture and
+* might still work in most cases.
+*/
+ WARN(1, "invalid memory target: %d\n", target);
+ return 0;
+}
+
/* accessor macros - kmap()/done() must bracket use of the other accessor
* macros to guarantee correct behaviour across all chipsets
*/
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c
index ab6424faf84c..ffa64c0d3eda 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c
@@ -248,8 +248,9 @@ gf100_vmm_valid(struct nvkm_vmm *vmm, void *argv, u32 argc,
struct nvkm_device *device = vmm->mmu->subdev.device;
struct nvkm_memory *memory = map->memory;
u8 kind, priv, ro, vol;
- int kindn, aper, ret = -ENOSYS;
+ int kindn, ret = -ENOSYS;
const u8 *kindm;
+ u32 aper;
map->next = (1 << page->shift) >> 8;
map->type = map->ctag = 0;
@@ -270,9 +271,7 @@ gf100_vmm_valid(struct nvkm_vmm *vmm, void *argv, u32 argc,
return ret;
}
- aper = vmm->func->aper(target);
- if (WARN_ON(aper < 0))
- return aper;
+ aper = nvkm_memory_aperture(map->memory);
kindm = vmm->mmu->func->kind(vmm->mmu, );
if (kind >= kindn || kindm[kind] == 0xff) {
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c
index b4f519768d5e..4a1a658328e5 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c
@@ -321,8 +321,9 @@ gp100_vmm_valid(struct nvkm_vmm *vmm, void *argv, u32 argc,
struct nvkm_device *device = vmm->mmu->subdev.device;
struct nvkm_memory *memory = map->memory;
u8 kind, priv, ro, vol;
- int kindn, aper, ret = -ENOSYS;
+ int kindn, ret = -ENOSYS;
const u8 *kindm;
+ u32 aper;
map->next = (1ULL << page->shift) >> 4;
map->type = 0;
@@ -343,9 +344,7 @@ gp100_vmm_valid(struct nvkm_vmm *vmm, void *argv, u32 argc,
return ret;
}
- aper = vmm->func->aper(target);
- if (WARN_ON(aper < 0))
- return aper;
+ aper = nvkm_memory_aperture(map->memory);
kindm = vmm->mmu->func->kind(vmm->mmu, );
if (kind >= kindn || kindm[kind] == 0xff) {
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm/nouveau: Remove bogus gk20a aperture callback
From: Thierry Reding
The gk20a (as well as all subsequent Tegra instantiations of the GPU) do
in fact use the same apertures as regular GPUs. Prior to gv11b there are
no checks in hardware for the aperture, so we get away with setting VRAM
as the aperture for buffers that are actually in system memory.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 1 -
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk20a.c | 10 --
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgm20b.c | 4 ++--
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp10b.c | 2 +-
4 files changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
index fb3a9e8bb9cd..9862f44ac8b5 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h
@@ -212,7 +212,6 @@ void gf100_vmm_flush(struct nvkm_vmm *, int);
void gf100_vmm_invalidate(struct nvkm_vmm *, u32 type);
void gf100_vmm_invalidate_pdb(struct nvkm_vmm *, u64 addr);
-int gk20a_vmm_aper(enum nvkm_memory_target);
int gk20a_vmm_valid(struct nvkm_vmm *, void *, u32, struct nvkm_vmm_map *);
int gm200_vmm_new_(const struct nvkm_vmm_func *, const struct nvkm_vmm_func *,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk20a.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk20a.c
index 16d7bf727292..999b953505b3 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk20a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk20a.c
@@ -25,16 +25,6 @@
#include
-int
-gk20a_vmm_aper(enum nvkm_memory_target target)
-{
- switch (target) {
- case NVKM_MEM_TARGET_NCOH: return 0;
- default:
- return -EINVAL;
- }
-}
-
int
gk20a_vmm_valid(struct nvkm_vmm *vmm, void *argv, u32 argc,
struct nvkm_vmm_map *map)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgm20b.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgm20b.c
index 7a6066d886cd..f5d7819c4a40 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgm20b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgm20b.c
@@ -25,7 +25,7 @@ static const struct nvkm_vmm_func
gm20b_vmm_17 = {
.join = gm200_vmm_join,
.part = gf100_vmm_part,
- .aper = gk20a_vmm_aper,
+ .aper = gf100_vmm_aper,
.valid = gk20a_vmm_valid,
.flush = gf100_vmm_flush,
.invalidate_pdb = gf100_vmm_invalidate_pdb,
@@ -41,7 +41,7 @@ static const struct nvkm_vmm_func
gm20b_vmm_16 = {
.join = gm200_vmm_join,
.part = gf100_vmm_part,
- .aper = gk20a_vmm_aper,
+ .aper = gf100_vmm_aper,
.valid = gk20a_vmm_valid,
.flush = gf100_vmm_flush,
.invalidate_pdb = gf100_vmm_invalidate_pdb,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp10b.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp10b.c
index 180c8f006e32..ffe84ea2f7d9 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp10b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp10b.c
@@ -43,7 +43,7 @@ static const struct nvkm_vmm_func
gp10b_vmm = {
.join = gp100_vmm_join,
.part = gf100_vmm_part,
- .aper = gk20a_vmm_aper,
+ .aper = gf100_vmm_aper,
.valid = gp10b_vmm_valid,
.flush = gp100_vmm_flush,
.mthd = gp100_vmm_mthd,
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109628] WARNING at dcn10_hw_sequencer.c:868 dcn10_verify_allow_pstate_change_high()
https://bugs.freedesktop.org/show_bug.cgi?id=109628 --- Comment #19 from peter m --- Created attachment 145377 --> https://bugs.freedesktop.org/attachment.cgi?id=145377=edit kernel 5.2.14-200 dmesg output -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/11] arm64: tegra: Enable GPU on Jetson TX2
From: Alexandre Courbot
Enable the GPU node for the Jetson TX2 board.
Signed-off-by: Alexandre Courbot
Signed-off-by: Thierry Reding
---
arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts
b/arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts
index bdace01561ba..6f7c7c4c5c29 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts
@@ -276,6 +276,10 @@
};
};
+ gpu@1700 {
+ status = "okay";
+ };
+
gpio-keys {
compatible = "gpio-keys";
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/11] arm64: tegra: Enable SMMU for GPU on Tegra186
From: Thierry Reding
The GPU has a connection to the ARM SMMU found on Tegra186, which can be
used to support large pages. Make sure the GPU is attached to the SMMU
to take advantage of its capabilities.
Signed-off-by: Thierry Reding
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 47cd831fcf44..171fd4dfa58d 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -1172,6 +1172,7 @@
status = "disabled";
power-domains = < TEGRA186_POWER_DOMAIN_GPU>;
+ iommus = < TEGRA186_SID_GPU>;
};
sysram@3000 {
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/11] drm/nouveau: tegra: Fall back to 32-bit DMA mask without IOMMU
From: Thierry Reding
The GPU can usually address more than 32-bit, even without being
attached to an IOMMU. However, if the GPU is not attached to an IOMMU,
it's likely that there is no IOMMU in the system, in which case any
buffers allocated by Nouveau will likely end up in a region of memory
that cannot be accessed by host1x.
Signed-off-by: Thierry Reding
---
.../drm/nouveau/nvkm/engine/device/tegra.c| 111 +++---
1 file changed, 70 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
index fc652aaa41c7..221238a2cf53 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
@@ -97,7 +97,7 @@ nvkm_device_tegra_power_down(struct nvkm_device_tegra *tdev)
return 0;
}
-static void
+static int
nvkm_device_tegra_probe_iommu(struct nvkm_device_tegra *tdev)
{
#if IS_ENABLED(CONFIG_IOMMU_API)
@@ -111,47 +111,65 @@ nvkm_device_tegra_probe_iommu(struct nvkm_device_tegra
*tdev)
* IOMMU.
*/
if (iommu_get_domain_for_dev(dev))
- return;
+ return -ENODEV;
if (!tdev->func->iommu_bit)
- return;
+ return -ENODEV;
+
+ if (!iommu_present(_bus_type))
+ return -ENODEV;
mutex_init(>iommu.mutex);
- if (iommu_present(_bus_type)) {
- tdev->iommu.domain = iommu_domain_alloc(_bus_type);
- if (!tdev->iommu.domain)
- goto error;
+ tdev->iommu.domain = iommu_domain_alloc(_bus_type);
+ if (!tdev->iommu.domain)
+ return -ENOMEM;
- /*
-* A IOMMU is only usable if it supports page sizes smaller
-* or equal to the system's PAGE_SIZE, with a preference if
-* both are equal.
-*/
- pgsize_bitmap = tdev->iommu.domain->ops->pgsize_bitmap;
- if (pgsize_bitmap & PAGE_SIZE) {
- tdev->iommu.pgshift = PAGE_SHIFT;
- } else {
- tdev->iommu.pgshift = fls(pgsize_bitmap & ~PAGE_MASK);
- if (tdev->iommu.pgshift == 0) {
- dev_warn(dev, "unsupported IOMMU page size\n");
- goto free_domain;
- }
- tdev->iommu.pgshift -= 1;
+ /*
+* An IOMMU is only usable if it supports page sizes smaller or equal
+* to the system's PAGE_SIZE, with a preference if both are equal.
+*/
+ pgsize_bitmap = tdev->iommu.domain->ops->pgsize_bitmap;
+ if (pgsize_bitmap & PAGE_SIZE) {
+ tdev->iommu.pgshift = PAGE_SHIFT;
+ } else {
+ tdev->iommu.pgshift = fls(pgsize_bitmap & ~PAGE_MASK);
+ if (tdev->iommu.pgshift == 0) {
+ dev_warn(dev, "unsupported IOMMU page size\n");
+ ret = -ENOTSUPP;
+ goto free_domain;
}
- ret = iommu_attach_device(tdev->iommu.domain, dev);
- if (ret)
- goto free_domain;
+ tdev->iommu.pgshift -= 1;
+ }
- ret = nvkm_mm_init(>iommu.mm, 0, 0,
- (1ULL << tdev->func->iommu_bit) >>
- tdev->iommu.pgshift, 1);
- if (ret)
- goto detach_device;
+ ret = iommu_attach_device(tdev->iommu.domain, dev);
+ if (ret) {
+ dev_warn(dev, "failed to attach to IOMMU: %d\n", ret);
+ goto free_domain;
+ }
+
+ ret = nvkm_mm_init(>iommu.mm, 0, 0,
+ (1ULL << tdev->func->iommu_bit) >>
+ tdev->iommu.pgshift, 1);
+ if (ret) {
+ dev_warn(dev, "failed to initialize IOVA space: %d\n", ret);
+ goto detach_device;
+ }
+
+ /*
+* The IOMMU bit defines the upper limit of the GPU-addressable space.
+*/
+ ret = dma_set_mask(dev, DMA_BIT_MASK(tdev->func->iommu_bit));
+ if (ret) {
+ dev_warn(dev, "failed to set DMA mask: %d\n", ret);
+ goto fini_mm;
}
- return;
+ return 0;
+
+fini_mm:
+ nvkm_mm_fini(>iommu.mm);
detach_device:
iommu_detach_device(tdev->iommu.domain, dev);
@@ -159,10 +177,15 @@ nvkm_device_tegra_probe_iommu(struct nvkm_device_tegra
*tdev)
free_domain:
iommu_domain_free(tdev->iommu.domain);
-error:
+ /* reset these so that the DMA API code paths are executed */
tdev->iommu.domain = NULL;
tdev->iommu.pgshift = 0;
- dev_err(dev, "cannot initialize IOMMU MM\n");
+
+ dev_warn(dev, "cannot initialize IOMMU MM\n");
+
+ return ret;
+#else
+ return -ENOTSUPP;
#endif
}
[PATCH 06/11] drm/nouveau: gk20a: Set IOMMU bit for DMA API if appropriate
From: Thierry Reding
Detect if the DMA API is backed by an IOMMU and set the IOMMU bit if so.
This is needed to make sure IOMMU addresses are properly translated even
the explicit IOMMU API is not used.
Signed-off-by: Thierry Reding
---
.../drm/nouveau/nvkm/subdev/instmem/gk20a.c | 35 +--
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
index b0493f8df1fe..1120a2a7d5f1 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
@@ -100,12 +100,14 @@ struct gk20a_instmem {
unsigned int vaddr_max;
struct list_head vaddr_lru;
+ /* IOMMU mapping */
+ unsigned int page_shift;
+ u64 iommu_mask;
+
/* Only used if IOMMU if present */
struct mutex *mm_mutex;
struct nvkm_mm *mm;
struct iommu_domain *domain;
- unsigned long iommu_pgshift;
- u16 iommu_bit;
/* Only used by DMA API */
unsigned long attrs;
@@ -357,12 +359,12 @@ gk20a_instobj_dtor_iommu(struct nvkm_memory *memory)
mutex_unlock(>lock);
/* clear IOMMU bit to unmap pages */
- r->offset &= ~BIT(imem->iommu_bit - imem->iommu_pgshift);
+ r->offset &= ~imem->iommu_mask;
/* Unmap pages from GPU address space and free them */
for (i = 0; i < node->base.mn->length; i++) {
iommu_unmap(imem->domain,
- (r->offset + i) << imem->iommu_pgshift, PAGE_SIZE);
+ (r->offset + i) << imem->page_shift, PAGE_SIZE);
dma_unmap_page(dev, node->dma_addrs[i], PAGE_SIZE,
DMA_BIDIRECTIONAL);
__free_page(node->pages[i]);
@@ -440,7 +442,7 @@ gk20a_instobj_ctor_dma(struct gk20a_instmem *imem, u32
npages, u32 align,
/* present memory for being mapped using small pages */
node->r.type = 12;
- node->r.offset = node->handle >> 12;
+ node->r.offset = imem->iommu_mask | node->handle >> 12;
node->r.length = (npages << PAGE_SHIFT) >> 12;
node->base.mn = >r;
@@ -493,7 +495,7 @@ gk20a_instobj_ctor_iommu(struct gk20a_instmem *imem, u32
npages, u32 align,
mutex_lock(imem->mm_mutex);
/* Reserve area from GPU address space */
ret = nvkm_mm_head(imem->mm, 0, 1, npages, npages,
- align >> imem->iommu_pgshift, );
+ align >> imem->page_shift, );
mutex_unlock(imem->mm_mutex);
if (ret) {
nvkm_error(subdev, "IOMMU space is full!\n");
@@ -502,7 +504,7 @@ gk20a_instobj_ctor_iommu(struct gk20a_instmem *imem, u32
npages, u32 align,
/* Map into GPU address space */
for (i = 0; i < npages; i++) {
- u32 offset = (r->offset + i) << imem->iommu_pgshift;
+ u32 offset = (r->offset + i) << imem->page_shift;
ret = iommu_map(imem->domain, offset, node->dma_addrs[i],
PAGE_SIZE, IOMMU_READ | IOMMU_WRITE);
@@ -518,7 +520,7 @@ gk20a_instobj_ctor_iommu(struct gk20a_instmem *imem, u32
npages, u32 align,
}
/* IOMMU bit tells that an address is to be resolved through the IOMMU
*/
- r->offset |= BIT(imem->iommu_bit - imem->iommu_pgshift);
+ r->offset |= imem->iommu_mask;
node->base.mn = r;
return 0;
@@ -619,11 +621,12 @@ gk20a_instmem_new(struct nvkm_device *device, int index,
imem->mm_mutex = >iommu.mutex;
imem->mm = >iommu.mm;
imem->domain = tdev->iommu.domain;
- imem->iommu_pgshift = tdev->iommu.pgshift;
- imem->iommu_bit = tdev->func->iommu_bit;
+ imem->page_shift = tdev->iommu.pgshift;
nvkm_info(>base.subdev, "using IOMMU\n");
} else {
+ imem->page_shift = PAGE_SHIFT;
+
imem->attrs = DMA_ATTR_NON_CONSISTENT |
DMA_ATTR_WEAK_ORDERING |
DMA_ATTR_WRITE_COMBINE;
@@ -631,5 +634,17 @@ gk20a_instmem_new(struct nvkm_device *device, int index,
nvkm_info(>base.subdev, "using DMA API\n");
}
+ /*
+* The IOMMU mask needs to be set if an IOMMU is used explicitly (via
+* direct IOMMU API usage) or implicitly (via the DMA API). In both
+* cases the device will have been attached to an IOMMU domain.
+*/
+ if (iommu_get_domain_for_dev(device->dev)) {
+ imem->iommu_mask = BIT_ULL(tdev->func->iommu_bit -
+ imem->page_shift);
+ nvkm_debug(>base.subdev, "IOMMU mask: %016llx\n",
+ imem->iommu_mask);
+ }
+
return 0;
}
--
2.23.0
___
dri-devel mailing list
[PATCH 08/11] drm/nouveau: tegra: Skip IOMMU initialization if already attached
From: Thierry Reding
If the GPU is already attached to an IOMMU, don't detach it and setup an
explicit IOMMU domain. Since Nouveau can now properly handle the case of
the DMA API being backed by an IOMMU, just continue using the DMA API.
Signed-off-by: Thierry Reding
---
.../drm/nouveau/nvkm/engine/device/tegra.c| 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
index d0d52c1d4aee..fc652aaa41c7 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
@@ -23,10 +23,6 @@
#ifdef CONFIG_NOUVEAU_PLATFORM_DRIVER
#include "priv.h"
-#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
-#include
-#endif
-
static int
nvkm_device_tegra_power_up(struct nvkm_device_tegra *tdev)
{
@@ -109,14 +105,13 @@ nvkm_device_tegra_probe_iommu(struct nvkm_device_tegra
*tdev)
unsigned long pgsize_bitmap;
int ret;
-#if IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)
- if (dev->archdata.mapping) {
- struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
-
- arm_iommu_detach_device(dev);
- arm_iommu_release_mapping(mapping);
- }
-#endif
+ /*
+* Skip explicit IOMMU initialization if the GPU is already attached
+* to an IOMMU domain. This can happen if the DMA API is backed by an
+* IOMMU.
+*/
+ if (iommu_get_domain_for_dev(dev))
+ return;
if (!tdev->func->iommu_bit)
return;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/11] drm/nouveau: gp10b: Use correct copy engine
From: Thierry Reding
gp10b uses the new engine enumeration mechanism introduced in the Pascal
architecture. As a result, the copy engine, which used to be at index 2
for prior Tegra GPU instantiations, has now moved to index 0. Fix up the
index and also use the gp100 variant of the copy engine class because on
gp10b the PASCAL_DMA_COPY_B class is not supported.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
index d2d6d5f4028a..99d3fa3fad89 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
@@ -2387,7 +2387,7 @@ nv13b_chipset = {
.pmu = gm20b_pmu_new,
.timer = gk20a_timer_new,
.top = gk104_top_new,
- .ce[2] = gp102_ce_new,
+ .ce[0] = gp100_ce_new,
.dma = gf119_dma_new,
.fifo = gp10b_fifo_new,
.gr = gp10b_gr_new,
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/11] drm/nouveau: gp10b: Add custom L2 cache implementation
From: Thierry Reding
There are extra registers that need to be programmed to make the level 2
cache work on GP10B, such as the stream ID register that is used when an
SMMU is used to translate memory addresses.
Signed-off-by: Thierry Reding
---
.../gpu/drm/nouveau/include/nvkm/subdev/ltc.h | 1 +
.../gpu/drm/nouveau/nvkm/engine/device/base.c | 2 +-
.../gpu/drm/nouveau/nvkm/subdev/ltc/Kbuild| 1 +
.../gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c | 69 +++
.../gpu/drm/nouveau/nvkm/subdev/ltc/priv.h| 2 +
5 files changed, 74 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/ltc.h
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/ltc.h
index 644d527c3b96..d76f60d7d29a 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/ltc.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/ltc.h
@@ -40,4 +40,5 @@ int gm107_ltc_new(struct nvkm_device *, int, struct nvkm_ltc
**);
int gm200_ltc_new(struct nvkm_device *, int, struct nvkm_ltc **);
int gp100_ltc_new(struct nvkm_device *, int, struct nvkm_ltc **);
int gp102_ltc_new(struct nvkm_device *, int, struct nvkm_ltc **);
+int gp10b_ltc_new(struct nvkm_device *, int, struct nvkm_ltc **);
#endif
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
index c3c7159f3411..d2d6d5f4028a 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
@@ -2380,7 +2380,7 @@ nv13b_chipset = {
.fuse = gm107_fuse_new,
.ibus = gp10b_ibus_new,
.imem = gk20a_instmem_new,
- .ltc = gp102_ltc_new,
+ .ltc = gp10b_ltc_new,
.mc = gp10b_mc_new,
.mmu = gp10b_mmu_new,
.secboot = gp10b_secboot_new,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/Kbuild
b/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/Kbuild
index 2b6d36ea7067..728d75010847 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/Kbuild
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/Kbuild
@@ -6,3 +6,4 @@ nvkm-y += nvkm/subdev/ltc/gm107.o
nvkm-y += nvkm/subdev/ltc/gm200.o
nvkm-y += nvkm/subdev/ltc/gp100.o
nvkm-y += nvkm/subdev/ltc/gp102.o
+nvkm-y += nvkm/subdev/ltc/gp10b.o
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c
new file mode 100644
index ..4d27c6ea1552
--- /dev/null
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c
@@ -0,0 +1,69 @@
+/*
+ * Copyright (c) 2019 NVIDIA Corporation.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: Thierry Reding
+ */
+
+#include "priv.h"
+
+static void
+gp10b_ltc_init(struct nvkm_ltc *ltc)
+{
+ struct nvkm_device *device = ltc->subdev.device;
+#ifdef CONFIG_IOMMU_API
+ struct iommu_fwspec *spec;
+#endif
+
+ nvkm_wr32(device, 0x17e27c, ltc->ltc_nr);
+ nvkm_wr32(device, 0x17e000, ltc->ltc_nr);
+ nvkm_wr32(device, 0x100800, ltc->ltc_nr);
+
+#ifdef CONFIG_IOMMU_API
+ spec = dev_iommu_fwspec_get(device->dev);
+ if (spec) {
+ u32 sid = spec->ids[0] & 0x;
+
+ /* stream ID */
+ nvkm_wr32(device, 0x16, sid << 2);
+ }
+#endif
+}
+
+static const struct nvkm_ltc_func
+gp10b_ltc = {
+ .oneinit = gp100_ltc_oneinit,
+ .init = gp10b_ltc_init,
+ .intr = gp100_ltc_intr,
+ .cbc_clear = gm107_ltc_cbc_clear,
+ .cbc_wait = gm107_ltc_cbc_wait,
+ .zbc = 16,
+ .zbc_clear_color = gm107_ltc_zbc_clear_color,
+ .zbc_clear_depth = gm107_ltc_zbc_clear_depth,
+ .zbc_clear_stencil = gp102_ltc_zbc_clear_stencil,
+ .invalidate = gf100_ltc_invalidate,
+ .flush = gf100_ltc_flush,
+};
+
+int
+gp10b_ltc_new(struct nvkm_device *device, int index, struct nvkm_ltc **pltc)
+{
+ return nvkm_ltc_new_(_ltc, device, index, pltc);
+}
diff
[PATCH 07/11] drm/nouveau: gk20a: Implement custom MMU class
From: Thierry Reding
The GPU integrated in NVIDIA Tegra SoCs is connected to system memory
via two paths: one direct path to the memory controller and another path
that goes through a system MMU first. It's not typically necessary to go
through the system MMU because the GPU's MMU can already map buffers so
that they appear contiguous to the GPU.
However, in order to support big pages, the system MMU has to be used to
combine multiple small pages into one virtually contiguous chunk so that
the GPU can then treat that as a single big page.
In order to prepare for big page support, implement a custom MMU class
that takes care of setting the IOMMU bit when writing page tables and
when appropriate.
This is also necessary to make sure that Nouveau works correctly on
Tegra devices where the GPU is connected to a system MMU and that IOMMU
is used to back the DMA API. Currently Nouveau assumes that the DMA API
is never backed by an IOMMU, so access to DMA-mapped buffers fault when
suddenly this assumption is no longer true.
One situation where this can happen is on 32-bit Tegra SoCs where the
ARM architecture code automatically attaches the GPU with a DMA/IOMMU
domain. This is currently worked around by detaching the GPU from the
IOMMU domain at probe time. However, with Tegra186 and later this can
now also happen, but unfortunately no mechanism exists to detach from
the domain in the 64-bit ARM architecture code.
Using this Tegra-specific MMU class ensures that DMA-mapped buffers are
properly mapped (with the IOMMU bit set) if the DMA API is backed by an
IOMMU domain.
Signed-off-by: Thierry Reding
---
.../gpu/drm/nouveau/nvkm/subdev/mmu/gk20a.c | 50 ++-
.../gpu/drm/nouveau/nvkm/subdev/mmu/gk20a.h | 44
.../gpu/drm/nouveau/nvkm/subdev/mmu/gm20b.c | 6 ++-
.../gpu/drm/nouveau/nvkm/subdev/mmu/gp10b.c | 4 +-
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 1 +
.../drm/nouveau/nvkm/subdev/mmu/vmmgk20a.c| 22 +++-
.../drm/nouveau/nvkm/subdev/mmu/vmmgm20b.c| 4 +-
.../drm/nouveau/nvkm/subdev/mmu/vmmgp10b.c| 20 +++-
8 files changed, 142 insertions(+), 9 deletions(-)
create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gk20a.h
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gk20a.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gk20a.c
index ac74965a60d4..d9a5e05b7dc7 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gk20a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gk20a.c
@@ -19,11 +19,59 @@
* ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
* OTHER DEALINGS IN THE SOFTWARE.
*/
+
+#include "gk20a.h"
#include "mem.h"
#include "vmm.h"
+#include
#include
+static void
+gk20a_mmu_ctor(const struct nvkm_mmu_func *func, struct nvkm_device *device,
+ int index, struct gk20a_mmu *mmu)
+{
+ struct iommu_domain *domain = iommu_get_domain_for_dev(device->dev);
+ struct nvkm_device_tegra *tegra = device->func->tegra(device);
+
+ nvkm_mmu_ctor(func, device, index, >base);
+
+ /*
+* If the DMA API is backed by an IOMMU, make sure the IOMMU bit is
+* set for all buffer accesses. If the IOMMU is explicitly used, it
+* is only used for instance blocks and the MMU doesn't care, since
+* buffer objects are only mapped through the MMU, not through the
+* IOMMU.
+*
+* Big page support could be implemented using explicit IOMMU usage,
+* but the DMA API already provides that for free, so we don't worry
+* about it for now.
+*/
+ if (domain && !tegra->iommu.domain) {
+ mmu->iommu_mask = BIT_ULL(tegra->func->iommu_bit);
+ nvkm_debug(>base.subdev, "IOMMU mask: %llx\n",
+ mmu->iommu_mask);
+ }
+}
+
+int
+gk20a_mmu_new_(const struct nvkm_mmu_func *func, struct nvkm_device *device,
+ int index, struct nvkm_mmu **pmmu)
+{
+ struct gk20a_mmu *mmu;
+
+ mmu = kzalloc(sizeof(*mmu), GFP_KERNEL);
+ if (!mmu)
+ return -ENOMEM;
+
+ gk20a_mmu_ctor(func, device, index, mmu);
+
+ if (pmmu)
+ *pmmu = >base;
+
+ return 0;
+}
+
static const struct nvkm_mmu_func
gk20a_mmu = {
.dma_bits = 40,
@@ -37,5 +85,5 @@ gk20a_mmu = {
int
gk20a_mmu_new(struct nvkm_device *device, int index, struct nvkm_mmu **pmmu)
{
- return nvkm_mmu_new_(_mmu, device, index, pmmu);
+ return gk20a_mmu_new_(_mmu, device, index, pmmu);
}
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gk20a.h
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gk20a.h
new file mode 100644
index ..bb81fc62509c
--- /dev/null
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gk20a.h
@@ -0,0 +1,44 @@
+/*
+ * Copyright (c) 2019 NVIDIA Corporation.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+
[PATCH 01/11] drm/nouveau: tegra: Avoid pulsing reset twice
From: Thierry Reding
When the GPU powergate is controlled by a generic power domain provider,
the reset will automatically be asserted and deasserted as part of the
power-ungating procedure.
On some Jetson TX2 boards, doing an additional assert and deassert of
the GPU outside of the power-ungate procedure can cause the GPU to go
into a bad state where the memory interface can no longer access system
memory.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
index 0e372a190d3f..747a775121cf 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
@@ -52,18 +52,18 @@ nvkm_device_tegra_power_up(struct nvkm_device_tegra *tdev)
clk_set_rate(tdev->clk_pwr, 20400);
udelay(10);
- reset_control_assert(tdev->rst);
- udelay(10);
-
if (!tdev->pdev->dev.pm_domain) {
+ reset_control_assert(tdev->rst);
+ udelay(10);
+
ret = tegra_powergate_remove_clamping(TEGRA_POWERGATE_3D);
if (ret)
goto err_clamp;
udelay(10);
- }
- reset_control_deassert(tdev->rst);
- udelay(10);
+ reset_control_deassert(tdev->rst);
+ udelay(10);
+ }
return 0;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/11] drm/nouveau: tegra: Set clock rate if not set
From: Thierry Reding
If the GPU clock has not had a rate set, initialize it to the maximum
clock rate to make sure it does run.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
index 747a775121cf..d0d52c1d4aee 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
@@ -279,6 +279,7 @@ nvkm_device_tegra_new(const struct nvkm_device_tegra_func
*func,
struct nvkm_device **pdevice)
{
struct nvkm_device_tegra *tdev;
+ unsigned long rate;
int ret;
if (!(tdev = kzalloc(sizeof(*tdev), GFP_KERNEL)))
@@ -307,6 +308,17 @@ nvkm_device_tegra_new(const struct nvkm_device_tegra_func
*func,
goto free;
}
+ rate = clk_get_rate(tdev->clk);
+ if (rate == 0) {
+ ret = clk_set_rate(tdev->clk, ULONG_MAX);
+ if (ret < 0)
+ goto free;
+
+ rate = clk_get_rate(tdev->clk);
+
+ dev_dbg(>dev, "GPU clock set to %lu\n", rate);
+ }
+
if (func->require_ref_clk)
tdev->clk_ref = devm_clk_get(>dev, "ref");
if (IS_ERR(tdev->clk_ref)) {
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/11] drm/nouveau: Enable GP10B by default
From: Thierry Reding Hi, the GPU on Jetson TX2 (GP10B) does not work properly on all devices. Why exactly is not clear, but there are slight differences between the SKUs that were tested. It turns out that the biggest issue is that on some devices (e.g. the one that I have), pulsing the GPU reset twice as is done in the current code (once as part of the power-ungate operation and then again in the driver) causes the GPU to go into a bad state on some devices. Conditionally doing the reset in the driver only if it isn't already done by the power domain code fixes this issue. Another issue is that the clock may be running at a rate of 0 Hz. This is unlikely to happen because it internally actually can't run that slow, but explicitly setting the clock rate at probe time does seem to help in some cases. Patch three in this series unifies reading the WPR configuration by getting it from GPU register rather than reaching into the memory controller's register space. This is slightly better because it better separates the two drivers and doesn't require an update everytime the memory controller moves to another register aperture. Patch 4 ensures the L2 cache makes memory requests with the proper stream ID, which is required when the GPU is behind an IOMMU. Patch 5 changes the GP10B device initialization to use the correct copy engine. GP10B is a Pascal generation GPU and the way that engines are described changes how the copy engines are enumerated compared to earlier generations. Patches 6 through 9 allow Nouveau to work on Tegra GPUs if the DMA API is backed by an IOMMU. This is different from current assumptions because mappings for all buffers mapped through the DMA API will need to have the special IOMMU bit set in their page tables. Note that this technically makes it possible to support big pages on Tegra because from the GPU's point of view all memory is now contiguous. However, these patches only make sure that buffers are mapped properly and don't try to enable big pages. Also note that mapping through the IOMMU comes at a slight cost, so this may not always be desirable. However, with Tegra186 and later it's currently not possible (from a DMA API point of view) to map only a subset of buffers through the IOMMU, so any such optimization is deferred. Furthermore, the ARM SMMU driver currently enforces the use of the SMMU by default, so there not much of a choice at the moment. Finally patches 10 and 11 enable the GPU on Jetson TX2 and make it use the SMMU. I can pick up patches 10 and 11 into the Tegra tree once the other patches have been merged into Nouveau. Thierry Alexandre Courbot (1): arm64: tegra: Enable GPU on Jetson TX2 Thierry Reding (10): drm/nouveau: tegra: Avoid pulsing reset twice drm/nouveau: tegra: Set clock rate if not set drm/nouveau: secboot: Read WPR configuration from GPU registers drm/nouveau: gp10b: Add custom L2 cache implementation drm/nouveau: gp10b: Use correct copy engine drm/nouveau: gk20a: Set IOMMU bit for DMA API if appropriate drm/nouveau: gk20a: Implement custom MMU class drm/nouveau: tegra: Skip IOMMU initialization if already attached drm/nouveau: tegra: Fall back to 32-bit DMA mask without IOMMU arm64: tegra: Enable SMMU for GPU on Tegra186 .../boot/dts/nvidia/tegra186-p2771-.dts | 4 + arch/arm64/boot/dts/nvidia/tegra186.dtsi | 1 + .../gpu/drm/nouveau/include/nvkm/subdev/ltc.h | 1 + .../gpu/drm/nouveau/nvkm/engine/device/base.c | 4 +- .../drm/nouveau/nvkm/engine/device/tegra.c| 152 +++--- .../drm/nouveau/nvkm/subdev/instmem/gk20a.c | 35 ++-- .../gpu/drm/nouveau/nvkm/subdev/ltc/Kbuild| 1 + .../gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c | 69 .../gpu/drm/nouveau/nvkm/subdev/ltc/priv.h| 2 + .../gpu/drm/nouveau/nvkm/subdev/mmu/gk20a.c | 50 +- .../gpu/drm/nouveau/nvkm/subdev/mmu/gk20a.h | 44 + .../gpu/drm/nouveau/nvkm/subdev/mmu/gm20b.c | 6 +- .../gpu/drm/nouveau/nvkm/subdev/mmu/gp10b.c | 4 +- drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 1 + .../drm/nouveau/nvkm/subdev/mmu/vmmgk20a.c| 22 ++- .../drm/nouveau/nvkm/subdev/mmu/vmmgm20b.c| 4 +- .../drm/nouveau/nvkm/subdev/mmu/vmmgp10b.c| 20 ++- .../drm/nouveau/nvkm/subdev/secboot/gm200.h | 2 +- .../drm/nouveau/nvkm/subdev/secboot/gm20b.c | 81 ++ .../drm/nouveau/nvkm/subdev/secboot/gp10b.c | 4 +- 20 files changed, 394 insertions(+), 113 deletions(-) create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gk20a.h -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/11] drm/nouveau: secboot: Read WPR configuration from GPU registers
From: Thierry Reding
The GPUs found on Tegra SoCs have registers that can be used to read the
WPR configuration. Use these registers instead of reaching into the
memory controller's register space to read the same information.
Signed-off-by: Thierry Reding
---
.../drm/nouveau/nvkm/subdev/secboot/gm200.h | 2 +-
.../drm/nouveau/nvkm/subdev/secboot/gm20b.c | 81 ---
.../drm/nouveau/nvkm/subdev/secboot/gp10b.c | 4 +-
3 files changed, 53 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm200.h
b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm200.h
index 62c5e162099a..280b1448df88 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm200.h
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm200.h
@@ -41,6 +41,6 @@ int gm200_secboot_run_blob(struct nvkm_secboot *, struct
nvkm_gpuobj *,
struct nvkm_falcon *);
/* Tegra-only */
-int gm20b_secboot_tegra_read_wpr(struct gm200_secboot *, u32);
+int gm20b_secboot_tegra_read_wpr(struct gm200_secboot *);
#endif
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c
index df8b919dcf09..f8a543122219 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/secboot/gm20b.c
@@ -23,39 +23,65 @@
#include "acr.h"
#include "gm200.h"
-#define TEGRA210_MC_BASE 0x70019000
-
#ifdef CONFIG_ARCH_TEGRA
-#define MC_SECURITY_CARVEOUT2_CFG0 0xc58
-#define MC_SECURITY_CARVEOUT2_BOM_00xc5c
-#define MC_SECURITY_CARVEOUT2_BOM_HI_0 0xc60
-#define MC_SECURITY_CARVEOUT2_SIZE_128K0xc64
-#define TEGRA_MC_SECURITY_CARVEOUT_CFG_LOCKED (1 << 1)
/**
* gm20b_secboot_tegra_read_wpr() - read the WPR registers on Tegra
*
- * On dGPU, we can manage the WPR region ourselves, but on Tegra the WPR region
- * is reserved from system memory by the bootloader and irreversibly locked.
- * This function reads the address and size of the pre-configured WPR region.
+ * On dGPU, we can manage the WPR region ourselves, but on Tegra this region
+ * is allocated from system memory by the secure firmware. The region is then
+ * marked as a "secure carveout" and irreversibly locked. Furthermore, the WPR
+ * secure carveout is also configured to be sent to the GPU via a dedicated
+ * serial bus between the memory controller and the GPU. The GPU requests this
+ * information upon leaving reset and exposes it through a FIFO register at
+ * offset 0x100cd4.
+ *
+ * The FIFO register's lower 4 bits can be used to set the read index into the
+ * FIFO. After each read of the FIFO register, the read index is incremented.
+ *
+ * Indices 2 and 3 contain the lower and upper addresses of the WPR. These are
+ * stored in units of 256 B. The WPR is inclusive of both addresses.
+ *
+ * Unfortunately, for some reason the WPR info register doesn't contain the
+ * correct values for the secure carveout. It seems like the upper address is
+ * always too small by 128 KiB - 1. Given that the secure carvout size in the
+ * memory controller configuration is specified in units of 128 KiB, it's
+ * possible that the computation of the upper address of the WPR is wrong and
+ * causes this difference.
*/
int
-gm20b_secboot_tegra_read_wpr(struct gm200_secboot *gsb, u32 mc_base)
+gm20b_secboot_tegra_read_wpr(struct gm200_secboot *gsb)
{
+ struct nvkm_device *device = gsb->base.subdev.device;
struct nvkm_secboot *sb = >base;
- void __iomem *mc;
- u32 cfg;
+ u64 base, limit;
+ u32 value;
- mc = ioremap(mc_base, 0xd00);
- if (!mc) {
- nvkm_error(>subdev, "Cannot map Tegra MC registers\n");
- return -ENOMEM;
- }
- sb->wpr_addr = ioread32_native(mc + MC_SECURITY_CARVEOUT2_BOM_0) |
- ((u64)ioread32_native(mc + MC_SECURITY_CARVEOUT2_BOM_HI_0) << 32);
- sb->wpr_size = ioread32_native(mc + MC_SECURITY_CARVEOUT2_SIZE_128K)
- << 17;
- cfg = ioread32_native(mc + MC_SECURITY_CARVEOUT2_CFG0);
- iounmap(mc);
+ /* set WPR info register to point at WPR base address register */
+ value = nvkm_rd32(device, 0x100cd4);
+ value &= ~0xf;
+ value |= 0x2;
+ nvkm_wr32(device, 0x100cd4, value);
+
+ /* read base address */
+ value = nvkm_rd32(device, 0x100cd4);
+ base = (u64)(value >> 4) << 12;
+
+ /* read limit */
+ value = nvkm_rd32(device, 0x100cd4);
+ limit = (u64)(value >> 4) << 12;
+
+ /*
+* The upper address of the WPR seems to be computed wrongly and is
+* actually SZ_128K - 1 bytes lower than it should be. Adjust the
+* value accordingly.
+*/
+ limit += SZ_128K - 1;
+
+ sb->wpr_size = limit - base + 1;
+ sb->wpr_addr = base;
+
+ nvkm_info(>subdev, "WPR: %016llx-%016llx\n", sb->wpr_addr,
+
[Bug 202445] amdgpu/dc: framerate dropping below adaptive sync range causes screen flickering
https://bugzilla.kernel.org/show_bug.cgi?id=202445 --- Comment #36 from Clément Guérin (li...@protonmail.com) --- If you haven't updated to linux 5.2 yet, you should because it fixed constant flickering when in LFC mode. This additional patch helps when the monitor goes in and out of LFC mode. It's not fully fixed, but the flickering is a lot less severe. According to the Phoronix article it should indeed land in linux 5.5. When compiling a kernel you should be able to install it next to the regular one so you can't break your setup. I personally used the linux-mainline package from AUR and added the LFC patch on top. Original Message On Sep 16, 2019, 06:22, wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=202445 > > --- Comment #34 from jaapbuur...@gmail.com --- > How big is the improvement? Is the issue completely gone, or is it still > there? > The KSP example also reliably triggers the flickering for me, and I am using > the exact same monitor. > > These LFC patches are going to be included in the 5.5 kernel, right? Or will > they be included in an earlier kernel version? > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202445] amdgpu/dc: framerate dropping below adaptive sync range causes screen flickering
https://bugzilla.kernel.org/show_bug.cgi?id=202445 --- Comment #35 from Clément Guérin (li...@protonmail.com) --- If you haven't updated to linux 5.2 yet, you should because it fixed constant flickering when in LFC mode. This additional patch helps when freesync goes in and out of LFC mode. It's not fully fixed, but the flickering is a lot less severe. According to the Phoronix article it should indeed land in linux 5.5. When compiling a kernel you should be able to install it next to the regular one so you can't break your setup. I personally used the linux-mainline package from the AUR and added the LFC patch on top. -- 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: blocking ops in drm_sched_cleanup_jobs()
Am 16.09.19 um 16:24 schrieb Daniel Vetter:
> On Mon, Sep 16, 2019 at 10:11 AM Koenig, Christian
> wrote:
>> Hi Steven,
>>
>> the problem seems to be than panfrost is trying to sleep while freeing a
>> job. E.g. it tries to take a mutex.
>>
>> That is not allowed any more since we need to free the jobs from atomic
>> and even interrupt context.
>>
>> Your suggestion wouldn't work because this way jobs are not freed when
>> there isn't a new one to be scheduled.
> One fix would be to make sure that any that any calls to
> drm_sched_cleanup_jobs are atomic, by putting preempt_disable/enable
> or local_irq_disable/enable in there, at least when lockdep or sleep
> debugging is enabled. That should help catch these reliable, instead
> of just once every blue moon.
Yeah, thought about that as well. But I would also prefer a solution
where drm_sched_cleanup_jobs() is never called in an atomic context.
The problem is that I don't see how that can be possible without
delaying freeing of jobs.
Regards,
Christian.
> -Daniel
>
>> Regards,
>> Christian.
>>
>> Am 13.09.19 um 16:50 schrieb Steven Price:
>>> Hi,
>>>
>>> I hit the below splat randomly with panfrost. From what I can tell this
>>> is a more general issue which would affect other drivers.
>>>
>>> 8<-
>>> [58604.913130] [ cut here ]
>>> [58604.918590] WARNING: CPU: 1 PID: 1758 at kernel/sched/core.c:6556
>>> __might_sleep+0x74/0x98
>>> [58604.927965] do not call blocking ops when !TASK_RUNNING; state=1 set at
>>> [<0c590494>] prepare_to_wait_event+0x104/0x164
>>> [58604.940047] Modules linked in: panfrost gpu_sched
>>> [58604.945370] CPU: 1 PID: 1758 Comm: pan_js Not tainted 5.3.0-rc1+ #13
>>> [58604.952500] Hardware name: Rockchip (Device Tree)
>>> [58604.957815] [] (unwind_backtrace) from []
>>> (show_stack+0x10/0x14)
>>> [58604.966521] [] (show_stack) from []
>>> (dump_stack+0x9c/0xd4)
>>> [58604.974639] [] (dump_stack) from []
>>> (__warn+0xe8/0x104)
>>> [58604.982462] [] (__warn) from []
>>> (warn_slowpath_fmt+0x44/0x6c)
>>> [58604.990867] [] (warn_slowpath_fmt) from []
>>> (__might_sleep+0x74/0x98)
>>> [58604.73] [] (__might_sleep) from []
>>> (__mutex_lock+0x38/0x948)
>>> [58605.008690] [] (__mutex_lock) from []
>>> (mutex_lock_nested+0x18/0x20)
>>> [58605.017841] [] (mutex_lock_nested) from []
>>> (panfrost_gem_free_object+0x60/0x10c [panfrost])
>>> [58605.029430] [] (panfrost_gem_free_object [panfrost]) from
>>> [] (panfrost_job_put+0x138/0x150 [panfrost])
>>> [58605.042076] [] (panfrost_job_put [panfrost]) from []
>>> (drm_sched_cleanup_jobs+0xc8/0xe0 [gpu_sched])
>>> [58605.054417] [] (drm_sched_cleanup_jobs [gpu_sched]) from
>>> [] (drm_sched_main+0xcc/0x26c [gpu_sched])
>>> [58605.066620] [] (drm_sched_main [gpu_sched]) from []
>>> (kthread+0x13c/0x154)
>>> [58605.076226] [] (kthread) from []
>>> (ret_from_fork+0x14/0x20)
>>> [58605.084346] Exception stack(0xe959bfb0 to 0xe959bff8)
>>> [58605.090046] bfa0:
>>>
>>> [58605.099250] bfc0:
>>>
>>> [58605.108480] bfe0: 0013
>>> [58605.116210] irq event stamp: 179
>>> [58605.119955] hardirqs last enabled at (187): []
>>> console_unlock+0x564/0x5c4
>>> [58605.128935] hardirqs last disabled at (202): []
>>> console_unlock+0x88/0x5c4
>>> [58605.137788] softirqs last enabled at (216): []
>>> __do_softirq+0x18c/0x548
>>> [58605.146543] softirqs last disabled at (227): []
>>> irq_exit+0xc4/0x10c
>>> [58605.154618] ---[ end trace f65bdbd9ea9adfc0 ]---
>>> 8<-
>>>
>>> The problem is that drm_sched_main() calls drm_sched_cleanup_jobs() as
>>> part of the condition of wait_event_interruptible:
>>>
wait_event_interruptible(sched->wake_up_worker,
(drm_sched_cleanup_jobs(sched),
(!drm_sched_blocked(sched) &&
(entity =
drm_sched_select_entity(sched))) ||
kthread_should_stop()));
>>> When drm_sched_cleanup_jobs() is called *after* a wait (i.e. after
>>> prepare_to_wait_event() has been called), then any might_sleep() will
>>> moan loudly about it. This doesn't seem to happen often (I've only
>>> triggered it once) because usually drm_sched_cleanup_jobs() either
>>> doesn't sleep or does the sleeping during the first call that
>>> wait_event_interruptible() makes (which is before the task state is set).
>>>
>>> I don't really understand why drm_sched_cleanup_jobs() needs to be
>>> called here, a simple change like below 'fixes' it. But I presume
>>> there's some reason for the call being part of the
>>> wait_event_interruptible condition. Can anyone shed light on this?
>>>
>>> The code was introduced in commit 5918045c4ed4 ("drm/scheduler: rework job
>>>
[PATCH 0/2] drm/nouveau: Two more fixes
From: Thierry Reding Hi Ben, I messed up the ordering of patches in my tree a bit, so these two fixes got separated from the others. I don't consider these particularily urgent because the crash that the first one fixes only happens on gp10b which we don't enable by default yet and the second patch fixes a crash that only happens on module unload (or driver unbind, more accurately), which isn't a terribly common thing to do. I'll be sending out fixes shortly to make the GP10B work more properly on a wider range of Jetson TX2 devices and enable it by default. One thing to mention is that I'm not exactly sure if the first patch is the right thing to do. I haven't seen any issues after that change, but I'm also not exactly sure I understand what BAR2 is used for, so I don't know if I would've even covered those code paths (other than the one causing the crash at probe time) in my tests. It'd be great to get Lyude's feedback on the second patch, since that call to pci_disable_device() was rather oddly placed and I'm not sure if that was essential for things to work or whether the slightly different point in time where it's called after this patch is also okay. It looks to me like it should work fine, but I don't currently have a way to test this on desktop GPUs. Thierry Thierry Reding (2): drm/nouveau: tegra: Fix NULL pointer dereference drm/nouveau: tegra: Do not try to disable PCI device drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +- .../drm/nouveau/nvkm/subdev/instmem/gk20a.c | 30 +++ 2 files changed, 31 insertions(+), 2 deletions(-) -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/nouveau: tegra: Fix NULL pointer dereference
From: Thierry Reding
Fill in BAR2 callbacks for instance memory. There's no BAR2 on Tegra
GPUs, but buffers are all in system memory anyway, so just return the
plain address.
Signed-off-by: Thierry Reding
---
.../drm/nouveau/nvkm/subdev/instmem/gk20a.c | 30 +++
1 file changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
index 985f2990ab0d..b0493f8df1fe 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
@@ -261,6 +261,34 @@ gk20a_instobj_release_iommu(struct nvkm_memory *memory)
nvkm_ltc_invalidate(ltc);
}
+static u64
+gk20a_instobj_bar2_dma(struct nvkm_memory *memory)
+{
+ struct gk20a_instobj_dma *iobj = gk20a_instobj_dma(memory);
+ u64 addr = ~0ULL;
+
+ if (gk20a_instobj_acquire_dma(>base.memory))
+ addr = gk20a_instobj_addr(>base.memory);
+
+ gk20a_instobj_release_dma(>base.memory);
+
+ return addr;
+}
+
+static u64
+gk20a_instobj_bar2_iommu(struct nvkm_memory *memory)
+{
+ struct gk20a_instobj_iommu *iobj = gk20a_instobj_iommu(memory);
+ u64 addr = ~0ULL;
+
+ if (gk20a_instobj_acquire_iommu(>base.memory))
+ addr = gk20a_instobj_addr(>base.memory);
+
+ gk20a_instobj_release_iommu(>base.memory);
+
+ return addr;
+}
+
static u32
gk20a_instobj_rd32(struct nvkm_memory *memory, u64 offset)
{
@@ -353,6 +381,7 @@ static const struct nvkm_memory_func
gk20a_instobj_func_dma = {
.dtor = gk20a_instobj_dtor_dma,
.target = gk20a_instobj_target,
+ .bar2 = gk20a_instobj_bar2_dma,
.page = gk20a_instobj_page,
.addr = gk20a_instobj_addr,
.size = gk20a_instobj_size,
@@ -365,6 +394,7 @@ static const struct nvkm_memory_func
gk20a_instobj_func_iommu = {
.dtor = gk20a_instobj_dtor_iommu,
.target = gk20a_instobj_target,
+ .bar2 = gk20a_instobj_bar2_iommu,
.page = gk20a_instobj_page,
.addr = gk20a_instobj_addr,
.size = gk20a_instobj_size,
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/nouveau: tegra: Do not try to disable PCI device
From: Thierry Reding
When Nouveau is instantiated on top of a platform device, the dev->pdev
field will be NULL and calling pci_disable_device() will crash. Move the
PCI disabling code to the PCI specific driver removal code.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 2cd83849600f..b65ae817eabf 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -715,7 +715,6 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
void
nouveau_drm_device_remove(struct drm_device *dev)
{
- struct pci_dev *pdev = dev->pdev;
struct nouveau_drm *drm = nouveau_drm(dev);
struct nvkm_client *client;
struct nvkm_device *device;
@@ -727,7 +726,6 @@ nouveau_drm_device_remove(struct drm_device *dev)
device = nvkm_device_find(client->device);
nouveau_drm_device_fini(dev);
- pci_disable_device(pdev);
drm_dev_put(dev);
nvkm_device_del();
}
@@ -738,6 +736,7 @@ nouveau_drm_remove(struct pci_dev *pdev)
struct drm_device *dev = pci_get_drvdata(pdev);
nouveau_drm_device_remove(dev);
+ pci_disable_device(pdev);
}
static int
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] dts: arm64: imx8mq: Enable gpu passive throttling
On Mi, 2019-09-11 at 19:40 -0700, Guido Günther wrote:
> Temperature and hysteresis were picked after the CPU.
>
> Signed-off-by: Guido Günther
Reviewed-by: Lucas Stach
> ---
> arch/arm64/boot/dts/freescale/imx8mq.dtsi | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> index 4fdd60f2c51e..5023a0e5068d 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> @@ -235,12 +235,26 @@
> thermal-sensors = < 1>;
>
> trips {
> + gpu_alert: gpu-alert {
> + temperature = <8>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> gpu-crit {
> temperature = <9>;
> hysteresis = <2000>;
> type = "critical";
> };
> };
> +
> + cooling-maps {
> + map0 {
> + trip = <_alert>;
> + cooling-device =
> + < THERMAL_NO_LIMIT
> THERMAL_NO_LIMIT>;
> + };
> + };
> };
>
> vpu-thermal {
> @@ -912,6 +926,7 @@
>< IMX8MQ_CLK_GPU_AXI>,
>< IMX8MQ_CLK_GPU_AHB>;
> clock-names = "core", "shader", "bus", "reg";
> + #cooling-cells = <2>;
> assigned-clocks = < IMX8MQ_CLK_GPU_CORE_SRC>,
> < IMX8MQ_CLK_GPU_SHADER_SRC>,
> < IMX8MQ_CLK_GPU_AXI>,
Re: [PATCH v2 2/2] dt-bindings: etnaviv: Add #cooling-cells
On Mi, 2019-09-11 at 19:40 -0700, Guido Günther wrote: > Add #cooling-cells for when the gpu acts as a cooling device. > > Signed-off-by: Guido Günther Reviewed-by: Lucas Stach > --- > .../devicetree/bindings/display/etnaviv/etnaviv-drm.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git > a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt > b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt > index 8def11b16a24..640592e8ab2e 100644 > --- a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt > +++ b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt > @@ -21,6 +21,7 @@ Required properties: > Optional properties: > - power-domains: a power domain consumer specifier according to >Documentation/devicetree/bindings/power/power_domain.txt > +- #cooling-cells: : If used as a cooling device, must be <2> > > example: >
Re: blocking ops in drm_sched_cleanup_jobs()
On Mon, Sep 16, 2019 at 10:11 AM Koenig, Christian
wrote:
>
> Hi Steven,
>
> the problem seems to be than panfrost is trying to sleep while freeing a
> job. E.g. it tries to take a mutex.
>
> That is not allowed any more since we need to free the jobs from atomic
> and even interrupt context.
>
> Your suggestion wouldn't work because this way jobs are not freed when
> there isn't a new one to be scheduled.
One fix would be to make sure that any that any calls to
drm_sched_cleanup_jobs are atomic, by putting preempt_disable/enable
or local_irq_disable/enable in there, at least when lockdep or sleep
debugging is enabled. That should help catch these reliable, instead
of just once every blue moon.
-Daniel
>
> Regards,
> Christian.
>
> Am 13.09.19 um 16:50 schrieb Steven Price:
> > Hi,
> >
> > I hit the below splat randomly with panfrost. From what I can tell this
> > is a more general issue which would affect other drivers.
> >
> > 8<-
> > [58604.913130] [ cut here ]
> > [58604.918590] WARNING: CPU: 1 PID: 1758 at kernel/sched/core.c:6556
> > __might_sleep+0x74/0x98
> > [58604.927965] do not call blocking ops when !TASK_RUNNING; state=1 set at
> > [<0c590494>] prepare_to_wait_event+0x104/0x164
> > [58604.940047] Modules linked in: panfrost gpu_sched
> > [58604.945370] CPU: 1 PID: 1758 Comm: pan_js Not tainted 5.3.0-rc1+ #13
> > [58604.952500] Hardware name: Rockchip (Device Tree)
> > [58604.957815] [] (unwind_backtrace) from []
> > (show_stack+0x10/0x14)
> > [58604.966521] [] (show_stack) from []
> > (dump_stack+0x9c/0xd4)
> > [58604.974639] [] (dump_stack) from []
> > (__warn+0xe8/0x104)
> > [58604.982462] [] (__warn) from []
> > (warn_slowpath_fmt+0x44/0x6c)
> > [58604.990867] [] (warn_slowpath_fmt) from []
> > (__might_sleep+0x74/0x98)
> > [58604.73] [] (__might_sleep) from []
> > (__mutex_lock+0x38/0x948)
> > [58605.008690] [] (__mutex_lock) from []
> > (mutex_lock_nested+0x18/0x20)
> > [58605.017841] [] (mutex_lock_nested) from []
> > (panfrost_gem_free_object+0x60/0x10c [panfrost])
> > [58605.029430] [] (panfrost_gem_free_object [panfrost]) from
> > [] (panfrost_job_put+0x138/0x150 [panfrost])
> > [58605.042076] [] (panfrost_job_put [panfrost]) from []
> > (drm_sched_cleanup_jobs+0xc8/0xe0 [gpu_sched])
> > [58605.054417] [] (drm_sched_cleanup_jobs [gpu_sched]) from
> > [] (drm_sched_main+0xcc/0x26c [gpu_sched])
> > [58605.066620] [] (drm_sched_main [gpu_sched]) from []
> > (kthread+0x13c/0x154)
> > [58605.076226] [] (kthread) from []
> > (ret_from_fork+0x14/0x20)
> > [58605.084346] Exception stack(0xe959bfb0 to 0xe959bff8)
> > [58605.090046] bfa0:
> >
> > [58605.099250] bfc0:
> >
> > [58605.108480] bfe0: 0013
> > [58605.116210] irq event stamp: 179
> > [58605.119955] hardirqs last enabled at (187): []
> > console_unlock+0x564/0x5c4
> > [58605.128935] hardirqs last disabled at (202): []
> > console_unlock+0x88/0x5c4
> > [58605.137788] softirqs last enabled at (216): []
> > __do_softirq+0x18c/0x548
> > [58605.146543] softirqs last disabled at (227): []
> > irq_exit+0xc4/0x10c
> > [58605.154618] ---[ end trace f65bdbd9ea9adfc0 ]---
> > 8<-
> >
> > The problem is that drm_sched_main() calls drm_sched_cleanup_jobs() as
> > part of the condition of wait_event_interruptible:
> >
> >> wait_event_interruptible(sched->wake_up_worker,
> >> (drm_sched_cleanup_jobs(sched),
> >> (!drm_sched_blocked(sched) &&
> >>(entity =
> >> drm_sched_select_entity(sched))) ||
> >> kthread_should_stop()));
> > When drm_sched_cleanup_jobs() is called *after* a wait (i.e. after
> > prepare_to_wait_event() has been called), then any might_sleep() will
> > moan loudly about it. This doesn't seem to happen often (I've only
> > triggered it once) because usually drm_sched_cleanup_jobs() either
> > doesn't sleep or does the sleeping during the first call that
> > wait_event_interruptible() makes (which is before the task state is set).
> >
> > I don't really understand why drm_sched_cleanup_jobs() needs to be
> > called here, a simple change like below 'fixes' it. But I presume
> > there's some reason for the call being part of the
> > wait_event_interruptible condition. Can anyone shed light on this?
> >
> > The code was introduced in commit 5918045c4ed4 ("drm/scheduler: rework job
> > destruction")
> >
> > Steve
> >
> > 8<-
> > diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> > b/drivers/gpu/drm/scheduler/sched_main.c
> > index 9a0ee74d82dc..528f295e3a31 100644
> > --- a/drivers/gpu/drm/scheduler/sched_main.c
> > +++ b/drivers/gpu/drm/scheduler/sched_main.c
> > @@ -699,11 +699,12 @@ static int
[PATCH 0/4] drm/nouveau: Miscellaneous fixes
From: Thierry Reding Hi Ben, these are fixes for a couple of issues that I've been running into when testing on various Tegra boards. The first two patches fix up issues in the fix that I had sent out earlier to fix the regression introduced in drm-misc-next. The first one is critical because it avoids a BUG_ON as reported by Ilia, while the second is less critical, but restores the locking correctness (at least to the best of my knowledge). Patch 3 is something that I think was also caused by the reservation object rework and is kind of a continuation of my earlier attempt to fix the VMA node sharing breakage. The current ordering between TTM and GEM teardown is causing a DEBUG_LOCKS_WARN_ON() because GEM cleanup already freed a mutex that TTM teardown will still want to use. Lastly, patch 4 is quite uncritical, but it's a one-line change that is causing an ugly (but harmless) external memory address decode error on Tegra210 and later. It seems that for some reason clearing this register will cause a DMA operation to be started by the GPU. I've verified that it's tied to exactly that register write by modifying the value written to the register, and stalling for a couple of seconds after the register write. The address decode error reflects the value written into this register exactly and it always happens a couple of milliseconds after this write. Thierry Thierry Reding (4): drm/nouveau: Fix fallout from reservation object rework drm/nouveau: prime: Extend DMA reservation object lock drm/nouveau: Fix ordering between TTM and GEM release drm/nouveau: gm20b: Avoid BAR1 teardown during init drivers/gpu/drm/nouveau/nouveau_bo.c | 26 +++--- drivers/gpu/drm/nouveau/nouveau_bo.h | 4 +-- drivers/gpu/drm/nouveau/nouveau_gem.c | 7 ++--- drivers/gpu/drm/nouveau/nouveau_prime.c | 27 --- .../gpu/drm/nouveau/nvkm/subdev/bar/gm20b.c | 1 - 5 files changed, 39 insertions(+), 26 deletions(-) -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/nouveau: gm20b: Avoid BAR1 teardown during init
From: Thierry Reding
Writing the 0x1704 (BUS_BAR1_BLOCK) register causes the GPU to probe the
memory region at the programmed address. The result is an address decode
error in the external memory controller because address 0, which is what
is written to the register, is not designated as accessible to devices.
Avoid triggering DMA from the GPU by removing teardown of the BAR1.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nvkm/subdev/bar/gm20b.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gm20b.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gm20b.c
index 950bff1955ad..1ed6170891c4 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gm20b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bar/gm20b.c
@@ -26,7 +26,6 @@ gm20b_bar_func = {
.dtor = gf100_bar_dtor,
.oneinit = gf100_bar_oneinit,
.bar1.init = gf100_bar_bar1_init,
- .bar1.fini = gf100_bar_bar1_fini,
.bar1.wait = gm107_bar_bar1_wait,
.bar1.vmm = gf100_bar_bar1_vmm,
.flush = g84_bar_flush,
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/nouveau: Fix ordering between TTM and GEM release
From: Thierry Reding
When the last reference to a TTM BO is dropped, ttm_bo_release() will
acquire the DMA reservation object's wound/wait mutex while trying to
clean up (ttm_bo_cleanup_refs_or_queue() via ttm_bo_release()). It is
therefore essential that drm_gem_object_release() be called after the
TTM BO has been uninitialized, otherwise drm_gem_object_release() has
already destroyed the wound/wait mutex (via dma_resv_fini()).
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 10 --
drivers/gpu/drm/nouveau/nouveau_gem.c | 4
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index e7803dca32c5..f8015e0318d7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -136,10 +136,16 @@ nouveau_bo_del_ttm(struct ttm_buffer_object *bo)
struct drm_device *dev = drm->dev;
struct nouveau_bo *nvbo = nouveau_bo(bo);
- if (unlikely(nvbo->bo.base.filp))
- DRM_ERROR("bo %p still attached to GEM object\n", bo);
WARN_ON(nvbo->pin_refcnt > 0);
nv10_bo_put_tile_region(dev, nvbo->tile, NULL);
+
+ /*
+* If nouveau_bo_new() allocated this buffer, the GEM object was never
+* initialized, so don't attempt to release it.
+*/
+ if (bo->base.dev)
+ drm_gem_object_release(>base);
+
kfree(nvbo);
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 1bdffd714456..1324c19f4e5c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -51,10 +51,6 @@ nouveau_gem_object_del(struct drm_gem_object *gem)
if (gem->import_attach)
drm_prime_gem_destroy(gem, nvbo->bo.sg);
- drm_gem_object_release(gem);
-
- /* reset filp so nouveau_bo_del_ttm() can test for it */
- gem->filp = NULL;
ttm_bo_put(>bo);
pm_runtime_mark_last_busy(dev);
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/nouveau: Fix fallout from reservation object rework
From: Thierry Reding
Commit 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM
object") introduced a subtle change in how the buffer allocation size is
handled. Prior to that change, the size would get aligned to at least a
page, whereas after that change a non-page-aligned size would get passed
through unmodified. This ultimately causes a BUG_ON() to trigger in
drm_gem_private_object_init() and crashes the system.
Fix this by restoring the code that align the allocation size.
Fixes: 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM object")
Reported-by: Ilia Mirkin
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nouveau_bo.c| 16 +---
drivers/gpu/drm/nouveau/nouveau_bo.h| 4 ++--
drivers/gpu/drm/nouveau/nouveau_gem.c | 3 ++-
drivers/gpu/drm/nouveau/nouveau_prime.c | 7 ---
4 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index e918b437af17..e7803dca32c5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -186,8 +186,8 @@ nouveau_bo_fixup_align(struct nouveau_bo *nvbo, u32 flags,
}
struct nouveau_bo *
-nouveau_bo_alloc(struct nouveau_cli *cli, u64 size, u32 flags, u32 tile_mode,
-u32 tile_flags)
+nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int *align, u32 flags,
+u32 tile_mode, u32 tile_flags)
{
struct nouveau_drm *drm = cli->drm;
struct nouveau_bo *nvbo;
@@ -195,8 +195,8 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 size, u32
flags, u32 tile_mode,
struct nvif_vmm *vmm = cli->svm.cli ? >svm.vmm : >vmm.vmm;
int i, pi = -1;
- if (!size) {
- NV_WARN(drm, "skipped size %016llx\n", size);
+ if (!*size) {
+ NV_WARN(drm, "skipped size %016llx\n", *size);
return ERR_PTR(-EINVAL);
}
@@ -266,7 +266,7 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 size, u32
flags, u32 tile_mode,
pi = i;
/* Stop once the buffer is larger than the current page size. */
- if (size >= 1ULL << vmm->page[i].shift)
+ if (*size >= 1ULL << vmm->page[i].shift)
break;
}
@@ -281,6 +281,8 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 size, u32
flags, u32 tile_mode,
}
nvbo->page = vmm->page[pi].shift;
+ nouveau_bo_fixup_align(nvbo, flags, align, size);
+
return nvbo;
}
@@ -294,7 +296,6 @@ nouveau_bo_init(struct nouveau_bo *nvbo, u64 size, int
align, u32 flags,
acc_size = ttm_bo_dma_acc_size(nvbo->bo.bdev, size, sizeof(*nvbo));
- nouveau_bo_fixup_align(nvbo, flags, , );
nvbo->bo.mem.num_pages = size >> PAGE_SHIFT;
nouveau_bo_placement_set(nvbo, flags, 0);
@@ -318,7 +319,8 @@ nouveau_bo_new(struct nouveau_cli *cli, u64 size, int align,
struct nouveau_bo *nvbo;
int ret;
- nvbo = nouveau_bo_alloc(cli, size, flags, tile_mode, tile_flags);
+ nvbo = nouveau_bo_alloc(cli, , , flags, tile_mode,
+ tile_flags);
if (IS_ERR(nvbo))
return PTR_ERR(nvbo);
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h
b/drivers/gpu/drm/nouveau/nouveau_bo.h
index 62930d834fba..38f9d8350963 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.h
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.h
@@ -71,8 +71,8 @@ nouveau_bo_ref(struct nouveau_bo *ref, struct nouveau_bo
**pnvbo)
extern struct ttm_bo_driver nouveau_bo_driver;
void nouveau_bo_move_init(struct nouveau_drm *);
-struct nouveau_bo *nouveau_bo_alloc(struct nouveau_cli *, u64 size, u32 flags,
- u32 tile_mode, u32 tile_flags);
+struct nouveau_bo *nouveau_bo_alloc(struct nouveau_cli *, u64 *size, int
*align,
+ u32 flags, u32 tile_mode, u32 tile_flags);
int nouveau_bo_init(struct nouveau_bo *, u64 size, int align, u32 flags,
struct sg_table *sg, struct dma_resv *robj);
int nouveau_bo_new(struct nouveau_cli *, u64 size, int align, u32 flags,
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index c2bfc0591909..1bdffd714456 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -188,7 +188,8 @@ nouveau_gem_new(struct nouveau_cli *cli, u64 size, int
align, uint32_t domain,
if (domain & NOUVEAU_GEM_DOMAIN_COHERENT)
flags |= TTM_PL_FLAG_UNCACHED;
- nvbo = nouveau_bo_alloc(cli, size, flags, tile_mode, tile_flags);
+ nvbo = nouveau_bo_alloc(cli, , , flags, tile_mode,
+ tile_flags);
if (IS_ERR(nvbo))
return PTR_ERR(nvbo);
diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c
b/drivers/gpu/drm/nouveau/nouveau_prime.c
index 84658d434225..656c334ee7d9 100644
[PATCH 2/4] drm/nouveau: prime: Extend DMA reservation object lock
From: Thierry Reding
Prior to commit 019cbd4a4feb ("drm/nouveau: Initialize GEM object before
TTM object"), the reservation object was locked across all of the buffer
object creation.
After splitting nouveau_bo_new() into separate nouveau_bo_alloc() and
nouveau_bo_init() functions, the reservation object is passed to the
latter, so the lock needs to be held across that function as well.
Fixes: 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM object")
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nouveau_prime.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c
b/drivers/gpu/drm/nouveau/nouveau_prime.c
index 656c334ee7d9..bae6a3eccee0 100644
--- a/drivers/gpu/drm/nouveau/nouveau_prime.c
+++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
@@ -60,6 +60,7 @@ struct drm_gem_object
*nouveau_gem_prime_import_sg_table(struct drm_device *dev,
struct sg_table *sg)
{
struct nouveau_drm *drm = nouveau_drm(dev);
+ struct drm_gem_object *obj;
struct nouveau_bo *nvbo;
struct dma_resv *robj = attach->dmabuf->resv;
u64 size = attach->dmabuf->size;
@@ -71,9 +72,10 @@ struct drm_gem_object
*nouveau_gem_prime_import_sg_table(struct drm_device *dev,
dma_resv_lock(robj, NULL);
nvbo = nouveau_bo_alloc(>client, , , flags, 0, 0);
- dma_resv_unlock(robj);
- if (IS_ERR(nvbo))
- return ERR_CAST(nvbo);
+ if (IS_ERR(nvbo)) {
+ obj = ERR_CAST(nvbo);
+ goto unlock;
+ }
nvbo->valid_domains = NOUVEAU_GEM_DOMAIN_GART;
@@ -82,16 +84,22 @@ struct drm_gem_object
*nouveau_gem_prime_import_sg_table(struct drm_device *dev,
ret = drm_gem_object_init(dev, >bo.base, size);
if (ret) {
nouveau_bo_ref(NULL, );
- return ERR_PTR(-ENOMEM);
+ obj = ERR_PTR(-ENOMEM);
+ goto unlock;
}
ret = nouveau_bo_init(nvbo, size, align, flags, sg, robj);
if (ret) {
nouveau_bo_ref(NULL, );
- return ERR_PTR(ret);
+ obj = ERR_PTR(ret);
+ goto unlock;
}
- return >bo.base;
+ obj = >bo.base;
+
+unlock:
+ dma_resv_unlock(robj);
+ return obj;
}
int nouveau_gem_prime_pin(struct drm_gem_object *obj)
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109628] WARNING at dcn10_hw_sequencer.c:868 dcn10_verify_allow_pstate_change_high()
https://bugs.freedesktop.org/show_bug.cgi?id=109628 Rohan Lean changed: What|Removed |Added CC||ro...@rohanlean.de --- Comment #18 from Rohan Lean --- Created attachment 145376 --> https://bugs.freedesktop.org/attachment.cgi?id=145376=edit 5.2.14 kernel messages Messages similar to this just overflowed my systemd-journal in a couple of minutes, causing high resource use by journald. An external monitor was attached; I had not noticed any problems apart from the sudden resource use. I have attached a representative (I hope) portion of the log. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/tegra: switch to using devm_gpiod_get_optional
On Sun, Sep 15, 2019 at 12:13:23AM -0700, Dmitry Torokhov wrote:
> We do not really need to use API that fetches GPIO data from an
> arbitrary device tree node, as we are dealing with device tree node
> assigned to the device structure. We can easily switch to
> devm_gpiod_get_optional() plus gpiod_set_consumer_name() and clean up
> the code.
>
> Note this is part of efforts to get rid of [devm_]gpiod_get_from_of_node
> in drivers so that gpiolib can be cleaned up.
>
> Signed-off-by: Dmitry Torokhov
> ---
> drivers/gpu/drm/tegra/output.c | 18 +++---
> 1 file changed, 7 insertions(+), 11 deletions(-)
We can't do that. There's a special case in rgb.c that sets
output->of_node to something different than output->dev, so we actually
need to pass the struct device_node * separately.
Thierry
>
> diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
> index bdcaa4c7168c..b4248125b844 100644
> --- a/drivers/gpu/drm/tegra/output.c
> +++ b/drivers/gpu/drm/tegra/output.c
> @@ -121,19 +121,15 @@ int tegra_output_probe(struct tegra_output *output)
> of_node_put(ddc);
> }
>
> - output->hpd_gpio = devm_gpiod_get_from_of_node(output->dev,
> -output->of_node,
> -"nvidia,hpd-gpio", 0,
> -GPIOD_IN,
> -"HDMI hotplug detect");
> - if (IS_ERR(output->hpd_gpio)) {
> - if (PTR_ERR(output->hpd_gpio) != -ENOENT)
> - return PTR_ERR(output->hpd_gpio);
> -
> - output->hpd_gpio = NULL;
> - }
> + output->hpd_gpio = devm_gpiod_get_optional(output->dev,
> +"nvidia,hpd", GPIOD_IN);
> + if (IS_ERR(output->hpd_gpio))
> + return PTR_ERR(output->hpd_gpio);
>
> if (output->hpd_gpio) {
> + gpiod_set_consumer_name(output->hpd_gpio,
> + "HDMI hotplug detect");
> +
> err = gpiod_to_irq(output->hpd_gpio);
> if (err < 0) {
> dev_err(output->dev, "gpiod_to_irq(): %d\n", err);
> --
> 2.23.0.237.gc6a4ce50a0-goog
>
>
> --
> Dmitry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
DRM Driver implementation question
Hi Laurent/Kieran, I need to upstream a driver for a display controller that within its registers memory region contains registers related to a PWM device. The PWM device is for controlling the backlight of the display. Ideally, I would like to create a separated driver for the PWM, so that I can re-use "pwm-backlight", but since the registers for the PWM are right in the middle of the registers for the display controller I would need to ioremap the memory region for the PWM registers region twice, once from the display controller driver, and once from the PWM driver. Do you think that the double ioremap would be acceptable upstream? Kind Regards, Gareth
Re: [PATCH 2/9] drm/print: add drm_debug_enabled()
On Mon, 16 Sep 2019, Eric Engestrom wrote:
> On Monday, 2019-09-16 11:53:24 +0300, Jani Nikula wrote:
>> On Fri, 13 Sep 2019, Eric Engestrom wrote:
>> > On Friday, 2019-09-13 14:51:39 +0300, Jani Nikula wrote:
>> >> Add helper to check if a drm debug category is enabled. Convert drm core
>> >> to use it. No functional changes.
>> >>
>> >> Signed-off-by: Jani Nikula
>> >> ---
>> >> drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
>> >> drivers/gpu/drm/drm_dp_mst_topology.c | 6 +++---
>> >> drivers/gpu/drm/drm_edid.c| 2 +-
>> >> drivers/gpu/drm/drm_edid_load.c | 2 +-
>> >> drivers/gpu/drm/drm_mipi_dbi.c| 4 ++--
>> >> drivers/gpu/drm/drm_print.c | 4 ++--
>> >> drivers/gpu/drm/drm_vblank.c | 6 +++---
>> >> include/drm/drm_print.h | 5 +
>> >> 8 files changed, 18 insertions(+), 13 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
>> >> b/drivers/gpu/drm/drm_atomic_uapi.c
>> >> index 5a5b42db6f2a..6576cd997cbd 100644
>> >> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> >> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> >> @@ -1406,7 +1406,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>> >> } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
>> >> ret = drm_atomic_nonblocking_commit(state);
>> >> } else {
>> >> - if (unlikely(drm_debug & DRM_UT_STATE))
>> >> + if (unlikely(drm_debug_enabled(DRM_UT_STATE)))
>> >> drm_atomic_print_state(state);
>> >>
>> >> ret = drm_atomic_commit(state);
>> >> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
>> >> b/drivers/gpu/drm/drm_dp_mst_topology.c
>> >> index 97216099a718..f47c5b6b51f7 100644
>> >> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
>> >> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
>> >> @@ -1180,7 +1180,7 @@ static int drm_dp_mst_wait_tx_reply(struct
>> >> drm_dp_mst_branch *mstb,
>> >> }
>> >> }
>> >> out:
>> >> - if (unlikely(ret == -EIO && drm_debug & DRM_UT_DP)) {
>> >> + if (unlikely(ret == -EIO && drm_debug_enabled(DRM_UT_DP))) {
>> >> struct drm_printer p = drm_debug_printer(DBG_PREFIX);
>> >>
>> >> drm_dp_mst_dump_sideband_msg_tx(, txmsg);
>> >> @@ -2321,7 +2321,7 @@ static int process_single_tx_qlock(struct
>> >> drm_dp_mst_topology_mgr *mgr,
>> >> idx += tosend + 1;
>> >>
>> >> ret = drm_dp_send_sideband_msg(mgr, up, chunk, idx);
>> >> - if (unlikely(ret && drm_debug & DRM_UT_DP)) {
>> >> + if (unlikely(ret && drm_debug_enabled(DRM_UT_DP))) {
>> >> struct drm_printer p = drm_debug_printer(DBG_PREFIX);
>> >>
>> >> drm_printf(, "sideband msg failed to send\n");
>> >> @@ -2388,7 +2388,7 @@ static void drm_dp_queue_down_tx(struct
>> >> drm_dp_mst_topology_mgr *mgr,
>> >> mutex_lock(>qlock);
>> >> list_add_tail(>next, >tx_msg_downq);
>> >>
>> >> - if (unlikely(drm_debug & DRM_UT_DP)) {
>> >> + if (unlikely(drm_debug_enabled(DRM_UT_DP))) {
>> >> struct drm_printer p = drm_debug_printer(DBG_PREFIX);
>> >>
>> >> drm_dp_mst_dump_sideband_msg_tx(, txmsg);
>> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> >> index 12c783f4d956..58dad4d24cd4 100644
>> >> --- a/drivers/gpu/drm/drm_edid.c
>> >> +++ b/drivers/gpu/drm/drm_edid.c
>> >> @@ -1551,7 +1551,7 @@ static void connector_bad_edid(struct drm_connector
>> >> *connector,
>> >> {
>> >> int i;
>> >>
>> >> - if (connector->bad_edid_counter++ && !(drm_debug & DRM_UT_KMS))
>> >> + if (connector->bad_edid_counter++ && !drm_debug_enabled(DRM_UT_KMS))
>> >> return;
>> >>
>> >> dev_warn(connector->dev->dev,
>> >> diff --git a/drivers/gpu/drm/drm_edid_load.c
>> >> b/drivers/gpu/drm/drm_edid_load.c
>> >> index d38b3b255926..37d8ba3ddb46 100644
>> >> --- a/drivers/gpu/drm/drm_edid_load.c
>> >> +++ b/drivers/gpu/drm/drm_edid_load.c
>> >> @@ -175,7 +175,7 @@ static void *edid_load(struct drm_connector
>> >> *connector, const char *name,
>> >> u8 *edid;
>> >> int fwsize, builtin;
>> >> int i, valid_extensions = 0;
>> >> - bool print_bad_edid = !connector->bad_edid_counter || (drm_debug &
>> >> DRM_UT_KMS);
>> >> + bool print_bad_edid = !connector->bad_edid_counter ||
>> >> drm_debug_enabled(DRM_UT_KMS);
>> >>
>> >> builtin = match_string(generic_edid_name, GENERIC_EDIDS, name);
>> >> if (builtin >= 0) {
>> >> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c
>> >> b/drivers/gpu/drm/drm_mipi_dbi.c
>> >> index f8154316a3b0..ccfb5b33c5e3 100644
>> >> --- a/drivers/gpu/drm/drm_mipi_dbi.c
>> >> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
>> >> @@ -783,7 +783,7 @@ static int mipi_dbi_spi1e_transfer(struct mipi_dbi
>> >> *dbi, int dc,
>> >> int i, ret;
>> >> u8 *dst;
>> >>
>> >> - if (drm_debug & DRM_UT_DRIVER)
>> >> + if (drm_debug_enabled(DRM_UT_DRIVER))
>> >> pr_debug("[drm:%s] dc=%d, max_chunk=%zu, transfers:\n",
>> >>__func__, dc, max_chunk);
>> >>
>> >> @@ -907,7 +907,7 @@ static int
[Bug 202445] amdgpu/dc: framerate dropping below adaptive sync range causes screen flickering
https://bugzilla.kernel.org/show_bug.cgi?id=202445 --- Comment #34 from jaapbuur...@gmail.com --- How big is the improvement? Is the issue completely gone, or is it still there? The KSP example also reliably triggers the flickering for me, and I am using the exact same monitor. These LFC patches are going to be included in the 5.5 kernel, right? Or will they be included in an earlier kernel version? -- 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: atomic helper: fix W=1 warnings
Le lun. 9 sept. 2019 à 16:41, Benjamin Gaignard
a écrit :
>
> Fix warnings with W=1.
> Few for_each macro set variables that are never used later.
> Prevent warning by marking these variables as __maybe_unused.
>
A little up on this one because it may exist others ways to fix these warnings.
Get feedback on this path could give the direction for similar ones in drm.
Thanks,
Benjamin
> Signed-off-by: Benjamin Gaignard
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 36 ++--
> 1 file changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index aa16ea17ff9b..b69d17b0b9bd 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -262,7 +262,7 @@ steal_encoder(struct drm_atomic_state *state,
> struct drm_encoder *encoder)
> {
> struct drm_crtc_state *crtc_state;
> - struct drm_connector *connector;
> + struct drm_connector __maybe_unused *connector;
> struct drm_connector_state *old_connector_state, *new_connector_state;
> int i;
>
> @@ -412,7 +412,7 @@ mode_fixup(struct drm_atomic_state *state)
> {
> struct drm_crtc *crtc;
> struct drm_crtc_state *new_crtc_state;
> - struct drm_connector *connector;
> + struct drm_connector __maybe_unused *connector;
> struct drm_connector_state *new_conn_state;
> int i;
> int ret;
> @@ -608,7 +608,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> {
> struct drm_crtc *crtc;
> struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> - struct drm_connector *connector;
> + struct drm_connector __maybe_unused *connector;
> struct drm_connector_state *old_connector_state, *new_connector_state;
> int i, ret;
> unsigned connectors_mask = 0;
> @@ -984,7 +984,7 @@ crtc_needs_disable(struct drm_crtc_state *old_state,
> static void
> disable_outputs(struct drm_device *dev, struct drm_atomic_state *old_state)
> {
> - struct drm_connector *connector;
> + struct drm_connector __maybe_unused *connector;
> struct drm_connector_state *old_conn_state, *new_conn_state;
> struct drm_crtc *crtc;
> struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> @@ -1173,7 +1173,7 @@ crtc_set_mode(struct drm_device *dev, struct
> drm_atomic_state *old_state)
> {
> struct drm_crtc *crtc;
> struct drm_crtc_state *new_crtc_state;
> - struct drm_connector *connector;
> + struct drm_connector __maybe_unused *connector;
> struct drm_connector_state *new_conn_state;
> int i;
>
> @@ -1294,7 +1294,7 @@ void drm_atomic_helper_commit_modeset_enables(struct
> drm_device *dev,
> struct drm_crtc *crtc;
> struct drm_crtc_state *old_crtc_state;
> struct drm_crtc_state *new_crtc_state;
> - struct drm_connector *connector;
> + struct drm_connector __maybe_unused *connector;
> struct drm_connector_state *new_conn_state;
> int i;
>
> @@ -1384,7 +1384,7 @@ int drm_atomic_helper_wait_for_fences(struct drm_device
> *dev,
> struct drm_atomic_state *state,
> bool pre_swap)
> {
> - struct drm_plane *plane;
> + struct drm_plane __maybe_unused *plane;
> struct drm_plane_state *new_plane_state;
> int i, ret;
>
> @@ -1431,7 +1431,7 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device
> *dev,
> struct drm_atomic_state *old_state)
> {
> struct drm_crtc *crtc;
> - struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> + struct drm_crtc_state __maybe_unused *old_crtc_state, *new_crtc_state;
> int i, ret;
> unsigned crtc_mask = 0;
>
> @@ -1621,7 +1621,7 @@ static void commit_work(struct work_struct *work)
> int drm_atomic_helper_async_check(struct drm_device *dev,
>struct drm_atomic_state *state)
> {
> - struct drm_crtc *crtc;
> + struct drm_crtc __maybe_unused *crtc;
> struct drm_crtc_state *crtc_state;
> struct drm_plane *plane = NULL;
> struct drm_plane_state *old_plane_state = NULL;
> @@ -1982,9 +1982,9 @@ int drm_atomic_helper_setup_commit(struct
> drm_atomic_state *state,
> {
> struct drm_crtc *crtc;
> struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> - struct drm_connector *conn;
> + struct drm_connector __maybe_unused *conn;
> struct drm_connector_state *old_conn_state, *new_conn_state;
> - struct drm_plane *plane;
> + struct drm_plane __maybe_unused *plane;
> struct drm_plane_state *old_plane_state, *new_plane_state;
> struct drm_crtc_commit *commit;
> int i, ret;
> @@ -2214,7 +2214,7 @@ EXPORT_SYMBOL(drm_atomic_helper_fake_vblank);
> */
> void
Re: [PATCH] drm: sti: fix W=1 warnings
Le lun. 9 sept. 2019 à 12:29, Benjamin Gaignard
a écrit :
>
> Fix warnings when W=1.
> No code changes, only clean up in sti internal structures and functions
> descriptions.
>
> Signed-off-by: Benjamin Gaignard
For my own reference, applied on drm-misc-next
> ---
> drivers/gpu/drm/sti/sti_cursor.c | 2 +-
> drivers/gpu/drm/sti/sti_dvo.c| 2 +-
> drivers/gpu/drm/sti/sti_gdp.c| 2 +-
> drivers/gpu/drm/sti/sti_hda.c| 2 +-
> drivers/gpu/drm/sti/sti_hdmi.c | 4 ++--
> drivers/gpu/drm/sti/sti_tvout.c | 10 +-
> drivers/gpu/drm/sti/sti_vtg.c| 2 +-
> 7 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_cursor.c
> b/drivers/gpu/drm/sti/sti_cursor.c
> index 0bf7c332cf0b..ea64c1dcaf63 100644
> --- a/drivers/gpu/drm/sti/sti_cursor.c
> +++ b/drivers/gpu/drm/sti/sti_cursor.c
> @@ -47,7 +47,7 @@ struct dma_pixmap {
> void *base;
> };
>
> -/**
> +/*
> * STI Cursor structure
> *
> * @sti_plane:sti_plane structure
> diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
> index 9e6d5d8b7030..c33d0aaee82b 100644
> --- a/drivers/gpu/drm/sti/sti_dvo.c
> +++ b/drivers/gpu/drm/sti/sti_dvo.c
> @@ -65,7 +65,7 @@ static struct dvo_config rgb_24bit_de_cfg = {
> .awg_fwgen_fct = sti_awg_generate_code_data_enable_mode,
> };
>
> -/**
> +/*
> * STI digital video output structure
> *
> * @dev: driver device
> diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
> index 8e926cd6a1c8..11595c748844 100644
> --- a/drivers/gpu/drm/sti/sti_gdp.c
> +++ b/drivers/gpu/drm/sti/sti_gdp.c
> @@ -103,7 +103,7 @@ struct sti_gdp_node_list {
> dma_addr_t btm_field_paddr;
> };
>
> -/**
> +/*
> * STI GDP structure
> *
> * @sti_plane: sti_plane structure
> diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
> index 94e404f13234..3512a94a0fca 100644
> --- a/drivers/gpu/drm/sti/sti_hda.c
> +++ b/drivers/gpu/drm/sti/sti_hda.c
> @@ -230,7 +230,7 @@ static const struct sti_hda_video_config
> hda_supported_modes[] = {
> AWGi_720x480p_60, NN_720x480p_60, VID_ED}
> };
>
> -/**
> +/*
> * STI hd analog structure
> *
> * @dev: driver device
> diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
> index f03d617edc4c..87e34f7a6cfe 100644
> --- a/drivers/gpu/drm/sti/sti_hdmi.c
> +++ b/drivers/gpu/drm/sti/sti_hdmi.c
> @@ -333,7 +333,6 @@ static void hdmi_infoframe_reset(struct sti_hdmi *hdmi,
> * Helper to concatenate infoframe in 32 bits word
> *
> * @ptr: pointer on the hdmi internal structure
> - * @data: infoframe to write
> * @size: size to write
> */
> static inline unsigned int hdmi_infoframe_subpack(const u8 *ptr, size_t size)
> @@ -543,13 +542,14 @@ static int hdmi_vendor_infoframe_config(struct sti_hdmi
> *hdmi)
> return 0;
> }
>
> +#define HDMI_TIMEOUT_SWRESET 100 /*milliseconds */
> +
> /**
> * Software reset of the hdmi subsystem
> *
> * @hdmi: pointer on the hdmi internal structure
> *
> */
> -#define HDMI_TIMEOUT_SWRESET 100 /*milliseconds */
> static void hdmi_swreset(struct sti_hdmi *hdmi)
> {
> u32 val;
> diff --git a/drivers/gpu/drm/sti/sti_tvout.c b/drivers/gpu/drm/sti/sti_tvout.c
> index e1b3c8cb7287..b1fc77b150da 100644
> --- a/drivers/gpu/drm/sti/sti_tvout.c
> +++ b/drivers/gpu/drm/sti/sti_tvout.c
> @@ -157,9 +157,9 @@ static void tvout_write(struct sti_tvout *tvout, u32 val,
> int offset)
> *
> * @tvout: tvout structure
> * @reg: register to set
> - * @cr_r:
> - * @y_g:
> - * @cb_b:
> + * @cr_r: red chroma or red order
> + * @y_g: y or green order
> + * @cb_b: blue chroma or blue order
> */
> static void tvout_vip_set_color_order(struct sti_tvout *tvout, int reg,
> u32 cr_r, u32 y_g, u32 cb_b)
> @@ -214,7 +214,7 @@ static void tvout_vip_set_rnd(struct sti_tvout *tvout,
> int reg, u32 rnd)
> * @tvout: tvout structure
> * @reg: register to set
> * @main_path: main or auxiliary path
> - * @sel_input: selected_input (main/aux + conv)
> + * @video_out: selected_input (main/aux + conv)
> */
> static void tvout_vip_set_sel_input(struct sti_tvout *tvout,
> int reg,
> @@ -251,7 +251,7 @@ static void tvout_vip_set_sel_input(struct sti_tvout
> *tvout,
> *
> * @tvout: tvout structure
> * @reg: register to set
> - * @in_vid_signed: used video input format
> + * @in_vid_fmt: used video input format
> */
> static void tvout_vip_set_in_vid_fmt(struct sti_tvout *tvout,
> int reg, u32 in_vid_fmt)
> diff --git a/drivers/gpu/drm/sti/sti_vtg.c b/drivers/gpu/drm/sti/sti_vtg.c
> index ef4009f11396..0b17ac8a3faa 100644
> --- a/drivers/gpu/drm/sti/sti_vtg.c
> +++ b/drivers/gpu/drm/sti/sti_vtg.c
> @@ -121,7 +121,7 @@ struct sti_vtg_sync_params {
> u32 vsync_off_bot;
> };
>
> -/**
> +/*
> * STI VTG structure
> *
> * @regs: register mapping
> --
> 2.15.0
