Administrivia: remove old list address
Hi all, Many years ago, linuxppc-dev was moved from ozlabs.org to lists.ozlabs.org. These days most of the mail sent to linuxppc-dev @ozlabs.org is spam (causing added burden to the list owner i.e. me), so I intend to drop that name. Initially, it will bounce with a message pointing to the new name, but after some time it will just bounce. I have submitted a patch to fix up the remaining (fairly obscure) references to the old name in the kernel sources. Does anyone have any objections to this plan? I also have a longer term plan to not accept HTML formatted emails on the list (as they are also mostly spam). -- Cheers, Stephen Rothwell pgpxqF7lMNzSP.pgp Description: OpenPGP digital signature
Re: [PATCH 2/2] MAINTAINERS: Make cxl obsolete
On Tue, 2024-04-09 at 14:37 +1000, Michael Ellerman wrote: > > Something like the patch below. Anyone who has an existing config and > runs oldconfig will get a prompt, eg: > > Deprecated support for IBM Coherent Accelerators (CXL) > (DEPRECATED_CXL) [N/m/y/?] (NEW) > > Folks who just use defconfig etc. won't notice any change which is a > pity. We could also change the default to n, but that risks breaking > someone's machine. Maybe we do that in a another releases time. > > cheers > > diff --git a/drivers/misc/cxl/Kconfig b/drivers/misc/cxl/Kconfig > index 5efc4151bf58..e3fd3fcaf62a 100644 > --- a/drivers/misc/cxl/Kconfig > +++ b/drivers/misc/cxl/Kconfig > @@ -9,11 +9,18 @@ config CXL_BASE > select PPC_64S_HASH_MMU > > config CXL > - tristate "Support for IBM Coherent Accelerators (CXL)" > + def_bool y > + depends on DEPRECATED_CXL > + > +config DEPRECATED_CXL > + tristate "Deprecated support for IBM Coherent Accelerators > (CXL)" This doesn't seem quite right to me, I don't think we can just redefine CONFIG_CXL as a bool, but I'll do something like this. Probably won't bother for CXLFLASH since they'll see it for CXL anyway, but I might add a warning message on probe to both drivers. > depends on PPC_POWERNV && PCI_MSI && EEH > select CXL_BASE > default m > help > + The cxl driver is no longer actively maintained and we > intend to > + remove it in a future kernel release. > + > Select this option to enable driver support for IBM > Coherent > Accelerators (CXL). CXL is otherwise known as Coherent > Accelerator > Processor Interface (CAPI). CAPI allows accelerators in > FPGAs to be -- Andrew DonnellanOzLabs, ADL Canberra a...@linux.ibm.com IBM Australia Limited
Re: [PATCH 1/3] powerpc/mm: Align memory_limit value specified using mem= kernel parameter
Joel Savitz writes: > On Wed, Apr 17, 2024 at 10:36 AM Joel Savitz wrote: >> >> Acked-by: Joel Savitz >> > > Hi, > > What is the status of this? This patch fixes a bug where a powerpc > machine hangs at boot when passed an unaligned value in the mem= > kernel parameter. It's in linux-next for v6.10 cheers
[PATCH] Fix the address of the linuxppc-dev mailing list
This list was moved many years ago. Signed-off-by: Stephen Rothwell --- Documentation/ABI/testing/sysfs-devices-system-cpu | 14 +++--- .../ABI/testing/sysfs-firmware-opal-powercap | 4 ++-- Documentation/ABI/testing/sysfs-firmware-opal-psr | 4 ++-- .../ABI/testing/sysfs-firmware-opal-sensor-groups | 4 ++-- .../testing/sysfs-firmware-papr-energy-scale-info | 10 +- 5 files changed, 18 insertions(+), 18 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index 710d47be11e0..e7e160954e79 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -423,7 +423,7 @@ What: /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/occ_reset Date: March 2016 Contact: Linux kernel mailing list - Linux for PowerPC mailing list + Linux for PowerPC mailing list Description: POWERNV CPUFreq driver's frequency throttle stats directory and attributes @@ -473,7 +473,7 @@ What: /sys/devices/system/cpu/cpufreq/policyX/throttle_stats /sys/devices/system/cpu/cpufreq/policyX/throttle_stats/occ_reset Date: March 2016 Contact: Linux kernel mailing list - Linux for PowerPC mailing list + Linux for PowerPC mailing list Description: POWERNV CPUFreq driver's frequency throttle stats directory and attributes @@ -608,7 +608,7 @@ Description:Umwait control What: /sys/devices/system/cpu/svm Date: August 2019 Contact: Linux kernel mailing list - Linux for PowerPC mailing list + Linux for PowerPC mailing list Description: Secure Virtual Machine If 1, it means the system is using the Protected Execution @@ -617,7 +617,7 @@ Description:Secure Virtual Machine What: /sys/devices/system/cpu/cpuX/purr Date: Apr 2005 -Contact: Linux for PowerPC mailing list +Contact: Linux for PowerPC mailing list Description: PURR ticks for this CPU since the system boot. The Processor Utilization Resources Register (PURR) is @@ -628,7 +628,7 @@ Description:PURR ticks for this CPU since the system boot. What: /sys/devices/system/cpu/cpuX/spurr Date: Dec 2006 -Contact: Linux for PowerPC mailing list +Contact: Linux for PowerPC mailing list Description: SPURR ticks for this CPU since the system boot. The Scaled Processor Utilization Resources Register @@ -640,7 +640,7 @@ Description:SPURR ticks for this CPU since the system boot. What: /sys/devices/system/cpu/cpuX/idle_purr Date: Apr 2020 -Contact: Linux for PowerPC mailing list +Contact: Linux for PowerPC mailing list Description: PURR ticks for cpuX when it was idle. This sysfs interface exposes the number of PURR ticks @@ -648,7 +648,7 @@ Description:PURR ticks for cpuX when it was idle. What: /sys/devices/system/cpu/cpuX/idle_spurr Date: Apr 2020 -Contact: Linux for PowerPC mailing list +Contact: Linux for PowerPC mailing list Description: SPURR ticks for cpuX when it was idle. This sysfs interface exposes the number of SPURR ticks diff --git a/Documentation/ABI/testing/sysfs-firmware-opal-powercap b/Documentation/ABI/testing/sysfs-firmware-opal-powercap index c9b66ec4f165..d2d12ee89288 100644 --- a/Documentation/ABI/testing/sysfs-firmware-opal-powercap +++ b/Documentation/ABI/testing/sysfs-firmware-opal-powercap @@ -1,6 +1,6 @@ What: /sys/firmware/opal/powercap Date: August 2017 -Contact: Linux for PowerPC mailing list +Contact: Linux for PowerPC mailing list Description: Powercap directory for Powernv (P8, P9) servers Each folder in this directory contains a @@ -11,7 +11,7 @@ What: /sys/firmware/opal/powercap/system-powercap /sys/firmware/opal/powercap/system-powercap/powercap-max /sys/firmware/opal/powercap/system-powercap/powercap-current Date: August 2017 -Contact: Linux for PowerPC mailing list +Contact: Linux for PowerPC mailing list Description: System powercap directory and attributes applicable for Powernv (P8, P9) servers diff --git a/Documentation/ABI/testing/sysfs-firmware-opal-psr b/Documentation/ABI/testing/sysfs-firmware-opal-psr index cc2ece70e365..1e55b56a0f89 100644 --- a/Documentation/ABI/testing/sysfs-firmware-opal-psr +++ b/Documentation/ABI/testing/sysfs-firmware-opal-psr @@ -1,6 +1,6 @@ What: /sys/firmware/opal/psr Date: August 2017 -Contact: Linux for PowerPC
Re: [PATCH] [RFC] scsi: Convert from tasklet to BH workqueue
Allen Pais writes: > The only generic interface to execute asynchronously in the BH context is > tasklet; however, it's marked deprecated and has some design flaws. To > replace tasklets, BH workqueue support was recently added. A BH workqueue > behaves similarly to regular workqueues except that the queued work items > are executed in the BH context. > > This patch converts drivers/scsi/* from tasklet to BH workqueue. > > Based on the work done by Tejun Heo > Branch: https://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-6.10 > > Signed-off-by: Allen Pais > --- > drivers/scsi/aic7xxx/aic7xxx_osm.c | 2 +- > drivers/scsi/aic94xx/aic94xx_hwi.c | 14 ++-- > drivers/scsi/aic94xx/aic94xx_hwi.h | 5 +- > drivers/scsi/aic94xx/aic94xx_scb.c | 36 +- > drivers/scsi/aic94xx/aic94xx_task.c | 14 ++-- > drivers/scsi/aic94xx/aic94xx_tmf.c | 34 - > drivers/scsi/esas2r/esas2r.h| 12 ++-- > drivers/scsi/esas2r/esas2r_init.c | 14 ++-- > drivers/scsi/esas2r/esas2r_int.c| 18 ++--- > drivers/scsi/esas2r/esas2r_io.c | 2 +- > drivers/scsi/esas2r/esas2r_main.c | 16 ++--- > drivers/scsi/ibmvscsi/ibmvfc.c | 16 ++--- > drivers/scsi/ibmvscsi/ibmvfc.h | 3 +- > drivers/scsi/ibmvscsi/ibmvscsi.c| 16 ++--- > drivers/scsi/ibmvscsi/ibmvscsi.h| 3 +- > drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c| 15 ++-- > drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.h| 3 +- Something there is giving me a build failure (ppc64le_guest_defconfig): + make -s 'CC=ccache powerpc64le-linux-gnu-gcc' -j 4 /linux/drivers/scsi/ibmvscsi/ibmvscsi.c: In function 'ibmvscsi_init_crq_queue': Error: /linux/drivers/scsi/ibmvscsi/ibmvscsi.c:370:331: error: 'ibmvscsi_work' undeclared (first use in this function) /linux/drivers/scsi/ibmvscsi/ibmvscsi.c:370:331: note: each undeclared identifier is reported only once for each function it appears in /linux/scripts/Makefile.build:244: recipe for target 'drivers/scsi/ibmvscsi/ibmvscsi.o' failed /linux/scripts/Makefile.build:485: recipe for target 'drivers/scsi/ibmvscsi' failed /linux/scripts/Makefile.build:485: recipe for target 'drivers/scsi' failed /linux/scripts/Makefile.build:485: recipe for target 'drivers' failed /linux/drivers/scsi/ibmvscsi/ibmvscsi.c: In function 'ibmvscsi_probe': Error: /linux/drivers/scsi/ibmvscsi/ibmvscsi.c:2255:78: error: passing argument 1 of 'kthread_create_on_node' from incompatible pointer type [-Werror=incompatible-pointer-types] In file included from /linux/drivers/scsi/ibmvscsi/ibmvscsi.c:56:0: /linux/include/linux/kthread.h:11:21: note: expected 'int (*)(void *)' but argument is of type 'int (*)(struct work_struct *)' struct task_struct *kthread_create_on_node(int (*threadfn)(void *data), ^ /linux/drivers/scsi/ibmvscsi/ibmvscsi.c: At top level: Warning: /linux/drivers/scsi/ibmvscsi/ibmvscsi.c:212:13: warning: 'ibmvscsi_task' defined but not used [-Wunused-function] static void ibmvscsi_task(void *data) ^ Warning: cc1: warning: unrecognized command line option '-Wno-shift-negative-value' Warning: cc1: warning: unrecognized command line option '-Wno-stringop-overflow' cc1: some warnings being treated as errors make[6]: *** [drivers/scsi/ibmvscsi/ibmvscsi.o] Error 1 make[5]: *** [drivers/scsi/ibmvscsi] Error 2 make[4]: *** [drivers/scsi] Error 2 make[3]: *** [drivers] Error 2 make[3]: *** Waiting for unfinished jobs Full log here: https://github.com/linuxppc/linux-snowpatch/actions/runs/8930174372/job/24529645923 Cross compile instructions if you're keen: https://github.com/linuxppc/wiki/wiki/Building-powerpc-kernels cheers
Re: [PATCH v15 00/16] Add audio support in v4l2 framework
On Thu, May 02, 2024 at 10:26:43AM +0100, Mauro Carvalho Chehab wrote: > Mauro Carvalho Chehab escreveu: > > There are still time control associated with it, as audio and video > > needs to be in sync. This is done by controlling the buffers size > > and could be fine-tuned by checking when the buffer transfer is done. ... > Just complementing: on media, we do this per video buffer (or > per half video buffer). A typical use case on cameras is to have > buffers transferred 30 times per second, if the video was streamed > at 30 frames per second. IIRC some big use case for this hardware was transcoding so there was a desire to just go at whatever rate the hardware could support as there is no interactive user consuming the output as it is generated. > I would assume that, on an audio/video stream, the audio data > transfer will be programmed to also happen on a regular interval. With audio the API is very much "wake userspace every Xms". signature.asc Description: PGP signature
[PATCH] power: Remove arch specific module bug stuff
From: "Dr. David Alan Gilbert"
The last function to reference module_bug_list went in 2008's
commit b9754568ef17 ("powerpc: Remove dead module_find_bug code")
but I don't think that was called since 2006's
commit 73c9ceab40b1 ("[POWERPC] Generic BUG for powerpc")
Now that the list has gone, I think we can also clean up the bug
entries in mod_arch_specific.
Lightly boot tested.
Signed-off-by: Dr. David Alan Gilbert
---
arch/powerpc/include/asm/module.h | 5 -
arch/powerpc/kernel/module.c | 2 --
2 files changed, 7 deletions(-)
diff --git a/arch/powerpc/include/asm/module.h
b/arch/powerpc/include/asm/module.h
index a8e2e8339fb7f..300c777cc3075 100644
--- a/arch/powerpc/include/asm/module.h
+++ b/arch/powerpc/include/asm/module.h
@@ -48,11 +48,6 @@ struct mod_arch_specific {
unsigned long tramp;
unsigned long tramp_regs;
#endif
-
- /* List of BUG addresses, source line numbers and filenames */
- struct list_head bug_list;
- struct bug_entry *bug_table;
- unsigned int num_bugs;
};
/*
diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c
index f6d6ae0a16923..8989e069e3aae 100644
--- a/arch/powerpc/kernel/module.c
+++ b/arch/powerpc/kernel/module.c
@@ -17,8 +17,6 @@
#include
#include
-static LIST_HEAD(module_bug_list);
-
static const Elf_Shdr *find_section(const Elf_Ehdr *hdr,
const Elf_Shdr *sechdrs,
const char *name)
--
2.44.0
Re: [PATCH v7 00/16] mm: jit/text allocator
On Thu, May 02, 2024 at 04:07:05PM -0700, Luis Chamberlain wrote:
> On Thu, May 02, 2024 at 11:50:36PM +0100, Liviu Dudau wrote:
> > On Mon, Apr 29, 2024 at 09:29:20AM -0700, Luis Chamberlain wrote:
> > > On Mon, Apr 29, 2024 at 03:16:04PM +0300, Mike Rapoport wrote:
> > > > From: "Mike Rapoport (IBM)"
> > > >
> > > > Hi,
> > > >
> > > > The patches are also available in git:
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux.git/log/?h=execmem/v7
> > > >
> > > > v7 changes:
> > > > * define MODULE_{VADDR,END} for riscv32 to fix the build and avoid
> > > > #ifdefs in a function body
> > > > * add Acks, thanks everybody
> > >
> > > Thanks, I've pushed this to modules-next for further exposure / testing.
> > > Given the status of testing so far with prior revisions, in that only a
> > > few issues were found and that those were fixed, and the status of
> > > reviews, this just might be ripe for v6.10.
> >
> > Looks like there is still some work needed. I've picked up next-20240501
> > and on arch/mips with CONFIG_MODULE_COMPRESS_XZ=y and
> > CONFIG_MODULE_DECOMPRESS=y
> > I fail to load any module:
> >
> > # modprobe rfkill
> > [11746.539090] Invalid ELF header magic: != ELF
> > [11746.587149] execmem: unable to allocate memory
> > modprobe: can't load module rfkill (kernel/net/rfkill/rfkill.ko.xz): Out of
> > memory
> >
> > The (hopefully) relevant parts of my .config:
>
> Thanks for the report! Any chance we can get you to try a bisection? I
> think it should take 2-3 test boots. To help reduce scope you try
> modules-next:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=modules-next
>
> Then can you check by resetting your tree to commmit 3fbe6c2f820a76 (mm:
> introduce execmem_alloc() and execmem_free()"). I suspect that should
> boot, so your bad commit would be the tip 3c2c250cb3a5fbb ("bpf: remove
> CONFIG_BPF_JIT dependency on CONFIG_MODULES of").
>
> That gives us only a few commits to bisect:
>
> git log --oneline 3fbe6c2f820a76bc36d5546bda85832f57c8fce2..
> 3c2c250cb3a5 (HEAD -> modules-next, korg/modules-next) bpf: remove
> CONFIG_BPF_JIT dependency on CONFIG_MODULES of
> 11e8e65cce5c kprobes: remove dependency on CONFIG_MODULES
> e10cbc38697b powerpc: use CONFIG_EXECMEM instead of CONFIG_MODULES where
> appropriate
> 4da3d38f24c5 x86/ftrace: enable dynamic ftrace without CONFIG_MODULES
> 13ae3d74ee70 arch: make execmem setup available regardless of CONFIG_MODULES
> 460bbbc70a47 powerpc: extend execmem_params for kprobes allocations
> e1a14069b5b4 arm64: extend execmem_info for generated code allocations
> 971e181c6585 riscv: extend execmem_params for generated code allocations
> 0fa276f26721 mm/execmem, arch: convert remaining overrides of module_alloc to
> execmem
> 022cef244287 mm/execmem, arch: convert simple overrides of module_alloc to
> execmem
>
> With 2-3 boots we should be to tell which is the bad commit.
Looks like 0fa276f26721 is the first bad commit.
$ git bisect log
# bad: [3c2c250cb3a5fbbccc4a4ff4c9354c54af91f02c] bpf: remove CONFIG_BPF_JIT
dependency on CONFIG_MODULES of
# good: [3fbe6c2f820a76bc36d5546bda85832f57c8fce2] mm: introduce
execmem_alloc() and execmem_free()
git bisect start '3c2c250cb3a5' '3fbe6c2f820a76'
# bad: [460bbbc70a47e929b1936ca68979f3b79f168fc6] powerpc: extend
execmem_params for kprobes allocations
git bisect bad 460bbbc70a47e929b1936ca68979f3b79f168fc6
# bad: [0fa276f26721e0ffc2ae9c7cf67dcc005b43c67e] mm/execmem, arch: convert
remaining overrides of module_alloc to execmem
git bisect bad 0fa276f26721e0ffc2ae9c7cf67dcc005b43c67e
# good: [022cef2442870db738a366d3b7a636040c081859] mm/execmem, arch: convert
simple overrides of module_alloc to execmem
git bisect good 022cef2442870db738a366d3b7a636040c081859
# first bad commit: [0fa276f26721e0ffc2ae9c7cf67dcc005b43c67e] mm/execmem,
arch: convert remaining overrides of module_alloc to execmem
Maybe MIPS also needs a ARCH_WANTS_EXECMEM_LATE?
Best regards,
Liviu
>
> Luis
>
--
Everyone who uses computers frequently has had, from time to time,
a mad desire to attack the precocious abacus with an axe.
-- John D. Clark, Ignition!
Re: [PATCH v7 00/16] mm: jit/text allocator
On Thu, May 02, 2024 at 11:50:36PM +0100, Liviu Dudau wrote:
> On Mon, Apr 29, 2024 at 09:29:20AM -0700, Luis Chamberlain wrote:
> > On Mon, Apr 29, 2024 at 03:16:04PM +0300, Mike Rapoport wrote:
> > > From: "Mike Rapoport (IBM)"
> > >
> > > Hi,
> > >
> > > The patches are also available in git:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux.git/log/?h=execmem/v7
> > >
> > > v7 changes:
> > > * define MODULE_{VADDR,END} for riscv32 to fix the build and avoid
> > > #ifdefs in a function body
> > > * add Acks, thanks everybody
> >
> > Thanks, I've pushed this to modules-next for further exposure / testing.
> > Given the status of testing so far with prior revisions, in that only a
> > few issues were found and that those were fixed, and the status of
> > reviews, this just might be ripe for v6.10.
>
> Looks like there is still some work needed. I've picked up next-20240501
> and on arch/mips with CONFIG_MODULE_COMPRESS_XZ=y and
> CONFIG_MODULE_DECOMPRESS=y
> I fail to load any module:
>
> # modprobe rfkill
> [11746.539090] Invalid ELF header magic: != ELF
> [11746.587149] execmem: unable to allocate memory
> modprobe: can't load module rfkill (kernel/net/rfkill/rfkill.ko.xz): Out of
> memory
>
> The (hopefully) relevant parts of my .config:
Thanks for the report! Any chance we can get you to try a bisection? I
think it should take 2-3 test boots. To help reduce scope you try modules-next:
https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux.git/log/?h=modules-next
Then can you check by resetting your tree to commmit 3fbe6c2f820a76 (mm:
introduce execmem_alloc() and execmem_free()"). I suspect that should
boot, so your bad commit would be the tip 3c2c250cb3a5fbb ("bpf: remove
CONFIG_BPF_JIT dependency on CONFIG_MODULES of").
That gives us only a few commits to bisect:
git log --oneline 3fbe6c2f820a76bc36d5546bda85832f57c8fce2..
3c2c250cb3a5 (HEAD -> modules-next, korg/modules-next) bpf: remove
CONFIG_BPF_JIT dependency on CONFIG_MODULES of
11e8e65cce5c kprobes: remove dependency on CONFIG_MODULES
e10cbc38697b powerpc: use CONFIG_EXECMEM instead of CONFIG_MODULES where
appropriate
4da3d38f24c5 x86/ftrace: enable dynamic ftrace without CONFIG_MODULES
13ae3d74ee70 arch: make execmem setup available regardless of CONFIG_MODULES
460bbbc70a47 powerpc: extend execmem_params for kprobes allocations
e1a14069b5b4 arm64: extend execmem_info for generated code allocations
971e181c6585 riscv: extend execmem_params for generated code allocations
0fa276f26721 mm/execmem, arch: convert remaining overrides of module_alloc to
execmem
022cef244287 mm/execmem, arch: convert simple overrides of module_alloc to
execmem
With 2-3 boots we should be to tell which is the bad commit.
Luis
Re: [PATCH v7 00/16] mm: jit/text allocator
On Mon, Apr 29, 2024 at 09:29:20AM -0700, Luis Chamberlain wrote:
> On Mon, Apr 29, 2024 at 03:16:04PM +0300, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > Hi,
> >
> > The patches are also available in git:
> > https://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux.git/log/?h=execmem/v7
> >
> > v7 changes:
> > * define MODULE_{VADDR,END} for riscv32 to fix the build and avoid
> > #ifdefs in a function body
> > * add Acks, thanks everybody
>
> Thanks, I've pushed this to modules-next for further exposure / testing.
> Given the status of testing so far with prior revisions, in that only a
> few issues were found and that those were fixed, and the status of
> reviews, this just might be ripe for v6.10.
Looks like there is still some work needed. I've picked up next-20240501
and on arch/mips with CONFIG_MODULE_COMPRESS_XZ=y and CONFIG_MODULE_DECOMPRESS=y
I fail to load any module:
# modprobe rfkill
[11746.539090] Invalid ELF header magic: != ELF
[11746.587149] execmem: unable to allocate memory
modprobe: can't load module rfkill (kernel/net/rfkill/rfkill.ko.xz): Out of
memory
The (hopefully) relevant parts of my .config:
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_MIPS=y
CONFIG_RALINK=y
CONFIG_SOC_MT7621=y
CONFIG_EXECMEM=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_MODULES=y
# CONFIG_MODULE_DEBUG is not set
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODULE_UNLOAD_TAINT_TRACKING is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_MODULE_SIG is not set
# CONFIG_MODULE_COMPRESS_NONE is not set
# CONFIG_MODULE_COMPRESS_GZIP is not set
CONFIG_MODULE_COMPRESS_XZ=y
# CONFIG_MODULE_COMPRESS_ZSTD is not set
CONFIG_MODULE_DECOMPRESS=y
# CONFIG_MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS is not set
CONFIG_MODULES_TREE_LOOKUP=y
Best regards,
Liviu
>
> Luis
>
--
Everyone who uses computers frequently has had, from time to time,
a mad desire to attack the precocious abacus with an axe.
-- John D. Clark, Ignition!
[PATCH] [RFC] scsi: Convert from tasklet to BH workqueue
The only generic interface to execute asynchronously in the BH context is
tasklet; however, it's marked deprecated and has some design flaws. To
replace tasklets, BH workqueue support was recently added. A BH workqueue
behaves similarly to regular workqueues except that the queued work items
are executed in the BH context.
This patch converts drivers/scsi/* from tasklet to BH workqueue.
Based on the work done by Tejun Heo
Branch: https://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-6.10
Signed-off-by: Allen Pais
---
drivers/scsi/aic7xxx/aic7xxx_osm.c | 2 +-
drivers/scsi/aic94xx/aic94xx_hwi.c | 14 ++--
drivers/scsi/aic94xx/aic94xx_hwi.h | 5 +-
drivers/scsi/aic94xx/aic94xx_scb.c | 36 +-
drivers/scsi/aic94xx/aic94xx_task.c | 14 ++--
drivers/scsi/aic94xx/aic94xx_tmf.c | 34 -
drivers/scsi/esas2r/esas2r.h| 12 ++--
drivers/scsi/esas2r/esas2r_init.c | 14 ++--
drivers/scsi/esas2r/esas2r_int.c| 18 ++---
drivers/scsi/esas2r/esas2r_io.c | 2 +-
drivers/scsi/esas2r/esas2r_main.c | 16 ++---
drivers/scsi/ibmvscsi/ibmvfc.c | 16 ++---
drivers/scsi/ibmvscsi/ibmvfc.h | 3 +-
drivers/scsi/ibmvscsi/ibmvscsi.c| 16 ++---
drivers/scsi/ibmvscsi/ibmvscsi.h| 3 +-
drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c| 15 ++--
drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.h| 3 +-
drivers/scsi/isci/host.c| 12 ++--
drivers/scsi/isci/host.h| 8 +--
drivers/scsi/isci/init.c| 4 +-
drivers/scsi/megaraid/mega_common.h | 5 +-
drivers/scsi/megaraid/megaraid_mbox.c | 21 +++---
drivers/scsi/megaraid/megaraid_sas.h| 4 +-
drivers/scsi/megaraid/megaraid_sas_base.c | 32 -
drivers/scsi/megaraid/megaraid_sas_fusion.c | 16 ++---
drivers/scsi/mvsas/mv_init.c| 27 ---
drivers/scsi/mvsas/mv_sas.h | 9 +--
drivers/scsi/pm8001/pm8001_init.c | 55 ---
drivers/scsi/pm8001/pm8001_sas.h| 2 +-
drivers/scsi/pmcraid.c | 78 +++--
drivers/scsi/pmcraid.h | 5 +-
31 files changed, 251 insertions(+), 250 deletions(-)
diff --git a/drivers/scsi/aic7xxx/aic7xxx_osm.c
b/drivers/scsi/aic7xxx/aic7xxx_osm.c
index b0c4f2345321..42f76391f589 100644
--- a/drivers/scsi/aic7xxx/aic7xxx_osm.c
+++ b/drivers/scsi/aic7xxx/aic7xxx_osm.c
@@ -797,7 +797,7 @@ struct scsi_host_template aic7xxx_driver_template = {
.target_destroy = ahc_linux_target_destroy,
};
-/ Tasklet Handler
*/
+/ Work Handler */
static inline unsigned int ahc_build_scsiid(struct ahc_softc *ahc,
diff --git a/drivers/scsi/aic94xx/aic94xx_hwi.c
b/drivers/scsi/aic94xx/aic94xx_hwi.c
index 9dda296c0152..b08f0231e562 100644
--- a/drivers/scsi/aic94xx/aic94xx_hwi.c
+++ b/drivers/scsi/aic94xx/aic94xx_hwi.c
@@ -246,7 +246,7 @@ static void asd_get_max_scb_ddb(struct asd_ha_struct
*asd_ha)
/* -- Done List initialization -- */
-static void asd_dl_tasklet_handler(unsigned long);
+static void asd_dl_work_handler(struct work_struct *);
static int asd_init_dl(struct asd_ha_struct *asd_ha)
{
@@ -259,8 +259,7 @@ static int asd_init_dl(struct asd_ha_struct *asd_ha)
asd_ha->seq.dl = asd_ha->seq.actual_dl->vaddr;
asd_ha->seq.dl_toggle = ASD_DEF_DL_TOGGLE;
asd_ha->seq.dl_next = 0;
- tasklet_init(_ha->seq.dl_tasklet, asd_dl_tasklet_handler,
-(unsigned long) asd_ha);
+ INIT_WORK(_ha->seq.dl_work, asd_dl_work_handler);
return 0;
}
@@ -709,10 +708,9 @@ static void asd_chip_reset(struct asd_ha_struct *asd_ha)
/* -- Done List Routines -- */
-static void asd_dl_tasklet_handler(unsigned long data)
+static void asd_dl_work_handler(struct work_struct *t)
{
- struct asd_ha_struct *asd_ha = (struct asd_ha_struct *) data;
- struct asd_seq_data *seq = _ha->seq;
+ struct asd_seq_data *seq = from_work(seq, t, dl_work);
unsigned long flags;
while (1) {
@@ -739,7 +737,7 @@ static void asd_dl_tasklet_handler(unsigned long data)
seq->pending--;
spin_unlock_irqrestore(>pend_q_lock, flags);
out:
- ascb->tasklet_complete(ascb, dl);
+ ascb->work_complete(ascb, dl);
next_1:
seq->dl_next = (seq->dl_next + 1) & (ASD_DL_SIZE-1);
@@ -756,7 +754,7 @@ static void asd_dl_tasklet_handler(unsigned long data)
*/
static void asd_process_donelist_isr(struct asd_ha_struct *asd_ha)
{
- tasklet_schedule(_ha->seq.dl_tasklet);
+ queue_work(system_bh_wq, _ha->seq.dl_work);
}
/**
diff --git a/drivers/scsi/aic94xx/aic94xx_hwi.h
[PATCH 0/1] Convert tasklets to bottom half workqueues
I am submitting this patch which converts instances of tasklets
in drivers/scsi/* to bottom half workqueues. I appreciate your
feedback and suggestion on the changes.
Note: The patch is only compile tested.
In the patcheset, you will notice *FIXME* in two places:
1. pm8001/pm8001_init.c @ pm8001_work(struct work_struct *t)
2. pmcraid.c @ pmcraid_work_function(struct work_struct *t)
The current implementation limits context-aware processing
within work functions due to the lack of a mechanism to identify
the source work_struct in the array. The proposed solution wraps
each work_struct with a struct work_wrapper, adding crucial context
like the array index and a reference to the parent data structure.
Ex:
#define SOME_CONSTANT 10
struct xxx_data {
.
struct work_struct work[SOME_CONSTANT]:
.
};
The xxx_data module currently uses an array of work_structs
for scheduling work, but it lacks the ability to identify which
array element is associated with a specific invocation of the work
function. This limitation prevents the execution of context-specific
actions based on the source of the work request.
The proposed solution is to introduce a struct work_wrapper that
encapsulates each work_struct along with additional metadata,
including an index and a pointer to the parent xxx_data structure.
This enhancement allows the work function to access necessary
context information.
Changes:
1. Definition of struct work_wrapper:
struct work_wrapper {
struct work_struct work;
struct xxx_data *data;
int index;
};
struct xxx_data {
struct work_wrapper work[SOME_CONSTANT];
};
During initialization:
for (int i = 0; i < SOME_CONSTANT; i++) {
p->work[i].data = p;
p->work[i].index = i;
INIT_WORK(>work[i].work, work_func);
}
And it's usage in the handler:
void work_func(struct work_struct *t)
{
struct work_wrapper *wrapper = from_work(wrapper, t, work);
struct xxx_data *a = wrapper->data;
int index = wrapper->index;
}
If the above is solution is acceptable, I can have the same
incorporated in version 2.
Thanks.
Allen Pais (1):
[RFC] scsi: Convert from tasklet to BH workqueue
drivers/scsi/aic7xxx/aic7xxx_osm.c | 2 +-
drivers/scsi/aic94xx/aic94xx_hwi.c | 14 ++--
drivers/scsi/aic94xx/aic94xx_hwi.h | 5 +-
drivers/scsi/aic94xx/aic94xx_scb.c | 36 +-
drivers/scsi/aic94xx/aic94xx_task.c | 14 ++--
drivers/scsi/aic94xx/aic94xx_tmf.c | 34 +-
drivers/scsi/esas2r/esas2r.h| 12 ++--
drivers/scsi/esas2r/esas2r_init.c | 14 ++--
drivers/scsi/esas2r/esas2r_int.c| 18 ++---
drivers/scsi/esas2r/esas2r_io.c | 2 +-
drivers/scsi/esas2r/esas2r_main.c | 16 ++---
drivers/scsi/ibmvscsi/ibmvfc.c | 16 ++---
drivers/scsi/ibmvscsi/ibmvfc.h | 3 +-
drivers/scsi/ibmvscsi/ibmvscsi.c| 16 ++---
drivers/scsi/ibmvscsi/ibmvscsi.h| 3 +-
drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c| 15 ++---
drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.h| 3 +-
drivers/scsi/isci/host.c| 12 ++--
drivers/scsi/isci/host.h| 8 +--
drivers/scsi/isci/init.c| 4 +-
drivers/scsi/megaraid/mega_common.h | 5 +-
drivers/scsi/megaraid/megaraid_mbox.c | 21 +++---
drivers/scsi/megaraid/megaraid_sas.h| 4 +-
drivers/scsi/megaraid/megaraid_sas_base.c | 32 +
drivers/scsi/megaraid/megaraid_sas_fusion.c | 16 ++---
drivers/scsi/mvsas/mv_init.c| 27
drivers/scsi/mvsas/mv_sas.h | 9 +--
drivers/scsi/pm8001/pm8001_init.c | 57
drivers/scsi/pm8001/pm8001_sas.h| 2 +-
drivers/scsi/pmcraid.c | 75 ++---
drivers/scsi/pmcraid.h | 5 +-
31 files changed, 249 insertions(+), 251 deletions(-)
--
2.17.1
Re: [PATCH 1/3] powerpc/mm: Align memory_limit value specified using mem= kernel parameter
On Wed, Apr 17, 2024 at 10:36 AM Joel Savitz wrote: > > Acked-by: Joel Savitz > Hi, What is the status of this? This patch fixes a bug where a powerpc machine hangs at boot when passed an unaligned value in the mem= kernel parameter. Best, Joel Savitz
[PATCH] powerpc/crash: remove unnecessary NULL check before kvfree()
Fix the following coccicheck build warning: arch/powerpc/kexec/crash.c:488:2-8: WARNING: NULL check before some freeing functions is not needed. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202404261048.skfv5ddb-...@intel.com/ Cc: Michael Ellerman Cc: Stephen Rothwell Signed-off-by: Sourabh Jain --- arch/powerpc/kexec/crash.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/powerpc/kexec/crash.c b/arch/powerpc/kexec/crash.c index 21b193e938a3..9ac3266e4965 100644 --- a/arch/powerpc/kexec/crash.c +++ b/arch/powerpc/kexec/crash.c @@ -484,8 +484,7 @@ static void update_crash_elfcorehdr(struct kimage *image, struct memory_notify * } out: kvfree(cmem); - if (elfbuf) - kvfree(elfbuf); + kvfree(elfbuf); } /** -- 2.44.0
[PATCH v4 1/2] powerpc64/bpf: fix tail calls for PCREL addressing
With PCREL addressing, there is no kernel TOC. So, it is not setup in
prologue when PCREL addressing is used. But the number of instructions
to skip on a tail call was not adjusted accordingly. That resulted in
not so obvious failures while using tailcalls. 'tailcalls' selftest
crashed the system with the below call trace:
bpf_test_run+0xe8/0x3cc (unreliable)
bpf_prog_test_run_skb+0x348/0x778
__sys_bpf+0xb04/0x2b00
sys_bpf+0x28/0x38
system_call_exception+0x168/0x340
system_call_vectored_common+0x15c/0x2ec
Also, as bpf programs are always module addresses and a bpf helper in
general is a core kernel text address, using PC relative addressing
often fails with "out of range of pcrel address" error. Switch to
using kernel base for relative addressing to handle this better.
Fixes: 7e3a68be42e1 ("powerpc/64: vmlinux support building with PCREL
addresing")
Cc: sta...@vger.kernel.org
Signed-off-by: Hari Bathini
---
* Changes in v4:
- Fix out of range errors by switching to kernelbase instead of PC
for relative addressing.
* Changes in v3:
- New patch to fix tailcall issues with PCREL addressing.
arch/powerpc/net/bpf_jit_comp64.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/net/bpf_jit_comp64.c
b/arch/powerpc/net/bpf_jit_comp64.c
index 79f23974a320..4de08e35e284 100644
--- a/arch/powerpc/net/bpf_jit_comp64.c
+++ b/arch/powerpc/net/bpf_jit_comp64.c
@@ -202,7 +202,8 @@ void bpf_jit_build_epilogue(u32 *image, struct
codegen_context *ctx)
EMIT(PPC_RAW_BLR());
}
-static int bpf_jit_emit_func_call_hlp(u32 *image, struct codegen_context *ctx,
u64 func)
+static int
+bpf_jit_emit_func_call_hlp(u32 *image, u32 *fimage, struct codegen_context
*ctx, u64 func)
{
unsigned long func_addr = func ? ppc_function_entry((void *)func) : 0;
long reladdr;
@@ -211,19 +212,20 @@ static int bpf_jit_emit_func_call_hlp(u32 *image, struct
codegen_context *ctx, u
return -EINVAL;
if (IS_ENABLED(CONFIG_PPC_KERNEL_PCREL)) {
- reladdr = func_addr - CTX_NIA(ctx);
+ reladdr = func_addr - local_paca->kernelbase;
if (reladdr >= (long)SZ_8G || reladdr < -(long)SZ_8G) {
- pr_err("eBPF: address of %ps out of range of pcrel
address.\n",
- (void *)func);
+ pr_err("eBPF: address of %ps out of range of 34-bit
relative address.\n",
+ (void *)func);
return -ERANGE;
}
- /* pla r12,addr */
- EMIT(PPC_PREFIX_MLS | __PPC_PRFX_R(1) | IMM_H18(reladdr));
- EMIT(PPC_INST_PADDI | ___PPC_RT(_R12) | IMM_L(reladdr));
- EMIT(PPC_RAW_MTCTR(_R12));
- EMIT(PPC_RAW_BCTR());
-
+ EMIT(PPC_RAW_LD(_R12, _R13, offsetof(struct paca_struct,
kernelbase)));
+ /* Align for subsequent prefix instruction */
+ if (!IS_ALIGNED((unsigned long)fimage + CTX_NIA(ctx), 8))
+ EMIT(PPC_RAW_NOP());
+ /* paddi r12,r12,addr */
+ EMIT(PPC_PREFIX_MLS | __PPC_PRFX_R(0) | IMM_H18(reladdr));
+ EMIT(PPC_INST_PADDI | ___PPC_RT(_R12) | ___PPC_RA(_R12) |
IMM_L(reladdr));
} else {
reladdr = func_addr - kernel_toc_addr();
if (reladdr > 0x7FFF || reladdr < -(0x8000L)) {
@@ -233,9 +235,9 @@ static int bpf_jit_emit_func_call_hlp(u32 *image, struct
codegen_context *ctx, u
EMIT(PPC_RAW_ADDIS(_R12, _R2, PPC_HA(reladdr)));
EMIT(PPC_RAW_ADDI(_R12, _R12, PPC_LO(reladdr)));
- EMIT(PPC_RAW_MTCTR(_R12));
- EMIT(PPC_RAW_BCTRL());
}
+ EMIT(PPC_RAW_MTCTR(_R12));
+ EMIT(PPC_RAW_BCTRL());
return 0;
}
@@ -285,7 +287,7 @@ static int bpf_jit_emit_tail_call(u32 *image, struct
codegen_context *ctx, u32 o
int b2p_index = bpf_to_ppc(BPF_REG_3);
int bpf_tailcall_prologue_size = 8;
- if (IS_ENABLED(CONFIG_PPC64_ELF_ABI_V2))
+ if (!IS_ENABLED(CONFIG_PPC_KERNEL_PCREL) &&
IS_ENABLED(CONFIG_PPC64_ELF_ABI_V2))
bpf_tailcall_prologue_size += 4; /* skip past the toc load */
/*
@@ -993,7 +995,7 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image, u32
*fimage, struct code
return ret;
if (func_addr_fixed)
- ret = bpf_jit_emit_func_call_hlp(image, ctx,
func_addr);
+ ret = bpf_jit_emit_func_call_hlp(image, fimage,
ctx, func_addr);
else
ret = bpf_jit_emit_func_call_rel(image, fimage,
ctx, func_addr);
--
2.44.0
[PATCH v4 2/2] powerpc/bpf: enable kfunc call
Currently, bpf jit code on powerpc assumes all the bpf functions and
helpers to be part of core kernel text. This is false for kfunc case,
as function addresses may not be part of core kernel text area. So,
add support for addresses that are not within core kernel text area
too, to enable kfunc support. Emit instructions based on whether the
function address is within core kernel text address or not, to retain
optimized instruction sequence where possible.
In case of PCREL, as a bpf function that is not within core kernel
text area is likely to go out of range with relative addressing on
kernel base, use PC relative addressing. If that goes out of range,
load the full address with PPC_LI64().
With addresses that are not within core kernel text area supported,
override bpf_jit_supports_kfunc_call() to enable kfunc support. Also,
override bpf_jit_supports_far_kfunc_call() to enable 64-bit pointers,
as an address offset can be more than 32-bit long on PPC64.
Signed-off-by: Hari Bathini
---
* Changes in v4:
- Use either kernelbase or PC for relative addressing. Also, fallback
to PPC_LI64(), if both are out of range.
- Update r2 with kernel TOC for elfv1 too as elfv1 also uses the
optimization sequence, that expects r2 to be kernel TOC, when
function address is within core kernel text.
* Changes in v3:
- Retained optimized instruction sequence when function address is
a core kernel address as suggested by Naveen.
- Used unoptimized instruction sequence for PCREL addressing to
avoid out of range errors for core kernel function addresses.
- Folded patch that adds support for kfunc calls with patch that
enables/advertises this support as suggested by Naveen.
arch/powerpc/net/bpf_jit_comp.c | 10 +
arch/powerpc/net/bpf_jit_comp64.c | 61 ++-
2 files changed, 61 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index 0f9a21783329..984655419da5 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -359,3 +359,13 @@ void bpf_jit_free(struct bpf_prog *fp)
bpf_prog_unlock_free(fp);
}
+
+bool bpf_jit_supports_kfunc_call(void)
+{
+ return true;
+}
+
+bool bpf_jit_supports_far_kfunc_call(void)
+{
+ return IS_ENABLED(CONFIG_PPC64);
+}
diff --git a/arch/powerpc/net/bpf_jit_comp64.c
b/arch/powerpc/net/bpf_jit_comp64.c
index 4de08e35e284..8afc14a4a125 100644
--- a/arch/powerpc/net/bpf_jit_comp64.c
+++ b/arch/powerpc/net/bpf_jit_comp64.c
@@ -208,17 +208,13 @@ bpf_jit_emit_func_call_hlp(u32 *image, u32 *fimage,
struct codegen_context *ctx,
unsigned long func_addr = func ? ppc_function_entry((void *)func) : 0;
long reladdr;
- if (WARN_ON_ONCE(!core_kernel_text(func_addr)))
+ if (WARN_ON_ONCE(!kernel_text_address(func_addr)))
return -EINVAL;
- if (IS_ENABLED(CONFIG_PPC_KERNEL_PCREL)) {
- reladdr = func_addr - local_paca->kernelbase;
+#ifdef CONFIG_PPC_KERNEL_PCREL
+ reladdr = func_addr - local_paca->kernelbase;
- if (reladdr >= (long)SZ_8G || reladdr < -(long)SZ_8G) {
- pr_err("eBPF: address of %ps out of range of 34-bit
relative address.\n",
- (void *)func);
- return -ERANGE;
- }
+ if (reladdr < (long)SZ_8G && reladdr >= -(long)SZ_8G) {
EMIT(PPC_RAW_LD(_R12, _R13, offsetof(struct paca_struct,
kernelbase)));
/* Align for subsequent prefix instruction */
if (!IS_ALIGNED((unsigned long)fimage + CTX_NIA(ctx), 8))
@@ -227,6 +223,26 @@ bpf_jit_emit_func_call_hlp(u32 *image, u32 *fimage, struct
codegen_context *ctx,
EMIT(PPC_PREFIX_MLS | __PPC_PRFX_R(0) | IMM_H18(reladdr));
EMIT(PPC_INST_PADDI | ___PPC_RT(_R12) | ___PPC_RA(_R12) |
IMM_L(reladdr));
} else {
+ unsigned long pc = (unsigned long)fimage + CTX_NIA(ctx);
+ bool alignment_needed = !IS_ALIGNED(pc, 8);
+
+ reladdr = func_addr - (alignment_needed ? pc + 4 : pc);
+
+ if (reladdr < (long)SZ_8G && reladdr >= -(long)SZ_8G) {
+ if (alignment_needed)
+ EMIT(PPC_RAW_NOP());
+ /* pla r12,addr */
+ EMIT(PPC_PREFIX_MLS | __PPC_PRFX_R(1) |
IMM_H18(reladdr));
+ EMIT(PPC_INST_PADDI | ___PPC_RT(_R12) | IMM_L(reladdr));
+ } else {
+ /* We can clobber r12 */
+ PPC_LI64(_R12, func);
+ }
+ }
+ EMIT(PPC_RAW_MTCTR(_R12));
+ EMIT(PPC_RAW_BCTRL());
+#else
+ if (core_kernel_text(func_addr)) {
reladdr = func_addr - kernel_toc_addr();
if (reladdr > 0x7FFF || reladdr < -(0x8000L)) {
pr_err("eBPF: address of %ps out
Re: [PATCH v15 00/16] Add audio support in v4l2 framework
Em Thu, 2 May 2024 09:59:56 +0100 Mauro Carvalho Chehab escreveu: > Em Thu, 02 May 2024 09:46:14 +0200 > Takashi Iwai escreveu: > > > On Wed, 01 May 2024 03:56:15 +0200, > > Mark Brown wrote: > > > > > > On Tue, Apr 30, 2024 at 05:27:52PM +0100, Mauro Carvalho Chehab wrote: > > > > Mark Brown escreveu: > > > > > On Tue, Apr 30, 2024 at 10:21:12AM +0200, Sebastian Fricke wrote: > > > > > > > > The discussion around this originally was that all the audio APIs are > > > > > very much centered around real time operations rather than completely > > > > > > > > > > > > The media subsystem is also centered around real time. Without real > > > > time, you can't have a decent video conference system. Having > > > > mem2mem transfers actually help reducing real time delays, as it > > > > avoids extra latency due to CPU congestion and/or data transfers > > > > from/to userspace. > > > > > > Real time means strongly tied to wall clock times rather than fast - the > > > issue was that all the ALSA APIs are based around pushing data through > > > the system based on a clock. > > > > > > > > That doesn't sound like an immediate solution to maintainer overload > > > > > issues... if something like this is going to happen the DRM solution > > > > > does seem more general but I'm not sure the amount of stop energy is > > > > > proportionate. > > > > > > > I don't think maintainer overload is the issue here. The main > > > > point is to avoid a fork at the audio uAPI, plus the burden > > > > of re-inventing the wheel with new codes for audio formats, > > > > new documentation for them, etc. > > > > > > I thought that discussion had been had already at one of the earlier > > > versions? TBH I've not really been paying attention to this since the > > > very early versions where I raised some similar "why is this in media" > > > points and I thought everyone had decided that this did actually make > > > sense. > > > > Yeah, it was discussed in v1 and v2 threads, e.g. > > > > https://patchwork.kernel.org/project/linux-media/cover/1690265540-25999-1-git-send-email-shengjiu.w...@nxp.com/#25485573 > > > > My argument at that time was how the operation would be, and the point > > was that it'd be a "batch-like" operation via M2M without any timing > > control. It'd be a very special usage for for ALSA, and if any, it'd > > be hwdep -- that is a very hardware-specific API implementation -- or > > try compress-offload API, which looks dubious. > > > > OTOH, the argument was that there is already a framework for M2M in > > media API and that also fits for the batch-like operation, too. So > > was the thread evolved until now. > > M2M transfers are not a hardware-specific API, and such kind of > transfers is not new either. Old media devices like bttv have > internally a way to do PCI2PCI transfers, allowing media streams > to be transferred directly without utilizing CPU. The media driver > supports it for video, as this made a huge difference of performance > back then. > > On embedded world, this is a pretty common scenario: different media > IP blocks can communicate with each other directly via memory. This > can happen for video capture, video display and audio. > > With M2M, most of the control is offloaded to the hardware. > > There are still time control associated with it, as audio and video > needs to be in sync. This is done by controlling the buffers size > and could be fine-tuned by checking when the buffer transfer is done. > > On media, M2M buffer transfers are started via VIDIOC_QBUF, > which is a request to do a frame transfer. A similar ioctl > (VIDIOC_DQBUF) is used to monitor when the hardware finishes > transfering the buffer. On other words, the CPU is responsible > for time control. Just complementing: on media, we do this per video buffer (or per half video buffer). A typical use case on cameras is to have buffers transferred 30 times per second, if the video was streamed at 30 frames per second. I would assume that, on an audio/video stream, the audio data transfer will be programmed to also happen on a regular interval. So, if the video stream is programmed to a 30 frames per second rate, I would assume that the associated audio stream will also be programmed to be grouped into 30 data transfers per second. On such scenario, if the audio is sampled at 48 kHZ, it means that: 1) each M2M transfer commanded by CPU will copy 1600 samples; 2) the time between each sample will remain 1/48000; 3) a notification event telling that 1600 samples were transferred will be generated when the last sample happens; 4) CPU will do time control by looking at the notification events. > On other words, this is still real time. The main difference > from a "sync" transfer is that the CPU doesn't need to copy data > from/to different devices, as such operation is offloaded to the > hardware. > > Regards, > Mauro
Re: [PATCH v15 00/16] Add audio support in v4l2 framework
Em Thu, 02 May 2024 09:46:14 +0200 Takashi Iwai escreveu: > On Wed, 01 May 2024 03:56:15 +0200, > Mark Brown wrote: > > > > On Tue, Apr 30, 2024 at 05:27:52PM +0100, Mauro Carvalho Chehab wrote: > > > Mark Brown escreveu: > > > > On Tue, Apr 30, 2024 at 10:21:12AM +0200, Sebastian Fricke wrote: > > > > > > The discussion around this originally was that all the audio APIs are > > > > very much centered around real time operations rather than completely > > > > > The media subsystem is also centered around real time. Without real > > > time, you can't have a decent video conference system. Having > > > mem2mem transfers actually help reducing real time delays, as it > > > avoids extra latency due to CPU congestion and/or data transfers > > > from/to userspace. > > > > Real time means strongly tied to wall clock times rather than fast - the > > issue was that all the ALSA APIs are based around pushing data through > > the system based on a clock. > > > > > > That doesn't sound like an immediate solution to maintainer overload > > > > issues... if something like this is going to happen the DRM solution > > > > does seem more general but I'm not sure the amount of stop energy is > > > > proportionate. > > > > > I don't think maintainer overload is the issue here. The main > > > point is to avoid a fork at the audio uAPI, plus the burden > > > of re-inventing the wheel with new codes for audio formats, > > > new documentation for them, etc. > > > > I thought that discussion had been had already at one of the earlier > > versions? TBH I've not really been paying attention to this since the > > very early versions where I raised some similar "why is this in media" > > points and I thought everyone had decided that this did actually make > > sense. > > Yeah, it was discussed in v1 and v2 threads, e.g. > > https://patchwork.kernel.org/project/linux-media/cover/1690265540-25999-1-git-send-email-shengjiu.w...@nxp.com/#25485573 > > My argument at that time was how the operation would be, and the point > was that it'd be a "batch-like" operation via M2M without any timing > control. It'd be a very special usage for for ALSA, and if any, it'd > be hwdep -- that is a very hardware-specific API implementation -- or > try compress-offload API, which looks dubious. > > OTOH, the argument was that there is already a framework for M2M in > media API and that also fits for the batch-like operation, too. So > was the thread evolved until now. M2M transfers are not a hardware-specific API, and such kind of transfers is not new either. Old media devices like bttv have internally a way to do PCI2PCI transfers, allowing media streams to be transferred directly without utilizing CPU. The media driver supports it for video, as this made a huge difference of performance back then. On embedded world, this is a pretty common scenario: different media IP blocks can communicate with each other directly via memory. This can happen for video capture, video display and audio. With M2M, most of the control is offloaded to the hardware. There are still time control associated with it, as audio and video needs to be in sync. This is done by controlling the buffers size and could be fine-tuned by checking when the buffer transfer is done. On media, M2M buffer transfers are started via VIDIOC_QBUF, which is a request to do a frame transfer. A similar ioctl (VIDIOC_DQBUF) is used to monitor when the hardware finishes transfering the buffer. On other words, the CPU is responsible for time control. On other words, this is still real time. The main difference from a "sync" transfer is that the CPU doesn't need to copy data from/to different devices, as such operation is offloaded to the hardware. Regards, Mauro
Re: [PATCH 2/3] selftest/powerpc: Add flags.mk to support pmu buildable
On 4/29/24 7:39 PM, Michael Ellerman wrote: Madhavan Srinivasan writes: When running `make -C powerpc/pmu run_tests` from top level selftests directory, currently this error is being reported make: Entering directory '/home/maddy/linux/tools/testing/selftests/powerpc/pmu' Makefile:40: warning: overriding recipe for target 'emit_tests' ../../lib.mk:111: warning: ignoring old recipe for target 'emit_tests' gcc -m64count_instructions.c ../harness.c event.c lib.c ../utils.c loop.S -o /home/maddy/selftest_output//count_instructions In file included from count_instructions.c:13: event.h:12:10: fatal error: utils.h: No such file or directory 12 | #include "utils.h" | ^ compilation terminated. This is due to missing of include path in CFLAGS. That is, CFLAGS and GIT_VERSION macros are defined in the powerpc/ folder Makefile which in this case not involved. To address the failure incase of executing specific sub-folder test directly, a new rule file has been addded by the patch called "flags.mk" under selftest/powerpc/ folder and is linked to all the Makefile of powerpc/pmu sub-folders. This patch made my selftest build go from ~10s to ~50s ! I tracked it down to "git describe" being run hundreds of times. diff --git a/tools/testing/selftests/powerpc/flags.mk b/tools/testing/selftests/powerpc/flags.mk new file mode 100644 index ..28374f470126 --- /dev/null +++ b/tools/testing/selftests/powerpc/flags.mk @@ -0,0 +1,12 @@ +#This checks for any ENV variables and add those. + +#ifeq ($(GIT_VERSION),) This isn't right, # is a comment in make syntax, so this line is just a comment. It needs to be "ifeq". oops, my bad :( But nice catch. Thanks Maddy +GIT_VERSION = $(shell git describe --always --long --dirty || echo "unknown") Using '=' here means Make re-runs the command every time the variable is used. Previously that was OK because the variable was set once and then exported. But now that it's a Make variable in each file it leads to "git describe" being run a few hundred times. I've squashed in those fixes, no need to send a v2. cheers
Re: [PATCH v2 1/2] selftests/powerpc: Convert pmu Makefile to for loop style
On 4/22/24 7:04 PM, Michael Ellerman wrote: The pmu Makefile has grown more sub directories over the years. Rather than open coding the rules for each subdir, use for loops. Nice cleanup. Thanks. Tested-by: Madhavan Srinivasan Signed-off-by: Michael Ellerman --- tools/testing/selftests/powerpc/pmu/Makefile | 43 ++-- 1 file changed, 22 insertions(+), 21 deletions(-) v2: Actually send both patches. diff --git a/tools/testing/selftests/powerpc/pmu/Makefile b/tools/testing/selftests/powerpc/pmu/Makefile index 1fcacae1b188..773933e5180e 100644 --- a/tools/testing/selftests/powerpc/pmu/Makefile +++ b/tools/testing/selftests/powerpc/pmu/Makefile @@ -9,7 +9,9 @@ top_srcdir = ../../../../.. include ../../lib.mk include ../flags.mk -all: $(TEST_GEN_PROGS) ebb sampling_tests event_code_tests +SUB_DIRS := ebb sampling_tests event_code_tests + +all: $(TEST_GEN_PROGS) $(SUB_DIRS) $(TEST_GEN_PROGS): $(EXTRA_SOURCES) @@ -23,12 +25,16 @@ $(OUTPUT)/count_stcx_fail: loop.S $(EXTRA_SOURCES) $(OUTPUT)/per_event_excludes: ../utils.c +$(SUB_DIRS): + BUILD_TARGET=$(OUTPUT)/$@; mkdir -p $$BUILD_TARGET; $(MAKE) OUTPUT=$$BUILD_TARGET -k -C $@ all + DEFAULT_RUN_TESTS := $(RUN_TESTS) override define RUN_TESTS $(DEFAULT_RUN_TESTS) - +TARGET=ebb; BUILD_TARGET=$$OUTPUT/$$TARGET; $(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET run_tests - +TARGET=sampling_tests; BUILD_TARGET=$$OUTPUT/$$TARGET; $(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET run_tests - +TARGET=event_code_tests; BUILD_TARGET=$$OUTPUT/$$TARGET; $(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET run_tests + +@for TARGET in $(SUB_DIRS); do \ + BUILD_TARGET=$(OUTPUT)/$$TARGET; \ + $(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET run_tests; \ + done; endef emit_tests: @@ -36,34 +42,29 @@ emit_tests: BASENAME_TEST=`basename $$TEST`;\ echo "$(COLLECTION):$$BASENAME_TEST"; \ done - +TARGET=ebb; BUILD_TARGET=$$OUTPUT/$$TARGET; $(MAKE) OUTPUT=$$BUILD_TARGET -s -C $$TARGET emit_tests - +TARGET=sampling_tests; BUILD_TARGET=$$OUTPUT/$$TARGET; $(MAKE) OUTPUT=$$BUILD_TARGET -s -C $$TARGET emit_tests - +TARGET=event_code_tests; BUILD_TARGET=$$OUTPUT/$$TARGET; $(MAKE) OUTPUT=$$BUILD_TARGET -s -C $$TARGET emit_tests + +@for TARGET in $(SUB_DIRS); do \ + BUILD_TARGET=$(OUTPUT)/$$TARGET; \ + $(MAKE) OUTPUT=$$BUILD_TARGET -s -C $$TARGET emit_tests; \ + done; DEFAULT_INSTALL_RULE := $(INSTALL_RULE) override define INSTALL_RULE $(DEFAULT_INSTALL_RULE) - +TARGET=ebb; BUILD_TARGET=$$OUTPUT/$$TARGET; $(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET install - +TARGET=sampling_tests; BUILD_TARGET=$$OUTPUT/$$TARGET; $(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET install - +TARGET=event_code_tests; BUILD_TARGET=$$OUTPUT/$$TARGET; $(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET install + +@for TARGET in $(SUB_DIRS); do \ + BUILD_TARGET=$(OUTPUT)/$$TARGET; \ + $(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET install; \ + done; endef DEFAULT_CLEAN := $(CLEAN) override define CLEAN $(DEFAULT_CLEAN) $(RM) $(TEST_GEN_PROGS) $(OUTPUT)/loop.o - +TARGET=ebb; BUILD_TARGET=$$OUTPUT/$$TARGET; $(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET clean - +TARGET=sampling_tests; BUILD_TARGET=$$OUTPUT/$$TARGET; $(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET clean - +TARGET=event_code_tests; BUILD_TARGET=$$OUTPUT/$$TARGET; $(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET clean + +@for TARGET in $(SUB_DIRS); do \ + BUILD_TARGET=$(OUTPUT)/$$TARGET; \ + $(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET clean; \ + done; endef -ebb: - TARGET=$@; BUILD_TARGET=$$OUTPUT/$$TARGET; mkdir -p $$BUILD_TARGET; $(MAKE) OUTPUT=$$BUILD_TARGET -k -C $$TARGET all - -sampling_tests: - TARGET=$@; BUILD_TARGET=$$OUTPUT/$$TARGET; mkdir -p $$BUILD_TARGET; $(MAKE) OUTPUT=$$BUILD_TARGET -k -C $$TARGET all - -event_code_tests: - TARGET=$@; BUILD_TARGET=$$OUTPUT/$$TARGET; mkdir -p $$BUILD_TARGET; $(MAKE) OUTPUT=$$BUILD_TARGET -k -C $$TARGET all .PHONY: all run_tests ebb sampling_tests event_code_tests emit_tests
Re: [PATCH v15 00/16] Add audio support in v4l2 framework
On Wed, 01 May 2024 03:56:15 +0200, Mark Brown wrote: > > On Tue, Apr 30, 2024 at 05:27:52PM +0100, Mauro Carvalho Chehab wrote: > > Mark Brown escreveu: > > > On Tue, Apr 30, 2024 at 10:21:12AM +0200, Sebastian Fricke wrote: > > > > The discussion around this originally was that all the audio APIs are > > > very much centered around real time operations rather than completely > > > The media subsystem is also centered around real time. Without real > > time, you can't have a decent video conference system. Having > > mem2mem transfers actually help reducing real time delays, as it > > avoids extra latency due to CPU congestion and/or data transfers > > from/to userspace. > > Real time means strongly tied to wall clock times rather than fast - the > issue was that all the ALSA APIs are based around pushing data through > the system based on a clock. > > > > That doesn't sound like an immediate solution to maintainer overload > > > issues... if something like this is going to happen the DRM solution > > > does seem more general but I'm not sure the amount of stop energy is > > > proportionate. > > > I don't think maintainer overload is the issue here. The main > > point is to avoid a fork at the audio uAPI, plus the burden > > of re-inventing the wheel with new codes for audio formats, > > new documentation for them, etc. > > I thought that discussion had been had already at one of the earlier > versions? TBH I've not really been paying attention to this since the > very early versions where I raised some similar "why is this in media" > points and I thought everyone had decided that this did actually make > sense. Yeah, it was discussed in v1 and v2 threads, e.g. https://patchwork.kernel.org/project/linux-media/cover/1690265540-25999-1-git-send-email-shengjiu.w...@nxp.com/#25485573 My argument at that time was how the operation would be, and the point was that it'd be a "batch-like" operation via M2M without any timing control. It'd be a very special usage for for ALSA, and if any, it'd be hwdep -- that is a very hardware-specific API implementation -- or try compress-offload API, which looks dubious. OTOH, the argument was that there is already a framework for M2M in media API and that also fits for the batch-like operation, too. So was the thread evolved until now. thanks, Takashi
