Re: [PATCH 1/6] drm/i915/ttm: fix sparse warning
Am 30.01.23 um 11:12 schrieb Matthew Auld:
Sparse complains with:
drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1066:21: sparse:
expected restricted vm_fault_t [assigned] [usertype] ret
drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1066:21: sparse: got int
Fixes: 516198d317d8 ("drm/i915: audit bo->resource usage v3")
Reported-by: kernel test robot
Signed-off-by: Matthew Auld
Cc: Christian König
Acked-by: Christian König for the i915 patches.
I'm on vacation this week. going to push this to drm-misc-next when I'm
back unless someone is faster.
Thanks,
Christian.
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 7420276827a5..4758f21c91e1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1067,11 +1067,12 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
.interruptible = true,
.no_wait_gpu = true, /* should be idle already */
};
+ int err;
GEM_BUG_ON(!bo->ttm || !(bo->ttm->page_flags & TTM_TT_FLAG_SWAPPED));
- ret = ttm_bo_validate(bo, i915_ttm_sys_placement(), );
- if (ret) {
+ err = ttm_bo_validate(bo, i915_ttm_sys_placement(), );
+ if (err) {
dma_resv_unlock(bo->base.resv);
return VM_FAULT_SIGBUS;
}
Re: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini
Hi Guchun,
no, that doesn't make any sense at all.
The ready flag indicates that the scheduler is fully prepared for hw
submissions from userspace and is unrelated to the initialization
status. It's set to true after IB testing was successful and only set to
false only when a GPU reset fails and we can't get the hardware to work
any more.
Please use sched.ops instead as I suggested before.
Regards,
Christian.
Am 31.01.23 um 14:58 schrieb Chen, Guchun:
Hi Christian,
Do you think if it makes sense that we can set 'ring->sched.ready' to be true
in each ring init, even if before executing/setting up drm_sched_init in
amdgpu_device_init_schedulers? As 'ready' is a member of gpu scheduler structure.
Regards,
Guchun
-Original Message-
From: Koenig, Christian
Sent: Tuesday, January 31, 2023 6:59 PM
To: Chen, Guchun ; Alex Deucher ;
Guilherme G. Piccoli
Cc: amd-...@lists.freedesktop.org; ker...@gpiccoli.net; Pan, Xinhui ;
dri-devel@lists.freedesktop.org; Tuikov, Luben ; Limonciello, Mario
; kernel-...@igalia.com; Deucher, Alexander
Subject: Re: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching drm_sched
init/fini
Am 31.01.23 um 10:17 schrieb Chen, Guchun:
Hi Piccoli,
Please ignore my request of full dmesg log. I can reproduce the issue and get
the same failure callstack by returning early with an error code prior to
amdgpu_device_init_schedulers.
Regards,
Guchun
-Original Message-
From: Chen, Guchun
Sent: Tuesday, January 31, 2023 2:37 PM
To: Alex Deucher ; Guilherme G. Piccoli
Cc: amd-...@lists.freedesktop.org; ker...@gpiccoli.net; Pan, Xinhui
; dri-devel@lists.freedesktop.org; Tuikov, Luben
; Limonciello, Mario
; kernel-...@igalia.com; Deucher, Alexander
; Koenig, Christian
Subject: RE: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching
drm_sched init/fini
Hi Piccoli,
I agree with Alex's point, using ring->sched.name for such check is not a good
way. BTW, can you please attach a full dmesg long in bad case to help me
understand more?
Regards,
Guchun
-Original Message-
From: Alex Deucher
Sent: Tuesday, January 31, 2023 6:30 AM
To: Guilherme G. Piccoli
Cc: amd-...@lists.freedesktop.org; ker...@gpiccoli.net; Chen, Guchun
; Pan, Xinhui ;
dri-devel@lists.freedesktop.org; Tuikov, Luben ;
Limonciello, Mario ; kernel-...@igalia.com;
Deucher, Alexander ; Koenig, Christian
Subject: Re: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching
drm_sched init/fini
On Mon, Jan 30, 2023 at 4:51 PM Guilherme G. Piccoli
wrote:
+ Luben
(sorry, missed that in the first submission).
On 30/01/2023 18:45, Guilherme G. Piccoli wrote:
Currently amdgpu calls drm_sched_fini() from the fence driver sw
fini routine - such function is expected to be called only after the
respective init function - drm_sched_init() - was executed successfully.
Happens that we faced a driver probe failure in the Steam Deck
recently, and the function drm_sched_fini() was called even without
its counter-part had been previously called, causing the following oops:
amdgpu: probe of :04:00.0 failed with error -110
BUG: kernel NULL pointer dereference, address: 0090 PGD
0 P4D 0
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 609 Comm: systemd-udevd Not tainted 6.2.0-rc3-gpiccoli
#338 Hardware name: Valve Jupiter/Jupiter, BIOS F7A0113 11/04/2022
RIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched] [...] Call Trace:
amdgpu_fence_driver_sw_fini+0xc8/0xd0 [amdgpu]
amdgpu_device_fini_sw+0x2b/0x3b0 [amdgpu]
amdgpu_driver_release_kms+0x16/0x30 [amdgpu]
devm_drm_dev_init_release+0x49/0x70
[...]
To prevent that, check if the drm_sched was properly initialized for
a given ring before calling its fini counter-part.
Notice ideally we'd use sched.ready for that; such field is set as
the latest thing on drm_sched_init(). But amdgpu seems to "override"
the meaning of such field - in the above oops for example, it was a
GFX ring causing the crash, and the sched.ready field was set to
true in the ring init routine, regardless of the state of the DRM scheduler.
Hence, we ended-up using another sched field.
Fixes: 067f44c8b459 ("drm/amdgpu: avoid over-handle of fence
driver fini in s3 test (v2)")
Cc: Andrey Grodzovsky
Cc: Guchun Chen
Cc: Mario Limonciello
Signed-off-by: Guilherme G. Piccoli
---
Hi folks, first of all thanks in advance for reviews / comments!
Notice that I've used the Fixes tag more in the sense to bring it to
stable, I didn't find a good patch candidate that added the call to
drm_sched_fini(), was reaching way too old commits...so
067f44c8b459 seems a good candidate - or maybe not?
Now, with regards sched.ready, spent a bit of time to figure what
was happening...would be feasible maybe to stop using that to mark
some kind ring status? I think it should be possible to add a flag
to the ring structure for that, and free sched.ready from being
manipulate by the amdgpu driver, what's your thoughts on that?
It's been a while, but IIRC, we used to have
Re: [PATCH] drm/format-helper: Use KUNIT_EXPECT_MEMEQ macro
Am 30.01.23 um 13:55 schrieb Maíra Canal:
Commit b8a926bea8b1 ("kunit: Introduce KUNIT_EXPECT_MEMEQ and
KUNIT_EXPECT_MEMNEQ macros") introduced a new macro to compare blocks of
memory and, if the test fails, print the result in a human-friendly
format. Therefore, use KUNIT_EXPECT_MEMEQ to compare memory blocks in
replacement of the KUNIT_EXPECT_EQ macro.
Signed-off-by: Maíra Canal
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/tests/drm_format_helper_test.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
b/drivers/gpu/drm/tests/drm_format_helper_test.c
index 34e80eb6d96e..9536829c6e3a 100644
--- a/drivers/gpu/drm/tests/drm_format_helper_test.c
+++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
@@ -597,7 +597,7 @@ static void drm_test_fb_xrgb_to_xrgb1555(struct kunit
*test)
drm_fb_xrgb_to_xrgb1555(, >dst_pitch, , , >clip);
buf = le16buf_to_cpu(test, (__force const __le16 *)buf, dst_size /
sizeof(__le16));
- KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
+ KUNIT_EXPECT_MEMEQ(test, buf, result->expected, dst_size);
}
static void drm_test_fb_xrgb_to_argb1555(struct kunit *test)
@@ -628,7 +628,7 @@ static void drm_test_fb_xrgb_to_argb1555(struct kunit
*test)
drm_fb_xrgb_to_argb1555(, >dst_pitch, , , >clip);
buf = le16buf_to_cpu(test, (__force const __le16 *)buf, dst_size /
sizeof(__le16));
- KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
+ KUNIT_EXPECT_MEMEQ(test, buf, result->expected, dst_size);
}
static void drm_test_fb_xrgb_to_rgba5551(struct kunit *test)
@@ -659,7 +659,7 @@ static void drm_test_fb_xrgb_to_rgba5551(struct kunit
*test)
drm_fb_xrgb_to_rgba5551(, >dst_pitch, , , >clip);
buf = le16buf_to_cpu(test, (__force const __le16 *)buf, dst_size /
sizeof(__le16));
- KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
+ KUNIT_EXPECT_MEMEQ(test, buf, result->expected, dst_size);
}
static void drm_test_fb_xrgb_to_rgb888(struct kunit *test)
@@ -724,7 +724,7 @@ static void drm_test_fb_xrgb_to_argb(struct kunit
*test)
drm_fb_xrgb_to_argb(, >dst_pitch, , , >clip);
buf = le32buf_to_cpu(test, (__force const __le32 *)buf, dst_size /
sizeof(u32));
- KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
+ KUNIT_EXPECT_MEMEQ(test, buf, result->expected, dst_size);
}
static void drm_test_fb_xrgb_to_xrgb2101010(struct kunit *test)
@@ -786,7 +786,7 @@ static void drm_test_fb_xrgb_to_argb2101010(struct
kunit *test)
drm_fb_xrgb_to_argb2101010(, >dst_pitch, , , >clip);
buf = le32buf_to_cpu(test, (__force const __le32 *)buf, dst_size /
sizeof(u32));
- KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
+ KUNIT_EXPECT_MEMEQ(test, buf, result->expected, dst_size);
}
static struct kunit_case drm_format_helper_test_cases[] = {
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Necessity for using the component helper library for DRM drivers.
Hi, I am new to the Linux and DRM framework in Linux. I was going through some reference drivers like VC4, exynos, etnaviv, Renesas (rcar-du), rockchip. Almost in all these cases, they use a component helpers to glue together the different IPs under the hood of a pseudo master driver. It should also be possible to let the individual components probe on their own, and they individually register with the DRM core to provide the required functionality. If an SoC contains different IP blocks to render and driver the display, should we not go with the basic probing for each individual IP and then register with the DRM core, rather than bringing it under one hood. Are there any inherent benefits for doing things the other way? Sorry for asking if it is too obvious. Thanks Yogender Arya
Re: [PATCH v2 1/1] tee: new ioctl to a register tee_shm from a dmabuf file descriptor
Hi Olivier,
On Fri, 27 Jan 2023 at 16:24, Olivier Masse wrote:
>
> Hi Joakim,
> Hi Etienne,
>
> Let me bring back this pull request for OPTEE Linux driver.
>
> Last feedback was from Christian König and Sumit Garg.
> From Christian:
> > Just two comments:
> >
> > 1. Dmitry is working on a change which renames some functions and
> > makes
> > it mandatory to call them with the dma_resv lock held.
> >
> > Depending on how you want to upstream this change you will certainly
> > run
> > into conflicts with that.
>
> Is there any update on these changes ?
>
> >
> > 2. Would it be possible to do this dynamically? In other words does
> > the
> > tee driver has a concept of buffers moving around?
>
> We do not support dynamic secure memory heap.
>
> From Sumit:
> > What limits you to extend this feature to non-contiguous memory
> > buffers? I believe that should be possible with OP-TEE dynamic shared
> > memory which gives you the granularity to register a list of pages.
>
> Our solution use a fixed protected reserved memory region and do not
> rely on a dynamic protection managed in secure.
>
> The scope of this implementation rely on a static memory region handled
> by a specific DMA Heap type.
>
AFAIR, the last review for v2 is here [1]. So we need to have this
secure DMA heap upstream in order for ioctl added by this patch to be
usable.
[1]
https://lists.trustedfirmware.org/archives/list/op-...@lists.trustedfirmware.org/message/M3WLO7RNG22OR4744BY6XNG2GLIYMNHN/
-Sumit
> Best regards,
> Olivier MASSE
>
>
> On ven., 2022-08-12 at 16:30 +0200, Olivier Masse wrote:
> > From: Etienne Carriere
> >
> > This change allows userland to create a tee_shm object that refers
> > to a dmabuf reference.
> >
> > Userland provides a dmabuf file descriptor as buffer reference.
> > The created tee_shm object exported as a brand new dmabuf reference
> > used to provide a clean fd to userland. Userland shall closed this
> > new
> > fd to release the tee_shm object resources. The initial dmabuf
> > resources
> > are tracked independently through original dmabuf file descriptor.
> >
> > Once the buffer is registered and until it is released, TEE driver
> > keeps a refcount on the registered dmabuf structure.
> >
> > This change only support dmabuf references that relates to physically
> > contiguous memory buffers.
> >
> > New tee_shm flag to identify tee_shm objects built from a registered
> > dmabuf: TEE_SHM_EXT_DMA_BUF. Such tee_shm structures are flagged with
> > TEE_SHM_EXT_DMA_BUF.
> >
> > Co-Developed-by: Etienne Carriere
> > Signed-off-by: Olivier Masse
> > Reported-by: kernel test robot
> > From: https://github.com/linaro-swg/linux.git
> > (cherry picked from commit 41e21e5c405530590dc2dd10b2a8dbe64589840f)
> > ---
> > drivers/tee/tee_core.c | 38 +++
> > drivers/tee/tee_shm.c| 99
> > +++-
> > include/linux/tee_drv.h | 11 +
> > include/uapi/linux/tee.h | 29
> > 4 files changed, 175 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
> > index 8aa1a4836b92..7c45cbf85eb9 100644
> > --- a/drivers/tee/tee_core.c
> > +++ b/drivers/tee/tee_core.c
> > @@ -355,6 +355,42 @@ tee_ioctl_shm_register(struct tee_context *ctx,
> > return ret;
> > }
> >
> > +static int tee_ioctl_shm_register_fd(struct tee_context *ctx,
> > + struct
> > tee_ioctl_shm_register_fd_data __user *udata)
> > +{
> > + struct tee_ioctl_shm_register_fd_data data;
> > + struct tee_shm *shm;
> > + long ret;
> > +
> > + if (copy_from_user(, udata, sizeof(data)))
> > + return -EFAULT;
> > +
> > + /* Currently no input flags are supported */
> > + if (data.flags)
> > + return -EINVAL;
> > +
> > + shm = tee_shm_register_fd(ctx, data.fd);
> > + if (IS_ERR(shm))
> > + return -EINVAL;
> > +
> > + data.id = shm->id;
> > + data.flags = shm->flags;
> > + data.size = shm->size;
> > +
> > + if (copy_to_user(udata, , sizeof(data)))
> > + ret = -EFAULT;
> > + else
> > + ret = tee_shm_get_fd(shm);
> > +
> > + /*
> > + * When user space closes the file descriptor the shared memory
> > + * should be freed or if tee_shm_get_fd() failed then it will
> > + * be freed immediately.
> > + */
> > + tee_shm_put(shm);
> > + return ret;
> > +}
> > +
> > static int params_from_user(struct tee_context *ctx, struct
> > tee_param *params,
> > size_t num_params,
> > struct tee_ioctl_param __user *uparams)
> > @@ -829,6 +865,8 @@ static long tee_ioctl(struct file *filp, unsigned
> > int cmd, unsigned long arg)
> > return tee_ioctl_shm_alloc(ctx, uarg);
> > case TEE_IOC_SHM_REGISTER:
> > return tee_ioctl_shm_register(ctx, uarg);
> > + case TEE_IOC_SHM_REGISTER_FD:
> > + return
Re: [PATCH] drm/format-helper: Use KUNIT_EXPECT_MEMEQ macro
On Mon, 30 Jan 2023 at 20:58, Maíra Canal wrote:
>
> Commit b8a926bea8b1 ("kunit: Introduce KUNIT_EXPECT_MEMEQ and
> KUNIT_EXPECT_MEMNEQ macros") introduced a new macro to compare blocks of
> memory and, if the test fails, print the result in a human-friendly
> format. Therefore, use KUNIT_EXPECT_MEMEQ to compare memory blocks in
> replacement of the KUNIT_EXPECT_EQ macro.
>
> Signed-off-by: Maíra Canal
> ---
Looks good to me! (I'd vaguely assumed we'd already updated these
tests, but apparently not...)
I expect this'll go in via one of the DRM trees, not the KUnit one (it
doesn't apply to the kselftest/kunit tree as-is).
Reviewed-by: David Gow
Cheers,
-- David
> drivers/gpu/drm/tests/drm_format_helper_test.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c
> b/drivers/gpu/drm/tests/drm_format_helper_test.c
> index 34e80eb6d96e..9536829c6e3a 100644
> --- a/drivers/gpu/drm/tests/drm_format_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
> @@ -597,7 +597,7 @@ static void drm_test_fb_xrgb_to_xrgb1555(struct kunit
> *test)
>
> drm_fb_xrgb_to_xrgb1555(, >dst_pitch, , ,
> >clip);
> buf = le16buf_to_cpu(test, (__force const __le16 *)buf, dst_size /
> sizeof(__le16));
> - KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
> + KUNIT_EXPECT_MEMEQ(test, buf, result->expected, dst_size);
> }
>
> static void drm_test_fb_xrgb_to_argb1555(struct kunit *test)
> @@ -628,7 +628,7 @@ static void drm_test_fb_xrgb_to_argb1555(struct kunit
> *test)
>
> drm_fb_xrgb_to_argb1555(, >dst_pitch, , ,
> >clip);
> buf = le16buf_to_cpu(test, (__force const __le16 *)buf, dst_size /
> sizeof(__le16));
> - KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
> + KUNIT_EXPECT_MEMEQ(test, buf, result->expected, dst_size);
> }
>
> static void drm_test_fb_xrgb_to_rgba5551(struct kunit *test)
> @@ -659,7 +659,7 @@ static void drm_test_fb_xrgb_to_rgba5551(struct kunit
> *test)
>
> drm_fb_xrgb_to_rgba5551(, >dst_pitch, , ,
> >clip);
> buf = le16buf_to_cpu(test, (__force const __le16 *)buf, dst_size /
> sizeof(__le16));
> - KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
> + KUNIT_EXPECT_MEMEQ(test, buf, result->expected, dst_size);
> }
>
> static void drm_test_fb_xrgb_to_rgb888(struct kunit *test)
> @@ -724,7 +724,7 @@ static void drm_test_fb_xrgb_to_argb(struct kunit
> *test)
>
> drm_fb_xrgb_to_argb(, >dst_pitch, , ,
> >clip);
> buf = le32buf_to_cpu(test, (__force const __le32 *)buf, dst_size /
> sizeof(u32));
> - KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
> + KUNIT_EXPECT_MEMEQ(test, buf, result->expected, dst_size);
> }
>
> static void drm_test_fb_xrgb_to_xrgb2101010(struct kunit *test)
> @@ -786,7 +786,7 @@ static void drm_test_fb_xrgb_to_argb2101010(struct
> kunit *test)
>
> drm_fb_xrgb_to_argb2101010(, >dst_pitch, , ,
> >clip);
> buf = le32buf_to_cpu(test, (__force const __le32 *)buf, dst_size /
> sizeof(u32));
> - KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
> + KUNIT_EXPECT_MEMEQ(test, buf, result->expected, dst_size);
> }
>
> static struct kunit_case drm_format_helper_test_cases[] = {
> --
> 2.39.1
>
smime.p7s
Description: S/MIME Cryptographic Signature
Re: linux-next: manual merge of the usb tree with the drm-intel-fixes tree
Hi all,
On Tue, 31 Jan 2023 10:27:29 -0800 John Harrison
wrote:
>
> On 1/31/2023 04:44, Andy Shevchenko wrote:
> > On Tue, Jan 31, 2023 at 01:03:05PM +1100, Stephen Rothwell wrote:
> >>
> >> Today's linux-next merge of the usb tree got a conflict in:
> >>
> >>drivers/gpu/drm/i915/gt/intel_engine_cs.c
> >>
> >> between commit:
> >>
> >>5bc4b43d5c6c ("drm/i915: Fix up locking around dumping requests lists")
> >>
> >> from the drm-intel-fixes tree and commit:
> >>
> >>4d70c74659d9 ("i915: Move list_count() to list.h as list_count_nodes()
> >> for broader use")
> >>
> >> from the usb tree.
> >>
> >> I fixed it up (the former removed the code changed by the latter)
> > Hmm... Currently I see that
> > 20230127002842.3169194-4-john.c.harri...@intel.com
> > moves the code to the drivers/gpu/drm/i915/gt/intel_execlists_submission.c.
> >
> > Is there any new series beside the above mentioned that touches that file
> > and
> > actually _removes_ that code?
> As long as the removal is limited to list_count/list_count_nodes,
> that's fine. I only moved it from one file to another because the one
> and only function that was using it was being moved to the other
> file. If someone else has found a use for the same and wants to move
> it to a more common place then great. I assume there was no conflict
> happening in the i915 specific code.
I have added this fix up patch to linux-next today (more or less - this
is a hand hacked version, but you get the idea):
From: Stephen Rothwell
Date: Wed, 1 Feb 2023 13:13:01 +1100
Subject: [PATCH] i915: fix up for "drm/i915: Fix up locking around dumping
requests lists"
interacting with "i915: Move list_count() to list.h as list_count_nodes() for
broader use"
Signed-off-by: Stephen Rothwell
---
.../gpu/drm/i915/gt/intel_execlists_submission.c| 15 +
1 file changed, 2 insertion(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 3c573d41d404..e919d41a48d9 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -4150,17 +4150,6 @@ void intel_execlists_show_requests(struct
intel_engine_cs *engine,
spin_unlock_irqrestore(_engine->lock, flags);
}
-static unsigned long list_count(struct list_head *list)
-{
- struct list_head *pos;
- unsigned long count = 0;
-
- list_for_each(pos, list)
- count++;
-
- return count;
-}
-
void intel_execlists_dump_active_requests(struct intel_engine_cs *engine,
struct i915_request *hung_rq,
struct drm_printer *m)
@@ -4172,7 +4161,7 @@ void intel_execlists_dump_active_requests(struct
intel_engine_cs *engine,
intel_engine_dump_active_requests(>sched_engine->requests,
hung_rq, m);
- drm_printf(m, "\tOn hold?: %lu\n",
- list_count(>sched_engine->hold));
+ drm_printf(m, "\tOn hold?: %zu\n",
+ list_count_nodes(>sched_engine->hold));
spin_unlock_irqrestore(>sched_engine->lock, flags);
}
--
2.35.1
--
Cheers,
Stephen Rothwell
pgpWA76dHJ3xE.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 1/4] memcg: Track exported dma-buffers
On Tue, Jan 31, 2023 at 6:01 AM Tvrtko Ursulin wrote: > > > On 25/01/2023 20:04, T.J. Mercier wrote: > > On Wed, Jan 25, 2023 at 9:31 AM Tvrtko Ursulin > > wrote: > >> > >> > >> Hi, > >> > >> On 25/01/2023 11:52, Michal Hocko wrote: > >>> On Tue 24-01-23 19:46:28, Shakeel Butt wrote: > On Tue, Jan 24, 2023 at 03:59:58PM +0100, Michal Hocko wrote: > > On Mon 23-01-23 19:17:23, T.J. Mercier wrote: > >> When a buffer is exported to userspace, use memcg to attribute the > >> buffer to the allocating cgroup until all buffer references are > >> released. > > > > Is there any reason why this memory cannot be charged during the > > allocation (__GFP_ACCOUNT used)? > > Also you do charge and account the memory but underlying pages do not > > know about their memcg (this is normally done with commit_charge for > > user mapped pages). This would become a problem if the memory is > > migrated for example. > > I don't think this is movable memory. > > > This also means that you have to maintain memcg > > reference outside of the memcg proper which is not really nice either. > > This mimicks tcp kmem limit implementation which I really have to say I > > am not a great fan of and this pattern shouldn't be coppied. > > > > I think we should keep the discussion on technical merits instead of > personal perference. To me using skmem like interface is totally fine > but the pros/cons need to be very explicit and the clear reasons to > select that option should be included. > >>> > >>> I do agree with that. I didn't want sound to be personal wrt tcp kmem > >>> accounting but the overall code maintenance cost is higher because > >>> of how tcp take on accounting differs from anything else in the memcg > >>> proper. I would prefer to not grow another example like that. > >>> > To me there are two options: > > 1. Using skmem like interface as this patch series: > > The main pros of this option is that it is very simple. Let me list down > the cons of this approach: > > a. There is time window between the actual memory allocation/free and > the charge and uncharge and [un]charge happen when the whole memory is > allocated or freed. I think for the charge path that might not be a big > issue but on the uncharge, this can cause issues. The application and > the potential shrinkers have freed some of this dmabuf memory but until > the whole dmabuf is freed, the memcg uncharge will not happen. This can > consequences on reclaim and oom behavior of the application. > > b. Due to the usage model i.e. a central daemon allocating the dmabuf > memory upfront, there is a requirement to have a memcg charge transfer > functionality to transfer the charge from the central daemon to the > client applications. This does introduce complexity and avenues of weird > reclaim and oom behavior. > > > 2. Allocate and charge the memory on page fault by actual user > > In this approach, the memory is not allocated upfront by the central > daemon but rather on the page fault by the client application and the > memcg charge happen at the same time. > > The only cons I can think of is this approach is more involved and may > need some clever tricks to track the page on the free patch i.e. we to > decrement the dmabuf memcg stat on free path. Maybe a page flag. > > The pros of this approach is there is no need have a charge transfer > functionality and the charge/uncharge being closely tied to the actual > memory allocation and free. > > Personally I would prefer the second approach but I don't want to just > block this work if the dmabuf folks are ok with the cons mentioned of > the first approach. > >>> > >>> I am not familiar with dmabuf internals to judge complexity on their end > >>> but I fully agree that charge-when-used is much more easier to reason > >>> about and it should have less subtle surprises. > >> > >> Disclaimer that I don't seem to see patches 3&4 on dri-devel so maybe I > >> am missing something, but in principle yes, I agree that the 2nd option > >> (charge the user, not exporter) should be preferred. Thing being that at > >> export time there may not be any backing store allocated, plus if the > >> series is restricting the charge transfer to just Android clients then > >> it seems it has the potential to miss many other use cases. At least > >> needs to outline a description on how the feature will be useful outside > >> Android. > >> > > There is no restriction like that. It's available to anybody who wants > > to call dma_buf_charge_transfer if they actually have a need for that, > > which I don't really expect to be common since most users/owners of > > the buffers will be the ones causing the export in the first place. > > It's
Re: [PATCH v4 02/21] dt-bindings: display: tegra: vi: add 'vip' property and example
On Mon, 30 Jan 2023 15:15:44 +0100, Luca Ceresoli wrote: > The Tegra20 VI peripheral can receive parallel input from the VIP parallel > input module. Add it to the allowed properties and augment the existing > nvidia,tegra20-vi example to show a 'vip' property. > > Signed-off-by: Luca Ceresoli > > --- > > Changed in v4: > - complete the removal of 'channel@0' > > Changed in v3 (suggested by Rob Herring): > - drop 'endpoint', unneeded as there's no extra properties in the >endpoints > > Changed in v2 (suggested by Krzysztof Kozlowski): > - rename "i2c3" -> "ic2" > - add review tag > --- > .../display/tegra/nvidia,tegra20-vi.yaml | 59 +++ > MAINTAINERS | 1 + > 2 files changed, 60 insertions(+) > Reviewed-by: Rob Herring
Re: [PATCH v2 8/8] drm/vmwgfx: Stop using raw ttm_buffer_object's
On 1/30/23 19:35, Zack Rusin wrote:
> From: Zack Rusin
>
> Various bits of the driver used raw ttm_buffer_object instead of the
> driver specific vmw_bo object. All those places used to duplicate
> the mapped bo caching policy of vmw_bo.
>
> Instead of duplicating all of that code and special casing various
> functions to work both with vmw_bo and raw ttm_buffer_object's unify
> the buffer object handling code.
>
> As part of that work fix the naming of bo's, e.g. insted of generic
> backup use 'guest_memory' because that's what it really is.
>
> All of it makes the driver easier to maintain and the code easier to
> read. Saves 100+ loc as well.
>
> Signed-off-by: Zack Rusin
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 204 +---
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.h| 60 ++---
> drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c | 4 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c| 44 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 16 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 51 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 17 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 53 +++--
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 14 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 37 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 105 -
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 6 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_mob.c | 38 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c| 51 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 220 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_resource_priv.h | 7 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 29 ++-
> drivers/gpu/drm/vmwgfx/vmwgfx_shader.c| 49 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_so.c| 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 8 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_streamoutput.c | 8 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 98
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c| 66 ++
> drivers/gpu/drm/vmwgfx/vmwgfx_va.c| 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_validation.c| 62 +++--
> 27 files changed, 566 insertions(+), 691 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> index d8f6ccecf4bf..63486802c8fd 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> @@ -32,6 +32,12 @@
>
> #include
>
> +static void vmw_bo_release(struct vmw_bo *vbo)
> +{
> + vmw_bo_unmap(vbo);
> + drm_gem_object_release(>tbo.base);
> +}
> +
> /**
> * vmw_bo_free - vmw_bo destructor
> *
> @@ -43,26 +49,10 @@ static void vmw_bo_free(struct ttm_buffer_object *bo)
>
> WARN_ON(vbo->dirty);
> WARN_ON(!RB_EMPTY_ROOT(>res_tree));
> - vmw_bo_unmap(vbo);
> - drm_gem_object_release(>base);
> + vmw_bo_release(vbo);
> kfree(vbo);
> }
>
> -/**
> - * bo_is_vmw - check if the buffer object is a _bo
> - * @bo: ttm buffer object to be checked
> - *
> - * Uses destroy function associated with the object to determine if this is
> - * a _bo.
> - *
> - * Returns:
> - * true if the object is of _bo type, false if not.
> - */
> -static bool bo_is_vmw(struct ttm_buffer_object *bo)
> -{
> - return bo->destroy == _bo_free;
> -}
> -
> /**
> * vmw_bo_pin_in_placement - Validate a buffer to placement.
> *
> @@ -79,7 +69,7 @@ static int vmw_bo_pin_in_placement(struct vmw_private
> *dev_priv,
> bool interruptible)
> {
> struct ttm_operation_ctx ctx = {interruptible, false };
> - struct ttm_buffer_object *bo = >base;
> + struct ttm_buffer_object *bo = >tbo;
> int ret;
>
> vmw_execbuf_release_pinned_bo(dev_priv);
> @@ -88,7 +78,7 @@ static int vmw_bo_pin_in_placement(struct vmw_private
> *dev_priv,
> if (unlikely(ret != 0))
> goto err;
>
> - if (buf->base.pin_count > 0)
> + if (buf->tbo.pin_count > 0)
> ret = ttm_resource_compat(bo->resource, placement)
> ? 0 : -EINVAL;
> else
> @@ -120,7 +110,7 @@ int vmw_bo_pin_in_vram_or_gmr(struct vmw_private
> *dev_priv,
> bool interruptible)
> {
> struct ttm_operation_ctx ctx = {interruptible, false };
> - struct ttm_buffer_object *bo = >base;
> + struct ttm_buffer_object *bo = >tbo;
> int ret;
>
> vmw_execbuf_release_pinned_bo(dev_priv);
> @@ -129,7 +119,7 @@ int vmw_bo_pin_in_vram_or_gmr(struct vmw_private
> *dev_priv,
> if (unlikely(ret != 0))
> goto err;
>
> - if (buf->base.pin_count > 0) {
> + if (buf->tbo.pin_count > 0) {
> ret = ttm_resource_compat(bo->resource, _vram_gmr_placement)
> ? 0 :
Re: [PATCH v2 7/8] drm/vmwgfx: Abstract placement selection
On 1/30/23 19:35, Zack Rusin wrote:
> From: Zack Rusin
>
> Problem with explicit placement selection in vmwgfx is that by the time
> the buffer object needs to be validated the information about which
> placement was supposed to be used is lost. To workaround this the driver
> had a bunch of state in various places e.g. as_mob or cpu_blit to
> somehow convey the information on which placement was intended.
>
> Fix it properly by allowing the buffer objects to hold their preferred
> placement so it can be reused whenever needed. This makes the entire
> validation pipeline a lot easier both to understand and maintain.
>
> Signed-off-by: Zack Rusin
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 145 +++--
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.h| 25 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 9 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 11 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 3 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 2 -
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 35 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 5 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 22 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 21 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 11 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_resource_priv.h | 3 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 13 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_shader.c| 15 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_so.c| 4 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 304 ++
> drivers/gpu/drm/vmwgfx/vmwgfx_streamoutput.c | 3 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 6 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c| 47 ---
> drivers/gpu/drm/vmwgfx/vmwgfx_va.c| 4 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_validation.c| 74 ++---
> drivers/gpu/drm/vmwgfx/vmwgfx_validation.h| 6 +-
> 22 files changed, 312 insertions(+), 456 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> index c6dc733f6d45..d8f6ccecf4bf 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> @@ -135,11 +135,17 @@ int vmw_bo_pin_in_vram_or_gmr(struct vmw_private
> *dev_priv,
> goto out_unreserve;
> }
>
> - ret = ttm_bo_validate(bo, _vram_gmr_placement, );
> + vmw_bo_placement_set(buf,
> + VMW_BO_DOMAIN_GMR | VMW_BO_DOMAIN_VRAM,
> + VMW_BO_DOMAIN_GMR);
> + ret = ttm_bo_validate(bo, >placement, );
> if (likely(ret == 0) || ret == -ERESTARTSYS)
> goto out_unreserve;
>
> - ret = ttm_bo_validate(bo, _vram_placement, );
> + vmw_bo_placement_set(buf,
> + VMW_BO_DOMAIN_VRAM,
> + VMW_BO_DOMAIN_VRAM);
> + ret = ttm_bo_validate(bo, >placement, );
>
> out_unreserve:
> if (!ret)
> @@ -190,17 +196,8 @@ int vmw_bo_pin_in_start_of_vram(struct vmw_private
> *dev_priv,
> {
> struct ttm_operation_ctx ctx = {interruptible, false };
> struct ttm_buffer_object *bo = >base;
> - struct ttm_placement placement;
> - struct ttm_place place;
> int ret = 0;
>
> - place = vmw_vram_placement.placement[0];
> - place.lpfn = PFN_UP(bo->resource->size);
> - placement.num_placement = 1;
> - placement.placement =
> - placement.num_busy_placement = 1;
> - placement.busy_placement =
> -
> vmw_execbuf_release_pinned_bo(dev_priv);
> ret = ttm_bo_reserve(bo, interruptible, false, NULL);
> if (unlikely(ret != 0))
> @@ -216,14 +213,21 @@ int vmw_bo_pin_in_start_of_vram(struct vmw_private
> *dev_priv,
> bo->resource->start > 0 &&
> buf->base.pin_count == 0) {
> ctx.interruptible = false;
> - (void) ttm_bo_validate(bo, _sys_placement, );
> + vmw_bo_placement_set(buf,
> + VMW_BO_DOMAIN_SYS,
> + VMW_BO_DOMAIN_SYS);
> + (void)ttm_bo_validate(bo, >placement, );
> }
>
> + vmw_bo_placement_set(buf,
> + VMW_BO_DOMAIN_VRAM,
> + VMW_BO_DOMAIN_VRAM);
> + buf->places[0].lpfn = PFN_UP(bo->resource->size);
> if (buf->base.pin_count > 0)
> - ret = ttm_resource_compat(bo->resource, )
> + ret = ttm_resource_compat(bo->resource, >placement)
> ? 0 : -EINVAL;
> else
> - ret = ttm_bo_validate(bo, , );
> + ret = ttm_bo_validate(bo, >placement, );
>
> /* For some reason we didn't end up at the start of vram */
> WARN_ON(ret == 0 && bo->resource->start != 0);
> @@ -431,7 +435,7 @@ int vmw_bo_create_kernel(struct vmw_private *dev_priv,
> unsigned long size,
> }
>
> int vmw_bo_create(struct vmw_private *vmw,
> -
Re: [PATCH v2 6/8] drm/vmwgfx: Rename dummy to is_iomem
On 1/30/23 19:35, Zack Rusin wrote:
> From: Zack Rusin
>
> Rename dummy to is_iomem because that's what it is even if we're not
> activelly using it. Makes the code easier to read.
>
> Signed-off-by: Zack Rusin
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index 1082218a1cfc..e83286e08837 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -153,9 +153,9 @@ static void vmw_cursor_update_mob(struct vmw_private
> *dev_priv,
> SVGAGBCursorHeader *header;
> SVGAGBAlphaCursorHeader *alpha_header;
> const u32 image_size = width * height * sizeof(*image);
> - bool dummy;
> + bool is_iomem;
>
> - header = ttm_kmap_obj_virtual(>cursor.map, );
> + header = ttm_kmap_obj_virtual(>cursor.map, _iomem);
> alpha_header = >header.alphaHeader;
>
> memset(header, 0, sizeof(*header));
> @@ -185,13 +185,13 @@ static u32 vmw_du_cursor_mob_size(u32 w, u32 h)
> */
> static u32 *vmw_du_cursor_plane_acquire_image(struct vmw_plane_state *vps)
> {
> - bool dummy;
> + bool is_iomem;
> if (vps->surf) {
> if (vps->surf_mapped)
> return vmw_bo_map_and_cache(vps->surf->res.backup);
> return vps->surf->snooper.image;
> } else if (vps->bo)
> - return ttm_kmap_obj_virtual(>bo->map, );
> + return ttm_kmap_obj_virtual(>bo->map, _iomem);
> return NULL;
> }
>
> @@ -364,7 +364,7 @@ void vmw_kms_cursor_snoop(struct vmw_surface *srf,
> SVGA3dCopyBox *box;
> unsigned box_count;
> void *virtual;
> - bool dummy;
> + bool is_iomem;
> struct vmw_dma_cmd {
> SVGA3dCmdHeader header;
> SVGA3dCmdSurfaceDMA dma;
> @@ -424,7 +424,7 @@ void vmw_kms_cursor_snoop(struct vmw_surface *srf,
> if (unlikely(ret != 0))
> goto err_unreserve;
>
> - virtual = ttm_kmap_obj_virtual(, );
> + virtual = ttm_kmap_obj_virtual(, _iomem);
>
> if (box->w == VMW_CURSOR_SNOOP_WIDTH && cmd->dma.guest.pitch ==
> image_pitch) {
> memcpy(srf->snooper.image, virtual,
> @@ -658,14 +658,14 @@ vmw_du_cursor_plane_cleanup_fb(struct drm_plane *plane,
> {
> struct vmw_cursor_plane *vcp = vmw_plane_to_vcp(plane);
> struct vmw_plane_state *vps = vmw_plane_state_to_vps(old_state);
> - bool dummy;
> + bool is_iomem;
>
> if (vps->surf_mapped) {
> vmw_bo_unmap(vps->surf->res.backup);
> vps->surf_mapped = false;
> }
>
> - if (vps->bo && ttm_kmap_obj_virtual(>bo->map, )) {
> + if (vps->bo && ttm_kmap_obj_virtual(>bo->map, _iomem)) {
> const int ret = ttm_bo_reserve(>bo->base, true, false,
> NULL);
>
> if (likely(ret == 0)) {
LGTM!
Reviewed-by: Maaz Mombasawala
--
Maaz Mombasawala (VMware)
Re: [PATCH v2 5/8] drm/vmwgfx: Cleanup the vmw bo usage in the cursor paths
On 1/30/23 19:35, Zack Rusin wrote:
> From: Zack Rusin
>
> Base mapped count is useless because the ttm unmap functions handle
> null maps just fine so completely remove all the code related to it.
>
> Signed-off-by: Zack Rusin
> Reviewed-by: Martin Krastev
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.h | 3 ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 12 +---
> 2 files changed, 1 insertion(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
> b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
> index e2dadd68a16d..2ede1e28d7ce 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
> @@ -44,7 +44,6 @@ struct vmw_resource;
> * struct vmw_bo - TTM buffer object with vmwgfx additions
> * @base: The TTM buffer object
> * @res_tree: RB tree of resources using this buffer object as a backing MOB
> - * @base_mapped_count: ttm BO mapping count; used by KMS atomic helpers.
> * @cpu_writers: Number of synccpu write grabs. Protected by reservation when
> * increased. May be decreased without reservation.
> * @dx_query_ctx: DX context if this buffer object is used as a DX query MOB
> @@ -55,8 +54,6 @@ struct vmw_resource;
> struct vmw_bo {
> struct ttm_buffer_object base;
> struct rb_root res_tree;
> - /* For KMS atomic helpers: ttm bo mapping count */
> - atomic_t base_mapped_count;
>
> atomic_t cpu_writers;
> /* Not ref-counted. Protected by binding_mutex */
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index 6780391c57ea..1082218a1cfc 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -669,8 +669,7 @@ vmw_du_cursor_plane_cleanup_fb(struct drm_plane *plane,
> const int ret = ttm_bo_reserve(>bo->base, true, false,
> NULL);
>
> if (likely(ret == 0)) {
> - if (atomic_read(>bo->base_mapped_count) == 0)
> - ttm_bo_kunmap(>bo->map);
> + ttm_bo_kunmap(>bo->map);
> ttm_bo_unreserve(>bo->base);
> }
> }
> @@ -744,9 +743,6 @@ vmw_du_cursor_plane_prepare_fb(struct drm_plane *plane,
>
> ret = ttm_bo_kmap(>bo->base, 0, PFN_UP(size),
> >bo->map);
>
> - if (likely(ret == 0))
> - atomic_inc(>bo->base_mapped_count);
> -
> ttm_bo_unreserve(>bo->base);
>
> if (unlikely(ret != 0))
> @@ -786,7 +782,6 @@ vmw_du_cursor_plane_atomic_update(struct drm_plane *plane,
> struct vmw_plane_state *vps = vmw_plane_state_to_vps(new_state);
> struct vmw_plane_state *old_vps = vmw_plane_state_to_vps(old_state);
> s32 hotspot_x, hotspot_y;
> - bool dummy;
>
> hotspot_x = du->hotspot_x;
> hotspot_y = du->hotspot_y;
> @@ -828,11 +823,6 @@ vmw_du_cursor_plane_atomic_update(struct drm_plane
> *plane,
> hotspot_x, hotspot_y);
> }
>
> - if (vps->bo) {
> - if (ttm_kmap_obj_virtual(>bo->map, ))
> - atomic_dec(>bo->base_mapped_count);
> - }
> -
> du->cursor_x = new_state->crtc_x + du->set_gui_x;
> du->cursor_y = new_state->crtc_y + du->set_gui_y;
>
LGTM!
Reviewed-by: Maaz Mombasawala
--
Maaz Mombasawala (VMware)
Re: [PATCH v2 4/8] drm/vmwgfx: Simplify fb pinning
On 1/30/23 19:35, Zack Rusin wrote:
> From: Zack Rusin
>
> Only the legacy display unit requires pinning of the fb memory in vram.
> Both the screen objects and screen targets can present from any buffer.
> That makes the pinning abstraction pointless. Simplify all of the code
> and move it to the legacy display unit, the only place that needs it.
>
> Signed-off-by: Zack Rusin
> Reviewed-by: Martin Krastev
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 8 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.h | 4 --
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 66 -
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 4 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 57 +
> 5 files changed, 54 insertions(+), 85 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> index b6dc0baef350..c6dc733f6d45 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> @@ -73,10 +73,10 @@ static bool bo_is_vmw(struct ttm_buffer_object *bo)
> * Return: Zero on success, Negative error code on failure. In particular
> * -ERESTARTSYS if interrupted by a signal
> */
> -int vmw_bo_pin_in_placement(struct vmw_private *dev_priv,
> - struct vmw_bo *buf,
> - struct ttm_placement *placement,
> - bool interruptible)
> +static int vmw_bo_pin_in_placement(struct vmw_private *dev_priv,
> +struct vmw_bo *buf,
> +struct ttm_placement *placement,
> +bool interruptible)
> {
> struct ttm_operation_ctx ctx = {interruptible, false };
> struct ttm_buffer_object *bo = >base;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
> b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
> index 03ef4059c0d2..e2dadd68a16d 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
> @@ -82,10 +82,6 @@ int vmw_bo_init(struct vmw_private *dev_priv,
> int vmw_bo_unref_ioctl(struct drm_device *dev, void *data,
> struct drm_file *file_priv);
>
> -int vmw_bo_pin_in_placement(struct vmw_private *vmw_priv,
> - struct vmw_bo *bo,
> - struct ttm_placement *placement,
> - bool interruptible);
> int vmw_bo_pin_in_vram(struct vmw_private *dev_priv,
> struct vmw_bo *buf,
> bool interruptible);
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index ad41396c0a5d..6780391c57ea 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -1487,69 +1487,6 @@ static const struct drm_framebuffer_funcs
> vmw_framebuffer_bo_funcs = {
> .dirty = vmw_framebuffer_bo_dirty_ext,
> };
>
> -/*
> - * Pin the bofer in a location suitable for access by the
> - * display system.
> - */
> -static int vmw_framebuffer_pin(struct vmw_framebuffer *vfb)
> -{
> - struct vmw_private *dev_priv = vmw_priv(vfb->base.dev);
> - struct vmw_bo *buf;
> - struct ttm_placement *placement;
> - int ret;
> -
> - buf = vfb->bo ? vmw_framebuffer_to_vfbd(>base)->buffer :
> - vmw_framebuffer_to_vfbs(>base)->surface->res.backup;
> -
> - if (!buf)
> - return 0;
> -
> - switch (dev_priv->active_display_unit) {
> - case vmw_du_legacy:
> - vmw_overlay_pause_all(dev_priv);
> - ret = vmw_bo_pin_in_start_of_vram(dev_priv, buf, false);
> - vmw_overlay_resume_all(dev_priv);
> - break;
> - case vmw_du_screen_object:
> - case vmw_du_screen_target:
> - if (vfb->bo) {
> - if (dev_priv->capabilities & SVGA_CAP_3D) {
> - /*
> - * Use surface DMA to get content to
> - * sreen target surface.
> - */
> - placement = _vram_gmr_placement;
> - } else {
> - /* Use CPU blit. */
> - placement = _sys_placement;
> - }
> - } else {
> - /* Use surface / image update */
> - placement = _mob_placement;
> - }
> -
> - return vmw_bo_pin_in_placement(dev_priv, buf, placement, false);
> - default:
> - return -EINVAL;
> - }
> -
> - return ret;
> -}
> -
> -static int vmw_framebuffer_unpin(struct vmw_framebuffer *vfb)
> -{
> - struct vmw_private *dev_priv = vmw_priv(vfb->base.dev);
> - struct vmw_bo *buf;
> -
> - buf = vfb->bo ? vmw_framebuffer_to_vfbd(>base)->buffer :
> - vmw_framebuffer_to_vfbs(>base)->surface->res.backup;
> -
> - if (WARN_ON(!buf))
> - return 0;
> -
> - return
Re: [PATCH v2 3/8] drm/vmwgfx: Rename vmw_buffer_object to vmw_bo
On 1/30/23 19:35, Zack Rusin wrote:
> From: Zack Rusin
>
> The rest of the drivers which are using ttm have mostly standardized on
> driver_prefix_bo as the name for subclasses of the TTM buffer object.
> Make vmwgfx match the rest of the drivers and follow the same naming
> semantics.
>
> This is especially clear given that the name of the file in which the
> object was defined is vmw_bo.c.
>
> Signed-off-by: Zack Rusin
> Reviewed-by: Martin Krastev
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 94 -
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.h | 189 +++
> drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c | 10 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 9 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 11 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 9 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 7 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 184 ++
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 53 +++---
> drivers/gpu/drm/vmwgfx/vmwgfx_fence.c| 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 27 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 17 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 12 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_mob.c | 7 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | 18 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 27 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 29 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 15 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_shader.c | 15 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 13 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_streamoutput.c | 9 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 9 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 3 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_validation.c | 30 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_validation.h | 6 +-
> 25 files changed, 419 insertions(+), 386 deletions(-)
> create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> index 8aaeeecd2016..b6dc0baef350 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> @@ -1,7 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0 OR MIT
> /**
> *
> - * Copyright © 2011-2018 VMware, Inc., Palo Alto, CA., USA
> + * Copyright © 2011-2023 VMware, Inc., Palo Alto, CA., USA
> * All Rights Reserved.
> *
> * Permission is hereby granted, free of charge, to any person obtaining a
> @@ -26,55 +26,41 @@
> *
> **/
>
> -#include
> -
> +#include "vmwgfx_bo.h"
> #include "vmwgfx_drv.h"
> -#include "ttm_object.h"
>
>
> -/**
> - * vmw_buffer_object - Convert a struct ttm_buffer_object to a struct
> - * vmw_buffer_object.
> - *
> - * @bo: Pointer to the TTM buffer object.
> - * Return: Pointer to the struct vmw_buffer_object embedding the
> - * TTM buffer object.
> - */
> -static struct vmw_buffer_object *
> -vmw_buffer_object(struct ttm_buffer_object *bo)
> -{
> - return container_of(bo, struct vmw_buffer_object, base);
> -}
> +#include
>
> /**
> - * vmw_bo_bo_free - vmw buffer object destructor
> + * vmw_bo_free - vmw_bo destructor
> *
> * @bo: Pointer to the embedded struct ttm_buffer_object
> */
> -static void vmw_bo_bo_free(struct ttm_buffer_object *bo)
> +static void vmw_bo_free(struct ttm_buffer_object *bo)
> {
> - struct vmw_buffer_object *vmw_bo = vmw_buffer_object(bo);
> + struct vmw_bo *vbo = to_vmw_bo(>base);
>
> - WARN_ON(vmw_bo->dirty);
> - WARN_ON(!RB_EMPTY_ROOT(_bo->res_tree));
> - vmw_bo_unmap(vmw_bo);
> + WARN_ON(vbo->dirty);
> + WARN_ON(!RB_EMPTY_ROOT(>res_tree));
> + vmw_bo_unmap(vbo);
> drm_gem_object_release(>base);
> - kfree(vmw_bo);
> + kfree(vbo);
> }
>
> /**
> - * bo_is_vmw - check if the buffer object is a _buffer_object
> + * bo_is_vmw - check if the buffer object is a _bo
> * @bo: ttm buffer object to be checked
> *
> * Uses destroy function associated with the object to determine if this is
> - * a _buffer_object.
> + * a _bo.
> *
> * Returns:
> - * true if the object is of _buffer_object type, false if not.
> + * true if the object is of _bo type, false if not.
> */
> static bool bo_is_vmw(struct ttm_buffer_object *bo)
> {
> - return bo->destroy == _bo_bo_free;
> + return bo->destroy == _bo_free;
> }
>
> /**
> @@ -88,7 +74,7 @@ static bool bo_is_vmw(struct ttm_buffer_object *bo)
> * -ERESTARTSYS if interrupted by a signal
> */
> int vmw_bo_pin_in_placement(struct vmw_private *dev_priv,
> - struct vmw_buffer_object *buf,
> + struct vmw_bo *buf,
> struct ttm_placement *placement,
>
Re: [PATCH v2 2/8] drm/vmwgfx: Remove the duplicate bo_free function
On 1/30/23 19:35, Zack Rusin wrote:
> From: Zack Rusin
>
> Remove the explicit bo_free parameter which was switching between
> vmw_bo_bo_free and vmw_gem_destroy which had exactly the same
> implementation.
>
> It makes no sense to keep parameter which is always the same, remove it
> and all code referencing it. Instead use the vmw_bo_bo_free directly.
>
> Signed-off-by: Zack Rusin
> Reviewed-by: Martin Krastev
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 49 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 3 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 6 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 18 +
> drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 3 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_shader.c | 2 +-
> 8 files changed, 27 insertions(+), 58 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> index aa1cd5126a32..8aaeeecd2016 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> @@ -46,6 +46,22 @@ vmw_buffer_object(struct ttm_buffer_object *bo)
> return container_of(bo, struct vmw_buffer_object, base);
> }
>
> +/**
> + * vmw_bo_bo_free - vmw buffer object destructor
> + *
> + * @bo: Pointer to the embedded struct ttm_buffer_object
> + */
> +static void vmw_bo_bo_free(struct ttm_buffer_object *bo)
> +{
> + struct vmw_buffer_object *vmw_bo = vmw_buffer_object(bo);
> +
> + WARN_ON(vmw_bo->dirty);
> + WARN_ON(!RB_EMPTY_ROOT(_bo->res_tree));
> + vmw_bo_unmap(vmw_bo);
> + drm_gem_object_release(>base);
> + kfree(vmw_bo);
> +}
> +
> /**
> * bo_is_vmw - check if the buffer object is a _buffer_object
> * @bo: ttm buffer object to be checked
> @@ -58,8 +74,7 @@ vmw_buffer_object(struct ttm_buffer_object *bo)
> */
> static bool bo_is_vmw(struct ttm_buffer_object *bo)
> {
> - return bo->destroy == _bo_bo_free ||
> -bo->destroy == _gem_destroy;
> + return bo->destroy == _bo_bo_free;
> }
>
> /**
> @@ -376,23 +391,6 @@ void vmw_bo_unmap(struct vmw_buffer_object *vbo)
> ttm_bo_kunmap(>map);
> }
>
> -
> -/**
> - * vmw_bo_bo_free - vmw buffer object destructor
> - *
> - * @bo: Pointer to the embedded struct ttm_buffer_object
> - */
> -void vmw_bo_bo_free(struct ttm_buffer_object *bo)
> -{
> - struct vmw_buffer_object *vmw_bo = vmw_buffer_object(bo);
> -
> - WARN_ON(vmw_bo->dirty);
> - WARN_ON(!RB_EMPTY_ROOT(_bo->res_tree));
> - vmw_bo_unmap(vmw_bo);
> - drm_gem_object_release(>base);
> - kfree(vmw_bo);
> -}
> -
> /* default destructor */
> static void vmw_bo_default_destroy(struct ttm_buffer_object *bo)
> {
> @@ -449,13 +447,10 @@ int vmw_bo_create_kernel(struct vmw_private *dev_priv,
> unsigned long size,
> int vmw_bo_create(struct vmw_private *vmw,
> size_t size, struct ttm_placement *placement,
> bool interruptible, bool pin,
> - void (*bo_free)(struct ttm_buffer_object *bo),
> struct vmw_buffer_object **p_bo)
> {
> int ret;
>
> - BUG_ON(!bo_free);
> -
> *p_bo = kmalloc(sizeof(**p_bo), GFP_KERNEL);
> if (unlikely(!*p_bo)) {
> DRM_ERROR("Failed to allocate a buffer.\n");
> @@ -463,8 +458,7 @@ int vmw_bo_create(struct vmw_private *vmw,
> }
>
> ret = vmw_bo_init(vmw, *p_bo, size,
> - placement, interruptible, pin,
> - bo_free);
> + placement, interruptible, pin);
> if (unlikely(ret != 0))
> goto out_error;
>
> @@ -484,7 +478,6 @@ int vmw_bo_create(struct vmw_private *vmw,
> * @placement: Initial placement.
> * @interruptible: Whether waits should be performed interruptible.
> * @pin: If the BO should be created pinned at a fixed location.
> - * @bo_free: The buffer object destructor.
> * Returns: Zero on success, negative error code on error.
> *
> * Note that on error, the code will free the buffer object.
> @@ -492,8 +485,7 @@ int vmw_bo_create(struct vmw_private *vmw,
> int vmw_bo_init(struct vmw_private *dev_priv,
> struct vmw_buffer_object *vmw_bo,
> size_t size, struct ttm_placement *placement,
> - bool interruptible, bool pin,
> - void (*bo_free)(struct ttm_buffer_object *bo))
> + bool interruptible, bool pin)
> {
> struct ttm_operation_ctx ctx = {
> .interruptible = interruptible,
> @@ -503,7 +495,6 @@ int vmw_bo_init(struct vmw_private *dev_priv,
> struct drm_device *vdev = _priv->drm;
> int ret;
>
> - WARN_ON_ONCE(!bo_free);
> memset(vmw_bo, 0, sizeof(*vmw_bo));
> BUILD_BUG_ON(TTM_MAX_BO_PRIORITY <= 3);
> vmw_bo->base.priority = 3;
> @@ -513,7 +504,7 @@ int vmw_bo_init(struct vmw_private *dev_priv,
>
Re: [PATCH v2 1/8] drm/vmwgfx: Use the common gem mmap instead of the custom code
On 1/30/23 19:35, Zack Rusin wrote:
> From: Zack Rusin
>
> Before vmwgfx supported gem it needed to implement the entire mmap logic
> explicitly. With GEM support that's not needed and the generic code
> can be used by simply setting the vm_ops to vmwgfx specific ones on the
> gem object itself.
>
> Removes a lot of code from vmwgfx without any functional difference.
>
> Signed-off-by: Zack Rusin
> Reviewed-by: Thomas Zimmermann
> Reviewed-by: Martin Krastev
> ---
> drivers/gpu/drm/vmwgfx/Makefile | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 6 --
> drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 8 ++
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 110 ---
> 5 files changed, 10 insertions(+), 118 deletions(-)
> delete mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
>
> diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
> index 2a644f035597..e94479d9cd5b 100644
> --- a/drivers/gpu/drm/vmwgfx/Makefile
> +++ b/drivers/gpu/drm/vmwgfx/Makefile
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0
> vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o vmwgfx_drv.o \
> vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_ttm_buffer.o \
> - vmwgfx_cmd.o vmwgfx_irq.o vmwgfx_ldu.o vmwgfx_ttm_glue.o \
> + vmwgfx_cmd.o vmwgfx_irq.o vmwgfx_ldu.o \
> vmwgfx_overlay.o vmwgfx_gmrid_manager.o vmwgfx_fence.o \
> vmwgfx_bo.o vmwgfx_scrn.o vmwgfx_context.o \
> vmwgfx_surface.o vmwgfx_prime.o vmwgfx_mob.o vmwgfx_shader.o \
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index bd02cb0e6837..e0c2e3748015 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -1566,7 +1566,7 @@ static const struct file_operations vmwgfx_driver_fops
> = {
> .open = drm_open,
> .release = drm_release,
> .unlocked_ioctl = vmw_unlocked_ioctl,
> - .mmap = vmw_mmap,
> + .mmap = drm_gem_mmap,
> .poll = drm_poll,
> .read = drm_read,
> #if defined(CONFIG_COMPAT)
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> index 5acbf5849b27..4dfa5044a9e7 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> @@ -1053,12 +1053,6 @@ vmw_is_cursor_bypass3_enabled(const struct vmw_private
> *dev_priv)
> return (vmw_fifo_caps(dev_priv) & SVGA_FIFO_CAP_CURSOR_BYPASS_3) != 0;
> }
>
> -/**
> - * TTM glue - vmwgfx_ttm_glue.c
> - */
> -
> -extern int vmw_mmap(struct file *filp, struct vm_area_struct *vma);
> -
> /**
> * TTM buffer object driver - vmwgfx_ttm_buffer.c
> */
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
> index ce609e7d758f..ba4ddd9f7a7e 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
> @@ -103,6 +103,13 @@ static struct sg_table
> *vmw_gem_object_get_sg_table(struct drm_gem_object *obj)
> return drm_prime_pages_to_sg(obj->dev, vmw_tt->dma_ttm.pages,
> vmw_tt->dma_ttm.num_pages);
> }
>
> +static const struct vm_operations_struct vmw_vm_ops = {
> + .pfn_mkwrite = vmw_bo_vm_mkwrite,
> + .page_mkwrite = vmw_bo_vm_mkwrite,
> + .fault = vmw_bo_vm_fault,
> + .open = ttm_bo_vm_open,
> + .close = ttm_bo_vm_close,
> +};
>
> static const struct drm_gem_object_funcs vmw_gem_object_funcs = {
> .free = vmw_gem_object_free,
> @@ -115,6 +122,7 @@ static const struct drm_gem_object_funcs
> vmw_gem_object_funcs = {
> .vmap = drm_gem_ttm_vmap,
> .vunmap = drm_gem_ttm_vunmap,
> .mmap = drm_gem_ttm_mmap,
> + .vm_ops = _vm_ops,
> };
>
> /**
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
> deleted file mode 100644
> index 265f7c48d856..
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
> +++ /dev/null
> @@ -1,110 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0 OR MIT
> -/**
> - *
> - * Copyright 2009-2011 VMware, Inc., Palo Alto, CA., USA
> - *
> - * Permission is hereby granted, free of charge, to any person obtaining a
> - * copy of this software and associated documentation files (the
> - * "Software"), to deal in the Software without restriction, including
> - * without limitation the rights to use, copy, modify, merge, publish,
> - * distribute, sub license, and/or sell copies of the Software, and to
> - * permit persons to whom the Software is furnished to do so, subject to
> - * the following conditions:
> - *
> - * The above copyright notice and this permission notice (including the
> - * next paragraph) shall be included in all copies or substantial portions
> - * of the Software.
> - *
> - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> - *
Re: [RFT PATCH v2 2/3] drm/msm/dsi: Stop unconditionally powering up DSI hosts at modeset
On 1/31/2023 2:18 PM, Douglas Anderson wrote:
In commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset
time"), we moved powering up DSI hosts to modeset time. This wasn't
because it was an elegant design, but there were no better options.
That commit actually ended up breaking ps8640, and thus was born
commit ec7981e6c614 ("drm/msm/dsi: don't powerup at modeset time for
parade-ps8640") as a temporary hack to un-break ps8640 by moving it to
the old way of doing things. It turns out that ps8640 _really_ doesn't
like its pre_enable() function to be called after
dsi_mgr_bridge_power_on(). Specifically (from experimentation, not
because I have any inside knowledge), it looks like the assertion of
"RST#" in the ps8640 runtime resume handler seems like it's not
allowed to happen after dsi_mgr_bridge_power_on()
Recently, Dave Stevenson's series landed allowing bridges some control
over pre_enable ordering. The meaty commit for our purposes is commit
4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to alter
bridge init order"). As documented by that series, if a bridge doesn't
set "pre_enable_prev_first" then we should use the old ordering.
Now that we have the commit ("drm/bridge: tc358762: Set
pre_enable_prev_first") we can go back to the old ordering, which also
allows us to remove the ps8640 special case.
One last note is that even without reverting commit 7d8e9a90509f
("drm/msm/dsi: move DSI host powerup to modeset time"), if you _just_
revert the ps8640 special case and try it out then it doesn't seem to
fail anymore. I spent time bisecting / debugging this and it turns out
to be mostly luck, so we still want this patch to make sure it's
solid. Specifically the reason it sorta works these days is because
we implemented wait_hpd_asserted() in ps8640 now, plus the magic of
"pm_runtime" autosuspend. The fact that we have wait_hpd_asserted()
implemented means that we actually power the bridge chip up just a wee
bit earlier and then the bridge happens to stay on because of
autosuspend and thus ends up powered before dsi_mgr_bridge_power_on().
Cc: Dave Stevenson
Cc: Dmitry Baryshkov
Cc: Abhinav Kumar
Signed-off-by: Douglas Anderson
---
Changes in v2:
- Don't fold dsi_mgr_bridge_power_on() back into dsi_mgr_bridge_pre_enable()
drivers/gpu/drm/msm/dsi/dsi_manager.c | 38 +--
1 file changed, 1 insertion(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 1bbac72dad35..2197a54b9b96 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -34,32 +34,6 @@ static struct msm_dsi_manager msm_dsim_glb;
#define IS_SYNC_NEEDED() (msm_dsim_glb.is_sync_needed)
#define IS_MASTER_DSI_LINK(id)(msm_dsim_glb.master_dsi_link_id == id)
-#ifdef CONFIG_OF
-static bool dsi_mgr_power_on_early(struct drm_bridge *bridge)
-{
- struct drm_bridge *next_bridge = drm_bridge_get_next_bridge(bridge);
-
- /*
-* If the next bridge in the chain is the Parade ps8640 bridge chip
-* then don't power on early since it seems to violate the expectations
-* of the firmware that the bridge chip is running.
-*
-* NOTE: this is expected to be a temporary special case. It's expected
-* that we'll eventually have a framework that allows the next level
-* bridge to indicate whether it needs us to power on before it or
-* after it. When that framework is in place then we'll use it and
-* remove this special case.
-*/
- return !(next_bridge && next_bridge->of_node &&
-of_device_is_compatible(next_bridge->of_node,
"parade,ps8640"));
-}
-#else
-static inline bool dsi_mgr_power_on_early(struct drm_bridge *bridge)
-{
- return true;
-}
-#endif
-
static inline struct msm_dsi *dsi_mgr_get_dsi(int id)
{
return msm_dsim_glb.dsi[id];
@@ -265,12 +239,6 @@ static void dsi_mgr_bridge_power_on(struct drm_bridge
*bridge)
int ret;
DBG("id=%d", id);
- if (!msm_dsi_device_connected(msm_dsi))
- return;
-
- /* Do nothing with the host if it is slave-DSI in case of bonded DSI */
- if (is_bonded_dsi && !IS_MASTER_DSI_LINK(id))
- return;
Why are these two checks removed?
ret = dsi_mgr_phy_enable(id, phy_shared_timings);
if (ret)
@@ -327,8 +295,7 @@ static void dsi_mgr_bridge_pre_enable(struct drm_bridge
*bridge)
if (is_bonded_dsi && !IS_MASTER_DSI_LINK(id))
return;
- if (!dsi_mgr_power_on_early(bridge))
- dsi_mgr_bridge_power_on(bridge);
+ dsi_mgr_bridge_power_on(bridge);
ret = msm_dsi_host_enable(host);
if (ret) {
@@ -438,9 +405,6 @@ static void dsi_mgr_bridge_mode_set(struct drm_bridge
*bridge,
msm_dsi_host_set_display_mode(host, adjusted_mode);
if (is_bonded_dsi && other_dsi)
Re: [PATCH] dt-bindings: display: msm: Drop type from 'memory-region'
On Wed, 25 Jan 2023 16:13:56 -0600, Rob Herring wrote: > 'memory-region' is a common property and already has a type. > > Signed-off-by: Rob Herring > --- > Documentation/devicetree/bindings/display/msm/gpu.yaml | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Applied, thanks!
Re: [PATCH v2 02/17] drm/display/dp_mst: Handle old/new payload states in drm_dp_remove_payload()
On Tue, 2023-01-31 at 17:05 +0200, Imre Deak wrote:
> Atm, drm_dp_remove_payload() uses the same payload state to both get the
> vc_start_slot required for the payload removal DPCD message and to
> deduct time_slots from vc_start_slot of all payloads after the one being
> removed.
>
> The above isn't always correct, as vc_start_slot must be the up-to-date
> version contained in the new payload state, but time_slots must be the
> one used when the payload was previously added, contained in the old
> payload state. The new payload's time_slots can change vs. the old one
> if the current atomic commit changes the corresponding mode.
>
> This patch let's drivers pass the old and new payload states to
> drm_dp_remove_payload(), but keeps these the same for now in all drivers
> not to change the behavior. A follow-up i915 patch will pass in that
> driver the correct old and new states to the function.
Oh wow, this was definitely a mistake on my part, thanks for catching this!
TBH, I think this behavior is correct so (now that I actually have a setup
capable of testing amdgpu's MST fully thanks to gitlab issue 2171…) if you'd
like to change it on other drivers as well I can test it fully. Or feel free
to leave it to me, shouldn't be too difficult I think :).
For 0-2:
Reviewed-by: Lyude Paul
>
> Cc: Lyude Paul
> Cc: Ville Syrjälä
> Cc: Ben Skeggs
> Cc: Karol Herbst
> Cc: Harry Wentland
> Cc: Alex Deucher
> Cc: Wayne Lin
> Cc: sta...@vger.kernel.org # 6.1
> Cc: dri-devel@lists.freedesktop.org
> Reviewed-by: Ville Syrjälä
> Signed-off-by: Imre Deak
> ---
> .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
> drivers/gpu/drm/display/drm_dp_mst_topology.c | 26 ++-
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 ++-
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
> include/drm/display/drm_dp_mst_helper.h | 3 ++-
> 5 files changed, 21 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> index a50319fc42b11..180d3893b68da 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> @@ -208,7 +208,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
> if (enable)
> drm_dp_add_payload_part1(mst_mgr, mst_state, payload);
> else
> - drm_dp_remove_payload(mst_mgr, mst_state, payload);
> + drm_dp_remove_payload(mst_mgr, mst_state, payload, payload);
>
> /* mst_mgr->->payloads are VC payload notify MST branch using DPCD or
>* AUX message. The sequence is slot 1-63 allocated sequence for each
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 847c10aa2098c..1990ff5dc7ddd 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -3342,7 +3342,8 @@ EXPORT_SYMBOL(drm_dp_add_payload_part1);
> * drm_dp_remove_payload() - Remove an MST payload
> * @mgr: Manager to use.
> * @mst_state: The MST atomic state
> - * @payload: The payload to write
> + * @old_payload: The payload with its old state
> + * @new_payload: The payload to write
> *
> * Removes a payload from an MST topology if it was successfully assigned a
> start slot. Also updates
> * the starting time slots of all other payloads which would have been
> shifted towards the start of
> @@ -3350,36 +3351,37 @@ EXPORT_SYMBOL(drm_dp_add_payload_part1);
> */
> void drm_dp_remove_payload(struct drm_dp_mst_topology_mgr *mgr,
> struct drm_dp_mst_topology_state *mst_state,
> -struct drm_dp_mst_atomic_payload *payload)
> +const struct drm_dp_mst_atomic_payload *old_payload,
> +struct drm_dp_mst_atomic_payload *new_payload)
> {
> struct drm_dp_mst_atomic_payload *pos;
> bool send_remove = false;
>
> /* We failed to make the payload, so nothing to do */
> - if (payload->vc_start_slot == -1)
> + if (new_payload->vc_start_slot == -1)
> return;
>
> mutex_lock(>lock);
> - send_remove = drm_dp_mst_port_downstream_of_branch(payload->port,
> mgr->mst_primary);
> + send_remove = drm_dp_mst_port_downstream_of_branch(new_payload->port,
> mgr->mst_primary);
> mutex_unlock(>lock);
>
> if (send_remove)
> - drm_dp_destroy_payload_step1(mgr, mst_state, payload);
> + drm_dp_destroy_payload_step1(mgr, mst_state, new_payload);
> else
> drm_dbg_kms(mgr->dev, "Payload for VCPI %d not in topology, not
> sending remove\n",
> - payload->vcpi);
> + new_payload->vcpi);
>
> list_for_each_entry(pos, _state->payloads, next) {
> - if (pos != payload &&
[PATCH 2/2] backlight: hx8357: stop using of-specific APIs
There is no need for this driver to be OF-specific, so switch it to
use device_get_match_data() and stop including various of-related
headers.
Signed-off-by: Dmitry Torokhov
---
drivers/video/backlight/hx8357.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c
index a93e14adb846..2e162a70c1ce 100644
--- a/drivers/video/backlight/hx8357.c
+++ b/drivers/video/backlight/hx8357.c
@@ -10,8 +10,8 @@
#include
#include
#include
-#include
-#include
+#include
+#include
#include
#define HX8357_NUM_IM_PINS 3
@@ -581,11 +581,15 @@ MODULE_DEVICE_TABLE(of, hx8357_dt_ids);
static int hx8357_probe(struct spi_device *spi)
{
+ int (*lcd_init_fn)(struct lcd_device *);
struct lcd_device *lcdev;
struct hx8357_data *lcd;
- const struct of_device_id *match;
int i, ret;
+ lcd_init_fn = device_get_match_data(>dev);
+ if (!lcd_init_fn)
+ return -EINVAL;
+
lcd = devm_kzalloc(>dev, sizeof(*lcd), GFP_KERNEL);
if (!lcd)
return -ENOMEM;
@@ -598,10 +602,6 @@ static int hx8357_probe(struct spi_device *spi)
lcd->spi = spi;
- match = of_match_device(hx8357_dt_ids, >dev);
- if (!match || !match->data)
- return -EINVAL;
-
lcd->reset = devm_gpiod_get(>dev, "reset", GPIOD_OUT_LOW);
ret = PTR_ERR_OR_ZERO(lcd->reset);
if (ret) {
@@ -647,7 +647,7 @@ static int hx8357_probe(struct spi_device *spi)
hx8357_lcd_reset(lcdev);
- ret = ((int (*)(struct lcd_device *))match->data)(lcdev);
+ ret = lcd_init_fn(lcdev);
if (ret) {
dev_err(>dev, "Couldn't initialize panel\n");
return ret;
--
2.39.1.456.gfc5497dd1b-goog
[PATCH 1/2] backlight: hx8357: switch to using gpiod API
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
This makes driver use standard property name for the reset gpio
("reset-gpios" vs "gpios-reset"), however there is a quirk in gpiolib
to also recognize the legacy name and keep compatibility with older
DTSes.
Signed-off-by: Dmitry Torokhov
---
All preparation gpiolib work to handle legacy names and polarity quirks
has landed in mainline...
drivers/video/backlight/hx8357.c | 82 ++--
1 file changed, 37 insertions(+), 45 deletions(-)
diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c
index 9b50bc96e00f..a93e14adb846 100644
--- a/drivers/video/backlight/hx8357.c
+++ b/drivers/video/backlight/hx8357.c
@@ -6,11 +6,12 @@
*/
#include
+#include
+#include
#include
#include
#include
#include
-#include
#include
#define HX8357_NUM_IM_PINS 3
@@ -83,8 +84,8 @@
#define HX8369_SET_GAMMA_CURVE_RELATED 0xe0
struct hx8357_data {
- unsignedim_pins[HX8357_NUM_IM_PINS];
- unsignedreset;
+ struct gpio_desc*im_pins[HX8357_NUM_IM_PINS];
+ struct gpio_desc*reset;
struct spi_device *spi;
int state;
booluse_im_pins;
@@ -321,11 +322,11 @@ static void hx8357_lcd_reset(struct lcd_device *lcdev)
struct hx8357_data *lcd = lcd_get_data(lcdev);
/* Reset the screen */
- gpio_set_value(lcd->reset, 1);
+ gpiod_set_value_cansleep(lcd->reset, 0);
usleep_range(1, 12000);
- gpio_set_value(lcd->reset, 0);
+ gpiod_set_value_cansleep(lcd->reset, 1);
usleep_range(1, 12000);
- gpio_set_value(lcd->reset, 1);
+ gpiod_set_value_cansleep(lcd->reset, 0);
/* The controller needs 120ms to recover from reset */
msleep(120);
@@ -341,9 +342,9 @@ static int hx8357_lcd_init(struct lcd_device *lcdev)
* wires
*/
if (lcd->use_im_pins) {
- gpio_set_value_cansleep(lcd->im_pins[0], 1);
- gpio_set_value_cansleep(lcd->im_pins[1], 0);
- gpio_set_value_cansleep(lcd->im_pins[2], 1);
+ gpiod_set_value_cansleep(lcd->im_pins[0], 1);
+ gpiod_set_value_cansleep(lcd->im_pins[1], 0);
+ gpiod_set_value_cansleep(lcd->im_pins[2], 1);
}
ret = hx8357_spi_write_array(lcdev, hx8357_seq_power,
@@ -601,48 +602,39 @@ static int hx8357_probe(struct spi_device *spi)
if (!match || !match->data)
return -EINVAL;
- lcd->reset = of_get_named_gpio(spi->dev.of_node, "gpios-reset", 0);
- if (!gpio_is_valid(lcd->reset)) {
- dev_err(>dev, "Missing dt property: gpios-reset\n");
- return -EINVAL;
- }
-
- ret = devm_gpio_request_one(>dev, lcd->reset,
- GPIOF_OUT_INIT_HIGH,
- "hx8357-reset");
+ lcd->reset = devm_gpiod_get(>dev, "reset", GPIOD_OUT_LOW);
+ ret = PTR_ERR_OR_ZERO(lcd->reset);
if (ret) {
- dev_err(>dev,
- "failed to request gpio %d: %d\n",
- lcd->reset, ret);
- return -EINVAL;
+ dev_err(>dev, "failed to request reset gpio: %d\n", ret);
+ return ret;
}
- if (of_find_property(spi->dev.of_node, "im-gpios", NULL)) {
- lcd->use_im_pins = 1;
-
- for (i = 0; i < HX8357_NUM_IM_PINS; i++) {
- lcd->im_pins[i] = of_get_named_gpio(spi->dev.of_node,
- "im-gpios", i);
- if (lcd->im_pins[i] == -EPROBE_DEFER) {
- dev_info(>dev, "GPIO requested is not here
yet, deferring the probe\n");
- return -EPROBE_DEFER;
- }
- if (!gpio_is_valid(lcd->im_pins[i])) {
- dev_err(>dev, "Missing dt property:
im-gpios\n");
- return -EINVAL;
+ gpiod_set_consumer_name(lcd->reset, "hx8357-reset");
+
+ for (i = 0; i < HX8357_NUM_IM_PINS; i++) {
+ lcd->im_pins[i] = devm_gpiod_get_index(>dev,
+ "im", i, GPIOD_OUT_LOW);
+ ret = PTR_ERR_OR_ZERO(lcd->im_pins[i]);
+ if (ret) {
+ if (ret == -ENOENT) {
+ if (i == 0)
+ break;
+ dev_err(>dev, "Missing im gpios[%d]\n", i);
+ ret = -EINVAL;
+ } if (ret == -EPROBE_DEFER) {
+ dev_info(>dev, "im gpio[%d] is not here
yet, deferring the
[PATCH] drm/i915/huc: Add and use HuC oriented print macros
Like we did it for GuC, introduce some helper print macros for
HuC to have unified format of messages that also include GT#.
While around improve some messages and use %pe if possible.
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 44 ++
1 file changed, 23 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 410905da8e97..834e3b5b8f4b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -6,6 +6,7 @@
#include
#include "gt/intel_gt.h"
+#include "gt/intel_gt_print.h"
#include "intel_guc_reg.h"
#include "intel_huc.h"
#include "i915_drv.h"
@@ -13,6 +14,15 @@
#include
#include
+#define huc_printk(_huc, _level, _fmt, ...) \
+ gt_##_level(huc_to_gt(_huc), "HuC: " _fmt, ##__VA_ARGS__)
+#define huc_err(_huc, _fmt, ...) huc_printk((_huc), err, _fmt,
##__VA_ARGS__)
+#define huc_warn(_huc, _fmt, ...) huc_printk((_huc), warn, _fmt,
##__VA_ARGS__)
+#define huc_notice(_huc, _fmt, ...)huc_printk((_huc), notice, _fmt,
##__VA_ARGS__)
+#define huc_info(_huc, _fmt, ...) huc_printk((_huc), info, _fmt,
##__VA_ARGS__)
+#define huc_dbg(_huc, _fmt, ...) huc_printk((_huc), dbg, _fmt,
##__VA_ARGS__)
+#define huc_probe_error(_huc, _fmt, ...) huc_printk((_huc), probe_error, _fmt,
##__VA_ARGS__)
+
/**
* DOC: HuC
*
@@ -107,11 +117,9 @@ static enum hrtimer_restart
huc_delayed_load_timer_callback(struct hrtimer *hrti
if (!intel_huc_is_authenticated(huc)) {
if (huc->delayed_load.status == INTEL_HUC_WAITING_ON_GSC)
- drm_notice(_to_gt(huc)->i915->drm,
- "timed out waiting for MEI GSC init to load
HuC\n");
+ huc_notice(huc, "load timed out waiting for MEI GSC\n");
else if (huc->delayed_load.status == INTEL_HUC_WAITING_ON_PXP)
- drm_notice(_to_gt(huc)->i915->drm,
- "timed out waiting for MEI PXP init to load
HuC\n");
+ huc_notice(huc, "load timed out waiting for MEI PXP\n");
else
MISSING_CASE(huc->delayed_load.status);
@@ -174,8 +182,7 @@ static int gsc_notifier(struct notifier_block *nb, unsigned
long action, void *d
case BUS_NOTIFY_DRIVER_NOT_BOUND: /* mei driver fails to be bound */
case BUS_NOTIFY_UNBIND_DRIVER: /* mei driver about to be unbound */
- drm_info(_to_gt(huc)->i915->drm,
-"mei driver not bound, disabling HuC load\n");
+ huc_info(huc, "MEI driver not bound, disabling load\n");
gsc_init_error(huc);
break;
}
@@ -193,8 +200,7 @@ void intel_huc_register_gsc_notifier(struct intel_huc *huc,
struct bus_type *bus
huc->delayed_load.nb.notifier_call = gsc_notifier;
ret = bus_register_notifier(bus, >delayed_load.nb);
if (ret) {
- drm_err(_to_gt(huc)->i915->drm,
- "failed to register GSC notifier\n");
+ huc_err(huc, "failed to register GSC notifier %pe\n",
ERR_PTR(ret));
huc->delayed_load.nb.notifier_call = NULL;
gsc_init_error(huc);
}
@@ -306,29 +312,25 @@ static int check_huc_loading_mode(struct intel_huc *huc)
GSC_LOADS_HUC;
if (fw_needs_gsc != hw_uses_gsc) {
- drm_err(>i915->drm,
- "mismatch between HuC FW (%s) and HW (%s) load modes\n",
- HUC_LOAD_MODE_STRING(fw_needs_gsc),
- HUC_LOAD_MODE_STRING(hw_uses_gsc));
+ huc_err(huc, "mismatch between FW (%s) and HW (%s) load
modes\n",
+ HUC_LOAD_MODE_STRING(fw_needs_gsc),
HUC_LOAD_MODE_STRING(hw_uses_gsc));
return -ENOEXEC;
}
/* make sure we can access the GSC via the mei driver if we need it */
if (!(IS_ENABLED(CONFIG_INTEL_MEI_PXP) &&
IS_ENABLED(CONFIG_INTEL_MEI_GSC)) &&
fw_needs_gsc) {
- drm_info(>i915->drm,
-"Can't load HuC due to missing MEI modules\n");
+ huc_info(huc, "can't load due to missing MEI modules\n");
return -EIO;
}
- drm_dbg(>i915->drm, "GSC loads huc=%s\n", str_yes_no(fw_needs_gsc));
+ huc_dbg(huc, "loaded by GSC = %s\n", str_yes_no(fw_needs_gsc));
return 0;
}
int intel_huc_init(struct intel_huc *huc)
{
- struct drm_i915_private *i915 = huc_to_gt(huc)->i915;
int err;
err = check_huc_loading_mode(huc);
@@ -345,7 +347,7 @@ int intel_huc_init(struct intel_huc *huc)
out:
intel_uc_fw_change_status(>fw, INTEL_UC_FIRMWARE_INIT_FAIL);
- drm_info(>drm, "HuC init failed with %d\n", err);
+ huc_info(huc,
[RFT PATCH v2 2/3] drm/msm/dsi: Stop unconditionally powering up DSI hosts at modeset
In commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset
time"), we moved powering up DSI hosts to modeset time. This wasn't
because it was an elegant design, but there were no better options.
That commit actually ended up breaking ps8640, and thus was born
commit ec7981e6c614 ("drm/msm/dsi: don't powerup at modeset time for
parade-ps8640") as a temporary hack to un-break ps8640 by moving it to
the old way of doing things. It turns out that ps8640 _really_ doesn't
like its pre_enable() function to be called after
dsi_mgr_bridge_power_on(). Specifically (from experimentation, not
because I have any inside knowledge), it looks like the assertion of
"RST#" in the ps8640 runtime resume handler seems like it's not
allowed to happen after dsi_mgr_bridge_power_on()
Recently, Dave Stevenson's series landed allowing bridges some control
over pre_enable ordering. The meaty commit for our purposes is commit
4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to alter
bridge init order"). As documented by that series, if a bridge doesn't
set "pre_enable_prev_first" then we should use the old ordering.
Now that we have the commit ("drm/bridge: tc358762: Set
pre_enable_prev_first") we can go back to the old ordering, which also
allows us to remove the ps8640 special case.
One last note is that even without reverting commit 7d8e9a90509f
("drm/msm/dsi: move DSI host powerup to modeset time"), if you _just_
revert the ps8640 special case and try it out then it doesn't seem to
fail anymore. I spent time bisecting / debugging this and it turns out
to be mostly luck, so we still want this patch to make sure it's
solid. Specifically the reason it sorta works these days is because
we implemented wait_hpd_asserted() in ps8640 now, plus the magic of
"pm_runtime" autosuspend. The fact that we have wait_hpd_asserted()
implemented means that we actually power the bridge chip up just a wee
bit earlier and then the bridge happens to stay on because of
autosuspend and thus ends up powered before dsi_mgr_bridge_power_on().
Cc: Dave Stevenson
Cc: Dmitry Baryshkov
Cc: Abhinav Kumar
Signed-off-by: Douglas Anderson
---
Changes in v2:
- Don't fold dsi_mgr_bridge_power_on() back into dsi_mgr_bridge_pre_enable()
drivers/gpu/drm/msm/dsi/dsi_manager.c | 38 +--
1 file changed, 1 insertion(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 1bbac72dad35..2197a54b9b96 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -34,32 +34,6 @@ static struct msm_dsi_manager msm_dsim_glb;
#define IS_SYNC_NEEDED() (msm_dsim_glb.is_sync_needed)
#define IS_MASTER_DSI_LINK(id) (msm_dsim_glb.master_dsi_link_id == id)
-#ifdef CONFIG_OF
-static bool dsi_mgr_power_on_early(struct drm_bridge *bridge)
-{
- struct drm_bridge *next_bridge = drm_bridge_get_next_bridge(bridge);
-
- /*
-* If the next bridge in the chain is the Parade ps8640 bridge chip
-* then don't power on early since it seems to violate the expectations
-* of the firmware that the bridge chip is running.
-*
-* NOTE: this is expected to be a temporary special case. It's expected
-* that we'll eventually have a framework that allows the next level
-* bridge to indicate whether it needs us to power on before it or
-* after it. When that framework is in place then we'll use it and
-* remove this special case.
-*/
- return !(next_bridge && next_bridge->of_node &&
-of_device_is_compatible(next_bridge->of_node,
"parade,ps8640"));
-}
-#else
-static inline bool dsi_mgr_power_on_early(struct drm_bridge *bridge)
-{
- return true;
-}
-#endif
-
static inline struct msm_dsi *dsi_mgr_get_dsi(int id)
{
return msm_dsim_glb.dsi[id];
@@ -265,12 +239,6 @@ static void dsi_mgr_bridge_power_on(struct drm_bridge
*bridge)
int ret;
DBG("id=%d", id);
- if (!msm_dsi_device_connected(msm_dsi))
- return;
-
- /* Do nothing with the host if it is slave-DSI in case of bonded DSI */
- if (is_bonded_dsi && !IS_MASTER_DSI_LINK(id))
- return;
ret = dsi_mgr_phy_enable(id, phy_shared_timings);
if (ret)
@@ -327,8 +295,7 @@ static void dsi_mgr_bridge_pre_enable(struct drm_bridge
*bridge)
if (is_bonded_dsi && !IS_MASTER_DSI_LINK(id))
return;
- if (!dsi_mgr_power_on_early(bridge))
- dsi_mgr_bridge_power_on(bridge);
+ dsi_mgr_bridge_power_on(bridge);
ret = msm_dsi_host_enable(host);
if (ret) {
@@ -438,9 +405,6 @@ static void dsi_mgr_bridge_mode_set(struct drm_bridge
*bridge,
msm_dsi_host_set_display_mode(host, adjusted_mode);
if (is_bonded_dsi && other_dsi)
msm_dsi_host_set_display_mode(other_dsi->host, adjusted_mode);
-
- if
[RFT PATCH v2 3/3] drm/msm/dsi: More properly handle errors in regards to dsi_mgr_bridge_power_on()
In commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset
time") the error handling with regards to dsi_mgr_bridge_power_on()
got a bit worse. Specifically if we failed to power the bridge on then
nothing would really notice. The modeset function couldn't return an
error and thus we'd blindly go forward and try to do the pre-enable.
In commit ec7981e6c614 ("drm/msm/dsi: don't powerup at modeset time
for parade-ps8640") we added a special case to move the powerup back
to pre-enable time for ps8640. When we did that, we didn't try to
recover the old/better error handling just for ps8640.
In the patch ("drm/msm/dsi: Stop unconditionally powering up DSI hosts
at modeset") we've now moved the powering up back to exclusively being
during pre-enable. That means we can add the better error handling
back in, so let's do it. To do so we'll add a new function
dsi_mgr_bridge_power_off() that's matches how errors were handled
prior to commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to
modeset time").
NOTE: Now that we have dsi_mgr_bridge_power_off(), it feels as if we
should be calling it in dsi_mgr_bridge_post_disable(). That would make
some sense, but doing so would change the current behavior and thus
should be a separate patch. Specifically:
* dsi_mgr_bridge_post_disable() always calls dsi_mgr_phy_disable()
even in the slave-DSI case of bonded DSI. We'd need to add special
handling for this if it's truly needed.
* dsi_mgr_bridge_post_disable() calls msm_dsi_phy_pll_save_state()
midway through the poweroff.
* dsi_mgr_bridge_post_disable() has a different order of some of the
poweroffs / IRQ disables.
For now we'll leave dsi_mgr_bridge_post_disable() alone.
Signed-off-by: Douglas Anderson
---
Changes in v2:
- ("More properly handle errors...") new for v2.
drivers/gpu/drm/msm/dsi/dsi_manager.c | 32 ++-
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 2197a54b9b96..28b8012a21f2 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -228,7 +228,7 @@ static void msm_dsi_manager_set_split_display(u8 id)
}
}
-static void dsi_mgr_bridge_power_on(struct drm_bridge *bridge)
+static int dsi_mgr_bridge_power_on(struct drm_bridge *bridge)
{
int id = dsi_mgr_bridge_get_id(bridge);
struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
@@ -268,14 +268,31 @@ static void dsi_mgr_bridge_power_on(struct drm_bridge
*bridge)
if (is_bonded_dsi && msm_dsi1)
msm_dsi_host_enable_irq(msm_dsi1->host);
- return;
+ return 0;
host1_on_fail:
msm_dsi_host_power_off(host);
host_on_fail:
dsi_mgr_phy_disable(id);
phy_en_fail:
- return;
+ return ret;
+}
+
+static void dsi_mgr_bridge_power_off(struct drm_bridge *bridge)
+{
+ int id = dsi_mgr_bridge_get_id(bridge);
+ struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
+ struct msm_dsi *msm_dsi1 = dsi_mgr_get_dsi(DSI_1);
+ struct mipi_dsi_host *host = msm_dsi->host;
+ bool is_bonded_dsi = IS_BONDED_DSI();
+
+ msm_dsi_host_disable_irq(host);
+ if (is_bonded_dsi && msm_dsi1) {
+ msm_dsi_host_disable_irq(msm_dsi1->host);
+ msm_dsi_host_power_off(msm_dsi1->host);
+ }
+ msm_dsi_host_power_off(host);
+ dsi_mgr_phy_disable(id);
}
static void dsi_mgr_bridge_pre_enable(struct drm_bridge *bridge)
@@ -295,7 +312,11 @@ static void dsi_mgr_bridge_pre_enable(struct drm_bridge
*bridge)
if (is_bonded_dsi && !IS_MASTER_DSI_LINK(id))
return;
- dsi_mgr_bridge_power_on(bridge);
+ ret = dsi_mgr_bridge_power_on(bridge);
+ if (ret) {
+ dev_err(_dsi->pdev->dev, "Power on failed: %d\n", ret);
+ return;
+ }
ret = msm_dsi_host_enable(host);
if (ret) {
@@ -316,8 +337,7 @@ static void dsi_mgr_bridge_pre_enable(struct drm_bridge
*bridge)
host1_en_fail:
msm_dsi_host_disable(host);
host_en_fail:
-
- return;
+ dsi_mgr_bridge_power_off(bridge);
}
void msm_dsi_manager_tpg_enable(void)
--
2.39.1.456.gfc5497dd1b-goog
[RFT PATCH v2 1/3] drm/bridge: tc358762: Set pre_enable_prev_first
Set the "pre_enable_prev_first" as provided by commit 4fb912e5e190
("drm/bridge: Introduce pre_enable_prev_first to alter bridge init
order"). This should allow us to revert commit ec7981e6c614
("drm/msm/dsi: don't powerup at modeset time for parade-ps8640") and
commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset
time").
Cc: Dave Stevenson
Cc: Dmitry Baryshkov
Cc: Abhinav Kumar
Signed-off-by: Douglas Anderson
---
(no changes since v1)
drivers/gpu/drm/bridge/tc358762.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/tc358762.c
b/drivers/gpu/drm/bridge/tc358762.c
index 0b6a28436885..77f7f7f54757 100644
--- a/drivers/gpu/drm/bridge/tc358762.c
+++ b/drivers/gpu/drm/bridge/tc358762.c
@@ -229,6 +229,7 @@ static int tc358762_probe(struct mipi_dsi_device *dsi)
ctx->bridge.funcs = _bridge_funcs;
ctx->bridge.type = DRM_MODE_CONNECTOR_DPI;
ctx->bridge.of_node = dev->of_node;
+ ctx->bridge.pre_enable_prev_first = true;
drm_bridge_add(>bridge);
--
2.39.1.456.gfc5497dd1b-goog
[PATCH] drm/i915/guc: Improve debug message on context reset notification
Just recently we switched over to new GuC oriented log macros but in
the meantime yet another message was added that we missed to update.
While around improve that new message by adding engine name and use
existing helpers to check for context state.
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 53f3ed3244d5..be495e657d66 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4660,9 +4660,10 @@ static void guc_handle_context_reset(struct intel_guc
*guc,
{
trace_intel_context_reset(ce);
- drm_dbg(_to_gt(guc)->i915->drm, "Got GuC reset of 0x%04X, exiting =
%d, banned = %d\n",
- ce->guc_id.id, test_bit(CONTEXT_EXITING, >flags),
- test_bit(CONTEXT_BANNED, >flags));
+ guc_dbg(guc, "Got context reset notification: 0x%04X on %s, exiting =
%s, banned = %s\n",
+ ce->guc_id.id, ce->engine->name,
+ str_yes_no(intel_context_is_exiting(ce)),
+ str_yes_no(intel_context_is_banned(ce)));
if (likely(intel_context_is_schedulable(ce))) {
capture_error_state(guc, ce);
--
2.25.1
Re: [PATCH] drm/panel: boe-tv101wum-nl6: Ensure DSI writes succeed during disable
Hi,
On Thu, Jan 26, 2023 at 4:52 PM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Jan 18, 2023 at 1:34 PM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Thu, Jan 5, 2023 at 7:01 PM Stephen Boyd wrote:
> > >
> > > The unprepare sequence has started to fail after moving to panel bridge
> > > code in the msm drm driver (commit 007ac0262b0d ("drm/msm/dsi: switch to
> > > DRM_PANEL_BRIDGE")). You'll see messages like this in the kernel logs:
> > >
> > >panel-boe-tv101wum-nl6 ae94000.dsi.0: failed to set panel off: -22
> > >
> > > This is because boe_panel_enter_sleep_mode() needs an operating DSI link
> > > to set the panel into sleep mode. Performing those writes in the
> > > unprepare phase of bridge ops is too late, because the link has already
> > > been torn down by the DSI controller in post_disable, i.e. the PHY has
> > > been disabled, etc. See dsi_mgr_bridge_post_disable() for more details
> > > on the DSI .
> > >
> > > Split the unprepare function into a disable part and an unprepare part.
> > > For now, just the DSI writes to enter sleep mode are put in the disable
> > > function. This fixes the panel off routine and keeps the panel happy.
> > >
> > > My Wormdingler has an integrated touchscreen that stops responding to
> > > touch if the panel is only half disabled too. This patch fixes it. And
> > > finally, this saves power when the screen is off because without this
> > > fix the regulators for the panel are left enabled when nothing is being
> > > displayed on the screen.
> > >
> > > Fixes: 007ac0262b0d ("drm/msm/dsi: switch to DRM_PANEL_BRIDGE")
> > > Fixes: a869b9db7adf ("drm/panel: support for boe tv101wum-nl6 wuxga dsi
> > > video mode panel")
> > > Cc: yangcong
> > > Cc: Douglas Anderson
> > > Cc: Jitao Shi
> > > Cc: Sam Ravnborg
> > > Cc: Rob Clark
> > > Cc: Dmitry Baryshkov
> > > Signed-off-by: Stephen Boyd
> > > ---
> > > drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 16
> > > 1 file changed, 12 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> > > b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> > > index 857a2f0420d7..c924f1124ebc 100644
> > > --- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> > > +++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> > > @@ -1193,14 +1193,11 @@ static int boe_panel_enter_sleep_mode(struct
> > > boe_panel *boe)
> > > return 0;
> > > }
> > >
> > > -static int boe_panel_unprepare(struct drm_panel *panel)
> > > +static int boe_panel_disable(struct drm_panel *panel)
> > > {
> > > struct boe_panel *boe = to_boe_panel(panel);
> > > int ret;
> > >
> > > - if (!boe->prepared)
> > > - return 0;
> > > -
> > > ret = boe_panel_enter_sleep_mode(boe);
> > > if (ret < 0) {
> > > dev_err(panel->dev, "failed to set panel off: %d\n", ret);
> > > @@ -1209,6 +1206,16 @@ static int boe_panel_unprepare(struct drm_panel
> > > *panel)
> > >
> > > msleep(150);
> > >
> > > + return 0;
> > > +}
> > > +
> > > +static int boe_panel_unprepare(struct drm_panel *panel)
> > > +{
> > > + struct boe_panel *boe = to_boe_panel(panel);
> > > +
> > > + if (!boe->prepared)
> > > + return 0;
> > > +
> > > if (boe->desc->discharge_on_disable) {
> > > regulator_disable(boe->avee);
> > > regulator_disable(boe->avdd);
> > > @@ -1528,6 +1535,7 @@ static enum drm_panel_orientation
> > > boe_panel_get_orientation(struct drm_panel *pa
> > > }
> > >
> > > static const struct drm_panel_funcs boe_panel_funcs = {
> > > + .disable = boe_panel_disable,
> > > .unprepare = boe_panel_unprepare,
> > > .prepare = boe_panel_prepare,
> > > .enable = boe_panel_enable,
> >
> > As mentioned by Stephen, my initial reaction was that this felt
> > asymmetric. We were moving some stuff from unprepare() to disable()
> > and it felt like that would mean we would also need to move something
> > from prepare() to enable. Initially I thought maybe that "something"
> > was all of boe_panel_init_dcs_cmd() but I guess that didn't work.
> >
> > I don't truly have a reason that this _has_ to be symmetric. I was
> > initially worried that there might be some place where we call
> > pre_enable(), then never call enable() / disable(), and then call
> > post_disable(). That could have us in a bad state because we'd never
> > enter sleep mode / turn the display off. However (as I think I've
> > discovered before and just forgot), I don't think this is possible
> > because we always call pre-enable() and enable() together. Also, as
> > mentioned by Sam, we're about to fully shut the panel's power off so
> > (unless it's on a shared rail) it probably doesn't really matter.
> >
> > Thus, I'd be OK with:
> >
> > Reviewed-by: Douglas Anderson
> >
> > I'm also happy to land this (adding Cc: stable) to drm-misc-fixes if
> > nobody has any objections (also happy
Re: [PATCH] dma-buf: Add "dma-buf" to title of documentation
Jonathan Neuschäfer writes: > To make it easier to find the dma-buf documentation when looking through > tables-of-contents etc., put the name "dma-buf" in the title. > > Signed-off-by: Jonathan Neuschäfer > --- > Documentation/driver-api/dma-buf.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/driver-api/dma-buf.rst > b/Documentation/driver-api/dma-buf.rst > index 622b8156d2127..61b6f42ed0f18 100644 > --- a/Documentation/driver-api/dma-buf.rst > +++ b/Documentation/driver-api/dma-buf.rst > @@ -1,5 +1,5 @@ > -Buffer Sharing and Synchronization > -== > +Buffer Sharing and Synchronization (dma-buf) > + Applied, thanks. jon
Re: [PATCH AUTOSEL 5.15 12/12] amdgpu: fix build on non-DCN platforms.
On Tue, Jan 31, 2023 at 10:01 AM Sasha Levin wrote: > > From: Dave Airlie > > [ Upstream commit f439a959dcfb6b39d6fd4b85ca1110a1d1de1587 ] > > This fixes the build here locally on my 32-bit arm build. > > Signed-off-by: Dave Airlie > Signed-off-by: Sasha Levin This patch is only applicable to kernel 6.1 and newer. Alex > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index ee238a16572e..0f0dd9b0d84a 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -10769,6 +10769,8 @@ static int amdgpu_dm_atomic_check(struct drm_device > *dev, > bool lock_and_validation_needed = false; > struct dm_crtc_state *dm_old_crtc_state; > #if defined(CONFIG_DRM_AMD_DC_DCN) > + struct drm_dp_mst_topology_mgr *mgr; > + struct drm_dp_mst_topology_state *mst_state; > struct dsc_mst_fairness_vars vars[MAX_PIPES]; > #endif > > -- > 2.39.0 >
Re: [PATCH 0/2 v6] drm/mediatek: Add support for 10-bit overlays
My apologies, I accidentally mangled the version history. It should actually read: v2: * Rebase and resolve merge conflicts with the AFBC patch. v3: * Moved 10-bit support detection to mtk_disk_ovl.c v4: * Moved formats to mtk_disp_ovl.c and mtk_disp_rdma.c v5: * Minor style adjustments per checkpatch.pl v6: * Refactor patch into patch series. * Add formats directly to private data. On Tue, Jan 31, 2023 at 3:08 PM Justin Green wrote: > > This patch series adds support for 10-bit overlays to the Mediatek DRM driver. > Specifically, we add support for AR30 and BA30 overlays on MT8195 devices and > lay the groundwork for supporting more 10-bit formats on more devices. > > 1. Refactor plane initialization logic to allow individual DDP components to > provide their supported pixel formats. > > 2. Add AR30 and BA30 support to the MT8195 overlay driver. > > > Version history: > v6: > * Refactor patch into patch series. > * Add formats directly to private data. > > v5: > * Removed some dead defines. > * Refactored mtk_ovl_set_afbc(). > > v4: > * Move modifier validation to format_mod_supported function. > * Add modifiers to drm_universal_plane_init() call. > * Make comparisons to DRM_FORMAT_MOD_LINEAR explicit rather than relying on > DRM_FORMAT_LINEAR being equal to 0. > * Gate AFBC control bit writes on device compatibility. > > v3: > * Replaced pitch bitshift math with union based approach. > * Refactored overlay register writes to shared code between non-AFBC and > AFBC. > * Minor code cleanups. > > v2: > * Marked mtk_ovl_set_afbc as static. > * Reflowed some lines to fit column limit. > > > Justin Green (2): > drm/mediatek: Refactor pixel format logic > drm/mediatek: Add support for AR30 and BA30 overlays > > drivers/gpu/drm/mediatek/mtk_disp_drv.h | 4 + > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 89 + > drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 38 + > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +- > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 4 + > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 20 + > drivers/gpu/drm/mediatek/mtk_drm_plane.c| 24 ++ > drivers/gpu/drm/mediatek/mtk_drm_plane.h| 3 +- > 8 files changed, 168 insertions(+), 18 deletions(-) > > -- > 2.39.1.456.gfc5497dd1b-goog >
[PATCH 1/2] drm/mediatek: Refactor pixel format logic
Add an DDP component interface for querying pixel format support and move list
of supported pixel formats into DDP components instead of mtk_drm_plane.c
Tested by running Chrome on an MT8195.
Signed-off-by: Justin Green
edit1
---
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 4 ++
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 44 +
drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 38 ++
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 4 ++
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 20 ++
drivers/gpu/drm/mediatek/mtk_drm_plane.c| 24 ---
drivers/gpu/drm/mediatek/mtk_drm_plane.h| 3 +-
8 files changed, 123 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 33e61a136bbc..0df6a06defb8 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -96,6 +96,8 @@ void mtk_ovl_register_vblank_cb(struct device *dev,
void mtk_ovl_unregister_vblank_cb(struct device *dev);
void mtk_ovl_enable_vblank(struct device *dev);
void mtk_ovl_disable_vblank(struct device *dev);
+const u32 *mtk_ovl_get_formats(struct device *dev);
+size_t mtk_ovl_get_num_formats(struct device *dev);
void mtk_rdma_bypass_shadow(struct device *dev);
int mtk_rdma_clk_enable(struct device *dev);
@@ -115,6 +117,8 @@ void mtk_rdma_register_vblank_cb(struct device *dev,
void mtk_rdma_unregister_vblank_cb(struct device *dev);
void mtk_rdma_enable_vblank(struct device *dev);
void mtk_rdma_disable_vblank(struct device *dev);
+const u32 *mtk_rdma_get_formats(struct device *dev);
+size_t mtk_rdma_get_num_formats(struct device *dev);
int mtk_mdp_rdma_clk_enable(struct device *dev);
void mtk_mdp_rdma_clk_disable(struct device *dev);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 84daeaffab6a..8743c8047dc9 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -66,6 +66,20 @@
#defineOVL_CON_VIRT_FLIP BIT(9)
#defineOVL_CON_HORZ_FLIP BIT(10)
+static const u32 mt8173_formats[] = {
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_BGRX,
+ DRM_FORMAT_BGRA,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_BGR888,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_YUYV,
+};
+
struct mtk_disp_ovl_data {
unsigned int addr;
unsigned int gmc_bits;
@@ -73,6 +87,8 @@ struct mtk_disp_ovl_data {
bool fmt_rgb565_is_0;
bool smi_id_en;
bool supports_afbc;
+ const u32 *formats;
+ size_t num_formats;
};
/*
@@ -138,6 +154,20 @@ void mtk_ovl_disable_vblank(struct device *dev)
writel_relaxed(0x0, ovl->regs + DISP_REG_OVL_INTEN);
}
+const u32 *mtk_ovl_get_formats(struct device *dev)
+{
+ struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
+
+ return ovl->data->formats;
+}
+
+size_t mtk_ovl_get_num_formats(struct device *dev)
+{
+ struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
+
+ return ovl->data->num_formats;
+}
+
int mtk_ovl_clk_enable(struct device *dev)
{
struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
@@ -495,6 +525,8 @@ static const struct mtk_disp_ovl_data
mt2701_ovl_driver_data = {
.gmc_bits = 8,
.layer_nr = 4,
.fmt_rgb565_is_0 = false,
+ .formats = mt8173_formats,
+ .num_formats = ARRAY_SIZE(mt8173_formats),
};
static const struct mtk_disp_ovl_data mt8173_ovl_driver_data = {
@@ -502,6 +534,8 @@ static const struct mtk_disp_ovl_data
mt8173_ovl_driver_data = {
.gmc_bits = 8,
.layer_nr = 4,
.fmt_rgb565_is_0 = true,
+ .formats = mt8173_formats,
+ .num_formats = ARRAY_SIZE(mt8173_formats),
};
static const struct mtk_disp_ovl_data mt8183_ovl_driver_data = {
@@ -509,6 +543,8 @@ static const struct mtk_disp_ovl_data
mt8183_ovl_driver_data = {
.gmc_bits = 10,
.layer_nr = 4,
.fmt_rgb565_is_0 = true,
+ .formats = mt8173_formats,
+ .num_formats = ARRAY_SIZE(mt8173_formats),
};
static const struct mtk_disp_ovl_data mt8183_ovl_2l_driver_data = {
@@ -516,6 +552,8 @@ static const struct mtk_disp_ovl_data
mt8183_ovl_2l_driver_data = {
.gmc_bits = 10,
.layer_nr = 2,
.fmt_rgb565_is_0 = true,
+ .formats = mt8173_formats,
+ .num_formats = ARRAY_SIZE(mt8173_formats),
};
static const struct mtk_disp_ovl_data mt8192_ovl_driver_data = {
@@ -524,6 +562,8 @@ static const struct mtk_disp_ovl_data
mt8192_ovl_driver_data = {
.layer_nr = 4,
.fmt_rgb565_is_0 = true,
.smi_id_en = true,
+ .formats = mt8173_formats,
+ .num_formats = ARRAY_SIZE(mt8173_formats),
};
static const struct mtk_disp_ovl_data
[PATCH 2/2] drm/mediatek: Add support for AR30 and BA30 overlays
Add support for overlays with pixel formats AR30 and BA30 on MT8195.
Tested using "modetest -P" on an MT8195 device.
Signed-off-by: Justin Green
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 49 -
1 file changed, 47 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 8743c8047dc9..cd2f9a156456 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -41,6 +41,7 @@
#define DISP_REG_OVL_RDMA_CTRL(n) (0x00c0 + 0x20 * (n))
#define DISP_REG_OVL_RDMA_GMC(n) (0x00c8 + 0x20 * (n))
#define DISP_REG_OVL_ADDR_MT2701 0x0040
+#define DISP_REG_OVL_CLRFMT_EXT0x02D0
#define DISP_REG_OVL_ADDR_MT8173 0x0f40
#define DISP_REG_OVL_ADDR(ovl, n) ((ovl)->data->addr + 0x20 * (n))
#define DISP_REG_OVL_HDR_ADDR(ovl, n) ((ovl)->data->addr + 0x20 * (n)
+ 0x04)
@@ -61,6 +62,10 @@
0 : OVL_CON_CLRFMT_RGB)
#define OVL_CON_CLRFMT_RGB888(ovl) ((ovl)->data->fmt_rgb565_is_0 ? \
OVL_CON_CLRFMT_RGB : 0)
+#define OVL_CON_CLRFMT_BIT_DEPTH_MASK(ovl) (0xFF << 4 * (ovl))
+#define OVL_CON_CLRFMT_BIT_DEPTH(depth, ovl) (depth << 4 * (ovl))
+#define OVL_CON_CLRFMT_8_BIT 0x00
+#define OVL_CON_CLRFMT_10_BIT 0x01
#defineOVL_CON_AEN BIT(8)
#defineOVL_CON_ALPHA 0xff
#defineOVL_CON_VIRT_FLIP BIT(9)
@@ -80,6 +85,22 @@ static const u32 mt8173_formats[] = {
DRM_FORMAT_YUYV,
};
+static const u32 mt8195_formats[] = {
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ARGB2101010,
+ DRM_FORMAT_BGRX,
+ DRM_FORMAT_BGRA,
+ DRM_FORMAT_BGRA1010102,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_BGR888,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_YUYV,
+};
+
struct mtk_disp_ovl_data {
unsigned int addr;
unsigned int gmc_bits;
@@ -218,6 +239,27 @@ static void mtk_ovl_set_afbc(struct mtk_disp_ovl *ovl,
struct cmdq_pkt *cmdq_pkt
DISP_REG_OVL_DATAPATH_CON, OVL_LAYER_AFBC_EN(idx));
}
+static void mtk_ovl_set_bit_depth(struct device *dev, int idx, u32 format,
+ struct cmdq_pkt *cmdq_pkt)
+{
+ struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
+ unsigned int reg;
+ unsigned int bit_depth = OVL_CON_CLRFMT_8_BIT;
+
+ reg = readl(ovl->regs + DISP_REG_OVL_CLRFMT_EXT);
+ reg &= ~OVL_CON_CLRFMT_BIT_DEPTH_MASK(idx);
+
+ if (format == DRM_FORMAT_RGBA1010102 ||
+ format == DRM_FORMAT_BGRA1010102 ||
+ format == DRM_FORMAT_ARGB2101010)
+ bit_depth = OVL_CON_CLRFMT_10_BIT;
+
+ reg |= OVL_CON_CLRFMT_BIT_DEPTH(bit_depth, idx);
+
+ mtk_ddp_write(cmdq_pkt, reg, >cmdq_reg,
+ ovl->regs, DISP_REG_OVL_CLRFMT_EXT);
+}
+
void mtk_ovl_config(struct device *dev, unsigned int w,
unsigned int h, unsigned int vrefresh,
unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
@@ -332,9 +374,11 @@ static unsigned int ovl_fmt_convert(struct mtk_disp_ovl
*ovl, unsigned int fmt)
return OVL_CON_CLRFMT_ARGB;
case DRM_FORMAT_BGRX:
case DRM_FORMAT_BGRA:
+ case DRM_FORMAT_BGRA1010102:
return OVL_CON_CLRFMT_ARGB | OVL_CON_BYTE_SWAP;
case DRM_FORMAT_XRGB:
case DRM_FORMAT_ARGB:
+ case DRM_FORMAT_ARGB2101010:
return OVL_CON_CLRFMT_RGBA;
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ABGR:
@@ -418,6 +462,7 @@ void mtk_ovl_layer_config(struct device *dev, unsigned int
idx,
>cmdq_reg, ovl->regs,
DISP_REG_OVL_PITCH_MSB(idx));
}
+ mtk_ovl_set_bit_depth(dev, idx, fmt, cmdq_pkt);
mtk_ovl_layer_on(dev, idx, cmdq_pkt);
}
@@ -583,8 +628,8 @@ static const struct mtk_disp_ovl_data
mt8195_ovl_driver_data = {
.fmt_rgb565_is_0 = true,
.smi_id_en = true,
.supports_afbc = true,
- .formats = mt8173_formats,
- .num_formats = ARRAY_SIZE(mt8173_formats),
+ .formats = mt8195_formats,
+ .num_formats = ARRAY_SIZE(mt8195_formats),
};
static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
--
2.39.1.456.gfc5497dd1b-goog
[PATCH 0/2 v6] drm/mediatek: Add support for 10-bit overlays
This patch series adds support for 10-bit overlays to the Mediatek DRM driver. Specifically, we add support for AR30 and BA30 overlays on MT8195 devices and lay the groundwork for supporting more 10-bit formats on more devices. 1. Refactor plane initialization logic to allow individual DDP components to provide their supported pixel formats. 2. Add AR30 and BA30 support to the MT8195 overlay driver. Version history: v6: * Refactor patch into patch series. * Add formats directly to private data. v5: * Removed some dead defines. * Refactored mtk_ovl_set_afbc(). v4: * Move modifier validation to format_mod_supported function. * Add modifiers to drm_universal_plane_init() call. * Make comparisons to DRM_FORMAT_MOD_LINEAR explicit rather than relying on DRM_FORMAT_LINEAR being equal to 0. * Gate AFBC control bit writes on device compatibility. v3: * Replaced pitch bitshift math with union based approach. * Refactored overlay register writes to shared code between non-AFBC and AFBC. * Minor code cleanups. v2: * Marked mtk_ovl_set_afbc as static. * Reflowed some lines to fit column limit. Justin Green (2): drm/mediatek: Refactor pixel format logic drm/mediatek: Add support for AR30 and BA30 overlays drivers/gpu/drm/mediatek/mtk_disp_drv.h | 4 + drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 89 + drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 38 + drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 4 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 20 + drivers/gpu/drm/mediatek/mtk_drm_plane.c| 24 ++ drivers/gpu/drm/mediatek/mtk_drm_plane.h| 3 +- 8 files changed, 168 insertions(+), 18 deletions(-) -- 2.39.1.456.gfc5497dd1b-goog
[PATCH v3 6/6] drm/debugfs: Make the struct drm_debugfs_entry independent of DRM device
In order to turn the API more expansible to other DRM objects, such as
the struct drm_connector, make the struct drm_debugfs_entry hold a void
pointer and cast the void pointer to the struct drm_device when needed.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/drm_debugfs.c | 4 ++--
include/drm/drm_debugfs.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 21f01c7d0ab1..f12c3fdf61bb 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -141,7 +141,7 @@ static int drm_debugfs_dev_show(struct seq_file *m, void
*unused)
struct drm_debugfs_entry *entry = m->private;
int (*show)(struct seq_file *, struct drm_device *, void *) =
entry->file.show;
- return show(m, entry->dev, entry->file.data);
+ return show(m, entry->object, entry->file.data);
}
static int drm_debugfs_open(struct inode *inode, struct file *file)
@@ -362,7 +362,7 @@ void drm_debugfs_add_file(struct drm_device *dev, const
char *name,
entry->file.name = name;
entry->file.show = show;
entry->file.data = data;
- entry->dev = dev;
+ entry->object = dev;
drm_debugfs_files_add(dev->debugfs_files, >list);
}
diff --git a/include/drm/drm_debugfs.h b/include/drm/drm_debugfs.h
index 0fb7ad5f6893..4ab0557f55e0 100644
--- a/include/drm/drm_debugfs.h
+++ b/include/drm/drm_debugfs.h
@@ -130,8 +130,8 @@ struct drm_debugfs_info {
* drm_debugfs_info on a drm_device.
*/
struct drm_debugfs_entry {
- /** @dev: drm_device for this node. */
- struct drm_device *dev;
+ /** @object: The DRM object that owns this node. */
+ void *object;
/** @file: Template for this node. */
struct drm_debugfs_info file;
--
2.39.1
[PATCH v3 5/6] drm/debugfs: Make the show callback pass the pointer to the right object
Currently, the drivers need to access the struct drm_debugfs_entry to
get the proper device on the show callback. There is no need for such
thing, as you can wrap the show callback in order to provide to the
driver the proper parameters: the struct seq_file, the struct drm_device
and the driver-specific data stored in the struct drm_debugfs_info.
Therefore, make the show callback pass the pointer to the right object
in the parameters, which makes the API more type-safe.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/arm/hdlcd_drv.c | 8 ++--
drivers/gpu/drm/drm_atomic.c | 4 +---
drivers/gpu/drm/drm_client.c | 5 ++---
drivers/gpu/drm/drm_debugfs.c | 25 -
drivers/gpu/drm/drm_framebuffer.c | 4 +---
drivers/gpu/drm/drm_gem_vram_helper.c | 5 ++---
drivers/gpu/drm/gud/gud_drv.c | 5 ++---
drivers/gpu/drm/v3d/v3d_debugfs.c | 16
drivers/gpu/drm/vc4/vc4_bo.c | 4 +---
drivers/gpu/drm/vc4/vc4_debugfs.c | 6 ++
drivers/gpu/drm/vc4/vc4_hdmi.c| 6 ++
drivers/gpu/drm/vc4/vc4_hvs.c | 8 ++--
drivers/gpu/drm/vc4/vc4_v3d.c | 4 +---
drivers/gpu/drm/vkms/vkms_drv.c | 4 +---
include/drm/drm_debugfs.h | 14 --
15 files changed, 43 insertions(+), 75 deletions(-)
diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index e3507dd6f82a..b70bc7b11764 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -193,10 +193,8 @@ static int hdlcd_setup_mode_config(struct drm_device *drm)
}
#ifdef CONFIG_DEBUG_FS
-static int hdlcd_show_underrun_count(struct seq_file *m, void *arg)
+static int hdlcd_show_underrun_count(struct seq_file *m, struct drm_device
*drm, void *arg)
{
- struct drm_debugfs_entry *entry = m->private;
- struct drm_device *drm = entry->dev;
struct hdlcd_drm_private *hdlcd = drm_to_hdlcd_priv(drm);
seq_printf(m, "underrun : %d\n",
atomic_read(>buffer_underrun_count));
@@ -206,10 +204,8 @@ static int hdlcd_show_underrun_count(struct seq_file *m,
void *arg)
return 0;
}
-static int hdlcd_show_pxlclock(struct seq_file *m, void *arg)
+static int hdlcd_show_pxlclock(struct seq_file *m, struct drm_device *drm,
void *arg)
{
- struct drm_debugfs_entry *entry = m->private;
- struct drm_device *drm = entry->dev;
struct hdlcd_drm_private *hdlcd = drm_to_hdlcd_priv(drm);
unsigned long clkrate = clk_get_rate(hdlcd->clk);
unsigned long mode_clock = hdlcd->crtc.mode.crtc_clock * 1000;
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 5457c02ca1ab..38f140481fcc 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1754,10 +1754,8 @@ void drm_state_dump(struct drm_device *dev, struct
drm_printer *p)
EXPORT_SYMBOL(drm_state_dump);
#ifdef CONFIG_DEBUG_FS
-static int drm_state_info(struct seq_file *m, void *data)
+static int drm_state_info(struct seq_file *m, struct drm_device *dev, void
*data)
{
- struct drm_debugfs_entry *entry = m->private;
- struct drm_device *dev = entry->dev;
struct drm_printer p = drm_seq_file_printer(m);
__drm_state_dump(dev, , true);
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 009e7b10455c..ec2e6bc3515d 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -488,10 +488,9 @@ int drm_client_framebuffer_flush(struct drm_client_buffer
*buffer, struct drm_re
EXPORT_SYMBOL(drm_client_framebuffer_flush);
#ifdef CONFIG_DEBUG_FS
-static int drm_client_debugfs_internal_clients(struct seq_file *m, void *data)
+static int drm_client_debugfs_internal_clients(struct seq_file *m, struct
drm_device *dev,
+ void *data)
{
- struct drm_debugfs_entry *entry = m->private;
- struct drm_device *dev = entry->dev;
struct drm_printer p = drm_seq_file_printer(m);
struct drm_client_dev *client;
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index b4d2e7dd87f5..21f01c7d0ab1 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -49,10 +49,8 @@
* Initialization, etc.
**/
-static int drm_name_info(struct seq_file *m, void *data)
+static int drm_name_info(struct seq_file *m, struct drm_device *dev, void
*data)
{
- struct drm_debugfs_entry *entry = m->private;
- struct drm_device *dev = entry->dev;
struct drm_master *master;
mutex_lock(>master_mutex);
@@ -70,10 +68,8 @@ static int drm_name_info(struct seq_file *m, void *data)
return 0;
}
-static int drm_clients_info(struct seq_file *m, void *data)
+static int drm_clients_info(struct seq_file *m, struct drm_device *dev, void
*data)
{
- struct drm_debugfs_entry *entry =
[PATCH v3 4/6] drm/debugfs: Create wrapper to register debugfs
Create a helper to encapsulate the code that creates a new debugfs files
from a linked list related to an object. Moreover, the helper also
provides more flexibily on the type of the object.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/drm_debugfs.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 0e3f3ffa9f88..b4d2e7dd87f5 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -243,11 +243,21 @@ static void drm_debugfs_files_add(struct
drm_debugfs_files *debugfs_files, struc
mutex_unlock(_files->mutex);
}
+static void drm_debugfs_register(struct drm_minor *minor, struct
drm_debugfs_files *debugfs_files)
+{
+ struct drm_debugfs_entry *entry, *tmp;
+
+ list_for_each_entry_safe(entry, tmp, _files->list, list) {
+ debugfs_create_file(entry->file.name, 0444,
+ minor->debugfs_root, entry,
_debugfs_entry_fops);
+ list_del(>list);
+ }
+}
+
int drm_debugfs_init(struct drm_minor *minor, int minor_id,
struct dentry *root)
{
struct drm_device *dev = minor->dev;
- struct drm_debugfs_entry *entry, *tmp;
char name[64];
INIT_LIST_HEAD(>debugfs_list);
@@ -270,11 +280,7 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
if (dev->driver->debugfs_init)
dev->driver->debugfs_init(minor);
- list_for_each_entry_safe(entry, tmp, >debugfs_files->list, list) {
- debugfs_create_file(entry->file.name, 0444,
- minor->debugfs_root, entry,
_debugfs_entry_fops);
- list_del(>list);
- }
+ drm_debugfs_register(minor, dev->debugfs_files);
return 0;
}
@@ -282,16 +288,11 @@ int drm_debugfs_init(struct drm_minor *minor, int
minor_id,
void drm_debugfs_late_register(struct drm_device *dev)
{
struct drm_minor *minor = dev->primary;
- struct drm_debugfs_entry *entry, *tmp;
if (!minor)
return;
- list_for_each_entry_safe(entry, tmp, >debugfs_files->list, list) {
- debugfs_create_file(entry->file.name, 0444,
- minor->debugfs_root, entry,
_debugfs_entry_fops);
- list_del(>list);
- }
+ drm_debugfs_register(minor, dev->debugfs_files);
}
int drm_debugfs_remove_files(const struct drm_info_list *files, int count,
--
2.39.1
[PATCH v3 3/6] drm/debugfs: Create wrapper to add files to debugfs list
Create a helper to encapsulate the code that adds a new debugfs file to
a linked list related to a object. Moreover, the helper also provides
more flexibily, as the parameter is a struct drm_debugfs_files.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/drm_debugfs.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index aa83f230c402..0e3f3ffa9f88 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -236,6 +236,13 @@ void drm_debugfs_files_destroy(struct drm_debugfs_files
*debugfs_files)
kfree(debugfs_files);
}
+static void drm_debugfs_files_add(struct drm_debugfs_files *debugfs_files,
struct list_head *entry)
+{
+ mutex_lock(_files->mutex);
+ list_add(entry, _files->list);
+ mutex_unlock(_files->mutex);
+}
+
int drm_debugfs_init(struct drm_minor *minor, int minor_id,
struct dentry *root)
{
@@ -357,9 +364,7 @@ void drm_debugfs_add_file(struct drm_device *dev, const
char *name,
entry->file.data = data;
entry->dev = dev;
- mutex_lock(>debugfs_files->mutex);
- list_add(>list, >debugfs_files->list);
- mutex_unlock(>debugfs_files->mutex);
+ drm_debugfs_files_add(dev->debugfs_files, >list);
}
EXPORT_SYMBOL(drm_debugfs_add_file);
--
2.39.1
[PATCH v3 1/6] drm/debugfs: Introduce wrapper for debugfs list
Introduce a struct wrapper for all the debugfs-related stuff: the list
of debugfs files and the mutex that protects it. This will make it
easier to initialize all the debugfs list in a DRM object and will
create a good abstraction for a possible implementation of the debugfs
infrastructure for KMS objects.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/drm_debugfs.c | 18 ++
drivers/gpu/drm/drm_internal.h | 12
include/drm/drm_debugfs.h | 16
3 files changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 4f643a490dc3..8658d3929ea5 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -218,6 +218,24 @@ void drm_debugfs_create_files(const struct drm_info_list
*files, int count,
}
EXPORT_SYMBOL(drm_debugfs_create_files);
+struct drm_debugfs_files *drm_debugfs_files_init(void)
+{
+ struct drm_debugfs_files *debugfs_files;
+
+ debugfs_files = kzalloc(sizeof(*debugfs_files), GFP_KERNEL);
+
+ INIT_LIST_HEAD(_files->list);
+ mutex_init(_files->mutex);
+
+ return debugfs_files;
+}
+
+void drm_debugfs_files_destroy(struct drm_debugfs_files *debugfs_files)
+{
+ mutex_destroy(_files->mutex);
+ kfree(debugfs_files);
+}
+
int drm_debugfs_init(struct drm_minor *minor, int minor_id,
struct dentry *root)
{
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index ed2103ee272c..f1c8766ed828 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -23,6 +23,7 @@
#include
+#include
#include
#include
@@ -183,6 +184,8 @@ int drm_gem_dumb_destroy(struct drm_file *file, struct
drm_device *dev,
/* drm_debugfs.c drm_debugfs_crc.c */
#if defined(CONFIG_DEBUG_FS)
+struct drm_debugfs_files *drm_debugfs_files_init(void);
+void drm_debugfs_files_destroy(struct drm_debugfs_files *debugfs_files);
int drm_debugfs_init(struct drm_minor *minor, int minor_id,
struct dentry *root);
void drm_debugfs_cleanup(struct drm_minor *minor);
@@ -193,6 +196,15 @@ void drm_debugfs_crtc_add(struct drm_crtc *crtc);
void drm_debugfs_crtc_remove(struct drm_crtc *crtc);
void drm_debugfs_crtc_crc_add(struct drm_crtc *crtc);
#else
+static inline struct drm_debugfs_files *drm_debugfs_files_init(void)
+{
+ return NULL;
+}
+
+static inline void drm_debugfs_files_destroy(struct drm_debugfs_files
*debugfs_files)
+{
+}
+
static inline int drm_debugfs_init(struct drm_minor *minor, int minor_id,
struct dentry *root)
{
diff --git a/include/drm/drm_debugfs.h b/include/drm/drm_debugfs.h
index 7616f457ce70..423aa3de506a 100644
--- a/include/drm/drm_debugfs.h
+++ b/include/drm/drm_debugfs.h
@@ -32,6 +32,8 @@
#ifndef _DRM_DEBUGFS_H_
#define _DRM_DEBUGFS_H_
+#include
+#include
#include
#include
/**
@@ -79,6 +81,20 @@ struct drm_info_node {
struct dentry *dent;
};
+/**
+ * struct drm_debugfs_files - Encapsulates the debugfs list and its mutex
+ *
+ * This structure represents the debugfs list of files and is encapsulated
+ * with a mutex to protect the access of the list.
+ */
+struct drm_debugfs_files {
+ /** @list: List of debugfs files to be created by the DRM object. */
+ struct list_head list;
+
+ /** @mutex: Protects access. */
+ struct mutex mutex;
+};
+
/**
* struct drm_debugfs_info - debugfs info list entry
*
--
2.39.1
[PATCH v3 0/6] drm/debugfs: Make the debugfs structure more generic
This series is the first step to introduce a debugfs structure to KMS objects and it is inspired by the feedback provided in [1]. Thanks, Jani and Daniel for all the feedback provided! This first step is making the current API more generic and preparing it to receive the KMS objects in the future. Moreover, this will help to avoid copypasting when expanding the API. Make the debug structure more generic by: - Passing the right pointer to the functions as an explicit parameter. So, the show function signature should be int show(struct seq_file *m, struct drm_device *dev, void *data) Note that with this approach, the show callback doesn't need to use the struct drm_debugfs_entry anymore. - Switch the pointer in struct drm_debugfs_entry to void *, so that, in the future, the struct drm_debugfs_entry can receive different types of DRM objects (struct drm_device, struct drm_connector, struct drm_crtc...). - Switch the show callback pointer to void * and cast it in the show callback wrapper. This way in the future we can create different callback wrappers and cast each one to the proper function signature. - Add a struct wrapper for debugfs_list and debugfs_mutex, and also create helpers to init the list, destroy the list, register the list's files and add files to the list. v1 -> v2: https://lore.kernel.org/dri-devel/20230116102815.95063-1-mca...@igalia.com/T/ - Use forward declaration instead of the header (Jani Nikula). - Make the struct drm_debugfs_files a pointer in struct drm_device (Jani Nikula). - Change the parameter order of `drm_debugfs_files_add` (Jani Nikula). - s/struct drm_debugfs_list/struct drm_debugfs_files (Jani Nikula). v2 -> v3: https://lore.kernel.org/dri-devel/20230130123008.287141-1-mca...@igalia.com/T/ - Fix compilation errors for CONFIG_DEBUG_FS=n (kernel test robot). [1] https://lore.kernel.org/dri-devel/2023073748.752659-1-mca...@igalia.com/T/ Best Regards, - Maíra Canal Maíra Canal (6): drm/debugfs: Introduce wrapper for debugfs list drm/debugfs: Make drm_device use the struct drm_debugfs_files drm/debugfs: Create wrapper to add files to debugfs list drm/debugfs: Create wrapper to register debugfs drm/debugfs: Make the show callback pass the pointer to the right object drm/debugfs: Make the struct drm_debugfs_entry independent of DRM device drivers/gpu/drm/arm/hdlcd_drv.c | 8 +-- drivers/gpu/drm/drm_atomic.c | 4 +- drivers/gpu/drm/drm_client.c | 5 +- drivers/gpu/drm/drm_debugfs.c | 81 +-- drivers/gpu/drm/drm_drv.c | 7 ++- drivers/gpu/drm/drm_framebuffer.c | 4 +- drivers/gpu/drm/drm_gem_vram_helper.c | 5 +- drivers/gpu/drm/drm_internal.h| 12 drivers/gpu/drm/gud/gud_drv.c | 5 +- drivers/gpu/drm/v3d/v3d_debugfs.c | 16 ++ drivers/gpu/drm/vc4/vc4_bo.c | 4 +- drivers/gpu/drm/vc4/vc4_debugfs.c | 6 +- drivers/gpu/drm/vc4/vc4_hdmi.c| 6 +- drivers/gpu/drm/vc4/vc4_hvs.c | 8 +-- drivers/gpu/drm/vc4/vc4_v3d.c | 4 +- drivers/gpu/drm/vkms/vkms_drv.c | 4 +- include/drm/drm_debugfs.h | 34 --- include/drm/drm_device.h | 12 +--- 18 files changed, 120 insertions(+), 105 deletions(-) -- 2.39.1
[PATCH v3 2/6] drm/debugfs: Make drm_device use the struct drm_debugfs_files
The struct drm_debugfs_files encapsulates all the debugfs-related
objects, so that they can be initialized and destroyed with two helpers.
Therefore, make the struct drm_device use the struct drm_debugfs_files
instead of instantiating the debugfs list and mutex separated.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/drm_debugfs.c | 10 +-
drivers/gpu/drm/drm_drv.c | 7 ---
include/drm/drm_device.h | 12 +++-
3 files changed, 12 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 8658d3929ea5..aa83f230c402 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -263,7 +263,7 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
if (dev->driver->debugfs_init)
dev->driver->debugfs_init(minor);
- list_for_each_entry_safe(entry, tmp, >debugfs_list, list) {
+ list_for_each_entry_safe(entry, tmp, >debugfs_files->list, list) {
debugfs_create_file(entry->file.name, 0444,
minor->debugfs_root, entry,
_debugfs_entry_fops);
list_del(>list);
@@ -280,7 +280,7 @@ void drm_debugfs_late_register(struct drm_device *dev)
if (!minor)
return;
- list_for_each_entry_safe(entry, tmp, >debugfs_list, list) {
+ list_for_each_entry_safe(entry, tmp, >debugfs_files->list, list) {
debugfs_create_file(entry->file.name, 0444,
minor->debugfs_root, entry,
_debugfs_entry_fops);
list_del(>list);
@@ -357,9 +357,9 @@ void drm_debugfs_add_file(struct drm_device *dev, const
char *name,
entry->file.data = data;
entry->dev = dev;
- mutex_lock(>debugfs_mutex);
- list_add(>list, >debugfs_list);
- mutex_unlock(>debugfs_mutex);
+ mutex_lock(>debugfs_files->mutex);
+ list_add(>list, >debugfs_files->list);
+ mutex_unlock(>debugfs_files->mutex);
}
EXPORT_SYMBOL(drm_debugfs_add_file);
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index c6eb8972451a..50812cbe1d81 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -598,7 +599,7 @@ static void drm_dev_init_release(struct drm_device *dev,
void *res)
mutex_destroy(>clientlist_mutex);
mutex_destroy(>filelist_mutex);
mutex_destroy(>struct_mutex);
- mutex_destroy(>debugfs_mutex);
+ drm_debugfs_files_destroy(dev->debugfs_files);
drm_legacy_destroy_members(dev);
}
@@ -639,14 +640,14 @@ static int drm_dev_init(struct drm_device *dev,
INIT_LIST_HEAD(>filelist_internal);
INIT_LIST_HEAD(>clientlist);
INIT_LIST_HEAD(>vblank_event_list);
- INIT_LIST_HEAD(>debugfs_list);
spin_lock_init(>event_lock);
mutex_init(>struct_mutex);
mutex_init(>filelist_mutex);
mutex_init(>clientlist_mutex);
mutex_init(>master_mutex);
- mutex_init(>debugfs_mutex);
+
+ dev->debugfs_files = drm_debugfs_files_init();
ret = drmm_add_action_or_reset(dev, drm_dev_init_release, NULL);
if (ret)
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index 7cf4afae2e79..77290f4a06ff 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -16,6 +16,7 @@ struct drm_vblank_crtc;
struct drm_vma_offset_manager;
struct drm_vram_mm;
struct drm_fb_helper;
+struct drm_debugfs_files;
struct inode;
@@ -312,19 +313,12 @@ struct drm_device {
struct drm_fb_helper *fb_helper;
/**
-* @debugfs_mutex:
-*
-* Protects _list access.
-*/
- struct mutex debugfs_mutex;
-
- /**
-* @debugfs_list:
+* @debugfs_files:
*
* List of debugfs files to be created by the DRM device. The files
* must be added during drm_dev_register().
*/
- struct list_head debugfs_list;
+ struct drm_debugfs_files *debugfs_files;
/* Everything below here is for legacy driver, never use! */
/* private: */
--
2.39.1
Re: [PATCH v2 0/8] drm/vmwgfx: Refactor the buffer object code
Hi, I cannot comment much on the internal workings of the vmwgfx driver, but feel free to add Acked-by: Thomas Zimmermann to the patches that don't already have my r-b. Best regards Thomas Am 31.01.23 um 04:35 schrieb Zack Rusin: From: Zack Rusin v2: Fix all the issues which Thomas pointed out in the initial review and split the "simplify fb pinning" change into two commits with the second one being just the rename. The series refactors the buffer object code to make more alike the other ttm drivers. The placement becomes a property of the bo which makes it a lot easier to correctly validate based on the current usage. vmwgfx tends to do more validation due to forced moves, because the buffer placement sometimes need to change due to userspace commands, i.e. some commands e.g. SURFACE_DMA implies GMR's which are really deprecated in favor of MOB's, but the x11 driver still uses GMR's so buffers tend to flip between GMR's and MOB's a bit when running on X11. The functionality remains largely unchanged, but the LOC are reduced by about 400 and the groundwork is done for adding prime support with SG ttm buffers. Zack Rusin (8): drm/vmwgfx: Use the common gem mmap instead of the custom code drm/vmwgfx: Remove the duplicate bo_free function drm/vmwgfx: Rename vmw_buffer_object to vmw_bo drm/vmwgfx: Simplify fb pinning drm/vmwgfx: Cleanup the vmw bo usage in the cursor paths drm/vmwgfx: Rename dummy to is_iomem drm/vmwgfx: Abstract placement selection drm/vmwgfx: Stop using raw ttm_buffer_object's drivers/gpu/drm/vmwgfx/Makefile | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 392 +- drivers/gpu/drm/vmwgfx/vmwgfx_bo.h| 203 + drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c | 14 +- drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c| 53 +-- drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 36 +- drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 65 +-- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 26 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 245 +++ drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 102 +++-- drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 89 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 230 -- drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 43 +- drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 57 ++- drivers/gpu/drm/vmwgfx/vmwgfx_mob.c | 45 +- drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | 20 +- drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c| 68 ++- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 243 +-- drivers/gpu/drm/vmwgfx/vmwgfx_resource_priv.h | 10 +- drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 53 +-- drivers/gpu/drm/vmwgfx/vmwgfx_shader.c| 65 +-- drivers/gpu/drm/vmwgfx/vmwgfx_so.c| 6 +- drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 323 ++- drivers/gpu/drm/vmwgfx/vmwgfx_streamoutput.c | 20 +- drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 111 ++--- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c| 116 +- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 110 - drivers/gpu/drm/vmwgfx/vmwgfx_va.c| 6 +- drivers/gpu/drm/vmwgfx/vmwgfx_validation.c| 150 +++ drivers/gpu/drm/vmwgfx/vmwgfx_validation.h| 10 +- 31 files changed, 1248 insertions(+), 1667 deletions(-) create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_bo.h delete mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v2 8/8] drm/vmwgfx: Stop using raw ttm_buffer_object's
From: Martin Krastev
LGTM!
Reviewed-by: Martin Krastev
Regards,
Martin
On 31.01.23 г. 5:35 ч., Zack Rusin wrote:
From: Zack Rusin
Various bits of the driver used raw ttm_buffer_object instead of the
driver specific vmw_bo object. All those places used to duplicate
the mapped bo caching policy of vmw_bo.
Instead of duplicating all of that code and special casing various
functions to work both with vmw_bo and raw ttm_buffer_object's unify
the buffer object handling code.
As part of that work fix the naming of bo's, e.g. insted of generic
backup use 'guest_memory' because that's what it really is.
All of it makes the driver easier to maintain and the code easier to
read. Saves 100+ loc as well.
Signed-off-by: Zack Rusin
---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 204 +---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.h| 60 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c| 44 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 16 +-
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 51 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 17 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 53 +++--
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 14 +-
drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 37 +--
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 105 -
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 6 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_mob.c | 38 +--
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c| 51 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 220 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource_priv.h | 7 +-
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 29 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c| 49 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_so.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 8 +-
drivers/gpu/drm/vmwgfx/vmwgfx_streamoutput.c | 8 +-
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 98
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c| 66 ++
drivers/gpu/drm/vmwgfx/vmwgfx_va.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_validation.c| 62 +++--
27 files changed, 566 insertions(+), 691 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index d8f6ccecf4bf..63486802c8fd 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -32,6 +32,12 @@
#include
+static void vmw_bo_release(struct vmw_bo *vbo)
+{
+ vmw_bo_unmap(vbo);
+ drm_gem_object_release(>tbo.base);
+}
+
/**
* vmw_bo_free - vmw_bo destructor
*
@@ -43,26 +49,10 @@ static void vmw_bo_free(struct ttm_buffer_object *bo)
WARN_ON(vbo->dirty);
WARN_ON(!RB_EMPTY_ROOT(>res_tree));
- vmw_bo_unmap(vbo);
- drm_gem_object_release(>base);
+ vmw_bo_release(vbo);
kfree(vbo);
}
-/**
- * bo_is_vmw - check if the buffer object is a _bo
- * @bo: ttm buffer object to be checked
- *
- * Uses destroy function associated with the object to determine if this is
- * a _bo.
- *
- * Returns:
- * true if the object is of _bo type, false if not.
- */
-static bool bo_is_vmw(struct ttm_buffer_object *bo)
-{
- return bo->destroy == _bo_free;
-}
-
/**
* vmw_bo_pin_in_placement - Validate a buffer to placement.
*
@@ -79,7 +69,7 @@ static int vmw_bo_pin_in_placement(struct vmw_private
*dev_priv,
bool interruptible)
{
struct ttm_operation_ctx ctx = {interruptible, false };
- struct ttm_buffer_object *bo = >base;
+ struct ttm_buffer_object *bo = >tbo;
int ret;
vmw_execbuf_release_pinned_bo(dev_priv);
@@ -88,7 +78,7 @@ static int vmw_bo_pin_in_placement(struct vmw_private
*dev_priv,
if (unlikely(ret != 0))
goto err;
- if (buf->base.pin_count > 0)
+ if (buf->tbo.pin_count > 0)
ret = ttm_resource_compat(bo->resource, placement)
? 0 : -EINVAL;
else
@@ -120,7 +110,7 @@ int vmw_bo_pin_in_vram_or_gmr(struct vmw_private *dev_priv,
bool interruptible)
{
struct ttm_operation_ctx ctx = {interruptible, false };
- struct ttm_buffer_object *bo = >base;
+ struct ttm_buffer_object *bo = >tbo;
int ret;
vmw_execbuf_release_pinned_bo(dev_priv);
@@ -129,7 +119,7 @@ int vmw_bo_pin_in_vram_or_gmr(struct vmw_private *dev_priv,
if (unlikely(ret != 0))
goto err;
- if (buf->base.pin_count > 0) {
+ if (buf->tbo.pin_count > 0) {
ret = ttm_resource_compat(bo->resource, _vram_gmr_placement)
? 0 : -EINVAL;
goto out_unreserve;
@@ -195,7 +185,7 @@ int
Re: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini
On Tue, Jan 31, 2023 at 1:23 PM Guilherme G. Piccoli wrote: > > On 31/01/2023 14:52, Alex Deucher wrote: > > [...] > >> (b) We can't use sched.ready, which would make sense...but amdgpu > >> overrides its meaning, the driver manipulates this value for its own > >> purposes of tracking ring init, or something like that. > >> > >> This is the tangential topic: what should we do here? My understanding > >> of Alex's message is that we could have a "ready" field in the ring > >> structure and stop messing with sched.ready - does it make sense Alex? > > > > Yes, I think so. The tricky part will be figuring out which current > > sched.ready checks are checking for the scheduler being ready vs. > > whether the ring itself is ready. > > > > Thanks, makes sense! > > $ grep -nr "sched.ready" drivers/gpu/drm/amd/ | wc -l > 83 > > Maybe not super tough, I hope heh > > >> > >> Guchun / Christian, does it also make sense for you? > >> > >> > >> Regarding (a), I could re-submit having s/sched.name/sched.ops, no > >> biggies, I tested both to be fair, before sending...I just chose name > >> but any field that is proper initialized on drm_sched_init() would work. > > > > Yeah, I think ops is fine. You could even use sched.ready after we > > clean up the use of that in the driver. There are already a bunch of > > places where we check sched.ready to check if the scheduler really is > > ready. > > Hmm..unfortunately, doesn't work. This was a case in which sched.ready > was set to true in the ring init routine, but scheduler wasn't properly > initialized. So, a different key for comparison is required..I'll > re-submit with sched.ops. > > After a potential rework of the driver to get rid of sched.ready > manipulation, then it could be fixed to properly use this flag...makes > sense to you? Yeah, sounds good. Thanks! Alex > > Tnx again for the prompt review! > Cheers, > > > Guilherme
Re: linux-next: manual merge of the usb tree with the drm-intel-fixes tree
On 1/31/2023 04:44, Andy Shevchenko wrote:
On Tue, Jan 31, 2023 at 01:03:05PM +1100, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the usb tree got a conflict in:
drivers/gpu/drm/i915/gt/intel_engine_cs.c
between commit:
5bc4b43d5c6c ("drm/i915: Fix up locking around dumping requests lists")
from the drm-intel-fixes tree and commit:
4d70c74659d9 ("i915: Move list_count() to list.h as list_count_nodes() for
broader use")
from the usb tree.
I fixed it up (the former removed the code changed by the latter)
Hmm... Currently I see that 20230127002842.3169194-4-john.c.harri...@intel.com
moves the code to the drivers/gpu/drm/i915/gt/intel_execlists_submission.c.
Is there any new series beside the above mentioned that touches that file and
actually _removes_ that code?
As long as the removal is limited to list_count/list_count_nodes, that's
fine. I only moved it from one file to another because the one and only
function that was using it was being moved to the other file. If someone
else has found a use for the same and wants to move it to a more common
place then great. I assume there was no conflict happening in the i915
specific code.
John.
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.
Re: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini
On 31/01/2023 14:52, Alex Deucher wrote: > [...] >> (b) We can't use sched.ready, which would make sense...but amdgpu >> overrides its meaning, the driver manipulates this value for its own >> purposes of tracking ring init, or something like that. >> >> This is the tangential topic: what should we do here? My understanding >> of Alex's message is that we could have a "ready" field in the ring >> structure and stop messing with sched.ready - does it make sense Alex? > > Yes, I think so. The tricky part will be figuring out which current > sched.ready checks are checking for the scheduler being ready vs. > whether the ring itself is ready. > Thanks, makes sense! $ grep -nr "sched.ready" drivers/gpu/drm/amd/ | wc -l 83 Maybe not super tough, I hope heh >> >> Guchun / Christian, does it also make sense for you? >> >> >> Regarding (a), I could re-submit having s/sched.name/sched.ops, no >> biggies, I tested both to be fair, before sending...I just chose name >> but any field that is proper initialized on drm_sched_init() would work. > > Yeah, I think ops is fine. You could even use sched.ready after we > clean up the use of that in the driver. There are already a bunch of > places where we check sched.ready to check if the scheduler really is > ready. Hmm..unfortunately, doesn't work. This was a case in which sched.ready was set to true in the ring init routine, but scheduler wasn't properly initialized. So, a different key for comparison is required..I'll re-submit with sched.ops. After a potential rework of the driver to get rid of sched.ready manipulation, then it could be fixed to properly use this flag...makes sense to you? Tnx again for the prompt review! Cheers, Guilherme
Re: [PATCH v2 6/8] drm/vmwgfx: Rename dummy to is_iomem
From: Martin Krastev
LGTM
Reviewed-by: Martin Krastev
Regards,
Martin
On 31.01.23 г. 5:35 ч., Zack Rusin wrote:
From: Zack Rusin
Rename dummy to is_iomem because that's what it is even if we're not
activelly using it. Makes the code easier to read.
Signed-off-by: Zack Rusin
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 1082218a1cfc..e83286e08837 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -153,9 +153,9 @@ static void vmw_cursor_update_mob(struct vmw_private
*dev_priv,
SVGAGBCursorHeader *header;
SVGAGBAlphaCursorHeader *alpha_header;
const u32 image_size = width * height * sizeof(*image);
- bool dummy;
+ bool is_iomem;
- header = ttm_kmap_obj_virtual(>cursor.map, );
+ header = ttm_kmap_obj_virtual(>cursor.map, _iomem);
alpha_header = >header.alphaHeader;
memset(header, 0, sizeof(*header));
@@ -185,13 +185,13 @@ static u32 vmw_du_cursor_mob_size(u32 w, u32 h)
*/
static u32 *vmw_du_cursor_plane_acquire_image(struct vmw_plane_state *vps)
{
- bool dummy;
+ bool is_iomem;
if (vps->surf) {
if (vps->surf_mapped)
return vmw_bo_map_and_cache(vps->surf->res.backup);
return vps->surf->snooper.image;
} else if (vps->bo)
- return ttm_kmap_obj_virtual(>bo->map, );
+ return ttm_kmap_obj_virtual(>bo->map, _iomem);
return NULL;
}
@@ -364,7 +364,7 @@ void vmw_kms_cursor_snoop(struct vmw_surface *srf,
SVGA3dCopyBox *box;
unsigned box_count;
void *virtual;
- bool dummy;
+ bool is_iomem;
struct vmw_dma_cmd {
SVGA3dCmdHeader header;
SVGA3dCmdSurfaceDMA dma;
@@ -424,7 +424,7 @@ void vmw_kms_cursor_snoop(struct vmw_surface *srf,
if (unlikely(ret != 0))
goto err_unreserve;
- virtual = ttm_kmap_obj_virtual(, );
+ virtual = ttm_kmap_obj_virtual(, _iomem);
if (box->w == VMW_CURSOR_SNOOP_WIDTH && cmd->dma.guest.pitch == image_pitch) {
memcpy(srf->snooper.image, virtual,
@@ -658,14 +658,14 @@ vmw_du_cursor_plane_cleanup_fb(struct drm_plane *plane,
{
struct vmw_cursor_plane *vcp = vmw_plane_to_vcp(plane);
struct vmw_plane_state *vps = vmw_plane_state_to_vps(old_state);
- bool dummy;
+ bool is_iomem;
if (vps->surf_mapped) {
vmw_bo_unmap(vps->surf->res.backup);
vps->surf_mapped = false;
}
- if (vps->bo && ttm_kmap_obj_virtual(>bo->map, )) {
+ if (vps->bo && ttm_kmap_obj_virtual(>bo->map, _iomem)) {
const int ret = ttm_bo_reserve(>bo->base, true, false,
NULL);
if (likely(ret == 0)) {
Re: [PATCH v2 7/8] drm/vmwgfx: Abstract placement selection
From: Martin Krastev
LGTM
Reviewed-by: Martin Krastev
Regards,
Martin
On 31.01.23 г. 5:35 ч., Zack Rusin wrote:
From: Zack Rusin
Problem with explicit placement selection in vmwgfx is that by the time
the buffer object needs to be validated the information about which
placement was supposed to be used is lost. To workaround this the driver
had a bunch of state in various places e.g. as_mob or cpu_blit to
somehow convey the information on which placement was intended.
Fix it properly by allowing the buffer objects to hold their preferred
placement so it can be reused whenever needed. This makes the entire
validation pipeline a lot easier both to understand and maintain.
Signed-off-by: Zack Rusin
---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 145 +++--
drivers/gpu/drm/vmwgfx/vmwgfx_bo.h| 25 +-
drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 9 +-
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 11 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 3 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 2 -
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 35 +-
drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 5 +-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 22 +-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 21 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 11 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource_priv.h | 3 +-
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 13 +-
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c| 15 +-
drivers/gpu/drm/vmwgfx/vmwgfx_so.c| 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 304 ++
drivers/gpu/drm/vmwgfx/vmwgfx_streamoutput.c | 3 +-
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 6 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c| 47 ---
drivers/gpu/drm/vmwgfx/vmwgfx_va.c| 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_validation.c| 74 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_validation.h| 6 +-
22 files changed, 312 insertions(+), 456 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index c6dc733f6d45..d8f6ccecf4bf 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -135,11 +135,17 @@ int vmw_bo_pin_in_vram_or_gmr(struct vmw_private
*dev_priv,
goto out_unreserve;
}
- ret = ttm_bo_validate(bo, _vram_gmr_placement, );
+ vmw_bo_placement_set(buf,
+VMW_BO_DOMAIN_GMR | VMW_BO_DOMAIN_VRAM,
+VMW_BO_DOMAIN_GMR);
+ ret = ttm_bo_validate(bo, >placement, );
if (likely(ret == 0) || ret == -ERESTARTSYS)
goto out_unreserve;
- ret = ttm_bo_validate(bo, _vram_placement, );
+ vmw_bo_placement_set(buf,
+VMW_BO_DOMAIN_VRAM,
+VMW_BO_DOMAIN_VRAM);
+ ret = ttm_bo_validate(bo, >placement, );
out_unreserve:
if (!ret)
@@ -190,17 +196,8 @@ int vmw_bo_pin_in_start_of_vram(struct vmw_private
*dev_priv,
{
struct ttm_operation_ctx ctx = {interruptible, false };
struct ttm_buffer_object *bo = >base;
- struct ttm_placement placement;
- struct ttm_place place;
int ret = 0;
- place = vmw_vram_placement.placement[0];
- place.lpfn = PFN_UP(bo->resource->size);
- placement.num_placement = 1;
- placement.placement =
- placement.num_busy_placement = 1;
- placement.busy_placement =
-
vmw_execbuf_release_pinned_bo(dev_priv);
ret = ttm_bo_reserve(bo, interruptible, false, NULL);
if (unlikely(ret != 0))
@@ -216,14 +213,21 @@ int vmw_bo_pin_in_start_of_vram(struct vmw_private
*dev_priv,
bo->resource->start > 0 &&
buf->base.pin_count == 0) {
ctx.interruptible = false;
- (void) ttm_bo_validate(bo, _sys_placement, );
+ vmw_bo_placement_set(buf,
+VMW_BO_DOMAIN_SYS,
+VMW_BO_DOMAIN_SYS);
+ (void)ttm_bo_validate(bo, >placement, );
}
+ vmw_bo_placement_set(buf,
+VMW_BO_DOMAIN_VRAM,
+VMW_BO_DOMAIN_VRAM);
+ buf->places[0].lpfn = PFN_UP(bo->resource->size);
if (buf->base.pin_count > 0)
- ret = ttm_resource_compat(bo->resource, )
+ ret = ttm_resource_compat(bo->resource, >placement)
? 0 : -EINVAL;
else
- ret = ttm_bo_validate(bo, , );
+ ret = ttm_bo_validate(bo, >placement, );
/* For some reason we didn't end up at the start of vram */
WARN_ON(ret == 0 && bo->resource->start != 0);
@@ -431,7 +435,7 @@ int vmw_bo_create_kernel(struct vmw_private *dev_priv,
unsigned long size,
}
int vmw_bo_create(struct vmw_private *vmw,
- size_t size,
Re: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini
On Tue, Jan 31, 2023 at 9:32 AM Guilherme G. Piccoli wrote: > > On 31/01/2023 10:58, Chen, Guchun wrote: > > Hi Christian, > > > > Do you think if it makes sense that we can set 'ring->sched.ready' to be > > true in each ring init, even if before executing/setting up drm_sched_init > > in amdgpu_device_init_schedulers? As 'ready' is a member of gpu scheduler > > structure. > > > > Regards, > > Guchun > > > > Hi folks, thanks a lot for the feedback so far, much appreciated! > > I'm feeling a bit confused specially since there seems to be 2 > orthogonal (yet related) topics being discussed; let me try to summarize > my understanding and we can then further discuss better: > > (a) The first problem is the one addressed in the patch - how to prevent > drm_sched_fini() to get called if drm_sched_init() wasn't called? > > I've proposed sched.name, seems Christian prefers sched.ops, correct? > > > (b) We can't use sched.ready, which would make sense...but amdgpu > overrides its meaning, the driver manipulates this value for its own > purposes of tracking ring init, or something like that. > > This is the tangential topic: what should we do here? My understanding > of Alex's message is that we could have a "ready" field in the ring > structure and stop messing with sched.ready - does it make sense Alex? Yes, I think so. The tricky part will be figuring out which current sched.ready checks are checking for the scheduler being ready vs. whether the ring itself is ready. > > Guchun / Christian, does it also make sense for you? > > > Regarding (a), I could re-submit having s/sched.name/sched.ops, no > biggies, I tested both to be fair, before sending...I just chose name > but any field that is proper initialized on drm_sched_init() would work. Yeah, I think ops is fine. You could even use sched.ready after we clean up the use of that in the driver. There are already a bunch of places where we check sched.ready to check if the scheduler really is ready. Alex > > Thanks, > > > Guilherme
Re: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini
On Tue, Jan 31, 2023 at 5:58 AM Christian König
wrote:
>
> Am 31.01.23 um 10:17 schrieb Chen, Guchun:
> > Hi Piccoli,
> >
> > Please ignore my request of full dmesg log. I can reproduce the issue and
> > get the same failure callstack by returning early with an error code prior
> > to amdgpu_device_init_schedulers.
> >
> > Regards,
> > Guchun
> >
> > -Original Message-
> > From: Chen, Guchun
> > Sent: Tuesday, January 31, 2023 2:37 PM
> > To: Alex Deucher ; Guilherme G. Piccoli
> >
> > Cc: amd-...@lists.freedesktop.org; ker...@gpiccoli.net; Pan, Xinhui
> > ; dri-devel@lists.freedesktop.org; Tuikov, Luben
> > ; Limonciello, Mario ;
> > kernel-...@igalia.com; Deucher, Alexander ;
> > Koenig, Christian
> > Subject: RE: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching
> > drm_sched init/fini
> >
> > Hi Piccoli,
> >
> > I agree with Alex's point, using ring->sched.name for such check is not a
> > good way. BTW, can you please attach a full dmesg long in bad case to help
> > me understand more?
> >
> > Regards,
> > Guchun
> >
> > -Original Message-
> > From: Alex Deucher
> > Sent: Tuesday, January 31, 2023 6:30 AM
> > To: Guilherme G. Piccoli
> > Cc: amd-...@lists.freedesktop.org; ker...@gpiccoli.net; Chen, Guchun
> > ; Pan, Xinhui ;
> > dri-devel@lists.freedesktop.org; Tuikov, Luben ;
> > Limonciello, Mario ; kernel-...@igalia.com;
> > Deucher, Alexander ; Koenig, Christian
> >
> > Subject: Re: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching
> > drm_sched init/fini
> >
> > On Mon, Jan 30, 2023 at 4:51 PM Guilherme G. Piccoli
> > wrote:
> >> + Luben
> >>
> >> (sorry, missed that in the first submission).
> >>
> >> On 30/01/2023 18:45, Guilherme G. Piccoli wrote:
> >>> Currently amdgpu calls drm_sched_fini() from the fence driver sw
> >>> fini routine - such function is expected to be called only after the
> >>> respective init function - drm_sched_init() - was executed successfully.
> >>>
> >>> Happens that we faced a driver probe failure in the Steam Deck
> >>> recently, and the function drm_sched_fini() was called even without
> >>> its counter-part had been previously called, causing the following oops:
> >>>
> >>> amdgpu: probe of :04:00.0 failed with error -110
> >>> BUG: kernel NULL pointer dereference, address: 0090 PGD
> >>> 0 P4D 0
> >>> Oops: 0002 [#1] PREEMPT SMP NOPTI
> >>> CPU: 0 PID: 609 Comm: systemd-udevd Not tainted 6.2.0-rc3-gpiccoli
> >>> #338 Hardware name: Valve Jupiter/Jupiter, BIOS F7A0113 11/04/2022
> >>> RIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched] [...] Call Trace:
> >>>
> >>> amdgpu_fence_driver_sw_fini+0xc8/0xd0 [amdgpu]
> >>> amdgpu_device_fini_sw+0x2b/0x3b0 [amdgpu]
> >>> amdgpu_driver_release_kms+0x16/0x30 [amdgpu]
> >>> devm_drm_dev_init_release+0x49/0x70
> >>> [...]
> >>>
> >>> To prevent that, check if the drm_sched was properly initialized for
> >>> a given ring before calling its fini counter-part.
> >>>
> >>> Notice ideally we'd use sched.ready for that; such field is set as
> >>> the latest thing on drm_sched_init(). But amdgpu seems to "override"
> >>> the meaning of such field - in the above oops for example, it was a
> >>> GFX ring causing the crash, and the sched.ready field was set to
> >>> true in the ring init routine, regardless of the state of the DRM
> >>> scheduler. Hence, we ended-up using another sched field.
> > Fixes: 067f44c8b459 ("drm/amdgpu: avoid over-handle of fence
> > driver fini in s3 test (v2)")
> >>> Cc: Andrey Grodzovsky
> >>> Cc: Guchun Chen
> >>> Cc: Mario Limonciello
> >>> Signed-off-by: Guilherme G. Piccoli
> >>> ---
> >>>
> >>>
> >>> Hi folks, first of all thanks in advance for reviews / comments!
> >>> Notice that I've used the Fixes tag more in the sense to bring it to
> >>> stable, I didn't find a good patch candidate that added the call to
> >>> drm_sched_fini(), was reaching way too old commits...so
> >>> 067f44c8b459 seems a good candidate - or maybe not?
> >>>
> >>> Now, with regards sched.ready, spent a bit of time to figure what
> >>> was happening...would be feasible maybe to stop using that to mark
> >>> some kind ring status? I think it should be possible to add a flag
> >>> to the ring structure for that, and free sched.ready from being
> >>> manipulate by the amdgpu driver, what's your thoughts on that?
> > It's been a while, but IIRC, we used to have a ring->ready field in the
> > driver which at some point got migrated out of the driver into the GPU
> > scheduler and the driver side code never got cleaned up. I think we should
> > probably just drop the driver messing with that field and leave it up to
> > the drm scheduler.
>
> To use ring->ready is not a good idea since this doesn't specify if the
> scheduler was initialized, but rather if bringup of the engine worked.
ring->ready no longer exists. It was moved into the scheduler and the
driver side never got cleaned up. Also, we set ring->sched.ready =
true once the rings
Re: [PATCH] drm/amd/display: Trivial swizzle-related code clean-ups
Applied. Thanks!
Alex
On Tue, Jan 31, 2023 at 9:40 AM Harry Wentland wrote:
>
> On 1/30/23 14:56, Guilherme G. Piccoli wrote:
> > This is a very trivial code clean-up related to commit 5468c36d6285
> > ("drm/amd/display: Filter Invalid 420 Modes for HDMI TMDS"). This commit
> > added a validation on driver probe to prevent invalid TMDS modes, but one
> > of the fake properties (swizzle) ended-up causing a warning on driver
> > probe; was reported here:
> > https://gitlab.freedesktop.org/drm/amd/-/issues/2264.
> >
> > It was fixed by commit 105a8b8698e2 ("drm/amd/display: patch cases with
> > unknown plane state to prevent warning"), but the validation code had
> > a double variable assignment, which we hereby remove. Also, the fix relies
> > in the dcn2{0,1}patch_unknown_plane_state() callbacks, so while at it we
> > took the opportunity to perform a small code clean-up in such routines.
> >
> > Cc: Aurabindo Pillai
> > Cc: Daniel Wheeler
> > Cc: Fangzhi Zuo
> > Cc: Harry Wentland
> > Cc: Leo Li
> > Cc: Mark Broadworth
> > Cc: Melissa Wen
> > Cc: Rodrigo Siqueira
> > Cc: Sung Joon Kim
> > Cc: Swapnil Patel
> > Signed-off-by: Guilherme G. Piccoli
>
> Reviewed-by: Harry Wentland
>
> Harry
>
> > ---
> > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
> > drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 8 ++--
> > drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 6 ++
> > 3 files changed, 4 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index 86a2f7f58550..e71e94663d14 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -6336,7 +6336,6 @@ static enum dc_status
> > dm_validate_stream_and_context(struct dc *dc,
> > dc_plane_state->plane_size.surface_size.width = stream->src.width;
> > dc_plane_state->plane_size.chroma_size.height = stream->src.height;
> > dc_plane_state->plane_size.chroma_size.width = stream->src.width;
> > - dc_plane_state->tiling_info.gfx9.swizzle = DC_SW_UNKNOWN;
> > dc_plane_state->format = SURFACE_PIXEL_FORMAT_GRPH_ARGB;
> > dc_plane_state->tiling_info.gfx9.swizzle = DC_SW_UNKNOWN;
> > dc_plane_state->rotation = ROTATION_ANGLE_0;
> > diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> > b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> > index 531f405d2554..3af24ef9cb2d 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> > +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> > @@ -2225,14 +2225,10 @@ enum dc_status
> > dcn20_patch_unknown_plane_state(struct dc_plane_state *plane_stat
> > enum surface_pixel_format surf_pix_format = plane_state->format;
> > unsigned int bpp = resource_pixel_format_to_bpp(surf_pix_format);
> >
> > - enum swizzle_mode_values swizzle = DC_SW_LINEAR;
> > -
> > + plane_state->tiling_info.gfx9.swizzle = DC_SW_64KB_S;
> > if (bpp == 64)
> > - swizzle = DC_SW_64KB_D;
> > - else
> > - swizzle = DC_SW_64KB_S;
> > + plane_state->tiling_info.gfx9.swizzle = DC_SW_64KB_D;
> >
> > - plane_state->tiling_info.gfx9.swizzle = swizzle;
> > return DC_OK;
> > }
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
> > b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
> > index fbcf0afeae0d..8f9244fe5c86 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
> > +++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
> > @@ -1393,15 +1393,13 @@ static uint32_t read_pipe_fuses(struct dc_context
> > *ctx)
> >
> > static enum dc_status dcn21_patch_unknown_plane_state(struct
> > dc_plane_state *plane_state)
> > {
> > - enum dc_status result = DC_OK;
> > -
> > if (plane_state->ctx->dc->debug.disable_dcc == DCC_ENABLE) {
> > plane_state->dcc.enable = 1;
> > /* align to our worst case block width */
> > plane_state->dcc.meta_pitch = ((plane_state->src_rect.width +
> > 1023) / 1024) * 1024;
> > }
> > - result = dcn20_patch_unknown_plane_state(plane_state);
> > - return result;
> > +
> > + return dcn20_patch_unknown_plane_state(plane_state);
> > }
> >
> > static const struct resource_funcs dcn21_res_pool_funcs = {
>
Re: [Intel-gfx] [PATCH v6 07/10] drm/i915/hdcp: Use HDCP helpers for i915
+Suraj
On Tue, Jan 31, 2023 at 12:16:44PM -0500, Rodrigo Vivi wrote:
>
> +Suraj who is also working on HDCP related code that even can conflict
> wit this.
>
> On Wed, Jan 18, 2023 at 07:30:12PM +, Mark Yacoub wrote:
> > From: Sean Paul
>
> First of all, Sean, please accept my public apologies here. I just noticed
> now that you had pinged me 9 *months* ago!
> I noticed while taking a look to the history to refresh my mind around
> this series.
>
> >
> > Now that all of the HDCP 1.x logic has been migrated to the central HDCP
> > helpers, use it in the i915 driver.
> >
> > The majority of the driver code for HDCP 1.x will live in intel_hdcp.c,
> > however there are a few helper hooks which are connector-specific and
> > need to be partially or fully implemented in the intel_dp_hdcp.c or
> > intel_hdmi.c.
>
> so far so good! we need to do this soon.
>
> >
> > We'll leave most of the HDCP 2.x code alone since we don't have another
> > implementation of HDCP 2.x to use as reference for what should and
> > should not live in the drm helpers. The helper will call the overly
> > general enable/disable/is_capable HDCP 2.x callbacks and leave the
> > interesting stuff for the driver. Once we have another HDCP 2.x
> > implementation, we should do a similar migration.
>
> I believe this part is the part that I start to get lost when
> trying to review it.
>
> Mark told me in irc that it is really hard to split this patch,
> but do we really need to have the hdcp 1.x changes along with the
> 2.x? I start to get lost in the review when I see the changes around
> the hdcp2_capable...
>
> So, it would be really really good if we can split this patch.
>
> >
> > Acked-by: Jani Nikula
> > Signed-off-by: Sean Paul
> > Signed-off-by: Mark Yacoub
>
> Cc: Suraj Kandpal
>
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-8-s...@poorly.run
> > #v1
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20210915203834.1439-8-s...@poorly.run
> > #v2
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20211001151145.55916-8-s...@poorly.run
> > #v3
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20211105030434.2828845-8-s...@poorly.run
> > #v4
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20220411204741.1074308-8-s...@poorly.run
> > #v5
> >
> > Changes in v2:
> > -Fix mst helper function pointer reported by 0-day
> > Changes in v3:
> > -Add forward declaration for drm_atomic_state in intel_hdcp.h identified
> > by 0-day
> > Changes in v4:
> > -None
> > Changes in v5:
> > -None
> > Changes in v6:
> > -Rebased.
> >
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 32 +-
> > .../drm/i915/display/intel_display_debugfs.c | 6 +-
> > .../drm/i915/display/intel_display_types.h| 60 +-
> > drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 348 +++
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 16 +-
> > drivers/gpu/drm/i915/display/intel_hdcp.c | 952 +++---
> > drivers/gpu/drm/i915/display/intel_hdcp.h | 31 +-
> > drivers/gpu/drm/i915/display/intel_hdmi.c | 270 ++---
> > 8 files changed, 445 insertions(+), 1270 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 69ecf2a3d6c6..a4397f066a3e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -28,6 +28,7 @@
> > #include
> >
> > #include
> > +#include
> > #include
> >
> > #include "i915_drv.h"
> > @@ -2909,6 +2910,10 @@ static void intel_enable_ddi(struct
> > intel_atomic_state *state,
> > const struct intel_crtc_state *crtc_state,
> > const struct drm_connector_state *conn_state)
> > {
> > + struct intel_connector *connector =
> > + to_intel_connector(conn_state->connector);
> > + struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> > +
> > drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
> >
> > if (!intel_crtc_is_bigjoiner_slave(crtc_state))
> > @@ -2925,12 +2930,10 @@ static void intel_enable_ddi(struct
> > intel_atomic_state *state,
> > else
> > intel_enable_ddi_dp(state, encoder, crtc_state, conn_state);
> >
> > - /* Enable hdcp if it's desired */
> > - if (conn_state->content_protection ==
> > - DRM_MODE_CONTENT_PROTECTION_DESIRED)
> > - intel_hdcp_enable(to_intel_connector(conn_state->connector),
> > - crtc_state,
> > - (u8)conn_state->hdcp_content_type);
> > + if (connector->hdcp_helper_data)
> > + drm_hdcp_helper_atomic_commit(connector->hdcp_helper_data,
> > + >base,
> > + _port->hdcp_mutex);
> > }
> >
> > static void intel_disable_ddi_dp(struct intel_atomic_state *state,
> > @@
Re: [PATCH] drm/amd/display: reduce else-if to else in dcn32_calculate_dlg_params()
Applied. Thanks!
Alex
On Thu, Jan 26, 2023 at 3:50 PM Tom Rix wrote:
>
> cppcheck reports
> drivers/gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c:1403:76: style:
> Expression is always true because 'else if' condition is opposite to
> previous condition at line 1396. [multiCondition]
>} else if (context->res_ctx.pipe_ctx[i].stream->mall_stream_config.type ==
> SUBVP_PHANTOM) {
>^
> drivers/gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c:1396:69: note: first
> condition
>if (context->res_ctx.pipe_ctx[i].stream->mall_stream_config.type !=
> SUBVP_PHANTOM) {
> ^
> drivers/gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c:1403:76: note: else if
> condition is opposite to first condition
>} else if (context->res_ctx.pipe_ctx[i].stream->mall_stream_config.type ==
> SUBVP_PHANTOM) {
>
> It is not necessary to explicitly the check != condition, an else is simplier.
>
> Fixes: 238debcaebe4 ("drm/amd/display: Use DML for MALL SS and Subvp
> allocation calculations")
> Signed-off-by: Tom Rix
> ---
> drivers/gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c
> b/drivers/gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c
> index 0dc1a03999b6..c96cbd88e20d 100644
> --- a/drivers/gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c
> +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c
> @@ -1400,7 +1400,7 @@ static void dcn32_calculate_dlg_params(struct dc *dc,
> struct dc_state *context,
> /* SS PSR On: all active surfaces
> part of streams not supporting PSR stored in MALL */
>
> context->bw_ctx.bw.dcn.mall_ss_psr_active_size_bytes +=
> context->res_ctx.pipe_ctx[i].surface_size_in_mall_bytes;
> }
> - } else if
> (context->res_ctx.pipe_ctx[i].stream->mall_stream_config.type ==
> SUBVP_PHANTOM) {
> + } else {
> /* SUBVP: phantom surfaces only stored in
> MALL */
> context->bw_ctx.bw.dcn.mall_subvp_size_bytes
> += context->res_ctx.pipe_ctx[i].surface_size_in_mall_bytes;
> }
> --
> 2.26.3
>
[linux-next:master] BUILD REGRESSION 80bd9028fecadae4e8e3a278cd32d74badc2a6e0
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 80bd9028fecadae4e8e3a278cd32d74badc2a6e0 Add linux-next specific files for 20230131 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202301230743.xnut0zvc-...@intel.com https://lore.kernel.org/oe-kbuild-all/202301300743.bp7dpazv-...@intel.com https://lore.kernel.org/oe-kbuild-all/202301301801.y5o08tqx-...@intel.com https://lore.kernel.org/oe-kbuild-all/202301302110.metnwkbd-...@intel.com https://lore.kernel.org/oe-kbuild-all/202301310227.semvyeta-...@intel.com https://lore.kernel.org/oe-kbuild-all/202301310939.tagcoezb-...@intel.com Error/Warning: (recently discovered and may have been fixed) Documentation/riscv/uabi.rst:24: WARNING: Enumerated list ends without a blank line; unexpected unindent. ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/fsl-edma.ko] undefined! ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/idma64.ko] undefined! arch/arm64/kvm/arm.c:2206: warning: expecting prototype for Initialize Hyp(). Prototype was for kvm_arm_init() instead drivers/clk/qcom/gcc-sa8775p.c:313:32: warning: unused variable 'gcc_parent_map_10' [-Wunused-const-variable] drivers/clk/qcom/gcc-sa8775p.c:318:37: warning: unused variable 'gcc_parent_data_10' [-Wunused-const-variable] drivers/clk/qcom/gcc-sa8775p.c:333:32: warning: unused variable 'gcc_parent_map_12' [-Wunused-const-variable] drivers/clk/qcom/gcc-sa8775p.c:338:37: warning: unused variable 'gcc_parent_data_12' [-Wunused-const-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/link/accessories/link_dp_trace.c:148:6: warning: no previous prototype for 'link_dp_trace_set_edp_power_timestamp' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/link/accessories/link_dp_trace.c:158:10: warning: no previous prototype for 'link_dp_trace_get_edp_poweron_timestamp' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/link/accessories/link_dp_trace.c:163:10: warning: no previous prototype for 'link_dp_trace_get_edp_poweroff_timestamp' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:1295:32: warning: variable 'result_write_min_hblank' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:279:42: warning: variable 'ds_port' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training.c:1585:38: warning: variable 'result' set but not used [-Wunused-but-set-variable] drivers/gpu/host1x/dev.c:520:6: warning: variable 'syncpt_irq' is uninitialized when used here [-Wuninitialized] ftrace-ops.c:(.init.text+0x2cb): undefined reference to `__udivdi3' Unverified Error/Warning (likely false positive, please contact us if interested): drivers/nvmem/imx-ocotp.c:599:21: sparse: sparse: symbol 'imx_ocotp_layout' was not declared. Should it be static? drivers/thermal/qcom/tsens-v0_1.c:106:40: sparse: sparse: symbol 'tsens_9607_nvmem' was not declared. Should it be static? drivers/thermal/qcom/tsens-v0_1.c:26:40: sparse: sparse: symbol 'tsens_8916_nvmem' was not declared. Should it be static? drivers/thermal/qcom/tsens-v0_1.c:42:40: sparse: sparse: symbol 'tsens_8939_nvmem' was not declared. Should it be static? drivers/thermal/qcom/tsens-v0_1.c:62:40: sparse: sparse: symbol 'tsens_8974_nvmem' was not declared. Should it be static? drivers/thermal/qcom/tsens-v0_1.c:84:40: sparse: sparse: symbol 'tsens_8974_backup_nvmem' was not declared. Should it be static? drivers/thermal/qcom/tsens-v1.c:24:40: sparse: sparse: symbol 'tsens_qcs404_nvmem' was not declared. Should it be static? drivers/thermal/qcom/tsens-v1.c:45:40: sparse: sparse: symbol 'tsens_8976_nvmem' was not declared. Should it be static? Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-accessories-link_dp_trace.c:warning:no-previous-prototype-for-link_dp_trace_get_edp_poweroff_timestamp | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-accessories-link_dp_trace.c:warning:no-previous-prototype-for-link_dp_trace_get_edp_poweron_timestamp | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-accessories-link_dp_trace.c:warning:no-previous-prototype-for-link_dp_trace_set_edp_power_timestamp | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:variable-ds_port-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:variable-result_write_min_hblank-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_training.c:warning:variable-result-set-but-not-used |-- alpha-randconfig-s052-20230129 | |-- drivers-nvmem-imx-ocotp.c:sparse:sparse:symbol-imx_ocotp_layout-was-not-declared.-Should-it-be-static | |-- drivers-the
Re: [PATCH] drm/amd/display: reduce else-if to else in dcn10_blank_pixel_data()
Applied. Thanks!
On Thu, Jan 26, 2023 at 8:38 PM Tom Rix wrote:
>
> checkpatch reports
> drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c:2902:13: style:
> Expression is always true because 'else if' condition is opposite to
> previous condition at line 2895. [multiCondition]
> } else if (blank) {
> ^
> drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c:2895:6: note: first
> condition
> if (!blank) {
> ^
> drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c:2902:13: note: else
> if condition is opposite to first condition
> } else if (blank) {
>
> It is not necessary to explicitly the check != condition, an else is simplier.
>
> Fixes: aa5a57773042 ("drm/amd/display: Vari-bright looks disabled near end of
> MM14")
> Signed-off-by: Tom Rix
> ---
> drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> index bb155734ac93..f735ae5e045f 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> @@ -2899,7 +2899,7 @@ void dcn10_blank_pixel_data(
> dc->hwss.set_pipe(pipe_ctx);
>
> stream_res->abm->funcs->set_abm_level(stream_res->abm, stream->abm_level);
> }
> - } else if (blank) {
> + } else {
> dc->hwss.set_abm_immediate_disable(pipe_ctx);
> if (stream_res->tg->funcs->set_blank) {
> stream_res->tg->funcs->wait_for_state(stream_res->tg,
> CRTC_STATE_VBLANK);
> --
> 2.26.3
>
Re: [PATCH] drm/amdgpu/display: remove duplicate include header in files
Applied. Thanks! Alex On Fri, Jan 27, 2023 at 8:39 PM wrote: > > From: ye xingchen > > opp.h is included more than once. > > Signed-off-by: ye xingchen > --- > drivers/gpu/drm/amd/display/dc/core/dc_link.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c > b/drivers/gpu/drm/amd/display/dc/core/dc_link.c > index 6475664baa8a..1a2ab934b4bd 100644 > --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c > @@ -46,7 +46,6 @@ > #include "dpcd_defs.h" > #include "dmcu.h" > #include "dsc.h" > -#include "opp.h" > #include "hw/clk_mgr.h" > #include "dce/dmub_psr.h" > #include "dmub/dmub_srv.h" > -- > 2.25.1
Re: [Intel-gfx] [PATCH v6 07/10] drm/i915/hdcp: Use HDCP helpers for i915
+Suraj who is also working on HDCP related code that even can conflict
wit this.
On Wed, Jan 18, 2023 at 07:30:12PM +, Mark Yacoub wrote:
> From: Sean Paul
First of all, Sean, please accept my public apologies here. I just noticed
now that you had pinged me 9 *months* ago!
I noticed while taking a look to the history to refresh my mind around
this series.
>
> Now that all of the HDCP 1.x logic has been migrated to the central HDCP
> helpers, use it in the i915 driver.
>
> The majority of the driver code for HDCP 1.x will live in intel_hdcp.c,
> however there are a few helper hooks which are connector-specific and
> need to be partially or fully implemented in the intel_dp_hdcp.c or
> intel_hdmi.c.
so far so good! we need to do this soon.
>
> We'll leave most of the HDCP 2.x code alone since we don't have another
> implementation of HDCP 2.x to use as reference for what should and
> should not live in the drm helpers. The helper will call the overly
> general enable/disable/is_capable HDCP 2.x callbacks and leave the
> interesting stuff for the driver. Once we have another HDCP 2.x
> implementation, we should do a similar migration.
I believe this part is the part that I start to get lost when
trying to review it.
Mark told me in irc that it is really hard to split this patch,
but do we really need to have the hdcp 1.x changes along with the
2.x? I start to get lost in the review when I see the changes around
the hdcp2_capable...
So, it would be really really good if we can split this patch.
>
> Acked-by: Jani Nikula
> Signed-off-by: Sean Paul
> Signed-off-by: Mark Yacoub
Cc: Suraj Kandpal
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-8-s...@poorly.run
> #v1
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20210915203834.1439-8-s...@poorly.run
> #v2
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20211001151145.55916-8-s...@poorly.run
> #v3
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20211105030434.2828845-8-s...@poorly.run
> #v4
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20220411204741.1074308-8-s...@poorly.run
> #v5
>
> Changes in v2:
> -Fix mst helper function pointer reported by 0-day
> Changes in v3:
> -Add forward declaration for drm_atomic_state in intel_hdcp.h identified
> by 0-day
> Changes in v4:
> -None
> Changes in v5:
> -None
> Changes in v6:
> -Rebased.
>
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 32 +-
> .../drm/i915/display/intel_display_debugfs.c | 6 +-
> .../drm/i915/display/intel_display_types.h| 60 +-
> drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 348 +++
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 16 +-
> drivers/gpu/drm/i915/display/intel_hdcp.c | 952 +++---
> drivers/gpu/drm/i915/display/intel_hdcp.h | 31 +-
> drivers/gpu/drm/i915/display/intel_hdmi.c | 270 ++---
> 8 files changed, 445 insertions(+), 1270 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 69ecf2a3d6c6..a4397f066a3e 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -28,6 +28,7 @@
> #include
>
> #include
> +#include
> #include
>
> #include "i915_drv.h"
> @@ -2909,6 +2910,10 @@ static void intel_enable_ddi(struct intel_atomic_state
> *state,
>const struct intel_crtc_state *crtc_state,
>const struct drm_connector_state *conn_state)
> {
> + struct intel_connector *connector =
> + to_intel_connector(conn_state->connector);
> + struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> +
> drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
>
> if (!intel_crtc_is_bigjoiner_slave(crtc_state))
> @@ -2925,12 +2930,10 @@ static void intel_enable_ddi(struct
> intel_atomic_state *state,
> else
> intel_enable_ddi_dp(state, encoder, crtc_state, conn_state);
>
> - /* Enable hdcp if it's desired */
> - if (conn_state->content_protection ==
> - DRM_MODE_CONTENT_PROTECTION_DESIRED)
> - intel_hdcp_enable(to_intel_connector(conn_state->connector),
> - crtc_state,
> - (u8)conn_state->hdcp_content_type);
> + if (connector->hdcp_helper_data)
> + drm_hdcp_helper_atomic_commit(connector->hdcp_helper_data,
> + >base,
> + _port->hdcp_mutex);
> }
>
> static void intel_disable_ddi_dp(struct intel_atomic_state *state,
> @@ -2976,7 +2979,14 @@ static void intel_disable_ddi(struct
> intel_atomic_state *state,
> const struct intel_crtc_state *old_crtc_state,
> const struct drm_connector_state *old_conn_state)
> {
> -
Re: [PATCH] drm/amdgpu: Fix a typo ("boradcast")
Applied. Thanks! On Sun, Jan 29, 2023 at 10:18 AM Jonathan Neuschäfer wrote: > > Spell it as "broadcast". > > Signed-off-by: Jonathan Neuschäfer > --- > drivers/gpu/drm/amd/amdgpu/df_v1_7.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/df_v1_7.c > b/drivers/gpu/drm/amd/amdgpu/df_v1_7.c > index b991609f46c10..5dfab8021 100644 > --- a/drivers/gpu/drm/amd/amdgpu/df_v1_7.c > +++ b/drivers/gpu/drm/amd/amdgpu/df_v1_7.c > @@ -94,7 +94,7 @@ static void df_v1_7_update_medium_grain_clock_gating(struct > amdgpu_device *adev, > WREG32_SOC15(DF, 0, mmDF_PIE_AON0_DfGlobalClkGater, tmp); > } > > - /* Exit boradcast mode */ > + /* Exit broadcast mode */ > adev->df.funcs->enable_broadcast_mode(adev, false); > } > > -- > 2.39.0 >
Re: [PATCH v2 2/6] drm/debugfs: Make drm_device use the struct drm_debugfs_files
Hi Maíra,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm-intel/for-linux-next drm-tip/drm-tip
next-20230131]
[cannot apply to drm-intel/for-linux-next-fixes linus/master v6.2-rc6]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Ma-ra-Canal/drm-debugfs-Introduce-wrapper-for-debugfs-list/20230130-203549
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20230130123008.287141-3-mcanal%40igalia.com
patch subject: [PATCH v2 2/6] drm/debugfs: Make drm_device use the struct
drm_debugfs_files
config: arc-randconfig-r043-20230129
(https://download.01.org/0day-ci/archive/20230201/202302010102.zlw3vtyi-...@intel.com/config)
compiler: arceb-elf-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/776660a442d9112d8fbc06b0b8b0b77852b18fca
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Ma-ra-Canal/drm-debugfs-Introduce-wrapper-for-debugfs-list/20230130-203549
git checkout 776660a442d9112d8fbc06b0b8b0b77852b18fca
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=arc olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=arc SHELL=/bin/bash drivers/gpu/drm/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
All error/warnings (new ones prefixed by >>):
drivers/gpu/drm/drm_drv.c: In function 'drm_dev_init_release':
>> drivers/gpu/drm/drm_drv.c:602:9: error: implicit declaration of function
>> 'drm_debugfs_files_destroy'; did you mean 'drm_debugfs_list_destroy'?
>> [-Werror=implicit-function-declaration]
602 | drm_debugfs_files_destroy(dev->debugfs_files);
| ^
| drm_debugfs_list_destroy
drivers/gpu/drm/drm_drv.c: In function 'drm_dev_init':
>> drivers/gpu/drm/drm_drv.c:650:30: error: implicit declaration of function
>> 'drm_debugfs_files_init'; did you mean 'drm_debugfs_list_init'?
>> [-Werror=implicit-function-declaration]
650 | dev->debugfs_files = drm_debugfs_files_init();
| ^~
| drm_debugfs_list_init
>> drivers/gpu/drm/drm_drv.c:650:28: warning: assignment to 'struct
>> drm_debugfs_files *' from 'int' makes pointer from integer without a cast
>> [-Wint-conversion]
650 | dev->debugfs_files = drm_debugfs_files_init();
|^
cc1: some warnings being treated as errors
vim +602 drivers/gpu/drm/drm_drv.c
562
563 /**
564 * DOC: component helper usage recommendations
565 *
566 * DRM drivers that drive hardware where a logical device consists of a
pile of
567 * independent hardware blocks are recommended to use the
:ref:`component helper
568 * library`. For consistency and better options for code
reuse the
569 * following guidelines apply:
570 *
571 * - The entire device initialization procedure should be run from the
572 *_master_ops.master_bind callback, starting with
573 *devm_drm_dev_alloc(), then binding all components with
574 *component_bind_all() and finishing with drm_dev_register().
575 *
576 * - The opaque pointer passed to all components through
component_bind_all()
577 *should point at drm_device of the device instance, not
some driver
578 *specific private structure.
579 *
580 * - The component helper fills the niche where further
standardization of
581 *interfaces is not practical. When there already is, or will be, a
582 *standardized interface like _bridge or _panel, providing
its own
583 *functions to find such components at driver load time, like
584 *drm_of_find_panel_or_bridge(), then the component helper should
not be
585 *used.
586 */
587
588 static void drm_dev_init_release(struct drm_device *dev, void *res)
589 {
590 drm_legacy_ctxbitmap_cleanup(dev);
591 drm_legacy_remove_map_hash(dev);
592 drm_fs_inode_free(dev->anon_inode);
593
594 put_device(dev->dev);
595 /* Prevent use-after-
RE: [PATCH AUTOSEL 6.1 20/20] amdgpu: fix build on non-DCN platforms.
[AMD Official Use Only - General] > -Original Message- > From: Sasha Levin > Sent: Tuesday, January 31, 2023 10:00 AM > To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org > Cc: Dave Airlie ; Sasha Levin ; > Wentland, Harry ; Li, Sun peng (Leo) > ; Siqueira, Rodrigo ; > Deucher, Alexander ; Koenig, Christian > ; Pan, Xinhui ; > airl...@gmail.com; dan...@ffwll.ch; Li, Roman ; > Wang, Chao-kai (Stylon) ; Pillai, Aurabindo > ; Zuo, Jerry ; amd- > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Subject: [PATCH AUTOSEL 6.1 20/20] amdgpu: fix build on non-DCN > platforms. > > From: Dave Airlie > > [ Upstream commit f439a959dcfb6b39d6fd4b85ca1110a1d1de1587 ] > > This fixes the build here locally on my 32-bit arm build. > > Signed-off-by: Dave Airlie > Signed-off-by: Sasha Levin This patch is only applicable to kernel 6.1.x and newer. Alex > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index 15b408e3a705..d756a606b5e2 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -9411,6 +9411,8 @@ static int amdgpu_dm_atomic_check(struct > drm_device *dev, > bool lock_and_validation_needed = false; > struct dm_crtc_state *dm_old_crtc_state, *dm_new_crtc_state; #if > defined(CONFIG_DRM_AMD_DC_DCN) > + struct drm_dp_mst_topology_mgr *mgr; > + struct drm_dp_mst_topology_state *mst_state; > struct dsc_mst_fairness_vars vars[MAX_PIPES]; #endif > > -- > 2.39.0
Re: [PATCH v2 1/8] drm/vmwgfx: Use the common gem mmap instead of the custom code
From: Martin Krastev
LGTM
Reviewed-by: Martin Krastev
Regards,
Martin
On 31.01.23 г. 5:35 ч., Zack Rusin wrote:
From: Zack Rusin
Before vmwgfx supported gem it needed to implement the entire mmap logic
explicitly. With GEM support that's not needed and the generic code
can be used by simply setting the vm_ops to vmwgfx specific ones on the
gem object itself.
Removes a lot of code from vmwgfx without any functional difference.
Signed-off-by: Zack Rusin
Reviewed-by: Thomas Zimmermann
Reviewed-by: Martin Krastev
---
drivers/gpu/drm/vmwgfx/Makefile | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 6 --
drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 8 ++
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 110 ---
5 files changed, 10 insertions(+), 118 deletions(-)
delete mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
index 2a644f035597..e94479d9cd5b 100644
--- a/drivers/gpu/drm/vmwgfx/Makefile
+++ b/drivers/gpu/drm/vmwgfx/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o vmwgfx_drv.o \
vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_ttm_buffer.o \
- vmwgfx_cmd.o vmwgfx_irq.o vmwgfx_ldu.o vmwgfx_ttm_glue.o \
+ vmwgfx_cmd.o vmwgfx_irq.o vmwgfx_ldu.o \
vmwgfx_overlay.o vmwgfx_gmrid_manager.o vmwgfx_fence.o \
vmwgfx_bo.o vmwgfx_scrn.o vmwgfx_context.o \
vmwgfx_surface.o vmwgfx_prime.o vmwgfx_mob.o vmwgfx_shader.o \
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index bd02cb0e6837..e0c2e3748015 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -1566,7 +1566,7 @@ static const struct file_operations vmwgfx_driver_fops = {
.open = drm_open,
.release = drm_release,
.unlocked_ioctl = vmw_unlocked_ioctl,
- .mmap = vmw_mmap,
+ .mmap = drm_gem_mmap,
.poll = drm_poll,
.read = drm_read,
#if defined(CONFIG_COMPAT)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 5acbf5849b27..4dfa5044a9e7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -1053,12 +1053,6 @@ vmw_is_cursor_bypass3_enabled(const struct vmw_private
*dev_priv)
return (vmw_fifo_caps(dev_priv) & SVGA_FIFO_CAP_CURSOR_BYPASS_3) != 0;
}
-/**
- * TTM glue - vmwgfx_ttm_glue.c
- */
-
-extern int vmw_mmap(struct file *filp, struct vm_area_struct *vma);
-
/**
* TTM buffer object driver - vmwgfx_ttm_buffer.c
*/
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
index ce609e7d758f..ba4ddd9f7a7e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
@@ -103,6 +103,13 @@ static struct sg_table *vmw_gem_object_get_sg_table(struct
drm_gem_object *obj)
return drm_prime_pages_to_sg(obj->dev, vmw_tt->dma_ttm.pages,
vmw_tt->dma_ttm.num_pages);
}
+static const struct vm_operations_struct vmw_vm_ops = {
+ .pfn_mkwrite = vmw_bo_vm_mkwrite,
+ .page_mkwrite = vmw_bo_vm_mkwrite,
+ .fault = vmw_bo_vm_fault,
+ .open = ttm_bo_vm_open,
+ .close = ttm_bo_vm_close,
+};
static const struct drm_gem_object_funcs vmw_gem_object_funcs = {
.free = vmw_gem_object_free,
@@ -115,6 +122,7 @@ static const struct drm_gem_object_funcs
vmw_gem_object_funcs = {
.vmap = drm_gem_ttm_vmap,
.vunmap = drm_gem_ttm_vunmap,
.mmap = drm_gem_ttm_mmap,
+ .vm_ops = _vm_ops,
};
/**
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
deleted file mode 100644
index 265f7c48d856..
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
+++ /dev/null
@@ -1,110 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0 OR MIT
-/**
- *
- * Copyright 2009-2011 VMware, Inc., Palo Alto, CA., USA
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the
- * "Software"), to deal in the Software without restriction, including
- * without limitation the rights to use, copy, modify, merge, publish,
- * distribute, sub license, and/or sell copies of the Software, and to
- * permit persons to whom the Software is furnished to do so, subject to
- * the following conditions:
- *
- * The above copyright notice and this permission notice (including the
- * next paragraph) shall be included in all copies or substantial portions
- * of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A
[PATCH v2 14/17] drm/display/dp_mst: Factor out a helper to reset the payload table
A follow-up patch adds a workaround for a payload allocation problem in
a DELL monitor. For this the driver needs to reset the payload table in
the monitor's MST hub, factor out a helper to do this.
While at it use DP_PAYLOAD_TABLE_SIZE in the reset command, instead of
open coding it.
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 8 +++-
include/drm/display/drm_dp_mst_helper.h | 1 +
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index d0e929df7d088..eb170389cf9bc 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3429,6 +3429,12 @@ int drm_dp_add_payload_part2(struct
drm_dp_mst_topology_mgr *mgr,
}
EXPORT_SYMBOL(drm_dp_add_payload_part2);
+int drm_dp_mst_reset_payload_table(struct drm_dp_mst_topology_mgr *mgr)
+{
+ return drm_dp_dpcd_write_payload(mgr, 0, 0, DP_PAYLOAD_TABLE_SIZE - 1);
+}
+EXPORT_SYMBOL(drm_dp_mst_reset_payload_table);
+
/**
* drm_dp_mst_has_payload_alloc_errors - Query for payload allocation errors
* @mst_state: The MST atomic state
@@ -3699,7 +3705,7 @@ int drm_dp_mst_topology_mgr_set_mst(struct
drm_dp_mst_topology_mgr *mgr, bool ms
goto out_unlock;
/* Write reset payload */
- drm_dp_dpcd_write_payload(mgr, 0, 0, 0x3f);
+ drm_dp_mst_reset_payload_table(mgr);
queue_work(system_long_wq, >work);
diff --git a/include/drm/display/drm_dp_mst_helper.h
b/include/drm/display/drm_dp_mst_helper.h
index bb7c595096fed..2d15399df2950 100644
--- a/include/drm/display/drm_dp_mst_helper.h
+++ b/include/drm/display/drm_dp_mst_helper.h
@@ -845,6 +845,7 @@ void drm_dp_remove_payload(struct drm_dp_mst_topology_mgr
*mgr,
struct drm_dp_mst_topology_state *mst_state,
const struct drm_dp_mst_atomic_payload *old_payload,
struct drm_dp_mst_atomic_payload *new_payload);
+int drm_dp_mst_reset_payload_table(struct drm_dp_mst_topology_mgr *mgr);
bool drm_dp_mst_has_payload_alloc_errors(const struct
drm_dp_mst_topology_state *mst_state);
int drm_dp_mst_payload_vchannel(const struct drm_dp_mst_topology_state
*mst_state,
const struct drm_dp_mst_atomic_payload
*payload);
--
2.37.1
[PATCH v2 11/17] drm/display/dp_mst: Add helpers to query for payload allocation errors
Add a way for drivers to query if allocating time slots for any payloads
in a given MST topology failed. This is needed by a follow-up i915 patch
verifying the SW vs. HW state of the MST topology.
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 35 ---
include/drm/display/drm_dp_mst_helper.h | 3 ++
2 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index e57dd16955d52..f2081f3fad0da 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3306,15 +3306,14 @@ int drm_dp_add_payload_part1(struct
drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_atomic_payload *payload)
{
struct drm_dp_mst_port *port;
- int ret;
+ int ret = 0;
port = drm_dp_mst_topology_get_port_validated(mgr, payload->port);
if (!port) {
drm_dbg_kms(mgr->dev,
"VCPI %d for port %p not in topology, not creating
a payload\n",
payload->vcpi, payload->port);
- payload->vc_start_slot = -1;
- return 0;
+ goto alloc_fail;
}
if (mgr->payload_count == 0)
@@ -3327,14 +3326,21 @@ int drm_dp_add_payload_part1(struct
drm_dp_mst_topology_mgr *mgr,
if (ret < 0) {
drm_warn(mgr->dev, "Failed to create MST payload for port %p:
%d\n",
payload->port, ret);
- payload->vc_start_slot = -1;
- return ret;
+ goto alloc_fail;
}
+ payload->alloc_failed = false;
+
mgr->payload_count++;
mgr->next_start_slot += payload->time_slots;
return 0;
+
+alloc_fail:
+ payload->vc_start_slot = -1;
+ payload->alloc_failed = true;
+
+ return ret;
}
EXPORT_SYMBOL(drm_dp_add_payload_part1);
@@ -3423,6 +3429,25 @@ int drm_dp_add_payload_part2(struct
drm_dp_mst_topology_mgr *mgr,
}
EXPORT_SYMBOL(drm_dp_add_payload_part2);
+/**
+ * drm_dp_mst_has_payload_alloc_errors - Query for payload allocation errors
+ * @mst_state: The MST atomic state
+ *
+ * Returns %true if the allocation of any of the payloads in @mst_state
+ * failed, %false otherwise.
+ */
+bool drm_dp_mst_has_payload_alloc_errors(const struct
drm_dp_mst_topology_state *mst_state)
+{
+ struct drm_dp_mst_atomic_payload *pos;
+
+ list_for_each_entry(pos, _state->payloads, next)
+ if (pos->alloc_failed)
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL(drm_dp_mst_has_payload_alloc_errors);
+
static int drm_dp_send_dpcd_read(struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_port *port,
int offset, int size, u8 *bytes)
diff --git a/include/drm/display/drm_dp_mst_helper.h
b/include/drm/display/drm_dp_mst_helper.h
index 44c6710ebf315..53b251b264e89 100644
--- a/include/drm/display/drm_dp_mst_helper.h
+++ b/include/drm/display/drm_dp_mst_helper.h
@@ -568,6 +568,8 @@ struct drm_dp_mst_atomic_payload {
bool delete : 1;
/** @dsc_enabled: Whether or not this payload has DSC enabled */
bool dsc_enabled : 1;
+ /** @alloc_failed: Whether or not allocating this payload failed */
+ bool alloc_failed : 1;
/** @next: The list node for this payload */
struct list_head next;
@@ -843,6 +845,7 @@ void drm_dp_remove_payload(struct drm_dp_mst_topology_mgr
*mgr,
struct drm_dp_mst_topology_state *mst_state,
const struct drm_dp_mst_atomic_payload *old_payload,
struct drm_dp_mst_atomic_payload *new_payload);
+bool drm_dp_mst_has_payload_alloc_errors(const struct
drm_dp_mst_topology_state *mst_state);
int drm_dp_check_act_status(struct drm_dp_mst_topology_mgr *mgr);
--
2.37.1
[PATCH v2 13/17] drm/display/dp_mst: Export the DP_PAYLOAD_TABLE_SIZE definition
In a follow-up workaround for a payload allocation problem the driver
uses DP_PAYLOAD_TABLE_SIZE to determine when the workaround is needed,
so export the definition.
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 --
include/drm/display/drm_dp.h | 2 ++
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 47605f67578ad..d0e929df7d088 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -4771,8 +4771,6 @@ static void drm_dp_mst_dump_mstb(struct seq_file *m,
}
}
-#define DP_PAYLOAD_TABLE_SIZE 64
-
static bool dump_dp_payload_table(struct drm_dp_mst_topology_mgr *mgr,
char *buf)
{
diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index bcc5183188a68..8f18f66ff5bc3 100644
--- a/include/drm/display/drm_dp.h
+++ b/include/drm/display/drm_dp.h
@@ -932,6 +932,8 @@
# define DP_PAYLOAD_ID_SLOT0_6 (1 << 7)
# define DP_PAYLOAD_ID_MASK0x7f
+#define DP_PAYLOAD_TABLE_SIZE 64
+
/* Source Device-specific */
#define DP_SOURCE_OUI 0x300
--
2.37.1
[PATCH v2 15/17] drm/dp: Add a quirk for a DELL P2715Q MST payload allocation problem
The DELL P2715Q monitor's MST hub has a payload allocation problem,
where the VCPI used to reserve the last two time slots (at position
0x3e, 0x3f) in the hub's payload table, this VCPI can't be reused for
later payload configurations. To work around the problem in a follow-up
patch the driver needs to reset the payload table after all payloads
have been freed; add a quirk the driver can use to detect the monitor
and apply the WA if needed.
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_helper.c | 2 ++
include/drm/display/drm_dp_helper.h | 8
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index 16565a0a5da6d..e2cf4b4fe11ea 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2244,6 +2244,8 @@ static const struct dpcd_quirk dpcd_quirk_list[] = {
{ OUI(0x90, 0xCC, 0x24), DEVICE_ID_ANY, true,
BIT(DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) },
/* Apple MacBookPro 2017 15 inch eDP Retina panel reports too low
DP_MAX_LINK_RATE */
{ OUI(0x00, 0x10, 0xfa), DEVICE_ID(101, 68, 21, 101, 98, 97), false,
BIT(DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS) },
+ /* DELL P2715Q MST payload table must be reset after the two last
payload slots get allocated. */
+ { OUI(0x00, 0xe0, 0x4c), DEVICE_ID('D', 'p', '1', '.', '2', 0), true,
BIT(DP_DPCD_QUIRK_MST_PAYLOAD_TABLE_RESET_WA) },
};
#undef OUI
diff --git a/include/drm/display/drm_dp_helper.h
b/include/drm/display/drm_dp_helper.h
index ab55453f2d2cd..fcd445921ec9d 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -620,6 +620,14 @@ enum drm_dp_quirk {
* the DP_MAX_LINK_RATE register reporting a lower max multiplier.
*/
DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS,
+ /**
+* @DP_DPCD_QUIRK_MST_PAYLOAD_TABLE_RESET_WA:
+*
+* An bug in the MST branch device's payload allocation logic requires
+* the payload table to be reset after its last two payload slots get
+* allocated.
+*/
+ DP_DPCD_QUIRK_MST_PAYLOAD_TABLE_RESET_WA,
};
/**
--
2.37.1
[PATCH v2 09/17] drm/display/dp_mst: Add a helper to verify the MST payload state
Add a function drivers can use to verify the MST payload state tracking
and compare this to the sink's payload table.
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 169 ++
include/drm/display/drm_dp.h | 3 +
include/drm/display/drm_dp_mst_helper.h | 3 +
3 files changed, 175 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 0c04b96ae614c..e57dd16955d52 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -4847,6 +4847,175 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
}
EXPORT_SYMBOL(drm_dp_mst_dump_topology);
+static bool verify_mst_payload_state(struct drm_dp_mst_topology_state
*mst_state)
+{
+ struct drm_dp_mst_topology_mgr *mgr = mst_state->mgr;
+ struct drm_dp_mst_atomic_payload *payload;
+ int payload_count = 0;
+ u64 time_slot_mask = 0;
+ u32 vcpi_mask = 0;
+ int last_set;
+
+ if (BITS_PER_TYPE(time_slot_mask) < mst_state->total_avail_slots)
+ return false;
+
+ list_for_each_entry(payload, _state->payloads, next) {
+ u64 mask;
+
+ if (payload->vc_start_slot == -1)
+ continue;
+
+ if (!payload->time_slots)
+ return false;
+
+ if (payload->vc_start_slot < mst_state->start_slot)
+ return false;
+
+ if (payload->vc_start_slot + payload->time_slots -
mst_state->start_slot >
+ mst_state->total_avail_slots)
+ return false;
+
+ mask = GENMASK_ULL(payload->vc_start_slot + payload->time_slots
- 1,
+ payload->vc_start_slot);
+
+ if (time_slot_mask & mask)
+ return false;
+
+ time_slot_mask |= mask;
+
+ if (payload->vcpi < 1 ||
+ payload->vcpi & ~DP_PAYLOAD_ID_MASK ||
+ payload->vcpi > BITS_PER_TYPE(vcpi_mask))
+ return false;
+ if (BIT(payload->vcpi - 1) & vcpi_mask)
+ return false;
+ vcpi_mask |= BIT(payload->vcpi - 1);
+
+ payload_count++;
+ }
+
+ if (payload_count != mgr->payload_count)
+ return false;
+
+ last_set = fls64(time_slot_mask);
+
+ if (last_set &&
+ GENMASK_ULL(last_set - 1, mst_state->start_slot) != time_slot_mask)
+ return false;
+
+ if (max(mst_state->start_slot, mgr->next_start_slot) !=
+ max_t(int, mst_state->start_slot, last_set))
+ return false;
+
+ return true;
+}
+
+static int get_payload_table_vcpi(const u8 *table, int slot)
+{
+ if (slot == 0)
+ return FIELD_GET(DP_PAYLOAD_ID_SLOT0_5_0_MASK, table[0]) |
+ (FIELD_GET(DP_PAYLOAD_ID_SLOT0_6, table[1]) << 6);
+ else
+ return FIELD_GET(DP_PAYLOAD_ID_MASK, table[slot]);
+}
+
+static bool verify_mst_payload_table(struct drm_dp_mst_topology_state
*mst_state,
+const u8 *payload_table)
+{
+ struct drm_dp_mst_topology_mgr *mgr = mst_state->mgr;
+ struct drm_dp_mst_atomic_payload *payload;
+ int i;
+
+ list_for_each_entry(payload, _state->payloads, next) {
+ if (payload->vc_start_slot == -1)
+ continue;
+
+ if (payload->vc_start_slot + payload->time_slots >
DP_PAYLOAD_TABLE_SIZE)
+ return false;
+
+ for (i = 0; i < payload->time_slots; i++)
+ if (get_payload_table_vcpi(payload_table,
+ payload->vc_start_slot + i)
!= payload->vcpi)
+ return false;
+ }
+
+ for (i = max(mgr->next_start_slot, mst_state->start_slot);
+i < DP_PAYLOAD_TABLE_SIZE;
+i++) {
+ if (get_payload_table_vcpi(payload_table, i) != 0)
+ return false;
+ }
+
+ return true;
+}
+
+static void print_mst_payload_state(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_topology_state *mst_state,
+ const u8 *payload_table)
+{
+ struct drm_dp_mst_atomic_payload *payload;
+ int i = 0;
+
+ drm_dbg(mgr->dev,
+ "Payload state: start_slot %d total_avail_slots %d
next_start_slot %d payload_count %d\n",
+ mst_state->start_slot, mst_state->total_avail_slots,
+ mgr->next_start_slot, mgr->payload_count);
+
+ list_for_each_entry(payload, _state->payloads, next) {
+ drm_dbg(mgr->dev,
+ "
[PATCH v2 12/17] drm/display/dp_mst: Add helpers to query payload allocation properties
Add helper functions to query the virtual channel and time slots for a
payload and the current payload count and total allocated time slots in
an MST topology. These are needed by a follow-up i915 patch verifying
the SW vs. HW state of the MST topology.
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 36 +++
include/drm/display/drm_dp_mst_helper.h | 21 +++
2 files changed, 57 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index f2081f3fad0da..47605f67578ad 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3448,6 +3448,42 @@ bool drm_dp_mst_has_payload_alloc_errors(const struct
drm_dp_mst_topology_state
}
EXPORT_SYMBOL(drm_dp_mst_has_payload_alloc_errors);
+/**
+ * drm_dp_mst_payload_vchannel - Return the DP virtual channel for a payload
+ * @mst_state: The MST atomic state containing @payload
+ * @payload: The payload to get the virtual channel for
+ *
+ * Return the DP virtual channel for @payload. The virtual channel is a
+ * contiguous range of MST Transmission Units on the DP main lanes between
+ * the source DPTX and the first downstream MST hub DPRX. Accordingly the
+ * channel is determined by the payload's position on the payload list
+ * ordered by VC start slot.
+ *
+ * Returns the 0-based virtual channel of @payload if it's in @mst_state with
+ * its time slots being allocated, or -1 otherwise.
+ */
+int drm_dp_mst_payload_vchannel(const struct drm_dp_mst_topology_state
*mst_state,
+ const struct drm_dp_mst_atomic_payload *payload)
+{
+ struct drm_dp_mst_atomic_payload *pos;
+ int vc = 0;
+ bool found = false;
+
+ list_for_each_entry(pos, _state->payloads, next) {
+ if (pos->vc_start_slot == -1)
+ continue;
+
+ if (pos == payload)
+ found = true;
+
+ if (pos->vc_start_slot < payload->vc_start_slot)
+ vc++;
+ }
+
+ return found ? vc : -1;
+}
+EXPORT_SYMBOL(drm_dp_mst_payload_vchannel);
+
static int drm_dp_send_dpcd_read(struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_port *port,
int offset, int size, u8 *bytes)
diff --git a/include/drm/display/drm_dp_mst_helper.h
b/include/drm/display/drm_dp_mst_helper.h
index 53b251b264e89..bb7c595096fed 100644
--- a/include/drm/display/drm_dp_mst_helper.h
+++ b/include/drm/display/drm_dp_mst_helper.h
@@ -846,6 +846,27 @@ void drm_dp_remove_payload(struct drm_dp_mst_topology_mgr
*mgr,
const struct drm_dp_mst_atomic_payload *old_payload,
struct drm_dp_mst_atomic_payload *new_payload);
bool drm_dp_mst_has_payload_alloc_errors(const struct
drm_dp_mst_topology_state *mst_state);
+int drm_dp_mst_payload_vchannel(const struct drm_dp_mst_topology_state
*mst_state,
+ const struct drm_dp_mst_atomic_payload
*payload);
+
+static inline int
+drm_dp_mst_payload_count(const struct drm_dp_mst_topology_state *mst_state)
+{
+ return mst_state->mgr->payload_count;
+}
+
+static inline int
+drm_dp_mst_allocated_time_slots(const struct drm_dp_mst_topology_state
*mst_state)
+{
+ return drm_dp_mst_payload_count(mst_state) ?
+ mst_state->mgr->next_start_slot - mst_state->start_slot : 0;
+}
+
+static inline int
+drm_dp_mst_payload_time_slots(const struct drm_dp_mst_atomic_payload *payload)
+{
+ return payload->time_slots;
+}
int drm_dp_check_act_status(struct drm_dp_mst_topology_mgr *mgr);
--
2.37.1
[PATCH v2 05/17] drm/display/dp_mst: Fix the payload VCPI check in drm_dp_mst_dump_topology()
Fix an off-by-one error in the VCPI check in drm_dp_mst_dump_topology().
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 38dab76ae69ea..8787df19f428b 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -4772,7 +4772,7 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
list_for_each_entry(payload, >payloads, next) {
char name[14];
- if (payload->vcpi != i || payload->delete)
+ if (payload->vcpi != i + 1 || payload->delete)
continue;
fetch_monitor_name(mgr, payload->port, name,
sizeof(name));
--
2.37.1
[PATCH v2 03/17] drm/display/dp_mst: Add drm_atomic_get_old_mst_topology_state()
Add a function to get the old MST topology state, required by a
follow-up i915 patch.
While at it clarify the code comment of
drm_atomic_get_new_mst_topology_state() and add _new prefix
to the new state pointer to remind about its difference from the old
state.
v2: Use old_/new_ prefixes for the state pointers. (Ville)
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: sta...@vger.kernel.org # 6.1
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 33 ---
include/drm/display/drm_dp_mst_helper.h | 3 ++
2 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 1990ff5dc7ddd..38dab76ae69ea 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -5364,28 +5364,53 @@ struct drm_dp_mst_topology_state
*drm_atomic_get_mst_topology_state(struct drm_a
}
EXPORT_SYMBOL(drm_atomic_get_mst_topology_state);
+/**
+ * drm_atomic_get_old_mst_topology_state: get old MST topology state in atomic
state, if any
+ * @state: global atomic state
+ * @mgr: MST topology manager, also the private object in this case
+ *
+ * This function wraps drm_atomic_get_old_private_obj_state() passing in the
MST atomic
+ * state vtable so that the private object state returned is that of a MST
+ * topology object.
+ *
+ * Returns:
+ *
+ * The old MST topology state, or NULL if there's no topology state for this
MST mgr
+ * in the global atomic state
+ */
+struct drm_dp_mst_topology_state *
+drm_atomic_get_old_mst_topology_state(struct drm_atomic_state *state,
+ struct drm_dp_mst_topology_mgr *mgr)
+{
+ struct drm_private_state *old_priv_state =
+ drm_atomic_get_old_private_obj_state(state, >base);
+
+ return old_priv_state ? to_dp_mst_topology_state(old_priv_state) : NULL;
+}
+EXPORT_SYMBOL(drm_atomic_get_old_mst_topology_state);
+
/**
* drm_atomic_get_new_mst_topology_state: get new MST topology state in atomic
state, if any
* @state: global atomic state
* @mgr: MST topology manager, also the private object in this case
*
- * This function wraps drm_atomic_get_priv_obj_state() passing in the MST
atomic
+ * This function wraps drm_atomic_get_new_private_obj_state() passing in the
MST atomic
* state vtable so that the private object state returned is that of a MST
* topology object.
*
* Returns:
*
- * The MST topology state, or NULL if there's no topology state for this MST
mgr
+ * The new MST topology state, or NULL if there's no topology state for this
MST mgr
* in the global atomic state
*/
struct drm_dp_mst_topology_state *
drm_atomic_get_new_mst_topology_state(struct drm_atomic_state *state,
struct drm_dp_mst_topology_mgr *mgr)
{
- struct drm_private_state *priv_state =
+ struct drm_private_state *new_priv_state =
drm_atomic_get_new_private_obj_state(state, >base);
- return priv_state ? to_dp_mst_topology_state(priv_state) : NULL;
+ return new_priv_state ? to_dp_mst_topology_state(new_priv_state) : NULL;
}
EXPORT_SYMBOL(drm_atomic_get_new_mst_topology_state);
diff --git a/include/drm/display/drm_dp_mst_helper.h
b/include/drm/display/drm_dp_mst_helper.h
index f5eb9aa152b14..32c764fb9cb56 100644
--- a/include/drm/display/drm_dp_mst_helper.h
+++ b/include/drm/display/drm_dp_mst_helper.h
@@ -868,6 +868,9 @@ struct drm_dp_mst_topology_state *
drm_atomic_get_mst_topology_state(struct drm_atomic_state *state,
struct drm_dp_mst_topology_mgr *mgr);
struct drm_dp_mst_topology_state *
+drm_atomic_get_old_mst_topology_state(struct drm_atomic_state *state,
+ struct drm_dp_mst_topology_mgr *mgr);
+struct drm_dp_mst_topology_state *
drm_atomic_get_new_mst_topology_state(struct drm_atomic_state *state,
struct drm_dp_mst_topology_mgr *mgr);
struct drm_dp_mst_atomic_payload *
--
2.37.1
[PATCH v2 02/17] drm/display/dp_mst: Handle old/new payload states in drm_dp_remove_payload()
Atm, drm_dp_remove_payload() uses the same payload state to both get the
vc_start_slot required for the payload removal DPCD message and to
deduct time_slots from vc_start_slot of all payloads after the one being
removed.
The above isn't always correct, as vc_start_slot must be the up-to-date
version contained in the new payload state, but time_slots must be the
one used when the payload was previously added, contained in the old
payload state. The new payload's time_slots can change vs. the old one
if the current atomic commit changes the corresponding mode.
This patch let's drivers pass the old and new payload states to
drm_dp_remove_payload(), but keeps these the same for now in all drivers
not to change the behavior. A follow-up i915 patch will pass in that
driver the correct old and new states to the function.
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: Ben Skeggs
Cc: Karol Herbst
Cc: Harry Wentland
Cc: Alex Deucher
Cc: Wayne Lin
Cc: sta...@vger.kernel.org # 6.1
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ville Syrjälä
Signed-off-by: Imre Deak
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
drivers/gpu/drm/display/drm_dp_mst_topology.c | 26 ++-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 ++-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
include/drm/display/drm_dp_mst_helper.h | 3 ++-
5 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index a50319fc42b11..180d3893b68da 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -208,7 +208,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
if (enable)
drm_dp_add_payload_part1(mst_mgr, mst_state, payload);
else
- drm_dp_remove_payload(mst_mgr, mst_state, payload);
+ drm_dp_remove_payload(mst_mgr, mst_state, payload, payload);
/* mst_mgr->->payloads are VC payload notify MST branch using DPCD or
* AUX message. The sequence is slot 1-63 allocated sequence for each
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 847c10aa2098c..1990ff5dc7ddd 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3342,7 +3342,8 @@ EXPORT_SYMBOL(drm_dp_add_payload_part1);
* drm_dp_remove_payload() - Remove an MST payload
* @mgr: Manager to use.
* @mst_state: The MST atomic state
- * @payload: The payload to write
+ * @old_payload: The payload with its old state
+ * @new_payload: The payload to write
*
* Removes a payload from an MST topology if it was successfully assigned a
start slot. Also updates
* the starting time slots of all other payloads which would have been shifted
towards the start of
@@ -3350,36 +3351,37 @@ EXPORT_SYMBOL(drm_dp_add_payload_part1);
*/
void drm_dp_remove_payload(struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_topology_state *mst_state,
- struct drm_dp_mst_atomic_payload *payload)
+ const struct drm_dp_mst_atomic_payload *old_payload,
+ struct drm_dp_mst_atomic_payload *new_payload)
{
struct drm_dp_mst_atomic_payload *pos;
bool send_remove = false;
/* We failed to make the payload, so nothing to do */
- if (payload->vc_start_slot == -1)
+ if (new_payload->vc_start_slot == -1)
return;
mutex_lock(>lock);
- send_remove = drm_dp_mst_port_downstream_of_branch(payload->port,
mgr->mst_primary);
+ send_remove = drm_dp_mst_port_downstream_of_branch(new_payload->port,
mgr->mst_primary);
mutex_unlock(>lock);
if (send_remove)
- drm_dp_destroy_payload_step1(mgr, mst_state, payload);
+ drm_dp_destroy_payload_step1(mgr, mst_state, new_payload);
else
drm_dbg_kms(mgr->dev, "Payload for VCPI %d not in topology, not
sending remove\n",
- payload->vcpi);
+ new_payload->vcpi);
list_for_each_entry(pos, _state->payloads, next) {
- if (pos != payload && pos->vc_start_slot >
payload->vc_start_slot)
- pos->vc_start_slot -= payload->time_slots;
+ if (pos != new_payload && pos->vc_start_slot >
new_payload->vc_start_slot)
+ pos->vc_start_slot -= old_payload->time_slots;
}
- payload->vc_start_slot = -1;
+ new_payload->vc_start_slot = -1;
mgr->payload_count--;
- mgr->next_start_slot -= payload->time_slots;
+ mgr->next_start_slot -= old_payload->time_slots;
- if (payload->delete)
- drm_dp_mst_put_port_malloc(payload->port);
+ if
Re: [PATCH v5] drm/mediatek: Add support for AR30 and BA30
Hi Chun-Kuang,
Thanks for the review! Will try to have a new patch out later today.
Re MT8195 RDMA: Yes, the MT8195 RDMA has a 10 bit mode, but I left
this unimplemented because I have no means of testing it
unfortunately; ChromeOS does not use this hardware.
I also wanted to mention, I think this patch might conflict with the
in-flight ovl-adaptor patch. Is there a protocol for a situation like
this?
Regards,
Justin
On Mon, Jan 30, 2023 at 7:28 PM Chun-Kuang Hu wrote:
>
> Hi, Justin:
>
> Justin Green 於 2023年1月31日 週二 上午4:36寫道：
> >
> > Add support for AR30 and BA30 pixel formats to the Mediatek DRM driver.
> >
> > Tested using "modetest -P" on an MT8195.
> >
> > Signed-off-by: Justin Green
> > ---
> > v2:
> > * Rebase and resolve merge conflicts with the AFBC patch.
> > v3:
> > * Moved 10-bit support detection to mtk_disk_ovl.c
> > v4:
> > * Moved formats to mtk_disp_ovl.c and mtk_disp_rdma.c
> > v5:
> > * Minor style adjustments per checkpatch.pl
> >
> > drivers/gpu/drm/mediatek/mtk_disp_drv.h | 4 ++
> > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 75 +
> > drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 27
> > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +-
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 4 ++
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 20 ++
> > drivers/gpu/drm/mediatek/mtk_drm_plane.c| 28 +++-
> > drivers/gpu/drm/mediatek/mtk_drm_plane.h| 3 +-
> > 8 files changed, 146 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > index 33e61a136bbc..6ad22ce75b81 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > @@ -96,6 +96,8 @@ void mtk_ovl_register_vblank_cb(struct device *dev,
> > void mtk_ovl_unregister_vblank_cb(struct device *dev);
> > void mtk_ovl_enable_vblank(struct device *dev);
> > void mtk_ovl_disable_vblank(struct device *dev);
> > +const u32 *mtk_ovl_get_formats(struct device *dev);
> > +size_t mtk_ovl_get_num_formats(struct device *dev);
> >
> > void mtk_rdma_bypass_shadow(struct device *dev);
> > int mtk_rdma_clk_enable(struct device *dev);
> > @@ -122,4 +124,6 @@ void mtk_mdp_rdma_start(struct device *dev, struct
> > cmdq_pkt *cmdq_pkt);
> > void mtk_mdp_rdma_stop(struct device *dev, struct cmdq_pkt *cmdq_pkt);
> > void mtk_mdp_rdma_config(struct device *dev, struct mtk_mdp_rdma_cfg *cfg,
> > struct cmdq_pkt *cmdq_pkt);
> > +const u32 *mtk_rdma_get_formats(struct device *dev);
> > +size_t mtk_rdma_get_num_formats(struct device *dev);
> > #endif
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > index 84daeaffab6a..1db70a77560f 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > @@ -41,6 +41,7 @@
> > #define DISP_REG_OVL_RDMA_CTRL(n) (0x00c0 + 0x20 * (n))
> > #define DISP_REG_OVL_RDMA_GMC(n) (0x00c8 + 0x20 * (n))
> > #define DISP_REG_OVL_ADDR_MT2701 0x0040
> > +#define DISP_REG_OVL_CLRFMT_EXT0x02D0
> > #define DISP_REG_OVL_ADDR_MT8173 0x0f40
> > #define DISP_REG_OVL_ADDR(ovl, n) ((ovl)->data->addr + 0x20 *
> > (n))
> > #define DISP_REG_OVL_HDR_ADDR(ovl, n) ((ovl)->data->addr + 0x20 *
> > (n) + 0x04)
> > @@ -61,11 +62,45 @@
> > 0 : OVL_CON_CLRFMT_RGB)
> > #define OVL_CON_CLRFMT_RGB888(ovl) ((ovl)->data->fmt_rgb565_is_0 ? \
> > OVL_CON_CLRFMT_RGB : 0)
> > +#define OVL_CON_CLRFMT_BIT_DEPTH_MASK(ovl) (0xFF << 4 * (ovl))
> > +#define OVL_CON_CLRFMT_BIT_DEPTH(depth, ovl) (depth << 4 * (ovl))
> > +#define OVL_CON_CLRFMT_8_BIT 0x00
> > +#define OVL_CON_CLRFMT_10_BIT 0x01
> > #defineOVL_CON_AEN BIT(8)
> > #defineOVL_CON_ALPHA 0xff
> > #defineOVL_CON_VIRT_FLIP BIT(9)
> > #defineOVL_CON_HORZ_FLIP BIT(10)
> >
> > +static const u32 formats_mt8173[] = {
> > + DRM_FORMAT_XRGB,
> > + DRM_FORMAT_ARGB,
> > + DRM_FORMAT_BGRX,
> > + DRM_FORMAT_BGRA,
> > + DRM_FORMAT_ABGR,
> > + DRM_FORMAT_XBGR,
> > + DRM_FORMAT_RGB888,
> > + DRM_FORMAT_BGR888,
> > + DRM_FORMAT_RGB565,
> > + DRM_FORMAT_UYVY,
> > + DRM_FORMAT_YUYV,
> > +};
> > +
> > +static const u32 formats_mt8195[] = {
> > + DRM_FORMAT_XRGB,
> > + DRM_FORMAT_ARGB,
> > + DRM_FORMAT_ARGB2101010,
> > + DRM_FORMAT_BGRX,
> > + DRM_FORMAT_BGRA,
> > + DRM_FORMAT_BGRA1010102,
> > + DRM_FORMAT_ABGR,
> > + DRM_FORMAT_XBGR,
> > + DRM_FORMAT_RGB888,
> > + DRM_FORMAT_BGR888,
> > + DRM_FORMAT_RGB565,
> > +
[PATCH AUTOSEL 5.15 12/12] amdgpu: fix build on non-DCN platforms.
From: Dave Airlie [ Upstream commit f439a959dcfb6b39d6fd4b85ca1110a1d1de1587 ] This fixes the build here locally on my 32-bit arm build. Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index ee238a16572e..0f0dd9b0d84a 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -10769,6 +10769,8 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev, bool lock_and_validation_needed = false; struct dm_crtc_state *dm_old_crtc_state; #if defined(CONFIG_DRM_AMD_DC_DCN) + struct drm_dp_mst_topology_mgr *mgr; + struct drm_dp_mst_topology_state *mst_state; struct dsc_mst_fairness_vars vars[MAX_PIPES]; #endif -- 2.39.0
[PATCH AUTOSEL 5.15 11/12] drm/amd/display: Fix timing not changning when freesync video is enabled
From: Aurabindo Pillai
[ Upstream commit 4b069553246f993c4221e382d0d0ae34f5ba730e ]
[Why]
Switching between certain modes that are freesync video modes and those
are not freesync video modes result in timing not changing as seen by
the monitor due to incorrect timing being driven.
The issue is fixed by ensuring that when a non freesync video mode is
set, we reset the freesync status on the crtc.
Reviewed-by: Nicholas Kazlauskas
Acked-by: Alan Liu
Signed-off-by: Aurabindo Pillai
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 409739ee5ba0..ee238a16572e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -10140,6 +10140,13 @@ static int dm_update_crtc_state(struct
amdgpu_display_manager *dm,
if (!dm_old_crtc_state->stream)
goto skip_modeset;
+ /* Unset freesync video if it was active before */
+ if (dm_old_crtc_state->freesync_config.state ==
VRR_STATE_ACTIVE_FIXED) {
+ dm_new_crtc_state->freesync_config.state =
VRR_STATE_INACTIVE;
+ dm_new_crtc_state->freesync_config.fixed_refresh_in_uhz
= 0;
+ }
+
+ /* Now check if we should set freesync video mode */
if (amdgpu_freesync_vid_mode && dm_new_crtc_state->stream &&
is_timing_unchanged_for_freesync(new_crtc_state,
old_crtc_state)) {
--
2.39.0
[PATCH AUTOSEL 6.1 20/20] amdgpu: fix build on non-DCN platforms.
From: Dave Airlie [ Upstream commit f439a959dcfb6b39d6fd4b85ca1110a1d1de1587 ] This fixes the build here locally on my 32-bit arm build. Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 15b408e3a705..d756a606b5e2 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -9411,6 +9411,8 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev, bool lock_and_validation_needed = false; struct dm_crtc_state *dm_old_crtc_state, *dm_new_crtc_state; #if defined(CONFIG_DRM_AMD_DC_DCN) + struct drm_dp_mst_topology_mgr *mgr; + struct drm_dp_mst_topology_state *mst_state; struct dsc_mst_fairness_vars vars[MAX_PIPES]; #endif -- 2.39.0
[PATCH AUTOSEL 6.1 18/20] drm/amd/display: Fix timing not changning when freesync video is enabled
From: Aurabindo Pillai
[ Upstream commit 4b069553246f993c4221e382d0d0ae34f5ba730e ]
[Why]
Switching between certain modes that are freesync video modes and those
are not freesync video modes result in timing not changing as seen by
the monitor due to incorrect timing being driven.
The issue is fixed by ensuring that when a non freesync video mode is
set, we reset the freesync status on the crtc.
Reviewed-by: Nicholas Kazlauskas
Acked-by: Alan Liu
Signed-off-by: Aurabindo Pillai
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index e10f1f15c9c4..15b408e3a705 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8788,6 +8788,13 @@ static int dm_update_crtc_state(struct
amdgpu_display_manager *dm,
if (!dm_old_crtc_state->stream)
goto skip_modeset;
+ /* Unset freesync video if it was active before */
+ if (dm_old_crtc_state->freesync_config.state ==
VRR_STATE_ACTIVE_FIXED) {
+ dm_new_crtc_state->freesync_config.state =
VRR_STATE_INACTIVE;
+ dm_new_crtc_state->freesync_config.fixed_refresh_in_uhz
= 0;
+ }
+
+ /* Now check if we should set freesync video mode */
if (amdgpu_freesync_vid_mode && dm_new_crtc_state->stream &&
is_timing_unchanged_for_freesync(new_crtc_state,
old_crtc_state)) {
--
2.39.0
Re: [PATCHv2] fbcon: Check font dimension limits
On Sun, Jan 29, 2023 at 04:17:40PM +0100, Samuel Thibault wrote:
> blit_x and blit_y are u32, so fbcon currently cannot support fonts
> larger than 32x32.
>
> The 32x32 case also needs shifting an unsigned int, to properly set bit
> 31, otherwise we get "UBSAN: shift-out-of-bounds in fbcon_set_font",
> as reported on:
>
> http://lore.kernel.org/all/ia1pr07mb98308653e259a6f2ce94a4afab...@ia1pr07mb9830.namprd07.prod.outlook.com
> Kernel Branch: 6.2.0-rc5-next-20230124
> Kernel config:
> https://drive.google.com/file/d/1F-LszDAizEEH0ZX0HcSR06v5q8FPl2Uv/view?usp=sharing
> Reproducer:
> https://drive.google.com/file/d/1mP1jcLBY7vWCNM60OMf-ogw-urQRjNrm/view?usp=sharing
>
> Reported-by: Sanan Hasanov
> Signed-off-by: Samuel Thibault
> Fixes: 2d2699d98492 ("fbcon: font setting should check limitation of driver")
> Cc: sta...@vger.kernel.org
Reviewed-by: Greg Kroah-Hartman
Re: [PATCH] drm/amd/display: Trivial swizzle-related code clean-ups
On 1/30/23 14:56, Guilherme G. Piccoli wrote:
> This is a very trivial code clean-up related to commit 5468c36d6285
> ("drm/amd/display: Filter Invalid 420 Modes for HDMI TMDS"). This commit
> added a validation on driver probe to prevent invalid TMDS modes, but one
> of the fake properties (swizzle) ended-up causing a warning on driver
> probe; was reported here:
> https://gitlab.freedesktop.org/drm/amd/-/issues/2264.
>
> It was fixed by commit 105a8b8698e2 ("drm/amd/display: patch cases with
> unknown plane state to prevent warning"), but the validation code had
> a double variable assignment, which we hereby remove. Also, the fix relies
> in the dcn2{0,1}patch_unknown_plane_state() callbacks, so while at it we
> took the opportunity to perform a small code clean-up in such routines.
>
> Cc: Aurabindo Pillai
> Cc: Daniel Wheeler
> Cc: Fangzhi Zuo
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Mark Broadworth
> Cc: Melissa Wen
> Cc: Rodrigo Siqueira
> Cc: Sung Joon Kim
> Cc: Swapnil Patel
> Signed-off-by: Guilherme G. Piccoli
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
> drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 8 ++--
> drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 6 ++
> 3 files changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 86a2f7f58550..e71e94663d14 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6336,7 +6336,6 @@ static enum dc_status
> dm_validate_stream_and_context(struct dc *dc,
> dc_plane_state->plane_size.surface_size.width = stream->src.width;
> dc_plane_state->plane_size.chroma_size.height = stream->src.height;
> dc_plane_state->plane_size.chroma_size.width = stream->src.width;
> - dc_plane_state->tiling_info.gfx9.swizzle = DC_SW_UNKNOWN;
> dc_plane_state->format = SURFACE_PIXEL_FORMAT_GRPH_ARGB;
> dc_plane_state->tiling_info.gfx9.swizzle = DC_SW_UNKNOWN;
> dc_plane_state->rotation = ROTATION_ANGLE_0;
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> index 531f405d2554..3af24ef9cb2d 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> @@ -2225,14 +2225,10 @@ enum dc_status dcn20_patch_unknown_plane_state(struct
> dc_plane_state *plane_stat
> enum surface_pixel_format surf_pix_format = plane_state->format;
> unsigned int bpp = resource_pixel_format_to_bpp(surf_pix_format);
>
> - enum swizzle_mode_values swizzle = DC_SW_LINEAR;
> -
> + plane_state->tiling_info.gfx9.swizzle = DC_SW_64KB_S;
> if (bpp == 64)
> - swizzle = DC_SW_64KB_D;
> - else
> - swizzle = DC_SW_64KB_S;
> + plane_state->tiling_info.gfx9.swizzle = DC_SW_64KB_D;
>
> - plane_state->tiling_info.gfx9.swizzle = swizzle;
> return DC_OK;
> }
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
> b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
> index fbcf0afeae0d..8f9244fe5c86 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
> @@ -1393,15 +1393,13 @@ static uint32_t read_pipe_fuses(struct dc_context
> *ctx)
>
> static enum dc_status dcn21_patch_unknown_plane_state(struct dc_plane_state
> *plane_state)
> {
> - enum dc_status result = DC_OK;
> -
> if (plane_state->ctx->dc->debug.disable_dcc == DCC_ENABLE) {
> plane_state->dcc.enable = 1;
> /* align to our worst case block width */
> plane_state->dcc.meta_pitch = ((plane_state->src_rect.width +
> 1023) / 1024) * 1024;
> }
> - result = dcn20_patch_unknown_plane_state(plane_state);
> - return result;
> +
> + return dcn20_patch_unknown_plane_state(plane_state);
> }
>
> static const struct resource_funcs dcn21_res_pool_funcs = {
Re: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini
On 31/01/2023 10:58, Chen, Guchun wrote: > Hi Christian, > > Do you think if it makes sense that we can set 'ring->sched.ready' to be true > in each ring init, even if before executing/setting up drm_sched_init in > amdgpu_device_init_schedulers? As 'ready' is a member of gpu scheduler > structure. > > Regards, > Guchun > Hi folks, thanks a lot for the feedback so far, much appreciated! I'm feeling a bit confused specially since there seems to be 2 orthogonal (yet related) topics being discussed; let me try to summarize my understanding and we can then further discuss better: (a) The first problem is the one addressed in the patch - how to prevent drm_sched_fini() to get called if drm_sched_init() wasn't called? I've proposed sched.name, seems Christian prefers sched.ops, correct? (b) We can't use sched.ready, which would make sense...but amdgpu overrides its meaning, the driver manipulates this value for its own purposes of tracking ring init, or something like that. This is the tangential topic: what should we do here? My understanding of Alex's message is that we could have a "ready" field in the ring structure and stop messing with sched.ready - does it make sense Alex? Guchun / Christian, does it also make sense for you? Regarding (a), I could re-submit having s/sched.name/sched.ops, no biggies, I tested both to be fair, before sending...I just chose name but any field that is proper initialized on drm_sched_init() would work. Thanks, Guilherme
Re: [RESEND PATCH v11 02/18] drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper
On Tue, Jan 31, 2023 at 7:29 PM Maxime Ripard wrote:
>
> On Tue, Jan 31, 2023 at 07:17:50PM +0530, Jagan Teki wrote:
> > On Tue, Jan 31, 2023 at 6:16 PM Maxime Ripard wrote:
> > >
> > > On Mon, Jan 30, 2023 at 06:54:54PM +0530, Jagan Teki wrote:
> > > > On Mon, Jan 30, 2023 at 6:26 PM Maxime Ripard wrote:
> > > > >
> > > > > On Fri, Jan 27, 2023 at 11:09:26PM +0530, Jagan Teki wrote:
> > > > > > Hi,
> > > > > >
> > > > > > On Thu, Jan 26, 2023 at 8:48 PM Jagan Teki
> > > > > > wrote:
> > > > > > >
> > > > > > > On Thu, Jan 26, 2023 at 5:42 PM Maxime Ripard
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > On Mon, Jan 23, 2023 at 08:41:56PM +0530, Jagan Teki wrote:
> > > > > > > > > Add devm OF helper to return the next DSI bridge in the chain.
> > > > > > > > >
> > > > > > > > > Unlike general bridge return helper devm_drm_of_get_bridge,
> > > > > > > > > this
> > > > > > > > > helper uses the dsi specific panel_or_bridge helper to find
> > > > > > > > > the
> > > > > > > > > next DSI device in the pipeline.
> > > > > > > > >
> > > > > > > > > Helper lookup a given child DSI node or a DT node's port and
> > > > > > > > > endpoint number, find the connected node and return either
> > > > > > > > > the associated struct drm_panel or drm_bridge device.
> > > > > > > >
> > > > > > > > I'm not sure that using a device managed helper is the right
> > > > > > > > choice
> > > > > > > > here. The bridge will stay longer than the backing device so it
> > > > > > > > will
> > > > > > > > create a use-after-free. You should probably use a DRM-managed
> > > > > > > > action
> > > > > > > > here instead.
> > > > > > >
> > > > > > > Thanks for the comments. If I understand correctly we can use
> > > > > > > drmm_panel_bridge_add instead devm_drm_panel_bridge_add once we
> > > > > > > found
> > > > > > > the panel or bridge - am I correct?
> > > > > >
> > > > > > Look like it is not possible to use DRM-managed action helper here
> > > > > > as
> > > > > > devm_drm_of_dsi_get_bridge is calling from the DSI host attach hook
> > > > > > in
> > > > > > which we cannot find drm_device pointer (as drm_device pointer is
> > > > > > mandatory for using DRM-managed action).
> > > > > > https://github.com/openedev/kernel/blob/imx8mm-dsi-v12/drivers/gpu/drm/bridge/samsung-dsim.c#L1545
> > > > > >
> > > > > > Please check and correct me if I mentioned any incorrect details.
> > > > >
> > > > > You shouldn't call that function from attach anyway:
> > > > > https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html#special-care-with-mipi-dsi-bridges
> > > >
> > > > True, If I remember we have bridges earlier to find the downstream
> > > > bridge/panels from the bridge ops and attach the hook, if that is the
> > > > case maybe we can use this DRM-managed action as we can get the
> > > > drm_device pointer from the bridge pointer.
> > >
> > > I'm not quite sure what you mean. You shouldn't retrieve the bridge from
> > > the attach hook but from the probe / bind ones. If that's not working
> > > for you, this is a bug in the documentation we should address.
> >
> > Something like this, afterward the design has updated to move the
> > panel or bridge found to be in host attach.
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/bridge/nwl-dsi.c?h=v5.10#n911
>
> What are you pointing to exactly, it's not a MIPI-DSI host attach,
> that's a bridge attach, you have access to the DRM device there.
Yes, what I'm saying here is we can have the option to use a DRM
device pointer so finding the panel or bridge by using a DRM-managed
action helper can be possible rather than host attach.
Something like this,
struct drm_bridge *drmm_of_dsi_get_bridge(struct drm_device *drm,
struct device_node *np,
u32 port, u32 endpoint)
{
struct drm_bridge *bridge;
struct drm_panel *panel;
int ret;
ret = drm_of_dsi_find_panel_or_bridge(np, port, endpoint,
, );
if (ret)
return ERR_PTR(ret);
if (panel)
bridge = drmm_panel_bridge_add(drm, panel);
return bridge;
}
static int nwl_dsi_bridge_attach(struct drm_bridge *bridge, enum
drm_bridge_attach_flags flags)
{
struct nwl_dsi *dsi = bridge_to_dsi(bridge);
struct drm_bridge *bridge;
int ret;
bridge = drmm_of_dsi_get_bridge(bridge->dev, dsi->dev->of_node, 1, 0);
if (IS_ERR(bridge))
ret = PTR_ERR(dsi->out_bridge);
return drm_bridge_attach(bridge->encoder, dsi->panel_bridge,
bridge, flags);
}
static const struct drm_bridge_funcs nwl_dsi_bridge_funcs = {
.attach = nwl_dsi_bridge_attach,
};
>
> > >
> > > > So, what is the best we can do here, add any TODO comment to follow up
> > > > the same in the future or something else, please let me know?
> > >
Re: [PATCH v2 1/4] memcg: Track exported dma-buffers
On 25/01/2023 20:04, T.J. Mercier wrote: On Wed, Jan 25, 2023 at 9:31 AM Tvrtko Ursulin wrote: Hi, On 25/01/2023 11:52, Michal Hocko wrote: On Tue 24-01-23 19:46:28, Shakeel Butt wrote: On Tue, Jan 24, 2023 at 03:59:58PM +0100, Michal Hocko wrote: On Mon 23-01-23 19:17:23, T.J. Mercier wrote: When a buffer is exported to userspace, use memcg to attribute the buffer to the allocating cgroup until all buffer references are released. Is there any reason why this memory cannot be charged during the allocation (__GFP_ACCOUNT used)? Also you do charge and account the memory but underlying pages do not know about their memcg (this is normally done with commit_charge for user mapped pages). This would become a problem if the memory is migrated for example. I don't think this is movable memory. This also means that you have to maintain memcg reference outside of the memcg proper which is not really nice either. This mimicks tcp kmem limit implementation which I really have to say I am not a great fan of and this pattern shouldn't be coppied. I think we should keep the discussion on technical merits instead of personal perference. To me using skmem like interface is totally fine but the pros/cons need to be very explicit and the clear reasons to select that option should be included. I do agree with that. I didn't want sound to be personal wrt tcp kmem accounting but the overall code maintenance cost is higher because of how tcp take on accounting differs from anything else in the memcg proper. I would prefer to not grow another example like that. To me there are two options: 1. Using skmem like interface as this patch series: The main pros of this option is that it is very simple. Let me list down the cons of this approach: a. There is time window between the actual memory allocation/free and the charge and uncharge and [un]charge happen when the whole memory is allocated or freed. I think for the charge path that might not be a big issue but on the uncharge, this can cause issues. The application and the potential shrinkers have freed some of this dmabuf memory but until the whole dmabuf is freed, the memcg uncharge will not happen. This can consequences on reclaim and oom behavior of the application. b. Due to the usage model i.e. a central daemon allocating the dmabuf memory upfront, there is a requirement to have a memcg charge transfer functionality to transfer the charge from the central daemon to the client applications. This does introduce complexity and avenues of weird reclaim and oom behavior. 2. Allocate and charge the memory on page fault by actual user In this approach, the memory is not allocated upfront by the central daemon but rather on the page fault by the client application and the memcg charge happen at the same time. The only cons I can think of is this approach is more involved and may need some clever tricks to track the page on the free patch i.e. we to decrement the dmabuf memcg stat on free path. Maybe a page flag. The pros of this approach is there is no need have a charge transfer functionality and the charge/uncharge being closely tied to the actual memory allocation and free. Personally I would prefer the second approach but I don't want to just block this work if the dmabuf folks are ok with the cons mentioned of the first approach. I am not familiar with dmabuf internals to judge complexity on their end but I fully agree that charge-when-used is much more easier to reason about and it should have less subtle surprises. Disclaimer that I don't seem to see patches 3&4 on dri-devel so maybe I am missing something, but in principle yes, I agree that the 2nd option (charge the user, not exporter) should be preferred. Thing being that at export time there may not be any backing store allocated, plus if the series is restricting the charge transfer to just Android clients then it seems it has the potential to miss many other use cases. At least needs to outline a description on how the feature will be useful outside Android. There is no restriction like that. It's available to anybody who wants to call dma_buf_charge_transfer if they actually have a need for that, which I don't really expect to be common since most users/owners of the buffers will be the ones causing the export in the first place. It's just not like that on Android with the extra allocator process in the middle most of the time. Yeah I used the wrong term "restrict", apologies. What I meant was, if the idea was to allow spotting memory leaks, with the charge transfer being optional and in the series only wired up for Android Binder, then it obviously only fully works for that one case. So a step back.. .. For instance, it is not feasible to transfer the charge when dmabuf is attached, or imported? That would attribute the usage to the user/importer so give better visibility on who is actually causing the memory leak. Further more, if above is feasible, then could it
Re: [PATCH 2/2] accel/ivpu: avoid duplciate assignment
Applied to drm-misc-next. Thanks.
On 26.01.2023 17:37, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> With extra warnings enabled, gcc warns about two assignments
> of the same .mmap callback:
>
> In file included from drivers/accel/ivpu/ivpu_drv.c:10:
> include/drm/drm_accel.h:31:27: error: initialized field overwritten
> [-Werror=override-init]
>31 | .mmap = drm_gem_mmap
> | ^~~~
> drivers/accel/ivpu/ivpu_drv.c:360:9: note: in expansion of macro
> 'DRM_ACCEL_FOPS'
> 360 | DRM_ACCEL_FOPS,
> | ^~
>
> Remove the unused local assignment.
>
> Fixes: 20709aa9435b ("accel: Add .mmap to DRM_ACCEL_FOPS")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/accel/ivpu/ivpu_drv.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
> index 2bc2f1b90671..a29e8ee0dce6 100644
> --- a/drivers/accel/ivpu/ivpu_drv.c
> +++ b/drivers/accel/ivpu/ivpu_drv.c
> @@ -356,7 +356,6 @@ int ivpu_shutdown(struct ivpu_device *vdev)
>
> static const struct file_operations ivpu_fops = {
> .owner = THIS_MODULE,
> - .mmap = drm_gem_mmap,
> DRM_ACCEL_FOPS,
> };
>
Re: [RESEND PATCH v11 02/18] drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper
On Tue, Jan 31, 2023 at 07:17:50PM +0530, Jagan Teki wrote: > On Tue, Jan 31, 2023 at 6:16 PM Maxime Ripard wrote: > > > > On Mon, Jan 30, 2023 at 06:54:54PM +0530, Jagan Teki wrote: > > > On Mon, Jan 30, 2023 at 6:26 PM Maxime Ripard wrote: > > > > > > > > On Fri, Jan 27, 2023 at 11:09:26PM +0530, Jagan Teki wrote: > > > > > Hi, > > > > > > > > > > On Thu, Jan 26, 2023 at 8:48 PM Jagan Teki > > > > > wrote: > > > > > > > > > > > > On Thu, Jan 26, 2023 at 5:42 PM Maxime Ripard > > > > > > wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > On Mon, Jan 23, 2023 at 08:41:56PM +0530, Jagan Teki wrote: > > > > > > > > Add devm OF helper to return the next DSI bridge in the chain. > > > > > > > > > > > > > > > > Unlike general bridge return helper devm_drm_of_get_bridge, this > > > > > > > > helper uses the dsi specific panel_or_bridge helper to find the > > > > > > > > next DSI device in the pipeline. > > > > > > > > > > > > > > > > Helper lookup a given child DSI node or a DT node's port and > > > > > > > > endpoint number, find the connected node and return either > > > > > > > > the associated struct drm_panel or drm_bridge device. > > > > > > > > > > > > > > I'm not sure that using a device managed helper is the right > > > > > > > choice > > > > > > > here. The bridge will stay longer than the backing device so it > > > > > > > will > > > > > > > create a use-after-free. You should probably use a DRM-managed > > > > > > > action > > > > > > > here instead. > > > > > > > > > > > > Thanks for the comments. If I understand correctly we can use > > > > > > drmm_panel_bridge_add instead devm_drm_panel_bridge_add once we > > > > > > found > > > > > > the panel or bridge - am I correct? > > > > > > > > > > Look like it is not possible to use DRM-managed action helper here as > > > > > devm_drm_of_dsi_get_bridge is calling from the DSI host attach hook in > > > > > which we cannot find drm_device pointer (as drm_device pointer is > > > > > mandatory for using DRM-managed action). > > > > > https://github.com/openedev/kernel/blob/imx8mm-dsi-v12/drivers/gpu/drm/bridge/samsung-dsim.c#L1545 > > > > > > > > > > Please check and correct me if I mentioned any incorrect details. > > > > > > > > You shouldn't call that function from attach anyway: > > > > https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html#special-care-with-mipi-dsi-bridges > > > > > > True, If I remember we have bridges earlier to find the downstream > > > bridge/panels from the bridge ops and attach the hook, if that is the > > > case maybe we can use this DRM-managed action as we can get the > > > drm_device pointer from the bridge pointer. > > > > I'm not quite sure what you mean. You shouldn't retrieve the bridge from > > the attach hook but from the probe / bind ones. If that's not working > > for you, this is a bug in the documentation we should address. > > Something like this, afterward the design has updated to move the > panel or bridge found to be in host attach. > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/bridge/nwl-dsi.c?h=v5.10#n911 What are you pointing to exactly, it's not a MIPI-DSI host attach, that's a bridge attach, you have access to the DRM device there. > > > > > So, what is the best we can do here, add any TODO comment to follow up > > > the same in the future or something else, please let me know? > > > > Make it work in a safe way, as described in the documentation? > > Yeah, it is a clear deadlock. It is not possible to use DM-managed > action helper in host attach as there is no drm_device pointer and we > cannot move panel or bridge finding out of host attach as per design > documentation. I'm thinking of go-ahead with adding TODO for adding > the safe way with an existing patch. Please let me know. I've been telling you for three mails now that it's not acceptable. So, again, no, it's not acceptable. Do something else and follow the documentation instead. Maxime
RE: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini
Hi Christian,
Do you think if it makes sense that we can set 'ring->sched.ready' to be true
in each ring init, even if before executing/setting up drm_sched_init in
amdgpu_device_init_schedulers? As 'ready' is a member of gpu scheduler
structure.
Regards,
Guchun
-Original Message-
From: Koenig, Christian
Sent: Tuesday, January 31, 2023 6:59 PM
To: Chen, Guchun ; Alex Deucher ;
Guilherme G. Piccoli
Cc: amd-...@lists.freedesktop.org; ker...@gpiccoli.net; Pan, Xinhui
; dri-devel@lists.freedesktop.org; Tuikov, Luben
; Limonciello, Mario ;
kernel-...@igalia.com; Deucher, Alexander
Subject: Re: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching drm_sched
init/fini
Am 31.01.23 um 10:17 schrieb Chen, Guchun:
> Hi Piccoli,
>
> Please ignore my request of full dmesg log. I can reproduce the issue and get
> the same failure callstack by returning early with an error code prior to
> amdgpu_device_init_schedulers.
>
> Regards,
> Guchun
>
> -Original Message-
> From: Chen, Guchun
> Sent: Tuesday, January 31, 2023 2:37 PM
> To: Alex Deucher ; Guilherme G. Piccoli
>
> Cc: amd-...@lists.freedesktop.org; ker...@gpiccoli.net; Pan, Xinhui
> ; dri-devel@lists.freedesktop.org; Tuikov, Luben
> ; Limonciello, Mario
> ; kernel-...@igalia.com; Deucher, Alexander
> ; Koenig, Christian
>
> Subject: RE: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching
> drm_sched init/fini
>
> Hi Piccoli,
>
> I agree with Alex's point, using ring->sched.name for such check is not a
> good way. BTW, can you please attach a full dmesg long in bad case to help me
> understand more?
>
> Regards,
> Guchun
>
> -Original Message-
> From: Alex Deucher
> Sent: Tuesday, January 31, 2023 6:30 AM
> To: Guilherme G. Piccoli
> Cc: amd-...@lists.freedesktop.org; ker...@gpiccoli.net; Chen, Guchun
> ; Pan, Xinhui ;
> dri-devel@lists.freedesktop.org; Tuikov, Luben ;
> Limonciello, Mario ; kernel-...@igalia.com;
> Deucher, Alexander ; Koenig, Christian
>
> Subject: Re: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching
> drm_sched init/fini
>
> On Mon, Jan 30, 2023 at 4:51 PM Guilherme G. Piccoli
> wrote:
>> + Luben
>>
>> (sorry, missed that in the first submission).
>>
>> On 30/01/2023 18:45, Guilherme G. Piccoli wrote:
>>> Currently amdgpu calls drm_sched_fini() from the fence driver sw
>>> fini routine - such function is expected to be called only after the
>>> respective init function - drm_sched_init() - was executed successfully.
>>>
>>> Happens that we faced a driver probe failure in the Steam Deck
>>> recently, and the function drm_sched_fini() was called even without
>>> its counter-part had been previously called, causing the following oops:
>>>
>>> amdgpu: probe of :04:00.0 failed with error -110
>>> BUG: kernel NULL pointer dereference, address: 0090 PGD
>>> 0 P4D 0
>>> Oops: 0002 [#1] PREEMPT SMP NOPTI
>>> CPU: 0 PID: 609 Comm: systemd-udevd Not tainted 6.2.0-rc3-gpiccoli
>>> #338 Hardware name: Valve Jupiter/Jupiter, BIOS F7A0113 11/04/2022
>>> RIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched] [...] Call Trace:
>>>
>>> amdgpu_fence_driver_sw_fini+0xc8/0xd0 [amdgpu]
>>> amdgpu_device_fini_sw+0x2b/0x3b0 [amdgpu]
>>> amdgpu_driver_release_kms+0x16/0x30 [amdgpu]
>>> devm_drm_dev_init_release+0x49/0x70
>>> [...]
>>>
>>> To prevent that, check if the drm_sched was properly initialized for
>>> a given ring before calling its fini counter-part.
>>>
>>> Notice ideally we'd use sched.ready for that; such field is set as
>>> the latest thing on drm_sched_init(). But amdgpu seems to "override"
>>> the meaning of such field - in the above oops for example, it was a
>>> GFX ring causing the crash, and the sched.ready field was set to
>>> true in the ring init routine, regardless of the state of the DRM
>>> scheduler. Hence, we ended-up using another sched field.
> Fixes: 067f44c8b459 ("drm/amdgpu: avoid over-handle of fence
> driver fini in s3 test (v2)")
>>> Cc: Andrey Grodzovsky
>>> Cc: Guchun Chen
>>> Cc: Mario Limonciello
>>> Signed-off-by: Guilherme G. Piccoli
>>> ---
>>>
>>>
>>> Hi folks, first of all thanks in advance for reviews / comments!
>>> Notice that I've used the Fixes tag more in the sense to bring it to
>>> stable, I didn't find a good patch candidate that added the call to
>>> drm_sched_fini(), was reaching way too old commits...so
>>> 067f44c8b459 seems a good candidate - or maybe not?
>>>
>>> Now, with regards sched.ready, spent a bit of time to figure what
>>> was happening...would be feasible maybe to stop using that to mark
>>> some kind ring status? I think it should be possible to add a flag
>>> to the ring structure for that, and free sched.ready from being
>>> manipulate by the amdgpu driver, what's your thoughts on that?
> It's been a while, but IIRC, we used to have a ring->ready field in the
> driver which at some point got migrated out of the driver into the GPU
> scheduler and the driver side code never
Re: [RESEND PATCH v11 02/18] drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper
On Tue, Jan 31, 2023 at 6:16 PM Maxime Ripard wrote: > > On Mon, Jan 30, 2023 at 06:54:54PM +0530, Jagan Teki wrote: > > On Mon, Jan 30, 2023 at 6:26 PM Maxime Ripard wrote: > > > > > > On Fri, Jan 27, 2023 at 11:09:26PM +0530, Jagan Teki wrote: > > > > Hi, > > > > > > > > On Thu, Jan 26, 2023 at 8:48 PM Jagan Teki > > > > wrote: > > > > > > > > > > On Thu, Jan 26, 2023 at 5:42 PM Maxime Ripard > > > > > wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > On Mon, Jan 23, 2023 at 08:41:56PM +0530, Jagan Teki wrote: > > > > > > > Add devm OF helper to return the next DSI bridge in the chain. > > > > > > > > > > > > > > Unlike general bridge return helper devm_drm_of_get_bridge, this > > > > > > > helper uses the dsi specific panel_or_bridge helper to find the > > > > > > > next DSI device in the pipeline. > > > > > > > > > > > > > > Helper lookup a given child DSI node or a DT node's port and > > > > > > > endpoint number, find the connected node and return either > > > > > > > the associated struct drm_panel or drm_bridge device. > > > > > > > > > > > > I'm not sure that using a device managed helper is the right choice > > > > > > here. The bridge will stay longer than the backing device so it will > > > > > > create a use-after-free. You should probably use a DRM-managed > > > > > > action > > > > > > here instead. > > > > > > > > > > Thanks for the comments. If I understand correctly we can use > > > > > drmm_panel_bridge_add instead devm_drm_panel_bridge_add once we found > > > > > the panel or bridge - am I correct? > > > > > > > > Look like it is not possible to use DRM-managed action helper here as > > > > devm_drm_of_dsi_get_bridge is calling from the DSI host attach hook in > > > > which we cannot find drm_device pointer (as drm_device pointer is > > > > mandatory for using DRM-managed action). > > > > https://github.com/openedev/kernel/blob/imx8mm-dsi-v12/drivers/gpu/drm/bridge/samsung-dsim.c#L1545 > > > > > > > > Please check and correct me if I mentioned any incorrect details. > > > > > > You shouldn't call that function from attach anyway: > > > https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html#special-care-with-mipi-dsi-bridges > > > > True, If I remember we have bridges earlier to find the downstream > > bridge/panels from the bridge ops and attach the hook, if that is the > > case maybe we can use this DRM-managed action as we can get the > > drm_device pointer from the bridge pointer. > > I'm not quite sure what you mean. You shouldn't retrieve the bridge from > the attach hook but from the probe / bind ones. If that's not working > for you, this is a bug in the documentation we should address. Something like this, afterward the design has updated to move the panel or bridge found to be in host attach. https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/bridge/nwl-dsi.c?h=v5.10#n911 > > > So, what is the best we can do here, add any TODO comment to follow up > > the same in the future or something else, please let me know? > > Make it work in a safe way, as described in the documentation? Yeah, it is a clear deadlock. It is not possible to use DM-managed action helper in host attach as there is no drm_device pointer and we cannot move panel or bridge finding out of host attach as per design documentation. I'm thinking of go-ahead with adding TODO for adding the safe way with an existing patch. Please let me know. Thanks, Jagan.
Re: [PATCH v12 13/14] drm/msm/disp/dpu: add PSR support for eDP interface in dpu driver
On 30/01/2023 17:11, Vinod Polimera wrote:
Enable PSR on eDP interface using drm self-refresh librabry.
This patch uses a trigger from self-refresh library to enter/exit
into PSR, when there are no updates from framework.
Signed-off-by: Kalyan Thota
Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 13 -
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 14 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
3 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index f29a339..60e5984 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include "dpu_kms.h"
#include "dpu_hw_lm.h"
@@ -1021,6 +1022,9 @@ static void dpu_crtc_disable(struct drm_crtc *crtc,
DRM_DEBUG_KMS("crtc%d\n", crtc->base.id);
+ if (old_crtc_state->self_refresh_active)
+ return;
+
I have been looking at the crtc_needs_disable(). It explicitly mentions
that 'We also need to run through the crtc_funcs->disable() function
[..] if it's transitioning to self refresh mode...'. Don't we need to
perform some cleanup here (like disabling the vblank irq handling,
freeing the bandwidth, etc)?
/* Disable/save vblank irq handling */
drm_crtc_vblank_off(crtc);
@@ -1577,7 +1581,7 @@ struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane *plane,
{
struct drm_crtc *crtc = NULL;
struct dpu_crtc *dpu_crtc = NULL;
- int i;
+ int i, ret;
dpu_crtc = kzalloc(sizeof(*dpu_crtc), GFP_KERNEL);
if (!dpu_crtc)
@@ -1614,6 +1618,13 @@ struct drm_crtc *dpu_crtc_init(struct drm_device *dev,
struct drm_plane *plane,
/* initialize event handling */
spin_lock_init(_crtc->event_lock);
+ ret = drm_self_refresh_helper_init(crtc);
+ if (ret) {
+ DPU_ERROR("Failed to initialize %s with self-refresh helpers
%d\n",
+ crtc->name, ret);
+ return ERR_PTR(ret);
+ }
+
DRM_DEBUG_KMS("%s: successfully initialized crtc\n", dpu_crtc->name);
return crtc;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 01b7509..450abb1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
#include
#include
@@ -1212,11 +1213,24 @@ static void dpu_encoder_virt_atomic_disable(struct
drm_encoder *drm_enc,
struct drm_atomic_state *state)
{
struct dpu_encoder_virt *dpu_enc = NULL;
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *old_state = NULL;
int i = 0;
dpu_enc = to_dpu_encoder_virt(drm_enc);
DPU_DEBUG_ENC(dpu_enc, "\n");
+ crtc = drm_atomic_get_old_crtc_for_encoder(state, drm_enc);
+ if (crtc)
+ old_state = drm_atomic_get_old_crtc_state(state, crtc);
+
+ /*
+* The encoder is already disabled if self refresh mode was set earlier,
+* in the old_state for the corresponding crtc.
+*/
+ if (old_state && old_state->self_refresh_active)
+ return;
+
Again the same question here, doesn't crtc_needs_disable() take care of
this clause? I might be missing something in the PSR state transitions.
Could you please add some explanation here?
mutex_lock(_enc->enc_lock);
dpu_enc->enabled = false;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index a683bd9..681dd2e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -491,7 +491,7 @@ static void dpu_kms_wait_for_commit_done(struct msm_kms
*kms,
return;
}
- if (!crtc->state->active) {
+ if (!drm_atomic_crtc_effectively_active(crtc->state)) {
DPU_DEBUG("[crtc:%d] not active\n", crtc->base.id);
return;
}
--
With best wishes
Dmitry
Re: [PATCH] drivers: Restore alignment and newline in Makefile
Applied to drm-misc-next.
Thanks.
On 24.01.2023 11:41, Geert Uytterhoeven wrote:
> The introduction of drivers/accel/ broke alignment, and removed the
> newline at the end of the file. Fix all of that.
>
> Fixes: 35b137630f08d913 ("accel/ivpu: Introduce a new DRM driver for Intel
> VPU")
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/Makefile b/drivers/Makefile
> index f0972e2226c97cb5..9ea6eb3b5d7b7f17 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -189,4 +189,4 @@ obj-$(CONFIG_COUNTER) += counter/
> obj-$(CONFIG_MOST) += most/
> obj-$(CONFIG_PECI) += peci/
> obj-$(CONFIG_HTE)+= hte/
> -obj-$(CONFIG_DRM_ACCEL) += accel/
> \ No newline at end of file
> +obj-$(CONFIG_DRM_ACCEL) += accel/
Re: [RFC PATCH v3 0/3] Support for Solid Fill Planes
On Tue, 31 Jan 2023 11:21:18 + Simon Ser wrote: > On Tuesday, January 31st, 2023 at 12:13, Pekka Paalanen > wrote: > > > On Tue, 31 Jan 2023 10:06:39 + > > Simon Ser wrote: > > > > > On Tuesday, January 31st, 2023 at 10:25, Pekka Paalanen > > > wrote: > > > > > > > indeed, what about simply using a 1x1 framebuffer for real? Why was that > > > > approach rejected? > > > > > > Ideally we don't want to allocate any GPU memory for the solid-fill > > > stuff. And if we special-case 1x1 FB creation to not be backed by real > > > GPU memory then we hit several situations where user-space expects a > > > real FB but there isn't: for instance, GETFB2 converts from FB object > > > ID to GEM handles. Even if we make GETFB2 fail and accept that this > > > breaks user-space, then there is no way for user-space to recover the > > > FB color for flicker-free transitions and such. > > > > > > This is all purely from a uAPI PoV, completely ignoring the potential > > > issues with the internal kernel abstractions which might not be suitable > > > for this either. > > > > I mean a real 1x1 buffer: a dumb buffer. > > > > It would be absolutely compatible with anything existing, because it is > > a real FB. As a dumb buffer it would be trivial to write into and read > > out. As 1x1 it would be tiny (one page?). Even if something needs to > > raw-access uncached memory over 33 MHz PCI bus or whatever the worst > > case is, it's just one pixel, so it's fast enough, right? And it only > > needs to be read once when set, like USB display drivers do. The driver > > does not need to manually apply any color operations, because none are > > supported in this special case. > > > > One can put all these limitations and even pixel format in the plane > > property that tells userspace that a 1x1 FB works here. > > > > To recap, the other alternatives under discussion I see right now are: > > > > - this proposal of dedicated fill color property > > - stuffing something new into FB_ID property > > > > There is also the question of other kinds of plane content sources like > > live camera feeds where userspace won't be shovelling each frame > > individually like we do now. > > > > 1x1 dumb buffer is not as small and lean as a dedicated fill color > > property, but the UAPI design questions seem to be much less. What's > > the best trade-off and for whom? > > By "real memory" yes I mean the 1 page. > > Using a real buffer also brings back other discussions, e.g. the one about > which pixel formats to accept. Yeah, which is why I wrote: "One can put all these limitations and even pixel format in the plane property". It doesn't even need to be a variable in the UAPI, it can be hardcoded in the UAPI doc. Please, do not understand this as me strongly advocating for the real FB approach! I just don't want that option to be misunderstood. I don't really care which design is chosen, but I do care about documenting why other designs were rejected. If the rejection reasons were false, they should be revised, even if the decision does not change. Thanks, pq pgpszxg8fCqxd.pgp Description: OpenPGP digital signature
Re: [PATCH v12 09/14] drm/msm/dp: disable self_refresh_aware after entering psr
On 30/01/2023 17:11, Vinod Polimera wrote: From: Sankeerth Billakanti Updated frames get queued if self_refresh_aware is set when the sink is in psr. To support bridge enable and avoid queuing of update frames, reset the self_refresh_aware state after entering psr. Signed-off-by: Sankeerth Billakanti Signed-off-by: Vinod Polimera --- drivers/gpu/drm/msm/dp/dp_drm.c | 25 - 1 file changed, 24 insertions(+), 1 deletion(-) As I stated in v11's discussion, I do not like the way this change plays with the self_refresh_aware. Please find another way to work around the timing issue (let's probably continue the discussion back in v11). -- With best wishes Dmitry
Re: [RESEND PATCH v11 02/18] drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper
On Mon, Jan 30, 2023 at 06:54:54PM +0530, Jagan Teki wrote: > On Mon, Jan 30, 2023 at 6:26 PM Maxime Ripard wrote: > > > > On Fri, Jan 27, 2023 at 11:09:26PM +0530, Jagan Teki wrote: > > > Hi, > > > > > > On Thu, Jan 26, 2023 at 8:48 PM Jagan Teki > > > wrote: > > > > > > > > On Thu, Jan 26, 2023 at 5:42 PM Maxime Ripard wrote: > > > > > > > > > > Hi, > > > > > > > > > > On Mon, Jan 23, 2023 at 08:41:56PM +0530, Jagan Teki wrote: > > > > > > Add devm OF helper to return the next DSI bridge in the chain. > > > > > > > > > > > > Unlike general bridge return helper devm_drm_of_get_bridge, this > > > > > > helper uses the dsi specific panel_or_bridge helper to find the > > > > > > next DSI device in the pipeline. > > > > > > > > > > > > Helper lookup a given child DSI node or a DT node's port and > > > > > > endpoint number, find the connected node and return either > > > > > > the associated struct drm_panel or drm_bridge device. > > > > > > > > > > I'm not sure that using a device managed helper is the right choice > > > > > here. The bridge will stay longer than the backing device so it will > > > > > create a use-after-free. You should probably use a DRM-managed action > > > > > here instead. > > > > > > > > Thanks for the comments. If I understand correctly we can use > > > > drmm_panel_bridge_add instead devm_drm_panel_bridge_add once we found > > > > the panel or bridge - am I correct? > > > > > > Look like it is not possible to use DRM-managed action helper here as > > > devm_drm_of_dsi_get_bridge is calling from the DSI host attach hook in > > > which we cannot find drm_device pointer (as drm_device pointer is > > > mandatory for using DRM-managed action). > > > https://github.com/openedev/kernel/blob/imx8mm-dsi-v12/drivers/gpu/drm/bridge/samsung-dsim.c#L1545 > > > > > > Please check and correct me if I mentioned any incorrect details. > > > > You shouldn't call that function from attach anyway: > > https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html#special-care-with-mipi-dsi-bridges > > True, If I remember we have bridges earlier to find the downstream > bridge/panels from the bridge ops and attach the hook, if that is the > case maybe we can use this DRM-managed action as we can get the > drm_device pointer from the bridge pointer. I'm not quite sure what you mean. You shouldn't retrieve the bridge from the attach hook but from the probe / bind ones. If that's not working for you, this is a bug in the documentation we should address. > So, what is the best we can do here, add any TODO comment to follow up > the same in the future or something else, please let me know? Make it work in a safe way, as described in the documentation? Maxime
Re: [PATCH v12 00/14] Add PSR support for eDP
On 30/01/2023 17:11, Vinod Polimera wrote: Changes in v2: - Use dp bridge to set psr entry/exit instead of dpu_enocder. - Don't modify whitespaces. - Set self refresh aware from atomic_check. - Set self refresh aware only if psr is supported. - Provide a stub for msm_dp_display_set_psr. - Move dp functions to bridge code. Changes in v3: - Change callback names to reflect atomic interfaces. - Move bridge callback change to separate patch as suggested by Dmitry. - Remove psr function declaration from msm_drv.h. - Set self_refresh_aware flag only if psr is supported. - Modify the variable names to simpler form. - Define bit fields for PSR settings. - Add comments explaining the steps to enter/exit psr. - Change DRM_INFO to drm_dbg_db. Changes in v4: - Move the get crtc functions to drm_atomic. - Add atomic functions for DP bridge too. - Add ternary operator to choose eDP or DP ops. - Return true/false instead of 1/0. - mode_valid missing in the eDP bridge ops. - Move the functions to get crtc into drm_atomic.c. - Fix compilation issues. - Remove dpu_assign_crtc and get crtc from drm_enc instead of dpu_enc. - Check for crtc state enable while reserving resources. Changes in v5: - Move the mode_valid changes into a different patch. - Complete psr_op_comp only when isr is set. - Move the DP atomic callback changes to a different patch. - Get crtc from drm connector state crtc. - Move to separate patch for check for crtc state enable while reserving resources. Changes in v6: - Remove crtc from dpu_encoder_virt struct. - fix crtc check during vblank toggle crtc. - Misc changes. Changes in v7: - Add fix for underrun issue on kasan build. Changes in v8: - Drop the enc spinlock as it won't serve any purpose in protetcing conn state.(Dmitry/Doug) Changes in v9: - Update commit message and fix alignment using spaces.(Marijn) - Misc changes.(Marijn) Changes in v10: - Get crtc cached in dpu_enc during obj init.(Dmitry) Changes in v11: - Remove crtc cached in dpu_enc during obj init. - Update dpu_enc crtc state on crtc enable/disable during self refresh. Changes in v12: - Update sc7180 intf mask to get intf timing gen status based on DPU_INTF_STATUS_SUPPORTED bit.(Dmitry) - Remove "clear active interface in the datapath cleanup" change as it is already included. - Move core changes to top of the series.(Dmitry) Unfortunately they still are not at the top. Sankeerth Billakanti (1): drm/msm/dp: disable self_refresh_aware after entering psr Vinod Polimera (13): drm/msm/disp/dpu: check for crtc enable rather than crtc active to release shared resources drm/msm/disp/dpu: get timing engine status from intf status register drm/msm/disp/dpu: wait for extra vsync till timing engine status is disabled drm/msm/disp/dpu: reset the datapath after timing engine disable drm: add helper functions to retrieve old and new crtc drm/msm/dp: use atomic callbacks for DP bridge ops drm/msm/dp: Add basic PSR support for eDP drm/msm/dp: use the eDP bridge ops to validate eDP modes drm/bridge: use atomic enable/disable callbacks for panel bridge drm/bridge: add psr support for panel bridge callbacks drm/msm/disp/dpu: use atomic enable/disable callbacks for encoder functions drm/msm/disp/dpu: add PSR support for eDP interface in dpu driver drm/msm/disp/dpu: update dpu_enc crtc state on crtc enable/disable during self refresh drivers/gpu/drm/bridge/panel.c | 68 +++- drivers/gpu/drm/drm_atomic.c | 60 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 40 - drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 26 ++- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 22 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 6 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 12 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c| 8 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 2 +- drivers/gpu/drm/msm/dp/dp_catalog.c| 80 + drivers/gpu/drm/msm/dp/dp_catalog.h| 4 + drivers/gpu/drm/msm/dp/dp_ctrl.c | 80 + drivers/gpu/drm/msm/dp/dp_ctrl.h | 3 + drivers/gpu/drm/msm/dp/dp_display.c| 36 ++-- drivers/gpu/drm/msm/dp/dp_display.h| 2 + drivers/gpu/drm/msm/dp/dp_drm.c| 194 - drivers/gpu/drm/msm/dp/dp_drm.h| 9 +- drivers/gpu/drm/msm/dp/dp_link.c | 36 drivers/gpu/drm/msm/dp/dp_panel.c | 22 +++ drivers/gpu/drm/msm/dp/dp_panel.h | 6 + drivers/gpu/drm/msm/dp/dp_reg.h| 27 +++ include/drm/drm_atomic.h | 7 + 22 files changed, 706
Re: [PATCH v12 02/14] drm/msm/disp/dpu: get timing engine status from intf status register
On 30/01/2023 17:11, Vinod Polimera wrote:
Recommended way of reading the interface timing gen status is via
status register. Timing gen status register will give a reliable status
of the interface especially during ON/OFF transitions. This support was
added from DPU version 5.0.0.
Signed-off-by: Vinod Polimera
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 6 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 12 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c| 8 +++-
3 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index cf053e8..ce6e9e6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -78,9 +78,11 @@
#define INTF_SDM845_MASK (0)
-#define INTF_SC7180_MASK BIT(DPU_INTF_INPUT_CTRL) | BIT(DPU_INTF_TE)
+#define INTF_SC7180_MASK \
+ (BIT(DPU_INTF_INPUT_CTRL) | BIT(DPU_INTF_TE) |
BIT(DPU_INTF_STATUS_SUPPORTED))
-#define INTF_SC7280_MASK INTF_SC7180_MASK | BIT(DPU_DATA_HCTL_EN)
+#define INTF_SC7280_MASK \
+ (INTF_SC7180_MASK | BIT(DPU_DATA_HCTL_EN))
Not necessary anymore.
With that fixed:
Reviewed-by: Dmitry Baryshkov
#define IRQ_SDM845_MASK (BIT(MDP_SSPP_TOP0_INTR) | \
BIT(MDP_SSPP_TOP0_INTR2) | \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index ddab9ca..08cd1a1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -213,17 +213,19 @@ enum {
/**
* INTF sub-blocks
- * @DPU_INTF_INPUT_CTRL Supports the setting of pp block from which
- * pixel data arrives to this INTF
- * @DPU_INTF_TE INTF block has TE configuration support
- * @DPU_DATA_HCTL_ENAllows data to be transferred at different rate
-than video timing
+ * @DPU_INTF_INPUT_CTRL Supports the setting of pp block from which
+ * pixel data arrives to this INTF
+ * @DPU_INTF_TE INTF block has TE configuration support
+ * @DPU_DATA_HCTL_ENAllows data to be transferred at different
rate
+ * than video timing
+ * @DPU_INTF_STATUS_SUPPORTED INTF block has INTF_STATUS register
* @DPU_INTF_MAX
*/
enum {
DPU_INTF_INPUT_CTRL = 0x1,
DPU_INTF_TE,
DPU_DATA_HCTL_EN,
+ DPU_INTF_STATUS_SUPPORTED,
DPU_INTF_MAX
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 7ce66bf..84ee2ef 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -62,6 +62,7 @@
#define INTF_LINE_COUNT 0x0B0
#define INTF_MUX 0x25C
+#define INTF_STATUS 0x26C
#define INTF_CFG_ACTIVE_H_EN BIT(29)
#define INTF_CFG_ACTIVE_V_EN BIT(30)
@@ -297,8 +298,13 @@ static void dpu_hw_intf_get_status(
struct intf_status *s)
{
struct dpu_hw_blk_reg_map *c = >hw;
+ unsigned long cap = intf->cap->features;
+
+ if (cap & BIT(DPU_INTF_STATUS_SUPPORTED))
+ s->is_en = DPU_REG_READ(c, INTF_STATUS) & BIT(0);
+ else
+ s->is_en = DPU_REG_READ(c, INTF_TIMING_ENGINE_EN);
- s->is_en = DPU_REG_READ(c, INTF_TIMING_ENGINE_EN);
s->is_prog_fetch_en = !!(DPU_REG_READ(c, INTF_CONFIG) & BIT(31));
if (s->is_en) {
s->frame_count = DPU_REG_READ(c, INTF_FRAME_COUNT);
--
With best wishes
Dmitry
Re: linux-next: manual merge of the usb tree with the drm-intel-fixes tree
On Tue, Jan 31, 2023 at 01:03:05PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the usb tree got a conflict in:
>
> drivers/gpu/drm/i915/gt/intel_engine_cs.c
>
> between commit:
>
> 5bc4b43d5c6c ("drm/i915: Fix up locking around dumping requests lists")
>
> from the drm-intel-fixes tree and commit:
>
> 4d70c74659d9 ("i915: Move list_count() to list.h as list_count_nodes() for
> broader use")
>
> from the usb tree.
>
> I fixed it up (the former removed the code changed by the latter)
Hmm... Currently I see that 20230127002842.3169194-4-john.c.harri...@intel.com
moves the code to the drivers/gpu/drm/i915/gt/intel_execlists_submission.c.
Is there any new series beside the above mentioned that touches that file and
actually _removes_ that code?
> 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.
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v2 10/27] drm/msm/dpu: pass dpu_format to _dpu_hw_sspp_setup_scaler3()
On 31/01/2023 14:10, Dmitry Baryshkov wrote:
On 31/01/2023 07:13, Abhinav Kumar wrote:
On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
There is no need to pass full dpu_hw_pipe_cfg instance to
_dpu_hw_sspp_setup_scaler3, pass just struct dpu_format pointer.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 9 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 7 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 4 ++--
3 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index f7f81ab08fa2..176cd6dc9a69 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -415,19 +415,18 @@ static void dpu_hw_sspp_setup_pe_config(struct
dpu_hw_sspp *ctx,
}
static void _dpu_hw_sspp_setup_scaler3(struct dpu_hw_sspp *ctx,
- struct dpu_hw_pipe_cfg *sspp,
- void *scaler_cfg)
+ struct dpu_hw_scaler3_cfg *scaler3_cfg,
+ const struct dpu_format *format)
{
u32 idx;
- struct dpu_hw_scaler3_cfg *scaler3_cfg = scaler_cfg;
- if (_sspp_subblk_offset(ctx, DPU_SSPP_SCALER_QSEED3, ) || !sspp
+ if (_sspp_subblk_offset(ctx, DPU_SSPP_SCALER_QSEED3, )
|| !scaler3_cfg)
Do we need to check for !format ?
We don't have since the calling sequence ensures that it is not NULL,
but let's check for it since it's a different module.
On the other hand, dpu_hw_setup_scaler3() properly handles the !format
case and programs the rest of the scaler setup. So in the end I'll skip
this check.
return;
dpu_hw_setup_scaler3(>hw, scaler3_cfg, idx,
ctx->cap->sblk->scaler_blk.version,
- sspp->layout.format);
+ format);
}
static u32 _dpu_hw_sspp_get_scaler3_ver(struct dpu_hw_sspp *ctx)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
index f5aae563741a..c713343378aa 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
@@ -317,13 +317,12 @@ struct dpu_hw_sspp_ops {
/**
* setup_scaler - setup scaler
- * @ctx: Pointer to pipe context
- * @pipe_cfg: Pointer to pipe configuration
* @scaler_cfg: Pointer to scaler configuration
This doc needs to be fixed from scaler_cfg to scaler3_cfg
+ * @format: pixel format parameters
*/
void (*setup_scaler)(struct dpu_hw_sspp *ctx,
- struct dpu_hw_pipe_cfg *pipe_cfg,
- void *scaler_cfg);
+ struct dpu_hw_scaler3_cfg *scaler3_cfg,
+ const struct dpu_format *format);
/**
* get_scaler_ver - get scaler h/w version
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 172a2c012917..cbff4dea8662 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -677,8 +677,8 @@ static void _dpu_plane_setup_scaler(struct
dpu_sw_pipe *pipe,
if (pipe_hw->ops.setup_scaler &&
pipe->multirect_index != DPU_SSPP_RECT_1)
pipe_hw->ops.setup_scaler(pipe_hw,
- pipe_cfg,
- _cfg);
+ _cfg,
+ fmt);
}
/**
--
With best wishes
Dmitry
Re: [PATCH v2 10/27] drm/msm/dpu: pass dpu_format to _dpu_hw_sspp_setup_scaler3()
On 31/01/2023 07:13, Abhinav Kumar wrote:
On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
There is no need to pass full dpu_hw_pipe_cfg instance to
_dpu_hw_sspp_setup_scaler3, pass just struct dpu_format pointer.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 9 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 7 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 4 ++--
3 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index f7f81ab08fa2..176cd6dc9a69 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -415,19 +415,18 @@ static void dpu_hw_sspp_setup_pe_config(struct
dpu_hw_sspp *ctx,
}
static void _dpu_hw_sspp_setup_scaler3(struct dpu_hw_sspp *ctx,
- struct dpu_hw_pipe_cfg *sspp,
- void *scaler_cfg)
+ struct dpu_hw_scaler3_cfg *scaler3_cfg,
+ const struct dpu_format *format)
{
u32 idx;
- struct dpu_hw_scaler3_cfg *scaler3_cfg = scaler_cfg;
- if (_sspp_subblk_offset(ctx, DPU_SSPP_SCALER_QSEED3, ) || !sspp
+ if (_sspp_subblk_offset(ctx, DPU_SSPP_SCALER_QSEED3, )
|| !scaler3_cfg)
Do we need to check for !format ?
We don't have since the calling sequence ensures that it is not NULL,
but let's check for it since it's a different module.
return;
dpu_hw_setup_scaler3(>hw, scaler3_cfg, idx,
ctx->cap->sblk->scaler_blk.version,
- sspp->layout.format);
+ format);
}
static u32 _dpu_hw_sspp_get_scaler3_ver(struct dpu_hw_sspp *ctx)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
index f5aae563741a..c713343378aa 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
@@ -317,13 +317,12 @@ struct dpu_hw_sspp_ops {
/**
* setup_scaler - setup scaler
- * @ctx: Pointer to pipe context
- * @pipe_cfg: Pointer to pipe configuration
* @scaler_cfg: Pointer to scaler configuration
This doc needs to be fixed from scaler_cfg to scaler3_cfg
+ * @format: pixel format parameters
*/
void (*setup_scaler)(struct dpu_hw_sspp *ctx,
- struct dpu_hw_pipe_cfg *pipe_cfg,
- void *scaler_cfg);
+ struct dpu_hw_scaler3_cfg *scaler3_cfg,
+ const struct dpu_format *format);
/**
* get_scaler_ver - get scaler h/w version
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 172a2c012917..cbff4dea8662 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -677,8 +677,8 @@ static void _dpu_plane_setup_scaler(struct
dpu_sw_pipe *pipe,
if (pipe_hw->ops.setup_scaler &&
pipe->multirect_index != DPU_SSPP_RECT_1)
pipe_hw->ops.setup_scaler(pipe_hw,
- pipe_cfg,
- _cfg);
+ _cfg,
+ fmt);
}
/**
--
With best wishes
Dmitry
Re: [PATCH] drivers: Restore alignment and newline in Makefile
On Tue, Jan 24, 2023 at 12:42 PM Geert Uytterhoeven
wrote:
>
> The introduction of drivers/accel/ broke alignment, and removed the
> newline at the end of the file. Fix all of that.
>
> Fixes: 35b137630f08d913 ("accel/ivpu: Introduce a new DRM driver for Intel
> VPU")
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/Makefile b/drivers/Makefile
> index f0972e2226c97cb5..9ea6eb3b5d7b7f17 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -189,4 +189,4 @@ obj-$(CONFIG_COUNTER) += counter/
> obj-$(CONFIG_MOST) += most/
> obj-$(CONFIG_PECI) += peci/
> obj-$(CONFIG_HTE) += hte/
> -obj-$(CONFIG_DRM_ACCEL)+= accel/
> \ No newline at end of file
> +obj-$(CONFIG_DRM_ACCEL)+= accel/
> --
> 2.34.1
>
Reviewed-by: Oded Gabbay
Re: [PATCH] drivers: Restore alignment and newline in Makefile
On Tue, Jan 24, 2023 at 11:41:45AM +0100, Geert Uytterhoeven wrote:
> The introduction of drivers/accel/ broke alignment, and removed the
> newline at the end of the file. Fix all of that.
>
> Fixes: 35b137630f08d913 ("accel/ivpu: Introduce a new DRM driver for Intel
> VPU")
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/Makefile b/drivers/Makefile
> index f0972e2226c97cb5..9ea6eb3b5d7b7f17 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -189,4 +189,4 @@ obj-$(CONFIG_COUNTER) += counter/
> obj-$(CONFIG_MOST) += most/
> obj-$(CONFIG_PECI) += peci/
> obj-$(CONFIG_HTE)+= hte/
> -obj-$(CONFIG_DRM_ACCEL) += accel/
> \ No newline at end of file
> +obj-$(CONFIG_DRM_ACCEL) += accel/
> --
> 2.34.1
>
Acked-by: Greg Kroah-Hartman
Re: [PATCH v2 06/27] drm/msm/dpu: move pipe_hw to dpu_plane_state
On 30/01/2023 23:51, Abhinav Kumar wrote:
On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
In preparation to adding fully virtualized planes, move struct
dpu_hw_sspp instance from struct dpu_plane to struct dpu_plane_state, as
it will become a part of state (allocated during atomic check) rather
than part of a plane (allocated during boot).
I was thinking about a couple of things about this patch:
1) Since we are moving away from using "pipe" and using "sspp", perhaps
we can rename pipe_hw to hw_sspp in the below struct
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
@@ -35,6 +35,8 @@ struct dpu_plane_state {
uint32_t multirect_mode;
bool pending;
+ struct dpu_hw_pipe *hw_sspp;
+
Ack
u64 plane_fetch_bw;
u64 plane_clk;
};
2) I still dont see any comment as promised in v1 about why we are doing
this in dpu_plane_reset().
https://patchwork.freedesktop.org/patch/473155/?series=99909=1#comment_875365
I think what we need to mention is that the dpu_plane_reset() is the one
which allocates the plane state today and hence pipe_hw can only be
assigned there.
Ack
Rest LGTM.
--
With best wishes
Dmitry
Re: [RFC PATCH v3 0/3] Support for Solid Fill Planes
On Tuesday, January 31st, 2023 at 12:13, Pekka Paalanen wrote: > On Tue, 31 Jan 2023 10:06:39 + > Simon Ser wrote: > > > On Tuesday, January 31st, 2023 at 10:25, Pekka Paalanen > > wrote: > > > > > indeed, what about simply using a 1x1 framebuffer for real? Why was that > > > approach rejected? > > > > Ideally we don't want to allocate any GPU memory for the solid-fill > > stuff. And if we special-case 1x1 FB creation to not be backed by real > > GPU memory then we hit several situations where user-space expects a > > real FB but there isn't: for instance, GETFB2 converts from FB object > > ID to GEM handles. Even if we make GETFB2 fail and accept that this > > breaks user-space, then there is no way for user-space to recover the > > FB color for flicker-free transitions and such. > > > > This is all purely from a uAPI PoV, completely ignoring the potential > > issues with the internal kernel abstractions which might not be suitable > > for this either. > > I mean a real 1x1 buffer: a dumb buffer. > > It would be absolutely compatible with anything existing, because it is > a real FB. As a dumb buffer it would be trivial to write into and read > out. As 1x1 it would be tiny (one page?). Even if something needs to > raw-access uncached memory over 33 MHz PCI bus or whatever the worst > case is, it's just one pixel, so it's fast enough, right? And it only > needs to be read once when set, like USB display drivers do. The driver > does not need to manually apply any color operations, because none are > supported in this special case. > > One can put all these limitations and even pixel format in the plane > property that tells userspace that a 1x1 FB works here. > > To recap, the other alternatives under discussion I see right now are: > > - this proposal of dedicated fill color property > - stuffing something new into FB_ID property > > There is also the question of other kinds of plane content sources like > live camera feeds where userspace won't be shovelling each frame > individually like we do now. > > 1x1 dumb buffer is not as small and lean as a dedicated fill color > property, but the UAPI design questions seem to be much less. What's > the best trade-off and for whom? By "real memory" yes I mean the 1 page. Using a real buffer also brings back other discussions, e.g. the one about which pixel formats to accept.
Re: [PATCH v2 02/27] drm/msm/dpu: rename struct dpu_hw_pipe to dpu_hw_sspp
On 27/01/2023 00:55, Abhinav Kumar wrote:
On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
For all hardware blocks except SSPP the corresponding struct is named
after the block. Rename dpu_hw_pipe (SSPP structure) to dpu_hw_sspp.
Signed-off-by: Dmitry Baryshkov
Idea seems okay but then we should also rename dpu_hw_pipe_cfg to
dpu_hw_sspp_cfg.
I'll have to think about it. I ended up reusing the dpu_hw_pipe_cfg to
describe a single rectangle configuration (iow, one for rect0, one for
rect1). Let me check if I can make it more obvious.
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 42 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 42 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 2 +-
3 files changed, 43 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index 691c471b08c2..93f01f767fd8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -136,7 +136,7 @@
#define TS_CLK 1920
-static int _sspp_subblk_offset(struct dpu_hw_pipe *ctx,
+static int _sspp_subblk_offset(struct dpu_hw_sspp *ctx,
int s_id,
u32 *idx)
{
@@ -168,7 +168,7 @@ static int _sspp_subblk_offset(struct dpu_hw_pipe
*ctx,
return rc;
}
-static void dpu_hw_sspp_setup_multirect(struct dpu_hw_pipe *ctx,
+static void dpu_hw_sspp_setup_multirect(struct dpu_hw_sspp *ctx,
enum dpu_sspp_multirect_index index,
enum dpu_sspp_multirect_mode mode)
{
@@ -197,7 +197,7 @@ static void dpu_hw_sspp_setup_multirect(struct
dpu_hw_pipe *ctx,
DPU_REG_WRITE(>hw, SSPP_MULTIRECT_OPMODE + idx, mode_mask);
}
-static void _sspp_setup_opmode(struct dpu_hw_pipe *ctx,
+static void _sspp_setup_opmode(struct dpu_hw_sspp *ctx,
u32 mask, u8 en)
{
u32 idx;
@@ -218,7 +218,7 @@ static void _sspp_setup_opmode(struct dpu_hw_pipe
*ctx,
DPU_REG_WRITE(>hw, SSPP_VIG_OP_MODE + idx, opmode);
}
-static void _sspp_setup_csc10_opmode(struct dpu_hw_pipe *ctx,
+static void _sspp_setup_csc10_opmode(struct dpu_hw_sspp *ctx,
u32 mask, u8 en)
{
u32 idx;
@@ -239,7 +239,7 @@ static void _sspp_setup_csc10_opmode(struct
dpu_hw_pipe *ctx,
/*
* Setup source pixel format, flip,
*/
-static void dpu_hw_sspp_setup_format(struct dpu_hw_pipe *ctx,
+static void dpu_hw_sspp_setup_format(struct dpu_hw_sspp *ctx,
const struct dpu_format *fmt, u32 flags,
enum dpu_sspp_multirect_index rect_mode)
{
@@ -356,7 +356,7 @@ static void dpu_hw_sspp_setup_format(struct
dpu_hw_pipe *ctx,
DPU_REG_WRITE(c, SSPP_UBWC_ERROR_STATUS + idx, BIT(31));
}
-static void dpu_hw_sspp_setup_pe_config(struct dpu_hw_pipe *ctx,
+static void dpu_hw_sspp_setup_pe_config(struct dpu_hw_sspp *ctx,
struct dpu_hw_pixel_ext *pe_ext)
{
struct dpu_hw_blk_reg_map *c;
@@ -414,7 +414,7 @@ static void dpu_hw_sspp_setup_pe_config(struct
dpu_hw_pipe *ctx,
tot_req_pixels[3]);
}
-static void _dpu_hw_sspp_setup_scaler3(struct dpu_hw_pipe *ctx,
+static void _dpu_hw_sspp_setup_scaler3(struct dpu_hw_sspp *ctx,
struct dpu_hw_pipe_cfg *sspp,
void *scaler_cfg)
{
@@ -430,7 +430,7 @@ static void _dpu_hw_sspp_setup_scaler3(struct
dpu_hw_pipe *ctx,
sspp->layout.format);
}
-static u32 _dpu_hw_sspp_get_scaler3_ver(struct dpu_hw_pipe *ctx)
+static u32 _dpu_hw_sspp_get_scaler3_ver(struct dpu_hw_sspp *ctx)
{
u32 idx;
@@ -443,7 +443,7 @@ static u32 _dpu_hw_sspp_get_scaler3_ver(struct
dpu_hw_pipe *ctx)
/*
* dpu_hw_sspp_setup_rects()
*/
-static void dpu_hw_sspp_setup_rects(struct dpu_hw_pipe *ctx,
+static void dpu_hw_sspp_setup_rects(struct dpu_hw_sspp *ctx,
struct dpu_hw_pipe_cfg *cfg,
enum dpu_sspp_multirect_index rect_index)
{
@@ -512,7 +512,7 @@ static void dpu_hw_sspp_setup_rects(struct
dpu_hw_pipe *ctx,
DPU_REG_WRITE(c, SSPP_SRC_YSTRIDE1 + idx, ystride1);
}
-static void dpu_hw_sspp_setup_sourceaddress(struct dpu_hw_pipe *ctx,
+static void dpu_hw_sspp_setup_sourceaddress(struct dpu_hw_sspp *ctx,
struct dpu_hw_pipe_cfg *cfg,
enum dpu_sspp_multirect_index rect_mode)
{
@@ -539,7 +539,7 @@ static void dpu_hw_sspp_setup_sourceaddress(struct
dpu_hw_pipe *ctx,
}
}
-static void dpu_hw_sspp_setup_csc(struct dpu_hw_pipe *ctx,
+static void dpu_hw_sspp_setup_csc(struct dpu_hw_sspp *ctx,
const struct dpu_csc_cfg *data)
{
u32 idx;
@@ -556,7 +556,7 @@ static void dpu_hw_sspp_setup_csc(struct
dpu_hw_pipe *ctx,
dpu_hw_csc_setup(>hw, idx, data, csc10);
}
-static void dpu_hw_sspp_setup_solidfill(struct dpu_hw_pipe *ctx, u32
color, enum
+static void dpu_hw_sspp_setup_solidfill(struct dpu_hw_sspp *ctx, u32
color, enum
dpu_sspp_multirect_index rect_index)
{
u32 idx;
@@ -571,7 +571,7 @@ static void
Re: [RFC PATCH v3 0/3] Support for Solid Fill Planes
On Tue, 31 Jan 2023 10:06:39 + Simon Ser wrote: > On Tuesday, January 31st, 2023 at 10:25, Pekka Paalanen > wrote: > > > indeed, what about simply using a 1x1 framebuffer for real? Why was that > > approach rejected? > > Ideally we don't want to allocate any GPU memory for the solid-fill > stuff. And if we special-case 1x1 FB creation to not be backed by real > GPU memory then we hit several situations where user-space expects a > real FB but there isn't: for instance, GETFB2 converts from FB object > ID to GEM handles. Even if we make GETFB2 fail and accept that this > breaks user-space, then there is no way for user-space to recover the > FB color for flicker-free transitions and such. > > This is all purely from a uAPI PoV, completely ignoring the potential > issues with the internal kernel abstractions which might not be suitable > for this either. I mean a real 1x1 buffer: a dumb buffer. It would be absolutely compatible with anything existing, because it is a real FB. As a dumb buffer it would be trivial to write into and read out. As 1x1 it would be tiny (one page?). Even if something needs to raw-access uncached memory over 33 MHz PCI bus or whatever the worst case is, it's just one pixel, so it's fast enough, right? And it only needs to be read once when set, like USB display drivers do. The driver does not need to manually apply any color operations, because none are supported in this special case. One can put all these limitations and even pixel format in the plane property that tells userspace that a 1x1 FB works here. To recap, the other alternatives under discussion I see right now are: - this proposal of dedicated fill color property - stuffing something new into FB_ID property There is also the question of other kinds of plane content sources like live camera feeds where userspace won't be shovelling each frame individually like we do now. 1x1 dumb buffer is not as small and lean as a dedicated fill color property, but the UAPI design questions seem to be much less. What's the best trade-off and for whom? Thanks, pq pgp3vQ9YxUOiq.pgp Description: OpenPGP digital signature
