Re: [PATCH v2 1/6] drm/msm/a6xx: Avoid freeing gmu resources multiple times
On Thu, May 23, 2019 at 01:16:40PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> The driver checks for gmu->mmio as a sign that the device has been
> initialized, however there are failures in probe below the mmio init.
> If one of those is hit, mmio will be non-null but freed.
>
> In that case, a6xx_gmu_probe will return an error to a6xx_gpu_init which
> will in turn call a6xx_gmu_remove which checks gmu->mmio and tries to free
> resources for a second time. This causes a great boom.
>
> Fix this by adding an initialized member to gmu which is set on
> successful probe and cleared on removal.
>
> Changes in v2:
> - None
>
> Cc: Jordan Crouse
> Signed-off-by: Sean Paul
Reviewed-by: Jordan Crouse
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 14 +-
> drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 1 +
> 2 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> index 38e2cfa9cec7..aa84edb25d91 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> @@ -74,7 +74,7 @@ bool a6xx_gmu_sptprac_is_on(struct a6xx_gmu *gmu)
> u32 val;
>
> /* This can be called from gpu state code so make sure GMU is valid */
> - if (IS_ERR_OR_NULL(gmu->mmio))
> + if (!gmu->initialized)
> return false;
>
> val = gmu_read(gmu, REG_A6XX_GMU_SPTPRAC_PWR_CLK_STATUS);
> @@ -90,7 +90,7 @@ bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
> u32 val;
>
> /* This can be called from gpu state code so make sure GMU is valid */
> - if (IS_ERR_OR_NULL(gmu->mmio))
> + if (!gmu->initialized)
> return false;
>
> val = gmu_read(gmu, REG_A6XX_GMU_SPTPRAC_PWR_CLK_STATUS);
> @@ -695,7 +695,7 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
> struct a6xx_gmu *gmu = _gpu->gmu;
> int status, ret;
>
> - if (WARN(!gmu->mmio, "The GMU is not set up yet\n"))
> + if (WARN(!gmu->initialized, "The GMU is not set up yet\n"))
> return 0;
>
> gmu->hung = false;
> @@ -765,7 +765,7 @@ bool a6xx_gmu_isidle(struct a6xx_gmu *gmu)
> {
> u32 reg;
>
> - if (!gmu->mmio)
> + if (!gmu->initialized)
> return true;
>
> reg = gmu_read(gmu, REG_A6XX_GPU_GMU_AO_GPU_CX_BUSY_STATUS);
> @@ -1227,7 +1227,7 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
> {
> struct a6xx_gmu *gmu = _gpu->gmu;
>
> - if (IS_ERR_OR_NULL(gmu->mmio))
> + if (!gmu->initialized)
> return;
>
> a6xx_gmu_stop(a6xx_gpu);
> @@ -1245,6 +1245,8 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
> iommu_detach_device(gmu->domain, gmu->dev);
>
> iommu_domain_free(gmu->domain);
> +
> + gmu->initialized = false;
> }
>
> int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct device_node *node)
> @@ -1309,6 +1311,8 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct
> device_node *node)
> /* Set up the HFI queues */
> a6xx_hfi_init(gmu);
>
> + gmu->initialized = true;
> +
> return 0;
> err:
> a6xx_gmu_memory_free(gmu, gmu->hfi);
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> index bedd8e6a63aa..39a26dd63674 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
> @@ -75,6 +75,7 @@ struct a6xx_gmu {
>
> struct a6xx_hfi_queue queues[2];
>
> + bool initialized;
> bool hung;
> };
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/mst: Fix MST sideband up-reply failure handling
Fix the breakage resulting in the stacktrace below, due to tx queue
being full when trying to send an up-reply. txmsg->seqno is -1 in this
case leading to a corruption of the mstb object by
txmsg->dst->tx_slots[txmsg->seqno] = NULL;
in process_single_up_tx_qlock().
[ +0,005162] [drm:process_single_tx_qlock [drm_kms_helper]]
set_hdr_from_dst_qlock: failed to find slot
[ +0,15] [drm:drm_dp_send_up_ack_reply.constprop.19 [drm_kms_helper]]
failed to send msg in q -11
[ +0,000939] BUG: kernel NULL pointer dereference, address: 05a0
[ +0,006982] #PF: supervisor write access in kernel mode
[ +0,005223] #PF: error_code(0x0002) - not-present page
[ +0,005135] PGD 0 P4D 0
[ +0,002581] Oops: 0002 [#1] PREEMPT SMP NOPTI
[ +0,004359] CPU: 1 PID: 1200 Comm: kworker/u16:3 Tainted: G U
5.2.0-rc1+ #410
[ +0,008433] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake
U DDR4 SODIMM PD RVP, BIOS ICLSFWR1.R00.3175.A00.1904261428 04/26/2019
[ +0,013323] Workqueue: i915-dp i915_digport_work_func [i915]
[ +0,005676] RIP: 0010:queue_work_on+0x19/0x70
[ +0,004372] Code: ff ff ff 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 41 56 49
89 f6 41 55 41 89 fd 41 54 55 53 48 89 d3 9c 5d fa e8 e7 81 0c 00 48 0f ba
2b 00 73 31 45 31 e4 f7 c5 00 02 00 00 74 13 e8 cf 7f
[ +0,018750] RSP: 0018:c97dfc50 EFLAGS: 00010006
[ +0,005222] RAX: 0046 RBX: 05a0 RCX: 0001
[ +0,007133] RDX: 0001b608 RSI: RDI: 82121972
[ +0,007129] RBP: 0202 R08: R09: 0001
[ +0,007129] R10: R11: R12: 88847bfa5096
[ +0,007131] R13: 0010 R14: 88849c08f3f8 R15:
[ +0,007128] FS: () GS:88849dc8()
knlGS:
[ +0,008083] CS: 0010 DS: ES: CR0: 80050033
[ +0,005749] CR2: 05a0 CR3: 05210006 CR4: 00760ee0
[ +0,007128] PKRU: 5554
[ +0,002722] Call Trace:
[ +0,002458] drm_dp_mst_handle_up_req+0x517/0x540 [drm_kms_helper]
[ +0,006197] ? drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
[ +0,005764] drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
[ +0,005623] ? intel_dp_hpd_pulse+0x205/0x370 [i915]
[ +0,005018] intel_dp_hpd_pulse+0x205/0x370 [i915]
[ +0,004836] i915_digport_work_func+0xbb/0x140 [i915]
[ +0,005108] process_one_work+0x245/0x610
[ +0,004027] worker_thread+0x37/0x380
[ +0,003684] ? process_one_work+0x610/0x610
[ +0,004184] kthread+0x119/0x130
[ +0,003240] ? kthread_park+0x80/0x80
[ +0,003668] ret_from_fork+0x24/0x50
Cc: Lyude Paul
Cc: Dave Airlie
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_dp_mst_topology.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index da1abca1b9e9..24c325f4a616 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1996,7 +1996,11 @@ static void process_single_up_tx_qlock(struct
drm_dp_mst_topology_mgr *mgr,
if (ret != 1)
DRM_DEBUG_KMS("failed to send msg in q %d\n", ret);
- txmsg->dst->tx_slots[txmsg->seqno] = NULL;
+ if (txmsg->seqno != -1) {
+ WARN_ON((unsigned)txmsg->seqno >
+ ARRAY_SIZE(txmsg->dst->tx_slots));
+ txmsg->dst->tx_slots[txmsg->seqno] = NULL;
+ }
}
static void drm_dp_queue_down_tx(struct drm_dp_mst_topology_mgr *mgr,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110721] graphics corruption on steam client with mesa 19.1.0 rc3 on polaris
https://bugs.freedesktop.org/show_bug.cgi?id=110721 --- Comment #16 from Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0...@gmail.com> --- I confirm that reverting "mesa: unreference current winsys buffers when unbinding winsys buffers" fixes the rendering issues in Spotify and Visual Studio Code. Thanks. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel
On Thu, May 23, 2019 at 06:43:46PM +0100, Catalin Marinas wrote: > On Thu, May 23, 2019 at 09:38:19AM -0700, Kees Cook wrote: > > What on this front would you be comfortable with? Given it's a new > > feature isn't it sufficient to have a CONFIG (and/or boot option)? > > I'd rather avoid re-building kernels. A boot option would do, unless we > see value in a per-process (inherited) personality or prctl. The I think I've convinced myself that the normal<->TBI ABI control should be a boot parameter. More below... > > What about testing tools that intentionally insert high bits for syscalls > > and are _expecting_ them to fail? It seems the TBI series will break them? > > In that case, do we need to opt into TBI as well? > > If there are such tools, then we may need a per-process control. It's > basically an ABI change. syzkaller already attempts to randomly inject non-canonical and 0x addresses for user pointers in syscalls in an effort to find bugs like CVE-2017-5123 where waitid() via unchecked put_user() was able to write directly to kernel memory[1]. It seems that using TBI by default and not allowing a switch back to "normal" ABI without a reboot actually means that userspace cannot inject kernel pointers into syscalls any more, since they'll get universally stripped now. Is my understanding correct, here? i.e. exploiting CVE-2017-5123 would be impossible under TBI? If so, then I think we should commit to the TBI ABI and have a boot flag to disable it, but NOT have a process flag, as that would allow attackers to bypass the masking. The only flag should be "TBI or MTE". If so, can I get top byte masking for other architectures too? Like, just to strip high bits off userspace addresses? ;) (Oh, in looking I see this is implemented with sign-extension... why not just a mask? So it'll either be valid userspace address or forced into the non-canonical range?) [1] https://salls.github.io/Linux-Kernel-CVE-2017-5123/ > > Alright, the tl;dr appears to be: > > - you want more assurances that we can find __user stripping in the > > kernel more easily. (But this seems like a parallel problem.) > > Yes, and that we found all (most) cases now. The reason I don't see it > as a parallel problem is that, as maintainer, I promise an ABI to user > and I'd rather stick to it. I don't want, for example, ncurses to stop > working because of some ioctl() rejecting tagged pointers. But this is what I don't understand: it would need to be ncurses _using TBI_, that would stop working (having started to work before, but then regress due to a newly added one-off bug). Regular ncurses will be fine because it's not using TBI. So The Golden Rule isn't violated, and by definition, it's a specific regression caused by some bug (since TBI would have had to have worked _before_ in the situation to be considered a regression now). Which describes the normal path for kernel development... add feature, find corner cases where it doesn't work, fix them, encounter new regressions, fix those, repeat forever. > If it's just the occasional one-off bug I'm fine to deal with it. But > no-one convinced me yet that this is the case. You believe there still to be some systemic cases that haven't been found yet? And even if so -- isn't it better to work on that incrementally? > As for the generic driver code (filesystems or other subsystems), > without some clear direction for developers, together with static > checking/sparse, on how user pointers are cast to longs (one example), > it would become my responsibility to identify and fix them up with any > kernel release. This series is not providing such guidance, just adding > untagged_addr() in some places that we think matter. What about adding a nice bit of .rst documentation that describes the situation and shows how to use untagged_addr(). This is the kind of kernel-wide change that "everyone" needs to know about, and shouldn't be the arch maintainer's sole responsibility to fix. > > - we might need to opt in to TBI with a prctl() > > Yes, although still up for discussion. I think I've talked myself out of it. I say boot param only! :) So what do you say to these next steps: - change untagged_addr() to use a static branch that is controlled with a boot parameter. - add, say, Documentation/core-api/user-addresses.rst to describe proper care and handling of user space pointers with untagged_addr(), with examples based on all the cases seen so far in this series. - continue work to improve static analysis. Thanks for wading through this with me! :) -- Kees Cook ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110749] [Vega 11] [amdgpu retry page fault VM_L2_PROTECTION_FAULT_STATUS] System lock up during playing Steam version of Saints Row 3
https://bugs.freedesktop.org/show_bug.cgi?id=110749 --- Comment #1 from Cyrax --- OS : Arch Linux with linux-next-git kernel https://aur.archlinux.org/packages/linux-next-git With latest libdrm-git, mesa-git and llvm-git packages installed. local/linux-next-git 20190523.r0.gf48b97e163b3-1 The Linux-next-git kernel and modules local/linux-next-git-headers 20190523.r0.gf48b97e163b3-1 Header files and scripts for building modules for Linux-next-git kernel local/lib32-libdrm-git 2.4.98.r16.g922d9299-2 Userspace interface to kernel DRM services, git 32-bit version local/libdrm-git 2.4.98.r16.g922d9299-1 Userspace interface to kernel DRM services, master git version local/lib32-llvm-git 9.0.0_r317246.30905a375ea-1 Collection of modular and reusable compiler and toolchain technologies (32-bit, git) local/lib32-llvm-libs-git 9.0.0_r317246.30905a375ea-1 Collection of modular and reusable compiler and toolchain technologies (32-bit, git) local/llvm-git 9.0.0_r317246.30905a375ea-1 LLVM development version. includes clang and many other tools local/llvm-libs-git 9.0.0_r317246.30905a375ea-1 runtime libraries for llvm-git local/lib32-mesa-git 19.2.0_devel.92.8d386e6eef8-1 an open-source implementation of the OpenGL specification, git version local/mesa-git 19.2.0_devel.92.8d386e6eef8-1 an open-source implementation of the OpenGL specification, git version -- 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 v2 2/6] drm/msm/a6xx: Remove duplicate irq disable from remove
On Thu, May 23, 2019 at 01:16:41PM -0400, Sean Paul wrote: > From: Sean Paul > > a6xx_gmu_stop() already calls this function via shutdown or force_stop, > so it's not necessary to call it twice. Previously this would have > knocked the irq refcount out of sync, but now with the irqs_enabled flag > it's just housekeeping. > > Changes in v2: > - None > > Cc: Jordan Crouse > Signed-off-by: Sean Paul Reviewed-by: Jordan Crouse > --- > drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > index aa84edb25d91..742c8ff9a61c 100644 > --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > @@ -1239,7 +1239,6 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu) > dev_pm_domain_detach(gmu->gxpd, false); > } > > - a6xx_gmu_irq_disable(gmu); > a6xx_gmu_memory_free(gmu, gmu->hfi); > > iommu_detach_device(gmu->domain, gmu->dev); > -- > Sean Paul, Software Engineer, Google / Chromium OS > -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: build failure after merge of the drm-fixes tree
Hi all,
After merging the drm-fixes tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
'load_dmcu_fw':
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:667:7: error:
implicit declaration of function 'ASICREV_IS_PICASSO'; did you mean
'ASICREV_IS_VEGA12_P'? [-Werror=implicit-function-declaration]
if (ASICREV_IS_PICASSO(adev->external_rev_id))
^~
ASICREV_IS_VEGA12_P
Caused by commit
55143dc23ca4 ("drm/amd/display: Don't load DMCU for Raven 1")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
pgpTyuNGOkWbE.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mst: Fix MST sideband up-reply failure handling
On Thu, May 23, 2019 at 06:09:56PM -0400, Lyude Paul wrote:
> Patch mostly looks good to me, one comment below
>
> On Fri, 2019-05-24 at 00:24 +0300, Imre Deak wrote:
> > Fix the breakage resulting in the stacktrace below, due to tx queue
> > being full when trying to send an up-reply. txmsg->seqno is -1 in this
> > case leading to a corruption of the mstb object by
> >
> > txmsg->dst->tx_slots[txmsg->seqno] = NULL;
> >
> > in process_single_up_tx_qlock().
> >
> > [ +0,005162] [drm:process_single_tx_qlock [drm_kms_helper]]
> > set_hdr_from_dst_qlock: failed to find slot
> > [ +0,15] [drm:drm_dp_send_up_ack_reply.constprop.19 [drm_kms_helper]]
> > failed to send msg in q -11
> > [ +0,000939] BUG: kernel NULL pointer dereference, address:
> > 05a0
> > [ +0,006982] #PF: supervisor write access in kernel mode
> > [ +0,005223] #PF: error_code(0x0002) - not-present page
> > [ +0,005135] PGD 0 P4D 0
> > [ +0,002581] Oops: 0002 [#1] PREEMPT SMP NOPTI
> > [ +0,004359] CPU: 1 PID: 1200 Comm: kworker/u16:3 Tainted:
> > G U5.2.0-rc1+ #410
> > [ +0,008433] Hardware name: Intel Corporation Ice Lake Client
> > Platform/IceLake U DDR4 SODIMM PD RVP, BIOS ICLSFWR1.R00.3175.A00.1904261428
> > 04/26/2019
> > [ +0,013323] Workqueue: i915-dp i915_digport_work_func [i915]
> > [ +0,005676] RIP: 0010:queue_work_on+0x19/0x70
> > [ +0,004372] Code: ff ff ff 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 41 56
> > 49 89 f6 41 55 41 89 fd 41 54 55 53 48 89 d3 9c 5d fa e8 e7 81 0c 00 48
> > 0f ba 2b 00 73 31 45 31 e4 f7 c5 00 02 00 00 74 13 e8 cf 7f
> > [ +0,018750] RSP: 0018:c97dfc50 EFLAGS: 00010006
> > [ +0,005222] RAX: 0046 RBX: 05a0 RCX:
> > 0001
> > [ +0,007133] RDX: 0001b608 RSI: RDI:
> > 82121972
> > [ +0,007129] RBP: 0202 R08: R09:
> > 0001
> > [ +0,007129] R10: R11: R12:
> > 88847bfa5096
> > [ +0,007131] R13: 0010 R14: 88849c08f3f8 R15:
> >
> > [ +0,007128] FS: () GS:88849dc8()
> > knlGS:
> > [ +0,008083] CS: 0010 DS: ES: CR0: 80050033
> > [ +0,005749] CR2: 05a0 CR3: 05210006 CR4:
> > 00760ee0
> > [ +0,007128] PKRU: 5554
> > [ +0,002722] Call Trace:
> > [ +0,002458] drm_dp_mst_handle_up_req+0x517/0x540 [drm_kms_helper]
> > [ +0,006197] ? drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
> > [ +0,005764] drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
> > [ +0,005623] ? intel_dp_hpd_pulse+0x205/0x370 [i915]
> > [ +0,005018] intel_dp_hpd_pulse+0x205/0x370 [i915]
> > [ +0,004836] i915_digport_work_func+0xbb/0x140 [i915]
> > [ +0,005108] process_one_work+0x245/0x610
> > [ +0,004027] worker_thread+0x37/0x380
> > [ +0,003684] ? process_one_work+0x610/0x610
> > [ +0,004184] kthread+0x119/0x130
> > [ +0,003240] ? kthread_park+0x80/0x80
> > [ +0,003668] ret_from_fork+0x24/0x50
> >
> > Cc: Lyude Paul
> > Cc: Dave Airlie
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/drm_dp_mst_topology.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index da1abca1b9e9..24c325f4a616 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -1996,7 +1996,11 @@ static void process_single_up_tx_qlock(struct
> > drm_dp_mst_topology_mgr *mgr,
> > if (ret != 1)
> > DRM_DEBUG_KMS("failed to send msg in q %d\n", ret);
> >
> > - txmsg->dst->tx_slots[txmsg->seqno] = NULL;
> > + if (txmsg->seqno != -1) {
> > + WARN_ON((unsigned)txmsg->seqno >
> > + ARRAY_SIZE(txmsg->dst->tx_slots));
>
> Not 100% sure on this nitpick myself but, if we know that txmsg->seqno is
> about to go out of bounds shouldn't we also try to take action to stop it?
> like
Imo, it's worth keeping thins simple. If the WARN triggers we need to
fix the original issue in any case (txmsg->seqno never should be set to
anything else than -1 or a valid idx) so making the assignment here
conditional wouldn't have a real purpose.
>
> if (!WARN_ON((unsigned)txmsg->seqno > ARRAY_SIZE(txmsg->dst->tx_slots)))
> txmsg->dst->tx_slots[txmsg->seqno] = NULL;
>
>
>
> > + txmsg->dst->tx_slots[txmsg->seqno] = NULL;
> > + }
> > }
> >
> > static void drm_dp_queue_down_tx(struct drm_dp_mst_topology_mgr *mgr,
> --
> Cheers,
> Lyude Paul
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv6 4/4] drm/omap: add support for manually updated displays
This adds the required infrastructure for manually updated displays,
such as DSI command mode panels. While those panels often support
partial updates we currently always do a full refresh.
The display will be refreshed when something calls the dirty callback,
such as libdrm's drmModeDirtyFB(). This is currently being done at least
by the kernel console and Xorg (with modesetting driver) in their
default configuration. Weston does not implement this and the fbdev
backend does not work (display will not update). Weston's DRM backend
uses double buffering and the page flip will also trigger a display
refresh.
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 114 ++--
drivers/gpu/drm/omapdrm/omap_crtc.h | 1 +
drivers/gpu/drm/omapdrm/omap_fb.c | 19 +
3 files changed, 129 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 68697820d189..b59065365c9e 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -32,6 +32,7 @@ struct omap_crtc_state {
/* Shadow values for legacy userspace support. */
unsigned int rotation;
unsigned int zpos;
+ bool manually_updated;
};
#define to_omap_crtc(x) container_of(x, struct omap_crtc, base)
@@ -51,6 +52,7 @@ struct omap_crtc {
bool pending;
wait_queue_head_t pending_wait;
struct drm_pending_vblank_event *event;
+ struct delayed_work update_work;
void (*framedone_handler)(void *);
void *framedone_handler_data;
@@ -105,21 +107,18 @@ int omap_crtc_wait_pending(struct drm_crtc *crtc)
/*
* Manager-ops, callbacks from output when they need to configure
* the upstream part of the video pipe.
- *
- * Most of these we can ignore until we add support for command-mode
- * panels.. for video-mode the crtc-helpers already do an adequate
- * job of sequencing the setup of the video pipe in the proper order
*/
-/* we can probably ignore these until we support command-mode panels: */
static void omap_crtc_dss_start_update(struct omap_drm_private *priv,
enum omap_channel channel)
{
+ priv->dispc_ops->mgr_enable(priv->dispc, channel, true);
}
/* Called only from the encoder enable/disable and suspend/resume handlers. */
static void omap_crtc_set_enabled(struct drm_crtc *crtc, bool enable)
{
+ struct omap_crtc_state *omap_state = to_omap_crtc_state(crtc->state);
struct drm_device *dev = crtc->dev;
struct omap_drm_private *priv = dev->dev_private;
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
@@ -131,6 +130,12 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc,
bool enable)
if (WARN_ON(omap_crtc->enabled == enable))
return;
+ if (omap_state->manually_updated) {
+ omap_irq_enable_framedone(crtc, enable);
+ omap_crtc->enabled = enable;
+ return;
+ }
+
if (omap_crtc->pipe->output->type == OMAP_DISPLAY_TYPE_HDMI) {
priv->dispc_ops->mgr_enable(priv->dispc, channel, enable);
omap_crtc->enabled = enable;
@@ -352,6 +357,51 @@ void omap_crtc_framedone_irq(struct drm_crtc *crtc,
uint32_t irqstatus)
wake_up(_crtc->pending_wait);
}
+void omap_crtc_flush(struct drm_crtc *crtc)
+{
+ struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+ struct omap_crtc_state *omap_state = to_omap_crtc_state(crtc->state);
+
+ if (!omap_state->manually_updated)
+ return;
+
+ if (!delayed_work_pending(_crtc->update_work))
+ schedule_delayed_work(_crtc->update_work, 0);
+}
+
+static void omap_crtc_manual_display_update(struct work_struct *data)
+{
+ struct omap_crtc *omap_crtc =
+ container_of(data, struct omap_crtc, update_work.work);
+ struct drm_display_mode *mode = _crtc->pipe->crtc->mode;
+ struct omap_dss_device *dssdev = omap_crtc->pipe->output->next;
+ struct drm_device *dev = omap_crtc->base.dev;
+ const struct omap_dss_driver *dssdrv;
+ int ret;
+
+ if (!dssdev) {
+ dev_err_once(dev->dev, "missing display dssdev!");
+ return;
+ }
+
+ dssdrv = dssdev->driver;
+ if (!dssdrv || !dssdrv->update) {
+ dev_err_once(dev->dev, "missing or incorrect dssdrv!");
+ return;
+ }
+
+ if (dssdrv->sync)
+ dssdrv->sync(dssdev);
+
+ ret = dssdrv->update(dssdev, 0, 0, mode->hdisplay, mode->vdisplay);
+ if (ret < 0) {
+ spin_lock_irq(>event_lock);
+ omap_crtc->pending = false;
+ spin_unlock_irq(>event_lock);
+ wake_up(_crtc->pending_wait);
+ }
+}
+
static void omap_crtc_write_crtc_properties(struct drm_crtc *crtc)
{
struct omap_drm_private *priv =
[PATCHv6 0/4] omapdrm: DSI command mode panel support
Hi, Here is another round of the DSI command mode panel patchset integrating the feedback from PATCHv5. The patches are based on v5.2-rc1 tag. It does not contain the patches required for OMAP3 support (it needs a workaround for a hardware bug) and for automatic display rotation. They should get their own series, once after everything has been moved to DRM panel API. I think DRM panel conversion should happen _after_ this series, since otherwise there is a high risk of bricking DSI support completely. I already started a WIP branch for converting DSI to the DRM panel API on top of this patchset. Tested on Droid 4: * Display blanking - automatic backlight blanking is missing (not handled by DSI) * Framebuffer Console, updated at 1Hz due to blinking cursor * Xorg 1.19 with modesetting driver * Weston 5.0 with DRM backend * kmstest (static image) * No updates send when nothing needs to be sent Known issues: * OMAP3 is untested and most likely broken due to missing workaround(s) for hardware bugs. * Weston 5.0 with fbdev backend does not work, since it uses neither page flip nor dirty ioctl. You need to use the drm backend. Changes since PATCHv5: * Rebased to v5.2-rc1 * Simplified omap_framebuffer_dirty() by using drm_for_each_crtc() Changes since PATCHv4: * Apply Acked-/Tested-by received from Tony and Pavel * Fix spelling/optimize commit messages * Use proper multi-line comments * Restructure patch 4: move the whole HDMI block into a static subfunction, that is only called when output type is HDMI. Also drop the incorrect check for DVI. Changes since PATCHv3: * Drop all Tested/Acked-by tags * Drop the rotation patches for now * Rebase to 4.20-rc1 + fixes from Laurent and Tony * Add fixes for DSI regressions introduced in 4.20-rc1 * Store info update manual update mode in omap_crtc_state * Lock modesetting in omap_framebuffer_dirty * Directly loop through CRTCs instead of connectors in dirty function * Properly refresh display during page flips and get Weston working * Add more comments about implementation details Changes since PATCHv2: * Drop omap3 quirk patch (OMAP3 should get its own mini-series) * Rebase to current linux-next * Use existing 'rotation' DT property to set DRM orientation hint * Add Tested-by from Tony Changes since PATCHv1: * Drop patches, that were queued by Tomi * Rebase to current master * Rework the omap3 workaround patch to only affect omap3 * Add orientation DRM property support -- Sebastian Sebastian Reichel (4): drm/omap: use DRM_DEBUG_DRIVER instead of CORE drm/omap: don't check dispc timings for DSI drm/omap: add framedone interrupt support drm/omap: add support for manually updated displays drivers/gpu/drm/omapdrm/omap_crtc.c | 182 ++-- drivers/gpu/drm/omapdrm/omap_crtc.h | 2 + drivers/gpu/drm/omapdrm/omap_drv.h | 4 +- drivers/gpu/drm/omapdrm/omap_fb.c | 19 +++ drivers/gpu/drm/omapdrm/omap_irq.c | 25 drivers/gpu/drm/omapdrm/omap_irq.h | 1 + 6 files changed, 222 insertions(+), 11 deletions(-) -- 2.20.1
[PATCHv6 1/4] drm/omap: use DRM_DEBUG_DRIVER instead of CORE
This macro is only used by omapdrm, which should print debug messages using the DRIVER category instead of the default CORE category. Acked-by: Pavel Machek Tested-by: Tony Lindgren Tested-by: Pavel Machek Signed-off-by: Sebastian Reichel --- drivers/gpu/drm/omapdrm/omap_drv.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h b/drivers/gpu/drm/omapdrm/omap_drv.h index 3cca45cb25f3..896aa12f09b2 100644 --- a/drivers/gpu/drm/omapdrm/omap_drv.h +++ b/drivers/gpu/drm/omapdrm/omap_drv.h @@ -37,8 +37,8 @@ #include "omap_irq.h" #include "omap_plane.h" -#define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__) -#define VERB(fmt, ...) if (0) DRM_DEBUG(fmt, ##__VA_ARGS__) /* verbose debug */ +#define DBG(fmt, ...) DRM_DEBUG_DRIVER(fmt"\n", ##__VA_ARGS__) +#define VERB(fmt, ...) if (0) DRM_DEBUG_DRIVER(fmt, ##__VA_ARGS__) /* verbose debug */ #define MODULE_NAME "omapdrm" -- 2.20.1
[PATCHv6 3/4] drm/omap: add framedone interrupt support
This prepares framedone interrupt handling for
manual display update support.
Acked-by: Pavel Machek
Tested-by: Tony Lindgren
Tested-by: Pavel Machek
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 50 +
drivers/gpu/drm/omapdrm/omap_crtc.h | 1 +
drivers/gpu/drm/omapdrm/omap_irq.c | 25 +++
drivers/gpu/drm/omapdrm/omap_irq.h | 1 +
4 files changed, 77 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 86827a061b0b..68697820d189 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -51,6 +51,9 @@ struct omap_crtc {
bool pending;
wait_queue_head_t pending_wait;
struct drm_pending_vblank_event *event;
+
+ void (*framedone_handler)(void *);
+ void *framedone_handler_data;
};
/*
-
@@ -230,6 +233,18 @@ static int omap_crtc_dss_register_framedone(
struct omap_drm_private *priv, enum omap_channel channel,
void (*handler)(void *), void *data)
{
+ struct drm_crtc *crtc = priv->channels[channel]->crtc;
+ struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+ struct drm_device *dev = omap_crtc->base.dev;
+
+ if (omap_crtc->framedone_handler)
+ return -EBUSY;
+
+ dev_dbg(dev->dev, "register framedone %s", omap_crtc->name);
+
+ omap_crtc->framedone_handler = handler;
+ omap_crtc->framedone_handler_data = data;
+
return 0;
}
@@ -237,6 +252,17 @@ static void omap_crtc_dss_unregister_framedone(
struct omap_drm_private *priv, enum omap_channel channel,
void (*handler)(void *), void *data)
{
+ struct drm_crtc *crtc = priv->channels[channel]->crtc;
+ struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+ struct drm_device *dev = omap_crtc->base.dev;
+
+ dev_dbg(dev->dev, "unregister framedone %s", omap_crtc->name);
+
+ WARN_ON(omap_crtc->framedone_handler != handler);
+ WARN_ON(omap_crtc->framedone_handler_data != data);
+
+ omap_crtc->framedone_handler = NULL;
+ omap_crtc->framedone_handler_data = NULL;
}
static const struct dss_mgr_ops mgr_ops = {
@@ -302,6 +328,30 @@ void omap_crtc_vblank_irq(struct drm_crtc *crtc)
DBG("%s: apply done", omap_crtc->name);
}
+void omap_crtc_framedone_irq(struct drm_crtc *crtc, uint32_t irqstatus)
+{
+ struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+
+ if (!omap_crtc->framedone_handler) {
+ dev_warn(omap_crtc->base.dev->dev, "no framedone handler?");
+ return;
+ }
+
+ omap_crtc->framedone_handler(omap_crtc->framedone_handler_data);
+
+ spin_lock(>dev->event_lock);
+ /* Send the vblank event if one has been requested. */
+ if (omap_crtc->event) {
+ drm_crtc_send_vblank_event(crtc, omap_crtc->event);
+ omap_crtc->event = NULL;
+ }
+ omap_crtc->pending = false;
+ spin_unlock(>dev->event_lock);
+
+ /* Wake up omap_atomic_complete. */
+ wake_up(_crtc->pending_wait);
+}
+
static void omap_crtc_write_crtc_properties(struct drm_crtc *crtc)
{
struct omap_drm_private *priv = crtc->dev->dev_private;
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.h
b/drivers/gpu/drm/omapdrm/omap_crtc.h
index d9de437ba9dd..d33bbb7a4f90 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.h
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.h
@@ -41,5 +41,6 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
int omap_crtc_wait_pending(struct drm_crtc *crtc);
void omap_crtc_error_irq(struct drm_crtc *crtc, u32 irqstatus);
void omap_crtc_vblank_irq(struct drm_crtc *crtc);
+void omap_crtc_framedone_irq(struct drm_crtc *crtc, uint32_t irqstatus);
#endif /* __OMAPDRM_CRTC_H__ */
diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c
b/drivers/gpu/drm/omapdrm/omap_irq.c
index 329ad26d6d50..01dda84ca2ee 100644
--- a/drivers/gpu/drm/omapdrm/omap_irq.c
+++ b/drivers/gpu/drm/omapdrm/omap_irq.c
@@ -85,6 +85,28 @@ int omap_irq_wait(struct drm_device *dev, struct
omap_irq_wait *wait,
return ret == 0 ? -1 : 0;
}
+int omap_irq_enable_framedone(struct drm_crtc *crtc, bool enable)
+{
+ struct drm_device *dev = crtc->dev;
+ struct omap_drm_private *priv = dev->dev_private;
+ unsigned long flags;
+ enum omap_channel channel = omap_crtc_channel(crtc);
+ int framedone_irq =
+ priv->dispc_ops->mgr_get_framedone_irq(priv->dispc, channel);
+
+ DBG("dev=%p, crtc=%u, enable=%d", dev, channel, enable);
+
+ spin_lock_irqsave(>wait_lock, flags);
+ if (enable)
+ priv->irq_mask |= framedone_irq;
+ else
+ priv->irq_mask &= ~framedone_irq;
+ omap_irq_update(dev);
+ spin_unlock_irqrestore(>wait_lock, flags);
+
+ return 0;
+}
+
[Bug 110712] [regression]Raven Ridge: System freeze but mouse cursor able to move when using Firefox Webrender.
https://bugs.freedesktop.org/show_bug.cgi?id=110712 --- Comment #1 from Haxk20 --- Im have not been able to get dmesg in the past few days and will not be able to get one in upcoming few days but hopefully i will be able to get one by the end of the month. If somebody could post dmesg in the mean time that would be fantastic. And if we could get somebody to look at this it would be even more awesome. -- 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 v10 03/11] drm/sun4i: dsi: Fix video start delay computation
On Mon, May 20, 2019 at 02:33:10PM +0530, Jagan Teki wrote: > The current code is computing vertical video start delay as > > delay = mode->vtotal - (mode->vsync_end - mode->vdisplay) + start; > > On which the second parameter > > mode->vsync_end - mode->vdisplay = front porch + sync timings > > according to "DRM kernel-internal display mode structure" in > include/drm/drm_modes.h > > With adding additional sync timings, the desired video start delay > value as 510 for "bananapi,s070wv20-ct16" panel timings which indeed > trigger panel flip_done timed out as: > > WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 > drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 > [CRTC:46:crtc-0] vblank wait timed out > Modules linked in: > CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted > 5.1.0-next-20190514-00029-g09e5b0ed0a58 #18 > Hardware name: Allwinner sun8i Family > Workqueue: events deferred_probe_work_func > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [] (show_stack) from [] (dump_stack+0x84/0x98) > [] (dump_stack) from [] (__warn+0xfc/0x114) > [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) > [] (warn_slowpath_fmt) from [] > (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) > [] (drm_atomic_helper_wait_for_vblanks.part.1) from [] > (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) > [] (drm_atomic_helper_commit_tail_rpm) from [] > (commit_tail+0x40/0x6c) > [] (commit_tail) from [] > (drm_atomic_helper_commit+0xbc/0x128) > [] (drm_atomic_helper_commit) from [] > (restore_fbdev_mode_atomic+0x1cc/0x1dc) > [] (restore_fbdev_mode_atomic) from [] > (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) > [] (drm_fb_helper_restore_fbdev_mode_unlocked) from [] > (drm_fb_helper_set_par+0x30/0x54) > [] (drm_fb_helper_set_par) from [] > (fbcon_init+0x560/0x5ac) > [] (fbcon_init) from [] (visual_init+0xbc/0x104) > [] (visual_init) from [] (do_bind_con_driver+0x1b0/0x390) > [] (do_bind_con_driver) from [] > (do_take_over_console+0x13c/0x1c4) > [] (do_take_over_console) from [] > (do_fbcon_takeover+0x74/0xcc) > [] (do_fbcon_takeover) from [] > (notifier_call_chain+0x44/0x84) > [] (notifier_call_chain) from [] > (__blocking_notifier_call_chain+0x48/0x60) > [] (__blocking_notifier_call_chain) from [] > (blocking_notifier_call_chain+0x18/0x20) > [] (blocking_notifier_call_chain) from [] > (register_framebuffer+0x1e0/0x2f8) > [] (register_framebuffer) from [] > (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) > [] (__drm_fb_helper_initial_config_and_unlock) from [] > (drm_fbdev_client_hotplug+0xe8/0x1b8) > [] (drm_fbdev_client_hotplug) from [] > (drm_fbdev_generic_setup+0x88/0x118) > [] (drm_fbdev_generic_setup) from [] > (sun4i_drv_bind+0x128/0x160) > [] (sun4i_drv_bind) from [] > (try_to_bring_up_master+0x164/0x1a0) > [] (try_to_bring_up_master) from [] > (__component_add+0x94/0x140) > [] (__component_add) from [] > (sun6i_dsi_probe+0x144/0x234) > [] (sun6i_dsi_probe) from [] > (platform_drv_probe+0x48/0x9c) > [] (platform_drv_probe) from [] > (really_probe+0x1dc/0x2c8) > [] (really_probe) from [] > (driver_probe_device+0x60/0x160) > [] (driver_probe_device) from [] > (bus_for_each_drv+0x74/0xb8) > [] (bus_for_each_drv) from [] > (__device_attach+0xd0/0x13c) > [] (__device_attach) from [] (bus_probe_device+0x84/0x8c) > [] (bus_probe_device) from [] > (deferred_probe_work_func+0x64/0x90) > [] (deferred_probe_work_func) from [] > (process_one_work+0x204/0x420) > [] (process_one_work) from [] (worker_thread+0x274/0x5a0) > [] (worker_thread) from [] (kthread+0x11c/0x14c) > [] (kthread) from [] (ret_from_fork+0x14/0x2c) > Exception stack(0xde539fb0 to 0xde539ff8) > 9fa0: > 9fc0: > 9fe0: 0013 > ---[ end trace 495200a78b24980e ]--- > random: fast init done > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:46:crtc-0] > flip_done timed out > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:48:DSI-1] > flip_done timed out > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:30:plane-0] > flip_done timed out > > But the expected video start delay value is 513 which states that > the second parameter on the computation is "front porch" value > (no sync timings included). > > This is clearly confirmed from the legacy [1] and new [2] bsp codes > that the second parameter on the video start delay is "front porch" > > Here is the detailed evidence for calculating front porch as per > bsp code. > > vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp > => (panel->lcd_vt) - panel->lcd_y - panel->lcd_vbp > => (tt->ver_front_porch + lcdp->panel_info.lcd_vbp > + lcdp->panel_info.lcd_y) - panel->lcd_y - panel->lcd_vbp > => tt->ver_front_porch The comment on patch 1 still applies on this
Re: [PATCH v2 3/6] drm/msm/a6xx: Check for ERR or NULL before iounmap
On Thu, May 23, 2019 at 01:16:42PM -0400, Sean Paul wrote: > From: Sean Paul > > pdcptr and seqptr aren't necessarily valid, check them before trying to > unmap them. > > Changes in v2: > - None > > Cc: Jordan Crouse > Signed-off-by: Sean Paul It has always been sad to me that iounmap() has chosen to not check for NULL. Reviewed-by: Jordan Crouse > --- > drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > index 742c8ff9a61c..7465423e9b71 100644 > --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > @@ -504,8 +504,10 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu) > wmb(); > > err: > - devm_iounmap(gmu->dev, pdcptr); > - devm_iounmap(gmu->dev, seqptr); > + if (!IS_ERR_OR_NULL(pdcptr)) > + devm_iounmap(gmu->dev, pdcptr); > + if (!IS_ERR_OR_NULL(seqptr)) > + devm_iounmap(gmu->dev, seqptr); > } > > /* > -- > Sean Paul, Software Engineer, Google / Chromium OS > -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 04/11] drm/sun4i: tcon: Compute DCLK dividers based on format, lanes
On Mon, May 20, 2019 at 02:33:11PM +0530, Jagan Teki wrote: > pll-video => pll-mipi => tcon0 => tcon0-pixel-clock is the typical > MIPI clock topology in Allwinner DSI controller. > > TCON dotclock driver is computing the desired DCLK divider based on > panel pixel clock along with input DCLK min, max divider values from > tcon driver and that would eventually set the pll-mipi clock rate. > > The current code is passing dsi min and max divider value as 4 via > tcon driver which would ended-up triggering below vblank wait timed out > warning on "bananapi,s070wv20-ct16" panel. > > WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 > drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 > [CRTC:46:crtc-0] vblank wait timed out > Modules linked in: > CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted > 5.1.0-next-20190514-00025-g5186cdf10757-dirty #6 > Hardware name: Allwinner sun8i Family > Workqueue: events deferred_probe_work_func > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [] (show_stack) from [] (dump_stack+0x84/0x98) > [] (dump_stack) from [] (__warn+0xfc/0x114) > [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) > [] (warn_slowpath_fmt) from [] > (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) > [] (drm_atomic_helper_wait_for_vblanks.part.1) from [] > (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) > [] (drm_atomic_helper_commit_tail_rpm) from [] > (commit_tail+0x40/0x6c) > [] (commit_tail) from [] > (drm_atomic_helper_commit+0xbc/0x128) > [] (drm_atomic_helper_commit) from [] > (restore_fbdev_mode_atomic+0x1cc/0x1dc) > [] (restore_fbdev_mode_atomic) from [] > (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) > [] (drm_fb_helper_restore_fbdev_mode_unlocked) from [] > (drm_fb_helper_set_par+0x30/0x54) > [] (drm_fb_helper_set_par) from [] > (fbcon_init+0x560/0x5ac) > [] (fbcon_init) from [] (visual_init+0xbc/0x104) > [] (visual_init) from [] (do_bind_con_driver+0x1b0/0x390) > [] (do_bind_con_driver) from [] > (do_take_over_console+0x13c/0x1c4) > [] (do_take_over_console) from [] > (do_fbcon_takeover+0x74/0xcc) > [] (do_fbcon_takeover) from [] > (notifier_call_chain+0x44/0x84) > [] (notifier_call_chain) from [] > (__blocking_notifier_call_chain+0x48/0x60) > [] (__blocking_notifier_call_chain) from [] > (blocking_notifier_call_chain+0x18/0x20) > [] (blocking_notifier_call_chain) from [] > (register_framebuffer+0x1e0/0x2f8) > [] (register_framebuffer) from [] > (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) > [] (__drm_fb_helper_initial_config_and_unlock) from [] > (drm_fbdev_client_hotplug+0xe8/0x1b8) > [] (drm_fbdev_client_hotplug) from [] > (drm_fbdev_generic_setup+0x88/0x118) > [] (drm_fbdev_generic_setup) from [] > (sun4i_drv_bind+0x128/0x160) > [] (sun4i_drv_bind) from [] > (try_to_bring_up_master+0x164/0x1a0) > [] (try_to_bring_up_master) from [] > (__component_add+0x94/0x140) > [] (__component_add) from [] > (sun6i_dsi_probe+0x144/0x234) > [] (sun6i_dsi_probe) from [] > (platform_drv_probe+0x48/0x9c) > [] (platform_drv_probe) from [] > (really_probe+0x1dc/0x2c8) > [] (really_probe) from [] > (driver_probe_device+0x60/0x160) > [] (driver_probe_device) from [] > (bus_for_each_drv+0x74/0xb8) > [] (bus_for_each_drv) from [] > (__device_attach+0xd0/0x13c) > [] (__device_attach) from [] (bus_probe_device+0x84/0x8c) > [] (bus_probe_device) from [] > (deferred_probe_work_func+0x64/0x90) > [] (deferred_probe_work_func) from [] > (process_one_work+0x204/0x420) > [] (process_one_work) from [] (worker_thread+0x274/0x5a0) > [] (worker_thread) from [] (kthread+0x11c/0x14c) > [] (kthread) from [] (ret_from_fork+0x14/0x2c) > Exception stack(0xde539fb0 to 0xde539ff8) > 9fa0: > 9fc0: > 9fe0: 0013 > ---[ end trace 4017fea4906ab391 ]--- > > But accordingly to Allwinner A33, A64 BSP codes [1] [2] this divider > is clearly using 'format/lanes' for dsi divider value, dsi_clk.clk_div > > Which would compute the pll_freq and set a clock rate for it in > [3] and [4] respectively. > > The same issue has reproduced in A33, A64 with 4-lane and 2-lane devices > and got fixed with this computation logic 'format/lanes', so this patch > using dclk min and max dividers as per BSP. > > [1] > https://github.com/BPI-SINOVOIP/BPI-M2M-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp/de/disp_lcd.c#L1106 > [2] > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/disp_al.c#L213 > [3] > https://github.com/BPI-SINOVOIP/BPI-M2M-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp/de/disp_lcd.c#L1127 > [4] > https://github.com/BPI-SINOVOIP/BPI-M2M-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp/de/disp_lcd.c#L1161 In that mail, I've pointed out that
[Bug 110749] [Vega 11] [amdgpu retry page fault VM_L2_PROTECTION_FAULT_STATUS] System lock up during playing Steam version of Saints Row 3
https://bugs.freedesktop.org/show_bug.cgi?id=110749 Bug ID: 110749 Summary: [Vega 11] [amdgpu retry page fault VM_L2_PROTECTION_FAULT_STATUS] System lock up during playing Steam version of Saints Row 3 Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: blocker Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: ev...@hotmail.com Created attachment 144337 --> https://bugs.freedesktop.org/attachment.cgi?id=144337=edit contains files generated from output of dmesg, umr and "cat /sys/kernel/debug/tracing/trace" System hangs shortly (approximately few minutes) after starting playing Saints Row 3. Sound keeps playing but mouse et al doesn't work. Monitor turns itself off after few seconds. Logging in the system via SSH fails. Only magickal SysRq + REISUB command helps. -- 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 110701] GPU faults in in Unigine Valley 1.0
https://bugs.freedesktop.org/show_bug.cgi?id=110701 --- Comment #25 from Christoph Haag --- (In reply to Yury Zhuravlev from comment #24) > (In reply to Marek Olšák from comment #23) > > Fixed by d6053bf2a170a0fec6d232fda097d2f35f0e9eae. Closing. > > The original issue was about Vega and on Vega we saw a different problem. I > suppose before close issue somebody should check patch on Vega. > I will do it soon. Since nobody responded: On a Vega 64 I got GPU faults like the ones posted here followed by a GPU hang immediately when restoring a firefox (nightly) session. With mesa master this does not happen anymore. -- 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 v10 02/11] drm/sun4i: dsi: Update start value in video start delay
On Mon, May 20, 2019 at 02:33:09PM +0530, Jagan Teki wrote: > start value in video start delay computation done in below commit > is as per the legacy bsp drivers/video/sunxi/legacy.. > "drm/sun4i: dsi: Change the start delay calculation" > (sha1: da676c6aa6413d59ab0a80c97bbc273025e640b2) > > This existing start delay computation gives start value of 35, > for "bananapi,s070wv20-ct16" panel timings which indeed trigger > panel flip_done timed out as: > > WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 > drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 > [CRTC:46:crtc-0] vblank wait timed out > Modules linked in: > CPU: 0 PID: 31 Comm: kworker/0:1 Tainted: GW > 5.1.0-next-20190514-00025-gf928bc7cc146 #15 > Hardware name: Allwinner sun8i Family > Workqueue: events deferred_probe_work_func > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [] (show_stack) from [] (dump_stack+0x84/0x98) > [] (dump_stack) from [] (__warn+0xfc/0x114) > [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) > [] (warn_slowpath_fmt) from [] > (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) > [] (drm_atomic_helper_wait_for_vblanks.part.1) from [] > (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) > [] (drm_atomic_helper_commit_tail_rpm) from [] > (commit_tail+0x40/0x6c) > [] (commit_tail) from [] > (drm_atomic_helper_commit+0xbc/0x128) > [] (drm_atomic_helper_commit) from [] > (restore_fbdev_mode_atomic+0x1cc/0x1dc) > [] (restore_fbdev_mode_atomic) from [] > (drm_fb_helper_pan_display+0xac/0x1d0) > [] (drm_fb_helper_pan_display) from [] > (fb_pan_display+0xcc/0x134) > [] (fb_pan_display) from [] (bit_update_start+0x14/0x30) > [] (bit_update_start) from [] (fbcon_switch+0x3d8/0x4e0) > [] (fbcon_switch) from [] (redraw_screen+0x174/0x238) > [] (redraw_screen) from [] > (fbcon_prepare_logo+0x3c4/0x400) > [] (fbcon_prepare_logo) from [] (fbcon_init+0x3c8/0x5ac) > [] (fbcon_init) from [] (visual_init+0xbc/0x104) > [] (visual_init) from [] (do_bind_con_driver+0x1b0/0x390) > [] (do_bind_con_driver) from [] > (do_take_over_console+0x13c/0x1c4) > [] (do_take_over_console) from [] > (do_fbcon_takeover+0x74/0xcc) > [] (do_fbcon_takeover) from [] > (notifier_call_chain+0x44/0x84) > [] (notifier_call_chain) from [] > (__blocking_notifier_call_chain+0x48/0x60) > [] (__blocking_notifier_call_chain) from [] > (blocking_notifier_call_chain+0x18/0x20) > [] (blocking_notifier_call_chain) from [] > (register_framebuffer+0x1e0/0x2f8) > [] (register_framebuffer) from [] > (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) > [] (__drm_fb_helper_initial_config_and_unlock) from [] > (drm_fbdev_client_hotplug+0xe8/0x1b8) > [] (drm_fbdev_client_hotplug) from [] > (drm_fbdev_generic_setup+0x88/0x118) > [] (drm_fbdev_generic_setup) from [] > (sun4i_drv_bind+0x128/0x160) > [] (sun4i_drv_bind) from [] > (try_to_bring_up_master+0x164/0x1a0) > [] (try_to_bring_up_master) from [] > (__component_add+0x94/0x140) > [] (__component_add) from [] > (sun6i_dsi_probe+0x144/0x234) > [] (sun6i_dsi_probe) from [] > (platform_drv_probe+0x48/0x9c) > [] (platform_drv_probe) from [] > (really_probe+0x1dc/0x2c8) > [] (really_probe) from [] > (driver_probe_device+0x60/0x160) > [] (driver_probe_device) from [] > (bus_for_each_drv+0x74/0xb8) > [] (bus_for_each_drv) from [] > (__device_attach+0xd0/0x13c) > [] (__device_attach) from [] (bus_probe_device+0x84/0x8c) > [] (bus_probe_device) from [] > (deferred_probe_work_func+0x64/0x90) > [] (deferred_probe_work_func) from [] > (process_one_work+0x204/0x420) > [] (process_one_work) from [] (worker_thread+0x274/0x5a0) > [] (worker_thread) from [] (kthread+0x11c/0x14c) > [] (kthread) from [] (ret_from_fork+0x14/0x2c) > Exception stack(0xde539fb0 to 0xde539ff8) > 9fa0: > 9fc0: > 9fe0: 0013 > ---[ end trace 755e10f62b83f396 ]--- > Console: switching to colour frame buffer device 100x30 > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:46:crtc-0] > flip_done timed out > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:48:DSI-1] > flip_done timed out > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:30:plane-0] > flip_done timed out > > But the expected start delay value is 1 which is confirmed from > new bsp [2]. If you're saying that the "legacy" link (second one) is the new BSP. > The important and unclear note on legacy and new bsp codes [1] [2] > is both use similar start computation initially but it later reassign > it to 1 in new bsp. Then start_delay is never reassigned to 1 in that link, and is clamped between 8 and 100 as the code that you are removing is doing. > Unfortunately we don't have any evidence or documentation for this > reassignment to 1 in new bsp,
[Bug 110749] [Vega 11] [amdgpu retry page fault VM_L2_PROTECTION_FAULT_STATUS] System lock up during playing Steam version of Saints Row 3
https://bugs.freedesktop.org/show_bug.cgi?id=110749 Cyrax changed: What|Removed |Added Priority|medium |highest -- 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/mst: Fix MST sideband up-reply failure handling
Patch mostly looks good to me, one comment below
On Fri, 2019-05-24 at 00:24 +0300, Imre Deak wrote:
> Fix the breakage resulting in the stacktrace below, due to tx queue
> being full when trying to send an up-reply. txmsg->seqno is -1 in this
> case leading to a corruption of the mstb object by
>
> txmsg->dst->tx_slots[txmsg->seqno] = NULL;
>
> in process_single_up_tx_qlock().
>
> [ +0,005162] [drm:process_single_tx_qlock [drm_kms_helper]]
> set_hdr_from_dst_qlock: failed to find slot
> [ +0,15] [drm:drm_dp_send_up_ack_reply.constprop.19 [drm_kms_helper]]
> failed to send msg in q -11
> [ +0,000939] BUG: kernel NULL pointer dereference, address:
> 05a0
> [ +0,006982] #PF: supervisor write access in kernel mode
> [ +0,005223] #PF: error_code(0x0002) - not-present page
> [ +0,005135] PGD 0 P4D 0
> [ +0,002581] Oops: 0002 [#1] PREEMPT SMP NOPTI
> [ +0,004359] CPU: 1 PID: 1200 Comm: kworker/u16:3 Tainted:
> G U5.2.0-rc1+ #410
> [ +0,008433] Hardware name: Intel Corporation Ice Lake Client
> Platform/IceLake U DDR4 SODIMM PD RVP, BIOS ICLSFWR1.R00.3175.A00.1904261428
> 04/26/2019
> [ +0,013323] Workqueue: i915-dp i915_digport_work_func [i915]
> [ +0,005676] RIP: 0010:queue_work_on+0x19/0x70
> [ +0,004372] Code: ff ff ff 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 41 56
> 49 89 f6 41 55 41 89 fd 41 54 55 53 48 89 d3 9c 5d fa e8 e7 81 0c 00 48
> 0f ba 2b 00 73 31 45 31 e4 f7 c5 00 02 00 00 74 13 e8 cf 7f
> [ +0,018750] RSP: 0018:c97dfc50 EFLAGS: 00010006
> [ +0,005222] RAX: 0046 RBX: 05a0 RCX:
> 0001
> [ +0,007133] RDX: 0001b608 RSI: RDI:
> 82121972
> [ +0,007129] RBP: 0202 R08: R09:
> 0001
> [ +0,007129] R10: R11: R12:
> 88847bfa5096
> [ +0,007131] R13: 0010 R14: 88849c08f3f8 R15:
>
> [ +0,007128] FS: () GS:88849dc8()
> knlGS:
> [ +0,008083] CS: 0010 DS: ES: CR0: 80050033
> [ +0,005749] CR2: 05a0 CR3: 05210006 CR4:
> 00760ee0
> [ +0,007128] PKRU: 5554
> [ +0,002722] Call Trace:
> [ +0,002458] drm_dp_mst_handle_up_req+0x517/0x540 [drm_kms_helper]
> [ +0,006197] ? drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
> [ +0,005764] drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
> [ +0,005623] ? intel_dp_hpd_pulse+0x205/0x370 [i915]
> [ +0,005018] intel_dp_hpd_pulse+0x205/0x370 [i915]
> [ +0,004836] i915_digport_work_func+0xbb/0x140 [i915]
> [ +0,005108] process_one_work+0x245/0x610
> [ +0,004027] worker_thread+0x37/0x380
> [ +0,003684] ? process_one_work+0x610/0x610
> [ +0,004184] kthread+0x119/0x130
> [ +0,003240] ? kthread_park+0x80/0x80
> [ +0,003668] ret_from_fork+0x24/0x50
>
> Cc: Lyude Paul
> Cc: Dave Airlie
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index da1abca1b9e9..24c325f4a616 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -1996,7 +1996,11 @@ static void process_single_up_tx_qlock(struct
> drm_dp_mst_topology_mgr *mgr,
> if (ret != 1)
> DRM_DEBUG_KMS("failed to send msg in q %d\n", ret);
>
> - txmsg->dst->tx_slots[txmsg->seqno] = NULL;
> + if (txmsg->seqno != -1) {
> + WARN_ON((unsigned)txmsg->seqno >
> + ARRAY_SIZE(txmsg->dst->tx_slots));
Not 100% sure on this nitpick myself but, if we know that txmsg->seqno is
about to go out of bounds shouldn't we also try to take action to stop it?
like
if (!WARN_ON((unsigned)txmsg->seqno > ARRAY_SIZE(txmsg->dst->tx_slots)))
txmsg->dst->tx_slots[txmsg->seqno] = NULL;
> + txmsg->dst->tx_slots[txmsg->seqno] = NULL;
> + }
> }
>
> static void drm_dp_queue_down_tx(struct drm_dp_mst_topology_mgr *mgr,
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mst: Fix MST sideband up-reply failure handling
On Fri, 2019-05-24 at 01:28 +0300, Imre Deak wrote:
> On Thu, May 23, 2019 at 06:09:56PM -0400, Lyude Paul wrote:
> > Patch mostly looks good to me, one comment below
> >
> > On Fri, 2019-05-24 at 00:24 +0300, Imre Deak wrote:
> > > Fix the breakage resulting in the stacktrace below, due to tx queue
> > > being full when trying to send an up-reply. txmsg->seqno is -1 in this
> > > case leading to a corruption of the mstb object by
> > >
> > > txmsg->dst->tx_slots[txmsg->seqno] = NULL;
> > >
> > > in process_single_up_tx_qlock().
> > >
> > > [ +0,005162] [drm:process_single_tx_qlock [drm_kms_helper]]
> > > set_hdr_from_dst_qlock: failed to find slot
> > > [ +0,15] [drm:drm_dp_send_up_ack_reply.constprop.19
> > > [drm_kms_helper]]
> > > failed to send msg in q -11
> > > [ +0,000939] BUG: kernel NULL pointer dereference, address:
> > > 05a0
> > > [ +0,006982] #PF: supervisor write access in kernel mode
> > > [ +0,005223] #PF: error_code(0x0002) - not-present page
> > > [ +0,005135] PGD 0 P4D 0
> > > [ +0,002581] Oops: 0002 [#1] PREEMPT SMP NOPTI
> > > [ +0,004359] CPU: 1 PID: 1200 Comm: kworker/u16:3 Tainted:
> > > G U5.2.0-rc1+ #410
> > > [ +0,008433] Hardware name: Intel Corporation Ice Lake Client
> > > Platform/IceLake U DDR4 SODIMM PD RVP, BIOS
> > > ICLSFWR1.R00.3175.A00.1904261428
> > > 04/26/2019
> > > [ +0,013323] Workqueue: i915-dp i915_digport_work_func [i915]
> > > [ +0,005676] RIP: 0010:queue_work_on+0x19/0x70
> > > [ +0,004372] Code: ff ff ff 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00
> > > 41 56
> > > 49 89 f6 41 55 41 89 fd 41 54 55 53 48 89 d3 9c 5d fa e8 e7 81 0c 00
> > > 48
> > > 0f ba 2b 00 73 31 45 31 e4 f7 c5 00 02 00 00 74 13 e8 cf 7f
> > > [ +0,018750] RSP: 0018:c97dfc50 EFLAGS: 00010006
> > > [ +0,005222] RAX: 0046 RBX: 05a0 RCX:
> > > 0001
> > > [ +0,007133] RDX: 0001b608 RSI: RDI:
> > > 82121972
> > > [ +0,007129] RBP: 0202 R08: R09:
> > > 0001
> > > [ +0,007129] R10: R11: R12:
> > > 88847bfa5096
> > > [ +0,007131] R13: 0010 R14: 88849c08f3f8 R15:
> > >
> > > [ +0,007128] FS: () GS:88849dc8()
> > > knlGS:
> > > [ +0,008083] CS: 0010 DS: ES: CR0: 80050033
> > > [ +0,005749] CR2: 05a0 CR3: 05210006 CR4:
> > > 00760ee0
> > > [ +0,007128] PKRU: 5554
> > > [ +0,002722] Call Trace:
> > > [ +0,002458] drm_dp_mst_handle_up_req+0x517/0x540 [drm_kms_helper]
> > > [ +0,006197] ? drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
> > > [ +0,005764] drm_dp_mst_hpd_irq+0x5b/0x9c0 [drm_kms_helper]
> > > [ +0,005623] ? intel_dp_hpd_pulse+0x205/0x370 [i915]
> > > [ +0,005018] intel_dp_hpd_pulse+0x205/0x370 [i915]
> > > [ +0,004836] i915_digport_work_func+0xbb/0x140 [i915]
> > > [ +0,005108] process_one_work+0x245/0x610
> > > [ +0,004027] worker_thread+0x37/0x380
> > > [ +0,003684] ? process_one_work+0x610/0x610
> > > [ +0,004184] kthread+0x119/0x130
> > > [ +0,003240] ? kthread_park+0x80/0x80
> > > [ +0,003668] ret_from_fork+0x24/0x50
> > >
> > > Cc: Lyude Paul
> > > Cc: Dave Airlie
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/gpu/drm/drm_dp_mst_topology.c | 6 +-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > index da1abca1b9e9..24c325f4a616 100644
> > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > @@ -1996,7 +1996,11 @@ static void process_single_up_tx_qlock(struct
> > > drm_dp_mst_topology_mgr *mgr,
> > > if (ret != 1)
> > > DRM_DEBUG_KMS("failed to send msg in q %d\n", ret);
> > >
> > > - txmsg->dst->tx_slots[txmsg->seqno] = NULL;
> > > + if (txmsg->seqno != -1) {
> > > + WARN_ON((unsigned)txmsg->seqno >
> > > + ARRAY_SIZE(txmsg->dst->tx_slots));
> >
> > Not 100% sure on this nitpick myself but, if we know that txmsg->seqno is
> > about to go out of bounds shouldn't we also try to take action to stop it?
> > like
>
> Imo, it's worth keeping thins simple. If the WARN triggers we need to
> fix the original issue in any case (txmsg->seqno never should be set to
> anything else than -1 or a valid idx) so making the assignment here
> conditional wouldn't have a real purpose.
mm, fair enough. Then:
Reviewed-by: Lyude Paul
Thanks for the fix!
>
> > if (!WARN_ON((unsigned)txmsg->seqno > ARRAY_SIZE(txmsg->dst->tx_slots)))
> > txmsg->dst->tx_slots[txmsg->seqno] = NULL;
> >
> >
> >
> > > + txmsg->dst->tx_slots[txmsg->seqno] = NULL;
> > > + }
> > > }
> > >
> > > static void drm_dp_queue_down_tx(struct drm_dp_mst_topology_mgr *mgr,
> > --
> > Cheers,
> > Lyude Paul
> >
--
[PATCHv6 2/4] drm/omap: don't check dispc timings for DSI
While most display types only forward their VM to the DISPC, this
is not true for DSI. DSI calculates the VM for DISPC based on its
own, but it's not identical. Actually the DSI VM is not even a valid
DISPC VM making this check fail. Let's restore the old behaviour
and avoid checking the DISPC VM for DSI here.
Fixes: 7c27fa57ef31 ("drm/omap: Call dispc timings check operation directly")
Acked-by: Pavel Machek
Tested-by: Tony Lindgren
Tested-by: Pavel Machek
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 5a29bf01c0e8..86827a061b0b 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -395,10 +395,20 @@ static enum drm_mode_status omap_crtc_mode_valid(struct
drm_crtc *crtc,
int r;
drm_display_mode_to_videomode(mode, );
- r = priv->dispc_ops->mgr_check_timings(priv->dispc, omap_crtc->channel,
- );
- if (r)
- return r;
+
+ /*
+* DSI might not call this, since the supplied mode is not a
+* valid DISPC mode. DSI will calculate and configure the
+* proper DISPC mode later.
+*/
+ if (omap_crtc->pipe->output->next == NULL ||
+ omap_crtc->pipe->output->next->type != OMAP_DISPLAY_TYPE_DSI) {
+ r = priv->dispc_ops->mgr_check_timings(priv->dispc,
+ omap_crtc->channel,
+ );
+ if (r)
+ return r;
+ }
/* Check for bandwidth limit */
if (priv->max_bandwidth) {
--
2.20.1
Re: [PATCHv6 1/4] drm/omap: use DRM_DEBUG_DRIVER instead of CORE
On Thu, 2019-05-23 at 22:07 +0200, Sebastian Reichel wrote:
> This macro is only used by omapdrm, which should print
> debug messages using the DRIVER category instead of the
> default CORE category.
[]
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h
> b/drivers/gpu/drm/omapdrm/omap_drv.h
[]
> @@ -37,8 +37,8 @@
> #include "omap_irq.h"
> #include "omap_plane.h"
>
> -#define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
> -#define VERB(fmt, ...) if (0) DRM_DEBUG(fmt, ##__VA_ARGS__) /* verbose debug
> */
> +#define DBG(fmt, ...) DRM_DEBUG_DRIVER(fmt"\n", ##__VA_ARGS__)
> +#define VERB(fmt, ...) if (0) DRM_DEBUG_DRIVER(fmt, ##__VA_ARGS__) /*
> verbose debug */
Trivia:
Strictly, this should use do { if (0) etc... } while (0)
Also, none of the VERB uses have a terminating newline
so ideally, this should be:
#define VERB(fmt, ...) do { if (0) DRM_DEBUG_DRIVER(fmt "\n", ##__VA_ARGS__); }
while (0) /* verbose debug */
And VERB isn't a particularly intelligible macro name.
Maybe VDBG instead.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 01/11] drm/sun4i: dsi: Fix TCON DRQ set bits
On Mon, May 20, 2019 at 02:33:08PM +0530, Jagan Teki wrote: > According to "DRM kernel-internal display mode structure" in > include/drm/drm_modes.h the current driver is trying to include > sync timings along with front porch value while checking and > computing drq set bits in non-burst mode. > > mode->hsync_end - mode->hdisplay => horizontal front porch + sync > > With adding additional sync timings, the dsi controller leads to > wrong drq set bits for "bananapi,s070wv20-ct16" panel which indeed > trigger panel flip_done timed out as: > > WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 > drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 > [CRTC:46:crtc-0] vblank wait timed out > Modules linked in: > CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted > 5.1.0-next-20190514-00026-g01f0c75b902d-dirty #13 > Hardware name: Allwinner sun8i Family > Workqueue: events deferred_probe_work_func > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [] (show_stack) from [] (dump_stack+0x84/0x98) > [] (dump_stack) from [] (__warn+0xfc/0x114) > [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) > [] (warn_slowpath_fmt) from [] > (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) > [] (drm_atomic_helper_wait_for_vblanks.part.1) from [] > (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) > [] (drm_atomic_helper_commit_tail_rpm) from [] > (commit_tail+0x40/0x6c) > [] (commit_tail) from [] > (drm_atomic_helper_commit+0xbc/0x128) > [] (drm_atomic_helper_commit) from [] > (restore_fbdev_mode_atomic+0x1cc/0x1dc) > [] (restore_fbdev_mode_atomic) from [] > (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) > [] (drm_fb_helper_restore_fbdev_mode_unlocked) from [] > (drm_fb_helper_set_par+0x30/0x54) > [] (drm_fb_helper_set_par) from [] > (fbcon_init+0x560/0x5ac) > [] (fbcon_init) from [] (visual_init+0xbc/0x104) > [] (visual_init) from [] (do_bind_con_driver+0x1b0/0x390) > [] (do_bind_con_driver) from [] > (do_take_over_console+0x13c/0x1c4) > [] (do_take_over_console) from [] > (do_fbcon_takeover+0x74/0xcc) > [] (do_fbcon_takeover) from [] > (notifier_call_chain+0x44/0x84) > [] (notifier_call_chain) from [] > (__blocking_notifier_call_chain+0x48/0x60) > [] (__blocking_notifier_call_chain) from [] > (blocking_notifier_call_chain+0x18/0x20) > [] (blocking_notifier_call_chain) from [] > (register_framebuffer+0x1e0/0x2f8) > [] (register_framebuffer) from [] > (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) > [] (__drm_fb_helper_initial_config_and_unlock) from [] > (drm_fbdev_client_hotplug+0xe8/0x1b8) > [] (drm_fbdev_client_hotplug) from [] > (drm_fbdev_generic_setup+0x88/0x118) > [] (drm_fbdev_generic_setup) from [] > (sun4i_drv_bind+0x128/0x160) > [] (sun4i_drv_bind) from [] > (try_to_bring_up_master+0x164/0x1a0) > [] (try_to_bring_up_master) from [] > (__component_add+0x94/0x140) > [] (__component_add) from [] > (sun6i_dsi_probe+0x144/0x234) > [] (sun6i_dsi_probe) from [] > (platform_drv_probe+0x48/0x9c) > [] (platform_drv_probe) from [] > (really_probe+0x1dc/0x2c8) > [] (really_probe) from [] > (driver_probe_device+0x60/0x160) > [] (driver_probe_device) from [] > (bus_for_each_drv+0x74/0xb8) > [] (bus_for_each_drv) from [] > (__device_attach+0xd0/0x13c) > [] (__device_attach) from [] (bus_probe_device+0x84/0x8c) > [] (bus_probe_device) from [] > (deferred_probe_work_func+0x64/0x90) > [] (deferred_probe_work_func) from [] > (process_one_work+0x204/0x420) > [] (process_one_work) from [] (worker_thread+0x274/0x5a0) > [] (worker_thread) from [] (kthread+0x11c/0x14c) > [] (kthread) from [] (ret_from_fork+0x14/0x2c) > Exception stack(0xde539fb0 to 0xde539ff8) > 9fa0: > 9fc0: > 9fe0: 0013 > ---[ end trace b57eb1e5c64c6b8b ]--- > random: fast init done > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:46:crtc-0] > flip_done timed out > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:48:DSI-1] > flip_done timed out > [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:30:plane-0] > flip_done timed out > > But according to Allwinner A33, A64 BSP code [1] [3] the TCON DRQ for > non-burst DSI mode can be computed based on "horizontal front porch" > value only (no sync timings included). > > Detailed evidence for drq set bits based on A33 BSP [1] [2] > > => panel->lcd_ht - panel->lcd_x - panel->lcd_hbp - 20 > => (tt->hor_front_porch + lcdp->panel_info.lcd_hbp + > lcdp->panel_info.lcd_x) - panel->lcd_x - panel->lcd_hbp - 20 > => tt->hor_front_porch - 20 The thing is, while your explanation on the DRM side is sound, Allwinner has been using the hbp field of their panel description to store what DRM calls the backporch and the sync period. And nowhere in that commit log you are describing whether
Re: [PATCH v2 5/6] drm/msm/a6xx: Drop the device reference in gmu
On Thu, May 23, 2019 at 01:16:44PM -0400, Sean Paul wrote: > From: Sean Paul > > of_find_device_by_node() grabs a dev reference, so make sure we clear it > on error and remove. > > Changes in v2: > - Added to the set (Jordan) > > Cc: Jordan Crouse > Signed-off-by: Sean Paul Reviewed-by: Jordan Crouse > --- > drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 14 +++--- > 1 file changed, 11 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > index f7240c9e11fb..e2b839b5d3bd 100644 > --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c > @@ -1253,6 +1253,9 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu) > free_irq(gmu->gmu_irq, gmu); > free_irq(gmu->hfi_irq, gmu); > > + /* Drop reference taken in of_find_device_by_node */ > + put_device(gmu->dev); > + > gmu->initialized = false; > } > > @@ -1277,12 +1280,12 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct > device_node *node) > /* Get the list of clocks */ > ret = a6xx_gmu_clocks_probe(gmu); > if (ret) > - return ret; > + goto err_put_device; > > /* Set up the IOMMU context bank */ > ret = a6xx_gmu_memory_probe(gmu); > if (ret) > - return ret; > + goto err_put_device; > > /* Allocate memory for for the HFI queues */ > gmu->hfi = a6xx_gmu_memory_alloc(gmu, SZ_16K); > @@ -1334,6 +1337,11 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct > device_node *node) > > iommu_domain_free(gmu->domain); > } > + ret = -ENODEV; > > - return -ENODEV; > +err_put_device: > + /* Drop reference taken in of_find_device_by_node */ > + put_device(gmu->dev); > + > + return ret; > } > -- > Sean Paul, Software Engineer, Google / Chromium OS > -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/6] drm/msm/a6xx: Remove devm calls from gmu driver
On Thu, May 23, 2019 at 01:16:43PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> The gmu driver is initialized and cleaned up with calls from the gpu driver.
> As
> such, the platform device stays valid after a6xx_gmu_remove is called and the
> device managed resources are not freed. In the case of gpu probe failures or
> unbind, these resources will remain managed.
>
> If the gpu bind is run again (eg: if there's a probe defer somewhere in msm),
> these resources will be initialized again for the same device, creating
> multiple
> references. In the case of irqs, this causes failures since the irqs are
> not shared (nor should they be).
>
> This patch removes all devm_* calls and manually cleans things up in
> gmu_remove.
>
> Changes in v2:
> - Add iounmap and free_irq to gmu_probe error paths
>
> Cc: Jordan Crouse
> Signed-off-by: Sean Paul
As we discussed in IRC, I feel like the way we are probing and dealing with
the GMU device is messing up the reference counting. I had hoped that a
put_device() would do the trick but testing showed it didn't so there is clearly
remaining fail that we should eventually find and fix.
That said; there is really no reason to be using managed resources for this
device so this is an entirely appropriate patch.
Reviewed-by: Jordan Crouse
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 33 ++-
> 1 file changed, 22 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> index 7465423e9b71..f7240c9e11fb 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> @@ -505,9 +505,9 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu)
>
> err:
> if (!IS_ERR_OR_NULL(pdcptr))
> - devm_iounmap(gmu->dev, pdcptr);
> + iounmap(pdcptr);
> if (!IS_ERR_OR_NULL(seqptr))
> - devm_iounmap(gmu->dev, seqptr);
> + iounmap(seqptr);
> }
>
> /*
> @@ -1197,7 +1197,7 @@ static void __iomem *a6xx_gmu_get_mmio(struct
> platform_device *pdev,
> return ERR_PTR(-EINVAL);
> }
>
> - ret = devm_ioremap(>dev, res->start, resource_size(res));
> + ret = ioremap(res->start, resource_size(res));
> if (!ret) {
> DRM_DEV_ERROR(>dev, "Unable to map the %s registers\n",
> name);
> return ERR_PTR(-EINVAL);
> @@ -1213,10 +1213,10 @@ static int a6xx_gmu_get_irq(struct a6xx_gmu *gmu,
> struct platform_device *pdev,
>
> irq = platform_get_irq_byname(pdev, name);
>
> - ret = devm_request_irq(>dev, irq, handler, IRQF_TRIGGER_HIGH,
> - name, gmu);
> + ret = request_irq(irq, handler, IRQF_TRIGGER_HIGH, name, gmu);
> if (ret) {
> - DRM_DEV_ERROR(>dev, "Unable to get interrupt %s\n", name);
> + DRM_DEV_ERROR(>dev, "Unable to get interrupt %s %d\n",
> + name, ret);
> return ret;
> }
>
> @@ -1241,12 +1241,18 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
> dev_pm_domain_detach(gmu->gxpd, false);
> }
>
> + iounmap(gmu->mmio);
> + gmu->mmio = NULL;
> +
> a6xx_gmu_memory_free(gmu, gmu->hfi);
>
> iommu_detach_device(gmu->domain, gmu->dev);
>
> iommu_domain_free(gmu->domain);
>
> + free_irq(gmu->gmu_irq, gmu);
> + free_irq(gmu->hfi_irq, gmu);
> +
> gmu->initialized = false;
> }
>
> @@ -1281,24 +1287,24 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct
> device_node *node)
> /* Allocate memory for for the HFI queues */
> gmu->hfi = a6xx_gmu_memory_alloc(gmu, SZ_16K);
> if (IS_ERR(gmu->hfi))
> - goto err;
> + goto err_memory;
>
> /* Allocate memory for the GMU debug region */
> gmu->debug = a6xx_gmu_memory_alloc(gmu, SZ_16K);
> if (IS_ERR(gmu->debug))
> - goto err;
> + goto err_memory;
>
> /* Map the GMU registers */
> gmu->mmio = a6xx_gmu_get_mmio(pdev, "gmu");
> if (IS_ERR(gmu->mmio))
> - goto err;
> + goto err_memory;
>
> /* Get the HFI and GMU interrupts */
> gmu->hfi_irq = a6xx_gmu_get_irq(gmu, pdev, "hfi", a6xx_hfi_irq);
> gmu->gmu_irq = a6xx_gmu_get_irq(gmu, pdev, "gmu", a6xx_gmu_irq);
>
> if (gmu->hfi_irq < 0 || gmu->gmu_irq < 0)
> - goto err;
> + goto err_mmio;
>
> /*
>* Get a link to the GX power domain to reset the GPU in case of GMU
> @@ -1315,7 +1321,12 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct
> device_node *node)
> gmu->initialized = true;
>
> return 0;
> -err:
> +
> +err_mmio:
> + iounmap(gmu->mmio);
> + free_irq(gmu->gmu_irq, gmu);
> + free_irq(gmu->hfi_irq, gmu);
> +err_memory:
> a6xx_gmu_memory_free(gmu, gmu->hfi);
>
> if (gmu->domain) {
> --
> Sean Paul, Software Engineer, Google / Chromium
Re: [PATCH v2 6/6] drm/msm/a6xx: Rename a6xx_gmu_probe to a6xx_gmu_init
On Thu, May 23, 2019 at 01:16:45PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> This rename makes it more clear that everything initialized in the _init
> function must be cleaned up in a6xx_gmu_remove. This will hopefully
> dissuade people from using device managed resources (for reasons laid
> out in the previous patch).
>
> Changes in v2:
> - None
>
> Cc: Jordan Crouse
> Signed-off-by: Sean Paul
Reviewed-by: Jordan Crouse
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +-
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
> drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> index e2b839b5d3bd..5ab69dcd5479 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> @@ -1259,7 +1259,7 @@ void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu)
> gmu->initialized = false;
> }
>
> -int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct device_node *node)
> +int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct device_node *node)
> {
> struct a6xx_gmu *gmu = _gpu->gmu;
> struct platform_device *pdev = of_find_device_by_node(node);
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index e74dce474250..1f9f4b0a9656 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -854,7 +854,7 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
> /* FIXME: How do we gracefully handle this? */
> BUG_ON(!node);
>
> - ret = a6xx_gmu_probe(a6xx_gpu, node);
> + ret = a6xx_gmu_init(a6xx_gpu, node);
> if (ret) {
> a6xx_destroy(&(a6xx_gpu->base.base));
> return ERR_PTR(ret);
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
> index b46279eb18c5..64399554f2dd 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
> @@ -53,7 +53,7 @@ bool a6xx_gmu_isidle(struct a6xx_gmu *gmu);
> int a6xx_gmu_set_oob(struct a6xx_gmu *gmu, enum a6xx_gmu_oob_state state);
> void a6xx_gmu_clear_oob(struct a6xx_gmu *gmu, enum a6xx_gmu_oob_state state);
>
> -int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct device_node *node);
> +int a6xx_gmu_init(struct a6xx_gpu *a6xx_gpu, struct device_node *node);
> void a6xx_gmu_remove(struct a6xx_gpu *a6xx_gpu);
>
> void a6xx_gmu_set_freq(struct msm_gpu *gpu, unsigned long freq);
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH] kernel.h: Add generic roundup_64() macro
On Thu, May 23, 2019 at 10:36 AM Steven Rostedt wrote:
>
> >
> > Of course, you probably want the usual "at least use 'int'" semantics,
> > in which case the "type" should be "(x)+0":
> >
> > #define round_up(x, y) size_fn((x)+0, round_up_size, x, y)
> >
> > and the 8-bit and 16-bit cases will never be used.
>
> I'm curious to what the advantage of that is?
Let's say that you have a structure with a 'unsigned char' member,
because the value range is 0-255.
What happens if you do
x = round_up(p->member, 4);
and the value is 255?
Now, if you stay in 'unsigned char' the end result is 0. If you follow
the usual C integer promotion rules ("all arithmetic promotes to at
least 'int'"), you get 256.
Most people probably expect 256, and that implies that even if you
pass an 'unsigned char' to an arithmetic function like this, you
expect any math to be done in 'int'. Doing the "(x)+0" forces that,
because the "+0" changes the type of the expression from "unsigned
char" to "int" due to C integer promotion.
Yes. The C integer type rules are subtle and sometimes surprising. One
of the things I've wanted is to have some way to limit silent
promotion (and silent truncation!), and cause warnings. 'sparse' does
some of that with some special-case types (ie __bitwise), but it's
pretty limited.
Linus
Re: [PATCH 1/1] drm/i915: remove unused IO_TLB_SEGPAGES which should be defined by swiotlb
Quoting Dongli Zhang (2019-05-21 05:40:39)
> This patch removes IO_TLB_SEGPAGES which is no longer used since
> commit 5584f1b1d73e ("drm/i915: fix i915 running as dom0 under Xen").
>
> As the define of both IO_TLB_SEGSIZE and IO_TLB_SHIFT are from swiotlb,
> IO_TLB_SEGPAGES should be defined on swiotlb side if it is required in the
> future.
>
> Signed-off-by: Dongli Zhang
Pushed, thanks for the patch.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110701] GPU faults in in Unigine Valley 1.0
https://bugs.freedesktop.org/show_bug.cgi?id=110701 --- Comment #26 from Yury Zhuravlev --- (In reply to Christoph Haag from comment #25) > (In reply to Yury Zhuravlev from comment #24) > > (In reply to Marek Olšák from comment #23) > > > Fixed by d6053bf2a170a0fec6d232fda097d2f35f0e9eae. Closing. > > > > The original issue was about Vega and on Vega we saw a different problem. I > > suppose before close issue somebody should check patch on Vega. > > I will do it soon. > > Since nobody responded: On a Vega 64 I got GPU faults like the ones posted > here followed by a GPU hang immediately when restoring a firefox (nightly) > session. With mesa master this does not happen anymore. I agree, everything fine now. Vega56 -- 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/vmwgfx: fix a warning due to missing dma_parms
Booting up with DMA_API_DEBUG_SG=y generates a warning below due to the
driver forgot to set dma_parms appropriately. Set it after
vmw_dma_masks(), so it can choose a size either DMA_BIT_MASK(64) or
DMA_BIT_MASK(44).
DMA-API: vmwgfx :00:0f.0: mapping sg segment longer than device
claims to support [len=2097152] [max=65536]
WARNING: CPU: 2 PID: 261 at kernel/dma/debug.c:1232
debug_dma_map_sg+0x360/0x480
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop
Reference Platform, BIOS 6.00 04/13/2018
RIP: 0010:debug_dma_map_sg+0x360/0x480
Call Trace:
vmw_ttm_map_dma+0x3b1/0x5b0 [vmwgfx]
vmw_bo_map_dma+0x25/0x30 [vmwgfx]
vmw_otables_setup+0x2a8/0x750 [vmwgfx]
vmw_request_device_late+0x78/0xc0 [vmwgfx]
vmw_request_device+0xee/0x4e0 [vmwgfx]
vmw_driver_load.cold+0x757/0xd84 [vmwgfx]
drm_dev_register+0x1ff/0x340 [drm]
drm_get_pci_dev+0x110/0x290 [drm]
vmw_probe+0x15/0x20 [vmwgfx]
local_pci_probe+0x7a/0xc0
pci_device_probe+0x1b9/0x290
really_probe+0x1b5/0x630
driver_probe_device+0xa3/0x1a0
device_driver_attach+0x94/0xa0
__driver_attach+0xdd/0x1c0
bus_for_each_dev+0xfe/0x150
driver_attach+0x2d/0x40
bus_add_driver+0x290/0x350
driver_register+0xdc/0x1d0
__pci_register_driver+0xda/0xf0
vmwgfx_init+0x34/0x1000 [vmwgfx]
do_one_initcall+0xe5/0x40a
do_init_module+0x10f/0x3a0
load_module+0x16a5/0x1a40
__se_sys_finit_module+0x183/0x1c0
__x64_sys_finit_module+0x43/0x50
do_syscall_64+0xc8/0x606
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes: fb1d9738ca05 ("drm/vmwgfx: Add DRM driver for VMware Virtual GPU")
Signed-off-by: Qian Cai
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index bf6c3500d363..5c567b81174f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -747,6 +747,13 @@ static int vmw_driver_load(struct drm_device *dev,
unsigned long chipset)
if (unlikely(ret != 0))
goto out_err0;
+ dev->dev->dma_parms = kzalloc(sizeof(*dev->dev->dma_parms),
+ GFP_KERNEL);
+ if (!dev->dev->dma_parms)
+ goto out_err0;
+
+ dma_set_max_seg_size(dev->dev, *dev->dev->dma_mask);
+
if (dev_priv->capabilities & SVGA_CAP_GMR2) {
DRM_INFO("Max GMR ids is %u\n",
(unsigned)dev_priv->max_gmr_ids);
@@ -772,7 +779,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned
long chipset)
if (unlikely(dev_priv->mmio_virt == NULL)) {
ret = -ENOMEM;
DRM_ERROR("Failed mapping MMIO.\n");
- goto out_err0;
+ goto out_err1;
}
/* Need mmio memory to check for fifo pitchlock cap. */
@@ -781,7 +788,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned
long chipset)
!vmw_fifo_have_pitchlock(dev_priv)) {
ret = -ENOSYS;
DRM_ERROR("Hardware has no pitchlock\n");
- goto out_err4;
+ goto out_err2;
}
dev_priv->tdev = ttm_object_device_init(_mem_glob, 12,
@@ -790,7 +797,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned
long chipset)
if (unlikely(dev_priv->tdev == NULL)) {
DRM_ERROR("Unable to initialize TTM object management.\n");
ret = -ENOMEM;
- goto out_err4;
+ goto out_err2;
}
dev->dev_private = dev_priv;
@@ -944,8 +951,11 @@ static int vmw_driver_load(struct drm_device *dev,
unsigned long chipset)
pci_release_regions(dev->pdev);
out_no_device:
ttm_object_device_release(_priv->tdev);
-out_err4:
+out_err2:
memunmap(dev_priv->mmio_virt);
+out_err1:
+ kfree(dev->dev->dma_parms);
+ dev->dev->dma_parms = NULL;
out_err0:
for (i = vmw_res_context; i < vmw_res_max; ++i)
idr_destroy(_priv->res_idr[i]);
@@ -995,6 +1005,8 @@ static void vmw_driver_unload(struct drm_device *dev)
ttm_object_device_release(_priv->tdev);
memunmap(dev_priv->mmio_virt);
+ kfree(dev->dev->dma_parms);
+ dev->dev->dma_parms = NULL;
if (dev_priv->ctx.staged_bindings)
vmw_binding_state_free(dev_priv->ctx.staged_bindings);
--
2.20.1 (Apple Git-117)
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #22 from Mauro Gaspari --- I ran more tests: 1. Installed Arch Linux, vulkan, llvm8 and ran wine games with DXVK. With same kernel parameters on grub, no freezes, no crashes. Great performance. 2. Installed Ubuntu Budgie 19.04, Oibaf ppa, updated mesa and llvm8. Same as with Arch Linux: With same kernel parameters on grub, no freezes, no crashes. Great performance. The only issue I have not being able to reproduce the issue quickly, is to clearly understand when the issue is resolved by Mesa. It takes hours for me to get the freeze sometimes. If someone has a quick way to trigger system freeze, I am happy to run more tests. -- 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
[git pull] drm fixes for 5.2-rc2
Hey Linus, Nothing too unusual here for rc2. i915: - boosting fix - bump ready task fixes - GVT - reset fix, error return, TRTT handling fix amdgpu: - DMCU firmware loading fix - Polaris 10 pci id for kfd - picasso screen corruption fix - SR-IOV fixes - vega driver reload fixes - SMU locking fix - compute profile fix for kfd vmwgfx: - integer overflow fixes - dma sg fix sun4i: - HDMI phy fixes gma500: - LVDS detection fix panfrost: - devfreq selection fix drm-fixes-2019-05-24: drm i915, amdgpu, vmwgfx, sun4i, panfrost, gma500 fixes. The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9: Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-05-24 for you to fetch changes up to e1e52981f292b4e321781794eaf6e8a087f4f300: Merge tag 'drm-intel-fixes-2019-05-23' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2019-05-24 14:01:00 +1000) drm i915, amdgpu, vmwgfx, sun4i, panfrost, gma500 fixes. Alex Deucher (2): drm/amdgpu/soc15: skip reset on init drm/amdgpu/gmc9: set vram_width properly for SR-IOV Chris Wilson (5): drm/i915: Rearrange i915_scheduler.c drm/i915: Pass i915_sched_node around internally drm/i915: Bump signaler priority on adding a waiter drm/i915: Downgrade NEWCLIENT to non-preemptive drm/i915: Truly bump ready tasks ahead of busywaits Dan Carpenter (2): drm/amd/powerplay: fix locking in smu_feature_set_supported() drm/i915/gvt: Fix an error code in ppgtt_populate_spt_by_guest_entry() Dave Airlie (4): Merge branch 'vmwgfx-fixes-5.2' of git://people.freedesktop.org/~thomash/linux into drm-fixes Merge tag 'drm-misc-fixes-2019-05-22' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge branch 'drm-fixes-5.2' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge tag 'drm-intel-fixes-2019-05-23' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Ezequiel Garcia (1): drm/panfrost: Select devfreq Flora Cui (1): drm/amdgpu: keep stolen memory on picasso Harish Kasiviswanathan (1): drm/amdkfd: Fix compute profile switching Harry Wentland (2): drm/amd/display: Add ASICREV_IS_PICASSO drm/amd/display: Don't load DMCU for Raven 1 Jagan Teki (1): drm/sun4i: sun6i_mipi_dsi: Fix hsync_porch overflow Jernej Skrabec (2): drm/sun4i: Fix sun8i HDMI PHY clock initialization drm/sun4i: Fix sun8i HDMI PHY configuration for > 148.5 MHz Joonas Lahtinen (1): Merge tag 'gvt-fixes-2019-05-21' of https://github.com/intel/gvt-linux into drm-intel-fixes Kent Russell (1): drm/amdkfd: Add missing Polaris10 ID Murray McAllister (2): drm/vmwgfx: NULL pointer dereference from vmw_cmd_dx_view_define() drm/vmwgfx: integer underflow in vmw_cmd_dx_set_shader() leading to an invalid read Patrik Jakobsson (1): drm/gma500/cdv: Check vbt config bits when detecting lvds panels Sean Paul (1): Merge drm-misc-next-fixes-2019-05-20 into drm-misc-fixes Thomas Hellstrom (4): drm/vmwgfx: Don't send drm sysfs hotplug events on initial master set drm/vmwgfx: Fix user space handle equal to zero drm/vmwgfx: Fix compat mode shader operation drm/vmwgfx: Use the dma scatter-gather iterator to get dma addresses Weinan (1): drm/i915/gvt: emit init breadcrumb for gvt request Yan Zhao (4): drm/i915/gvt: use cmd to restore in-context mmios to hw for gen9 platform drm/i915/gvt: Tiled Resources mmios are in-context mmios for gen9+ drm/i915/gvt: add 0x4dfc to gen9 save-restore list drm/i915/gvt: do not let TRTTE and 0x4dfc write passthrough to hardware Yintian Tao (1): drm/amdgpu: skip fw pri bo alloc for SRIOV drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 17 +- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 11 +- drivers/gpu/drm/amd/amdgpu/soc15.c | 5 + drivers/gpu/drm/amd/amdkfd/kfd_device.c| 17 ++ .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 11 +- drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 7 + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 +- drivers/gpu/drm/amd/display/include/dal_asic_id.h | 7 +- drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 2 +- drivers/gpu/drm/gma500/cdv_intel_lvds.c| 3 + drivers/gpu/drm/gma500/intel_bios.c| 3 + drivers/gpu/drm/gma500/psb_drv.h | 1 + drivers/gpu/drm/i915/gvt/cmd_parser.c | 14 +- drivers/gpu/drm/i915/gvt/gtt.c | 4 +- drivers/gpu/drm/i915/gvt/handlers.c| 15 -- drivers/gpu/drm/i915/gvt/mmio_context.c| 23 +- drivers/gpu/drm/i915/gvt/scheduler.c | 23 +-
Re: [PATCH 1/2] update drm.h
anyone can pick up to gitlab for libdrm?
Thanks,
-David
On 2019年05月22日 18:46, Koenig, Christian wrote:
Am 22.05.19 um 11:07 schrieb Chunming Zhou:
a) delta: only DRM_CAP_SYNCOBJ_TIMELINE
b) Generated using make headers_install.
c) Generated from origin/drm-misc-next commit
982c0500fd1a8012c31d3c9dd8de285129904656"
Signed-off-by: Chunming Zhou
Suggested-by: Michel Dänzer
Reviewed-by: Christian König
---
include/drm/drm.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index c893f3b4..438abde3 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -44,6 +44,7 @@ typedef unsigned int drm_handle_t;
#else /* One of the BSDs */
+#include
#include
#include
typedef int8_t __s8;
@@ -643,6 +644,7 @@ struct drm_gem_open {
#define DRM_CAP_PAGE_FLIP_TARGET 0x11
#define DRM_CAP_CRTC_IN_VBLANK_EVENT 0x12
#define DRM_CAP_SYNCOBJ 0x13
+#define DRM_CAP_SYNCOBJ_TIMELINE 0x14
/** DRM_IOCTL_GET_CAP ioctl argument type */
struct drm_get_cap {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110749] [Vega 11] [amdgpu retry page fault VM_L2_PROTECTION_FAULT_STATUS] System lock up during playing Steam version of Saints Row 3
https://bugs.freedesktop.org/show_bug.cgi?id=110749 --- Comment #2 from Cyrax --- Created attachment 144338 --> https://bugs.freedesktop.org/attachment.cgi?id=144338=edit Xorg log before starting the game -- 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 06/10] drm/ttm: fix busy memory to fail other user v10
Use Abaqus torturing the amdgpu driver more times will running into locking
first busy BO deadlock .Then the caller will
return EAGAIN and eventually dm_plane_helper_prepare_fb popups out pinned
failed message .For this case, the patch#7
can we add EAGAIN as ERESTARTSYS which filter out the annoying error message .
Thanks,
Prike
-Original Message-
From: Christian König
Sent: Thursday, May 23, 2019 7:04 PM
To: Zhou, David(ChunMing) ; Olsak, Marek
; Zhou, David(ChunMing) ; Liang,
Prike ; dri-devel@lists.freedesktop.org;
amd-...@lists.freedesktop.org
Subject: Re: [PATCH 06/10] drm/ttm: fix busy memory to fail other user v10
[CAUTION: External Email]
Am 23.05.19 um 12:24 schrieb zhoucm1:
>
>
> On 2019年05月22日 20:59, Christian König wrote:
>> [CAUTION: External Email]
>>
>> BOs on the LRU might be blocked during command submission and cause
>> OOM situations.
>>
>> Avoid this by blocking for the first busy BO not locked by the same
>> ticket as the BO we are searching space for.
>>
>> v10: completely start over with the patch since we didn't
>> handled a whole bunch of corner cases.
>>
>> Signed-off-by: Christian König
>> ---
>> drivers/gpu/drm/ttm/ttm_bo.c | 77 ++--
>> 1 file changed, 66 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
>> b/drivers/gpu/drm/ttm/ttm_bo.c index 4c6389d849ed..861facac33d4
>> 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>> @@ -771,32 +771,72 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
>>* b. Otherwise, trylock it.
>>*/
>> static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object
>> *bo,
>> - struct ttm_operation_ctx *ctx, bool *locked)
>> + struct ttm_operation_ctx *ctx, bool *locked,
>> bool *busy)
>> {
>> bool ret = false;
>>
>> - *locked = false;
>> if (bo->resv == ctx->resv) {
>> reservation_object_assert_held(bo->resv);
>> if (ctx->flags & TTM_OPT_FLAG_ALLOW_RES_EVICT
>> || !list_empty(>ddestroy))
>> ret = true;
>> + *locked = false;
>> + if (busy)
>> + *busy = false;
>> } else {
>> - *locked = reservation_object_trylock(bo->resv);
>> - ret = *locked;
>> + ret = reservation_object_trylock(bo->resv);
>> + *locked = ret;
>> + if (busy)
>> + *busy = !ret;
>> }
>>
>> return ret;
>> }
>>
>> +/**
>> + * ttm_mem_evict_wait_busy - wait for a busy BO to become available
>> + *
>> + * @busy_bo: BO which couldn't be locked with trylock
>> + * @ctx: operation context
>> + * @ticket: acquire ticket
>> + *
>> + * Try to lock a busy buffer object to avoid failing eviction.
>> + */
>> +static int ttm_mem_evict_wait_busy(struct ttm_buffer_object *busy_bo,
>> + struct ttm_operation_ctx *ctx,
>> + struct ww_acquire_ctx *ticket) {
>> + int r;
>> +
>> + if (!busy_bo || !ticket)
>> + return -EBUSY;
>> +
>> + if (ctx->interruptible)
>> + r =
>> + reservation_object_lock_interruptible(busy_bo->resv,
>> + ticket);
>> + else
>> + r = reservation_object_lock(busy_bo->resv, ticket);
>> +
>> + /*
>> +* TODO: It would be better to keep the BO locked until
>> allocation is at
>> +* least tried one more time, but that would mean a much
>> larger rework
>> +* of TTM.
>> +*/
>> + if (!r)
>> + reservation_object_unlock(busy_bo->resv);
>> +
>> + return r == -EDEADLK ? -EAGAIN : r; }
>> +
>> static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
>> uint32_t mem_type,
>> const struct ttm_place *place,
>> - struct ttm_operation_ctx *ctx)
>> + struct ttm_operation_ctx *ctx,
>> + struct ww_acquire_ctx *ticket)
>> {
>> + struct ttm_buffer_object *bo = NULL, *busy_bo = NULL;
>> struct ttm_bo_global *glob = bdev->glob;
>> struct ttm_mem_type_manager *man = >man[mem_type];
>> - struct ttm_buffer_object *bo = NULL;
>> bool locked = false;
>> unsigned i;
>> int ret;
>> @@ -804,8 +844,15 @@ static int ttm_mem_evict_first(struct
>> ttm_bo_device *bdev,
>> spin_lock(>lru_lock);
>> for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
>> list_for_each_entry(bo, >lru[i], lru) {
>> - if (!ttm_bo_evict_swapout_allowable(bo, ctx,
>> ))
>> + bool busy;
>> +
>> + if (!ttm_bo_evict_swapout_allowable(bo, ctx,
>> ,
>> + )) {
>> + if (busy &&
[PATCH] drm_edid-load: Fix a missing-check bug in drm_load_edid_firmware()
In drm_load_edid_firmware(), fwstr is allocated by kstrdup(). And fwstr
is dereferenced in the following codes. However, memory allocation
functions such as kstrdup() may fail and returns NULL. Dereferencing
this null pointer may cause the kernel go wrong. Thus we should check
this kstrdup() operation.
Further, if kstrdup() returns NULL, we should return ERR_PTR(-ENOMEM) to
the caller site.
Signed-off-by: Gen Zhang
Reviewed-by: Jani Nikula
---
diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index a491509..a0e107a 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -290,6 +290,8 @@ struct edid *drm_load_edid_firmware(struct drm_connector
*connector)
* the last one found one as a fallback.
*/
fwstr = kstrdup(edid_firmware, GFP_KERNEL);
+ if (!fwstr)
+ return ERR_PTR(-ENOMEM);
edidstr = fwstr;
while ((edidname = strsep(, ","))) {
---
[PATCH] drm/komeda: Refine function to_d71_input_id
Since the component_state->input[i] is only valid when it is active, the
content of input[i] is undefined if it is inactive. The user must check the
state->active_inputs with input index firstly before using state->input[i].
Refine the function to_d71_input_id and directly move such check into it.
Simplify the using and avoid problem that caller forget the valid check.
Depends on:
- https://patchwork.freedesktop.org/series/60856/
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../arm/display/komeda/d71/d71_component.c| 32 ++-
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index d101a5cc2766..fff9fc8fab15 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -156,11 +156,15 @@ static u32 to_ad_ctrl(u64 modifier)
return afbc_ctrl;
}
-static inline u32 to_d71_input_id(struct komeda_component_output *output)
+static inline u32 to_d71_input_id(struct komeda_component_state *st, int idx)
{
- struct komeda_component *comp = output->component;
+ struct komeda_component_output *input = >inputs[idx];
- return comp ? (comp->hw_id + output->output_port) : 0;
+ /* if input is not active, set hw input_id(0) to disable it */
+ if (has_bit(idx, st->active_inputs))
+ return input->component->hw_id + input->output_port;
+ else
+ return 0;
}
static void d71_layer_update_fb(struct komeda_component *c,
@@ -388,7 +392,7 @@ static void d71_wb_layer_update(struct komeda_component *c,
ctrl |= LW_TBU_EN;
malidp_write32(reg, BLK_IN_SIZE, HV_SIZE(st->hsize, st->vsize));
- malidp_write32(reg, BLK_INPUT_ID0, to_d71_input_id(>inputs[0]));
+ malidp_write32(reg, BLK_INPUT_ID0, to_d71_input_id(state, 0));
malidp_write32_mask(reg, BLK_CONTROL, mask, ctrl);
}
@@ -512,15 +516,15 @@ static void d71_compiz_update(struct komeda_component *c,
struct komeda_compiz_state *st = to_compiz_st(state);
u32 __iomem *reg = c->reg;
u32 __iomem *id_reg, *cfg_reg;
- u32 index, input_hw_id;
+ u32 index;
for_each_changed_input(state, index) {
id_reg = reg + index;
cfg_reg = reg + index * CU_PER_INPUT_REGS;
- input_hw_id = to_d71_input_id(>inputs[index]);
if (state->active_inputs & BIT(index)) {
compiz_enable_input(id_reg, cfg_reg,
- input_hw_id, >cins[index]);
+ to_d71_input_id(state, index),
+ >cins[index]);
} else {
malidp_write32(id_reg, BLK_INPUT_ID0, 0);
malidp_write32(cfg_reg, CU_INPUT0_CONTROL, 0);
@@ -696,7 +700,7 @@ static void d71_scaler_update(struct komeda_component *c,
ctrl |= SC_CTRL_LS;
malidp_write32(reg, BLK_CONTROL, ctrl);
- malidp_write32(reg, BLK_INPUT_ID0, to_d71_input_id(>inputs[0]));
+ malidp_write32(reg, BLK_INPUT_ID0, to_d71_input_id(state, 0));
}
static void d71_scaler_dump(struct komeda_component *c, struct seq_file *sf)
@@ -772,7 +776,7 @@ static void d71_merger_update(struct komeda_component *c,
for_each_changed_input(state, index)
malidp_write32(reg, MG_INPUT_ID0 + index * 4,
- to_d71_input_id(>inputs[index]));
+ to_d71_input_id(state, index));
malidp_write32(reg, MG_SIZE, HV_SIZE(st->hsize_merged,
st->vsize_merged));
@@ -839,13 +843,11 @@ static void d71_improc_update(struct komeda_component *c,
{
struct komeda_improc_state *st = to_improc_st(state);
u32 __iomem *reg = c->reg;
- u32 index, input_hw_id;
+ u32 index;
- for_each_changed_input(state, index) {
- input_hw_id = state->active_inputs & BIT(index) ?
- to_d71_input_id(>inputs[index]) : 0;
- malidp_write32(reg, BLK_INPUT_ID0 + index * 4, input_hw_id);
- }
+ for_each_changed_input(state, index)
+ malidp_write32(reg, BLK_INPUT_ID0 + index * 4,
+ to_d71_input_id(state, index));
malidp_write32(reg, BLK_SIZE, HV_SIZE(st->hsize, st->vsize));
}
--
2.17.1
[PATCH] drm/komeda: Accept null writeback configurations for writeback
User may send null writeback configurations for writeback connector like:
- Only bind the writeback connector to crtc.
- set a fb_id(0) to writeback_fb_id_property
All above configurations are meaningless for writeback, but since they are
still valid configurations, accept them.
Depends on:
- https://patchwork.freedesktop.org/series/60856/
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../gpu/drm/arm/display/komeda/komeda_wb_connector.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
index 20295291572f..0d734244f662 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
@@ -13,11 +13,7 @@ komeda_wb_init_data_flow(struct komeda_layer *wb_layer,
struct komeda_crtc_state *kcrtc_st,
struct komeda_data_flow_cfg *dflow)
{
- struct drm_framebuffer *fb = conn_st->writeback_job ?
-conn_st->writeback_job->fb : NULL;
-
- if (!fb)
- return -EINVAL;
+ struct drm_framebuffer *fb = conn_st->writeback_job->fb;
memset(dflow, 0, sizeof(*dflow));
@@ -42,10 +38,15 @@ komeda_wb_encoder_atomic_check(struct drm_encoder *encoder,
struct drm_connector_state *conn_st)
{
struct komeda_crtc_state *kcrtc_st = to_kcrtc_st(crtc_st);
+ struct drm_writeback_job *writeback_job = conn_st->writeback_job;
struct komeda_layer *wb_layer;
struct komeda_data_flow_cfg dflow;
int err;
+ if (!writeback_job || !writeback_job->fb) {
+ return 0;
+ }
+
if (!crtc_st->active) {
DRM_DEBUG_ATOMIC("Cannot write the composition result out on a
inactive CRTC.\n");
return -EINVAL;
--
2.17.1
Re: [PATCH] drm/cirrus: remove leftover files
On Wed, May 22, 2019 at 05:06:34PM +0200, Sam Ravnborg wrote:
> On Wed, May 22, 2019 at 12:33:07PM +0200, Gerd Hoffmann wrote:
> > cirrus_drv.h and cirrus_ttm.c are unused since commit ab3e023b1b4c
> > ("drm/cirrus: rewrite and modernize driver"), apparently I ran "rm"
> > instead of "git rm" on them so they are still in present the tree.
> >
> > Signed-off-by: Gerd Hoffmann
> Reviewed-by: Sam Ravnborg
>
> Always nice with the code removal patches.
> Will you apply yourself?
Yes.
thanks,
Gerd
Re: [PATCH 2/4] drm/virtio: remove irrelevant DRM_UNLOCKED flag
On Wed, May 22, 2019 at 04:47:00PM +0100, Emil Velikov wrote: > From: Emil Velikov > > DRM_UNLOCKED doesn't do anything for non-legacy drivers. Remove it. Patch applied to drm-misc-next. thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/10] drm/ttm: fix busy memory to fail other user v10
On 2019年05月22日 20:59, Christian König wrote:
[CAUTION: External Email]
BOs on the LRU might be blocked during command submission
and cause OOM situations.
Avoid this by blocking for the first busy BO not locked by
the same ticket as the BO we are searching space for.
v10: completely start over with the patch since we didn't
handled a whole bunch of corner cases.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 77 ++--
1 file changed, 66 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 4c6389d849ed..861facac33d4 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -771,32 +771,72 @@ EXPORT_SYMBOL(ttm_bo_eviction_valuable);
* b. Otherwise, trylock it.
*/
static bool ttm_bo_evict_swapout_allowable(struct ttm_buffer_object *bo,
- struct ttm_operation_ctx *ctx, bool *locked)
+ struct ttm_operation_ctx *ctx, bool *locked, bool *busy)
{
bool ret = false;
- *locked = false;
if (bo->resv == ctx->resv) {
reservation_object_assert_held(bo->resv);
if (ctx->flags & TTM_OPT_FLAG_ALLOW_RES_EVICT
|| !list_empty(>ddestroy))
ret = true;
+ *locked = false;
+ if (busy)
+ *busy = false;
} else {
- *locked = reservation_object_trylock(bo->resv);
- ret = *locked;
+ ret = reservation_object_trylock(bo->resv);
+ *locked = ret;
+ if (busy)
+ *busy = !ret;
}
return ret;
}
+/**
+ * ttm_mem_evict_wait_busy - wait for a busy BO to become available
+ *
+ * @busy_bo: BO which couldn't be locked with trylock
+ * @ctx: operation context
+ * @ticket: acquire ticket
+ *
+ * Try to lock a busy buffer object to avoid failing eviction.
+ */
+static int ttm_mem_evict_wait_busy(struct ttm_buffer_object *busy_bo,
+ struct ttm_operation_ctx *ctx,
+ struct ww_acquire_ctx *ticket)
+{
+ int r;
+
+ if (!busy_bo || !ticket)
+ return -EBUSY;
+
+ if (ctx->interruptible)
+ r = reservation_object_lock_interruptible(busy_bo->resv,
+ ticket);
+ else
+ r = reservation_object_lock(busy_bo->resv, ticket);
+
+ /*
+* TODO: It would be better to keep the BO locked until allocation is at
+* least tried one more time, but that would mean a much larger rework
+* of TTM.
+*/
+ if (!r)
+ reservation_object_unlock(busy_bo->resv);
+
+ return r == -EDEADLK ? -EAGAIN : r;
+}
+
static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
uint32_t mem_type,
const struct ttm_place *place,
- struct ttm_operation_ctx *ctx)
+ struct ttm_operation_ctx *ctx,
+ struct ww_acquire_ctx *ticket)
{
+ struct ttm_buffer_object *bo = NULL, *busy_bo = NULL;
struct ttm_bo_global *glob = bdev->glob;
struct ttm_mem_type_manager *man = >man[mem_type];
- struct ttm_buffer_object *bo = NULL;
bool locked = false;
unsigned i;
int ret;
@@ -804,8 +844,15 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
spin_lock(>lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, >lru[i], lru) {
- if (!ttm_bo_evict_swapout_allowable(bo, ctx, ))
+ bool busy;
+
+ if (!ttm_bo_evict_swapout_allowable(bo, ctx, ,
+ )) {
+ if (busy && !busy_bo &&
+ bo->resv->lock.ctx != ticket)
+ busy_bo = bo;
continue;
+ }
if (place && !bdev->driver->eviction_valuable(bo,
place)) {
@@ -824,8 +871,13 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
}
if (!bo) {
+ if (busy_bo)
+ ttm_bo_get(busy_bo);
spin_unlock(>lru_lock);
- return -EBUSY;
+ ret = ttm_mem_evict_wait_busy(busy_bo, ctx, ticket);
If you rely on EAGAIN, why do you still try to lock busy_bo? any
negative effect if directly return EAGAIN without tring lock?
-David
+ if (busy_bo)
+ ttm_bo_put(busy_bo);
+ return ret;
}
Re: [PATCH v2 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
On Wed, May 22, 2019 at 02:38:48PM -0700, Brendan Higgins wrote: > +Bjorn Helgaas > > On Wed, May 15, 2019 at 12:41 AM Daniel Vetter wrote: > > > > On Tue, May 14, 2019 at 11:36:18AM -0700, Brendan Higgins wrote: > > > On Tue, May 14, 2019 at 02:05:05PM +0200, Daniel Vetter wrote: > > > > On Tue, May 14, 2019 at 8:04 AM Brendan Higgins > > > > wrote: > > > > > > > > > > On Mon, May 13, 2019 at 04:44:51PM +0200, Daniel Vetter wrote: > > > > > > On Sat, May 11, 2019 at 01:33:44PM -0400, Theodore Ts'o wrote: > > > > > > > On Fri, May 10, 2019 at 02:12:40PM -0700, Frank Rowand wrote: > > > > > > > > However, the reply is incorrect. Kselftest in-kernel tests > > > > > > > > (which > > > > > > > > is the context here) can be configured as built in instead of as > > > > > > > > a module, and built in a UML kernel. The UML kernel can boot, > > > > > > > > running the in-kernel tests before UML attempts to invoke the > > > > > > > > init process. > > > > > > > > > > > > > > Um, Citation needed? > > > > > > > > > > > > > > I don't see any evidence for this in the kselftest documentation, > > > > > > > nor > > > > > > > do I see any evidence of this in the kselftest Makefiles. > > > > > > > > > > > > > > There exists test modules in the kernel that run before the init > > > > > > > scripts run --- but that's not strictly speaking part of > > > > > > > kselftests, > > > > > > > and do not have any kind of infrastructure. As noted, the > > > > > > > kselftests_harness header file fundamentally assumes that you are > > > > > > > running test code in userspace. > > > > > > > > > > > > Yeah I really like the "no userspace required at all" design of > > > > > > kunit, > > > > > > while still collecting results in a well-defined way (unless the > > > > > > current > > > > > > self-test that just run when you load the module, with maybe some > > > > > > kselftest ad-hoc wrapper around to collect the results). > > > > > > > > > > > > What I want to do long-term is to run these kernel unit tests as > > > > > > part of > > > > > > the build-testing, most likely in gitlab (sooner or later, for > > > > > > drm.git > > > > > > > > > > Totally! This is part of the reason I have been insisting on a minimum > > > > > of UML compatibility for all unit tests. If you can suffiently > > > > > constrain > > > > > the environment that is required for tests to run in, it makes it much > > > > > easier not only for a human to run your tests, but it also makes it a > > > > > lot easier for an automated service to be able to run your tests. > > > > > > > > > > I actually have a prototype presubmit already working on my > > > > > "stable/non-upstream" branch. You can checkout what presubmit results > > > > > look like here[1][2]. > > > > > > > > ug gerrit :-) > > > > > > Yeah, yeah, I know, but it is a lot easier for me to get a project set > > > up here using Gerrit, when we already use that for a lot of other > > > projects. > > > > > > Also, Gerrit has gotten a lot better over the last two years or so. Two > > > years ago, I wouldn't touch it with a ten foot pole. It's not so bad > > > anymore, at least if you are used to using a web UI to review code. > > > > I was somewhat joking, I'm just not used to gerrit ... And seems to indeed > > be a lot more polished than last time I looked at it seriously. > > I mean, it is still not perfect, but I think it has finally gotten to > the point where I prefer it over reviewing by email for high context > patches where you don't expect a lot of deep discussion. > > Still not great for patches where you want to have a lot of discussion. > > > > > > > only ofc). So that people get their pull requests (and patch > > > > > > series, we > > > > > > have some ideas to tie this into patchwork) automatically tested > > > > > > for this > > > > > > > > > > Might that be Snowpatch[3]? I talked to Russell, the creator of > > > > > Snowpatch, > > > > > and he seemed pretty open to collaboration. > > > > > > > > > > Before I heard about Snowpatch, I had an intern write a translation > > > > > layer that made Prow (the presubmit service that I used in the > > > > > prototype > > > > > above) work with LKML[4]. > > > > > > > > There's about 3-4 forks/clones of patchwork. snowpatch is one, we have > > > > a different one on freedesktop.org. It's a bit a mess :-/ > > I think Snowpatch is an ozlabs project; at least the maintainer works at IBM. > > Patchwork originally was a ozlabs project, right? So there's two patchworks (snowpatch makes the 3rd): the one on freedesktop is another fork. > Has any discussion taken place trying to consolidate some of the forks? Yup, but didn't lead anywhere unfortunately :-/ At least between patchwork and patchwork-fdo, I think snowpatch happened in parallel and once it was done it's kinda too late. The trouble is that they all have slightly different REST api and functionality, so for CI integration you can't just switch one for the other. > Presubmit
Re: [PATCH 01/10] drm/ttm: Make LRU removal optional.
On 2019年05月22日 20:59, Christian König wrote:
[CAUTION: External Email]
We are already doing this for DMA-buf imports and also for
amdgpu VM BOs for quite a while now.
If this doesn't run into any problems we are probably going
to stop removing BOs from the LRU altogether.
Signed-off-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 9 +
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 4 ++--
drivers/gpu/drm/qxl/qxl_release.c | 2 +-
drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
drivers/gpu/drm/radeon/radeon_object.c| 2 +-
drivers/gpu/drm/ttm/ttm_execbuf_util.c| 20 +++
drivers/gpu/drm/virtio/virtgpu_ioctl.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 3 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_validation.h| 2 +-
include/drm/ttm/ttm_bo_driver.h | 5 -
include/drm/ttm/ttm_execbuf_util.h| 3 ++-
13 files changed, 34 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index e1cae4a37113..647e18f9e136 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -574,7 +574,7 @@ static int reserve_bo_and_vm(struct kgd_mem *mem,
amdgpu_vm_get_pd_bo(vm, >list, >vm_pd[0]);
ret = ttm_eu_reserve_buffers(>ticket, >list,
-false, >duplicates);
+false, >duplicates, true);
if (!ret)
ctx->reserved = true;
else {
@@ -647,7 +647,7 @@ static int reserve_bo_and_cond_vms(struct kgd_mem *mem,
}
ret = ttm_eu_reserve_buffers(>ticket, >list,
-false, >duplicates);
+false, >duplicates, true);
if (!ret)
ctx->reserved = true;
else
@@ -1800,7 +1800,8 @@ static int validate_invalid_user_pages(struct
amdkfd_process_info *process_info)
}
/* Reserve all BOs and page tables for validation */
- ret = ttm_eu_reserve_buffers(, _list, false, );
+ ret = ttm_eu_reserve_buffers(, _list, false, ,
+true);
WARN(!list_empty(), "Duplicates should be empty");
if (ret)
goto out_free;
@@ -2006,7 +2007,7 @@ int amdgpu_amdkfd_gpuvm_restore_process_bos(void *info,
struct dma_fence **ef)
}
ret = ttm_eu_reserve_buffers(, ,
-false, _save);
+false, _save, true);
if (ret) {
pr_debug("Memory eviction: TTM Reserve Failed. Try again\n");
goto ttm_reserve_fail;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index d72cc583ebd1..fff558cf385b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -648,7 +648,7 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser *p,
}
r = ttm_eu_reserve_buffers(>ticket, >validated, true,
- );
+ , true);
if (unlikely(r != 0)) {
if (r != -ERESTARTSYS)
DRM_ERROR("ttm_eu_reserve_buffers failed.\n");
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
index 54dd02a898b9..06f83cac0d3a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
@@ -79,7 +79,7 @@ int amdgpu_map_static_csa(struct amdgpu_device *adev, struct
amdgpu_vm *vm,
list_add(_tv.head, );
amdgpu_vm_get_pd_bo(vm, , );
- r = ttm_eu_reserve_buffers(, , true, NULL);
+ r = ttm_eu_reserve_buffers(, , true, NULL, true);
if (r) {
DRM_ERROR("failed to reserve CSA,PD BOs: err=%d\n", r);
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 7b840367004c..d513a5ad03dd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -171,7 +171,7 @@ void amdgpu_gem_object_close(struct drm_gem_object *obj,
amdgpu_vm_get_pd_bo(vm, , _pd);
- r = ttm_eu_reserve_buffers(, , false, );
+ r = ttm_eu_reserve_buffers(, , false, , true);
if (r) {
dev_err(adev->dev, "leaking bo va because "
"we fail to reserve bo (%d)\n", r);
@@ -608,7 +608,7 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data,
amdgpu_vm_get_pd_bo(>vm, , _pd);
- r = ttm_eu_reserve_buffers(, , true, );
+ r = ttm_eu_reserve_buffers(, , true, , true);
[PATCH v4] drm/komeda: Add writeback support
Komeda driver uses a individual component to describe the HW's writeback
caps, but drivers doesn't define a new structure and still uses the
existing "struct komeda_layer" to describe this new component.
The detailed changes as follow:
1. Initialize wb_layer according to HW and report it to CORE.
2. CORE exposes wb_layer as a resource to KMS by private_obj.
3. Report writeback supporting by add a wb_connector to KMS, and then
wb_connector will take act as a component resources user,
so the func komeda_wb_encoder_atomic_check claims komeda resources
(scaler and wb_layer) accroding to its state configuration to the
wb_connector. and the wb_state configuration will be validated on the
specific component resources to see if the caps of component can
meet the requirement of wb_connector. if not check failed.
4. Update irq_handler to notify the completion of writeback.
NOTE:
This change doesn't add scaling writeback support, that support will
be added in the future after the scaler support.
v2: Rebase
v3: Rebase and constify the d71_wb_layer_funcs
v4: Addressed Ayan's comments
Depends on:
- https://patchwork.freedesktop.org/series/59915/
Signed-off-by: James Qian Wang (Arm Technology China)
---
drivers/gpu/drm/arm/display/komeda/Makefile | 1 +
.../arm/display/komeda/d71/d71_component.c| 90 -
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 15 ++
.../arm/display/komeda/komeda_framebuffer.c | 19 ++
.../gpu/drm/arm/display/komeda/komeda_kms.c | 4 +
.../gpu/drm/arm/display/komeda/komeda_kms.h | 27 +++
.../drm/arm/display/komeda/komeda_pipeline.h | 7 +
.../display/komeda/komeda_pipeline_state.c| 51 -
.../arm/display/komeda/komeda_private_obj.c | 6 +
.../arm/display/komeda/komeda_wb_connector.c | 181 ++
10 files changed, 398 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
diff --git a/drivers/gpu/drm/arm/display/komeda/Makefile
b/drivers/gpu/drm/arm/display/komeda/Makefile
index 62bd1bff66a3..d7e29fc688c3 100644
--- a/drivers/gpu/drm/arm/display/komeda/Makefile
+++ b/drivers/gpu/drm/arm/display/komeda/Makefile
@@ -14,6 +14,7 @@ komeda-y := \
komeda_kms.o \
komeda_crtc.o \
komeda_plane.o \
+ komeda_wb_connector.o \
komeda_private_obj.o
komeda-y += \
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index 6bab816ed8e7..323e5994a55c 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -288,10 +288,98 @@ static int d71_layer_init(struct d71_dev *d71,
return 0;
}
+static void d71_wb_layer_update(struct komeda_component *c,
+ struct komeda_component_state *state)
+{
+ struct komeda_layer_state *st = to_layer_st(state);
+ struct drm_connector_state *conn_st = state->wb_conn->state;
+ struct drm_framebuffer *fb = conn_st->writeback_job->fb;
+ struct komeda_fb *kfb = to_kfb(fb);
+ u32 __iomem *reg = c->reg;
+ u32 ctrl = L_EN | LW_OFM, mask = L_EN | LW_OFM | LW_TBU_EN;
+ int i;
+
+ for (i = 0; i < fb->format->num_planes; i++) {
+ malidp_write32(reg + i * LAYER_PER_PLANE_REGS, BLK_P0_PTR_LOW,
+ lower_32_bits(st->addr[i]));
+ malidp_write32(reg + i * LAYER_PER_PLANE_REGS, BLK_P0_PTR_HIGH,
+ upper_32_bits(st->addr[i]));
+
+ malidp_write32(reg + i * LAYER_PER_PLANE_REGS, BLK_P0_STRIDE,
+ fb->pitches[i] & 0x);
+ }
+
+ malidp_write32(reg, LAYER_FMT, kfb->format_caps->hw_id);
+ malidp_write32(reg, BLK_IN_SIZE, HV_SIZE(st->hsize, st->vsize));
+ malidp_write32(reg, BLK_INPUT_ID0, to_d71_input_id(>inputs[0]));
+ malidp_write32_mask(reg, BLK_CONTROL, mask, ctrl);
+}
+
+static void d71_wb_layer_dump(struct komeda_component *c, struct seq_file *sf)
+{
+ u32 v[12], i;
+
+ dump_block_header(sf, c->reg);
+
+ get_values_from_reg(c->reg, 0x80, 1, v);
+ seq_printf(sf, "LW_INPUT_ID0:\t\t0x%X\n", v[0]);
+
+ get_values_from_reg(c->reg, 0xD0, 3, v);
+ seq_printf(sf, "LW_CONTROL:\t\t0x%X\n", v[0]);
+ seq_printf(sf, "LW_PROG_LINE:\t\t0x%X\n", v[1]);
+ seq_printf(sf, "LW_FORMAT:\t\t0x%X\n", v[2]);
+
+ get_values_from_reg(c->reg, 0xE0, 1, v);
+ seq_printf(sf, "LW_IN_SIZE:\t\t0x%X\n", v[0]);
+
+ for (i = 0; i < 2; i++) {
+ get_values_from_reg(c->reg, 0x100 + i * 0x10, 3, v);
+ seq_printf(sf, "LW_P%u_PTR_LOW:\t\t0x%X\n", i, v[0]);
+ seq_printf(sf, "LW_P%u_PTR_HIGH:\t\t0x%X\n", i, v[1]);
+ seq_printf(sf, "LW_P%u_STRIDE:\t\t0x%X\n", i, v[2]);
+ }
+
+ get_values_from_reg(c->reg, 0x130, 12, v);
+ for (i = 0; i < 12; i++)
+
Re: [PATCH 01/10] drm/ttm: Make LRU removal optional.
Am 23.05.19 um 11:15 schrieb zhoucm1: On 2019年05月22日 20:59, Christian König wrote: [SNIP] @@ -203,7 +204,10 @@ void ttm_eu_fence_buffer_objects(struct ww_acquire_ctx *ticket, reservation_object_add_shared_fence(bo->resv, fence); else reservation_object_add_excl_fence(bo->resv, fence); - ttm_bo_add_to_lru(bo); + if (list_empty(>lru)) + ttm_bo_add_to_lru(bo); + else + ttm_bo_move_to_lru_tail(bo, NULL); can ttm_bo_move_to_lru_tail be moved to ttm_eu_reserve_buffers when del_lru is false? No, that won't work. The BO might have moved to another domain and when we have the ttm_bo_move_to_lru_tail() in the reservation we won't be handling this correctly. Christian. -David ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/komeda: Added AFBC support for komeda driver
For supporting AFBC:
1. Check if the user requested modifier can be supported by display HW.
2. Check the obj->size with AFBC's requirement.
3. Configure HW according to the modifier (afbc features)
This patch depends on:
- https://patchwork.freedesktop.org/series/59915/
- https://patchwork.freedesktop.org/series/59000/
v2: Rebase and addressed Ayan's comments
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../arm/display/komeda/d71/d71_component.c| 39 ++
.../arm/display/komeda/komeda_format_caps.c | 53 +
.../arm/display/komeda/komeda_format_caps.h | 5 ++
.../arm/display/komeda/komeda_framebuffer.c | 75 ++-
.../arm/display/komeda/komeda_framebuffer.h | 4 +
.../gpu/drm/arm/display/komeda/komeda_kms.c | 2 +-
.../drm/arm/display/komeda/komeda_pipeline.h | 4 +
.../display/komeda/komeda_pipeline_state.c| 18 -
.../gpu/drm/arm/display/komeda/komeda_plane.c | 15 +++-
9 files changed, 210 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index 323e5994a55c..5c9bc859f886 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -134,6 +134,27 @@ static u32 to_rot_ctrl(u32 rot)
return lr_ctrl;
}
+static u32 to_ad_ctrl(u64 modifier)
+{
+ u32 afbc_ctrl = AD_AEN;
+
+ if (!modifier)
+ return 0;
+
+ if ((modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) ==
+ AFBC_FORMAT_MOD_BLOCK_SIZE_32x8)
+ afbc_ctrl |= AD_WB;
+
+ if (modifier & AFBC_FORMAT_MOD_YTR)
+ afbc_ctrl |= AD_YT;
+ if (modifier & AFBC_FORMAT_MOD_SPLIT)
+ afbc_ctrl |= AD_BS;
+ if (modifier & AFBC_FORMAT_MOD_TILED)
+ afbc_ctrl |= AD_TH;
+
+ return afbc_ctrl;
+}
+
static inline u32 to_d71_input_id(struct komeda_component_output *output)
{
struct komeda_component *comp = output->component;
@@ -173,6 +194,24 @@ static void d71_layer_update(struct komeda_component *c,
fb->pitches[i] & 0x);
}
+ malidp_write32(reg, AD_CONTROL, to_ad_ctrl(fb->modifier));
+ if (fb->modifier) {
+ u64 addr;
+
+ malidp_write32(reg, LAYER_AD_H_CROP, HV_CROP(st->afbc_crop_l,
+st->afbc_crop_r));
+ malidp_write32(reg, LAYER_AD_V_CROP, HV_CROP(st->afbc_crop_t,
+st->afbc_crop_b));
+ /* afbc 1.2 wants payload, afbc 1.0/1.1 wants end_addr */
+ if (fb->modifier & AFBC_FORMAT_MOD_TILED)
+ addr = st->addr[0] + kfb->offset_payload;
+ else
+ addr = st->addr[0] + kfb->afbc_size - 1;
+
+ malidp_write32(reg, BLK_P1_PTR_LOW, lower_32_bits(addr));
+ malidp_write32(reg, BLK_P1_PTR_HIGH, upper_32_bits(addr));
+ }
+
malidp_write32(reg, LAYER_FMT, kfb->format_caps->hw_id);
malidp_write32(reg, BLK_IN_SIZE, HV_SIZE(st->hsize, st->vsize));
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.c
b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.c
index 1e17bd6107a4..b2195142e3f3 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.c
@@ -35,6 +35,59 @@ komeda_get_format_caps(struct komeda_format_caps_table
*table,
return NULL;
}
+/* Two assumptions
+ * 1. RGB always has YTR
+ * 2. Tiled RGB always has SC
+ */
+u64 komeda_supported_modifiers[] = {
+ /* AFBC_16x16 + features: YUV+RGB both */
+ AFBC_16x16(0),
+ /* SPARSE */
+ AFBC_16x16(_SPARSE),
+ /* YTR + (SPARSE) */
+ AFBC_16x16(_YTR | _SPARSE),
+ AFBC_16x16(_YTR),
+ /* SPLIT + SPARSE + YTR RGB only */
+ /* split mode is only allowed for sparse mode */
+ AFBC_16x16(_SPLIT | _SPARSE | _YTR),
+ /* TILED + (SPARSE) */
+ /* TILED YUV format only */
+ AFBC_16x16(_TILED | _SPARSE),
+ AFBC_16x16(_TILED),
+ /* TILED + SC + (SPLIT+SPARSE | SPARSE) + (YTR) */
+ AFBC_16x16(_TILED | _SC | _SPLIT | _SPARSE | _YTR),
+ AFBC_16x16(_TILED | _SC | _SPARSE | _YTR),
+ AFBC_16x16(_TILED | _SC | _YTR),
+ /* AFBC_32x8 + features: which are RGB formats only */
+ /* YTR + (SPARSE) */
+ AFBC_32x8(_YTR | _SPARSE),
+ AFBC_32x8(_YTR),
+ /* SPLIT + SPARSE + (YTR) */
+ /* split mode is only allowed for sparse mode */
+ AFBC_32x8(_SPLIT | _SPARSE | _YTR),
+ /* TILED + SC + (SPLIT+SPARSE | SPARSE) + YTR */
+ AFBC_32x8(_TILED | _SC | _SPLIT | _SPARSE | _YTR),
+ AFBC_32x8(_TILED | _SC | _SPARSE | _YTR),
+ AFBC_32x8(_TILED | _SC | _YTR),
+ DRM_FORMAT_MOD_LINEAR,
+
Re: [Intel-gfx] [v11 00/12] Add HDR Metadata Parsing and handling in DRM layer
On Thu, May 23, 2019 at 11:09:41AM +0300, Jani Nikula wrote: > On Wed, 22 May 2019, Ville Syrjälä wrote: > > Pushed the core/etc. bits to drm-misc-next so that other drivers > > can base their work on that. We'll need a backmerge to get the > > i915 stuff in via dinq. > > To avoid any confusion, drm-misc-next needs to get merged to drm-next, > which then needs to be backmerged to drm-intel-next-queued. We don't do > merges from drm-misc-next to drm-intel-next-queued directly. Yeah, I mentioned this also on some internal thread for clarification, just to make it clear that backmerges aren't instant. There's apparently also confusing about drm-tip, seems like people didn't know that drm-tip != drm-intel.git and that stuff fromm drm-misc immediately shows up in drm-tip ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/vmwgfx: use core drm to extend/check vmw_execbuf_ioctl
On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Currently vmw_execbuf_ioctl() open-codes the permission checking,
> size
> extending and copying that is already done in core drm.
>
> Kill all the duplication, adding a few comments for clarity.
>
> Cc: "VMware Graphics"
> Cc: Thomas Hellstrom
> Cc: Daniel Vetter
> Signed-off-by: Emil Velikov
Tested using piglit quick using execbuf versions 1 and 2.
Tested-by: Thomas Hellstrom
Reviewed-by: Thomas Hellstrom
> ---
> Thomas, VMware team,
>
> Please give this some testing on your end. I've only tested it
> against
> mesa-master.
>
> Thanks
> Emil
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 12 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 52 +
>
> 3 files changed, 23 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index d3f108f7e52d..2cb6ae219e43 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -186,7 +186,7 @@ static const struct drm_ioctl_desc vmw_ioctls[] =
> {
> DRM_RENDER_ALLOW),
> VMW_IOCTL_DEF(VMW_REF_SURFACE, vmw_surface_reference_ioctl,
> DRM_AUTH | DRM_RENDER_ALLOW),
> - VMW_IOCTL_DEF(VMW_EXECBUF, NULL, DRM_AUTH |
> + VMW_IOCTL_DEF(VMW_EXECBUF, vmw_execbuf_ioctl, DRM_AUTH |
> DRM_RENDER_ALLOW),
> VMW_IOCTL_DEF(VMW_FENCE_WAIT, vmw_fence_obj_wait_ioctl,
> DRM_RENDER_ALLOW),
> @@ -1140,15 +1140,7 @@ static long vmw_generic_ioctl(struct file
> *filp, unsigned int cmd,
> _ioctls[nr - DRM_COMMAND_BASE];
>
> if (nr == DRM_COMMAND_BASE + DRM_VMW_EXECBUF) {
> - ret = (long) drm_ioctl_permit(ioctl->flags,
> file_priv);
> - if (unlikely(ret != 0))
> - return ret;
> -
> - if (unlikely((cmd & (IOC_IN | IOC_OUT)) !=
> IOC_IN))
> - goto out_io_encoding;
> -
> - return (long) vmw_execbuf_ioctl(dev, arg,
> file_priv,
> - _IOC_SIZE(cmd))
> ;
> + return ioctl_func(filp, cmd, arg);
> } else if (nr == DRM_COMMAND_BASE +
> DRM_VMW_UPDATE_LAYOUT) {
> if (!drm_is_current_master(file_priv) &&
> !capable(CAP_SYS_ADMIN))
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> index 9be2176cc260..f5bfac85f793 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> @@ -910,8 +910,8 @@ static inline struct page *vmw_piter_page(struct
> vmw_piter *viter)
> * Command submission - vmwgfx_execbuf.c
> */
>
> -extern int vmw_execbuf_ioctl(struct drm_device *dev, unsigned long
> data,
> - struct drm_file *file_priv, size_t size);
> +extern int vmw_execbuf_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file_priv);
> extern int vmw_execbuf_process(struct drm_file *file_priv,
> struct vmw_private *dev_priv,
> void __user *user_commands,
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> index 2ff7ba04d8c8..767e2b99618d 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> @@ -3977,54 +3977,40 @@ void vmw_execbuf_release_pinned_bo(struct
> vmw_private *dev_priv)
> mutex_unlock(_priv->cmdbuf_mutex);
> }
>
> -int vmw_execbuf_ioctl(struct drm_device *dev, unsigned long data,
> - struct drm_file *file_priv, size_t size)
> +int vmw_execbuf_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file_priv)
> {
> struct vmw_private *dev_priv = vmw_priv(dev);
> - struct drm_vmw_execbuf_arg arg;
> + struct drm_vmw_execbuf_arg *arg = data;
> int ret;
> - static const size_t copy_offset[] = {
> - offsetof(struct drm_vmw_execbuf_arg, context_handle),
> - sizeof(struct drm_vmw_execbuf_arg)};
> struct dma_fence *in_fence = NULL;
>
> - if (unlikely(size < copy_offset[0])) {
> - VMW_DEBUG_USER("Invalid command size, ioctl %d\n",
> -DRM_VMW_EXECBUF);
> - return -EINVAL;
> - }
> -
> - if (copy_from_user(, (void __user *) data, copy_offset[0])
> != 0)
> - return -EFAULT;
> -
> /*
>* Extend the ioctl argument while maintaining backwards
> compatibility:
> - * We take different code paths depending on the value of
> arg.version.
> + * We take different code paths depending on the value of arg-
> >version.
> + *
> + * Note: The
Re: [PATCH 5/6] dt-bindings: Add ANX6345 DP/eDP transmitter binding
On Thu, May 23, 2019 at 08:54:00AM +0200, Torsten Duwe wrote: > From: Icenowy Zheng > > The anx6345 is an ultra-low power DisplayPort/eDP transmitter designed > for portable devices. > > Add a binding document for it. > > Signed-off-by: Icenowy Zheng > Signed-off-by: Vasily Khoruzhick > Reviewed-by: Rob Herring > Signed-off-by: Torsten Duwe > --- > .../bindings/display/bridge/anx6345.txt | 56 +++ > 1 file changed, 56 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/anx6345.txt > > diff --git a/Documentation/devicetree/bindings/display/bridge/anx6345.txt > b/Documentation/devicetree/bindings/display/bridge/anx6345.txt > new file mode 100644 > index ..e79a11348d11 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/bridge/anx6345.txt > @@ -0,0 +1,56 @@ > +Analogix ANX6345 eDP Transmitter > + > + > +The ANX6345 is an ultra-low power Full-HD eDP transmitter designed for > +portable devices. > + > +Required properties: > + > + - compatible: "analogix,anx6345" > + - reg : I2C address of the device > + - reset-gpios : Which GPIO to use for reset > + - dvdd12-supply : Regulator for 1.2V digital core power. > + - dvdd25-supply : Regulator for 2.5V digital core power. > + > +Optional properties: > + > + - Video ports for RGB input and eDP output using the DT bindings > + defined in [1] The output node can be optional, but the input one is probably going to be needed all the time, since otherwise you won't be able to fill the output port of the upstream device in the graph. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [PATCH 10/10] drm/amdgpu: stop removing BOs from the LRU v3
Leaving BOs on the LRU is harmless. We always did this for VM page table
and per VM BOs.
The key point is that BOs which couldn't be reserved can't be evicted.
So what happened is that an application used basically all of VRAM
during CS and because of this X server couldn't pin a BO for scanout.
Now we keep the BOs on the LRU and modify TTM to block for the CS to
complete, which in turn allows the X server to pin its BO for scanout.
Christian.
Am 22.05.19 um 21:43 schrieb Kuehling, Felix:
Can you explain how this avoids OOM situations? When is it safe to leave
a reserved BO on the LRU list? Could we do the same thing in
amdgpu_amdkfd_gpuvm.c? And if we did, what would be the expected side
effects or consequences?
Thanks,
Felix
On 2019-05-22 8:59 a.m., Christian König wrote:
[CAUTION: External Email]
This avoids OOM situations when we have lots of threads
submitting at the same time.
v3: apply this to the whole driver, not just CS
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 20f2955d2a55..3e2da24cd17a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -648,7 +648,7 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser *p,
}
r = ttm_eu_reserve_buffers(>ticket, >validated, true,
- , true);
+ , false);
if (unlikely(r != 0)) {
if (r != -ERESTARTSYS)
DRM_ERROR("ttm_eu_reserve_buffers failed.\n");
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
index 06f83cac0d3a..f660628e6af9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
@@ -79,7 +79,7 @@ int amdgpu_map_static_csa(struct amdgpu_device *adev, struct
amdgpu_vm *vm,
list_add(_tv.head, );
amdgpu_vm_get_pd_bo(vm, , );
- r = ttm_eu_reserve_buffers(, , true, NULL, true);
+ r = ttm_eu_reserve_buffers(, , true, NULL, false);
if (r) {
DRM_ERROR("failed to reserve CSA,PD BOs: err=%d\n", r);
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index d513a5ad03dd..ed25a4e14404 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -171,7 +171,7 @@ void amdgpu_gem_object_close(struct drm_gem_object *obj,
amdgpu_vm_get_pd_bo(vm, , _pd);
- r = ttm_eu_reserve_buffers(, , false, , true);
+ r = ttm_eu_reserve_buffers(, , false, , false);
if (r) {
dev_err(adev->dev, "leaking bo va because "
"we fail to reserve bo (%d)\n", r);
@@ -608,7 +608,7 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data,
amdgpu_vm_get_pd_bo(>vm, , _pd);
- r = ttm_eu_reserve_buffers(, , true, , true);
+ r = ttm_eu_reserve_buffers(, , true, , false);
if (r)
goto error_unref;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index c430e8259038..d60593cc436e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -155,7 +155,7 @@ static inline int amdgpu_bo_reserve(struct amdgpu_bo *bo,
bool no_intr)
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
int r;
- r = ttm_bo_reserve(>tbo, !no_intr, false, NULL);
+ r = __ttm_bo_reserve(>tbo, !no_intr, false, NULL);
if (unlikely(r != 0)) {
if (r != -ERESTARTSYS)
dev_err(adev->dev, "%p reserve failed\n", bo);
--
2.17.1
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/tegra: remove irrelevant DRM_UNLOCKED flag
On Wed, May 22, 2019 at 04:46:59PM +0100, Emil Velikov wrote: > From: Emil Velikov > > DRM_UNLOCKED doesn't do anything for non-legacy drivers. Remove it. > > Cc: Thierry Reding > Cc: linux-te...@vger.kernel.org > Cc: Daniel Vetter > Signed-off-by: Emil Velikov > --- > drivers/gpu/drm/tegra/drm.c | 28 ++-- > 1 file changed, 14 insertions(+), 14 deletions(-) I assume you want to take this through drm-misc? In that case: Acked-by: Thierry Reding Otherwise let me know and I'll pick it up into the Tegra tree. Thierry signature.asc Description: PGP signature ___ 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-misc tree with Linus' tree
Hi Maxime,
On Thu, 23 May 2019 10:10:22 +0200 Maxime Ripard
wrote:
>
> Hi Stephen,
>
> On Tue, May 21, 2019 at 10:51:51AM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the drm-misc tree got a conflict in:
> >
> > Documentation/devicetree/bindings/vendor-prefixes.txt
> >
> > between commit:
> >
> > 8122de54602e ("dt-bindings: Convert vendor prefixes to json-schema")
> >
> > from Linus' tree and commits:
> >
> > b4a2c0055a4f ("dt-bindings: Add vendor prefix for VXT Ltd")
> > b1b0d36bdb15 ("dt-bindings: drm/panel: simple: Add binding for TFC
> > S9700RTWV43TR-01B")
> > fbd8b69ab616 ("dt-bindings: Add vendor prefix for Evervision Electronics")
> >
> > from the drm-misc tree.
> >
> > I fixed it up (I deleted the file and added the patch below) and can
> > carry the fix as necessary. This is now fixed as far as linux-next is
> > concerned, but any non trivial conflicts should be mentioned to your
> > upstream maintainer when your tree is submitted for merging. You may
> > also want to consider cooperating with the maintainer of the conflicting
> > tree to minimise any particularly complex conflicts.
> >
> > --
> > Cheers,
> > Stephen Rothwell
> >
> > From: Stephen Rothwell
> > Date: Tue, 21 May 2019 10:48:36 +1000
> > Subject: [PATCH] dt-bindings: fix up for vendor prefixes file conversion
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > Documentation/devicetree/bindings/vendor-prefixes.yaml | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > index 83ca4816a78b..749e3c3843d0 100644
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> > @@ -287,6 +287,8 @@ patternProperties:
> > description: Everest Semiconductor Co. Ltd.
> >"^everspin,.*":
> > description: Everspin Technologies, Inc.
> > + "^evervision,.*":
> > +description: Evervision Electronics Co. Ltd.
> >"^exar,.*":
> > description: Exar Corporation
> >"^excito,.*":
> > @@ -851,6 +853,8 @@ patternProperties:
> > description: Shenzhen Techstar Electronics Co., Ltd.
> >"^terasic,.*":
> > description: Terasic Inc.
> > + "^tfc,.*":
> > +description: Three Five Corp
> >"^thine,.*":
> > description: THine Electronics, Inc.
> >"^ti,.*":
> > @@ -925,6 +929,8 @@ patternProperties:
> > description: Voipac Technologies s.r.o.
> >"^vot,.*":
> > description: Vision Optical Technology Co., Ltd.
> > + "^vxt,.*"
> > +description: VXT Ltd
>
> I'm not sure whether or not you can change it, but this breaks the
> users of that file.
>
> What you want is:
>
> - "^vxt,.*"
> + "^vxt,.*:"
I have fixed my version (but I put the ':' after the '"' like the
others).
Thanks for letting me know.
--
Cheers,
Stephen Rothwell
pgp4z66cZ0pdv.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave & Daniel, Two scheduling fixes for to oversaturated (media transcoding scenarios) and their dependencies. On GVT side a reset robustness fix and context state restoring fix + error path fix caught by static checker. Regards, Joonas PS. As you are aware, -rc1 caused an explosion on the CI due to the ext4 regression, which in turn let other regressions creep in momentarily. Now there is huge backlog, so the CI results are interpreted from multiple runs. I have a good confidence on the PR, so decided to send anyway. *** drm-intel-fixes-2019-05-23: - Fix boosting of new client to be non-preemptive - Fix to actually bump ready tasks ahead of busywaits - Includes gvt-fixes-2019-05-21 The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9: Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2019-05-23 for you to fetch changes up to 57cb853d1d5b07ed4e4647ad61b0c16a9c21996e: Merge tag 'gvt-fixes-2019-05-21' of https://github.com/intel/gvt-linux into drm-intel-fixes (2019-05-21 14:37:38 +0300) - Fix boosting of new client to be non-preemptive - Fix to actually bump ready tasks ahead of busywaits - Includes gvt-fixes-2019-05-21 Chris Wilson (5): drm/i915: Rearrange i915_scheduler.c drm/i915: Pass i915_sched_node around internally drm/i915: Bump signaler priority on adding a waiter drm/i915: Downgrade NEWCLIENT to non-preemptive drm/i915: Truly bump ready tasks ahead of busywaits Dan Carpenter (1): drm/i915/gvt: Fix an error code in ppgtt_populate_spt_by_guest_entry() Joonas Lahtinen (1): Merge tag 'gvt-fixes-2019-05-21' of https://github.com/intel/gvt-linux into drm-intel-fixes Weinan (1): drm/i915/gvt: emit init breadcrumb for gvt request Yan Zhao (4): drm/i915/gvt: use cmd to restore in-context mmios to hw for gen9 platform drm/i915/gvt: Tiled Resources mmios are in-context mmios for gen9+ drm/i915/gvt: add 0x4dfc to gen9 save-restore list drm/i915/gvt: do not let TRTTE and 0x4dfc write passthrough to hardware drivers/gpu/drm/i915/gvt/cmd_parser.c | 14 +- drivers/gpu/drm/i915/gvt/gtt.c | 4 +- drivers/gpu/drm/i915/gvt/handlers.c | 15 -- drivers/gpu/drm/i915/gvt/mmio_context.c | 23 ++- drivers/gpu/drm/i915/gvt/scheduler.c| 23 ++- drivers/gpu/drm/i915/i915_priolist_types.h | 5 +- drivers/gpu/drm/i915/i915_request.c | 42 ++--- drivers/gpu/drm/i915/i915_scheduler.c | 255 +++- drivers/gpu/drm/i915/i915_scheduler_types.h | 3 +- drivers/gpu/drm/i915/intel_lrc.c| 2 +- drivers/gpu/drm/i915/selftests/intel_lrc.c | 12 +- 11 files changed, 202 insertions(+), 196 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
