[PATCH linux-next] drm/i915/ddi: use string choice helpers
Use str_enabled_disabled string helpers for better readability and to fix cocci warning. Reported-by: kernel test robot Reported-by: Julia Lawall Closes: https://lore.kernel.org/r/202410071601.tfpxoqgw-...@intel.com/ Signed-off-by: R Sundar --- Reported in linux repo: tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master cocci warnings: (new ones prefixed by >>) >> drivers/gpu/drm/i915/display/intel_ddi.c:2225:7-13: opportunity for >> str_enabled_disabled(enable) vim +2225 drivers/gpu/drm/i915/display/intel_ddi.c compile tested only. drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index fe1ded6707f9..ff4c633c8546 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -2236,7 +2236,7 @@ static void intel_dp_sink_set_fec_ready(struct intel_dp *intel_dp, if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_FEC_CONFIGURATION, enable ? DP_FEC_READY : 0) <= 0) drm_dbg_kms(display->drm, "Failed to set FEC_READY to %s in the sink\n", - enable ? "enabled" : "disabled"); + str_enabled_disabled(enable)); if (enable && drm_dp_dpcd_writeb(&intel_dp->aux, DP_FEC_STATUS, -- 2.34.1
Patch "firmware/sysfb: Disable sysfb for firmware buffers with unknown parent" has been added to the 6.10-stable tree
This is a note to let you know that I've just added the patch titled
firmware/sysfb: Disable sysfb for firmware buffers with unknown parent
to the 6.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
firmware-sysfb-disable-sysfb-for-firmware-buffers-with-unknown-parent.patch
and it can be found in the queue-6.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From ad604f0a4c040dcb8faf44dc72db25e457c28076 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Tue, 24 Sep 2024 10:41:03 +0200
Subject: firmware/sysfb: Disable sysfb for firmware buffers with unknown parent
From: Thomas Zimmermann
commit ad604f0a4c040dcb8faf44dc72db25e457c28076 upstream.
The sysfb framebuffer handling only operates on graphics devices
that provide the system's firmware framebuffer. If that device is
not known, assume that any graphics device has been initialized by
firmware.
Fixes a problem on i915 where sysfb does not release the firmware
framebuffer after the native graphics driver loaded.
Reported-by: Borah, Chaitanya Kumar
Closes:
https://lore.kernel.org/dri-devel/sj1pr11mb6129efb8ce63d1ef6d932f94b9...@sj1pr11mb6129.namprd11.prod.outlook.com/
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12160
Signed-off-by: Thomas Zimmermann
Fixes: b49420d6a1ae ("video/aperture: optionally match the device in
sysfb_disable()")
Cc: Javier Martinez Canillas
Cc: Thomas Zimmermann
Cc: Helge Deller
Cc: Sam Ravnborg
Cc: Daniel Vetter
Cc: Alex Deucher
Cc: dri-devel@lists.freedesktop.org
Cc: Linux regression tracking (Thorsten Leemhuis)
Cc: # v6.11+
Acked-by: Alex Deucher
Reviewed-by: Javier Martinez Canillas
Link:
https://patchwork.freedesktop.org/patch/msgid/20240924084227.262271-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/firmware/sysfb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/sysfb.c b/drivers/firmware/sysfb.c
index 02a07d3d0d40..a3df782fa687 100644
--- a/drivers/firmware/sysfb.c
+++ b/drivers/firmware/sysfb.c
@@ -67,9 +67,11 @@ static bool sysfb_unregister(void)
void sysfb_disable(struct device *dev)
{
struct screen_info *si = &screen_info;
+ struct device *parent;
mutex_lock(&disable_lock);
- if (!dev || dev == sysfb_parent_dev(si)) {
+ parent = sysfb_parent_dev(si);
+ if (!dev || !parent || dev == parent) {
sysfb_unregister();
disabled = true;
}
--
2.46.2
Patches currently in stable-queue which might be from tzimmerm...@suse.de are
queue-6.10/firmware-sysfb-disable-sysfb-for-firmware-buffers-with-unknown-parent.patch
queue-6.10/drm-consistently-use-struct-drm_mode_rect-for-fb_damage_clips.patch
Patch "firmware/sysfb: Disable sysfb for firmware buffers with unknown parent" has been added to the 6.11-stable tree
This is a note to let you know that I've just added the patch titled
firmware/sysfb: Disable sysfb for firmware buffers with unknown parent
to the 6.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
firmware-sysfb-disable-sysfb-for-firmware-buffers-with-unknown-parent.patch
and it can be found in the queue-6.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From ad604f0a4c040dcb8faf44dc72db25e457c28076 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Tue, 24 Sep 2024 10:41:03 +0200
Subject: firmware/sysfb: Disable sysfb for firmware buffers with unknown parent
From: Thomas Zimmermann
commit ad604f0a4c040dcb8faf44dc72db25e457c28076 upstream.
The sysfb framebuffer handling only operates on graphics devices
that provide the system's firmware framebuffer. If that device is
not known, assume that any graphics device has been initialized by
firmware.
Fixes a problem on i915 where sysfb does not release the firmware
framebuffer after the native graphics driver loaded.
Reported-by: Borah, Chaitanya Kumar
Closes:
https://lore.kernel.org/dri-devel/sj1pr11mb6129efb8ce63d1ef6d932f94b9...@sj1pr11mb6129.namprd11.prod.outlook.com/
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12160
Signed-off-by: Thomas Zimmermann
Fixes: b49420d6a1ae ("video/aperture: optionally match the device in
sysfb_disable()")
Cc: Javier Martinez Canillas
Cc: Thomas Zimmermann
Cc: Helge Deller
Cc: Sam Ravnborg
Cc: Daniel Vetter
Cc: Alex Deucher
Cc: dri-devel@lists.freedesktop.org
Cc: Linux regression tracking (Thorsten Leemhuis)
Cc: # v6.11+
Acked-by: Alex Deucher
Reviewed-by: Javier Martinez Canillas
Link:
https://patchwork.freedesktop.org/patch/msgid/20240924084227.262271-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/firmware/sysfb.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/firmware/sysfb.c
+++ b/drivers/firmware/sysfb.c
@@ -67,9 +67,11 @@ static bool sysfb_unregister(void)
void sysfb_disable(struct device *dev)
{
struct screen_info *si = &screen_info;
+ struct device *parent;
mutex_lock(&disable_lock);
- if (!dev || dev == sysfb_parent_dev(si)) {
+ parent = sysfb_parent_dev(si);
+ if (!dev || !parent || dev == parent) {
sysfb_unregister();
disabled = true;
}
Patches currently in stable-queue which might be from tzimmerm...@suse.de are
queue-6.11/firmware-sysfb-disable-sysfb-for-firmware-buffers-with-unknown-parent.patch
queue-6.11/drm-consistently-use-struct-drm_mode_rect-for-fb_damage_clips.patch
Re: [PATCH v3 04/14] drm/mediatek: Fix XRGB setting error in Mixer
> Although the alpha channel in XRGB formats can be ignored, ALPHA_CON > must be configured accordingly when using XRGB formats or it will still > affects CRC generation. affect? Can such a change description become a bit nicer with an additional imperative wording? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.12-rc2#n94 Regards, Markus
Re: [PATCH 2/2] drm/amdgpu: Use drm_print_memory_stats helper from fdinfo
Applied the series. Thanks!
Alex
On Thu, May 30, 2024 at 6:20 AM Tvrtko Ursulin
wrote:
>
>
> Hi,
>
> On 20/05/2024 12:13, Tvrtko Ursulin wrote:
> > From: Tvrtko Ursulin
> >
> > Convert fdinfo memory stats to use the common drm_print_memory_stats
> > helper.
> >
> > This achieves alignment with the common keys as documented in
> > drm-usage-stats.rst, adding specifically drm-total- key the driver was
> > missing until now.
> >
> > Additionally I made the code stop skipping total size for objects which
> > currently do not have a backing store, and I added resident, active and
> > purgeable reporting.
> >
> > Legacy keys have been preserved, with the outlook of only potentially
> > removing only the drm-memory- when the time gets right.
> >
> > The example output now looks like this:
> >
> > pos:0
> > flags: 0212
> > mnt_id: 24
> > ino:1239
> > drm-driver: amdgpu
> > drm-client-id: 4
> > drm-pdev: :04:00.0
> > pasid: 32771
> > drm-total-cpu: 0
> > drm-shared-cpu: 0
> > drm-active-cpu: 0
> > drm-resident-cpu: 0
> > drm-purgeable-cpu: 0
> > drm-total-gtt: 2392 KiB
> > drm-shared-gtt: 0
> > drm-active-gtt: 0
> > drm-resident-gtt: 2392 KiB
> > drm-purgeable-gtt: 0
> > drm-total-vram: 44564 KiB
> > drm-shared-vram:31952 KiB
> > drm-active-vram:0
> > drm-resident-vram: 44564 KiB
> > drm-purgeable-vram: 0
> > drm-memory-vram:44564 KiB
> > drm-memory-gtt: 2392 KiB
> > drm-memory-cpu: 0 KiB
> > amd-memory-visible-vram:44564 KiB
> > amd-evicted-vram: 0 KiB
> > amd-evicted-visible-vram: 0 KiB
> > amd-requested-vram: 44564 KiB
> > amd-requested-visible-vram: 11952 KiB
> > amd-requested-gtt: 2392 KiB
> > drm-engine-compute: 46464671 ns
> >
> > v2:
> > * Track purgeable via AMDGPU_GEM_CREATE_DISCARDABLE.
>
> Any interest on this work from AMD side? As a summary it adds active and
> purgeable reporting and converts to using the drm_print_memory_stats
> helper for outputting all the fields as documented in drm-usage-stats.rst.
>
> Regards,
>
> Tvrtko
>
> >
> > Signed-off-by: Tvrtko Ursulin
> > Cc: Alex Deucher
> > Cc: Christian König
> > Cc: Daniel Vetter
> > Cc: Rob Clark
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 48 +++
> > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 96 +++---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 35 +++-
> > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h| 1 +
> > drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 20 +++--
> > drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 3 +-
> > 6 files changed, 122 insertions(+), 81 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> > index c7df7fa3459f..00a4ab082459 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> > @@ -59,18 +59,21 @@ void amdgpu_show_fdinfo(struct drm_printer *p, struct
> > drm_file *file)
> > struct amdgpu_fpriv *fpriv = file->driver_priv;
> > struct amdgpu_vm *vm = &fpriv->vm;
> >
> > - struct amdgpu_mem_stats stats;
> > + struct amdgpu_mem_stats stats[__AMDGPU_PL_LAST + 1] = { };
> > ktime_t usage[AMDGPU_HW_IP_NUM];
> > - unsigned int hw_ip;
> > + const char *pl_name[] = {
> > + [TTM_PL_VRAM] = "vram",
> > + [TTM_PL_TT] = "gtt",
> > + [TTM_PL_SYSTEM] = "cpu",
> > + };
> > + unsigned int hw_ip, i;
> > int ret;
> >
> > - memset(&stats, 0, sizeof(stats));
> > -
> > ret = amdgpu_bo_reserve(vm->root.bo, false);
> > if (ret)
> > return;
> >
> > - amdgpu_vm_get_memory(vm, &stats);
> > + amdgpu_vm_get_memory(vm, stats, ARRAY_SIZE(stats));
> > amdgpu_bo_unreserve(vm->root.bo);
> >
> > amdgpu_ctx_mgr_usage(&fpriv->ctx_mgr, usage);
> > @@ -82,24 +85,35 @@ void amdgpu_show_fdinfo(struct drm_printer *p, struct
> > drm_file *file)
> >*/
> >
> > drm_printf(p, "pasid:\t%u\n", fpriv->vm.pasid);
> > - drm_printf(p, "drm-memory-vram:\t%llu KiB\n", stats.vram/1024UL);
> > - drm_printf(p, "drm-memory-gtt: \t%llu KiB\n", stats.gtt/1024UL);
> > - drm_printf(p, "drm-memory-cpu: \t%llu KiB\n", stats.cpu/1024UL);
> > +
> > + for (i = 0; i < TTM_PL_PRIV; i++)
> > + drm_print_memory_stats(p,
> > +&stats[i].drm,
> > +DRM_GEM_OBJECT_RESIDENT |
> > +DRM_GEM_OBJECT_PURGEABLE,
> > +pl_name[i]);
> > +
> > + /* Legacy amdgpu keys, alias to drm-resident-memory-: */
> > + drm_printf(p, "drm-memory-vram:\t%llu KiB\n",
> > +stats[TTM_PL_VRAM].total/1024UL);
> > + drm_printf(p, "drm-memory-gtt: \t%llu KiB\n",
> > +stats[TTM_PL_TT].total/1024
Re: [PATCH v6 3/5] drm: handle HAS_IOPORT dependencies
On Mon, Oct 07, 2024 at 01:40:21PM +0200, Niklas Schnelle wrote: In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at compile time. We thus need to add HAS_IOPORT as dependency for those drivers using them. In the bochs driver there is optional MMIO support detected at runtime, warn if this isn't taken when HAS_IOPORT is not defined. There is also a direct and hard coded use in cirrus.c which according to the comment is only necessary during resume. Let's just skip this as for example s390 which doesn't have I/O port support also doesen't support suspend/resume. Co-developed-by: Arnd Bergmann Signed-off-by: Arnd Bergmann Signed-off-by: Niklas Schnelle --- drivers/gpu/drm/gma500/Kconfig | 2 +- drivers/gpu/drm/qxl/Kconfig| 1 + drivers/gpu/drm/tiny/bochs.c | 17 + drivers/gpu/drm/tiny/cirrus.c | 2 ++ drivers/gpu/drm/xe/Kconfig | 2 +- as an example: $ git grep -lw outb -- drivers/gpu/drm/ drivers/gpu/drm/gma500/cdv_device.c drivers/gpu/drm/i915/display/intel_vga.c drivers/gpu/drm/qxl/qxl_cmd.c drivers/gpu/drm/qxl/qxl_irq.c drivers/gpu/drm/tiny/bochs.c drivers/gpu/drm/tiny/cirrus.c you are adding the dependency on xe, but why are you keeping i915 out? What approach did you use to determine the dependency? Lucas De Marchi
Re: [PATCH v3 13/14] drm/mediatek: Support DRM plane alpha in OVL
Re: [PATCH v5 0/2] Basic support for TI TDP158
On 03/09/2024 14:40, Robert Foss wrote: > On Mon, 12 Aug 2024 16:51:00 +0200, Marc Gonzalez wrote: > >> TDP158 is an AC-coupled DVI / HDMI to TMDS level shifting Redriver. >> >> Like the TFP410, the TDP158 can be set up in 2 different ways: >> 1) hard-coding its configuration settings using pin-strapping resistors >> 2) placing it on an I2C bus, and defer set-up until run-time >> >> The mode is selected by pin 8 = I2C_EN >> I2C_EN = 1 ==> I2C Control Mode >> I2C_EN = 0 ==> Pin Strap Mode >> >> [...] > > Applied, thanks! > > [1/2] dt-bindings: display: bridge: add TI TDP158 > https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/887665792b99 > [2/2] drm/bridge: add support for TI TDP158 > https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/a15710027afb Hello Robert, I expected this series to be included in v6.12-rc1, since you applied it before the v6.12 merge window opened. Did I misunderstand the process? If not in v6.12, does that mean it will be in v6.13? Regards
Re: [PATCH v5 0/2] Basic support for TI TDP158
On Mon, 7 Oct 2024 at 16:33, Marc Gonzalez wrote: > > On 03/09/2024 14:40, Robert Foss wrote: > > > On Mon, 12 Aug 2024 16:51:00 +0200, Marc Gonzalez wrote: > > > >> TDP158 is an AC-coupled DVI / HDMI to TMDS level shifting Redriver. > >> > >> Like the TFP410, the TDP158 can be set up in 2 different ways: > >> 1) hard-coding its configuration settings using pin-strapping resistors > >> 2) placing it on an I2C bus, and defer set-up until run-time > >> > >> The mode is selected by pin 8 = I2C_EN > >> I2C_EN = 1 ==> I2C Control Mode > >> I2C_EN = 0 ==> Pin Strap Mode > >> > >> [...] > > > > Applied, thanks! > > > > [1/2] dt-bindings: display: bridge: add TI TDP158 > > https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/887665792b99 > > [2/2] drm/bridge: add support for TI TDP158 > > https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/a15710027afb > > Hello Robert, > > I expected this series to be included in v6.12-rc1, since you applied it > before the v6.12 merge window opened. Did I misunderstand the process? drm-misc-next stops propagating new changes to drm-next one or two weeks before the release. > If not in v6.12, does that mean it will be in v6.13? Yes. -- With best wishes Dmitry
[PATCH v9 0/7] Improve the copy of task comm
Using {memcpy,strncpy,strcpy,kstrdup} to copy the task comm relies on the
length of task comm. Changes in the task comm could result in a destination
string that is overflow. Therefore, we should explicitly ensure the
destination string is always NUL-terminated, regardless of the task comm.
This approach will facilitate future extensions to the task comm.
As suggested by Linus [0], we can identify all relevant code with the
following git grep command:
git grep 'memcpy.*->comm\>'
git grep 'kstrdup.*->comm\>'
git grep 'strncpy.*->comm\>'
git grep 'strcpy.*->comm\>'
PATCH #2~#4: memcpy
PATCH #5~#6: kstrdup
PATCH #7: strcpy
Please note that strncpy() is not included in this series as it is being
tracked by another effort. [1]
task_lock() is removed from get_task_comm() as it is unnecessary.
Suggested-by: Linus Torvalds
Link:
https://lore.kernel.org/all/CAHk-=wjAmmHUg6vho1KjzQi2=psr30+cogfd4axrthr2gsi...@mail.gmail.com/
[0]
Changes:
v8->v9:
- Keep the BUILD_BUG_ON() in get_task_comm() (Kees)
- Keep strscpy_pad() in get_task_comm() (Kees)
- Replace more strcpy() with strscpy() in
drivers/gpu/drm/i915/i915_gpu_error.c (Justin)
- Fix typos and commit improvement in patch #5 (Andy)
- Drop the change in net as it was fixed by
b19f69a95830 ("net/ipv6: replace deprecated strcpy with strscpy")
v7->v8: https://lore.kernel.org/all/20240828030321.20688-1-laoar.s...@gmail.com/
- Avoid '+1' and '-1' in string copy. (Alejandro)
v6->v7: https://lore.kernel.org/all/20240817025624.13157-1-laoar.s...@gmail.com/
- Improve the comment (Alejandro)
- Drop strncpy as it is being tracked by another effort (Justin)
https://github.com/KSPP/linux/issues/90 [1]
v5->v6:
https://lore.kernel.org/linux-mm/20240812022933.69850-1-laoar.s...@gmail.com/
- Get rid of __get_task_comm() (Linus)
- Use ARRAY_SIZE() in get_task_comm() (Alejandro)
v4->v5: https://lore.kernel.org/all/20240804075619.20804-1-laoar.s...@gmail.com/
- Drop changes in the mm/kmemleak.c as it was fixed by
commit 0b84780134fb ("mm/kmemleak: replace strncpy() with strscpy()")
- Drop changes in kernel/tsacct.c as it was fixed by
commit 0fe2356434e ("tsacct: replace strncpy() with strscpy()")
v3->v4:
https://lore.kernel.org/linux-mm/20240729023719.1933-1-laoar.s...@gmail.com/
- Rename __kstrndup() to __kmemdup_nul() and define it inside mm/util.c
(Matthew)
- Remove unused local variable (Simon)
v2->v3: https://lore.kernel.org/all/20240621022959.9124-1-laoar.s...@gmail.com/
- Deduplicate code around kstrdup (Andrew)
- Add commit log for dropping task_lock (Catalin)
v1->v2: https://lore.kernel.org/bpf/20240613023044.45873-1-laoar.s...@gmail.com/
- Add comment for dropping task_lock() in __get_task_comm() (Alexei)
- Drop changes in trace event (Steven)
- Fix comment on task comm (Matus)
v1: https://lore.kernel.org/all/20240602023754.25443-1-laoar.s...@gmail.com/
Yafang Shao (7):
Get rid of __get_task_comm()
auditsc: Replace memcpy() with strscpy()
security: Replace memcpy() with get_task_comm()
bpftool: Ensure task comm is always NUL-terminated
mm/util: Fix possible race condition in kstrdup()
mm/util: Deduplicate code in {kstrdup,kstrndup,kmemdup_nul}
drm: Replace strcpy() with strscpy()
drivers/gpu/drm/drm_framebuffer.c | 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 6 +--
fs/exec.c | 10 -
fs/proc/array.c | 2 +-
include/linux/sched.h | 28 +---
kernel/auditsc.c | 6 +--
kernel/kthread.c | 2 +-
mm/util.c | 62 ---
security/lsm_audit.c | 4 +-
security/selinux/selinuxfs.c | 2 +-
tools/bpf/bpftool/pids.c | 2 +
11 files changed, 63 insertions(+), 63 deletions(-)
--
2.43.5
[PATCH v9 1/7] Get rid of __get_task_comm()
We want to eliminate the use of __get_task_comm() for the following
reasons:
- The task_lock() is unnecessary
Quoted from Linus [0]:
: Since user space can randomly change their names anyway, using locking
: was always wrong for readers (for writers it probably does make sense
: to have some lock - although practically speaking nobody cares there
: either, but at least for a writer some kind of race could have
: long-term mixed results
Suggested-by: Linus Torvalds
Link:
https://lore.kernel.org/all/CAHk-=wivfrF0_zvf+oj6==Sh=-npjoop8chlpefafv0onyt...@mail.gmail.com
[0]
Link:
https://lore.kernel.org/all/CAHk-=whwtuc-ajmgjveaetkomemfstwkwu99v7+b6ayhmma...@mail.gmail.com/
Signed-off-by: Yafang Shao
Cc: Alexander Viro
Cc: Christian Brauner
Cc: Jan Kara
Cc: Eric Biederman
Cc: Kees Cook
Cc: Alexei Starovoitov
Cc: Matus Jokay
Cc: Alejandro Colomar
Cc: "Serge E. Hallyn"
---
fs/exec.c | 10 --
fs/proc/array.c | 2 +-
include/linux/sched.h | 28 ++--
kernel/kthread.c | 2 +-
4 files changed, 24 insertions(+), 18 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index 6c53920795c2..77364806b48d 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1189,16 +1189,6 @@ static int unshare_sighand(struct task_struct *me)
return 0;
}
-char *__get_task_comm(char *buf, size_t buf_size, struct task_struct *tsk)
-{
- task_lock(tsk);
- /* Always NUL terminated and zero-padded */
- strscpy_pad(buf, tsk->comm, buf_size);
- task_unlock(tsk);
- return buf;
-}
-EXPORT_SYMBOL_GPL(__get_task_comm);
-
/*
* These functions flushes out all traces of the currently running executable
* so that a new one can be started
diff --git a/fs/proc/array.c b/fs/proc/array.c
index 34a47fb0c57f..55ed3510d2bb 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -109,7 +109,7 @@ void proc_task_name(struct seq_file *m, struct task_struct
*p, bool escape)
else if (p->flags & PF_KTHREAD)
get_kthread_comm(tcomm, sizeof(tcomm), p);
else
- __get_task_comm(tcomm, sizeof(tcomm), p);
+ get_task_comm(tcomm, p);
if (escape)
seq_escape_str(m, tcomm, ESCAPE_SPACE | ESCAPE_SPECIAL, "\n\\");
diff --git a/include/linux/sched.h b/include/linux/sched.h
index e6ee4258169a..28f92c637abf 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1121,9 +1121,12 @@ struct task_struct {
/*
* executable name, excluding path.
*
-* - normally initialized setup_new_exec()
-* - access it with [gs]et_task_comm()
-* - lock it with task_lock()
+* - normally initialized begin_new_exec()
+* - set it with set_task_comm()
+* - strscpy_pad() to ensure it is always NUL-terminated and
+* zero-padded
+* - task_lock() to ensure the operation is atomic and the name is
+* fully updated.
*/
charcomm[TASK_COMM_LEN];
@@ -1938,10 +1941,23 @@ static inline void set_task_comm(struct task_struct
*tsk, const char *from)
__set_task_comm(tsk, from, false);
}
-extern char *__get_task_comm(char *to, size_t len, struct task_struct *tsk);
+/*
+ * - Why not use task_lock()?
+ * User space can randomly change their names anyway, so locking for readers
+ * doesn't make sense. For writers, locking is probably necessary, as a race
+ * condition could lead to long-term mixed results.
+ * The strscpy_pad() in __set_task_comm() can ensure that the task comm is
+ * always NUL-terminated and zero-padded. Therefore the race condition
between
+ * reader and writer is not an issue.
+ *
+ * - BUILD_BUG_ON() can help prevent the buf from being truncated.
+ * Since the callers don't perform any return value checks, this safeguard is
+ * necessary.
+ */
#define get_task_comm(buf, tsk) ({ \
- BUILD_BUG_ON(sizeof(buf) != TASK_COMM_LEN); \
- __get_task_comm(buf, sizeof(buf), tsk); \
+ BUILD_BUG_ON(sizeof(buf) < TASK_COMM_LEN); \
+ strscpy_pad(buf, (tsk)->comm); \
+ buf;\
})
#ifdef CONFIG_SMP
diff --git a/kernel/kthread.c b/kernel/kthread.c
index db4ceb0f503c..74d20f46fa30 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -101,7 +101,7 @@ void get_kthread_comm(char *buf, size_t buf_size, struct
task_struct *tsk)
struct kthread *kthread = to_kthread(tsk);
if (!kthread || !kthread->full_name) {
- __get_task_comm(buf, buf_size, tsk);
+ strscpy(buf, tsk->comm, buf_size);
return;
}
--
2.43.5
Re: [PATCH v5 0/2] Basic support for TI TDP158
On 07/10/2024 16:42, Dmitry Baryshkov wrote: > On Mon, 7 Oct 2024 at 16:33, Marc Gonzalez wrote: >> >> On 03/09/2024 14:40, Robert Foss wrote: >> >>> On Mon, 12 Aug 2024 16:51:00 +0200, Marc Gonzalez wrote: >>> TDP158 is an AC-coupled DVI / HDMI to TMDS level shifting Redriver. Like the TFP410, the TDP158 can be set up in 2 different ways: 1) hard-coding its configuration settings using pin-strapping resistors 2) placing it on an I2C bus, and defer set-up until run-time The mode is selected by pin 8 = I2C_EN I2C_EN = 1 ==> I2C Control Mode I2C_EN = 0 ==> Pin Strap Mode [...] >>> >>> Applied, thanks! >>> >>> [1/2] dt-bindings: display: bridge: add TI TDP158 >>> https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/887665792b99 >>> [2/2] drm/bridge: add support for TI TDP158 >>> https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/a15710027afb >> >> Hello Robert, >> >> I expected this series to be included in v6.12-rc1, since you applied it >> before the v6.12 merge window opened. Did I misunderstand the process? > > drm-misc-next stops propagating new changes to drm-next one or two > weeks before the release. Oh right, the "stop at rc6" rule of thumb that Krzysztof mentioned. Regards
[PATCH v9 5/7] mm/util: Fix possible race condition in kstrdup()
In kstrdup(), it is critical to ensure that the dest string is always
NUL-terminated. However, potential race condition can occur between a
writer and a reader.
Consider the following scenario involving task->comm:
readerwriter
len = strlen(s) + 1;
strlcpy(tsk->comm, buf, sizeof(tsk->comm));
memcpy(buf, s, len);
In this case, there is a race condition between the reader and the
writer. The reader calculates the length of the string `s` based on the
old value of task->comm. However, during the memcpy(), the string `s`
might be updated by the writer to a new value of task->comm.
If the new task->comm is larger than the old one, the `buf` might not be
NUL-terminated. This can lead to undefined behavior and potential
security vulnerabilities.
Let's fix it by explicitly adding a NUL terminator after the memcpy. It
is worth noting that memcpy() is not atomic, so the new string can be
shorter when memcpy() already copied past the new NUL.
Signed-off-by: Yafang Shao
Cc: Andrew Morton
Cc: Alejandro Colomar
Cc: Andy Shevchenko
---
mm/util.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/mm/util.c b/mm/util.c
index 4f1275023eb7..858a9a2f57e7 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -62,8 +62,15 @@ char *kstrdup(const char *s, gfp_t gfp)
len = strlen(s) + 1;
buf = kmalloc_track_caller(len, gfp);
- if (buf)
+ if (buf) {
memcpy(buf, s, len);
+ /*
+* During memcpy(), the string might be updated to a new value,
+* which could be longer than the string when strlen() is
+* called. Therefore, we need to add a NUL terminator.
+*/
+ buf[len - 1] = '\0';
+ }
return buf;
}
EXPORT_SYMBOL(kstrdup);
--
2.43.5
[PATCH v9 6/7] mm/util: Deduplicate code in {kstrdup, kstrndup, kmemdup_nul}
These three functions follow the same pattern. To deduplicate the code,
let's introduce a common helper __kmemdup_nul().
Suggested-by: Andrew Morton
Signed-off-by: Yafang Shao
Cc: Simon Horman
Cc: Matthew Wilcox
Cc: Alejandro Colomar
---
mm/util.c | 69 ++-
1 file changed, 27 insertions(+), 42 deletions(-)
diff --git a/mm/util.c b/mm/util.c
index 858a9a2f57e7..c7d851c40843 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -45,34 +45,41 @@ void kfree_const(const void *x)
EXPORT_SYMBOL(kfree_const);
/**
- * kstrdup - allocate space for and copy an existing string
- * @s: the string to duplicate
+ * __kmemdup_nul - Create a NUL-terminated string from @s, which might be
unterminated.
+ * @s: The data to copy
+ * @len: The size of the data, not including the NUL terminator
* @gfp: the GFP mask used in the kmalloc() call when allocating memory
*
- * Return: newly allocated copy of @s or %NULL in case of error
+ * Return: newly allocated copy of @s with NUL-termination or %NULL in
+ * case of error
*/
-noinline
-char *kstrdup(const char *s, gfp_t gfp)
+static __always_inline char *__kmemdup_nul(const char *s, size_t len, gfp_t
gfp)
{
- size_t len;
char *buf;
- if (!s)
+ /* '+1' for the NUL terminator */
+ buf = kmalloc_track_caller(len + 1, gfp);
+ if (!buf)
return NULL;
- len = strlen(s) + 1;
- buf = kmalloc_track_caller(len, gfp);
- if (buf) {
- memcpy(buf, s, len);
- /*
-* During memcpy(), the string might be updated to a new value,
-* which could be longer than the string when strlen() is
-* called. Therefore, we need to add a NUL terminator.
-*/
- buf[len - 1] = '\0';
- }
+ memcpy(buf, s, len);
+ /* Ensure the buf is always NUL-terminated, regardless of @s. */
+ buf[len] = '\0';
return buf;
}
+
+/**
+ * kstrdup - allocate space for and copy an existing string
+ * @s: the string to duplicate
+ * @gfp: the GFP mask used in the kmalloc() call when allocating memory
+ *
+ * Return: newly allocated copy of @s or %NULL in case of error
+ */
+noinline
+char *kstrdup(const char *s, gfp_t gfp)
+{
+ return s ? __kmemdup_nul(s, strlen(s), gfp) : NULL;
+}
EXPORT_SYMBOL(kstrdup);
/**
@@ -107,19 +114,7 @@ EXPORT_SYMBOL(kstrdup_const);
*/
char *kstrndup(const char *s, size_t max, gfp_t gfp)
{
- size_t len;
- char *buf;
-
- if (!s)
- return NULL;
-
- len = strnlen(s, max);
- buf = kmalloc_track_caller(len+1, gfp);
- if (buf) {
- memcpy(buf, s, len);
- buf[len] = '\0';
- }
- return buf;
+ return s ? __kmemdup_nul(s, strnlen(s, max), gfp) : NULL;
}
EXPORT_SYMBOL(kstrndup);
@@ -193,17 +188,7 @@ EXPORT_SYMBOL(kvmemdup);
*/
char *kmemdup_nul(const char *s, size_t len, gfp_t gfp)
{
- char *buf;
-
- if (!s)
- return NULL;
-
- buf = kmalloc_track_caller(len + 1, gfp);
- if (buf) {
- memcpy(buf, s, len);
- buf[len] = '\0';
- }
- return buf;
+ return s ? __kmemdup_nul(s, len, gfp) : NULL;
}
EXPORT_SYMBOL(kmemdup_nul);
--
2.43.5
[PATCH v9 2/7] auditsc: Replace memcpy() with strscpy()
Using strscpy() to read the task comm ensures that the name is always NUL-terminated, regardless of the source string. This approach also facilitates future extensions to the task comm. Signed-off-by: Yafang Shao Acked-by: Paul Moore Reviewed-by: Justin Stitt Cc: Eric Paris --- kernel/auditsc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/kernel/auditsc.c b/kernel/auditsc.c index cd57053b4a69..7adc67d5aafb 100644 --- a/kernel/auditsc.c +++ b/kernel/auditsc.c @@ -2730,7 +2730,7 @@ void __audit_ptrace(struct task_struct *t) context->target_uid = task_uid(t); context->target_sessionid = audit_get_sessionid(t); security_task_getsecid_obj(t, &context->target_sid); - memcpy(context->target_comm, t->comm, TASK_COMM_LEN); + strscpy(context->target_comm, t->comm); } /** @@ -2757,7 +2757,7 @@ int audit_signal_info_syscall(struct task_struct *t) ctx->target_uid = t_uid; ctx->target_sessionid = audit_get_sessionid(t); security_task_getsecid_obj(t, &ctx->target_sid); - memcpy(ctx->target_comm, t->comm, TASK_COMM_LEN); + strscpy(ctx->target_comm, t->comm); return 0; } @@ -2778,7 +2778,7 @@ int audit_signal_info_syscall(struct task_struct *t) axp->target_uid[axp->pid_count] = t_uid; axp->target_sessionid[axp->pid_count] = audit_get_sessionid(t); security_task_getsecid_obj(t, &axp->target_sid[axp->pid_count]); - memcpy(axp->target_comm[axp->pid_count], t->comm, TASK_COMM_LEN); + strscpy(axp->target_comm[axp->pid_count], t->comm); axp->pid_count++; return 0; -- 2.43.5
[PATCH v9 3/7] security: Replace memcpy() with get_task_comm()
Quoted from Linus [0]:
selinux never wanted a lock, and never wanted any kind of *consistent*
result, it just wanted a *stable* result.
Using get_task_comm() to read the task comm ensures that the name is
always NUL-terminated, regardless of the source string. This approach also
facilitates future extensions to the task comm.
Signed-off-by: Yafang Shao
LINK:
https://lore.kernel.org/all/CAHk-=wivfrF0_zvf+oj6==Sh=-npjoop8chlpefafv0onyt...@mail.gmail.com/
[0]
Acked-by: Paul Moore
Cc: James Morris
Cc: "Serge E. Hallyn"
Cc: Stephen Smalley
Cc: Ondrej Mosnacek
---
security/lsm_audit.c | 4 ++--
security/selinux/selinuxfs.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/security/lsm_audit.c b/security/lsm_audit.c
index 849e832719e2..9a8352972086 100644
--- a/security/lsm_audit.c
+++ b/security/lsm_audit.c
@@ -207,7 +207,7 @@ static void dump_common_audit_data(struct audit_buffer *ab,
BUILD_BUG_ON(sizeof(a->u) > sizeof(void *)*2);
audit_log_format(ab, " pid=%d comm=", task_tgid_nr(current));
- audit_log_untrustedstring(ab, memcpy(comm, current->comm,
sizeof(comm)));
+ audit_log_untrustedstring(ab, get_task_comm(comm, current));
switch (a->type) {
case LSM_AUDIT_DATA_NONE:
@@ -302,7 +302,7 @@ static void dump_common_audit_data(struct audit_buffer *ab,
char comm[sizeof(tsk->comm)];
audit_log_format(ab, " opid=%d ocomm=", pid);
audit_log_untrustedstring(ab,
- memcpy(comm, tsk->comm, sizeof(comm)));
+ get_task_comm(comm, tsk));
}
}
break;
diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index e172f182b65c..c9b05be27ddb 100644
--- a/security/selinux/selinuxfs.c
+++ b/security/selinux/selinuxfs.c
@@ -708,7 +708,7 @@ static ssize_t sel_write_checkreqprot(struct file *file,
const char __user *buf,
if (new_value) {
char comm[sizeof(current->comm)];
- memcpy(comm, current->comm, sizeof(comm));
+ strscpy(comm, current->comm);
pr_err("SELinux: %s (%d) set checkreqprot to 1. This is no
longer supported.\n",
comm, current->pid);
}
--
2.43.5
[PATCH v9 4/7] bpftool: Ensure task comm is always NUL-terminated
Let's explicitly ensure the destination string is NUL-terminated. This way, it won't be affected by changes to the source string. Signed-off-by: Yafang Shao Reviewed-by: Quentin Monnet --- tools/bpf/bpftool/pids.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/bpf/bpftool/pids.c b/tools/bpf/bpftool/pids.c index 9b898571b49e..23f488cf1740 100644 --- a/tools/bpf/bpftool/pids.c +++ b/tools/bpf/bpftool/pids.c @@ -54,6 +54,7 @@ static void add_ref(struct hashmap *map, struct pid_iter_entry *e) ref = &refs->refs[refs->ref_cnt]; ref->pid = e->pid; memcpy(ref->comm, e->comm, sizeof(ref->comm)); + ref->comm[sizeof(ref->comm) - 1] = '\0'; refs->ref_cnt++; return; @@ -77,6 +78,7 @@ static void add_ref(struct hashmap *map, struct pid_iter_entry *e) ref = &refs->refs[0]; ref->pid = e->pid; memcpy(ref->comm, e->comm, sizeof(ref->comm)); + ref->comm[sizeof(ref->comm) - 1] = '\0'; refs->ref_cnt = 1; refs->has_bpf_cookie = e->has_bpf_cookie; refs->bpf_cookie = e->bpf_cookie; -- 2.43.5
[PATCH v9 7/7] drm: Replace strcpy() with strscpy()
To prevent errors from occurring when the src string is longer than the
dst string in strcpy(), we should use strscpy() instead. This
approach also facilitates future extensions to the task comm.
Suggested-by: Justin Stitt
Signed-off-by: Yafang Shao
Acked-by: Daniel Vetter
Reviewed-by: Justin Stitt
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
---
drivers/gpu/drm/drm_framebuffer.c | 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index 888aadb6a4ac..2d6993539474 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -868,7 +868,7 @@ int drm_framebuffer_init(struct drm_device *dev, struct
drm_framebuffer *fb,
INIT_LIST_HEAD(&fb->filp_head);
fb->funcs = funcs;
- strcpy(fb->comm, current->comm);
+ strscpy(fb->comm, current->comm);
ret = __drm_mode_object_add(dev, &fb->base, DRM_MODE_OBJECT_FB,
false, drm_framebuffer_free);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 6469b9bcf2ec..9d4b25b2cd39 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1113,7 +1113,7 @@ i915_vma_coredump_create(const struct intel_gt *gt,
}
INIT_LIST_HEAD(&dst->page_list);
- strcpy(dst->name, name);
+ strscpy(dst->name, name);
dst->next = NULL;
dst->gtt_offset = vma_res->start;
@@ -1413,7 +1413,7 @@ static bool record_context(struct
i915_gem_context_coredump *e,
rcu_read_lock();
task = pid_task(ctx->pid, PIDTYPE_PID);
if (task) {
- strcpy(e->comm, task->comm);
+ strscpy(e->comm, task->comm);
e->pid = task->pid;
}
rcu_read_unlock();
@@ -1459,7 +1459,7 @@ capture_vma_snapshot(struct intel_engine_capture_vma
*next,
return next;
}
- strcpy(c->name, name);
+ strscpy(c->name, name);
c->vma_res = i915_vma_resource_get(vma_res);
c->next = next;
--
2.43.5
Re: [PATCH v6 3/5] drm: handle HAS_IOPORT dependencies
On Mon, Oct 7, 2024, at 14:39, Lucas De Marchi wrote: > as an example: > $ git grep -lw outb -- drivers/gpu/drm/ > drivers/gpu/drm/gma500/cdv_device.c > drivers/gpu/drm/i915/display/intel_vga.c > drivers/gpu/drm/qxl/qxl_cmd.c > drivers/gpu/drm/qxl/qxl_irq.c > drivers/gpu/drm/tiny/bochs.c > drivers/gpu/drm/tiny/cirrus.c > > you are adding the dependency on xe, but why are you keeping i915 out? > What approach did you use to determine the dependency? I did a lot of 'randconfig' build testing on earlier versions (and this version) of the series, which eventually catches all of them. The i915 driver depends on CONfIG_X86 since it is only used in Intel PC chipsets that already rely on PIO. The XE driver is also used for add-on cards, so the drivers can be built on all architectures including those that do not support PCI I/O space access. Adding the dependency on i915 as well wouldn't be wrong, but is not required for correctness. I also sent a patch for vmwgfx, which can be used on arm64. arm64 currently always sets HAS_IOPORT, so my patch is not required as a dependency for [PATCH v6 5/5], but we eventually want this so HAS_IOPORT can become optional on arm64. Arnd
[PATCH linux-next] drm/i915/dp: use string choice helpers
Use str_on_off string helpers for better readability and to fix cocci warning. Reported-by: kernel test robot Reported-by: Julia Lawall Closes: https://lore.kernel.org/r/202410071252.cwiljzrh-...@intel.com/ Signed-off-by: R Sundar --- Reported in linux repo: tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master cocci warnings: (new ones prefixed by >>) >> drivers/gpu/drm/i915/display/intel_dp.c:2243:6-9: opportunity for >> str_on_off(dsc) vim +2243 drivers/gpu/drm/i915/display/intel_dp.c compile tested only. drivers/gpu/drm/i915/display/intel_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index fbb096be02ad..733619b14193 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -2475,7 +2475,7 @@ intel_dp_compute_config_link_bpp_limits(struct intel_dp *intel_dp, encoder->base.base.id, encoder->base.name, crtc->base.base.id, crtc->base.name, adjusted_mode->crtc_clock, - dsc ? "on" : "off", + str_on_off(dsc), limits->max_lane_count, limits->max_rate, limits->pipe.max_bpp, -- 2.34.1
Patch "drm/sched: Always increment correct scheduler score" has been added to the 6.11-stable tree
This is a note to let you know that I've just added the patch titled
drm/sched: Always increment correct scheduler score
to the 6.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-sched-always-increment-correct-scheduler-score.patch
and it can be found in the queue-6.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 087913e0ba2b3b9d7ccbafb2acf5dab9e35ae1d5 Mon Sep 17 00:00:00 2001
From: Tvrtko Ursulin
Date: Tue, 24 Sep 2024 11:19:09 +0100
Subject: drm/sched: Always increment correct scheduler score
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Tvrtko Ursulin
commit 087913e0ba2b3b9d7ccbafb2acf5dab9e35ae1d5 upstream.
Entities run queue can change during drm_sched_entity_push_job() so make
sure to update the score consistently.
Signed-off-by: Tvrtko Ursulin
Fixes: d41a39dda140 ("drm/scheduler: improve job distribution with multiple
queues")
Cc: Nirmoy Das
Cc: Christian König
Cc: Luben Tuikov
Cc: Matthew Brost
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.9+
Reviewed-by: Christian König
Reviewed-by: Nirmoy Das
Link:
https://patchwork.freedesktop.org/patch/msgid/20240924101914.2713-4-tursu...@igalia.com
Signed-off-by: Christian König
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/scheduler/sched_entity.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -586,7 +586,6 @@ void drm_sched_entity_push_job(struct dr
ktime_t submit_ts;
trace_drm_sched_job(sched_job, entity);
- atomic_inc(entity->rq->sched->score);
WRITE_ONCE(entity->last_user, current->group_leader);
/*
@@ -614,6 +613,7 @@ void drm_sched_entity_push_job(struct dr
rq = entity->rq;
sched = rq->sched;
+ atomic_inc(sched->score);
drm_sched_rq_add_entity(rq, entity);
spin_unlock(&entity->rq_lock);
Patches currently in stable-queue which might be from tvrtko.ursu...@igalia.com
are
queue-6.11/drm-sched-always-increment-correct-scheduler-score.patch
queue-6.11/drm-v3d-prevent-out-of-bounds-access-in-performance-query-extensions.patch
queue-6.11/drm-sched-always-wake-up-correct-scheduler-in-drm_sched_entity_push_job.patch
queue-6.11/drm-sched-add-locking-to-drm_sched_entity_modify_sched.patch
Patch "drm/sched: Add locking to drm_sched_entity_modify_sched" has been added to the 6.1-stable tree
This is a note to let you know that I've just added the patch titled
drm/sched: Add locking to drm_sched_entity_modify_sched
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-sched-add-locking-to-drm_sched_entity_modify_sched.patch
and it can be found in the queue-6.1 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 4286cc2c953983d44d248c9de1c81d3a9643345c Mon Sep 17 00:00:00 2001
From: Tvrtko Ursulin
Date: Fri, 13 Sep 2024 17:05:52 +0100
Subject: drm/sched: Add locking to drm_sched_entity_modify_sched
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Tvrtko Ursulin
commit 4286cc2c953983d44d248c9de1c81d3a9643345c upstream.
Without the locking amdgpu currently can race between
amdgpu_ctx_set_entity_priority() (via drm_sched_entity_modify_sched()) and
drm_sched_job_arm(), leading to the latter accesing potentially
inconsitent entity->sched_list and entity->num_sched_list pair.
v2:
* Improve commit message. (Philipp)
Signed-off-by: Tvrtko Ursulin
Fixes: b37aced31eb0 ("drm/scheduler: implement a function to modify sched list")
Cc: Christian König
Cc: Alex Deucher
Cc: Luben Tuikov
Cc: Matthew Brost
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: Philipp Stanner
Cc: # v5.7+
Reviewed-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20240913160559.49054-2-tursu...@igalia.com
Signed-off-by: Christian König
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/scheduler/sched_entity.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -110,8 +110,10 @@ void drm_sched_entity_modify_sched(struc
{
WARN_ON(!num_sched_list || !sched_list);
+ spin_lock(&entity->rq_lock);
entity->sched_list = sched_list;
entity->num_sched_list = num_sched_list;
+ spin_unlock(&entity->rq_lock);
}
EXPORT_SYMBOL(drm_sched_entity_modify_sched);
Patches currently in stable-queue which might be from tvrtko.ursu...@igalia.com
are
queue-6.1/drm-sched-add-locking-to-drm_sched_entity_modify_sched.patch
Patch "drm/sched: Add locking to drm_sched_entity_modify_sched" has been added to the 5.15-stable tree
This is a note to let you know that I've just added the patch titled
drm/sched: Add locking to drm_sched_entity_modify_sched
to the 5.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-sched-add-locking-to-drm_sched_entity_modify_sched.patch
and it can be found in the queue-5.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 4286cc2c953983d44d248c9de1c81d3a9643345c Mon Sep 17 00:00:00 2001
From: Tvrtko Ursulin
Date: Fri, 13 Sep 2024 17:05:52 +0100
Subject: drm/sched: Add locking to drm_sched_entity_modify_sched
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Tvrtko Ursulin
commit 4286cc2c953983d44d248c9de1c81d3a9643345c upstream.
Without the locking amdgpu currently can race between
amdgpu_ctx_set_entity_priority() (via drm_sched_entity_modify_sched()) and
drm_sched_job_arm(), leading to the latter accesing potentially
inconsitent entity->sched_list and entity->num_sched_list pair.
v2:
* Improve commit message. (Philipp)
Signed-off-by: Tvrtko Ursulin
Fixes: b37aced31eb0 ("drm/scheduler: implement a function to modify sched list")
Cc: Christian König
Cc: Alex Deucher
Cc: Luben Tuikov
Cc: Matthew Brost
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: Philipp Stanner
Cc: # v5.7+
Reviewed-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20240913160559.49054-2-tursu...@igalia.com
Signed-off-by: Christian König
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/scheduler/sched_entity.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -99,8 +99,10 @@ void drm_sched_entity_modify_sched(struc
{
WARN_ON(!num_sched_list || !sched_list);
+ spin_lock(&entity->rq_lock);
entity->sched_list = sched_list;
entity->num_sched_list = num_sched_list;
+ spin_unlock(&entity->rq_lock);
}
EXPORT_SYMBOL(drm_sched_entity_modify_sched);
Patches currently in stable-queue which might be from tvrtko.ursu...@igalia.com
are
queue-5.15/drm-sched-add-locking-to-drm_sched_entity_modify_sched.patch
Patch "drm/sched: Add locking to drm_sched_entity_modify_sched" has been added to the 5.10-stable tree
This is a note to let you know that I've just added the patch titled
drm/sched: Add locking to drm_sched_entity_modify_sched
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-sched-add-locking-to-drm_sched_entity_modify_sched.patch
and it can be found in the queue-5.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 4286cc2c953983d44d248c9de1c81d3a9643345c Mon Sep 17 00:00:00 2001
From: Tvrtko Ursulin
Date: Fri, 13 Sep 2024 17:05:52 +0100
Subject: drm/sched: Add locking to drm_sched_entity_modify_sched
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Tvrtko Ursulin
commit 4286cc2c953983d44d248c9de1c81d3a9643345c upstream.
Without the locking amdgpu currently can race between
amdgpu_ctx_set_entity_priority() (via drm_sched_entity_modify_sched()) and
drm_sched_job_arm(), leading to the latter accesing potentially
inconsitent entity->sched_list and entity->num_sched_list pair.
v2:
* Improve commit message. (Philipp)
Signed-off-by: Tvrtko Ursulin
Fixes: b37aced31eb0 ("drm/scheduler: implement a function to modify sched list")
Cc: Christian König
Cc: Alex Deucher
Cc: Luben Tuikov
Cc: Matthew Brost
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: Philipp Stanner
Cc: # v5.7+
Reviewed-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20240913160559.49054-2-tursu...@igalia.com
Signed-off-by: Christian König
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/scheduler/sched_entity.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -96,8 +96,10 @@ void drm_sched_entity_modify_sched(struc
{
WARN_ON(!num_sched_list || !sched_list);
+ spin_lock(&entity->rq_lock);
entity->sched_list = sched_list;
entity->num_sched_list = num_sched_list;
+ spin_unlock(&entity->rq_lock);
}
EXPORT_SYMBOL(drm_sched_entity_modify_sched);
Patches currently in stable-queue which might be from tvrtko.ursu...@igalia.com
are
queue-5.10/drm-sched-add-locking-to-drm_sched_entity_modify_sched.patch
Patch "drm/sched: Add locking to drm_sched_entity_modify_sched" has been added to the 6.11-stable tree
This is a note to let you know that I've just added the patch titled
drm/sched: Add locking to drm_sched_entity_modify_sched
to the 6.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-sched-add-locking-to-drm_sched_entity_modify_sched.patch
and it can be found in the queue-6.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 4286cc2c953983d44d248c9de1c81d3a9643345c Mon Sep 17 00:00:00 2001
From: Tvrtko Ursulin
Date: Fri, 13 Sep 2024 17:05:52 +0100
Subject: drm/sched: Add locking to drm_sched_entity_modify_sched
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Tvrtko Ursulin
commit 4286cc2c953983d44d248c9de1c81d3a9643345c upstream.
Without the locking amdgpu currently can race between
amdgpu_ctx_set_entity_priority() (via drm_sched_entity_modify_sched()) and
drm_sched_job_arm(), leading to the latter accesing potentially
inconsitent entity->sched_list and entity->num_sched_list pair.
v2:
* Improve commit message. (Philipp)
Signed-off-by: Tvrtko Ursulin
Fixes: b37aced31eb0 ("drm/scheduler: implement a function to modify sched list")
Cc: Christian König
Cc: Alex Deucher
Cc: Luben Tuikov
Cc: Matthew Brost
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: Philipp Stanner
Cc: # v5.7+
Reviewed-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20240913160559.49054-2-tursu...@igalia.com
Signed-off-by: Christian König
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/scheduler/sched_entity.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -133,8 +133,10 @@ void drm_sched_entity_modify_sched(struc
{
WARN_ON(!num_sched_list || !sched_list);
+ spin_lock(&entity->rq_lock);
entity->sched_list = sched_list;
entity->num_sched_list = num_sched_list;
+ spin_unlock(&entity->rq_lock);
}
EXPORT_SYMBOL(drm_sched_entity_modify_sched);
Patches currently in stable-queue which might be from tvrtko.ursu...@igalia.com
are
queue-6.11/drm-sched-always-increment-correct-scheduler-score.patch
queue-6.11/drm-v3d-prevent-out-of-bounds-access-in-performance-query-extensions.patch
queue-6.11/drm-sched-always-wake-up-correct-scheduler-in-drm_sched_entity_push_job.patch
queue-6.11/drm-sched-add-locking-to-drm_sched_entity_modify_sched.patch
Patch "drm/sched: Add locking to drm_sched_entity_modify_sched" has been added to the 6.6-stable tree
This is a note to let you know that I've just added the patch titled
drm/sched: Add locking to drm_sched_entity_modify_sched
to the 6.6-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-sched-add-locking-to-drm_sched_entity_modify_sched.patch
and it can be found in the queue-6.6 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 4286cc2c953983d44d248c9de1c81d3a9643345c Mon Sep 17 00:00:00 2001
From: Tvrtko Ursulin
Date: Fri, 13 Sep 2024 17:05:52 +0100
Subject: drm/sched: Add locking to drm_sched_entity_modify_sched
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Tvrtko Ursulin
commit 4286cc2c953983d44d248c9de1c81d3a9643345c upstream.
Without the locking amdgpu currently can race between
amdgpu_ctx_set_entity_priority() (via drm_sched_entity_modify_sched()) and
drm_sched_job_arm(), leading to the latter accesing potentially
inconsitent entity->sched_list and entity->num_sched_list pair.
v2:
* Improve commit message. (Philipp)
Signed-off-by: Tvrtko Ursulin
Fixes: b37aced31eb0 ("drm/scheduler: implement a function to modify sched list")
Cc: Christian König
Cc: Alex Deucher
Cc: Luben Tuikov
Cc: Matthew Brost
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: Philipp Stanner
Cc: # v5.7+
Reviewed-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20240913160559.49054-2-tursu...@igalia.com
Signed-off-by: Christian König
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/scheduler/sched_entity.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -111,8 +111,10 @@ void drm_sched_entity_modify_sched(struc
{
WARN_ON(!num_sched_list || !sched_list);
+ spin_lock(&entity->rq_lock);
entity->sched_list = sched_list;
entity->num_sched_list = num_sched_list;
+ spin_unlock(&entity->rq_lock);
}
EXPORT_SYMBOL(drm_sched_entity_modify_sched);
Patches currently in stable-queue which might be from tvrtko.ursu...@igalia.com
are
queue-6.6/drm-sched-add-locking-to-drm_sched_entity_modify_sched.patch
Patch "drm/sched: Always increment correct scheduler score" has been added to the 6.10-stable tree
This is a note to let you know that I've just added the patch titled
drm/sched: Always increment correct scheduler score
to the 6.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-sched-always-increment-correct-scheduler-score.patch
and it can be found in the queue-6.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 087913e0ba2b3b9d7ccbafb2acf5dab9e35ae1d5 Mon Sep 17 00:00:00 2001
From: Tvrtko Ursulin
Date: Tue, 24 Sep 2024 11:19:09 +0100
Subject: drm/sched: Always increment correct scheduler score
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Tvrtko Ursulin
commit 087913e0ba2b3b9d7ccbafb2acf5dab9e35ae1d5 upstream.
Entities run queue can change during drm_sched_entity_push_job() so make
sure to update the score consistently.
Signed-off-by: Tvrtko Ursulin
Fixes: d41a39dda140 ("drm/scheduler: improve job distribution with multiple
queues")
Cc: Nirmoy Das
Cc: Christian König
Cc: Luben Tuikov
Cc: Matthew Brost
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.9+
Reviewed-by: Christian König
Reviewed-by: Nirmoy Das
Link:
https://patchwork.freedesktop.org/patch/msgid/20240924101914.2713-4-tursu...@igalia.com
Signed-off-by: Christian König
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/scheduler/sched_entity.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -586,7 +586,6 @@ void drm_sched_entity_push_job(struct dr
ktime_t submit_ts;
trace_drm_sched_job(sched_job, entity);
- atomic_inc(entity->rq->sched->score);
WRITE_ONCE(entity->last_user, current->group_leader);
/*
@@ -614,6 +613,7 @@ void drm_sched_entity_push_job(struct dr
rq = entity->rq;
sched = rq->sched;
+ atomic_inc(sched->score);
drm_sched_rq_add_entity(rq, entity);
spin_unlock(&entity->rq_lock);
Patches currently in stable-queue which might be from tvrtko.ursu...@igalia.com
are
queue-6.10/drm-sched-always-increment-correct-scheduler-score.patch
queue-6.10/drm-v3d-prevent-out-of-bounds-access-in-performance-query-extensions.patch
queue-6.10/drm-sched-always-wake-up-correct-scheduler-in-drm_sched_entity_push_job.patch
queue-6.10/drm-sched-add-locking-to-drm_sched_entity_modify_sched.patch
Patch "drm/sched: Always wake up correct scheduler in drm_sched_entity_push_job" has been added to the 6.10-stable tree
This is a note to let you know that I've just added the patch titled
drm/sched: Always wake up correct scheduler in drm_sched_entity_push_job
to the 6.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-sched-always-wake-up-correct-scheduler-in-drm_sched_entity_push_job.patch
and it can be found in the queue-6.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From cbc8764e29c2318229261a679b2aafd0f9072885 Mon Sep 17 00:00:00 2001
From: Tvrtko Ursulin
Date: Tue, 24 Sep 2024 11:19:08 +0100
Subject: drm/sched: Always wake up correct scheduler in
drm_sched_entity_push_job
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Tvrtko Ursulin
commit cbc8764e29c2318229261a679b2aafd0f9072885 upstream.
Since drm_sched_entity_modify_sched() can modify the entities run queue,
lets make sure to only dereference the pointer once so both adding and
waking up are guaranteed to be consistent.
Alternative of moving the spin_unlock to after the wake up would for now
be more problematic since the same lock is taken inside
drm_sched_rq_update_fifo().
v2:
* Improve commit message. (Philipp)
* Cache the scheduler pointer directly. (Christian)
Signed-off-by: Tvrtko Ursulin
Fixes: b37aced31eb0 ("drm/scheduler: implement a function to modify sched list")
Cc: Christian König
Cc: Alex Deucher
Cc: Luben Tuikov
Cc: Matthew Brost
Cc: David Airlie
Cc: Daniel Vetter
Cc: Philipp Stanner
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.7+
Reviewed-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20240924101914.2713-3-tursu...@igalia.com
Signed-off-by: Christian König
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/scheduler/sched_entity.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -599,6 +599,9 @@ void drm_sched_entity_push_job(struct dr
/* first job wakes up scheduler */
if (first) {
+ struct drm_gpu_scheduler *sched;
+ struct drm_sched_rq *rq;
+
/* Add the entity to the run queue */
spin_lock(&entity->rq_lock);
if (entity->stopped) {
@@ -608,13 +611,16 @@ void drm_sched_entity_push_job(struct dr
return;
}
- drm_sched_rq_add_entity(entity->rq, entity);
+ rq = entity->rq;
+ sched = rq->sched;
+
+ drm_sched_rq_add_entity(rq, entity);
spin_unlock(&entity->rq_lock);
if (drm_sched_policy == DRM_SCHED_POLICY_FIFO)
drm_sched_rq_update_fifo(entity, submit_ts);
- drm_sched_wakeup(entity->rq->sched);
+ drm_sched_wakeup(sched);
}
}
EXPORT_SYMBOL(drm_sched_entity_push_job);
Patches currently in stable-queue which might be from tvrtko.ursu...@igalia.com
are
queue-6.10/drm-sched-always-increment-correct-scheduler-score.patch
queue-6.10/drm-v3d-prevent-out-of-bounds-access-in-performance-query-extensions.patch
queue-6.10/drm-sched-always-wake-up-correct-scheduler-in-drm_sched_entity_push_job.patch
queue-6.10/drm-sched-add-locking-to-drm_sched_entity_modify_sched.patch
Patch "drm/sched: Always wake up correct scheduler in drm_sched_entity_push_job" has been added to the 6.11-stable tree
This is a note to let you know that I've just added the patch titled
drm/sched: Always wake up correct scheduler in drm_sched_entity_push_job
to the 6.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-sched-always-wake-up-correct-scheduler-in-drm_sched_entity_push_job.patch
and it can be found in the queue-6.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From cbc8764e29c2318229261a679b2aafd0f9072885 Mon Sep 17 00:00:00 2001
From: Tvrtko Ursulin
Date: Tue, 24 Sep 2024 11:19:08 +0100
Subject: drm/sched: Always wake up correct scheduler in
drm_sched_entity_push_job
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Tvrtko Ursulin
commit cbc8764e29c2318229261a679b2aafd0f9072885 upstream.
Since drm_sched_entity_modify_sched() can modify the entities run queue,
lets make sure to only dereference the pointer once so both adding and
waking up are guaranteed to be consistent.
Alternative of moving the spin_unlock to after the wake up would for now
be more problematic since the same lock is taken inside
drm_sched_rq_update_fifo().
v2:
* Improve commit message. (Philipp)
* Cache the scheduler pointer directly. (Christian)
Signed-off-by: Tvrtko Ursulin
Fixes: b37aced31eb0 ("drm/scheduler: implement a function to modify sched list")
Cc: Christian König
Cc: Alex Deucher
Cc: Luben Tuikov
Cc: Matthew Brost
Cc: David Airlie
Cc: Daniel Vetter
Cc: Philipp Stanner
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.7+
Reviewed-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20240924101914.2713-3-tursu...@igalia.com
Signed-off-by: Christian König
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/scheduler/sched_entity.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -599,6 +599,9 @@ void drm_sched_entity_push_job(struct dr
/* first job wakes up scheduler */
if (first) {
+ struct drm_gpu_scheduler *sched;
+ struct drm_sched_rq *rq;
+
/* Add the entity to the run queue */
spin_lock(&entity->rq_lock);
if (entity->stopped) {
@@ -608,13 +611,16 @@ void drm_sched_entity_push_job(struct dr
return;
}
- drm_sched_rq_add_entity(entity->rq, entity);
+ rq = entity->rq;
+ sched = rq->sched;
+
+ drm_sched_rq_add_entity(rq, entity);
spin_unlock(&entity->rq_lock);
if (drm_sched_policy == DRM_SCHED_POLICY_FIFO)
drm_sched_rq_update_fifo(entity, submit_ts);
- drm_sched_wakeup(entity->rq->sched);
+ drm_sched_wakeup(sched);
}
}
EXPORT_SYMBOL(drm_sched_entity_push_job);
Patches currently in stable-queue which might be from tvrtko.ursu...@igalia.com
are
queue-6.11/drm-sched-always-increment-correct-scheduler-score.patch
queue-6.11/drm-v3d-prevent-out-of-bounds-access-in-performance-query-extensions.patch
queue-6.11/drm-sched-always-wake-up-correct-scheduler-in-drm_sched_entity_push_job.patch
queue-6.11/drm-sched-add-locking-to-drm_sched_entity_modify_sched.patch
Patch "drm/sched: Add locking to drm_sched_entity_modify_sched" has been added to the 6.10-stable tree
This is a note to let you know that I've just added the patch titled
drm/sched: Add locking to drm_sched_entity_modify_sched
to the 6.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-sched-add-locking-to-drm_sched_entity_modify_sched.patch
and it can be found in the queue-6.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 4286cc2c953983d44d248c9de1c81d3a9643345c Mon Sep 17 00:00:00 2001
From: Tvrtko Ursulin
Date: Fri, 13 Sep 2024 17:05:52 +0100
Subject: drm/sched: Add locking to drm_sched_entity_modify_sched
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Tvrtko Ursulin
commit 4286cc2c953983d44d248c9de1c81d3a9643345c upstream.
Without the locking amdgpu currently can race between
amdgpu_ctx_set_entity_priority() (via drm_sched_entity_modify_sched()) and
drm_sched_job_arm(), leading to the latter accesing potentially
inconsitent entity->sched_list and entity->num_sched_list pair.
v2:
* Improve commit message. (Philipp)
Signed-off-by: Tvrtko Ursulin
Fixes: b37aced31eb0 ("drm/scheduler: implement a function to modify sched list")
Cc: Christian König
Cc: Alex Deucher
Cc: Luben Tuikov
Cc: Matthew Brost
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: Philipp Stanner
Cc: # v5.7+
Reviewed-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20240913160559.49054-2-tursu...@igalia.com
Signed-off-by: Christian König
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/scheduler/sched_entity.c |2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -133,8 +133,10 @@ void drm_sched_entity_modify_sched(struc
{
WARN_ON(!num_sched_list || !sched_list);
+ spin_lock(&entity->rq_lock);
entity->sched_list = sched_list;
entity->num_sched_list = num_sched_list;
+ spin_unlock(&entity->rq_lock);
}
EXPORT_SYMBOL(drm_sched_entity_modify_sched);
Patches currently in stable-queue which might be from tvrtko.ursu...@igalia.com
are
queue-6.10/drm-sched-always-increment-correct-scheduler-score.patch
queue-6.10/drm-v3d-prevent-out-of-bounds-access-in-performance-query-extensions.patch
queue-6.10/drm-sched-always-wake-up-correct-scheduler-in-drm_sched_entity_push_job.patch
queue-6.10/drm-sched-add-locking-to-drm_sched_entity_modify_sched.patch
Re: Patch "drm/sched: Always wake up correct scheduler in drm_sched_entity_push_job" has been added to the 6.10-stable tree
Hi Greg,
please drop this patch from all backports. It turned out to be broken
and the old handling has been restored by a revert.
Sorry for the noise. The revert should show up in Linus tree by the end
of the week.
Regards,
Christian.
Am 07.10.24 um 19:50 schrieb gre...@linuxfoundation.org:
This is a note to let you know that I've just added the patch titled
drm/sched: Always wake up correct scheduler in drm_sched_entity_push_job
to the 6.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-sched-always-wake-up-correct-scheduler-in-drm_sched_entity_push_job.patch
and it can be found in the queue-6.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
From cbc8764e29c2318229261a679b2aafd0f9072885 Mon Sep 17 00:00:00 2001
From: Tvrtko Ursulin
Date: Tue, 24 Sep 2024 11:19:08 +0100
Subject: drm/sched: Always wake up correct scheduler in
drm_sched_entity_push_job
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Tvrtko Ursulin
commit cbc8764e29c2318229261a679b2aafd0f9072885 upstream.
Since drm_sched_entity_modify_sched() can modify the entities run queue,
lets make sure to only dereference the pointer once so both adding and
waking up are guaranteed to be consistent.
Alternative of moving the spin_unlock to after the wake up would for now
be more problematic since the same lock is taken inside
drm_sched_rq_update_fifo().
v2:
* Improve commit message. (Philipp)
* Cache the scheduler pointer directly. (Christian)
Signed-off-by: Tvrtko Ursulin
Fixes: b37aced31eb0 ("drm/scheduler: implement a function to modify sched list")
Cc: Christian König
Cc: Alex Deucher
Cc: Luben Tuikov
Cc: Matthew Brost
Cc: David Airlie
Cc: Daniel Vetter
Cc: Philipp Stanner
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.7+
Reviewed-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20240924101914.2713-3-tursu...@igalia.com
Signed-off-by: Christian König
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/scheduler/sched_entity.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -599,6 +599,9 @@ void drm_sched_entity_push_job(struct dr
/* first job wakes up scheduler */
if (first) {
+ struct drm_gpu_scheduler *sched;
+ struct drm_sched_rq *rq;
+
/* Add the entity to the run queue */
spin_lock(&entity->rq_lock);
if (entity->stopped) {
@@ -608,13 +611,16 @@ void drm_sched_entity_push_job(struct dr
return;
}
- drm_sched_rq_add_entity(entity->rq, entity);
+ rq = entity->rq;
+ sched = rq->sched;
+
+ drm_sched_rq_add_entity(rq, entity);
spin_unlock(&entity->rq_lock);
if (drm_sched_policy == DRM_SCHED_POLICY_FIFO)
drm_sched_rq_update_fifo(entity, submit_ts);
- drm_sched_wakeup(entity->rq->sched);
+ drm_sched_wakeup(sched);
}
}
EXPORT_SYMBOL(drm_sched_entity_push_job);
Patches currently in stable-queue which might be from tvrtko.ursu...@igalia.com
are
queue-6.10/drm-sched-always-increment-correct-scheduler-score.patch
queue-6.10/drm-v3d-prevent-out-of-bounds-access-in-performance-query-extensions.patch
queue-6.10/drm-sched-always-wake-up-correct-scheduler-in-drm_sched_entity_push_job.patch
queue-6.10/drm-sched-add-locking-to-drm_sched_entity_modify_sched.patch
Re: Patch "drm/sched: Always wake up correct scheduler in drm_sched_entity_push_job" has been added to the 6.10-stable tree
Or wait a second with that.
Tvrtko which one was the patch we had to revert?
Regards,
Christian.
Am 07.10.24 um 19:53 schrieb Christian König:
Hi Greg,
please drop this patch from all backports. It turned out to be broken
and the old handling has been restored by a revert.
Sorry for the noise. The revert should show up in Linus tree by the
end of the week.
Regards,
Christian.
Am 07.10.24 um 19:50 schrieb gre...@linuxfoundation.org:
This is a note to let you know that I've just added the patch titled
drm/sched: Always wake up correct scheduler in
drm_sched_entity_push_job
to the 6.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-sched-always-wake-up-correct-scheduler-in-drm_sched_entity_push_job.patch
and it can be found in the queue-6.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
From cbc8764e29c2318229261a679b2aafd0f9072885 Mon Sep 17 00:00:00 2001
From: Tvrtko Ursulin
Date: Tue, 24 Sep 2024 11:19:08 +0100
Subject: drm/sched: Always wake up correct scheduler in
drm_sched_entity_push_job
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Tvrtko Ursulin
commit cbc8764e29c2318229261a679b2aafd0f9072885 upstream.
Since drm_sched_entity_modify_sched() can modify the entities run queue,
lets make sure to only dereference the pointer once so both adding and
waking up are guaranteed to be consistent.
Alternative of moving the spin_unlock to after the wake up would for now
be more problematic since the same lock is taken inside
drm_sched_rq_update_fifo().
v2:
* Improve commit message. (Philipp)
* Cache the scheduler pointer directly. (Christian)
Signed-off-by: Tvrtko Ursulin
Fixes: b37aced31eb0 ("drm/scheduler: implement a function to modify
sched list")
Cc: Christian König
Cc: Alex Deucher
Cc: Luben Tuikov
Cc: Matthew Brost
Cc: David Airlie
Cc: Daniel Vetter
Cc: Philipp Stanner
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.7+
Reviewed-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20240924101914.2713-3-tursu...@igalia.com
Signed-off-by: Christian König
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/scheduler/sched_entity.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -599,6 +599,9 @@ void drm_sched_entity_push_job(struct dr
/* first job wakes up scheduler */
if (first) {
+ struct drm_gpu_scheduler *sched;
+ struct drm_sched_rq *rq;
+
/* Add the entity to the run queue */
spin_lock(&entity->rq_lock);
if (entity->stopped) {
@@ -608,13 +611,16 @@ void drm_sched_entity_push_job(struct dr
return;
}
- drm_sched_rq_add_entity(entity->rq, entity);
+ rq = entity->rq;
+ sched = rq->sched;
+
+ drm_sched_rq_add_entity(rq, entity);
spin_unlock(&entity->rq_lock);
if (drm_sched_policy == DRM_SCHED_POLICY_FIFO)
drm_sched_rq_update_fifo(entity, submit_ts);
- drm_sched_wakeup(entity->rq->sched);
+ drm_sched_wakeup(sched);
}
}
EXPORT_SYMBOL(drm_sched_entity_push_job);
Patches currently in stable-queue which might be from
tvrtko.ursu...@igalia.com are
queue-6.10/drm-sched-always-increment-correct-scheduler-score.patch
queue-6.10/drm-v3d-prevent-out-of-bounds-access-in-performance-query-extensions.patch
queue-6.10/drm-sched-always-wake-up-correct-scheduler-in-drm_sched_entity_push_job.patch
queue-6.10/drm-sched-add-locking-to-drm_sched_entity_modify_sched.patch
Re: [PATCH v2 1/2] dt-bindings: display: bridge: sil,sii9022: Add bus-width
On 07/10/2024 10:52, Wadim Egorov wrote: > The SI9022 HDMI transmitter can be configured with a bus-width of 16, > 18, or 24 bits. Introduce a bus-width property to the input endpoint, > specifying the number of parallel RGB input bits connected to the > transmitter. > > Signed-off-by: Wadim Egorov > --- Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
[RESEND PATCH] drm/vmwgfx: Remove unnecessary NULL checks before kvfree()
Since kvfree() already checks if its argument is NULL, an additional check before calling kvfree() is unnecessary and can be removed. Remove both and the following Coccinelle/coccicheck warnings reported by ifnullfree.cocci: WARNING: NULL check before some freeing functions is not needed WARNING: NULL check before some freeing functions is not needed Signed-off-by: Thorsten Blum --- drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c index 890a66a2361f..64bd7d74854e 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c @@ -635,10 +635,8 @@ int vmw_bo_cpu_blit(struct vmw_bo *vmw_dst, kunmap_atomic(d.src_addr); if (d.dst_addr) kunmap_atomic(d.dst_addr); - if (src_pages) - kvfree(src_pages); - if (dst_pages) - kvfree(dst_pages); + kvfree(src_pages); + kvfree(dst_pages); return ret; } -- 2.46.2
Re: [v2,20/31] drm/vc4: Introduce generation number enum
Hi Dave,
On 21.06.2024 17:20, Dave Stevenson wrote:
> From: Maxime Ripard
>
> With the introduction of the BCM2712 support, we will get yet another
> generation of display engine to support.
>
> The binary check of whether it's VC5 or not thus doesn't work anymore,
> especially since some parts of the driver will have changed with BCM2711,
> and some others with BCM2712.
>
> Let's introduce an enum to store the generation the driver is running
> on, which should provide more flexibility.
>
> Signed-off-by: Maxime Ripard
> Signed-off-by: Dave Stevenson
This patch landed recently in linux-next as commit 24c5ed3ddf27
("drm/vc4: Introduce generation number enum"). In my tests I found that
it introduces the following warning on Raspberry Pi3B+ board:
WARNING: lock held when returning to user space!
6.11.0-rc5+ #15405 Tainted: G C
(udev-worker)/161 is leaving the kernel with locks still held!
1 lock held by (udev-worker)/161:
#0: 80008338bff8 (drm_unplug_srcu){.?.?}-{0:0}, at:
drm_dev_enter+0x0/0xdc
I suspect that the error path is somewhere broken and the conversion
triggered that path.
A wild guess (noticed by grepping for 'drm_dev_enter') is that the
following chunk is broken:
> diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
> index 933177cb8d66..7380a02a69a2 100644
> --- a/drivers/gpu/drm/vc4/vc4_hvs.c
> +++ b/drivers/gpu/drm/vc4/vc4_hvs.c
> @@ -224,7 +224,7 @@ static void vc4_hvs_lut_load(struct vc4_hvs *hvs,
> if (!drm_dev_enter(drm, &idx))
> return;
>
> - if (hvs->vc4->is_vc5)
> + if (hvs->vc4->gen == VC4_GEN_4)
> return;
>
> /* The LUT memory is laid out with each HVS channel in order,
as changing the above check to 'if (hvs->vc4->gen > VC4_GEN_4)' fixes this
issue (tested also on top of linux-next). I think that one has to review the
checks again as well as the error paths in the driver.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Re: [PATCH v2 1/1] platform/x86/tuxedo: Add virtual LampArray for TUXEDO
On Fri, 04 Oct 2024, Werner Sembach wrote: > > Am 03.10.24 um 09:59 schrieb Lee Jones: > > On Wed, 02 Oct 2024, Werner Sembach wrote: > > > > > Hi, > > > > > > Am 02.10.24 um 14:52 schrieb Lee Jones: > > > > On Fri, 27 Sep 2024, Werner Sembach wrote: > > > > > > > > > Hi, > > > > > first revision integrating Armins feedback. > > > > > > > > > > Stuff I did not yet change and did not comment on previously: > > > > > - Still have to ask Christoffer why the mutex is required > > > > > - Still using acpi_size instad of size_t in the util functions, > > > > > because the value is put directly into a struct using acpi_size > > > > > - Error messages for __wmi_method_acpi_object_out still in that > > > > > method because they reference method internal variables > > > > > > > > > > Let me know if my reasoning is flawed > > > > Use `git format-patch`'s --annotate and --compose next time please. > > > > > > > I did but --compose does not automatically insert the subject line, that's > > > why i copied it but forgot to change it to 0/1 > > > > > > Sorry for the flawed subject line > > And the missing diff-stat? > > > Also not automatically created by git send-email --compose. is there a flag > I'm not aware of? As above. I use "--annotate --compose". See if that works. -- Lee Jones [李琼斯]
[PATCH] drm/vkms: Add support for ABGR8888 pixel format
Add support for pixel format ABGR, which is the default format
on Android devices. This will allow us to use VKMS as the default
display driver in Android Emulator (Cuttlefish) and increase VKMS
adoption.
Signed-off-by: Paz Zcharya
---
drivers/gpu/drm/vkms/vkms_formats.c | 20
drivers/gpu/drm/vkms/vkms_plane.c | 1 +
drivers/gpu/drm/vkms/vkms_writeback.c | 1 +
3 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/vkms/vkms_formats.c
b/drivers/gpu/drm/vkms/vkms_formats.c
index 040b7f113a3b..9e9d7290388e 100644
--- a/drivers/gpu/drm/vkms/vkms_formats.c
+++ b/drivers/gpu/drm/vkms/vkms_formats.c
@@ -73,6 +73,14 @@ static void XRGB_to_argb_u16(u8 *src_pixels, struct
pixel_argb_u16 *out_pixe
out_pixel->b = (u16)src_pixels[0] * 257;
}
+static void ABGR_to_argb_u16(u8 *src_pixels, struct pixel_argb_u16
*out_pixel)
+{
+ out_pixel->a = (u16)src_pixels[3] * 257;
+ out_pixel->b = (u16)src_pixels[2] * 257;
+ out_pixel->g = (u16)src_pixels[1] * 257;
+ out_pixel->r = (u16)src_pixels[0] * 257;
+}
+
static void ARGB16161616_to_argb_u16(u8 *src_pixels, struct pixel_argb_u16
*out_pixel)
{
__le16 *pixels = (__force __le16 *)src_pixels;
@@ -176,6 +184,14 @@ static void argb_u16_to_XRGB(u8 *dst_pixels, struct
pixel_argb_u16 *in_pixel
dst_pixels[0] = DIV_ROUND_CLOSEST(in_pixel->b, 257);
}
+static void argb_u16_to_ABGR(u8 *dst_pixels, struct pixel_argb_u16
*in_pixel)
+{
+ dst_pixels[3] = DIV_ROUND_CLOSEST(in_pixel->a, 257);
+ dst_pixels[2] = DIV_ROUND_CLOSEST(in_pixel->b, 257);
+ dst_pixels[1] = DIV_ROUND_CLOSEST(in_pixel->g, 257);
+ dst_pixels[0] = DIV_ROUND_CLOSEST(in_pixel->r, 257);
+}
+
static void argb_u16_to_ARGB16161616(u8 *dst_pixels, struct pixel_argb_u16
*in_pixel)
{
__le16 *pixels = (__force __le16 *)dst_pixels;
@@ -234,6 +250,8 @@ void *get_pixel_conversion_function(u32 format)
return &ARGB_to_argb_u16;
case DRM_FORMAT_XRGB:
return &XRGB_to_argb_u16;
+ case DRM_FORMAT_ABGR:
+ return &ABGR_to_argb_u16;
case DRM_FORMAT_ARGB16161616:
return &ARGB16161616_to_argb_u16;
case DRM_FORMAT_XRGB16161616:
@@ -252,6 +270,8 @@ void *get_pixel_write_function(u32 format)
return &argb_u16_to_ARGB;
case DRM_FORMAT_XRGB:
return &argb_u16_to_XRGB;
+ case DRM_FORMAT_ABGR:
+ return &argb_u16_to_ABGR;
case DRM_FORMAT_ARGB16161616:
return &argb_u16_to_ARGB16161616;
case DRM_FORMAT_XRGB16161616:
diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
b/drivers/gpu/drm/vkms/vkms_plane.c
index e5c625ab8e3e..8efd585fc34c 100644
--- a/drivers/gpu/drm/vkms/vkms_plane.c
+++ b/drivers/gpu/drm/vkms/vkms_plane.c
@@ -15,6 +15,7 @@
static const u32 vkms_formats[] = {
DRM_FORMAT_ARGB,
DRM_FORMAT_XRGB,
+ DRM_FORMAT_ABGR,
DRM_FORMAT_XRGB16161616,
DRM_FORMAT_ARGB16161616,
DRM_FORMAT_RGB565
diff --git a/drivers/gpu/drm/vkms/vkms_writeback.c
b/drivers/gpu/drm/vkms/vkms_writeback.c
index bc724cbd5e3a..04cb9c58e7ad 100644
--- a/drivers/gpu/drm/vkms/vkms_writeback.c
+++ b/drivers/gpu/drm/vkms/vkms_writeback.c
@@ -17,6 +17,7 @@
static const u32 vkms_wb_formats[] = {
DRM_FORMAT_ARGB,
DRM_FORMAT_XRGB,
+ DRM_FORMAT_ABGR,
DRM_FORMAT_XRGB16161616,
DRM_FORMAT_ARGB16161616,
DRM_FORMAT_RGB565
--
2.47.0.rc0.187.ge670bccf7e-goog
Re: [PATCH v9 1/5] drm/mediatek: ovl: Fix XRGB format breakage for blend_modes unsupported SoCs
Re: [PATCH v3 13/14] drm/mediatek: Support DRM plane alpha in OVL
On 10/7/24 02:22, Jason-JH Lin (林睿祥) wrote: > > Hi Adam, Yassine, > > Please try the patches below and check if they can fix the downgrade > issue: > [1] Fix degradation problem of alpha blending series > - > https://patchwork.kernel.org/project/linux-mediatek/list/?series=893634 > [2] drm/mediatek: Fix XRGB format breakage for blend_modes unsupported > SoCs > - > https://patchwork.kernel.org/project/linux-mediatek/patch/20241005095234.12925-1-jason-jh@mediatek.com/ > > Regards, > Jason-JH.Lin Jason, I've built 6.12-rc1 with those patch series applied. (I am also not reverting the other commit.) This fixes the issue - I'm able to see the console now. Thank you! Hopefully these can go into 6.12? - Adam Thiede Yes, they will go into 6.12. Hi Adam, Yassine, Since the maintainer, CK, had some comments at the [2], I made some changes for it. Could you please test again only with this single fix patch: [3] drm/mediatek: ovl: Fix XRGB format breakage for blend_modes unsupported SoCs - https://patchwork.kernel.org/project/linux-mediatek/patch/20241007070101.23263-2-jason-jh@mediatek.com/ and see if it can fix your problem? Regards, Jason-JH.Lin Jason, Just this patch on 6.12-rc1 does fix my problem too. Thank you. -Adam
[PATCH v6 4/5] tty: serial: handle HAS_IOPORT dependencies
In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at
compile time. We thus need to add HAS_IOPORT as dependency for those
drivers using them unconditionally. Some 8250 serial drivers support
MMIO only use, so fence only the parts requiring I/O ports and print an
error message if a device can't be supported with the current
configuration.
Co-developed-by: Arnd Bergmann
Signed-off-by: Arnd Bergmann
Signed-off-by: Niklas Schnelle
---
drivers/tty/Kconfig | 4 +--
drivers/tty/serial/8250/8250_early.c | 4 +++
drivers/tty/serial/8250/8250_pci.c| 49 ++-
drivers/tty/serial/8250/8250_pcilib.c | 4 +++
drivers/tty/serial/8250/8250_port.c | 47 ++---
drivers/tty/serial/8250/Kconfig | 4 +--
drivers/tty/serial/Kconfig| 2 +-
7 files changed, 98 insertions(+), 16 deletions(-)
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index
a45d423ad10f02c3a818021bbb18655a8b690500..63a494d36a1fdceba5a7b39f4516060e48af0cc6
100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -220,7 +220,7 @@ config MOXA_INTELLIO
config MOXA_SMARTIO
tristate "Moxa SmartIO support v. 2.0"
- depends on SERIAL_NONSTANDARD && PCI
+ depends on SERIAL_NONSTANDARD && PCI && HAS_IOPORT
help
Say Y here if you have a Moxa SmartIO multiport serial card and/or
want to help develop a new version of this driver.
@@ -302,7 +302,7 @@ config GOLDFISH_TTY_EARLY_CONSOLE
config IPWIRELESS
tristate "IPWireless 3G UMTS PCMCIA card support"
- depends on PCMCIA && NETDEVICES
+ depends on PCMCIA && NETDEVICES && HAS_IOPORT
select PPP
help
This is a driver for 3G UMTS PCMCIA card from IPWireless company. In
diff --git a/drivers/tty/serial/8250/8250_early.c
b/drivers/tty/serial/8250/8250_early.c
index
6176083d0341ca10edebe5c4eebfffc922a61472..84242292176570cd2c92afbd4755d303827a4abc
100644
--- a/drivers/tty/serial/8250/8250_early.c
+++ b/drivers/tty/serial/8250/8250_early.c
@@ -46,8 +46,10 @@ static unsigned int serial8250_early_in(struct uart_port
*port, int offset)
return readl(port->membase + offset);
case UPIO_MEM32BE:
return ioread32be(port->membase + offset);
+#ifdef CONFIG_HAS_IOPORT
case UPIO_PORT:
return inb(port->iobase + offset);
+#endif
default:
return 0;
}
@@ -70,9 +72,11 @@ static void serial8250_early_out(struct uart_port *port, int
offset, int value)
case UPIO_MEM32BE:
iowrite32be(value, port->membase + offset);
break;
+#ifdef CONFIG_HAS_IOPORT
case UPIO_PORT:
outb(value, port->iobase + offset);
break;
+#endif
}
}
diff --git a/drivers/tty/serial/8250/8250_pci.c
b/drivers/tty/serial/8250/8250_pci.c
index
6709b6a5f3011db38acc58dc7223158fe4fcf72e..6a638feb44e443a1998980dd037748f227ec1bc8
100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -156,6 +156,14 @@ static const struct pci_device_id pci_use_msi[] = {
static int pci_default_setup(struct serial_private*,
const struct pciserial_board*, struct uart_8250_port *, int);
+static int serial_8250_need_ioport(struct pci_dev *dev)
+{
+ dev_warn(&dev->dev,
+"Serial port not supported because of missing I/O resource\n");
+
+ return -ENXIO;
+}
+
static void moan_device(const char *str, struct pci_dev *dev)
{
pci_err(dev, "%s\n"
@@ -964,6 +972,9 @@ static int pci_ite887x_init(struct pci_dev *dev)
struct resource *iobase = NULL;
u32 miscr, uartbar, ioport;
+ if (!IS_ENABLED(CONFIG_HAS_IOPORT))
+ return serial_8250_need_ioport(dev);
+
/* search for the base-ioport */
for (i = 0; i < ARRAY_SIZE(inta_addr); i++) {
iobase = request_region(inta_addr[i], ITE_887x_IOSIZE,
@@ -1514,6 +1525,9 @@ static int pci_quatech_init(struct pci_dev *dev)
const struct pci_device_id *match;
bool amcc = false;
+ if (!IS_ENABLED(CONFIG_HAS_IOPORT))
+ return serial_8250_need_ioport(dev);
+
match = pci_match_id(quatech_cards, dev);
if (match)
amcc = match->driver_data;
@@ -1538,6 +1552,9 @@ static int pci_quatech_setup(struct serial_private *priv,
const struct pciserial_board *board,
struct uart_8250_port *port, int idx)
{
+ if (!IS_ENABLED(CONFIG_HAS_IOPORT))
+ return serial_8250_need_ioport(priv->dev);
+
/* Needed by pci_quatech calls below */
port->port.iobase = pci_resource_start(priv->dev,
FL_GET_BASE(board->flags));
/* Set up the clocking */
@@ -1655,6 +1672,9 @@ static int pci_fintek_setup(struct serial_private *priv,
u8 config_base;
u16 iobase;
+ if (!IS_ENABLED(CONFIG_HA
[PATCH v6 3/5] drm: handle HAS_IOPORT dependencies
In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at
compile time. We thus need to add HAS_IOPORT as dependency for those
drivers using them. In the bochs driver there is optional MMIO support
detected at runtime, warn if this isn't taken when HAS_IOPORT is not
defined.
There is also a direct and hard coded use in cirrus.c which according to
the comment is only necessary during resume. Let's just skip this as
for example s390 which doesn't have I/O port support also doesen't
support suspend/resume.
Co-developed-by: Arnd Bergmann
Signed-off-by: Arnd Bergmann
Signed-off-by: Niklas Schnelle
---
drivers/gpu/drm/gma500/Kconfig | 2 +-
drivers/gpu/drm/qxl/Kconfig| 1 +
drivers/gpu/drm/tiny/bochs.c | 17 +
drivers/gpu/drm/tiny/cirrus.c | 2 ++
drivers/gpu/drm/xe/Kconfig | 2 +-
5 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
index
efb4a2dd2f80885cb59c925d09401002278d7d61..23b7c14de5e29238ece939d5822d8a9ffc4675cc
100644
--- a/drivers/gpu/drm/gma500/Kconfig
+++ b/drivers/gpu/drm/gma500/Kconfig
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0-only
config DRM_GMA500
tristate "Intel GMA500/600/3600/3650 KMS Framebuffer"
- depends on DRM && PCI && X86 && MMU
+ depends on DRM && PCI && X86 && MMU && HAS_IOPORT
select DRM_KMS_HELPER
select FB_IOMEM_HELPERS if DRM_FBDEV_EMULATION
select I2C
diff --git a/drivers/gpu/drm/qxl/Kconfig b/drivers/gpu/drm/qxl/Kconfig
index
ca3f51c2a8fe1a383f8a2479f04b5c0b3fb14e44..d0e0d440c8d96564cb7b8ffd2385c44fc43f873d
100644
--- a/drivers/gpu/drm/qxl/Kconfig
+++ b/drivers/gpu/drm/qxl/Kconfig
@@ -2,6 +2,7 @@
config DRM_QXL
tristate "QXL virtual GPU"
depends on DRM && PCI && MMU
+ depends on HAS_IOPORT
select DRM_KMS_HELPER
select DRM_TTM
select DRM_TTM_HELPER
diff --git a/drivers/gpu/drm/tiny/bochs.c b/drivers/gpu/drm/tiny/bochs.c
index
31fc5d839e106ea4d5c8fe42d1bfc3c70291e3fb..0ed78d3d5774778f91de972ac27056938036e722
100644
--- a/drivers/gpu/drm/tiny/bochs.c
+++ b/drivers/gpu/drm/tiny/bochs.c
@@ -2,6 +2,7 @@
#include
#include
+#include
#include
#include
@@ -105,7 +106,9 @@ static void bochs_vga_writeb(struct bochs_device *bochs,
u16 ioport, u8 val)
writeb(val, bochs->mmio + offset);
} else {
+#ifdef CONFIG_HAS_IOPORT
outb(val, ioport);
+#endif
}
}
@@ -119,7 +122,11 @@ static u8 bochs_vga_readb(struct bochs_device *bochs, u16
ioport)
return readb(bochs->mmio + offset);
} else {
+#ifdef CONFIG_HAS_IOPORT
return inb(ioport);
+#else
+ return 0xff;
+#endif
}
}
@@ -132,8 +139,12 @@ static u16 bochs_dispi_read(struct bochs_device *bochs,
u16 reg)
ret = readw(bochs->mmio + offset);
} else {
+#ifdef CONFIG_HAS_IOPORT
outw(reg, VBE_DISPI_IOPORT_INDEX);
ret = inw(VBE_DISPI_IOPORT_DATA);
+#else
+ ret = 0x;
+#endif
}
return ret;
}
@@ -145,8 +156,10 @@ static void bochs_dispi_write(struct bochs_device *bochs,
u16 reg, u16 val)
writew(val, bochs->mmio + offset);
} else {
+#ifdef CONFIG_HAS_IOPORT
outw(reg, VBE_DISPI_IOPORT_INDEX);
outw(val, VBE_DISPI_IOPORT_DATA);
+#endif
}
}
@@ -229,6 +242,10 @@ static int bochs_hw_init(struct drm_device *dev)
return -ENOMEM;
}
} else {
+ if (!IS_ENABLED(CONFIG_HAS_IOPORT)) {
+ DRM_ERROR("I/O ports are not supported\n");
+ return -EIO;
+ }
ioaddr = VBE_DISPI_IOPORT_INDEX;
iosize = 2;
if (!request_region(ioaddr, iosize, "bochs-drm")) {
diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c
index
751326e3d9c374baf72115492aeefff2b73869f0..e31e1df029ab0272c4a1ff0ab3eb026ca679b560
100644
--- a/drivers/gpu/drm/tiny/cirrus.c
+++ b/drivers/gpu/drm/tiny/cirrus.c
@@ -509,8 +509,10 @@ static void cirrus_crtc_helper_atomic_enable(struct
drm_crtc *crtc,
cirrus_mode_set(cirrus, &crtc_state->mode);
+#ifdef CONFIG_HAS_IOPORT
/* Unblank (needed on S3 resume, vgabios doesn't do it then) */
outb(VGA_AR_ENABLE_DISPLAY, VGA_ATT_W);
+#endif
drm_dev_exit(idx);
}
diff --git a/drivers/gpu/drm/xe/Kconfig b/drivers/gpu/drm/xe/Kconfig
index
7bbe46a98ff1f449bc2af30686585a00e9e8af93..116f58774135fc3a9f37d6d72d41340f5c812297
100644
--- a/drivers/gpu/drm/xe/Kconfig
+++ b/drivers/gpu/drm/xe/Kconfig
@@ -49,7 +49,7 @@ config DRM_XE
config DRM_XE_DISPLAY
bool "Enable display support"
- depends on DRM_XE && DRM_XE=m
+ depends on DRM_XE && DRM_XE=m && HAS_IOPORT
select FB_IOMEM_HELPERS
select I2C
select I2C_AL
[PATCH v6 5/5] asm-generic/io.h: Remove I/O port accessors for HAS_IOPORT=n
With all subsystems and drivers either declaring their dependence on
HAS_IOPORT or fencing I/O port specific code sections we can finally
make inb()/outb() and friends compile-time dependent on HAS_IOPORT as
suggested by Linus in the linked mail. The main benefit of this is that
on platforms such as s390 which have no meaningful way of implementing
inb()/outb() their use without the proper HAS_IOPORT dependency will
result in easy to catch and fix compile-time errors instead of compiling
code that can never work.
Link:
https://lore.kernel.org/lkml/CAHk-=wg80je=k7madf4e7wrrnp37e3qh6y10svhdc7o8sz_...@mail.gmail.com/
Co-developed-by: Arnd Bergmann
Signed-off-by: Arnd Bergmann
Signed-off-by: Niklas Schnelle
---
include/asm-generic/io.h | 60
1 file changed, 60 insertions(+)
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index
80de699bf6af4b7b77f582c0469c43e978f67a43..1027be6a62bcbcd5f6797e0fa42035208d0ca79f
100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -540,6 +540,7 @@ static inline void writesq(volatile void __iomem *addr,
const void *buffer,
#if !defined(inb) && !defined(_inb)
#define _inb _inb
+#ifdef CONFIG_HAS_IOPORT
static inline u8 _inb(unsigned long addr)
{
u8 val;
@@ -549,10 +550,15 @@ static inline u8 _inb(unsigned long addr)
__io_par(val);
return val;
}
+#else
+u8 _inb(unsigned long addr)
+ __compiletime_error("inb()) requires CONFIG_HAS_IOPORT");
+#endif
#endif
#if !defined(inw) && !defined(_inw)
#define _inw _inw
+#ifdef CONFIG_HAS_IOPORT
static inline u16 _inw(unsigned long addr)
{
u16 val;
@@ -562,10 +568,15 @@ static inline u16 _inw(unsigned long addr)
__io_par(val);
return val;
}
+#else
+u16 _inw(unsigned long addr)
+ __compiletime_error("inw() requires CONFIG_HAS_IOPORT");
+#endif
#endif
#if !defined(inl) && !defined(_inl)
#define _inl _inl
+#ifdef CONFIG_HAS_IOPORT
static inline u32 _inl(unsigned long addr)
{
u32 val;
@@ -575,36 +586,55 @@ static inline u32 _inl(unsigned long addr)
__io_par(val);
return val;
}
+#else
+u32 _inl(unsigned long addr)
+ __compiletime_error("inl() requires CONFIG_HAS_IOPORT");
+#endif
#endif
#if !defined(outb) && !defined(_outb)
#define _outb _outb
+#ifdef CONFIG_HAS_IOPORT
static inline void _outb(u8 value, unsigned long addr)
{
__io_pbw();
__raw_writeb(value, PCI_IOBASE + addr);
__io_paw();
}
+#else
+void _outb(u8 value, unsigned long addr)
+ __compiletime_error("outb() requires CONFIG_HAS_IOPORT");
+#endif
#endif
#if !defined(outw) && !defined(_outw)
#define _outw _outw
+#ifdef CONFIG_HAS_IOPORT
static inline void _outw(u16 value, unsigned long addr)
{
__io_pbw();
__raw_writew((u16 __force)cpu_to_le16(value), PCI_IOBASE + addr);
__io_paw();
}
+#else
+void _outw(u16 value, unsigned long addr)
+ __compiletime_error("outw() requires CONFIG_HAS_IOPORT");
+#endif
#endif
#if !defined(outl) && !defined(_outl)
#define _outl _outl
+#ifdef CONFIG_HAS_IOPORT
static inline void _outl(u32 value, unsigned long addr)
{
__io_pbw();
__raw_writel((u32 __force)cpu_to_le32(value), PCI_IOBASE + addr);
__io_paw();
}
+#else
+void _outl(u32 value, unsigned long addr)
+ __compiletime_error("outl() requires CONFIG_HAS_IOPORT");
+#endif
#endif
#include
@@ -688,53 +718,83 @@ static inline void outl_p(u32 value, unsigned long addr)
#ifndef insb
#define insb insb
+#ifdef CONFIG_HAS_IOPORT
static inline void insb(unsigned long addr, void *buffer, unsigned int count)
{
readsb(PCI_IOBASE + addr, buffer, count);
}
+#else
+void insb(unsigned long addr, void *buffer, unsigned int count)
+ __compiletime_error("insb() requires HAS_IOPORT");
+#endif
#endif
#ifndef insw
#define insw insw
+#ifdef CONFIG_HAS_IOPORT
static inline void insw(unsigned long addr, void *buffer, unsigned int count)
{
readsw(PCI_IOBASE + addr, buffer, count);
}
+#else
+void insw(unsigned long addr, void *buffer, unsigned int count)
+ __compiletime_error("insw() requires HAS_IOPORT");
+#endif
#endif
#ifndef insl
#define insl insl
+#ifdef CONFIG_HAS_IOPORT
static inline void insl(unsigned long addr, void *buffer, unsigned int count)
{
readsl(PCI_IOBASE + addr, buffer, count);
}
+#else
+void insl(unsigned long addr, void *buffer, unsigned int count)
+ __compiletime_error("insl() requires HAS_IOPORT");
+#endif
#endif
#ifndef outsb
#define outsb outsb
+#ifdef CONFIG_HAS_IOPORT
static inline void outsb(unsigned long addr, const void *buffer,
unsigned int count)
{
writesb(PCI_IOBASE + addr, buffer, count);
}
+#else
+void outsb(unsigned long addr, const void *buffer, unsigned int count)
+ __compiletime_error("outsb() requires HAS_IOPORT");
+#endif
#endif
#ifndef outsw
#define outsw outsw
+#i
[PATCH v6 2/5] Bluetooth: add HAS_IOPORT dependencies
In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at compile time. We thus need to add HAS_IOPORT as dependency for those drivers using them. Co-developed-by: Arnd Bergmann Signed-off-by: Arnd Bergmann Signed-off-by: Niklas Schnelle --- drivers/bluetooth/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig index 18767b54df352e929692850dc789d9377839e094..4ab32abf0f48644715d4c27ec0d2fdaccef62b76 100644 --- a/drivers/bluetooth/Kconfig +++ b/drivers/bluetooth/Kconfig @@ -336,7 +336,7 @@ config BT_HCIBFUSB config BT_HCIDTL1 tristate "HCI DTL1 (PC Card) driver" - depends on PCMCIA + depends on PCMCIA && HAS_IOPORT help Bluetooth HCI DTL1 (PC Card) driver. This driver provides support for Bluetooth PCMCIA devices with @@ -349,7 +349,7 @@ config BT_HCIDTL1 config BT_HCIBT3C tristate "HCI BT3C (PC Card) driver" - depends on PCMCIA + depends on PCMCIA && HAS_IOPORT select FW_LOADER help Bluetooth HCI BT3C (PC Card) driver. @@ -363,7 +363,7 @@ config BT_HCIBT3C config BT_HCIBLUECARD tristate "HCI BlueCard (PC Card) driver" - depends on PCMCIA + depends on PCMCIA && HAS_IOPORT help Bluetooth HCI BlueCard (PC Card) driver. This driver provides support for Bluetooth PCMCIA devices with -- 2.43.0
[PATCH v6 0/5] treewide: Remove I/O port accessors for HAS_IOPORT=n
Hi All, This is a follow up in my long running effort of making inb()/outb() and similar I/O port accessors compile-time optional. After initially sending this as a treewide series with the latest revision at[0] we switched to per subsystem series. Now though as we're left with only 5 patches left I'm going back to a single series with Arnd planning to take this via the the asm-generic tree. This series may also be viewed for your convenience on my git.kernel.org tree[1] under the b4/has_ioport branch. As for compile-time vs runtime see Linus' reply to my first attempt[2]. Thanks, Niklas [0] https://lore.kernel.org/all/20230522105049.1467313-1-schne...@linux.ibm.com/ [1] https://git.kernel.org/pub/scm/linux/kernel/git/niks/linux.git [2] https://lore.kernel.org/lkml/CAHk-=wg80je=k7madf4e7wrrnp37e3qh6y10svhdc7o8sz_...@mail.gmail.com/ Changes since v5 / per subsystem patches: drm: - Add HAS_IOPORT dependency for GMA500 tty: serial: - Make 8250 PCI driver emit an error message when trying to use devices which require I/O ports without CONFIG_HAS_IOPORT (Maciej) - Use early returns + dead code elimination to skip inb()/outb() uses in quirks (Arnd) - In 8250 PCI driver also handle fintek and moxi quirks - In 8250 ports code handle um's defined(__i385__) && defined(CONFIG_HAS_IOPORT) case - Use IS_ENABLED() early return also in is_upf_fourport() __always_inline to force constant folding Signed-off-by: Niklas Schnelle --- Niklas Schnelle (5): hexagon: Don't select GENERIC_IOMAP without HAS_IOPORT support Bluetooth: add HAS_IOPORT dependencies drm: handle HAS_IOPORT dependencies tty: serial: handle HAS_IOPORT dependencies asm-generic/io.h: Remove I/O port accessors for HAS_IOPORT=n arch/hexagon/Kconfig | 1 - drivers/bluetooth/Kconfig | 6 ++-- drivers/gpu/drm/gma500/Kconfig| 2 +- drivers/gpu/drm/qxl/Kconfig | 1 + drivers/gpu/drm/tiny/bochs.c | 17 ++ drivers/gpu/drm/tiny/cirrus.c | 2 ++ drivers/gpu/drm/xe/Kconfig| 2 +- drivers/tty/Kconfig | 4 +-- drivers/tty/serial/8250/8250_early.c | 4 +++ drivers/tty/serial/8250/8250_pci.c| 49 +++- drivers/tty/serial/8250/8250_pcilib.c | 4 +++ drivers/tty/serial/8250/8250_port.c | 47 +-- drivers/tty/serial/8250/Kconfig | 4 +-- drivers/tty/serial/Kconfig| 2 +- include/asm-generic/io.h | 60 +++ 15 files changed, 183 insertions(+), 22 deletions(-) --- base-commit: 8cf0b93919e13d1e8d4466eb4080a4c4d9d66d7b change-id: 20241004-b4-has_ioport-60ac6ce1deb6 Best regards, -- Niklas Schnelle
[PATCH v6 1/5] hexagon: Don't select GENERIC_IOMAP without HAS_IOPORT support
In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at compile time. As hexagon does not support I/O port access it also the GENERIC_IOMAP mechanism of dynamically choosing between I/O port and MMIO access doesn't work so don't select it. Reviewed-by: Brian Cain Co-developed-by: Arnd Bergmann Signed-off-by: Arnd Bergmann Signed-off-by: Niklas Schnelle --- arch/hexagon/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig index e233b5efa2761e35c416cbc147f6b6422a7c5b8f..5ea1bf4b7d4f5471a9c39ee9fb5c701455d21342 100644 --- a/arch/hexagon/Kconfig +++ b/arch/hexagon/Kconfig @@ -31,7 +31,6 @@ config HEXAGON select HAVE_ARCH_TRACEHOOK select NEED_SG_DMA_LENGTH select NO_IOPORT_MAP - select GENERIC_IOMAP select GENERIC_IOREMAP select GENERIC_SMP_IDLE_THREAD select STACKTRACE_SUPPORT -- 2.43.0
Re: NULL pointer dereference with kernel 6.12.0-rc1 and ARUBA GPU
Hi Am 30.09.24 um 19:54 schrieb Christian König: I've been running into the same issue as well. Going to take a look. Any results? Christian. Am 30.09.24 um 17:25 schrieb Arthur Marsh: [ 13.069630] [drm] radeon kernel modesetting enabled. [ 13.069681] radeon :00:01.0: vgaarb: deactivate vga console [ 13.070435] Console: switching to colour dummy device 80x25 [ 13.070632] [drm] initializing kernel modesetting (ARUBA 0x1002:0x990C 0x1002:0x0123 0x00). [ 13.070718] ATOM BIOS: 113 [ 13.070778] radeon :00:01.0: VRAM: 768M 0x - 0x2FFF (768M used) [ 13.070781] radeon :00:01.0: GTT: 1024M 0x3000 - 0x6FFF [ 13.070785] [drm] Detected VRAM RAM=768M, BAR=256M [ 13.070786] [drm] RAM width 64bits DDR [ 13.070884] [drm] radeon: 768M of VRAM memory ready [ 13.070885] [drm] radeon: 1024M of GTT memory ready. [ 13.070896] [drm] Loading ARUBA Microcode [ 13.504398] [drm] Internal thermal controller without fan control [ 13.504566] [drm] radeon: dpm initialized [ 13.839229] [drm] Found VCE firmware/feedback version 50.0.1 / 17! [ 13.839264] [drm] GART: num cpu pages 262144, num gpu pages 262144 [ 13.863929] [drm] PCIE GART of 1024M enabled (table at 0x001D6000). [ 13.864085] radeon :00:01.0: WB enabled [ 13.864088] radeon :00:01.0: fence driver on ring 0 use gpu addr 0x3c00 [ 13.864467] radeon :00:01.0: fence driver on ring 5 use gpu addr 0x00075a18 [ 13.884497] radeon :00:01.0: fence driver on ring 6 use gpu addr 0x3c18 [ 13.884502] radeon :00:01.0: fence driver on ring 7 use gpu addr 0x3c1c [ 13.884503] radeon :00:01.0: fence driver on ring 1 use gpu addr 0x3c04 [ 13.884505] radeon :00:01.0: fence driver on ring 2 use gpu addr 0x3c08 [ 13.884506] radeon :00:01.0: fence driver on ring 3 use gpu addr 0x3c0c [ 13.884507] radeon :00:01.0: fence driver on ring 4 use gpu addr 0x3c10 [ 13.884862] radeon :00:01.0: radeon: MSI limited to 32-bit [ 13.884921] radeon :00:01.0: radeon: using MSI. [ 13.885003] [drm] radeon: irq initialized. [ 13.903273] [drm] ring test on 0 succeeded in 3 usecs [ 13.903281] [drm] ring test on 3 succeeded in 4 usecs [ 13.903286] [drm] ring test on 4 succeeded in 3 usecs [ 13.949128] [drm] ring test on 5 succeeded in 2 usecs [ 13.968988] [drm] UVD initialized successfully. [ 14.078221] [drm] ring test on 6 succeeded in 17 usecs [ 14.078234] [drm] ring test on 7 succeeded in 3 usecs [ 14.078236] [drm] VCE initialized successfully. [ 14.078314] snd_hda_intel :00:01.1: bound :00:01.0 (ops radeon_audio_component_bind_ops [radeon]) [ 14.078502] [drm] ib test on ring 0 succeeded in 0 usecs [ 14.078555] [drm] ib test on ring 3 succeeded in 0 usecs [ 14.078606] [drm] ib test on ring 4 succeeded in 0 usecs [ 14.153378] mc: Linux media interface: v0.10 [ 14.593759] usb 1-3: dvb_usb_v2: found a 'Realtek RTL2832U reference design' in warm state [ 14.614227] [drm] ib test on ring 5 succeeded [ 14.625865] usb 1-3: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer [ 14.625885] dvbdev: DVB: registering new adapter (Realtek RTL2832U reference design) [ 14.625889] usb 1-3: media controller created [ 14.627064] dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered. [ 14.801142] i2c i2c-5: Added multiplexed i2c bus 6 [ 14.801149] rtl2832 5-0010: Realtek RTL2832 successfully attached [ 14.801176] usb 1-3: DVB: registering adapter 0 frontend 0 (Realtek RTL2832 (DVB-T))... [ 14.801189] dvbdev: dvb_create_media_entity: media entity 'Realtek RTL2832 (DVB-T)' registered. [ 14.957783] i2c i2c-6: fc0012: Fitipower FC0012 successfully identified [ 15.158461] [drm] ib test on ring 6 succeeded [ 15.178787] videodev: Linux video capture interface: v2.00 [ 15.460709] rtl2832_sdr rtl2832_sdr.1.auto: Registered as swradio0 [ 15.460715] rtl2832_sdr rtl2832_sdr.1.auto: Realtek RTL2832 SDR attached [ 15.460718] rtl2832_sdr rtl2832_sdr.1.auto: SDR API is still slightly experimental and functionality changes may follow [ 15.477759] usb 1-3: dvb_usb_v2: 'Realtek RTL2832U reference design' successfully initialized and connected [ 15.477878] usbcore: registered new interface driver dvb_usb_rtl28xxu [ 15.670413] [drm] ib test on ring 7 succeeded [ 15.67] BUG: kernel NULL pointer dereference, address: 0050 [ 15.671114] #PF: supervisor read access in kernel mode [ 15.671117] #PF: error_code(0x) - not-present page [ 15.671119] PGD 0 P4D 0 [ 15.671123] Oops: Oops: [#1] PREEMPT_RT SMP NOPTI [ 15.671127] CPU: 2 UID: 0 PID: 437 Comm: udevd Not tainted 6.12.0-rc1 #6131 [ 15.671132] Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./F2A78M-HD2, BIOS F2 05/28/2014 [ 15.671134] R
Re: [PATCH] drm/radeon: add late_register for connector
That's the issue I was working on, give me 10 minutes to send out the fix.
Regards,
Christian.
Am 07.10.24 um 06:49 schrieb Hoi Pok Wu:
Thank you. I am looking at the problem now.
On Mon, Oct 7, 2024 at 1:37 AM Christophe Leroy
wrote:
Le 06/10/2024 à 18:56, Christian Zigotzky a écrit :
On 03 October 2024 at 08:06 am, Wu Hoi Pok wrote:
This is a fix patch not tested yet,
for a bug I introduce in previous rework of radeon driver.
The bug is a null dereference in 'aux.dev', which is the
'device' not registered, resulting in kernel panic. By having
'late_register', the connector should be registered after
'drm_dev_register' automatically.
Please help testing thank you.
Hello Wu Hoi Pok,
Thanks a lot for your patch. Unfortunately there is a new issue after
patching the RC1. Could you please fix the following issue?
Thanks,
Christian
---
Linux fienix 6.12.0-rc1-2-powerpc64-smp #1 SMP Fri Oct 4 08:55:45 CEST
2024 ppc64 GNU/Linux
[ 29.167145] systemd[1]: Sent message type=signal sender=n/a
destination=n/a
path=/org/freedesktop/systemd1/unit/NetworkManager_2eservice
interface=org.freedesktop.DBus.Properties member=PropertiesChanged
cookie=103 reply_cookie=0 signature=sa{sv}as error-name=n/a
error-message=n/a
[ 29.542140] systemd-journald[1301]: Successfully sent stream file
descriptor to service manager.
[ 29.561863] BUG: Kernel NULL pointer dereference on read at 0x
[ 29.567156] Faulting instruction address: 0xc0c973c0
[ 29.571574] cpu 0x1: Vector: 300 (Data Access) at [c6f97640]
[ 29.576637] pc: c0c973c0: .drm_gem_object_free+0x20/0x70
[ 29.581708] lr: c0d28dd8: .radeon_bo_unref+0x58/0x90
[ 29.586428] sp: c6f978e0
[ 29.588695]msr: 90009032
[ 29.590962]dar: 0
[ 29.591925] dsisr: 4000
[ 29.593496] current = 0xc85b1f00
[ 29.596286] paca= 0xc0003680 irqmask: 0x03
irq_happened: 0x01
[ 29.602119] pid = 1524, comm = Xorg.wrap
[ 29.605257] Linux version 6.12.0-rc1-2-powerpc64-smp
(geeko@buildhost) (powerpc64-suse-linux-gcc (SUSE Linux) 7.5.0, GNU ld
(GNU Binutils; devel:gcc / SLE-15) 2.43.1.20240828-150300.536) #1 SMP
Fri Oct 4 08:55:45 CEST 2024
[ 29.623892] enter ? for help
[ 29.625487] [c6f97960] c0d28dd8
.radeon_bo_unref+0x58/0x90
[ 29.631083] [c6f979e0] c0e287b0
.radeon_vm_fini+0x260/0x330
[ 29.636765] [c6f97aa0] c0d07c94
.radeon_driver_postclose_kms+0x1a4/0x1f0
[ 29.643579] [c6f97b30] c0c9374c
.drm_file_free+0x28c/0x300
[ 29.649174] [c6f97be0] c0c93900 .drm_release+0x90/0x170
[ 29.654508] [c6f97c70] c0304790 .__fput+0x120/0x3b0
[ 29.659495] [c6f97d10] c02fe0fc .__se_sys_close+0x4c/0xc0
[ 29.665004] [c6f97d90] c0025bac
.system_call_exception+0x22c/0x260
[ 29.671295] [c6f97e10] c000b554
system_call_common+0xf4/0x258
[ 29.677164] --- Exception: c00 (System Call) at 006b2b48
[ 29.681876] SP (fff4b3d0) is in userspace
[ 29.684577] 1:mon>
[ 31.666727] Oops: Kernel access of bad area, sig: 11 [#1]
[ 31.670829] BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 A-EON Amigaone X1000
[ 31.676144] Modules linked in: snd_hda_codec_idt
snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg
snd_hda_codec snd_hda_core dm_mod
[ 31.688703] CPU: 1 UID: 0 PID: 1524 Comm: Xorg.wrap Not tainted
6.12.0-rc1-2-powerpc64-smp #1
[ 31.695932] Hardware name: pasemi,nemo PA6T 0x900102 A-EON Amigaone X1000
[ 31.701417] NIP: c0c973c0 LR: c0d28dd8 CTR:
c0d07af0
[ 31.707250] REGS: c6f97640 TRAP: 0300 Not tainted
(6.12.0-rc1-2-powerpc64-smp)
[ 31.714128] MSR: 90009032 CR:
2800 XER: 2000
[ 31.720773] DAR: DSISR: 4000 IRQMASK: 0
GPR00: c0d28dd8 c6f978e0
c207a800 c85f5468
GPR04: 0b9b 0b9a
000179779000 c86a4b00
GPR08:
0001
GPR12: 48002202 c0003680
GPR16: 006e3318 0001
006e289c 0063
GPR20: c04064a0 007f0088
fff4c734 007d165c
GPR24: 007d1668 c00024b6a220
c3588000 c00024b6a200
GPR28: c3b3cc00 c00024b6a248
c2d48820 c85f5468
[ 31.778903] NIP [c0c973c0] .drm_gem_object_free+0x20/0x70
[ 31.783701] LR [c0d28dd8] .radeon_bo_unref+0x58/0x90
[ 31.788062] Call Trace:
[ 31.789199] [c6f978e0] [c6f97990] 0xc6f97990
(unreliable)
[ 31.795388] [c6f97960] [c0d28dd8]
.radeon_bo_unref+0x58/0x90
[ 31.801142] [c6f979e0] [c0e2
Re: [PATCH][next] drm/i915/display: Fix spelling mistake "Uncomressed" -> "Uncompressed"
On Wed, Oct 02, 2024 at 01:32:29PM +0530, Nautiyal, Ankit K wrote: > > On 10/2/2024 1:19 PM, Colin Ian King wrote: > > There is a spelling mistake in a drm_WARN message. Fix it. > > > > Signed-off-by: Colin Ian King > Reviewed-by: Ankit Nautiyal pushed, thanks > > --- > > drivers/gpu/drm/i915/display/intel_display.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > > b/drivers/gpu/drm/i915/display/intel_display.c > > index 74311bb9d290..a5057ee4cbe5 100644 > > --- a/drivers/gpu/drm/i915/display/intel_display.c > > +++ b/drivers/gpu/drm/i915/display/intel_display.c > > @@ -3811,7 +3811,7 @@ static void enabled_joiner_pipes(struct > > drm_i915_private *dev_priv, > > secondary_ultrajoiner_pipes); > > drm_WARN(display->drm, (uncompressed_joiner_pipes & bigjoiner_pipes) != > > 0, > > -"Uncomressed joiner pipes(%#x) and bigjoiner pipes(%#x) can't > > intersect\n", > > +"Uncompressed joiner pipes(%#x) and bigjoiner pipes(%#x) can't > > intersect\n", > > uncompressed_joiner_pipes, bigjoiner_pipes); > > drm_WARN(display->drm, secondary_bigjoiner_pipes !=
Re: [PATCH] drm/amdgpu: fix typos
Applied. Thanks! On Sun, Oct 6, 2024 at 7:28 AM Andrew Kreimer wrote: > > Fix typos in comments: "wether -> whether". > > Signed-off-by: Andrew Kreimer > --- > drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 4 ++-- > drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 4 ++-- > drivers/gpu/drm/amd/amdgpu/gfx_v12_0.c | 2 +- > drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 4 ++-- > drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 2 +- > drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 +- > 6 files changed, 9 insertions(+), 9 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c > b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c > index c544ea2aea6e..87247055a666 100644 > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c > @@ -6374,7 +6374,7 @@ static int gfx_v10_0_cp_gfx_resume(struct amdgpu_device > *adev) > WREG32_SOC15(GC, 0, mmCP_RB0_WPTR, lower_32_bits(ring->wptr)); > WREG32_SOC15(GC, 0, mmCP_RB0_WPTR_HI, upper_32_bits(ring->wptr)); > > - /* set the wb address wether it's enabled or not */ > + /* set the wb address whether it's enabled or not */ > rptr_addr = ring->rptr_gpu_addr; > WREG32_SOC15(GC, 0, mmCP_RB0_RPTR_ADDR, lower_32_bits(rptr_addr)); > WREG32_SOC15(GC, 0, mmCP_RB0_RPTR_ADDR_HI, upper_32_bits(rptr_addr) & > @@ -6412,7 +6412,7 @@ static int gfx_v10_0_cp_gfx_resume(struct amdgpu_device > *adev) > ring->wptr = 0; > WREG32_SOC15(GC, 0, mmCP_RB1_WPTR, lower_32_bits(ring->wptr)); > WREG32_SOC15(GC, 0, mmCP_RB1_WPTR_HI, > upper_32_bits(ring->wptr)); > - /* Set the wb address wether it's enabled or not */ > + /* Set the wb address whether it's enabled or not */ > rptr_addr = ring->rptr_gpu_addr; > WREG32_SOC15(GC, 0, mmCP_RB1_RPTR_ADDR, > lower_32_bits(rptr_addr)); > WREG32_SOC15(GC, 0, mmCP_RB1_RPTR_ADDR_HI, > upper_32_bits(rptr_addr) & > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c > b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c > index a0f80cc993cf..cf741fc61300 100644 > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c > @@ -3557,7 +3557,7 @@ static int gfx_v11_0_cp_gfx_resume(struct amdgpu_device > *adev) > WREG32_SOC15(GC, 0, regCP_RB0_WPTR, lower_32_bits(ring->wptr)); > WREG32_SOC15(GC, 0, regCP_RB0_WPTR_HI, upper_32_bits(ring->wptr)); > > - /* set the wb address wether it's enabled or not */ > + /* set the wb address whether it's enabled or not */ > rptr_addr = ring->rptr_gpu_addr; > WREG32_SOC15(GC, 0, regCP_RB0_RPTR_ADDR, lower_32_bits(rptr_addr)); > WREG32_SOC15(GC, 0, regCP_RB0_RPTR_ADDR_HI, upper_32_bits(rptr_addr) & > @@ -3595,7 +3595,7 @@ static int gfx_v11_0_cp_gfx_resume(struct amdgpu_device > *adev) > ring->wptr = 0; > WREG32_SOC15(GC, 0, regCP_RB1_WPTR, > lower_32_bits(ring->wptr)); > WREG32_SOC15(GC, 0, regCP_RB1_WPTR_HI, > upper_32_bits(ring->wptr)); > - /* Set the wb address wether it's enabled or not */ > + /* Set the wb address whether it's enabled or not */ > rptr_addr = ring->rptr_gpu_addr; > WREG32_SOC15(GC, 0, regCP_RB1_RPTR_ADDR, > lower_32_bits(rptr_addr)); > WREG32_SOC15(GC, 0, regCP_RB1_RPTR_ADDR_HI, > upper_32_bits(rptr_addr) & > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v12_0.c > b/drivers/gpu/drm/amd/amdgpu/gfx_v12_0.c > index 63e1a2803503..b5281f45e1ea 100644 > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v12_0.c > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v12_0.c > @@ -2601,7 +2601,7 @@ static int gfx_v12_0_cp_gfx_resume(struct amdgpu_device > *adev) > WREG32_SOC15(GC, 0, regCP_RB0_WPTR, lower_32_bits(ring->wptr)); > WREG32_SOC15(GC, 0, regCP_RB0_WPTR_HI, upper_32_bits(ring->wptr)); > > - /* set the wb address wether it's enabled or not */ > + /* set the wb address whether it's enabled or not */ > rptr_addr = ring->rptr_gpu_addr; > WREG32_SOC15(GC, 0, regCP_RB0_RPTR_ADDR, lower_32_bits(rptr_addr)); > WREG32_SOC15(GC, 0, regCP_RB0_RPTR_ADDR_HI, upper_32_bits(rptr_addr) & > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c > b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c > index 990e7de8da25..ee9ad38e12cd 100644 > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c > @@ -2559,7 +2559,7 @@ static int gfx_v7_0_cp_gfx_resume(struct amdgpu_device > *adev) > ring->wptr = 0; > WREG32(mmCP_RB0_WPTR, lower_32_bits(ring->wptr)); > > - /* set the wb address wether it's enabled or not */ > + /* set the wb address whether it's enabled or not */ > rptr_addr = ring->rptr_gpu_addr; > WREG32(mmCP_RB0_RPTR_ADDR, lower_32_bits(rptr_addr)); > WREG32(mmCP_RB0_RPTR_ADDR_HI, upper_32_bits(rptr_addr) & 0xFF); > @@ -2876,7 +2876,7 @@ stati
Re: linux-next: manual merge of the drm-xe tree with the drm-misc-fixes tree
Hi all,
On Fri, 4 Oct 2024 12:18:00 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm-xe tree got a conflict in:
>
> drivers/gpu/drm/xe/xe_guc_submit.c
>
> between commit:
>
> 9286a191abe2 ("drm/xe: Drop GuC submit_wq pool")
>
> from the drm-misc-fixes tree and commit:
>
> 861108666cc0 ("drm/xe: fix UAF around queue destruction")
This is now also commit
2d2be279f1ca ("drm/xe: fix UAF around queue destruction")
in Linus' tree.
> from the drm-xe tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc drivers/gpu/drm/xe/xe_guc_submit.c
> index 17c25f18e286,8a5c21a87977..
> --- a/drivers/gpu/drm/xe/xe_guc_submit.c
> +++ b/drivers/gpu/drm/xe/xe_guc_submit.c
> @@@ -224,11 -224,80 +224,27 @@@ static bool exec_queue_killed_or_banned
>EXEC_QUEUE_STATE_BANNED));
> }
>
> -#ifdef CONFIG_PROVE_LOCKING
> -static int alloc_submit_wq(struct xe_guc *guc)
> -{
> -int i;
> -
> -for (i = 0; i < NUM_SUBMIT_WQ; ++i) {
> -guc->submission_state.submit_wq_pool[i] =
> -alloc_ordered_workqueue("submit_wq", 0);
> -if (!guc->submission_state.submit_wq_pool[i])
> -goto err_free;
> -}
> -
> -return 0;
> -
> -err_free:
> -while (i)
> -destroy_workqueue(guc->submission_state.submit_wq_pool[--i]);
> -
> -return -ENOMEM;
> -}
> -
> -static void free_submit_wq(struct xe_guc *guc)
> -{
> -int i;
> -
> -for (i = 0; i < NUM_SUBMIT_WQ; ++i)
> -destroy_workqueue(guc->submission_state.submit_wq_pool[i]);
> -}
> -
> -static struct workqueue_struct *get_submit_wq(struct xe_guc *guc)
> -{
> -int idx = guc->submission_state.submit_wq_idx++ % NUM_SUBMIT_WQ;
> -
> -return guc->submission_state.submit_wq_pool[idx];
> -}
> -#else
> -static int alloc_submit_wq(struct xe_guc *guc)
> -{
> -return 0;
> -}
> -
> -static void free_submit_wq(struct xe_guc *guc)
> -{
> -
> -}
> -
> -static struct workqueue_struct *get_submit_wq(struct xe_guc *guc)
> -{
> -return NULL;
> -}
> -#endif
> -
> + static void xe_guc_submit_fini(struct xe_guc *guc)
> + {
> + struct xe_device *xe = guc_to_xe(guc);
> + struct xe_gt *gt = guc_to_gt(guc);
> + int ret;
> +
> + ret = wait_event_timeout(guc->submission_state.fini_wq,
> +
> xa_empty(&guc->submission_state.exec_queue_lookup),
> + HZ * 5);
> +
> + drain_workqueue(xe->destroy_wq);
> +
> + xe_gt_assert(gt, ret);
> + }
> +
> static void guc_submit_fini(struct drm_device *drm, void *arg)
> {
> struct xe_guc *guc = arg;
>
> + xe_guc_submit_fini(guc);
> xa_destroy(&guc->submission_state.exec_queue_lookup);
> -free_submit_wq(guc);
> }
>
> static void guc_submit_wedged_fini(void *arg)
This is now a conflict between the drm-misc-fixes tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpSmSK7_9pw4.pgp
Description: OpenPGP digital signature
Patch "drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS" has been added to the 5.4-stable tree
This is a note to let you know that I've just added the patch titled
drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS
to the 5.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-consistently-use-struct-drm_mode_rect-for-fb_damage_clips.patch
and it can be found in the queue-5.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 8b0d2f61545545ab5eef923ed6e59fc3be2385e0 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Mon, 23 Sep 2024 09:58:14 +0200
Subject: drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Thomas Zimmermann
commit 8b0d2f61545545ab5eef923ed6e59fc3be2385e0 upstream.
FB_DAMAGE_CLIPS is a plane property for damage handling. Its UAPI
should only use UAPI types. Hence replace struct drm_rect with
struct drm_mode_rect in drm_atomic_plane_set_property(). Both types
are identical in practice, so there's no change in behavior.
Reported-by: Ville Syrjälä
Closes: https://lore.kernel.org/dri-devel/zu1ke1tuthbtz...@intel.com/
Signed-off-by: Thomas Zimmermann
Fixes: d3b21767821e ("drm: Add a new plane property to send damage during plane
update")
Cc: Lukasz Spintzyk
Cc: Deepak Rawat
Cc: Daniel Vetter
Cc: Thomas Hellstrom
Cc: David Airlie
Cc: Simona Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.0+
Reviewed-by: Dmitry Baryshkov
Link:
https://patchwork.freedesktop.org/patch/msgid/20240923075841.16231-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_atomic_uapi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -582,7 +582,7 @@ static int drm_atomic_plane_set_property
&state->fb_damage_clips,
val,
-1,
- sizeof(struct drm_rect),
+ sizeof(struct drm_mode_rect),
&replaced);
return ret;
} else if (plane->funcs->atomic_set_property) {
Patches currently in stable-queue which might be from tzimmerm...@suse.de are
queue-5.4/drm-consistently-use-struct-drm_mode_rect-for-fb_damage_clips.patch
Patch "drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS" has been added to the 5.15-stable tree
This is a note to let you know that I've just added the patch titled
drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS
to the 5.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-consistently-use-struct-drm_mode_rect-for-fb_damage_clips.patch
and it can be found in the queue-5.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 8b0d2f61545545ab5eef923ed6e59fc3be2385e0 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Mon, 23 Sep 2024 09:58:14 +0200
Subject: drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Thomas Zimmermann
commit 8b0d2f61545545ab5eef923ed6e59fc3be2385e0 upstream.
FB_DAMAGE_CLIPS is a plane property for damage handling. Its UAPI
should only use UAPI types. Hence replace struct drm_rect with
struct drm_mode_rect in drm_atomic_plane_set_property(). Both types
are identical in practice, so there's no change in behavior.
Reported-by: Ville Syrjälä
Closes: https://lore.kernel.org/dri-devel/zu1ke1tuthbtz...@intel.com/
Signed-off-by: Thomas Zimmermann
Fixes: d3b21767821e ("drm: Add a new plane property to send damage during plane
update")
Cc: Lukasz Spintzyk
Cc: Deepak Rawat
Cc: Daniel Vetter
Cc: Thomas Hellstrom
Cc: David Airlie
Cc: Simona Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.0+
Reviewed-by: Dmitry Baryshkov
Link:
https://patchwork.freedesktop.org/patch/msgid/20240923075841.16231-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_atomic_uapi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -603,7 +603,7 @@ static int drm_atomic_plane_set_property
&state->fb_damage_clips,
val,
-1,
- sizeof(struct drm_rect),
+ sizeof(struct drm_mode_rect),
&replaced);
return ret;
} else if (property == plane->scaling_filter_property) {
Patches currently in stable-queue which might be from tzimmerm...@suse.de are
queue-5.15/drm-consistently-use-struct-drm_mode_rect-for-fb_damage_clips.patch
Patch "drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS" has been added to the 6.1-stable tree
This is a note to let you know that I've just added the patch titled
drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-consistently-use-struct-drm_mode_rect-for-fb_damage_clips.patch
and it can be found in the queue-6.1 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 8b0d2f61545545ab5eef923ed6e59fc3be2385e0 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Mon, 23 Sep 2024 09:58:14 +0200
Subject: drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Thomas Zimmermann
commit 8b0d2f61545545ab5eef923ed6e59fc3be2385e0 upstream.
FB_DAMAGE_CLIPS is a plane property for damage handling. Its UAPI
should only use UAPI types. Hence replace struct drm_rect with
struct drm_mode_rect in drm_atomic_plane_set_property(). Both types
are identical in practice, so there's no change in behavior.
Reported-by: Ville Syrjälä
Closes: https://lore.kernel.org/dri-devel/zu1ke1tuthbtz...@intel.com/
Signed-off-by: Thomas Zimmermann
Fixes: d3b21767821e ("drm: Add a new plane property to send damage during plane
update")
Cc: Lukasz Spintzyk
Cc: Deepak Rawat
Cc: Daniel Vetter
Cc: Thomas Hellstrom
Cc: David Airlie
Cc: Simona Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.0+
Reviewed-by: Dmitry Baryshkov
Link:
https://patchwork.freedesktop.org/patch/msgid/20240923075841.16231-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_atomic_uapi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -567,7 +567,7 @@ static int drm_atomic_plane_set_property
&state->fb_damage_clips,
val,
-1,
- sizeof(struct drm_rect),
+ sizeof(struct drm_mode_rect),
&replaced);
return ret;
} else if (property == plane->scaling_filter_property) {
Patches currently in stable-queue which might be from tzimmerm...@suse.de are
queue-6.1/drm-consistently-use-struct-drm_mode_rect-for-fb_damage_clips.patch
Patch "drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS" has been added to the 5.10-stable tree
This is a note to let you know that I've just added the patch titled
drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-consistently-use-struct-drm_mode_rect-for-fb_damage_clips.patch
and it can be found in the queue-5.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 8b0d2f61545545ab5eef923ed6e59fc3be2385e0 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Mon, 23 Sep 2024 09:58:14 +0200
Subject: drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Thomas Zimmermann
commit 8b0d2f61545545ab5eef923ed6e59fc3be2385e0 upstream.
FB_DAMAGE_CLIPS is a plane property for damage handling. Its UAPI
should only use UAPI types. Hence replace struct drm_rect with
struct drm_mode_rect in drm_atomic_plane_set_property(). Both types
are identical in practice, so there's no change in behavior.
Reported-by: Ville Syrjälä
Closes: https://lore.kernel.org/dri-devel/zu1ke1tuthbtz...@intel.com/
Signed-off-by: Thomas Zimmermann
Fixes: d3b21767821e ("drm: Add a new plane property to send damage during plane
update")
Cc: Lukasz Spintzyk
Cc: Deepak Rawat
Cc: Daniel Vetter
Cc: Thomas Hellstrom
Cc: David Airlie
Cc: Simona Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.0+
Reviewed-by: Dmitry Baryshkov
Link:
https://patchwork.freedesktop.org/patch/msgid/20240923075841.16231-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_atomic_uapi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -584,7 +584,7 @@ static int drm_atomic_plane_set_property
&state->fb_damage_clips,
val,
-1,
- sizeof(struct drm_rect),
+ sizeof(struct drm_mode_rect),
&replaced);
return ret;
} else if (plane->funcs->atomic_set_property) {
Patches currently in stable-queue which might be from tzimmerm...@suse.de are
queue-5.10/drm-consistently-use-struct-drm_mode_rect-for-fb_damage_clips.patch
Patch "drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS" has been added to the 6.6-stable tree
This is a note to let you know that I've just added the patch titled
drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS
to the 6.6-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-consistently-use-struct-drm_mode_rect-for-fb_damage_clips.patch
and it can be found in the queue-6.6 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 8b0d2f61545545ab5eef923ed6e59fc3be2385e0 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Mon, 23 Sep 2024 09:58:14 +0200
Subject: drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Thomas Zimmermann
commit 8b0d2f61545545ab5eef923ed6e59fc3be2385e0 upstream.
FB_DAMAGE_CLIPS is a plane property for damage handling. Its UAPI
should only use UAPI types. Hence replace struct drm_rect with
struct drm_mode_rect in drm_atomic_plane_set_property(). Both types
are identical in practice, so there's no change in behavior.
Reported-by: Ville Syrjälä
Closes: https://lore.kernel.org/dri-devel/zu1ke1tuthbtz...@intel.com/
Signed-off-by: Thomas Zimmermann
Fixes: d3b21767821e ("drm: Add a new plane property to send damage during plane
update")
Cc: Lukasz Spintzyk
Cc: Deepak Rawat
Cc: Daniel Vetter
Cc: Thomas Hellstrom
Cc: David Airlie
Cc: Simona Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.0+
Reviewed-by: Dmitry Baryshkov
Link:
https://patchwork.freedesktop.org/patch/msgid/20240923075841.16231-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_atomic_uapi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -585,7 +585,7 @@ static int drm_atomic_plane_set_property
&state->fb_damage_clips,
val,
-1,
- sizeof(struct drm_rect),
+ sizeof(struct drm_mode_rect),
&replaced);
return ret;
} else if (property == plane->scaling_filter_property) {
Patches currently in stable-queue which might be from tzimmerm...@suse.de are
queue-6.6/drm-consistently-use-struct-drm_mode_rect-for-fb_damage_clips.patch
Patch "drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS" has been added to the 6.10-stable tree
This is a note to let you know that I've just added the patch titled
drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS
to the 6.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-consistently-use-struct-drm_mode_rect-for-fb_damage_clips.patch
and it can be found in the queue-6.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 8b0d2f61545545ab5eef923ed6e59fc3be2385e0 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Mon, 23 Sep 2024 09:58:14 +0200
Subject: drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Thomas Zimmermann
commit 8b0d2f61545545ab5eef923ed6e59fc3be2385e0 upstream.
FB_DAMAGE_CLIPS is a plane property for damage handling. Its UAPI
should only use UAPI types. Hence replace struct drm_rect with
struct drm_mode_rect in drm_atomic_plane_set_property(). Both types
are identical in practice, so there's no change in behavior.
Reported-by: Ville Syrjälä
Closes: https://lore.kernel.org/dri-devel/zu1ke1tuthbtz...@intel.com/
Signed-off-by: Thomas Zimmermann
Fixes: d3b21767821e ("drm: Add a new plane property to send damage during plane
update")
Cc: Lukasz Spintzyk
Cc: Deepak Rawat
Cc: Daniel Vetter
Cc: Thomas Hellstrom
Cc: David Airlie
Cc: Simona Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.0+
Reviewed-by: Dmitry Baryshkov
Link:
https://patchwork.freedesktop.org/patch/msgid/20240923075841.16231-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_atomic_uapi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -543,7 +543,7 @@ static int drm_atomic_plane_set_property
&state->fb_damage_clips,
val,
-1,
- sizeof(struct drm_rect),
+ sizeof(struct drm_mode_rect),
&replaced);
return ret;
} else if (property == plane->scaling_filter_property) {
Patches currently in stable-queue which might be from tzimmerm...@suse.de are
queue-6.10/drm-consistently-use-struct-drm_mode_rect-for-fb_damage_clips.patch
Re: [PATCH 1/3] drm/etnaviv: Track GPU VA size separately
Am Samstag, dem 05.10.2024 um 03:42 +0800 schrieb Sui Jingfeng:
> Etnaviv assumes that GPU page size is 4KiB, yet on some systems, the CPU
> page size is 16KiB. The size of etnaviv buffer objects will be aligned
> to CPU page size on kernel side, however, userspace still assumes the
> page size is 4KiB and doing allocation with 4KiB page as unit. This
> results in userspace allocated GPU virtual address range collision and
> therefore unable to be inserted to the specified hole exactly.
>
> The root cause is that kernel side BO takes up bigger address space than
> userspace assumes when the size of it is not CPU page size aligned. To
> Preserve GPU VA continuous as much as possible, track the size that
> userspace/GPU think of it is.
>
> Yes, we still need to overallocate to suit the CPU, but there is no need
> to waste GPU VA space anymore.
>
> Signed-off-by: Sui Jingfeng
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 8 +---
> drivers/gpu/drm/etnaviv/etnaviv_gem.h | 1 +
> drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 8
> 3 files changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> index 5c0c9d4e3be1..943fc20093e6 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> @@ -543,7 +543,7 @@ static const struct drm_gem_object_funcs
> etnaviv_gem_object_funcs = {
> .vm_ops = &vm_ops,
> };
>
> -static int etnaviv_gem_new_impl(struct drm_device *dev, u32 flags,
> +static int etnaviv_gem_new_impl(struct drm_device *dev, u32 size, u32 flags,
> const struct etnaviv_gem_ops *ops, struct drm_gem_object **obj)
> {
> struct etnaviv_gem_object *etnaviv_obj;
> @@ -570,6 +570,7 @@ static int etnaviv_gem_new_impl(struct drm_device *dev,
> u32 flags,
> if (!etnaviv_obj)
> return -ENOMEM;
>
> + etnaviv_obj->user_size = size;
> etnaviv_obj->flags = flags;
> etnaviv_obj->ops = ops;
>
> @@ -588,11 +589,12 @@ int etnaviv_gem_new_handle(struct drm_device *dev,
> struct drm_file *file,
> {
> struct etnaviv_drm_private *priv = dev->dev_private;
> struct drm_gem_object *obj = NULL;
> + unsigned int user_size = size;
This still needs to be be aligned to 4K. Userspace may request
unaligned buffer sizes and we don't want to risk any confusion about
which part is visible to the GPU, so better make sure this size is
aligned to the GPU page size.
Also, that more personal preference, but I would call this gpu_size or
something like that, to avoid any confusion with the user_size in
etnaviv_cmdbuf, where user_size doesn't denote the GPU visible size.
Regards,
Lucas
> int ret;
>
> size = PAGE_ALIGN(size);
>
> - ret = etnaviv_gem_new_impl(dev, flags, &etnaviv_gem_shmem_ops, &obj);
> + ret = etnaviv_gem_new_impl(dev, user_size, flags,
> &etnaviv_gem_shmem_ops, &obj);
> if (ret)
> goto fail;
>
> @@ -627,7 +629,7 @@ int etnaviv_gem_new_private(struct drm_device *dev,
> size_t size, u32 flags,
> struct drm_gem_object *obj;
> int ret;
>
> - ret = etnaviv_gem_new_impl(dev, flags, ops, &obj);
> + ret = etnaviv_gem_new_impl(dev, size, flags, ops, &obj);
> if (ret)
> return ret;
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> index a42d260cac2c..c6e27b9abb0c 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.h
> @@ -36,6 +36,7 @@ struct etnaviv_gem_object {
> const struct etnaviv_gem_ops *ops;
> struct mutex lock;
>
> + u32 user_size;
> u32 flags;
>
> struct list_head gem_node;
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> index 1661d589bf3e..6fbc62772d85 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> @@ -281,6 +281,7 @@ int etnaviv_iommu_map_gem(struct etnaviv_iommu_context
> *context,
> {
> struct sg_table *sgt = etnaviv_obj->sgt;
> struct drm_mm_node *node;
> + unsigned int user_size;
> int ret;
>
> lockdep_assert_held(&etnaviv_obj->lock);
> @@ -303,13 +304,12 @@ int etnaviv_iommu_map_gem(struct etnaviv_iommu_context
> *context,
> }
>
> node = &mapping->vram_node;
> + user_size = etnaviv_obj->user_size;
>
> if (va)
> - ret = etnaviv_iommu_insert_exact(context, node,
> - etnaviv_obj->base.size, va);
> + ret = etnaviv_iommu_insert_exact(context, node, user_size, va);
> else
> - ret = etnaviv_iommu_find_iova(context, node,
> - etnaviv_obj->base.size);
> + ret = etnaviv_iommu_find_iova(context, node, user_size);
> if (ret < 0)
> goto unlock;
>
Patch "drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS" has been added to the 6.11-stable tree
This is a note to let you know that I've just added the patch titled
drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS
to the 6.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-consistently-use-struct-drm_mode_rect-for-fb_damage_clips.patch
and it can be found in the queue-6.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 8b0d2f61545545ab5eef923ed6e59fc3be2385e0 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Mon, 23 Sep 2024 09:58:14 +0200
Subject: drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Thomas Zimmermann
commit 8b0d2f61545545ab5eef923ed6e59fc3be2385e0 upstream.
FB_DAMAGE_CLIPS is a plane property for damage handling. Its UAPI
should only use UAPI types. Hence replace struct drm_rect with
struct drm_mode_rect in drm_atomic_plane_set_property(). Both types
are identical in practice, so there's no change in behavior.
Reported-by: Ville Syrjälä
Closes: https://lore.kernel.org/dri-devel/zu1ke1tuthbtz...@intel.com/
Signed-off-by: Thomas Zimmermann
Fixes: d3b21767821e ("drm: Add a new plane property to send damage during plane
update")
Cc: Lukasz Spintzyk
Cc: Deepak Rawat
Cc: Daniel Vetter
Cc: Thomas Hellstrom
Cc: David Airlie
Cc: Simona Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.0+
Reviewed-by: Dmitry Baryshkov
Link:
https://patchwork.freedesktop.org/patch/msgid/20240923075841.16231-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_atomic_uapi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -543,7 +543,7 @@ static int drm_atomic_plane_set_property
&state->fb_damage_clips,
val,
-1,
- sizeof(struct drm_rect),
+ sizeof(struct drm_mode_rect),
&replaced);
return ret;
} else if (property == plane->scaling_filter_property) {
Patches currently in stable-queue which might be from tzimmerm...@suse.de are
queue-6.11/drm-consistently-use-struct-drm_mode_rect-for-fb_damage_clips.patch
Re: [PATCH 2/3] drm/etnaviv: Map and unmap the GPU VA range with respect to its user size
Am Samstag, dem 05.10.2024 um 03:42 +0800 schrieb Sui Jingfeng:
> Since the GPU VA space is compact in terms of 4KiB unit, map and/or unmap
> the area that doesn't belong to a context breaks the philosophy of PPAS.
> That results in severe errors: GPU hang and MMU fault (page not present)
> and such.
>
> Shrink the usuable size of etnaviv GEM buffer object to its user size,
> instead of the original physical size of its backing memory.
>
> Signed-off-by: Sui Jingfeng
> ---
> drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 28 +--
> 1 file changed, 9 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> index 6fbc62772d85..a52ec5eb0e3d 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> @@ -70,8 +70,10 @@ static int etnaviv_context_map(struct
> etnaviv_iommu_context *context,
> }
>
> static int etnaviv_iommu_map(struct etnaviv_iommu_context *context, u32 iova,
> + unsigned int user_len,
>struct sg_table *sgt, int prot)
> -{struct scatterlist *sg;
> +{
> + struct scatterlist *sg;
> unsigned int da = iova;
> unsigned int i;
> int ret;
> @@ -81,7 +83,8 @@ static int etnaviv_iommu_map(struct etnaviv_iommu_context
> *context, u32 iova,
>
> for_each_sgtable_dma_sg(sgt, sg, i) {
> phys_addr_t pa = sg_dma_address(sg) - sg->offset;
> - size_t bytes = sg_dma_len(sg) + sg->offset;
> + unsigned int phys_len = sg_dma_len(sg) + sg->offset;
> + size_t bytes = MIN(phys_len, user_len);
>
> VERB("map[%d]: %08x %pap(%zx)", i, iova, &pa, bytes);
>
> @@ -89,6 +92,7 @@ static int etnaviv_iommu_map(struct etnaviv_iommu_context
> *context, u32 iova,
> if (ret)
> goto fail;
>
> + user_len -= bytes;
> da += bytes;
> }
Since the MIN(phys_len, user_len) may limit the mapped amount in the
wrong direction, I would think it would be good to add a
WARN_ON(user_len != 0) after the dma SG iteration.
>
> @@ -104,21 +108,7 @@ static int etnaviv_iommu_map(struct
> etnaviv_iommu_context *context, u32 iova,
> static void etnaviv_iommu_unmap(struct etnaviv_iommu_context *context, u32
> iova,
> struct sg_table *sgt, unsigned len)
> {
> - struct scatterlist *sg;
> - unsigned int da = iova;
> - int i;
> -
> - for_each_sgtable_dma_sg(sgt, sg, i) {
> - size_t bytes = sg_dma_len(sg) + sg->offset;
> -
> - etnaviv_context_unmap(context, da, bytes);
> -
> - VERB("unmap[%d]: %08x(%zx)", i, iova, bytes);
> -
> - BUG_ON(!PAGE_ALIGNED(bytes));
> -
> - da += bytes;
> - }
> + etnaviv_context_unmap(context, iova, len);
This drops some sanity checks, but I have only ever seen them fire when
we had other kernel memory corruption issues, so I'm fine with the
simplification you did here.
Regards,
Lucas
>
> context->flush_seq++;
> }
> @@ -131,7 +121,7 @@ static void etnaviv_iommu_remove_mapping(struct
> etnaviv_iommu_context *context,
> lockdep_assert_held(&context->lock);
>
> etnaviv_iommu_unmap(context, mapping->vram_node.start,
> - etnaviv_obj->sgt, etnaviv_obj->base.size);
> + etnaviv_obj->sgt, etnaviv_obj->user_size);
> drm_mm_remove_node(&mapping->vram_node);
> }
>
> @@ -314,7 +304,7 @@ int etnaviv_iommu_map_gem(struct etnaviv_iommu_context
> *context,
> goto unlock;
>
> mapping->iova = node->start;
> - ret = etnaviv_iommu_map(context, node->start, sgt,
> + ret = etnaviv_iommu_map(context, node->start, user_size, sgt,
> ETNAVIV_PROT_READ | ETNAVIV_PROT_WRITE);
>
> if (ret < 0) {
Re: [PATCH 3/3] drm/etnaviv: Print an error message if inserting IOVA range fails
Am Samstag, dem 05.10.2024 um 03:42 +0800 schrieb Sui Jingfeng:
> Print an error message to help debug when such an issue happen, since it's
> not so obvious.
>
> Signed-off-by: Sui Jingfeng
Reviewed-by: Lucas Stach
> ---
> v0 -> v1: Use dev_err_ratelimited() to prevent spamming the logs
>
> v0 is at
> https://lore.kernel.org/dri-devel/20240930221706.399139-1-sui.jingf...@linux.dev/
> ---
> drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> index a52ec5eb0e3d..37866ed05c13 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> @@ -300,8 +300,12 @@ int etnaviv_iommu_map_gem(struct etnaviv_iommu_context
> *context,
> ret = etnaviv_iommu_insert_exact(context, node, user_size, va);
> else
> ret = etnaviv_iommu_find_iova(context, node, user_size);
> - if (ret < 0)
> + if (ret < 0) {
> + dev_err_ratelimited(context->global->dev,
> + "Insert iova failed: 0x%llx(0x%x)\n",
> + va, user_size);
> goto unlock;
> + }
>
> mapping->iova = node->start;
> ret = etnaviv_iommu_map(context, node->start, user_size, sgt,
Re: [PATCH] drm/fbdev-dma: Only cleanup deferred I/O if necessary
On Sun, Oct 6, 2024 at 7:49 PM Janne Grunau wrote:
> Commit 5a498d4d06d6 ("drm/fbdev-dma: Only install deferred I/O if
> necessary") initializes deferred I/O only if it is used.
> drm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup()
> unconditionally with struct fb_info.fbdefio == NULL. KASAN with the
> out-of-tree Apple silicon display driver posts following warning from
> __flush_work() of a random struct work_struct instead of the expected
> NULL pointer derefs.
>
> [ 22.053799] [ cut here ]
> [ 22.054832] WARNING: CPU: 2 PID: 1 at kernel/workqueue.c:4177
> __flush_work+0x4d8/0x580
> [ 22.056597] Modules linked in: uhid bnep uinput nls_ascii ip6_tables
> ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs
> xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple
> brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev
> regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm
> snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart
> apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84
> videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg
> apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi
> videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple
> clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core
> mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm
> phram
> [ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted
> 6.11.2-asahi+ #asahi-dev
> [ 22.075612] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT)
> [ 22.077032] pstate: 0145 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
> [ 22.078567] pc : __flush_work+0x4d8/0x580
> [ 22.079471] lr : __flush_work+0x54/0x580
> [ 22.080345] sp : c000836ef820
> [ 22.081089] x29: c000836ef880 x28: x27:
> 80002ddb7128
> [ 22.082678] x26: dfffc000 x25: 196f0c57 x24:
> c00082d3e358
> [ 22.084263] x23: 80004b7862b8 x22: dfffc000 x21:
> 80005aa1d470
> [ 22.085855] x20: 80004b786000 x19: 80004b7862a0 x18:
>
> [ 22.087439] x17: x16: x15:
> 0005
> [ 22.089030] x14: 1800106ddf0a x13: x12:
>
> [ 22.090618] x11: b800106ddf0f x10: dfffc000 x9 :
> 1800106ddf0e
> [ 22.092206] x8 : x7 : x6 :
> 0001
> [ 22.093790] x5 : c000836ef728 x4 : x3 :
> 0020
> [ 22.095368] x2 : 0008 x1 : 00aa x0 :
>
> [ 22.096955] Call trace:
> [ 22.097505] __flush_work+0x4d8/0x580
> [ 22.098330] flush_delayed_work+0x80/0xb8
> [ 22.099231] fb_deferred_io_cleanup+0x3c/0x130
> [ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper]
> [ 22.101559] unregister_framebuffer+0x210/0x2f0
> [ 22.102575] drm_fb_helper_unregister_info+0x48/0x60
> [ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper]
> [ 22.105147] drm_client_dev_unregister+0x1cc/0x230
> [ 22.106217] drm_dev_unregister+0x58/0x570
> [ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm]
> [ 22.108199] component_del+0x1f8/0x3a8
> [ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp]
> [ 22.110357] platform_shutdown+0x70/0x90
> [ 22.111219] device_shutdown+0x368/0x4d8
> [ 22.112095] kernel_restart+0x6c/0x1d0
> [ 22.112946] __arm64_sys_reboot+0x1c8/0x328
> [ 22.113868] invoke_syscall+0x78/0x1a8
> [ 22.114703] do_el0_svc+0x124/0x1a0
> [ 22.115498] el0_svc+0x3c/0xe0
> [ 22.116181] el0t_64_sync_handler+0x70/0xc0
> [ 22.117110] el0t_64_sync+0x190/0x198
> [ 22.117931] ---[ end trace ]---
>
> Signed-off-by: Janne Grunau
> Fixes: 5a498d4d06d6 ("drm/fbdev-dma: Only install deferred I/O if necessary")
Good catch!
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
Re: [PATCH 4/8] drm/client: Make copies of modes
Hi
Am 03.10.24 um 13:33 schrieb Ville Syrjala:
From: Ville Syrjälä
drm_client_firmware_config() is currently picking up the current
mode of the crtc via the legacy crtc->mode, which is not supposed
to be used by atomic drivers at all. We can't simply switch over
to the proper crtc->state->mode because we drop the crtc->mutex
(which protects crtc->state) before the mode gets used.
The most straightforward solution to extend the lifetime of
modes[] seem to be to make full copies of the modes instead
of just storing pointers. We do have to replace the NULL checks
with something else though. Checking that mode->clock!=0
should be sufficient.
And with this we can undo also commit 3eadd887dbac
("drm/client:Fully protect modes[] with dev->mode_config.mutex")
as the lifetime of modes[] no longer has anything to do with
that lock.
I think it would be a lot better to first build that mode list while
holding the mutex, and afterwards copy the resulting modes before
releasing the lock. The code below is convoluted with drm_mode_copy().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_client_modeset.c | 80 +++-
1 file changed, 43 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index 888323137a6a..d413e119db3f 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -265,10 +265,15 @@ static void drm_client_connectors_enabled(struct
drm_connector *connectors[],
enabled[i] = drm_connector_enabled(connectors[i], false);
}
+static bool mode_valid(const struct drm_display_mode *mode)
+{
+ return mode->clock != 0;
A mode's clock isn't always known and not all drivers might set it
correctly. At least in simpledrm/ofdrm, we have to make up a clock value
for the firmware framebuffer. Otherwise some of our userspace would oops.
The test for clock != 0 makes sense, but it's maybe the wrong place to
do this. Would a test for hdisplay/vdisplay != 0 work instead?
+}
+
static bool drm_client_target_cloned(struct drm_device *dev,
struct drm_connector *connectors[],
unsigned int connector_count,
-const struct drm_display_mode *modes[],
+struct drm_display_mode modes[],
struct drm_client_offset offsets[],
bool enabled[], int width, int height)
{
@@ -296,15 +301,16 @@ static bool drm_client_target_cloned(struct drm_device
*dev,
for (i = 0; i < connector_count; i++) {
if (!enabled[i])
continue;
- modes[i] = drm_connector_pick_cmdline_mode(connectors[i]);
- if (!modes[i]) {
+
+ drm_mode_copy(&modes[i],
drm_connector_pick_cmdline_mode(connectors[i]));
+ if (!mode_valid(&modes[i])) {
You're copying and only then test for validity?
can_clone = false;
break;
}
for (j = 0; j < i; j++) {
if (!enabled[j])
continue;
- if (!drm_mode_match(modes[j], modes[i],
+ if (!drm_mode_match(&modes[j], &modes[i],
DRM_MODE_MATCH_TIMINGS |
DRM_MODE_MATCH_CLOCK |
DRM_MODE_MATCH_FLAGS |
@@ -335,9 +341,9 @@ static bool drm_client_target_cloned(struct drm_device *dev,
DRM_MODE_MATCH_CLOCK |
DRM_MODE_MATCH_FLAGS |
DRM_MODE_MATCH_3D_FLAGS))
- modes[i] = mode;
+ drm_mode_copy(&modes[i], mode);
}
- if (!modes[i])
+ if (!mode_valid(&modes[i]))
can_clone = false;
}
drm_mode_destroy(dev, dmt_mode);
@@ -354,7 +360,7 @@ static bool drm_client_target_cloned(struct drm_device *dev,
static int drm_client_get_tile_offsets(struct drm_device *dev,
struct drm_connector *connectors[],
unsigned int connector_count,
- const struct drm_display_mode *modes[],
+ const struct drm_display_mode modes[],
struct drm_client_offset offsets[],
int idx,
int h_idx, int v_idx)
@@ -368,17 +374,17 @@ static int drm_client_get_tile_offsets(struct drm_device
*dev,
if (!connector->has_tile)
continue;
Re: [PATCH v9 2/2] drm/tiny: Add driver for Sharp Memory LCD
Helo Alex,
On Sun, Oct 06, 2024 at 09:30:06PM -0400, Alex Lanzano wrote:
> +static int sharp_memory_init_pwm_vcom_signal(struct sharp_memory_device *smd)
> +{
> + struct pwm_state pwm_state;
> + struct device *dev = &smd->spi->dev;
> +
> + smd->pwm_vcom_signal = devm_pwm_get(dev, NULL);
> + if (IS_ERR(smd->pwm_vcom_signal))
> + return dev_err_probe(dev, -EINVAL, "Could not get pwm
> device\n");
s/-EINVAL/PTR_ERR(smd->pwm_vcom_signal)/
> + pwm_init_state(smd->pwm_vcom_signal, &pwm_state);
> + pwm_set_relative_duty_cycle(&pwm_state, 1, 10);
> + pwm_state.enabled = true;
> + pwm_apply_might_sleep(smd->pwm_vcom_signal, &pwm_state);
Error checking for pwm_apply_might_sleep() please.
> + return 0;
> +}
> [...]
> + } else if (!strcmp("pwm", vcom_mode_str)) {
> + smd->vcom_mode = SHARP_MEMORY_PWM_VCOM;
> + ret = sharp_memory_init_pwm_vcom_signal(smd);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "Failed to initialize external COM
> signal\n");
sharp_memory_init_pwm_vcom_signal() already emits an error message, so you
have two here. One should be enough.
> + } else {
> + return dev_err_probe(dev, -EINVAL, "Invalid value set for
> vcom-mode\n");
> + }
> [...]
Best regards
Uwe
signature.asc
Description: PGP signature
Re: [PATCH 8/8] drm/client: s/unsigned int i/int i/
Hi
Am 03.10.24 um 13:33 schrieb Ville Syrjala:
From: Ville Syrjälä
Replace the 'unsigned int i' footguns with plain old signed
int. Avoids accidents if/when someone decides they need
to iterate backwards.
Why are signed types preferable here?
Best regards
Thomas
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_client_modeset.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index ccf5c9b5537b..875d517fa8f2 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -39,7 +39,7 @@ int drm_client_modeset_create(struct drm_client_dev *client)
unsigned int max_connector_count = 1;
struct drm_mode_set *modeset;
struct drm_crtc *crtc;
- unsigned int i = 0;
+ int i = 0;
/* Add terminating zero entry to enable index less iteration */
client->modesets = kcalloc(num_crtc + 1, sizeof(*client->modesets),
GFP_KERNEL);
@@ -75,7 +75,7 @@ static void drm_client_modeset_release(struct drm_client_dev
*client)
struct drm_mode_set *modeset;
drm_client_for_each_modeset(modeset, client) {
- unsigned int i;
+ int i;
drm_mode_destroy(client->dev, modeset->mode);
modeset->mode = NULL;
@@ -925,7 +925,7 @@ bool drm_client_rotation(struct drm_mode_set *modeset,
unsigned int *rotation)
struct drm_plane *plane = modeset->crtc->primary;
struct drm_cmdline_mode *cmdline;
u64 valid_mask = 0;
- unsigned int i;
+ int i;
if (!modeset->num_connectors)
return false;
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
[PATCH v1 1/4] misc: fastrpc: Add CRC support using invokeV2 request
InvokeV2 request is intended to support multiple enhanced invoke
requests like CRC check, performance counter enablement and polling
mode for RPC invocations. CRC check is getting enabled as part of
this patch. CRC check for input and output argument helps in ensuring
data consistency over a remote call. If user intends to enable CRC
check, first local user CRC is calculated at user end and a CRC buffer
is passed to DSP to capture remote CRC values. DSP is expected to
write to the remote CRC buffer which is then compared at user level
with the local CRC values.
Signed-off-by: Ekansh Gupta
---
drivers/misc/fastrpc.c | 161
include/uapi/misc/fastrpc.h | 7 ++
2 files changed, 116 insertions(+), 52 deletions(-)
diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 74181b8c386b..8e817a763d1d 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -573,13 +573,15 @@ static void fastrpc_get_buff_overlaps(struct
fastrpc_invoke_ctx *ctx)
static struct fastrpc_invoke_ctx *fastrpc_context_alloc(
struct fastrpc_user *user, u32 kernel, u32 sc,
- struct fastrpc_invoke_args *args)
+ struct fastrpc_invoke_v2 *inv2)
{
struct fastrpc_channel_ctx *cctx = user->cctx;
struct fastrpc_invoke_ctx *ctx = NULL;
+ struct fastrpc_invoke_args *args = NULL;
unsigned long flags;
int ret;
+ args = (struct fastrpc_invoke_args *)inv2->inv.args;
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return ERR_PTR(-ENOMEM);
@@ -611,6 +613,7 @@ static struct fastrpc_invoke_ctx *fastrpc_context_alloc(
/* Released in fastrpc_context_put() */
fastrpc_channel_ctx_get(cctx);
+ ctx->crc = (u32 *)(uintptr_t)inv2->crc;
ctx->sc = sc;
ctx->retval = -1;
ctx->pid = current->pid;
@@ -1070,6 +1073,7 @@ static int fastrpc_put_args(struct fastrpc_invoke_ctx
*ctx,
struct fastrpc_invoke_buf *list;
struct fastrpc_phy_page *pages;
u64 *fdlist;
+ u32 *crclist;
int i, inbufs, outbufs, handles;
inbufs = REMOTE_SCALARS_INBUFS(ctx->sc);
@@ -1078,6 +1082,7 @@ static int fastrpc_put_args(struct fastrpc_invoke_ctx
*ctx,
list = fastrpc_invoke_buf_start(rpra, ctx->nscalars);
pages = fastrpc_phy_page_start(list, ctx->nscalars);
fdlist = (uint64_t *)(pages + inbufs + outbufs + handles);
+ crclist = (u32 *)(fdlist + FASTRPC_MAX_FDLIST);
for (i = inbufs; i < ctx->nbufs; ++i) {
if (!ctx->maps[i]) {
@@ -1102,6 +1107,12 @@ static int fastrpc_put_args(struct fastrpc_invoke_ctx
*ctx,
fastrpc_map_put(mmap);
}
+ if (ctx->crc && crclist && rpra) {
+ if (copy_to_user((void __user *)ctx->crc, crclist,
+ FASTRPC_MAX_CRCLIST * sizeof(u32)))
+ return -EFAULT;
+ }
+
return 0;
}
@@ -1137,13 +1148,12 @@ static int fastrpc_invoke_send(struct
fastrpc_session_ctx *sctx,
}
-static int fastrpc_internal_invoke(struct fastrpc_user *fl, u32 kernel,
- u32 handle, u32 sc,
- struct fastrpc_invoke_args *args)
+static int fastrpc_internal_invoke(struct fastrpc_user *fl, u32 kernel,
struct fastrpc_invoke_v2 *inv2)
{
struct fastrpc_invoke_ctx *ctx = NULL;
struct fastrpc_buf *buf, *b;
-
+ struct fastrpc_invoke inv;
+ u32 handle, sc;
int err = 0;
if (!fl->sctx)
@@ -1152,12 +1162,15 @@ static int fastrpc_internal_invoke(struct fastrpc_user
*fl, u32 kernel,
if (!fl->cctx->rpdev)
return -EPIPE;
+ inv = inv2->inv;
+ handle = inv.handle;
+ sc = inv.sc;
if (handle == FASTRPC_INIT_HANDLE && !kernel) {
dev_warn_ratelimited(fl->sctx->dev, "user app trying to send a
kernel RPC message (%d)\n", handle);
return -EPERM;
}
- ctx = fastrpc_context_alloc(fl, kernel, sc, args);
+ ctx = fastrpc_context_alloc(fl, kernel, sc, inv2);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
@@ -1239,6 +1252,7 @@ static int fastrpc_init_create_static_process(struct
fastrpc_user *fl,
{
struct fastrpc_init_create_static init;
struct fastrpc_invoke_args *args;
+ struct fastrpc_invoke_v2 ioctl = {0};
struct fastrpc_phy_page pages[1];
char *name;
int err;
@@ -1248,7 +1262,6 @@ static int fastrpc_init_create_static_process(struct
fastrpc_user *fl,
u32 namelen;
u32 pageslen;
} inbuf;
- u32 sc;
args = kcalloc(FASTRPC_CREATE_STATIC_PROCESS_NARGS, sizeof(*args),
GFP_KERNEL);
if (!args)
@@ -1313,10 +1326,10 @@ static int fastrpc_init_create_static_process(struct
fastrpc_user *fl,
args[2].length =
[PATCH v1 2/4] misc: fastrpc: Capture kernel and DSP performance counters
Add support to capture kernel performance counters for different
kernel level operations. These counters collects the information
for remote call and copies the information to a buffer shared
by user.
Collection of DSP performance counters is also added as part of
this change. DSP updates the performance information in the
metadata which is then copied to a buffer passed by the users.
Signed-off-by: Ekansh Gupta
---
drivers/misc/fastrpc.c | 143 ++--
include/uapi/misc/fastrpc.h | 4 +-
2 files changed, 139 insertions(+), 8 deletions(-)
diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 8e817a763d1d..54a562fc94fb 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -38,6 +39,7 @@
#define FASTRPC_CTX_MAX (256)
#define FASTRPC_INIT_HANDLE1
#define FASTRPC_DSP_UTILITIES_HANDLE 2
+#define FASTRPC_MAX_STATIC_HANDLE (20)
#define FASTRPC_CTXID_MASK (0xFF0)
#define INIT_FILELEN_MAX (2 * 1024 * 1024)
#define INIT_FILE_NAMELEN_MAX (128)
@@ -106,6 +108,9 @@
#define miscdev_to_fdevice(d) container_of(d, struct fastrpc_device, miscdev)
+#define FASTRPC_KERNEL_PERF_LIST (PERF_KEY_MAX)
+#define FASTRPC_DSP_PERF_LIST 12
+
static const char *domains[FASTRPC_DEV_MAX] = { "adsp", "mdsp",
"sdsp", "cdsp", "cdsp1" };
struct fastrpc_phy_page {
@@ -229,6 +234,18 @@ struct fastrpc_map {
struct kref refcount;
};
+struct fastrpc_perf {
+ u64 count;
+ u64 flush;
+ u64 map;
+ u64 copy;
+ u64 link;
+ u64 getargs;
+ u64 putargs;
+ u64 invargs;
+ u64 invoke;
+};
+
struct fastrpc_invoke_ctx {
int nscalars;
int nbufs;
@@ -237,6 +254,8 @@ struct fastrpc_invoke_ctx {
int tgid;
u32 sc;
u32 *crc;
+ u64 *perf_kernel;
+ u64 *perf_dsp;
u64 ctxid;
u64 msg_sz;
struct kref refcount;
@@ -251,6 +270,7 @@ struct fastrpc_invoke_ctx {
struct fastrpc_invoke_args *args;
struct fastrpc_buf_overlap *olaps;
struct fastrpc_channel_ctx *cctx;
+ struct fastrpc_perf *perf;
};
struct fastrpc_session_ctx {
@@ -308,6 +328,51 @@ struct fastrpc_user {
struct mutex mutex;
};
+enum fastrpc_perfkeys {
+ PERF_COUNT = 0,
+ PERF_FLUSH = 1,
+ PERF_MAP = 2,
+ PERF_COPY = 3,
+ PERF_LINK = 4,
+ PERF_GETARGS = 5,
+ PERF_PUTARGS = 6,
+ PERF_INVARGS = 7,
+ PERF_INVOKE = 8,
+ PERF_KEY_MAX = 9,
+};
+
+#define PERF_END ((void)0)
+
+#define PERF(enb, cnt, ff) \
+ {\
+ struct timespec64 startT = {0};\
+ u64 *counter = cnt;\
+ if (enb && counter) {\
+ ktime_get_boottime_ts64(&startT);\
+ } \
+ ff ;\
+ if (enb && counter) {\
+ *counter += getnstimediff(&startT);\
+ } \
+ }
+
+#define GET_COUNTER(perf_ptr, offset) \
+ (perf_ptr != NULL ?\
+ (((offset >= 0) && (offset < PERF_KEY_MAX)) ?\
+ (u64 *)(perf_ptr + offset)\
+ : (u64 *)NULL) : (u64 *)NULL)
+
+static inline s64 getnstimediff(struct timespec64 *start)
+{
+ s64 ns;
+ struct timespec64 ts, b;
+
+ ktime_get_boottime_ts64(&ts);
+ b = timespec64_sub(ts, *start);
+ ns = timespec64_to_ns(&b);
+ return ns;
+}
+
static void fastrpc_free_map(struct kref *ref)
{
struct fastrpc_map *map;
@@ -497,6 +562,7 @@ static void fastrpc_context_free(struct kref *ref)
idr_remove(&cctx->ctx_idr, ctx->ctxid >> 4);
spin_unlock_irqrestore(&cctx->lock, flags);
+ kfree(ctx->perf);
kfree(ctx->maps);
kfree(ctx->olaps);
kfree(ctx);
@@ -614,6 +680,13 @@ static struct fastrpc_invoke_ctx *fastrpc_context_alloc(
fastrpc_channel_ctx_get(cctx);
ctx->crc = (u32 *)(uintptr_t)inv2->crc;
+ ctx->perf_dsp = (u64 *)(uintptr_t)inv2->perf_dsp;
+ ctx->perf_kernel = (u64 *)(uintptr_t)inv2->perf_kernel;
+ if (ctx->perf_kernel) {
+ ctx->perf = kzalloc(sizeof(*(ctx->perf)), GFP_KERNEL);
+ if (!ctx->perf)
+ return ERR_PTR(-ENOMEM);
+ }
ctx->sc = sc;
ctx->retval = -1;
ctx->pid = current->pid;
@@ -877,7 +950,8 @@ static int fastrpc_get_meta_size(struct fastrpc_invoke_ctx
*ctx)
sizeof(struct fastrpc_invoke_buf) +
sizeof(struct fastrpc_phy_page)) * ctx->nscalars +
sizeof(u64) * FASTRPC_MAX_FDLIST +
- sizeof(u32) * FASTRPC_MAX_CRCLIST;
+ sizeof(u32) * FASTRPC_MAX_CRCLIST +
+ sizeof(u32) + sizeof(u64) * FASTRPC_DSP_PERF_LIST;
return size;
}
@@ -951,7 +1025,9 @@ static int fastrpc_get_args
[PATCH v1 3/4] misc: fastrpc: Modify context id calculation for poll mode
Poll mode is a feature to be introduced which improves the fastrpc remote calls latency. For this feature, DSP expects the 4th to 7th bit of context id to be zero. Prepare context id in such a way that polling mode can be supported. Signed-off-by: Ekansh Gupta --- drivers/misc/fastrpc.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c index 54a562fc94fb..c008fcd95e15 100644 --- a/drivers/misc/fastrpc.c +++ b/drivers/misc/fastrpc.c @@ -40,7 +40,7 @@ #define FASTRPC_INIT_HANDLE1 #define FASTRPC_DSP_UTILITIES_HANDLE 2 #define FASTRPC_MAX_STATIC_HANDLE (20) -#define FASTRPC_CTXID_MASK (0xFF0) +#define FASTRPC_CTXID_MASK (0xFF) #define INIT_FILELEN_MAX (2 * 1024 * 1024) #define INIT_FILE_NAMELEN_MAX (128) #define FASTRPC_DEVICE_NAME"fastrpc" @@ -559,7 +559,7 @@ static void fastrpc_context_free(struct kref *ref) fastrpc_buf_free(ctx->buf); spin_lock_irqsave(&cctx->lock, flags); - idr_remove(&cctx->ctx_idr, ctx->ctxid >> 4); + idr_remove(&cctx->ctx_idr, ctx->ctxid >> 16); spin_unlock_irqrestore(&cctx->lock, flags); kfree(ctx->perf); @@ -706,7 +706,7 @@ static struct fastrpc_invoke_ctx *fastrpc_context_alloc( spin_unlock_irqrestore(&cctx->lock, flags); goto err_idr; } - ctx->ctxid = ret << 4; + ctx->ctxid = ret << 16; spin_unlock_irqrestore(&cctx->lock, flags); kref_init(&ctx->refcount); @@ -2621,7 +2621,7 @@ static int fastrpc_rpmsg_callback(struct rpmsg_device *rpdev, void *data, if (len < sizeof(*rsp)) return -EINVAL; - ctxid = ((rsp->ctx & FASTRPC_CTXID_MASK) >> 4); + ctxid = ((rsp->ctx & FASTRPC_CTXID_MASK) >> 16); spin_lock_irqsave(&cctx->lock, flags); ctx = idr_find(&cctx->ctx_idr, ctxid); -- 2.34.1
Re: [PATCH 1/2] drm/vc4: Use `vc4_perfmon_find()`
Similar to commit f2a4bcb25328 ("drm/v3d: Use v3d_perfmon_find()"),
replace the open-coded `vc4_perfmon_find()` with the real thing.
Cc: Christian Gmeiner
Signed-off-by: Maíra Canal
Reviewed-by: Christian Gmeiner
---
drivers/gpu/drm/vc4/vc4_perfmon.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_perfmon.c
b/drivers/gpu/drm/vc4/vc4_perfmon.c
index 4cd3643c3ba7..f2e56d0f6298 100644
--- a/drivers/gpu/drm/vc4/vc4_perfmon.c
+++ b/drivers/gpu/drm/vc4/vc4_perfmon.c
@@ -236,11 +236,7 @@ int vc4_perfmon_get_values_ioctl(struct drm_device *dev,
void *data,
return -ENODEV;
}
- mutex_lock(&vc4file->perfmon.lock);
- perfmon = idr_find(&vc4file->perfmon.idr, req->id);
- vc4_perfmon_get(perfmon);
- mutex_unlock(&vc4file->perfmon.lock);
-
+ perfmon = vc4_perfmon_find(vc4file, req->id);
if (!perfmon)
return -EINVAL;
--
Thanks & Regards,
Christian
[PATCH v1 0/4] Add invokeV2 to support new features
This patch series adds the listed features that have been missing in upstream fastRPC driver. - Add changes to support new enhanced invocation ioctl request. - Add support for CRC check. - Add support for DSP and kernel performance counters. - Add polling mode support. Userspace change: https://github.com/quic/fastrpc/pull/73 Ekansh Gupta (4): misc: fastrpc: Add CRC support using invokeV2 request misc: fastrpc: Capture kernel and DSP performance counters misc: fastrpc: Modify context id calculation for poll mode misc: fastrpc: Add polling mode support for fastRPC driver drivers/misc/fastrpc.c | 435 ++-- include/uapi/misc/fastrpc.h | 10 + 2 files changed, 376 insertions(+), 69 deletions(-) -- 2.34.1
[PATCH v1 4/4] misc: fastrpc: Add polling mode support for fastRPC driver
For any remote call to DSP, after sending an invocation message,
fastRPC driver waits for glink response and during this time the
CPU can go into low power modes. Adding a polling mode support
with which fastRPC driver will poll continuously on a memory
after sending a message to remote subsystem which will eliminate
CPU wakeup and scheduling latencies and reduce fastRPC overhead.
With this change, DSP always sends a glink response which will
get ignored if polling mode didn't time out.
Signed-off-by: Ekansh Gupta
---
drivers/misc/fastrpc.c | 127 +---
include/uapi/misc/fastrpc.h | 3 +-
2 files changed, 121 insertions(+), 9 deletions(-)
diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index c008fcd95e15..a25673c22db8 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -111,6 +111,19 @@
#define FASTRPC_KERNEL_PERF_LIST (PERF_KEY_MAX)
#define FASTRPC_DSP_PERF_LIST 12
+/* Poll response number from remote processor for call completion */
+#define FASTRPC_POLL_RESPONSE (0xdecaf)
+/* timeout in us for polling until memory barrier */
+#define FASTRPC_POLL_TIME_MEM_UPDATE (500)
+
+/* Response types supported for RPC calls */
+enum fastrpc_response_flags {
+ /* normal job completion glink response */
+ NORMAL_RESPONSE = 0,
+ /* process updates poll memory instead of glink response */
+ POLL_MODE = 1,
+};
+
static const char *domains[FASTRPC_DEV_MAX] = { "adsp", "mdsp",
"sdsp", "cdsp", "cdsp1" };
struct fastrpc_phy_page {
@@ -258,6 +271,12 @@ struct fastrpc_invoke_ctx {
u64 *perf_dsp;
u64 ctxid;
u64 msg_sz;
+ /* Threads poll for specified timeout and fall back to glink wait */
+ u64 poll_timeout;
+ /* work done status flag */
+ bool is_work_done;
+ /* response flags from remote processor */
+ enum fastrpc_response_flags rsp_flags;
struct kref refcount;
struct list_head node; /* list of ctxs */
struct completion work;
@@ -682,6 +701,7 @@ static struct fastrpc_invoke_ctx *fastrpc_context_alloc(
ctx->crc = (u32 *)(uintptr_t)inv2->crc;
ctx->perf_dsp = (u64 *)(uintptr_t)inv2->perf_dsp;
ctx->perf_kernel = (u64 *)(uintptr_t)inv2->perf_kernel;
+ ctx->poll_timeout = (u64)inv2->poll_timeout;
if (ctx->perf_kernel) {
ctx->perf = kzalloc(sizeof(*(ctx->perf)), GFP_KERNEL);
if (!ctx->perf)
@@ -692,6 +712,8 @@ static struct fastrpc_invoke_ctx *fastrpc_context_alloc(
ctx->pid = current->pid;
ctx->tgid = user->tgid;
ctx->cctx = cctx;
+ ctx->rsp_flags = NORMAL_RESPONSE;
+ ctx->is_work_done = false;
init_completion(&ctx->work);
INIT_WORK(&ctx->put_work, fastrpc_context_put_wq);
@@ -1256,6 +1278,87 @@ static void fastrpc_update_invoke_count(u32 handle, u64
*perf_counter,
*count++;
}
+static int poll_for_remote_response(struct fastrpc_invoke_ctx *ctx, u64
timeout)
+{
+ int err = -EIO, i, j;
+ u32 sc = ctx->sc;
+ struct fastrpc_invoke_buf *list;
+ struct fastrpc_phy_page *pages;
+ u64 *fdlist = NULL;
+ u32 *crclist = NULL, *poll = NULL;
+ unsigned int inbufs, outbufs, handles;
+
+ /* calculate poll memory location */
+ inbufs = REMOTE_SCALARS_INBUFS(sc);
+ outbufs = REMOTE_SCALARS_OUTBUFS(sc);
+ handles = REMOTE_SCALARS_INHANDLES(sc) + REMOTE_SCALARS_OUTHANDLES(sc);
+ list = fastrpc_invoke_buf_start(ctx->rpra, ctx->nscalars);
+ pages = fastrpc_phy_page_start(list, ctx->nscalars);
+ fdlist = (u64 *)(pages + inbufs + outbufs + handles);
+ crclist = (u32 *)(fdlist + FASTRPC_MAX_FDLIST);
+ poll = (u32 *)(crclist + FASTRPC_MAX_CRCLIST);
+
+ /* poll on memory for DSP response. Return failure on timeout */
+ for (i = 0, j = 0; i < timeout; i++, j++) {
+ if (*poll == FASTRPC_POLL_RESPONSE) {
+ err = 0;
+ ctx->is_work_done = true;
+ ctx->retval = 0;
+ break;
+ }
+ if (j == FASTRPC_POLL_TIME_MEM_UPDATE) {
+ /* make sure that all poll memory writes by DSP are
seen by CPU */
+ dma_rmb();
+ j = 0;
+ }
+ udelay(1);
+ }
+ return err;
+}
+
+static inline int fastrpc_wait_for_response(struct fastrpc_invoke_ctx *ctx,
+ u32 kernel)
+{
+ int err = 0;
+
+ if (kernel) {
+ if (!wait_for_completion_timeout(&ctx->work, 10 * HZ))
+ err = -ETIMEDOUT;
+ } else {
+ err = wait_for_completion_interruptible(&ctx->work);
+ }
+
+ return err;
+}
+
+static int fastrpc_wait_for_completion(struct fastrpc_invoke_ctx *ctx,
+
Re: [PATCH] drm/fbdev-dma: Only cleanup deferred I/O if necessary
Am 06.10.24 um 19:49 schrieb Janne Grunau:
Commit 5a498d4d06d6 ("drm/fbdev-dma: Only install deferred I/O if
necessary") initializes deferred I/O only if it is used.
drm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup()
unconditionally with struct fb_info.fbdefio == NULL. KASAN with the
out-of-tree Apple silicon display driver posts following warning from
__flush_work() of a random struct work_struct instead of the expected
NULL pointer derefs.
[ 22.053799] [ cut here ]
[ 22.054832] WARNING: CPU: 2 PID: 1 at kernel/workqueue.c:4177
__flush_work+0x4d8/0x580
[ 22.056597] Modules linked in: uhid bnep uinput nls_ascii ip6_tables
ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs
xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple
brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev
regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm
snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart
apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84
videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg
apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev
pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco
i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm
drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram
[ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted
6.11.2-asahi+ #asahi-dev
[ 22.075612] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT)
[ 22.077032] pstate: 0145 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[ 22.078567] pc : __flush_work+0x4d8/0x580
[ 22.079471] lr : __flush_work+0x54/0x580
[ 22.080345] sp : c000836ef820
[ 22.081089] x29: c000836ef880 x28: x27: 80002ddb7128
[ 22.082678] x26: dfffc000 x25: 196f0c57 x24: c00082d3e358
[ 22.084263] x23: 80004b7862b8 x22: dfffc000 x21: 80005aa1d470
[ 22.085855] x20: 80004b786000 x19: 80004b7862a0 x18:
[ 22.087439] x17: x16: x15: 0005
[ 22.089030] x14: 1800106ddf0a x13: x12:
[ 22.090618] x11: b800106ddf0f x10: dfffc000 x9 : 1800106ddf0e
[ 22.092206] x8 : x7 : x6 : 0001
[ 22.093790] x5 : c000836ef728 x4 : x3 : 0020
[ 22.095368] x2 : 0008 x1 : 00aa x0 :
[ 22.096955] Call trace:
[ 22.097505] __flush_work+0x4d8/0x580
[ 22.098330] flush_delayed_work+0x80/0xb8
[ 22.099231] fb_deferred_io_cleanup+0x3c/0x130
[ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper]
[ 22.101559] unregister_framebuffer+0x210/0x2f0
[ 22.102575] drm_fb_helper_unregister_info+0x48/0x60
[ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper]
[ 22.105147] drm_client_dev_unregister+0x1cc/0x230
[ 22.106217] drm_dev_unregister+0x58/0x570
[ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm]
[ 22.108199] component_del+0x1f8/0x3a8
[ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp]
[ 22.110357] platform_shutdown+0x70/0x90
[ 22.111219] device_shutdown+0x368/0x4d8
[ 22.112095] kernel_restart+0x6c/0x1d0
[ 22.112946] __arm64_sys_reboot+0x1c8/0x328
[ 22.113868] invoke_syscall+0x78/0x1a8
[ 22.114703] do_el0_svc+0x124/0x1a0
[ 22.115498] el0_svc+0x3c/0xe0
[ 22.116181] el0t_64_sync_handler+0x70/0xc0
[ 22.117110] el0t_64_sync+0x190/0x198
[ 22.117931] ---[ end trace ]---
Signed-off-by: Janne Grunau
Fixes: 5a498d4d06d6 ("drm/fbdev-dma: Only install deferred I/O if necessary")
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fbdev_dma.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fbdev_dma.c b/drivers/gpu/drm/drm_fbdev_dma.c
index b0602c4f3628..51c2d742d199 100644
--- a/drivers/gpu/drm/drm_fbdev_dma.c
+++ b/drivers/gpu/drm/drm_fbdev_dma.c
@@ -50,7 +50,8 @@ static void drm_fbdev_dma_fb_destroy(struct fb_info *info)
if (!fb_helper->dev)
return;
- fb_deferred_io_cleanup(info);
+ if (info->fbdefio)
+ fb_deferred_io_cleanup(info);
drm_fb_helper_fini(fb_helper);
drm_client_buffer_vunmap(fb_helper->buffer);
---
base-commit: 98f7e32f20d28ec452afb208f9cffc08448a2652
change-id: 20241006-drm_fbdev_dma_deferred_io_cleanup-de87ee345dbc
Best regards,
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
Re: [PATCH v6 1/3] drm/mipi-dsi: add mipi_dsi_compression_mode_multi
On 06/10/2024 20:18, Dzmitry Sankouski wrote:
mipi_dsi_compression_mode_multi can help with
error handling.
Signed-off-by: Dzmitry Sankouski
---
drivers/gpu/drm/drm_mipi_dsi.c | 16
include/drm/drm_mipi_dsi.h | 2 ++
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 2bc3973d35a1..d8ee74701f1e 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -1520,6 +1520,22 @@ void mipi_dsi_compression_mode_ext_multi(struct
mipi_dsi_multi_context *ctx,
}
EXPORT_SYMBOL(mipi_dsi_compression_mode_ext_multi);
+/**
+ * mipi_dsi_compression_mode_multi() - enable/disable DSC on the peripheral
+ * @dsi: DSI peripheral device
+ * @enable: Whether to enable or disable the DSC
+ *
+ * Enable or disable Display Stream Compression on the peripheral using the
+ * default Picture Parameter Set and VESA DSC 1.1 algorithm.
+ */
+void mipi_dsi_compression_mode_multi(struct mipi_dsi_multi_context *ctx,
+bool enable)
+{
+ return mipi_dsi_compression_mode_ext_multi(ctx, enable,
+ MIPI_DSI_COMPRESSION_DSC, 0);
+}
+EXPORT_SYMBOL(mipi_dsi_compression_mode_multi);
+
/**
* mipi_dsi_dcs_nop_multi() - send DCS NOP packet
* @ctx: Context for multiple DSI transactions
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index f725f8654611..94400a78031f 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -280,6 +280,8 @@ void mipi_dsi_compression_mode_ext_multi(struct
mipi_dsi_multi_context *ctx,
bool enable,
enum mipi_dsi_compression_algo algo,
unsigned int pps_selector);
+void mipi_dsi_compression_mode_multi(struct mipi_dsi_multi_context *ctx,
+bool enable);
void mipi_dsi_picture_parameter_set_multi(struct mipi_dsi_multi_context *ctx,
const struct
drm_dsc_picture_parameter_set *pps);
Reviewed-by: Neil Armstrong
Re: [PATCH v9 2/5] drm/mediatek: ovl: Refine ignore_pixel_alpha comment and placement
Il 07/10/24 09:00, Jason-JH.Lin ha scritto: Refine the comment for ignore_pixel_alpha flag and move it to if (state->fb) statement to make it less conditional. Signed-off-by: Jason-JH.Lin Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH v9 0/2] Add driver for Sharp Memory LCD
> This patch series add support for the monochrome Sharp Memory LCD panels. … > --- > Changes in v9: … Would you like to benefit from the application of scope-based resource management (also for this software component)? Regards, Markus
Re: [PATCH v9 1/5] drm/mediatek: ovl: Fix XRGB format breakage for blend_modes unsupported SoCs
Il 07/10/24 09:00, Jason-JH.Lin ha scritto:
If the constant alpha always enable, the SoCs that is not supported the
ignore pixel alpha bit will still use constant alpha. That will break
the original constant alpha setting of XRGB foramt for blend_modes
unsupported SoCs, such as MT8173.
Note that ignore pixel alpha bit is suppored if the SoC support the
blend_modes.
Make the constatnt alpha only enable when having a vliad blend_mode or
setting the has_alpha to fix the downgrade issue.
Fixes: bc46eb5d5d77 ("drm/mediatek: Support DRM plane alpha in OVL")
Signed-off-by: Jason-JH.Lin
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 89b439dcf3a6..8453a72f9e59 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -473,8 +473,14 @@ void mtk_ovl_layer_config(struct device *dev, unsigned int
idx,
con = ovl_fmt_convert(ovl, fmt, blend_mode);
if (state->base.fb) {
- con |= OVL_CON_AEN;
con |= state->base.alpha & OVL_CON_ALPHA;
+
+ /*
+* For blend_modes supported SoCs, always enable constant alpha.
+* For blend_modes unsupported SoCs, enable constant alpha when
has_alpha is set.
+*/
+ if (blend_mode || state->base.fb->format->has_alpha)
+ con |= OVL_CON_AEN;
I'd say that you should make sure that OVL_CON_AEN is not set when
!blend_mode && !has_alpha, and you can do that like this:
if (blend_mode || state->base.fb->format->has_alpha)
con |= OVL_CON_AEN;
else
con &= ~OVL_CON_AEN;
After applying the proposed change,
Reviewed-by: AngeloGioacchino Del Regno
shift and mask issue in drivers/gpu/drm/sprd/megacores_pll.c
Hi, I noticed a shift/mask issue in dphy_set_pll_reg() in drivers/gpu/drm/sprd/megacores_pll.c, the expression (pll->kint << 4) & 0xf is always zero: ... reg_val[4] = pll->kint >> 12; reg_val[5] = pll->kint >> 4; reg_val[6] = pll->out_sel | ((pll->kint << 4) & 0xf); ... I'm not sure what the correct expression should be, but the current assignment to reg_val[6] seems incorrect to me. Colin
Re: [PATCH v9 0/2] Add driver for Sharp Memory LCD
On Mon, Oct 07, 2024 at 11:34:13AM +0200, Markus Elfring wrote: > > This patch series add support for the monochrome Sharp Memory LCD panels. > … > > --- > > Changes in v9: > … > > Would you like to benefit from the application of scope-based resource > management > (also for this software component)? Hi, This is the semi-friendly patch-bot of Greg Kroah-Hartman. Markus, you seem to have sent a nonsensical or otherwise pointless review comment to a patch submission on a Linux kernel developer mailing list. I strongly suggest that you not do this anymore. Please do not bother developers who are actively working to produce patches and features with comments that, in the end, are a waste of time. Patch submitter, please ignore Markus's suggestion; you do not need to follow it at all. The person/bot/AI that sent it is being ignored by almost all Linux kernel maintainers for having a persistent pattern of behavior of producing distracting and pointless commentary, and inability to adapt to feedback. Please feel free to also ignore emails from them. thanks, greg k-h's patch email bot
[PATCH v9 5/5] drm/mediatek: Add blend_modes to mtk_plane_init() for different SoCs
Since some SoCs support premultiplied pixel formats but some do not,
the blend_modes parameter is added to mtk_plane_init(), which is
obtained from the mtk_ddp_comp_get_blend_modes function implemented
in different blending supported components.
The blending supported components can use driver data to set the
blend mode capabilities for different SoCs.
Signed-off-by: Jason-JH.Lin
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_crtc.c | 1 +
drivers/gpu/drm/mediatek/mtk_ddp_comp.c | 2 ++
drivers/gpu/drm/mediatek/mtk_ddp_comp.h | 10 ++
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 2 ++
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 7 +++
drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 7 +++
drivers/gpu/drm/mediatek/mtk_ethdr.c| 7 +++
drivers/gpu/drm/mediatek/mtk_ethdr.h| 1 +
drivers/gpu/drm/mediatek/mtk_plane.c| 15 +++
drivers/gpu/drm/mediatek/mtk_plane.h| 4 ++--
10 files changed, 46 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_crtc.c
b/drivers/gpu/drm/mediatek/mtk_crtc.c
index 175b00e5a253..b65f196f2015 100644
--- a/drivers/gpu/drm/mediatek/mtk_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_crtc.c
@@ -913,6 +913,7 @@ static int mtk_crtc_init_comp_planes(struct drm_device
*drm_dev,
BIT(pipe),
mtk_crtc_plane_type(mtk_crtc->layer_nr,
num_planes),
mtk_ddp_comp_supported_rotations(comp),
+ mtk_ddp_comp_get_blend_modes(comp),
mtk_ddp_comp_get_formats(comp),
mtk_ddp_comp_get_num_formats(comp), i);
if (ret)
diff --git a/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
index be66d94be361..edc6417639e6 100644
--- a/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
@@ -363,6 +363,7 @@ static const struct mtk_ddp_comp_funcs ddp_ovl = {
.layer_config = mtk_ovl_layer_config,
.bgclr_in_on = mtk_ovl_bgclr_in_on,
.bgclr_in_off = mtk_ovl_bgclr_in_off,
+ .get_blend_modes = mtk_ovl_get_blend_modes,
.get_formats = mtk_ovl_get_formats,
.get_num_formats = mtk_ovl_get_num_formats,
};
@@ -416,6 +417,7 @@ static const struct mtk_ddp_comp_funcs ddp_ovl_adaptor = {
.disconnect = mtk_ovl_adaptor_disconnect,
.add = mtk_ovl_adaptor_add_comp,
.remove = mtk_ovl_adaptor_remove_comp,
+ .get_blend_modes = mtk_ovl_adaptor_get_blend_modes,
.get_formats = mtk_ovl_adaptor_get_formats,
.get_num_formats = mtk_ovl_adaptor_get_num_formats,
.mode_valid = mtk_ovl_adaptor_mode_valid,
diff --git a/drivers/gpu/drm/mediatek/mtk_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_ddp_comp.h
index ecf6dc283cd7..39720b27f4e9 100644
--- a/drivers/gpu/drm/mediatek/mtk_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_ddp_comp.h
@@ -80,6 +80,7 @@ struct mtk_ddp_comp_funcs {
void (*ctm_set)(struct device *dev,
struct drm_crtc_state *state);
struct device * (*dma_dev_get)(struct device *dev);
+ u32 (*get_blend_modes)(struct device *dev);
const u32 *(*get_formats)(struct device *dev);
size_t (*get_num_formats)(struct device *dev);
void (*connect)(struct device *dev, struct device *mmsys_dev, unsigned
int next);
@@ -266,6 +267,15 @@ static inline struct device
*mtk_ddp_comp_dma_dev_get(struct mtk_ddp_comp *comp)
return comp->dev;
}
+static inline
+u32 mtk_ddp_comp_get_blend_modes(struct mtk_ddp_comp *comp)
+{
+ if (comp->funcs && comp->funcs->get_blend_modes)
+ return comp->funcs->get_blend_modes(comp->dev);
+
+ return 0;
+}
+
static inline
const u32 *mtk_ddp_comp_get_formats(struct mtk_ddp_comp *comp)
{
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 082ac18fe04a..04154db9085c 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -103,6 +103,7 @@ 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);
+u32 mtk_ovl_get_blend_modes(struct device *dev);
const u32 *mtk_ovl_get_formats(struct device *dev);
size_t mtk_ovl_get_num_formats(struct device *dev);
@@ -131,6 +132,7 @@ void mtk_ovl_adaptor_start(struct device *dev);
void mtk_ovl_adaptor_stop(struct device *dev);
unsigned int mtk_ovl_adaptor_layer_nr(struct device *dev);
struct device *mtk_ovl_adaptor_dma_dev_get(struct device *dev);
+u32 mtk_ovl_adaptor_get_blend_modes(struct device *dev);
const u32 *mtk_ovl_adaptor_get_formats(struct device *dev);
size_t mtk_ovl_adaptor_get_num_f
[PATCH v9 0/5] Fix degradation problem of alpha blending series
Some SoCs do not support the ignore_pixl_alpha flag, which breaks the XRGB format. Some SoCs do not support pre-multiplied pixel formats and extending configuration of OVL pre-multiplied color formats, such as MT8173. Fix the SoC degradation problem by this sreies. --- Change in v9: 1. Add the fix patch for the XRGB downgrade issue of MT8173 2. Add the refine patch for ignore_pixel_alpha statement Change in v8: Remove blend_modes for not supported pre-multiplied SoCs to fix the return error from drm_plane_create_blend_mode_property(). Change in v7: 1. Add the remove color format comment patch for OVL 2. Fix warning: 'const' type qualifier on return type has no effect Chnage in v6: 1. Use blend_modes instead of function pointer in OVL 2. Use ethdr instead of mdp_rdma to get blend_modes 3. Add 0 checking for adding blend_mode property for mtk_plane Change in v5: Add fix patch for mtk_plane Change in v4: Add lost cases of mtk_ovl_fmt_convert_with_blend Change in v3: Change MACRO approach to function pointer in driver data Change in v2: Fix build error and typo Change in v1: Add fix patch for OVL unsupport color format settings by driver data --- Jason-JH.Lin (5): drm/mediatek: ovl: Fix XRGB format breakage for blend_modes unsupported SoCs drm/mediatek: ovl: Refine ignore_pixel_alpha comment and placement drm/mediatek: ovl: Remove the color format comment for ovl_fmt_convert() drm/mediatek: ovl: Add blend_modes to driver data drm/mediatek: Add blend_modes to mtk_plane_init() for different SoCs drivers/gpu/drm/mediatek/mtk_crtc.c | 1 + drivers/gpu/drm/mediatek/mtk_ddp_comp.c | 2 + drivers/gpu/drm/mediatek/mtk_ddp_comp.h | 10 +++ drivers/gpu/drm/mediatek/mtk_disp_drv.h | 2 + drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 70 ++- .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 7 ++ drivers/gpu/drm/mediatek/mtk_ethdr.c | 7 ++ drivers/gpu/drm/mediatek/mtk_ethdr.h | 1 + drivers/gpu/drm/mediatek/mtk_plane.c | 15 ++-- drivers/gpu/drm/mediatek/mtk_plane.h | 4 +- 10 files changed, 92 insertions(+), 27 deletions(-) -- 2.43.0
[PATCH v9 1/5] drm/mediatek: ovl: Fix XRGB format breakage for blend_modes unsupported SoCs
If the constant alpha always enable, the SoCs that is not supported the
ignore pixel alpha bit will still use constant alpha. That will break
the original constant alpha setting of XRGB foramt for blend_modes
unsupported SoCs, such as MT8173.
Note that ignore pixel alpha bit is suppored if the SoC support the
blend_modes.
Make the constatnt alpha only enable when having a vliad blend_mode or
setting the has_alpha to fix the downgrade issue.
Fixes: bc46eb5d5d77 ("drm/mediatek: Support DRM plane alpha in OVL")
Signed-off-by: Jason-JH.Lin
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 89b439dcf3a6..8453a72f9e59 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -473,8 +473,14 @@ void mtk_ovl_layer_config(struct device *dev, unsigned int
idx,
con = ovl_fmt_convert(ovl, fmt, blend_mode);
if (state->base.fb) {
- con |= OVL_CON_AEN;
con |= state->base.alpha & OVL_CON_ALPHA;
+
+ /*
+* For blend_modes supported SoCs, always enable constant alpha.
+* For blend_modes unsupported SoCs, enable constant alpha when
has_alpha is set.
+*/
+ if (blend_mode || state->base.fb->format->has_alpha)
+ con |= OVL_CON_AEN;
}
/* CONST_BLD must be enabled for XRGB formats although the alpha channel
--
2.43.0
[PATCH v9 2/5] drm/mediatek: ovl: Refine ignore_pixel_alpha comment and placement
Refine the comment for ignore_pixel_alpha flag and move it to
if (state->fb) statement to make it less conditional.
Signed-off-by: Jason-JH.Lin
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 8453a72f9e59..ddc826c42653 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -481,16 +481,16 @@ void mtk_ovl_layer_config(struct device *dev, unsigned
int idx,
*/
if (blend_mode || state->base.fb->format->has_alpha)
con |= OVL_CON_AEN;
- }
- /* CONST_BLD must be enabled for XRGB formats although the alpha channel
-* can be ignored, or OVL will still read the value from memory.
-* For RGB888 related formats, whether CONST_BLD is enabled or not won't
-* affect the result. Therefore we use !has_alpha as the condition.
-*/
- if ((state->base.fb && !state->base.fb->format->has_alpha) ||
- blend_mode == DRM_MODE_BLEND_PIXEL_NONE)
- ignore_pixel_alpha = OVL_CONST_BLEND;
+ /*
+* Although the alpha channel can be ignored, CONST_BLD must be
enabled
+* for XRGB format, otherwise OVL will still read the value
from memory.
+* For RGB888 related formats, whether CONST_BLD is enabled or
not won't
+* affect the result. Therefore we use !has_alpha as the
condition.
+*/
+ if (blend_mode == DRM_MODE_BLEND_PIXEL_NONE ||
!state->base.fb->format->has_alpha)
+ ignore_pixel_alpha = OVL_CONST_BLEND;
+ }
if (pending->rotation & DRM_MODE_REFLECT_Y) {
con |= OVL_CON_VIRT_FLIP;
--
2.43.0
[PATCH v9 3/5] drm/mediatek: ovl: Remove the color format comment for ovl_fmt_convert()
Since we changed MACROs to be consistent with DRM input color format
naming, the comment for ovl_fmt_conver() is no longer needed.
Fixes: 9f428b95ac89 ("drm/mediatek: Add new color format MACROs in OVL")
Signed-off-by: Jason-JH.Lin
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index ddc826c42653..22f17ebfd8b3 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -389,11 +389,6 @@ void mtk_ovl_layer_off(struct device *dev, unsigned int
idx,
static unsigned int ovl_fmt_convert(struct mtk_disp_ovl *ovl, unsigned int fmt,
unsigned int blend_mode)
{
- /* The return value in switch "MEM_MODE_INPUT_FORMAT_XXX"
-* is defined in mediatek HW data sheet.
-* The alphabet order in XXX is no relation to data
-* arrangement in memory.
-*/
switch (fmt) {
default:
case DRM_FORMAT_RGB565:
--
2.43.0
[PATCH v9 4/5] drm/mediatek: ovl: Add blend_modes to driver data
OVL_CON_CLRFMT_MAN is a configuration for extending color format
settings of DISP_REG_OVL_CON(n).
It will change some of the original color format settings.
Take the settings of (3 << 12) for example.
- If OVL_CON_CLRFMT_MAN = 0 means OVL_CON_CLRFMT_RGBA.
- If OVL_CON_CLRFMT_MAN = 1 means OVL_CON_CLRFMT_PARGB.
Since previous SoCs did not support OVL_CON_CLRFMT_MAN, this means
that the SoC does not support the premultiplied color format.
It will break the original color format setting of MT8173.
Therefore, the blend_modes is added to the driver data and then
mtk_ovl_fmt_convert() will check the blend_modes to see if
premultiplied supported in current platform.
If it is not supported, use coverage mode to set it to the supported
color formats to solve the degradation problem.
Fixes: a3f7f7ef4bfe ("drm/mediatek: Support "Pre-multiplied" blending in OVL")
Signed-off-by: Jason-JH.Lin
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 34 ++---
1 file changed, 31 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 22f17ebfd8b3..41874dc9d933 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -146,6 +146,7 @@ struct mtk_disp_ovl_data {
bool fmt_rgb565_is_0;
bool smi_id_en;
bool supports_afbc;
+ const u32 blend_modes;
const u32 *formats;
size_t num_formats;
bool supports_clrfmt_ext;
@@ -386,9 +387,27 @@ void mtk_ovl_layer_off(struct device *dev, unsigned int
idx,
DISP_REG_OVL_RDMA_CTRL(idx));
}
-static unsigned int ovl_fmt_convert(struct mtk_disp_ovl *ovl, unsigned int fmt,
- unsigned int blend_mode)
+static unsigned int mtk_ovl_fmt_convert(struct mtk_disp_ovl *ovl,
+ struct mtk_plane_state *state)
{
+ unsigned int fmt = state->pending.format;
+ unsigned int blend_mode = DRM_MODE_BLEND_COVERAGE;
+
+ /*
+* For the platforms where OVL_CON_CLRFMT_MAN is defined in the
hardware data sheet
+* and supports premultiplied color formats, such as
OVL_CON_CLRFMT_PARGB.
+*
+* Check blend_modes in the driver data to see if premultiplied mode is
supported.
+* If not, use coverage mode instead to set it to the supported color
formats.
+*
+* Current DRM assumption is that alpha is default premultiplied, so
the bitmask of
+* blend_modes must include BIT(DRM_MODE_BLEND_PREMULTI). Otherwise,
mtk_plane_init()
+* will get an error return from drm_plane_create_blend_mode_property()
and
+* state->base.pixel_blend_mode should not be used.
+*/
+ if (ovl->data->blend_modes & BIT(DRM_MODE_BLEND_PREMULTI))
+ blend_mode = state->base.pixel_blend_mode;
+
switch (fmt) {
default:
case DRM_FORMAT_RGB565:
@@ -466,7 +485,7 @@ void mtk_ovl_layer_config(struct device *dev, unsigned int
idx,
return;
}
- con = ovl_fmt_convert(ovl, fmt, blend_mode);
+ con = mtk_ovl_fmt_convert(ovl, state);
if (state->base.fb) {
con |= state->base.alpha & OVL_CON_ALPHA;
@@ -664,6 +683,9 @@ static const struct mtk_disp_ovl_data
mt8192_ovl_driver_data = {
.layer_nr = 4,
.fmt_rgb565_is_0 = true,
.smi_id_en = true,
+ .blend_modes = BIT(DRM_MODE_BLEND_PREMULTI) |
+ BIT(DRM_MODE_BLEND_COVERAGE) |
+ BIT(DRM_MODE_BLEND_PIXEL_NONE),
.formats = mt8173_formats,
.num_formats = ARRAY_SIZE(mt8173_formats),
};
@@ -674,6 +696,9 @@ static const struct mtk_disp_ovl_data
mt8192_ovl_2l_driver_data = {
.layer_nr = 2,
.fmt_rgb565_is_0 = true,
.smi_id_en = true,
+ .blend_modes = BIT(DRM_MODE_BLEND_PREMULTI) |
+ BIT(DRM_MODE_BLEND_COVERAGE) |
+ BIT(DRM_MODE_BLEND_PIXEL_NONE),
.formats = mt8173_formats,
.num_formats = ARRAY_SIZE(mt8173_formats),
};
@@ -685,6 +710,9 @@ static const struct mtk_disp_ovl_data
mt8195_ovl_driver_data = {
.fmt_rgb565_is_0 = true,
.smi_id_en = true,
.supports_afbc = true,
+ .blend_modes = BIT(DRM_MODE_BLEND_PREMULTI) |
+ BIT(DRM_MODE_BLEND_COVERAGE) |
+ BIT(DRM_MODE_BLEND_PIXEL_NONE),
.formats = mt8195_formats,
.num_formats = ARRAY_SIZE(mt8195_formats),
.supports_clrfmt_ext = true,
--
2.43.0
[PATCH v2 2/2] drm/bridge: sii902x: Set input bus format based on bus-width
Introduce a bus-width property to define the number of parallel RGB
input pins connected to the transmitter. The input bus formats are updated
accordingly. If the property is not specified, default to 24-bit bus-width.
Signed-off-by: Wadim Egorov
---
v2:
- Use bus-width instead of data-lines as suggested by Krzysztof
- Handle default case separately as an error case
---
drivers/gpu/drm/bridge/sii902x.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
index 7f91b0db161e..3b9e4e1dec45 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -180,6 +180,8 @@ struct sii902x {
struct gpio_desc *reset_gpio;
struct i2c_mux_core *i2cmux;
bool sink_is_hdmi;
+ u32 bus_width;
+
/*
* Mutex protects audio and video functions from interfering
* each other, by keeping their i2c command sequences atomic.
@@ -477,6 +479,8 @@ static u32 *sii902x_bridge_atomic_get_input_bus_fmts(struct
drm_bridge *bridge,
u32 output_fmt,
unsigned int
*num_input_fmts)
{
+
+ struct sii902x *sii902x = bridge_to_sii902x(bridge);
u32 *input_fmts;
*num_input_fmts = 0;
@@ -485,7 +489,20 @@ static u32
*sii902x_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
if (!input_fmts)
return NULL;
- input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+ switch (sii902x->bus_width) {
+ case 16:
+ input_fmts[0] = MEDIA_BUS_FMT_RGB565_1X16;
+ break;
+ case 18:
+ input_fmts[0] = MEDIA_BUS_FMT_RGB666_1X18;
+ break;
+ case 24:
+ input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+ break;
+ default:
+ return NULL;
+ }
+
*num_input_fmts = 1;
return input_fmts;
@@ -1167,6 +1184,15 @@ static int sii902x_probe(struct i2c_client *client)
return PTR_ERR(sii902x->reset_gpio);
}
+ endpoint = of_graph_get_endpoint_by_regs(dev->of_node, 0, -1);
+ if (endpoint) {
+ ret = of_property_read_u32(endpoint, "bus-width",
&sii902x->bus_width);
+ if (ret) {
+ dev_dbg(dev, "Could not get bus-width, defaulting to
24-bit bus-width\n");
+ sii902x->bus_width = 24;
+ }
+ }
+
endpoint = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
if (endpoint) {
struct device_node *remote =
of_graph_get_remote_port_parent(endpoint);
--
2.34.1
[PATCH v2 0/2] Introduce bus-width property for input bus format
This patch series introduces a bus-width property for the SI9022 HDMI transmitter, allowing the input bus format to be configured based on the number of RGB input pins. The default is set to 24-bit if unspecified. v2: - Reorder patches to have dt-bindings go first - Use bus-width instead of data-lines as suggested by Krzysztof - Handle default case separately as an error case v1: https://lore.kernel.org/lkml/20241003082006.2728617-1-w.ego...@phytec.de/T/ Wadim Egorov (2): dt-bindings: display: bridge: sil,sii9022: Add bus-width drm/bridge: sii902x: Set input bus format based on bus-width .../bindings/display/bridge/sil,sii9022.yaml | 15 +- drivers/gpu/drm/bridge/sii902x.c | 28 ++- 2 files changed, 41 insertions(+), 2 deletions(-) -- 2.34.1
[PATCH v2 1/2] dt-bindings: display: bridge: sil, sii9022: Add bus-width
The SI9022 HDMI transmitter can be configured with a bus-width of 16, 18, or 24 bits. Introduce a bus-width property to the input endpoint, specifying the number of parallel RGB input bits connected to the transmitter. Signed-off-by: Wadim Egorov --- v2: - Use bus-width instead of data-lines as suggested by Krzysztof - Provide a default --- .../bindings/display/bridge/sil,sii9022.yaml | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/bridge/sil,sii9022.yaml b/Documentation/devicetree/bindings/display/bridge/sil,sii9022.yaml index 5a69547ad3d7..1509c4535e53 100644 --- a/Documentation/devicetree/bindings/display/bridge/sil,sii9022.yaml +++ b/Documentation/devicetree/bindings/display/bridge/sil,sii9022.yaml @@ -81,9 +81,22 @@ properties: properties: port@0: -$ref: /schemas/graph.yaml#/properties/port +unevaluatedProperties: false +$ref: /schemas/graph.yaml#/$defs/port-base description: Parallel RGB input port +properties: + endpoint: +$ref: /schemas/graph.yaml#/$defs/endpoint-base +unevaluatedProperties: false + +properties: + bus-width: +description: + Endpoint bus width. +enum: [ 16, 18, 24 ] +default: 24 + port@1: $ref: /schemas/graph.yaml#/properties/port description: HDMI output port -- 2.34.1
Re: RESEND Re: [PATCH v4 1/2] drm/ttm: Move swapped objects off the manager's LRU list
My r-b still hold for this series. Please merge it through whatever
branch you are comfortable with.
And sorry for the delay, I'm still on sick leave (dentist problems).
Regards,
Christian.
Am 02.10.24 um 13:44 schrieb Thomas Hellström:
Hi, Christian,
Gentle ping on this one as well.
Thanks,
Thomas
On Thu, 2024-09-19 at 17:24 +0200, Thomas Hellström wrote:
Hi Christian,
Ping?
/Thomas
On Thu, 2024-09-12 at 15:40 +0200, Thomas Hellström wrote:
Hi, Christian,
On Wed, 2024-09-04 at 12:47 +0200, Christian König wrote:
Am 04.09.24 um 10:54 schrieb Thomas Hellström:
On Wed, 2024-09-04 at 10:50 +0200, Christian König wrote:
Am 04.09.24 um 09:08 schrieb Thomas Hellström:
Resources of swapped objects remains on the TTM_PL_SYSTEM
manager's
LRU list, which is bad for the LRU walk efficiency.
Rename the device-wide "pinned" list to "unevictable" and
move
also resources of swapped-out objects to that list.
An alternative would be to create an "UNEVICTABLE" priority
to
be able to keep the pinned- and swapped objects on their
respective manager's LRU without affecting the LRU walk
efficiency.
v2:
- Remove a bogus WARN_ON (Christian König)
- Update ttm_resource_[add|del] bulk move (Christian König)
- Fix TTM KUNIT tests (Intel CI)
v3:
- Check for non-NULL bo->resource in ttm_bo_populate().
v4:
- Don't move to LRU tail during swapout until the resource
is properly swapped or there was a swapout failure.
(Intel Ci)
- Add a newline after checkpatch check.
Cc: Christian König
Cc: Matthew Brost
Cc:
Signed-off-by: Thomas Hellström
I really wonder if having a SWAPPED wouldn't be cleaner in
the
long
run.
Anyway, that seems to work for now. So patch is Reviewed-by:
Christian
König .
Thanks. Are you ok with the changes to the pinning patch that
happened
after yoour R-B as well?
I was already wondering why the increment used to be separate
while
reviewing the initial version. So yes that looks better now.
Ack to merge through drm-misc-next once CI is clean?
Yeah, works for me.
Christian.
i915 & xe CI is clean now for this series but I had to change patch
1
slightly to avoid putting *all* resources that were created for a
swapped bo on the unevictable list (Typically VRAM resources that
were
created for validation back to VRAM).
So question is if your R-B still holds. Series is now at version 6.
Thanks,
Thomas
/Thomas
Regards,
Christian.
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c | 4 +-
drivers/gpu/drm/ttm/tests/ttm_bo_test.c | 4 +-
drivers/gpu/drm/ttm/tests/ttm_resource_test.c | 6 +-
drivers/gpu/drm/ttm/ttm_bo.c | 59
++-
drivers/gpu/drm/ttm/ttm_bo_util.c | 6 +-
drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 +-
drivers/gpu/drm/ttm/ttm_device.c | 4 +-
drivers/gpu/drm/ttm/ttm_resource.c | 15 +++--
drivers/gpu/drm/ttm/ttm_tt.c | 3 +
drivers/gpu/drm/xe/xe_bo.c | 4 +-
include/drm/ttm/ttm_bo.h | 2 +
include/drm/ttm/ttm_device.h | 5 +-
include/drm/ttm/ttm_tt.h | 5 ++
15 files changed, 96 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 5c72462d1f57..7de284766f82 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -808,7 +808,7 @@ static int __i915_ttm_get_pages(struct
drm_i915_gem_object *obj,
}
if (bo->ttm && !ttm_tt_is_populated(bo->ttm)) {
- ret = ttm_tt_populate(bo->bdev, bo->ttm,
&ctx);
+ ret = ttm_bo_populate(bo, &ctx);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 03b00a03a634..041dab543b78 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -624,7 +624,7 @@ int i915_ttm_move(struct
ttm_buffer_object
*bo,
bool evict,
/* Populate ttm with pages if needed. Typically
system
memory. */
if (ttm && (dst_man->use_tt || (ttm->page_flags &
TTM_TT_FLAG_SWAPPED))) {
- ret = ttm_tt_populate(bo->bdev, ttm, ctx);
+ ret = ttm_bo_populate(bo, ctx);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
index ad649523d5e0..61596cecce4d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
@@ -90,7 +90,7 @@ static int i915_ttm_backup(struct
i915_gem_apply_to_region *apply,
goto out_no_lock;
backup_bo = i915_gem_to_ttm(backup);
- er
Re: [PATCH v1 1/4] misc: fastrpc: Add CRC support using invokeV2 request
On Mon, Oct 07, 2024 at 02:15:15PM +0530, Ekansh Gupta wrote:
> +struct fastrpc_invoke_v2 {
> + struct fastrpc_invoke inv;
> + __u64 crc;
> + __u32 reserved[16];
I'm sure we have been over this before, but if you have a reserved
field, you HAVE to check that it is zero if you ever want to use it in
the future. As you did not check it, just remove it from this structure
as obviously it can never be used for anything.
Your internal review should have caught this, if not, please go fix it
AND get some internal review and signed-off-by before submitting this
series again.
thanks,
greg k-h
Re: [PATCH v2] fbdev: sstfb: Make CONFIG_FB_DEVICE optional
Hi
Am 04.10.24 um 17:24 schrieb Gonzalo Silvalde Blanco:
The sstfb driver currently depends on CONFIG_FB_DEVICE to create sysfs
entries and access info->dev. This patch wraps the relevant code blocks
with #ifdef CONFIG_FB_DEVICE, allowing the driver to be built and used
even if CONFIG_FB_DEVICE is not selected.
The sysfs setting only controls the VGA pass-through state and is not
required for the display to work correctly.
(See: http://vogonswiki.com/index.php/VGA_passthrough_cable
for more information.)
Tested by building with and without CONFIG_FB_DEVICE, both of which
compiled without issues.
Signed-off-by: Gonzalo Silvalde Blanco
Reviewed-by: Thomas Zimmermann
One thing I forgot, is that you also have to remove the dependency from
the Kconfig option. [1] Otherwise, it won't be possible to select the
driver.
Best regards
Thomas
[1]
https://elixir.bootlin.com/linux/v6.11.2/source/drivers/video/fbdev/Kconfig#L1239
---
drivers/video/fbdev/sstfb.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/sstfb.c b/drivers/video/fbdev/sstfb.c
index f8ae54ca0cc3..8d2e9d1f8d80 100644
--- a/drivers/video/fbdev/sstfb.c
+++ b/drivers/video/fbdev/sstfb.c
@@ -716,6 +716,7 @@ static void sstfb_setvgapass( struct fb_info *info, int
enable )
pci_write_config_dword(sst_dev, PCI_INIT_ENABLE, tmp);
}
+#ifdef CONFIG_FB_DEVICE
static ssize_t store_vgapass(struct device *device, struct device_attribute
*attr,
const char *buf, size_t count)
{
@@ -736,10 +737,10 @@ static ssize_t show_vgapass(struct device *device, struct
device_attribute *attr
struct sstfb_par *par = info->par;
return sprintf(buf, "%d\n", par->vgapass);
}
-
static struct device_attribute device_attrs[] = {
__ATTR(vgapass, S_IRUGO|S_IWUSR, show_vgapass, store_vgapass)
};
+#endif
static int sstfb_ioctl(struct fb_info *info, unsigned int cmd,
unsigned long arg)
@@ -1435,10 +1436,10 @@ static int sstfb_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
}
sstfb_clear_screen(info);
-
+#fdef CONFIG_FB_DEVICE
if (device_create_file(info->dev, &device_attrs[0]))
printk(KERN_WARNING "sstfb: can't create sysfs entry.\n");
-
+#endif
fb_info(info, "%s frame buffer device at 0x%p\n",
fix->id, info->screen_base);
@@ -1467,8 +1468,9 @@ static void sstfb_remove(struct pci_dev *pdev)
info = pci_get_drvdata(pdev);
par = info->par;
-
+#ifdef CONFIG_FB_DEVICE
device_remove_file(info->dev, &device_attrs[0]);
+#endif
sst_shutdown(info);
iounmap(info->screen_base);
iounmap(par->mmio_vbase);
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
Re: [PATCH v1 2/4] misc: fastrpc: Capture kernel and DSP performance counters
On Mon, Oct 07, 2024 at 02:15:16PM +0530, Ekansh Gupta wrote: > Add support to capture kernel performance counters for different > kernel level operations. These counters collects the information > for remote call and copies the information to a buffer shared > by user. > > Collection of DSP performance counters is also added as part of > this change. DSP updates the performance information in the > metadata which is then copied to a buffer passed by the users. "also" usually means "should be broken up into a new patch", right? Also, where is any of these new "performance counters" documented? Why not use the normal kernel apis for performance counters? thanks, greg k-h
Re: [PATCH v10 3/3] drm/mediatek: Implement OF graphs support for display paths
Il 07/10/24 08:57, CK Hu (胡俊光) ha scritto:
Hi, Angelo:
On Fri, 2024-10-04 at 12:22 +0200, AngeloGioacchino Del Regno wrote:
Il 04/10/24 08:03, CK Hu (胡俊光) ha scritto:
Hi, Angelo:
On Tue, 2024-10-01 at 13:33 +0200, AngeloGioacchino Del Regno wrote:
Il 01/10/24 12:07, CK Hu (胡俊光) ha scritto:
Hi, Angelo:
On Tue, 2024-09-10 at 10:51 +, AngeloGioacchino Del Regno wrote:
It is impossible to add each and every possible DDP path combination
for each and every possible combination of SoC and board: right now,
this driver hardcodes configuration for 10 SoCs and this is going to
grow larger and larger, and with new hacks like the introduction of
mtk_drm_route which is anyway not enough for all final routes as the
DSI cannot be connected to MERGE if it's not a dual-DSI, or enabling
DSC preventively doesn't work if the display doesn't support it, or
others.
Since practically all display IPs in MediaTek SoCs support being
interconnected with different instances of other, or the same, IPs
or with different IPs and in different combinations, the final DDP
pipeline is effectively a board specific configuration.
Implement OF graphs support to the mediatek-drm drivers, allowing to
stop hardcoding the paths, and preventing this driver to get a huge
amount of arrays for each board and SoC combination, also paving the
way to share the same mtk_mmsys_driver_data between multiple SoCs,
making it more straightforward to add support for new chips.
Reviewed-by: Alexandre Mergnat
Tested-by: Alexandre Mergnat
Acked-by: Sui Jingfeng
Tested-by: Michael Walle # on kontron-sbc-i1200
Signed-off-by: AngeloGioacchino Del Regno
---
[snip]
+
+bool mtk_ovl_adaptor_is_comp_present(struct device_node *node)
+{
+ enum mtk_ovl_adaptor_comp_type type;
+ int ret;
+
+ ret = ovl_adaptor_of_get_ddp_comp_type(node, &type);
+ if (ret)
+ return false;
+
+ if (type >= OVL_ADAPTOR_TYPE_NUM)
+ return false;
+
+ /*
+* ETHDR and Padding are used exclusively in OVL Adaptor: if this
+* component is not one of those, it's likely not an OVL Adaptor path.
+*/
I don't know your logic here.
The OVL Adaptor pipeline is:
mdp_rdma -> padding ---+ +---+
Merge -> | |
mdp_rdma -> padding ---+ | |
| |
mdp_rdma -> padding ---+ | |
Merge -> | |
mdp_rdma -> padding ---+ | |
| ETHDR |
mdp_rdma -> padding ---+ | |
Merge -> | |
mdp_rdma -> padding ---+ | |
| |
mdp_rdma -> padding ---+ | |
Merge -> | |
mdp_rdma -> padding ---+ +---+
So mdp_rdma and merge is not OVL Adaptor?
Yes, and in device tree, you express that exactly like you just pictured.
OVL Adaptor is treated like a software component internally, and manages
its own merge pipes exactly like before this commit.
In case there will be any need to express OVL Adaptor as hardware component,
it will be possible to do so with no modification to the bindings.
+ return type == OVL_ADAPTOR_TYPE_ETHDR || type ==
OVL_ADAPTOR_TYPE_PADDING;
+}
+
[snip]
+
+/**
+ * mtk_drm_of_ddp_path_build_one - Build a Display HW Pipeline for a CRTC Path
+ * @dev: The mediatek-drm device
+ * @cpath:CRTC Path relative to a VDO or MMSYS
+ * @out_path: Pointer to an array that will contain the new pipeline
+ * @out_path_len: Number of entries in the pipeline array
+ *
+ * MediaTek SoCs can use different DDP hardware pipelines (or paths) depending
+ * on the board-specific desired display configuration; this function walks
+ * through all of the output endpoints starting from a VDO or MMSYS hardware
+ * instance and builds the right pipeline as specified in device trees.
+ *
+ * Return:
+ * * %0 - Display HW Pipeline successfully built and validated
+ * * %-ENOENT - Display pipeline was not specified in device tree
+ * * %-EINVAL - Display pipeline built but validation failed
+ * * %-ENOMEM - Failure to allocate pipeline array to pass to the caller
+ */
+static int mtk_drm_of_ddp_path_build_one(struct device *dev, enum
mtk_crtc_path cpath,
+const unsigned int **out_path,
+unsigned int *out_path_len)
+{
+ struct device_node *next, *prev, *vdo = dev->parent->of_node;
+ unsigned int temp_path[DDP_COMPONENT_DRM_ID_MAX] = { 0 };
+ unsigned int *final_ddp_path;
+ unsigned short int idx = 0;
+ bool ovl_adaptor_comp_added = false;
+ int ret;
+
+ /* Get the first entry for the temp_path array */
+ ret = mtk_drm_of_get_ddp_ep_cid(vdo, 0, cpath, &next, &temp_path[idx]);
+ if (ret) {
+ if (next && temp_path[idx] == DDP_COMPONENT_DRM_OVL_ADAPTOR)
Re: [PATCH 4/7] drm/ttm: move LRU walk defines into new internal header
Hi Thomas, I'm on sick leave, but I will try to answer questions and share some thoughts on this to unblock you. Am 18.09.24 um 14:57 schrieb Thomas Hellström: Sima, Christian I've updated the shrinker series now with a guarded for_each macro instead: https://patchwork.freedesktop.org/patch/614514/?series=131815&rev=9 Yeah that looks like a big step in the right direction. (Note I forgot to remove the export of the previous LRU walker). so the midlayer argument is now not an issue anymore. The cleanup.h guard provides some additional protection against drivers exiting the LRU loop early. So remaining is the question whether the driver is allowed to discard a suggested bo to shrink from TTM. Arguments for: 1) Not allowing that would require teaching TTM about purgeable objects. I think that is actually not correct. TTM already knows about purgeable objects. E.g. when TTM asks the driver what to do with evicted objects it is perfectly valid to return an empty placement list indicating that the backing store can just be thrown away. We use this for things like temporary buffers for example. That this doesn't apply to swapping looks like a design bug in the driver/TTM interface to me. 2) Devices who need the blitter during shrinking would want to punt runtime_pm_get() to kswapd to avoid sleeping direct reclaim. I think the outcome of the discussion is that runtime PM should never be mixed into TTM swapping. You can power up blocks to enable a HW blitter for swapping, but this then can't be driven by the runtime PM framework. 3) If those devices end up blitting (LNL) to be able to shrink, they would want to punt waiting for the fence to signal to kswapd to avoid waiting in direct reclaim. Mhm, what do you mean with that? 4) It looks like we need to resort to folio_trylock in the shmem backup backend when shrinking is called for gfp_t = GFP_NOFS. A failing trylock will require a new bo. Why would a folio trylock succeed with one BO and not another? And why would that trylock something the device specific driver should handle? Arguments against: None really. I thought the idea of demidlayering would be to allow the driver more freedom. Well that is a huge argument against it. Giving drivers more freedom is absolutely not something which turned out to be valuable in the past. Instead we should put device drivers in a very strict corset of validated approaches to do things. Background is that in my experience driver developers are perfectly willing to do unclean approaches which only work in like 99% of all cases just to get a bit more performance or simpler driver implementation. Those approaches are not legal and in my opinion as subsystem maintainer I think we need to be more strict and push back much harder on stuff like that. Regards, Christian. So any feedback appreciated. If that is found acceptable we can proceed with reviewing this patch and also with the shrinker series. Thanks, Thomas On Mon, 2024-09-02 at 13:07 +0200, Daniel Vetter wrote: On Wed, Aug 28, 2024 at 02:20:34PM +0200, Christian König wrote: Am 27.08.24 um 19:53 schrieb Daniel Vetter: On Tue, Aug 27, 2024 at 06:52:13PM +0200, Daniel Vetter wrote: On Thu, Aug 22, 2024 at 03:19:29PM +0200, Christian König wrote: Completely agree that this is complicated, but I still don't see the need for it. Drivers just need to use pm_runtime_get_if_in_use() inside the shrinker and postpone all hw activity until resume. Not good enough, at least long term I think. Also postponing hw activity to resume doesn't solve the deadlock issue, if you still need to grab ttm locks on resume. Pondered this specific aspect some more, and I think you still have a race here (even if you avoid the deadlock): If the condiditional rpm_get call fails there's no guarantee that the device will suspend/resume and clean up the GART mapping. Well I think we have a major disconnect here. When the device is powered down there is no GART mapping to clean up any more. In other words GART is a table in local memory (VRAM) when the device is powered down this table is completely destroyed. Any BO which was mapped inside this table is now not mapped any more. So when the shrinker wants to evict a BO which is marked as mapped to GART and the device is powered down we just skip the GART unmapping part because that has already implicitly happened during power down. Before mapping any BO into the GART again we power the GPU up through the runtime PM calls. And while powering it up again the GART is restored. My point is that you can't tell whether the device will power down or not, you can only tell whether there's a chance it might be powering down and so you can't get at the rpm reference without deadlock issues. The race gets a bit smaller if you use pm_runtime_get_if_active(), but even then you might catch it right when resume almost finished. What race are you talking about? The worst thing which c
Re: [PATCH v3 13/14] drm/mediatek: Support DRM plane alpha in OVL
Re: [PATCH v3 0/4] drm/log: Introduce a new boot logger to draw the kmsg on the screen
On 05/10/2024 00:40, Caleb Connolly wrote: Hi Jocelyn, On 10/09/2024 08:56, Jocelyn Falempe wrote: drm_log is a simple logger that uses the drm_client API to print the kmsg boot log on the screen. This is not a full replacement to fbcon, as it will only print the kmsg. It will never handle user input, or a terminal because this is better done in userspace. I tried this out on the OnePlus 6 (Qualcomm SDM845/freedreno) and it looks great :D Here's a demo for kicks: https://people.linaro.org/~caleb.connolly/drm_log_oneplus6.mp4 Thanks, it's a really nice demo! For high-resolution screen, I will add integer scaling soon, so that should be a bit easier to read, without requiring huge fonts. -- Jocelyn Tested-by: Caleb Connolly # freedreno/dsi Kind regards, If you're curious on how it looks like, I've put a small demo here: https://people.redhat.com/jfalempe/drm_log/drm_log_draft_boot_v2.mp4 Design decisions: * It uses the drm_client API, so it should work on all drm drivers from the start. * It doesn't scroll the message, that way it doesn't need to redraw the whole screen for each new message. It also means it doesn't have to keep drawn messages in memory, to redraw them when scrolling. * drm_log can only be built-in (and drm must be built-in too). The reason is that, if you build it as a module, then a userspace application will be more appropriate than this module. * It uses the new non-blocking console API, so it should work well with PREEMPT_RT v2: * Use vmap_local() api, with that change, I've tested it successfully on simpledrm, virtio-gpu, amdgpu, and nouveau. * Stop drawing when the drm_master is taken. This avoid wasting CPU cycle if the buffer is not visible. * Use deferred probe. Only do the probe the first time there is a log to draw. With this, if you boot with quiet, drm_log won't do any modeset. * Add color support for the timestamp prefix, like what dmesg does. * Add build dependency on disabling the fbdev emulation, as they are both drm_client, and there is no way to choose which one gets the focus. v3: * Remove the work thread and circular buffer, and use the new write_thread() console API. * Register a console for each drm driver. Thanks and best regards, Jocelyn Falempe (4): drm/panic: Move drawing functions to drm_draw drm/log: Introduce a new boot logger to draw the kmsg on the screen drm/log: Do not draw if drm_master is taken drm/log: Color the timestamp, to improve readability drivers/gpu/drm/Kconfig | 19 ++ drivers/gpu/drm/Makefile | 3 + drivers/gpu/drm/drm_draw.c | 216 drivers/gpu/drm/drm_draw.h | 56 ++ drivers/gpu/drm/drm_drv.c | 2 + drivers/gpu/drm/drm_log.c | 391 drivers/gpu/drm/drm_log.h | 11 + drivers/gpu/drm/drm_panic.c | 247 +++ 8 files changed, 721 insertions(+), 224 deletions(-) create mode 100644 drivers/gpu/drm/drm_draw.c create mode 100644 drivers/gpu/drm/drm_draw.h create mode 100644 drivers/gpu/drm/drm_log.c create mode 100644 drivers/gpu/drm/drm_log.h base-commit: 9aaeb87ce1e966169a57f53a02ba05b30880ffb8
[PATCH v11 1/3] dt-bindings: display: mediatek: Add OF graph support for board path
The display IPs in MediaTek SoCs support being interconnected with
different instances of DDP IPs (for example, merge0 or merge1) and/or
with different DDP IPs (for example, rdma can be connected with either
color, dpi, dsi, merge, etc), forming a full Display Data Path that
ends with an actual display.
The final display pipeline is effectively board specific, as it does
depend on the display that is attached to it, and eventually on the
sensors supported by the board (for example, Adaptive Ambient Light
would need an Ambient Light Sensor, otherwise it's pointless!), other
than the output type.
Add support for OF graphs to most of the MediaTek DDP (display) bindings
to add flexibility to build custom hardware paths, hence enabling board
specific configuration of the display pipeline and allowing to finally
migrate away from using hardcoded paths.
Reviewed-by: Rob Herring (Arm)
Reviewed-by: Alexandre Mergnat
Tested-by: Alexandre Mergnat
Reviewed-by: CK Hu
Tested-by: Michael Walle # on kontron-sbc-i1200
Signed-off-by: AngeloGioacchino Del Regno
---
.../display/mediatek/mediatek,aal.yaml| 40 +++
.../display/mediatek/mediatek,ccorr.yaml | 21 ++
.../display/mediatek/mediatek,color.yaml | 22 ++
.../display/mediatek/mediatek,dither.yaml | 22 ++
.../display/mediatek/mediatek,dpi.yaml| 25 +++-
.../display/mediatek/mediatek,dsc.yaml| 24 +++
.../display/mediatek/mediatek,dsi.yaml| 27 -
.../display/mediatek/mediatek,ethdr.yaml | 22 ++
.../display/mediatek/mediatek,gamma.yaml | 19 +
.../display/mediatek/mediatek,merge.yaml | 23 +++
.../display/mediatek/mediatek,od.yaml | 22 ++
.../display/mediatek/mediatek,ovl-2l.yaml | 22 ++
.../display/mediatek/mediatek,ovl.yaml| 22 ++
.../display/mediatek/mediatek,postmask.yaml | 21 ++
.../display/mediatek/mediatek,rdma.yaml | 22 ++
.../display/mediatek/mediatek,ufoe.yaml | 21 ++
16 files changed, 372 insertions(+), 3 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
index cf24434854ff..47ddba5c41af 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
@@ -62,6 +62,27 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: AAL input port
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ AAL output to the next component's input, for example could be one
+ of many gamma, overdrive or other blocks.
+
+required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
@@ -89,5 +110,24 @@ examples:
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_AAL>;
mediatek,gce-client-reg = <&gce SUBSYS_1401 0x5000 0x1000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ aal0_in: endpoint {
+ remote-endpoint = <&ccorr0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ aal0_out: endpoint {
+ remote-endpoint = <&gamma0_in>;
+ };
+ };
+ };
};
};
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
index 9f8366763831..fca8e7bb0cbc 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
@@ -57,6 +57,27 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: CCORR input port
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ CCORR output to the input of the next desired component in the
+ display pipeline,
[PATCH v11 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths per HW instance (so potentially up to six displays for multi-vdo SoCs). The MMSYS or VDOSYS is always the first component in the DDP pipeline, so it only supports an output port with multiple endpoints - where each endpoint defines the starting point for one of the (currently three) possible hardware paths. Reviewed-by: Rob Herring (Arm) Reviewed-by: Alexandre Mergnat Tested-by: Alexandre Mergnat Reviewed-by: CK Hu Tested-by: Michael Walle # on kontron-sbc-i1200 Signed-off-by: AngeloGioacchino Del Regno --- .../bindings/arm/mediatek/mediatek,mmsys.yaml | 28 +++ 1 file changed, 28 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml index b3c6888c1457..3f4262e93c78 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml @@ -93,6 +93,34 @@ properties: '#reset-cells': const: 1 + port: +$ref: /schemas/graph.yaml#/properties/port +description: + Output port node. This port connects the MMSYS/VDOSYS output to + the first component of one display pipeline, for example one of + the available OVL or RDMA blocks. + Some MediaTek SoCs support multiple display outputs per MMSYS. +properties: + endpoint@0: +$ref: /schemas/graph.yaml#/properties/endpoint +description: Output to the primary display pipeline + + endpoint@1: +$ref: /schemas/graph.yaml#/properties/endpoint +description: Output to the secondary display pipeline + + endpoint@2: +$ref: /schemas/graph.yaml#/properties/endpoint +description: Output to the tertiary display pipeline + +anyOf: + - required: + - endpoint@0 + - required: + - endpoint@1 + - required: + - endpoint@2 + required: - compatible - reg -- 2.46.1
[PATCH v11 3/3] drm/mediatek: Implement OF graphs support for display paths
It is impossible to add each and every possible DDP path combination
for each and every possible combination of SoC and board: right now,
this driver hardcodes configuration for 10 SoCs and this is going to
grow larger and larger, and with new hacks like the introduction of
mtk_drm_route which is anyway not enough for all final routes as the
DSI cannot be connected to MERGE if it's not a dual-DSI, or enabling
DSC preventively doesn't work if the display doesn't support it, or
others.
Since practically all display IPs in MediaTek SoCs support being
interconnected with different instances of other, or the same, IPs
or with different IPs and in different combinations, the final DDP
pipeline is effectively a board specific configuration.
Implement OF graphs support to the mediatek-drm drivers, allowing to
stop hardcoding the paths, and preventing this driver to get a huge
amount of arrays for each board and SoC combination, also paving the
way to share the same mtk_mmsys_driver_data between multiple SoCs,
making it more straightforward to add support for new chips.
Reviewed-by: Alexandre Mergnat
Tested-by: Alexandre Mergnat
Acked-by: Sui Jingfeng
Tested-by: Michael Walle # on kontron-sbc-i1200
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 1 +
.../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 43 ++-
drivers/gpu/drm/mediatek/mtk_dpi.c| 21 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.c| 253 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.h| 2 +-
drivers/gpu/drm/mediatek/mtk_dsi.c| 14 +-
6 files changed, 312 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 082ac18fe04a..94843974851f 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -108,6 +108,7 @@ size_t mtk_ovl_get_num_formats(struct device *dev);
void mtk_ovl_adaptor_add_comp(struct device *dev, struct mtk_mutex *mutex);
void mtk_ovl_adaptor_remove_comp(struct device *dev, struct mtk_mutex *mutex);
+bool mtk_ovl_adaptor_is_comp_present(struct device_node *node);
void mtk_ovl_adaptor_connect(struct device *dev, struct device *mmsys_dev,
unsigned int next);
void mtk_ovl_adaptor_disconnect(struct device *dev, struct device *mmsys_dev,
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
index c6768210b08b..4e064d3c97cc 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c
@@ -490,6 +490,41 @@ static int compare_of(struct device *dev, void *data)
return dev->of_node == data;
}
+static int ovl_adaptor_of_get_ddp_comp_type(struct device_node *node,
+ enum mtk_ovl_adaptor_comp_type
*ctype)
+{
+ const struct of_device_id *of_id =
of_match_node(mtk_ovl_adaptor_comp_dt_ids, node);
+
+ if (!of_id)
+ return -EINVAL;
+
+ *ctype = (enum mtk_ovl_adaptor_comp_type)((uintptr_t)of_id->data);
+
+ return 0;
+}
+
+bool mtk_ovl_adaptor_is_comp_present(struct device_node *node)
+{
+ enum mtk_ovl_adaptor_comp_type type;
+ int ret;
+
+ ret = ovl_adaptor_of_get_ddp_comp_type(node, &type);
+ if (ret)
+ return false;
+
+ if (type >= OVL_ADAPTOR_TYPE_NUM)
+ return false;
+
+ /*
+* In the context of mediatek-drm, ETHDR, MDP_RDMA and Padding are
+* used exclusively by OVL Adaptor: if this component is not one of
+* those, it's likely not an OVL Adaptor path.
+*/
+ return type == OVL_ADAPTOR_TYPE_ETHDR ||
+ type == OVL_ADAPTOR_TYPE_MDP_RDMA ||
+ type == OVL_ADAPTOR_TYPE_PADDING;
+}
+
static int ovl_adaptor_comp_init(struct device *dev, struct component_match
**match)
{
struct mtk_disp_ovl_adaptor *priv = dev_get_drvdata(dev);
@@ -499,12 +534,11 @@ static int ovl_adaptor_comp_init(struct device *dev,
struct component_match **ma
parent = dev->parent->parent->of_node->parent;
for_each_child_of_node_scoped(parent, node) {
- const struct of_device_id *of_id;
enum mtk_ovl_adaptor_comp_type type;
- int id;
+ int id, ret;
- of_id = of_match_node(mtk_ovl_adaptor_comp_dt_ids, node);
- if (!of_id)
+ ret = ovl_adaptor_of_get_ddp_comp_type(node, &type);
+ if (ret)
continue;
if (!of_device_is_available(node)) {
@@ -513,7 +547,6 @@ static int ovl_adaptor_comp_init(struct device *dev, struct
component_match **ma
continue;
}
- type = (enum mtk_ovl_adaptor_comp_type)(uintptr_t)of_id->data;
id = ovl_adaptor_comp_get_id(dev, node, type);
[PATCH v11 0/3] drm/mediatek: Add support for OF graphs
Changes in v11: - Added OVL_ADAPTOR_MDP_RDMA to OVL Adaptor exclusive components list to avoid failures in graphs with MDP_RDMA inside - Rebased on next-20241004 Changes in v10: - Removed erroneously added *.orig/*.rej files Changes in v9: - Rebased on next-20240910 - Removed redundant assignment and changed a print to dev_err() - Dropped if branch to switch conversion as requested; this will be sent as a separate commit out of this series. Changes in v8: - Rebased on next-20240617 - Changed to allow probing a VDO with no available display outputs Changes in v7: - Fix typo in patch 3/3 Changes in v6: - Added EPROBE_DEFER check to fix dsi/dpi false positive DT fallback case - Dropped refcount of ep_out in mtk_drm_of_get_ddp_ep_cid() - Fixed double refcount drop during path building - Removed failure upon finding a DT-disabled path as requested - Tested again on MT8195, MT8395 boards Changes in v5: - Fixed commit [2/3], changed allOf -> anyOf to get the intended allowance in the binding Changes in v4: - Fixed a typo that caused pure OF graphs pipelines multiple concurrent outputs to not get correctly parsed (port->id); - Added OVL_ADAPTOR support for OF graph specified pipelines; - Now tested with fully OF Graph specified pipelines on MT8195 Chromebooks and MT8395 boards; - Rebased on next-20240516 Changes in v3: - Rebased on next-20240502 because of renames in mediatek-drm Changes in v2: - Fixed wrong `required` block indentation in commit [2/3] The display IPs in MediaTek SoCs are *VERY* flexible and those support being interconnected with different instances of DDP IPs (for example, merge0 or merge1) and/or with different DDP IPs (for example, rdma can be connected with either color, dpi, dsi, merge, etc), forming a full Display Data Path that ends with an actual display. This series was born because of an issue that I've found while enabling support for MT8195/MT8395 boards with DSI output as main display: the current mtk_drm_route variations would not work as currently, the driver hardcodes a display path for Chromebooks, which have a DisplayPort panel with DSC support, instead of a DSI panel without DSC support. There are other reasons for which I wrote this series, and I find that hardcoding those paths - when a HW path is clearly board-specific - is highly suboptimal. Also, let's not forget about keeping this driver from becoming a huge list of paths for each combination of SoC->board->disp and... this and that. For more information, please look at the commit description for each of the commits included in this series. This series is essential to enable support for the MT8195/MT8395 EVK, Kontron i1200, Radxa NIO-12L and, mainly, for non-Chromebook boards and Chromebooks to co-exist without conflicts. Besides, this is also a valid option for MT8188 Chromebooks which might have different DSI-or-eDP displays depending on the model (as far as I can see from the mtk_drm_route attempt for this SoC that is already present in this driver). This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa NIO-12L with both hardcoded paths, OF graph support and partially hardcoded paths, and pure OF graph support including pipelines that require OVL_ADAPTOR support. AngeloGioacchino Del Regno (3): dt-bindings: display: mediatek: Add OF graph support for board path dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path drm/mediatek: Implement OF graphs support for display paths .../bindings/arm/mediatek/mediatek,mmsys.yaml | 28 ++ .../display/mediatek/mediatek,aal.yaml| 40 +++ .../display/mediatek/mediatek,ccorr.yaml | 21 ++ .../display/mediatek/mediatek,color.yaml | 22 ++ .../display/mediatek/mediatek,dither.yaml | 22 ++ .../display/mediatek/mediatek,dpi.yaml| 25 +- .../display/mediatek/mediatek,dsc.yaml| 24 ++ .../display/mediatek/mediatek,dsi.yaml| 27 +- .../display/mediatek/mediatek,ethdr.yaml | 22 ++ .../display/mediatek/mediatek,gamma.yaml | 19 ++ .../display/mediatek/mediatek,merge.yaml | 23 ++ .../display/mediatek/mediatek,od.yaml | 22 ++ .../display/mediatek/mediatek,ovl-2l.yaml | 22 ++ .../display/mediatek/mediatek,ovl.yaml| 22 ++ .../display/mediatek/mediatek,postmask.yaml | 21 ++ .../display/mediatek/mediatek,rdma.yaml | 22 ++ .../display/mediatek/mediatek,ufoe.yaml | 21 ++ drivers/gpu/drm/mediatek/mtk_disp_drv.h | 1 + .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 43 ++- drivers/gpu/drm/mediatek/mtk_dpi.c| 21 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c| 253 +- drivers/gpu/drm/mediatek/mtk_drm_drv.h| 2 +- drivers/gpu/drm/mediatek/mtk_dsi.c| 14 +- 23 files changed, 712 insertions(+), 25 deletions(-) -- 2.46.1
[PATCH] dma-buf: Use atomic64_inc_return() in dma_buf_getfile()
Use atomic64_inc_return(&ref) instead of atomic64_add_return(1, &ref) to use optimized implementation and ease register pressure around the primitive for targets that implement optimized variant. Signed-off-by: Uros Bizjak Cc: Sumit Semwal Cc: "Christian König" --- drivers/dma-buf/dma-buf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 8892bc701a66..a3649db76add 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -558,7 +558,7 @@ static struct file *dma_buf_getfile(size_t size, int flags) * Override ->i_ino with the unique and dmabuffs specific * value. */ - inode->i_ino = atomic64_add_return(1, &dmabuf_inode); + inode->i_ino = atomic64_inc_return(&dmabuf_inode); flags &= O_ACCMODE | O_NONBLOCK; file = alloc_file_pseudo(inode, dma_buf_mnt, "dmabuf", flags, &dma_buf_fops); -- 2.46.2
RE: [PATCH 3/6] drm/exynos: exynos7_drm_decon: fix ideal_clk by converting it to Hz
> -Original Message-
> From: Kaustabh Chakraborty
> Sent: Friday, September 20, 2024 12:11 AM
> To: Inki Dae ; Seung-Woo Kim
> ; Kyungmin Park ; David
> Airlie ; Simona Vetter ; Krzysztof
> Kozlowski ; Alim Akhtar ;
> Maarten Lankhorst ; Maxime Ripard
> ; Thomas Zimmermann ; Rob Herring
> ; Conor Dooley
> Cc: dri-devel@lists.freedesktop.org; linux-arm-ker...@lists.infradead.org;
> linux-samsung-...@vger.kernel.org; linux-ker...@vger.kernel.org;
> devicet...@vger.kernel.org; Kaustabh Chakraborty
> Subject: [PATCH 3/6] drm/exynos: exynos7_drm_decon: fix ideal_clk by
> converting it to Hz
>
> The clkdiv values are incorrect as ideal_clk is in kHz and the clock
> rate of vclk is in Hz. Multiply 1000 to ideal_clk to bring it to Hz.
>
> Signed-off-by: Kaustabh Chakraborty
> ---
> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index 2c4ee87ae6ec..4e4ced50ff15 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -137,7 +137,7 @@ static void decon_ctx_remove(struct decon_context *ctx)
> static u32 decon_calc_clkdiv(struct decon_context *ctx,
> const struct drm_display_mode *mode)
> {
> - unsigned long ideal_clk = mode->clock;
> + unsigned long ideal_clk = mode->clock * 1000;
Right. ideal_clk should be fixed with Hz.
Thanks,
Inki Dae
> u32 clkdiv;
>
> /* Find the clock divider value that gets us closest to ideal_clk
> */
>
> --
> 2.46.1
