Re: [PATCH] powerpc: Add PVN support for HeXin C2000 processor
Hi Michael,
On 2023/11/22 9:46, Michael Ellerman wrote:
Zhao Ke writes:
HeXin Tech Co. has applied for a new PVN from the OpenPower Community
for its new processor C2000. The OpenPower has assigned a new PVN
and this newly assigned PVN is 0x0066, add pvr register related
support for this PVN.
Signed-off-by: Zhao Ke
Link:
https://discuss.openpower.foundation/t/how-to-get-a-new-pvr-for-processors-follow-power-isa/477/10
Hi Zhao Ke,
Thanks for the patch. Just a few questions.
Are you able to provide any further detail on the processor?
Your cputable entry claims that it's identical to the original Power8
core, can you comment at all on how true that is in practice?
Basically, we made lots of design change for the new processor.
For example:
1. redesign the interconnect of the fabric, from crossbar to mesh
2. redesign the memory subsystem, including the modification of L2
and L3 architecture
3. redesign the SMP bus
4. upgrade PCIe to gen5 and increase the number of lanes
5. upgrade ddr to DDR5, dimm direct connected, and the number of
channels
6. redesign the pervasive architecture, including debug/trace,
clock management, etc.
Unfortunately the kernel has some hard-coded knowledge of various
non-architected features, which are not controlled via the CPU table,
and are instead controlled by firmware. So you'll need to make sure you
set those correctly, see init_fw_feat_flags() for details.
Thanks for telling me, we have a firmware team and we will work together
on this.
One other comment below ...
diff --git a/arch/powerpc/kernel/cpu_specs_book3s_64.h
b/arch/powerpc/kernel/cpu_specs_book3s_64.h
index c370c1b804a9..4f604934da7c 100644
--- a/arch/powerpc/kernel/cpu_specs_book3s_64.h
+++ b/arch/powerpc/kernel/cpu_specs_book3s_64.h
@@ -238,6 +238,21 @@ static struct cpu_spec cpu_specs[] __initdata = {
.machine_check_early= __machine_check_early_realmode_p8,
.platform = "power8",
},
+ { /* 2.07-compliant processor, HeXin C2000 processor */
+ .pvr_mask = 0x,
+ .pvr_value = 0x0066,
+ .cpu_name = "POWER8 (architected)",
Using "(architected)" here is not right. That's reserved for the
0x0f0x range of PVRs.
You should use "POWER8 (raw)", or you could actually use the marketing
name there if you want to, eg. "HeXin C2000" or whatever.
I will update this asap.
cheers
Re: [PATCH v5 1/3] powerpc: make fadump resilient with memory add/remove events
Aneesh Kumar K V writes: ... > > I am not sure whether we need to add all the complexity to enable supporting > different fadump kernel > version. Is that even a possible use case with fadump? Can't we always assume > that with fadump the > crash kernel and fadump kernel will be same version? How sure are we of that? Don't we go through grub when we boot into the 2nd kernel. And so couldn't it choose to boot a different kernel, for whatever reason. I don't think we need to support different pt_reg / cpumask sizes, but requiring the exact same kernel version is too strict I think. But maybe I'm wrong. Would be good to hear what distro folks think. cheers
Re: [PATCH] powerpc: Restrict ARCH_HIBERNATION_POSSIBLE to supported configurations
Vishal Chourasia writes: > On 17/11/23 4:52 am, Michael Ellerman wrote: >> Vishal Chourasia writes: >>> On 15/11/23 5:46 pm, Aneesh Kumar K V wrote: On 11/15/23 5:23 PM, Vishal Chourasia wrote: > On 15/11/23 1:39 pm, Aneesh Kumar K.V wrote: >> Vishal Chourasia writes: >> >>> This patch modifies the ARCH_HIBERNATION_POSSIBLE option to ensure that >>> it >>> correctly depends on these PowerPC configurations being enabled. As a >>> result, >>> it prevents the HOTPLUG_CPU from being selected when the required >>> dependencies >>> are not satisfied. >>> >>> This change aligns the dependency tree with the expected hardware >>> support for >>> CPU hot-plugging under PowerPC architectures, ensuring that the kernel >>> configuration steps do not lead to inconsistent states. >>> >>> Signed-off-by: Vishal Chourasia >>> --- >>> During the configuration process with 'make randconfig' followed by >>> 'make olddefconfig', we observed a warning indicating an unmet direct >>> dependency for the HOTPLUG_CPU option. The dependency in question >>> relates to >>> various PowerPC configurations (PPC_PSERIES, PPC_PMAC, PPC_POWERNV, >>> FSL_SOC_BOOKE) which were not enabled, yet the HOTPLUG_CPU was >>> beingDuring the configuration process with 'make randconfig' followed by >>> 'make olddefconfig', we observed a warning indicating an unmet direct >>> dependency for the HOTPLUG_CPU option. The dependency in question >>> relates to >>> various PowerPC configurations (PPC_PSERIES, PPC_PMAC, PPC_POWERNV, >>> FSL_SOC_BOOKE) which were not enabled, yet the HOTPLUG_CPU was being >>> erroneously selected due to an implicit assumption by the PM_SLEEP_SMP >>> option. >>> This misalignment in dependencies could potentially lead to >>> inconsistent kernel >>> configuration states, especially when considering the necessary hardware >>> support for CPU hot-plugging on PowerPC platforms. The patch aims to >>> correct >>> this by ensuring that ARCH_HIBERNATION_POSSIBLE is contingent upon the >>> appropriate PowerPC configurations being active. >>> >>> steps to reproduce (before applying the patch): >>> >>> Run 'make pseries_le_defconfig' >>> Run 'make menuconfig' >>> Enable hibernation [ Kernel options -> Hibernation (aka 'suspend to >>> disk') ] >>> Disable [ Platform support -> IBM PowerNV (Non-Virtualized) platform >>> support ] >>> Disable [ Platform support -> IBM pSeries & new (POWER5-based) iSeries ] >>> Enable SMP [ Processor support -> Symmetric multi-processing support ] >>> Save the config >>> Run 'make olddefconfig' >>> erroneously selected due to an implicit assumption by the PM_SLEEP_SMP >>> option. >>> This misalignment in dependencies could potentially lead to >>> inconsistent kernel >>> configuration states, especially when considering the necessary hardware >>> support for CPU hot-plugging on PowerPC platforms. The patch aims to >>> correct >>> this by ensuring that ARCH_HIBERNATION_POSSIBLE is contingent upon the >>> appropriate PowerPC configurations being active. >>> >>> steps to reproduce (before applying the patch): >>> >>> Run 'make pseries_le_defconfig' >>> Run 'make menuconfig' >>> Enable hibernation [ Kernel options -> Hibernation (aka 'suspend to >>> disk') ] >>> Disable [ Platform support -> IBM PowerNV (Non-Virtualized) platform >>> support ] >>> Disable [ Platform support -> IBM pSeries & new (POWER5-based) iSeries ] >>> Enable SMP [ Processor support -> Symmetric multi-processing support ] >>> Save the config >>> Run 'make olddefconfig' >>> >>> arch/powerpc/Kconfig | 5 +++-- >>> 1 file changed, 3 insertions(+), 2 deletions(-) >>> >>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig >>> index 6f105ee4f3cf..bf99ff9869f6 100644 >>> --- a/arch/powerpc/Kconfig >>> +++ b/arch/powerpc/Kconfig >>> @@ -380,8 +380,9 @@ config DEFAULT_UIMAGE >>> Used to allow a board to specify it wants a uImage built by >>> default >>> >>> config ARCH_HIBERNATION_POSSIBLE >>> - bool >>> - default y >>> + def_bool y >>> + depends on PPC_PSERIES || \ >>> + PPC_PMAC || PPC_POWERNV || FSL_SOC_BOOKE >>> >>> config ARCH_SUSPEND_POSSIBLE >>> def_bool y >>> >> I am wondering whether it should be switched to using select from >> config PPC? >> >> selecting ARCH_HIBERNATION_POSSIBLE based on value of config PPC >> will not guarantee config PPC_PSERIES being set >> >> PPC_PSERIES can be set to N, even when config PPC is set. >>> I understand what you meant before. Having ARCH_HIBERNATION_POSSIBLE under >>> config PPC makes more sense. >>
Re: [PATCH v2] powerpc: Don't clobber fr0/vs0 during fp|altivec register save
Timothy Pearson writes: > ... > > So a little more detail on this, just to put it to rest properly vs. > assuming hand analysis caught every possible pathway. :) > > The debugging that generates this stack trace also verifies the following in > __giveup_fpu(): > > 1.) tsk->thread.fp_state.fpr doesn't contain the FPSCR contents prior to > calling save_fpu() > 2.) tsk->thread.fp_state.fpr contains the FPSCR contents directly after > calling save_fpu() > 3.) MSR_FP is set both in the task struct and in the live MSR. > > Only if all three conditions are met will it generate the trace. This > is a generalization of the hack I used to find the problem in the > first place. > > If the state will subsequently be reloaded from the thread struct, > that means we're reloading the registers from the thread struct that > we just verified was corrupted by the earlier save_fpu() call. There > are only two ways I can see for that to be true -- one is if the > registers were already clobbered when giveup_all() was entered, and > the other is if save_fpu() went ahead and clobbered them right here > inside giveup_all(). > > To see which scenario we were dealing with, I added a bit more > instrumentation to dump the current register state if MSR_FP bit was > already set in registers (i.e. not dumping data from task struct, but > using the live FPU registers instead), and sure enough the registers > are corrupt on entry, so something else has already called save_fpu() > before we even hit giveup_all() in this call chain. Can you share the debug patch you're using? cheers
Re: [PATCH] powerpc/lib: Avoid array bounds warnings in vec ops
Naveen N Rao writes:
> On Tue, Nov 21, 2023 at 10:54:36AM +1100, Michael Ellerman wrote:
>> Building with GCC 13 (which has -array-bounds enabled) there are several
>
> Thanks, gcc13 indeed helps reproduce the warnings.
Actually that part is no longer true since 0da6e5fd6c37 ("gcc: disable
'-Warray-bounds' for gcc-13 too").
>> warnings in sstep.c along the lines of:
>>
>> In function ‘do_byte_reverse’,
>> inlined from ‘do_vec_load’ at arch/powerpc/lib/sstep.c:691:3,
>> inlined from ‘emulate_loadstore’ at arch/powerpc/lib/sstep.c:3439:9:
>> arch/powerpc/lib/sstep.c:289:23: error: array subscript 2 is outside array
>> bounds of ‘u8[16]’ {aka ‘unsigned char[16]’} [-Werror=array-bounds=]
>> 289 | up[2] = byterev_8(up[1]);
>> | ~~^~
>> arch/powerpc/lib/sstep.c: In function ‘emulate_loadstore’:
>> arch/powerpc/lib/sstep.c:681:11: note: at offset 16 into object ‘u’ of
>> size 16
>> 681 | } u = {};
>> | ^
>>
>> do_byte_reverse() supports a size up to 32 bytes, but in these cases the
>> caller is only passing a 16 byte buffer. In practice there is no bug,
>> do_vec_load() is only called from the LOAD_VMX case in emulate_loadstore().
>> That in turn is only reached when analyse_instr() recognises VMX ops,
>> and in all cases the size is no greater than 16:
>>
>> $ git grep -w LOAD_VMX arch/powerpc/lib/sstep.c
>> arch/powerpc/lib/sstep.c:op->type = MKOP(LOAD_VMX,
>> 0, 1);
>> arch/powerpc/lib/sstep.c:op->type = MKOP(LOAD_VMX,
>> 0, 2);
>> arch/powerpc/lib/sstep.c:op->type = MKOP(LOAD_VMX,
>> 0, 4);
>> arch/powerpc/lib/sstep.c:op->type = MKOP(LOAD_VMX,
>> 0, 16);
>>
>> Similarly for do_vec_store().
>>
>> Although the warning is incorrect, the code would be safer if it clamped
>> the size from the caller to the known size of the buffer. Do that using
>> min_t().
>
> But, do_vec_load() and do_vec_store() assume that the maximum size is 16
> (the address_ok() check as an example). So, should we be considering a
> bigger hammer to help detect future incorrect use?
Yeah true.
To be honest I don't know how paranoid we want to get, we could end up
putting WARN's all over the kernel :)
In this case I guess if the size is too large we overflow the buffer on
the kernel stack, so we should at least check the size.
But does it need a WARN? I'm not sure. If we had a case that was passing
a out-of-bound size hopefully we would notice in testing? :)
cheers
> diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
> index a4ab8625061a..ac22136032b8 100644
> --- a/arch/powerpc/lib/sstep.c
> +++ b/arch/powerpc/lib/sstep.c
> @@ -680,6 +680,9 @@ static nokprobe_inline int do_vec_load(int rn, unsigned
> long ea,
> u8 b[sizeof(__vector128)];
> } u = {};
>
> + if (WARN_ON_ONCE(size > sizeof(u)))
> + return -EINVAL;
> +
> if (!address_ok(regs, ea & ~0xfUL, 16))
> return -EFAULT;
> /* align to multiple of size */
> @@ -707,6 +710,9 @@ static nokprobe_inline int do_vec_store(int rn, unsigned
> long ea,
> u8 b[sizeof(__vector128)];
> } u;
>
> + if (WARN_ON_ONCE(size > sizeof(u)))
> + return -EINVAL;
> +
> if (!address_ok(regs, ea & ~0xfUL, 16))
> return -EFAULT;
> /* align to multiple of size */
>
>
> - Naveen
Re: [PATCH] powerpc: add crtsavres.o to always-y instead of extra-y
On Tue, Nov 21, 2023 at 6:55 PM Aneesh Kumar K.V
wrote:
>
> "Nicholas Piggin" writes:
>
> > On Tue Nov 21, 2023 at 9:23 AM AEST, Masahiro Yamada wrote:
> >> crtsavres.o is linked to modules. However, as explained in commit
> >> d0e628cd817f ("kbuild: doc: clarify the difference between extra-y
> >> and always-y"), 'make modules' does not build extra-y.
> >>
> >> For example, the following command fails:
> >>
> >> $ make ARCH=powerpc LLVM=1 KBUILD_MODPOST_WARN=1 mrproper ps3_defconfig
> >> modules
> >> [snip]
> >> LD [M] arch/powerpc/platforms/cell/spufs/spufs.ko
> >> ld.lld: error: cannot open arch/powerpc/lib/crtsavres.o: No such file or
> >> directory
> >> make[3]: *** [scripts/Makefile.modfinal:56:
> >> arch/powerpc/platforms/cell/spufs/spufs.ko] Error 1
> >> make[2]: *** [Makefile:1844: modules] Error 2
> >> make[1]: *** [/home/masahiro/workspace/linux-kbuild/Makefile:350:
> >> __build_one_by_one] Error 2
> >> make: *** [Makefile:234: __sub-make] Error 2
> >>
> >
> > Thanks. Is this the correct Fixes tag?
> >
> > Fixes: d0e628cd817f ("powerpc/64: Do not link crtsavres.o in vmlinux")
> >
>
> I am finding a different commit ID:
>
> commit baa25b571a168aff5a13bfdc973f1229e2b12b63
> Author: Nicholas Piggin
> Date: Fri May 12 01:56:49 2017 +1000
>
> powerpc/64: Do not link crtsavres.o in vmlinux
>
> The 64-bit linker creates save/restore functions on demand with final
> links, so vmlinux does not require crtsavres.o.
>
>
> -aneesh
Yeah, I think the correct tag is:
Fixes: baa25b571a16 ("powerpc/64: Do not link crtsavres.o in vmlinux")
--
Best Regards
Masahiro Yamada
[PATCH] powerpc/xics: Check return value of kasprintf in icp_native_map_one_cpu
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
Signed-off-by: Kunwu Chan
---
arch/powerpc/sysdev/xics/icp-native.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/sysdev/xics/icp-native.c
b/arch/powerpc/sysdev/xics/icp-native.c
index f6ec6dba92dc..700b67476a7d 100644
--- a/arch/powerpc/sysdev/xics/icp-native.c
+++ b/arch/powerpc/sysdev/xics/icp-native.c
@@ -236,6 +236,8 @@ static int __init icp_native_map_one_cpu(int hw_id,
unsigned long addr,
rname = kasprintf(GFP_KERNEL, "CPU %d [0x%x] Interrupt Presentation",
cpu, hw_id);
+ if (!rname)
+ return -ENOMEM;
if (!request_mem_region(addr, size, rname)) {
pr_warn("icp_native: Could not reserve ICP MMIO for CPU %d,
interrupt server #0x%x\n",
cpu, hw_id);
--
2.34.1
[PATCH] KVM: PPC: Book3S HV: Fix KVM_RUN clobbering FP/VEC user registers
Before running a guest, the host process (e.g., QEMU) FP/VEC registers
are saved if they were being used, similarly to when the kernel uses FP
registers. The guest values are then be loaded into regs, and the host
process registers will be restored lazily when it uses FP/VEC.
KVM HV has a bug here: the host process registers do get saved, but the
user MSR bits remain enabled, which indicates the registers are valid
for the process. After they are clobbered by running the guest, this
valid indication causes the host process to take on the FP/VEC regiter
values of the guest.
Fixes: de2a20aa7237b ("powerpc: Prepare for splitting giveup_{fpu, altivec,
vsx} in two")
Signed-off-by: Nicholas Piggin
---
arch/powerpc/kernel/process.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 392404688cec..9452a54d356c 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1198,11 +1198,11 @@ void kvmppc_save_user_regs(void)
usermsr = current->thread.regs->msr;
+ /* Caller has enabled FP/VEC/VSX/TM in MSR */
if (usermsr & MSR_FP)
- save_fpu(current);
-
+ __giveup_fpu(current);
if (usermsr & MSR_VEC)
- save_altivec(current);
+ __giveup_altivec(current);
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
if (usermsr & MSR_TM) {
--
2.42.0
[PATCH] ASoC: fsl_xcvr: Enable 2 * TX bit clock for spdif only case
The bit 10 in TX_DPTH_CTRL register controls the TX clock rate.
If this bit is set, TX datapath clock should be = 2* TX bit rate.
If this bit is not set, TX datapath clock should be 10* TX bit rate.
As the spdif only case, we always use 2 * TX bit clock, so
this bit need to be set.
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl_xcvr.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/sound/soc/fsl/fsl_xcvr.c b/sound/soc/fsl/fsl_xcvr.c
index fa0a15263c66..77f8e2394bf9 100644
--- a/sound/soc/fsl/fsl_xcvr.c
+++ b/sound/soc/fsl/fsl_xcvr.c
@@ -414,6 +414,16 @@ static int fsl_xcvr_prepare(struct snd_pcm_substream
*substream,
switch (xcvr->mode) {
case FSL_XCVR_MODE_SPDIF:
+ if (xcvr->soc_data->spdif_only && tx) {
+ ret = regmap_update_bits(xcvr->regmap,
FSL_XCVR_TX_DPTH_CTRL_SET,
+
FSL_XCVR_TX_DPTH_CTRL_BYPASS_FEM,
+
FSL_XCVR_TX_DPTH_CTRL_BYPASS_FEM);
+ if (ret < 0) {
+ dev_err(dai->dev, "Failed to set bypass fem:
%d\n", ret);
+ return ret;
+ }
+ }
+ fallthrough;
case FSL_XCVR_MODE_ARC:
if (tx) {
ret = fsl_xcvr_en_aud_pll(xcvr, fout);
--
2.34.1
Re: [PATCH] powerpc: Add PVN support for HeXin C2000 processor
Zhao Ke writes:
> HeXin Tech Co. has applied for a new PVN from the OpenPower Community
> for its new processor C2000. The OpenPower has assigned a new PVN
> and this newly assigned PVN is 0x0066, add pvr register related
> support for this PVN.
>
> Signed-off-by: Zhao Ke
> Link:
> https://discuss.openpower.foundation/t/how-to-get-a-new-pvr-for-processors-follow-power-isa/477/10
Hi Zhao Ke,
Thanks for the patch. Just a few questions.
Are you able to provide any further detail on the processor?
Your cputable entry claims that it's identical to the original Power8
core, can you comment at all on how true that is in practice?
Unfortunately the kernel has some hard-coded knowledge of various
non-architected features, which are not controlled via the CPU table,
and are instead controlled by firmware. So you'll need to make sure you
set those correctly, see init_fw_feat_flags() for details.
One other comment below ...
> diff --git a/arch/powerpc/kernel/cpu_specs_book3s_64.h
> b/arch/powerpc/kernel/cpu_specs_book3s_64.h
> index c370c1b804a9..4f604934da7c 100644
> --- a/arch/powerpc/kernel/cpu_specs_book3s_64.h
> +++ b/arch/powerpc/kernel/cpu_specs_book3s_64.h
> @@ -238,6 +238,21 @@ static struct cpu_spec cpu_specs[] __initdata = {
> .machine_check_early= __machine_check_early_realmode_p8,
> .platform = "power8",
> },
> + { /* 2.07-compliant processor, HeXin C2000 processor */
> + .pvr_mask = 0x,
> + .pvr_value = 0x0066,
> + .cpu_name = "POWER8 (architected)",
Using "(architected)" here is not right. That's reserved for the
0x0f0x range of PVRs.
You should use "POWER8 (raw)", or you could actually use the marketing
name there if you want to, eg. "HeXin C2000" or whatever.
cheers
Re: [PATCH v4 5/5] RISC-V: Enable SBI based earlycon support
Hi Anup,
On 2023-11-17 9:38 PM, Anup Patel wrote:
> Let us enable SBI based earlycon support in defconfigs for both RV32
> and RV64 so that "earlycon=sbi" can be used again.
>
> Signed-off-by: Anup Patel
> Reviewed-by: Andrew Jones
> ---
> arch/riscv/configs/defconfig | 1 +
> arch/riscv/configs/rv32_defconfig | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
> index 905881282a7c..eaf34e871e30 100644
> --- a/arch/riscv/configs/defconfig
> +++ b/arch/riscv/configs/defconfig
> @@ -149,6 +149,7 @@ CONFIG_SERIAL_8250_CONSOLE=y
> CONFIG_SERIAL_8250_DW=y
> CONFIG_SERIAL_OF_PLATFORM=y
> CONFIG_SERIAL_SH_SCI=y
> +CONFIG_SERIAL_EARLYCON_RISCV_SBI=y
> CONFIG_VIRTIO_CONSOLE=y
> CONFIG_HW_RANDOM=y
> CONFIG_HW_RANDOM_VIRTIO=y
> diff --git a/arch/riscv/configs/rv32_defconfig
> b/arch/riscv/configs/rv32_defconfig
> index 89b601e253a6..5721af39afd1 100644
> --- a/arch/riscv/configs/rv32_defconfig
> +++ b/arch/riscv/configs/rv32_defconfig
This file isn't used anymore since 72f045d19f25 ("riscv: Fixup difference with
defconfig"), so there's no need to update it. I'll send a patch deleting it.
Regards,
Samuel
> @@ -66,6 +66,7 @@ CONFIG_INPUT_MOUSEDEV=y
> CONFIG_SERIAL_8250=y
> CONFIG_SERIAL_8250_CONSOLE=y
> CONFIG_SERIAL_OF_PLATFORM=y
> +CONFIG_SERIAL_EARLYCON_RISCV_SBI=y
> CONFIG_VIRTIO_CONSOLE=y
> CONFIG_HW_RANDOM=y
> CONFIG_HW_RANDOM_VIRTIO=y
Re: [PATCH v4 2/5] RISC-V: Add SBI debug console helper routines
Hi Anup,
On 2023-11-17 9:38 PM, Anup Patel wrote:
> Let us provide SBI debug console helper routines which can be
> shared by serial/earlycon-riscv-sbi.c and hvc/hvc_riscv_sbi.c.
>
> Signed-off-by: Anup Patel
> ---
> arch/riscv/include/asm/sbi.h | 5 +
> arch/riscv/kernel/sbi.c | 43
> 2 files changed, 48 insertions(+)
>
> diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
> index 66f3933c14f6..ee7aef5f6233 100644
> --- a/arch/riscv/include/asm/sbi.h
> +++ b/arch/riscv/include/asm/sbi.h
> @@ -334,6 +334,11 @@ static inline unsigned long sbi_mk_version(unsigned long
> major,
> }
>
> int sbi_err_map_linux_errno(int err);
> +
> +extern bool sbi_debug_console_available;
> +int sbi_debug_console_write(unsigned int num_bytes, phys_addr_t base_addr);
> +int sbi_debug_console_read(unsigned int num_bytes, phys_addr_t base_addr);
> +
> #else /* CONFIG_RISCV_SBI */
> static inline int sbi_remote_fence_i(const struct cpumask *cpu_mask) {
> return -1; }
> static inline void sbi_init(void) {}
> diff --git a/arch/riscv/kernel/sbi.c b/arch/riscv/kernel/sbi.c
> index 5a62ed1da453..73a9c22c3945 100644
> --- a/arch/riscv/kernel/sbi.c
> +++ b/arch/riscv/kernel/sbi.c
> @@ -571,6 +571,44 @@ long sbi_get_mimpid(void)
> }
> EXPORT_SYMBOL_GPL(sbi_get_mimpid);
>
> +bool sbi_debug_console_available;
> +
> +int sbi_debug_console_write(unsigned int num_bytes, phys_addr_t base_addr)
> +{
> + struct sbiret ret;
> +
> + if (!sbi_debug_console_available)
> + return -EOPNOTSUPP;
> +
> + if (IS_ENABLED(CONFIG_32BIT))
> + ret = sbi_ecall(SBI_EXT_DBCN, SBI_EXT_DBCN_CONSOLE_WRITE,
> + num_bytes, lower_32_bits(base_addr),
> + upper_32_bits(base_addr), 0, 0, 0);
> + else
> + ret = sbi_ecall(SBI_EXT_DBCN, SBI_EXT_DBCN_CONSOLE_WRITE,
> + num_bytes, base_addr, 0, 0, 0, 0);
> +
> + return ret.error ? sbi_err_map_linux_errno(ret.error) : ret.value;
> +}
> +
> +int sbi_debug_console_read(unsigned int num_bytes, phys_addr_t base_addr)
> +{
> + struct sbiret ret;
> +
> + if (!sbi_debug_console_available)
> + return -EOPNOTSUPP;
> +
> + if (IS_ENABLED(CONFIG_32BIT))
> + ret = sbi_ecall(SBI_EXT_DBCN, SBI_EXT_DBCN_CONSOLE_READ,
> + num_bytes, lower_32_bits(base_addr),
> + upper_32_bits(base_addr), 0, 0, 0);
> + else
> + ret = sbi_ecall(SBI_EXT_DBCN, SBI_EXT_DBCN_CONSOLE_READ,
> + num_bytes, base_addr, 0, 0, 0, 0);
> +
> + return ret.error ? sbi_err_map_linux_errno(ret.error) : ret.value;
> +}
Since every place that calls these functions will need to do the vmalloc lookup,
would it make sense to do it here, and have these take a pointer instead?
Regards,
Samuel
Re: [PATCH v4 3/5] tty/serial: Add RISC-V SBI debug console based earlycon
Hi Anup,
On 2023-11-17 9:38 PM, Anup Patel wrote:
> We extend the existing RISC-V SBI earlycon support to use the new
> RISC-V SBI debug console extension.
>
> Signed-off-by: Anup Patel
> Reviewed-by: Andrew Jones
> ---
> drivers/tty/serial/Kconfig | 2 +-
> drivers/tty/serial/earlycon-riscv-sbi.c | 24
> 2 files changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index 732c893c8d16..1f2594b8ab9d 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -87,7 +87,7 @@ config SERIAL_EARLYCON_SEMIHOST
>
> config SERIAL_EARLYCON_RISCV_SBI
> bool "Early console using RISC-V SBI"
> - depends on RISCV_SBI_V01
> + depends on RISCV_SBI
> select SERIAL_CORE
> select SERIAL_CORE_CONSOLE
> select SERIAL_EARLYCON
> diff --git a/drivers/tty/serial/earlycon-riscv-sbi.c
> b/drivers/tty/serial/earlycon-riscv-sbi.c
> index 27afb0b74ea7..5351e1e31f45 100644
> --- a/drivers/tty/serial/earlycon-riscv-sbi.c
> +++ b/drivers/tty/serial/earlycon-riscv-sbi.c
> @@ -15,17 +15,33 @@ static void sbi_putc(struct uart_port *port, unsigned
> char c)
> sbi_console_putchar(c);
> }
>
> -static void sbi_console_write(struct console *con,
> - const char *s, unsigned n)
> +static void sbi_0_1_console_write(struct console *con,
> + const char *s, unsigned int n)
> {
> struct earlycon_device *dev = con->data;
> uart_console_write(>port, s, n, sbi_putc);
> }
>
> +static void sbi_dbcn_console_write(struct console *con,
> +const char *s, unsigned int n)
> +{
> + sbi_debug_console_write(n, __pa(s));
This only works for strings in the linear mapping or the kernel mapping (not
vmalloc, which includes the stack). So I don't think we can use __pa() here.
> +}
> +
> static int __init early_sbi_setup(struct earlycon_device *device,
> const char *opt)
> {
> - device->con->write = sbi_console_write;
> - return 0;
> + int ret = 0;
> +
> + if (sbi_debug_console_available) {
> + device->con->write = sbi_dbcn_console_write;
> + } else {
> + if (IS_ENABLED(CONFIG_RISCV_SBI_V01))
"else if", no need for the extra block/indentation.
Regards,
Samuel
> + device->con->write = sbi_0_1_console_write;
> + else
> + ret = -ENODEV;
> + }
> +
> + return ret;
> }
> EARLYCON_DECLARE(sbi, early_sbi_setup);
Re: [PATCH v4 1/5] RISC-V: Add stubs for sbi_console_putchar/getchar()
Hi Anup,
On 2023-11-17 9:38 PM, Anup Patel wrote:
> The functions sbi_console_putchar() and sbi_console_getchar() are
> not defined when CONFIG_RISCV_SBI_V01 is disabled so let us add
> stub of these functions to avoid "#ifdef" on user side.
>
> Signed-off-by: Anup Patel
> Reviewed-by: Andrew Jones
> ---
> arch/riscv/include/asm/sbi.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
> index 0892f4421bc4..66f3933c14f6 100644
> --- a/arch/riscv/include/asm/sbi.h
> +++ b/arch/riscv/include/asm/sbi.h
> @@ -271,8 +271,13 @@ struct sbiret sbi_ecall(int ext, int fid, unsigned long
> arg0,
> unsigned long arg3, unsigned long arg4,
> unsigned long arg5);
>
> +#ifdef CONFIG_RISCV_SBI_V01
> void sbi_console_putchar(int ch);
> int sbi_console_getchar(void);
> +#else
> +static inline void sbi_console_putchar(int ch) { }
> +static inline int sbi_console_getchar(void) { return -ENOENT; }
"The SBI call returns the byte on success, or -1 for failure."
So -ENOENT is not really an appropriate value to return here.
Regards,
Samuel
> +#endif
> long sbi_get_mvendorid(void);
> long sbi_get_marchid(void);
> long sbi_get_mimpid(void);
[PATCH 12/14] tools/perf: Update tools's copy of powerpc syscall table
tldr; Just FYI, I'm carrying this on the perf tools tree.
Full explanation:
There used to be no copies, with tools/ code using kernel headers
directly. From time to time tools/perf/ broke due to legitimate kernel
hacking. At some point Linus complained about such direct usage. Then we
adopted the current model.
The way these headers are used in perf are not restricted to just
including them to compile something.
There are sometimes used in scripts that convert defines into string
tables, etc, so some change may break one of these scripts, or new MSRs
may use some different #define pattern, etc.
E.g.:
$ ls -1 tools/perf/trace/beauty/*.sh | head -5
tools/perf/trace/beauty/arch_errno_names.sh
tools/perf/trace/beauty/drm_ioctl.sh
tools/perf/trace/beauty/fadvise.sh
tools/perf/trace/beauty/fsconfig.sh
tools/perf/trace/beauty/fsmount.sh
$
$ tools/perf/trace/beauty/fadvise.sh
static const char *fadvise_advices[] = {
[0] = "NORMAL",
[1] = "RANDOM",
[2] = "SEQUENTIAL",
[3] = "WILLNEED",
[4] = "DONTNEED",
[5] = "NOREUSE",
};
$
The tools/perf/check-headers.sh script, part of the tools/ build
process, points out changes in the original files.
So its important not to touch the copies in tools/ when doing changes in
the original kernel headers, that will be done later, when
check-headers.sh inform about the change to the perf tools hackers.
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Namhyung Kim
---
tools/perf/arch/powerpc/entry/syscalls/syscall.tbl | 4
1 file changed, 4 insertions(+)
diff --git a/tools/perf/arch/powerpc/entry/syscalls/syscall.tbl
b/tools/perf/arch/powerpc/entry/syscalls/syscall.tbl
index e1412519b4ad..7fab411378f2 100644
--- a/tools/perf/arch/powerpc/entry/syscalls/syscall.tbl
+++ b/tools/perf/arch/powerpc/entry/syscalls/syscall.tbl
@@ -539,3 +539,7 @@
450nospu set_mempolicy_home_node sys_set_mempolicy_home_node
451common cachestat sys_cachestat
452common fchmodat2 sys_fchmodat2
+453common map_shadow_stacksys_ni_syscall
+454common futex_wake sys_futex_wake
+455common futex_wait sys_futex_wait
+456common futex_requeue sys_futex_requeue
--
2.43.0.rc1.413.gea7ed67945-goog
Re: [PATCH 20/22] usb: fsl-mph-dr-of: mark fsl_usb2_mpc5121_init() static
On Wed, Nov 08, 2023 at 01:58:41PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> This function is only called locally and should always have been static:
>
> drivers/usb/host/fsl-mph-dr-of.c:291:5: error: no previous prototype for
> 'fsl_usb2_mpc5121_init' [-Werror=missing-prototypes]
>
> Fixes: 230f7ede6c2f ("USB: add USB EHCI support for MPC5121 SoC")
> Signed-off-by: Arnd Bergmann
Acked-by: Greg Kroah-Hartman
[PATCH][next] powerpc/crypto: Avoid -Wstringop-overflow warnings
The compiler doesn't know that `32` is an offset into the Hash table:
56 struct Hash_ctx {
57 u8 H[16]; /* subkey */
58 u8 Htable[256]; /* Xi, Hash table(offset 32) */
59 };
So, it legitimately complains about a potential out-of-bounds issue
if `256 bytes` are accessed in `htable` (this implies going
`32 bytes` beyond the boundaries of `Htable`):
arch/powerpc/crypto/aes-gcm-p10-glue.c: In function 'gcmp10_init':
arch/powerpc/crypto/aes-gcm-p10-glue.c:120:9: error: 'gcm_init_htable'
accessing 256 bytes in a region of size 224 [-Werror=stringop-overflow=]
120 | gcm_init_htable(hash->Htable+32, hash->H);
| ^
arch/powerpc/crypto/aes-gcm-p10-glue.c:120:9: note: referencing argument 1 of
type 'unsigned char[256]'
arch/powerpc/crypto/aes-gcm-p10-glue.c:120:9: note: referencing argument 2 of
type 'unsigned char[16]'
arch/powerpc/crypto/aes-gcm-p10-glue.c:40:17: note: in a call to function
'gcm_init_htable'
40 | asmlinkage void gcm_init_htable(unsigned char htable[256], unsigned
char Xi[16]);
| ^~~
Address this by avoiding specifying the size of `htable` in the function
prototype; and just for consistency, do the same for parameter `Xi`.
Reported-by: Stephen Rothwell
Closes:
https://lore.kernel.org/linux-next/20231121131903.68a37...@canb.auug.org.au/
Signed-off-by: Gustavo A. R. Silva
---
arch/powerpc/crypto/aes-gcm-p10-glue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/crypto/aes-gcm-p10-glue.c
b/arch/powerpc/crypto/aes-gcm-p10-glue.c
index 4b6e899895e7..f62ee54076c0 100644
--- a/arch/powerpc/crypto/aes-gcm-p10-glue.c
+++ b/arch/powerpc/crypto/aes-gcm-p10-glue.c
@@ -37,7 +37,7 @@ asmlinkage void aes_p10_gcm_encrypt(u8 *in, u8 *out, size_t
len,
void *rkey, u8 *iv, void *Xi);
asmlinkage void aes_p10_gcm_decrypt(u8 *in, u8 *out, size_t len,
void *rkey, u8 *iv, void *Xi);
-asmlinkage void gcm_init_htable(unsigned char htable[256], unsigned char
Xi[16]);
+asmlinkage void gcm_init_htable(unsigned char htable[], unsigned char Xi[]);
asmlinkage void gcm_ghash_p10(unsigned char *Xi, unsigned char *Htable,
unsigned char *aad, unsigned int alen);
--
2.34.1
Re: [PATCH v5 1/2] ASoC: dt-bindings: sound-card-common: List sound widgets ignoring system suspend
On Tue, 21 Nov 2023 13:25:11 +0800, Chancel Liu wrote: > Add a property to list audio sound widgets which are marked ignoring > system suspend. Paths between these endpoints are still active over > suspend of the main application processor that the current operating > system is running. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/2] ASoC: dt-bindings: sound-card-common: List sound widgets ignoring system suspend commit: 27c69d7da1084af0b8b3a20ef9ff01e9eda5270c [2/2] ASoC: imx-rpmsg: Force codec power on in low power audio mode commit: 5d9f746ca64c3ebfba3b650dbc4b0de705c83f3b All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH 34/34] KVM: selftests: Add a memory region subtest to validate invalid flags
On Mon, Nov 20, 2023 at 3:09 PM Mark Brown wrote: > > On Wed, Nov 08, 2023 at 05:08:01PM -0800, Anish Moorthy wrote: > > Applying [1] and [2] reveals that this also breaks non-x86 builds- the > > MEM_REGION_GPA/SLOT definitions are guarded behind an #ifdef > > __x86_64__, while the usages introduced here aren't. > > > > Should > > > > On Sun, Nov 5, 2023 at 8:35 AM Paolo Bonzini wrote: > > > > > > + test_invalid_memory_region_flags(); > > > > be #ifdef'd, perhaps? I'm not quite sure what the intent is. > > This has been broken in -next for a week now, do we have any progress > on a fix or should we just revert the patch? Sorry, I was away last week. I have now posted a patch. Paolo
Re: [PATCH v9 00/27] Add support for QMC HDLC, framer infrastructure and PEF2256 framer
On Tue, 21 Nov 2023 08:43:30 +0100 Herve Codina wrote: > I plan to send the v10 with the patch 23 fixed. > Based on that v10, some patches (21 to 25 at least) could be applied and > I will remove them for the future v11. > I think it will be easier to follow if I iterate on the series removing > patches as soon as they are applied. It'd be helpful if you only reposted the patches you expect to be applied, as a standalone series.
Re: [PATCH RFC 06/12] mm/gup: Drop folio_fast_pin_allowed() in hugepd processing
On Mon, Nov 20, 2023 at 12:26:24AM -0800, Christoph Hellwig wrote:
> On Wed, Nov 15, 2023 at 08:29:02PM -0500, Peter Xu wrote:
> > Hugepd format is only used in PowerPC with hugetlbfs. In commit
> > a6e79df92e4a ("mm/gup: disallow FOLL_LONGTERM GUP-fast writing to
> > file-backed mappings"), we added a check to fail gup-fast if there's
> > potential risk of violating GUP over writeback file systems. That should
> > never apply to hugepd.
> >
> > Drop that check, not only because it'll never be true for hugepd, but also
> > it paves way for reusing the function outside fast-gup.
>
> What prevents us from ever using hugepd with file mappings? I think
> it would naturally fit in with how large folios for the pagecache work.
>
> So keeping this check and generalizing it seems like the better idea to
> me.
But then it means we're still keeping that dead code for fast-gup even if
we know that fact.. Or do we have a plan to add that support very soon, so
this code will be destined to add back?
The other option is I can always add a comment above gup_huge_pd()
explaining this special bit, so that when someone is adding hugepd support
to file large folios we'll hopefully not forget it? But then that
generalization work will only happen when the code will be needed.
Thanks,
--
Peter Xu
Re: [PATCH] powerpc/lib: Avoid array bounds warnings in vec ops
On Tue, Nov 21, 2023 at 10:54:36AM +1100, Michael Ellerman wrote:
> Building with GCC 13 (which has -array-bounds enabled) there are several
Thanks, gcc13 indeed helps reproduce the warnings.
> warnings in sstep.c along the lines of:
>
> In function ‘do_byte_reverse’,
> inlined from ‘do_vec_load’ at arch/powerpc/lib/sstep.c:691:3,
> inlined from ‘emulate_loadstore’ at arch/powerpc/lib/sstep.c:3439:9:
> arch/powerpc/lib/sstep.c:289:23: error: array subscript 2 is outside array
> bounds of ‘u8[16]’ {aka ‘unsigned char[16]’} [-Werror=array-bounds=]
> 289 | up[2] = byterev_8(up[1]);
> | ~~^~
> arch/powerpc/lib/sstep.c: In function ‘emulate_loadstore’:
> arch/powerpc/lib/sstep.c:681:11: note: at offset 16 into object ‘u’ of size
> 16
> 681 | } u = {};
> | ^
>
> do_byte_reverse() supports a size up to 32 bytes, but in these cases the
> caller is only passing a 16 byte buffer. In practice there is no bug,
> do_vec_load() is only called from the LOAD_VMX case in emulate_loadstore().
> That in turn is only reached when analyse_instr() recognises VMX ops,
> and in all cases the size is no greater than 16:
>
> $ git grep -w LOAD_VMX arch/powerpc/lib/sstep.c
> arch/powerpc/lib/sstep.c:op->type = MKOP(LOAD_VMX,
> 0, 1);
> arch/powerpc/lib/sstep.c:op->type = MKOP(LOAD_VMX,
> 0, 2);
> arch/powerpc/lib/sstep.c:op->type = MKOP(LOAD_VMX,
> 0, 4);
> arch/powerpc/lib/sstep.c:op->type = MKOP(LOAD_VMX,
> 0, 16);
>
> Similarly for do_vec_store().
>
> Although the warning is incorrect, the code would be safer if it clamped
> the size from the caller to the known size of the buffer. Do that using
> min_t().
But, do_vec_load() and do_vec_store() assume that the maximum size is 16
(the address_ok() check as an example). So, should we be considering a
bigger hammer to help detect future incorrect use?
Something like the below?
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index a4ab8625061a..ac22136032b8 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -680,6 +680,9 @@ static nokprobe_inline int do_vec_load(int rn, unsigned
long ea,
u8 b[sizeof(__vector128)];
} u = {};
+ if (WARN_ON_ONCE(size > sizeof(u)))
+ return -EINVAL;
+
if (!address_ok(regs, ea & ~0xfUL, 16))
return -EFAULT;
/* align to multiple of size */
@@ -707,6 +710,9 @@ static nokprobe_inline int do_vec_store(int rn, unsigned
long ea,
u8 b[sizeof(__vector128)];
} u;
+ if (WARN_ON_ONCE(size > sizeof(u)))
+ return -EINVAL;
+
if (!address_ok(regs, ea & ~0xfUL, 16))
return -EFAULT;
/* align to multiple of size */
- Naveen
Re: Potential config regression after 89cde455 ("kexec: consolidate kexec and crash options into kernel/Kconfig.kexec")
On 11/21/23 at 07:53am, Ignat Korchagin wrote:
> On Tue, Nov 21, 2023 at 1:50 AM Baoquan He wrote:
> >
> > Eric DeVolder's Oracle mail address is not available anymore, add his
> > current mail address he told me.
>
> Thank you!
>
> > On 11/20/23 at 10:52pm, Ignat Korchagin wrote:
> > > Good day!
> > >
> > > We have recently started to evaluate Linux 6.6 and noticed that we
> > > cannot disable CONFIG_KEXEC anymore, but keep CONFIG_CRASH_DUMP
> > > enabled. It seems to be related to commit 89cde455 ("kexec:
> > > consolidate kexec and crash options into kernel/Kconfig.kexec"), where
> > > a CONFIG_KEXEC dependency was added to CONFIG_CRASH_DUMP.
> > >
> > > In our current kernel (Linux 6.1) we only enable CONFIG_KEXEC_FILE
> > > with enforced signature check to support the kernel crash dumping
> > > functionality and would like to keep CONFIG_KEXEC disabled for
> > > security reasons [1].
> > >
> > > I was reading the long commit message, but the reason for adding
> > > CONFIG_KEXEC as a dependency for CONFIG_CRASH_DUMP evaded me. And I
> > > believe from the implementation perspective CONFIG_KEXEC_FILE should
> > > suffice here (as we successfully used it for crashdumps on Linux 6.1).
> > >
> > > Is there a reason for adding this dependency or is it just an
> > > oversight? Would some solution of requiring either CONFIG_KEXEC or
> > > CONFIG_KEXEC_FILE work here?
> >
> > I searched the patch history, found Eric didn't add the dependency on
> > CONFIG_KEXEC at the beginning. Later a linux-next building failure with
> > randconfig was reported, in there CONFIG_CRASH_DUMP enabled, while
> > CONFIG_KEXEC is disabled. Finally Eric added the KEXEC dependency for
> > CRASH_DUMP. Please see below link for more details:
> >
> > https://lore.kernel.org/all/3e8eecd1-a277-2cfb-690e-5de2eb7b9...@oracle.com/T/#u
>
> Thank you for digging this up. However I'm still confused, because
> this is exactly how we configure Linux 6.1 (although we do have
> CONFIG_KEXEC_FILE enabled) and we don't have any problems. I believe
> we did not investigate this issue properly.
>
> > And besides, the newly added CONFIG_CRASH_HOTPLUG also needs
> > CONFIG_KEXEC if the elfcorehdr is allowed to be manipulated when
> > cpu/memory hotplug hapened.
>
> This still feels like a regression to me: any crash dump support
> should be independent of KEXEC syscalls being present. While probably
> the common case (including us) that the crashing kernel and recovery
> kernel are the same, they don't have to be. We need kexec syscall in
> the crashing kernel, but crashdump support in the recovery kernel (but
> the recovery kernel not having the kexec syscalls should be totally
> fine). If we do require some code definitions from kexec - at most we
> should put them under CONFIG_KEXEC_CORE.
Hmm, I understand your concern. Will wait for Eric a while to see if he
has any explannation or plan, otherwise I will check this.
Re: Potential config regression after 89cde455 ("kexec: consolidate kexec and crash options into kernel/Kconfig.kexec")
On Tue, Nov 21, 2023 at 7:53 AM Ignat Korchagin wrote:
>
> On Tue, Nov 21, 2023 at 1:50 AM Baoquan He wrote:
> >
> > Eric DeVolder's Oracle mail address is not available anymore, add his
> > current mail address he told me.
>
> Thank you!
>
> > On 11/20/23 at 10:52pm, Ignat Korchagin wrote:
> > > Good day!
> > >
> > > We have recently started to evaluate Linux 6.6 and noticed that we
> > > cannot disable CONFIG_KEXEC anymore, but keep CONFIG_CRASH_DUMP
> > > enabled. It seems to be related to commit 89cde455 ("kexec:
> > > consolidate kexec and crash options into kernel/Kconfig.kexec"), where
> > > a CONFIG_KEXEC dependency was added to CONFIG_CRASH_DUMP.
> > >
> > > In our current kernel (Linux 6.1) we only enable CONFIG_KEXEC_FILE
> > > with enforced signature check to support the kernel crash dumping
> > > functionality and would like to keep CONFIG_KEXEC disabled for
> > > security reasons [1].
> > >
> > > I was reading the long commit message, but the reason for adding
> > > CONFIG_KEXEC as a dependency for CONFIG_CRASH_DUMP evaded me. And I
> > > believe from the implementation perspective CONFIG_KEXEC_FILE should
> > > suffice here (as we successfully used it for crashdumps on Linux 6.1).
> > >
> > > Is there a reason for adding this dependency or is it just an
> > > oversight? Would some solution of requiring either CONFIG_KEXEC or
> > > CONFIG_KEXEC_FILE work here?
> >
> > I searched the patch history, found Eric didn't add the dependency on
> > CONFIG_KEXEC at the beginning. Later a linux-next building failure with
> > randconfig was reported, in there CONFIG_CRASH_DUMP enabled, while
> > CONFIG_KEXEC is disabled. Finally Eric added the KEXEC dependency for
> > CRASH_DUMP. Please see below link for more details:
> >
> > https://lore.kernel.org/all/3e8eecd1-a277-2cfb-690e-5de2eb7b9...@oracle.com/T/#u
>
> Thank you for digging this up. However I'm still confused, because
> this is exactly how we configure Linux 6.1 (although we do have
> CONFIG_KEXEC_FILE enabled) and we don't have any problems. I believe
> we did not investigate this issue properly.
I did some preliminary investigation for this. If I patch out the
dependency on CONFIG_KEXEC the kernel builds just fine for x86
(without CONFIG_CRASH_HOTPLUG - which is probably another issue) - so
this was the previous behaviour. I can see that the reported error is
for arm architecture and was able to reproduce it with a simple cross
compiler in Debian. However, I think it is still somehow related to
this patchset as the previous kernels (up to 6.5) build fine with just
CONFIG_CRASH_DUMP and without CONFIG_KEXEC for arm as well. So even
for arm it was introduced in 6.6.
> > And besides, the newly added CONFIG_CRASH_HOTPLUG also needs
> > CONFIG_KEXEC if the elfcorehdr is allowed to be manipulated when
> > cpu/memory hotplug hapened.
>
> This still feels like a regression to me: any crash dump support
> should be independent of KEXEC syscalls being present. While probably
> the common case (including us) that the crashing kernel and recovery
> kernel are the same, they don't have to be. We need kexec syscall in
> the crashing kernel, but crashdump support in the recovery kernel (but
> the recovery kernel not having the kexec syscalls should be totally
> fine). If we do require some code definitions from kexec - at most we
> should put them under CONFIG_KEXEC_CORE.
>
> > Thanks
> > Baoquan
> >
Ignat
Re: [PATCH v10 00/14] Add audio support in v4l2 framework
On 11/21/23 11:03, Shengjiu Wang wrote:
> On Tue, Nov 21, 2023 at 5:22 PM Hans Verkuil wrote:
>>
>> On 21/11/2023 08:37, Shengjiu Wang wrote:
>>> Audio signal processing also has the requirement for memory to
>>> memory similar as Video.
>>>
>>> This asrc memory to memory (memory ->asrc->memory) case is a non
>>> real time use case.
>>>
>>> User fills the input buffer to the asrc module, after conversion, then asrc
>>> sends back the output buffer to user. So it is not a traditional ALSA
>>> playback
>>> and capture case.
>>>
>>> It is a specific use case, there is no reference in current kernel.
>>> v4l2 memory to memory is the closed implementation, v4l2 current
>>> support video, image, radio, tuner, touch devices, so it is not
>>> complicated to add support for this specific audio case.
>>>
>>> Because we had implemented the "memory -> asrc ->i2s device-> codec"
>>> use case in ALSA. Now the "memory->asrc->memory" needs
>>> to reuse the code in asrc driver, so the first 3 patches is for refining
>>> the code to make it can be shared by the "memory->asrc->memory"
>>> driver.
>>>
>>> The main change is in the v4l2 side, A /dev/vl4-audioX will be created,
>>> user applications only use the ioctl of v4l2 framework.
>>>
>>> Other change is to add memory to memory support for two kinds of i.MX ASRC
>>> module.
>>>
>>> changes in v10
>>> - remove FIXED_POINT type
>>> - change code base on media: v4l2-ctrls: add support for fraction_bits
>>> - fix issue reported by kernel test robot
>>> - remove module_alias
>>
>> Note that I still need a patch for vivid adding a fixed point test control.
>>
>> I think I want two controls: one INTEGER Q16 and one INTEGER64 Q63 (a nice
>> corner case).
>>
>
> Not sure if we can do like this:
>
> diff --git a/drivers/media/test-drivers/vivid/vivid-core.h
> b/drivers/media/test-drivers/vivid/vivid-core.h
> index cfb8e66083f6..def8cf6c30c1 100644
> --- a/drivers/media/test-drivers/vivid/vivid-core.h
> +++ b/drivers/media/test-drivers/vivid/vivid-core.h
> @@ -222,6 +222,8 @@ struct vivid_dev {
> struct v4l2_ctrl*boolean;
> struct v4l2_ctrl*int32;
> struct v4l2_ctrl*int64;
> + struct v4l2_ctrl*int32Q16;
I would call this int32_q16. This to avoid checkpatch CamelCase warnings.
> + struct v4l2_ctrl*int64Q63;
ditto
> struct v4l2_ctrl*menu;
> struct v4l2_ctrl*string;
> struct v4l2_ctrl*bitmask;
> diff --git a/drivers/media/test-drivers/vivid/vivid-ctrls.c
> b/drivers/media/test-drivers/vivid/vivid-ctrls.c
> index f2b20e25a7a4..c912b6776775 100644
> --- a/drivers/media/test-drivers/vivid/vivid-ctrls.c
> +++ b/drivers/media/test-drivers/vivid/vivid-ctrls.c
> @@ -182,6 +182,28 @@ static const struct v4l2_ctrl_config vivid_ctrl_int64 = {
> .step = 1,
> };
>
> +static const struct v4l2_ctrl_config vivid_ctrl_int32Q16 = {
> + .ops = _user_gen_ctrl_ops,
> + .id = VIVID_CID_INTEGER,
You need to add new CIDs. E.g. VIVID_CID_INT_Q4_16.
> + .name = "Integer 32 Bits Q16",
Q4.16
> + .type = V4L2_CTRL_TYPE_INTEGER,
> + .min = 0x8000ULL,
Let's make this a Q4.16 integer.
I think it is worth adding this to the v4l2-ctrls.h header:
#define v4l2_ctrl_fp_compose(i, f, fraction_bits) \
(((i) << fraction_bits) + (f))
Then you can do:
.min = v4l2_ctrl_fp_compose(-16, 0),
.max = v4l2_ctrl_fp_compose(15, 0x),
> + .max = 0x7fff,
> + .step = 1,
> + .fraction_bits = 16,
> +};
> +
> +static const struct v4l2_ctrl_config vivid_ctrl_int64Q63 = {
> + .ops = _user_gen_ctrl_ops,
> + .id = VIVID_CID_INTEGER64,
> + .name = "Integer 64 Bits Q63",
> + .type = V4L2_CTRL_TYPE_INTEGER64,
> + .min = 0x8000ULL,
> + .max = 0x7fffLL,
.min = v4l2_ctrl_fp_compose(-1, 0),
.max = v4l2_ctrl_fp_compose(0, LLONG_MAX),
> + .step = 1,
> + .fraction_bits = 63,
> +};
Looks good otherwise.
The purpose is that v4l2-compliance can test such control types using a
hw emulation driver like vivid.
Regards,
Hans
> +
> static const struct v4l2_ctrl_config vivid_ctrl_u32_array = {
> .ops = _user_gen_ctrl_ops,
> .id = VIVID_CID_U32_ARRAY,
> @@ -1670,6 +1692,8 @@ int vivid_create_controls(struct vivid_dev *dev,
> bool show_ccs_cap,
> dev->button = v4l2_ctrl_new_custom(hdl_user_gen,
> _ctrl_button, NULL);
> dev->int32 = v4l2_ctrl_new_custom(hdl_user_gen,
> _ctrl_int32, NULL);
> dev->int64 = v4l2_ctrl_new_custom(hdl_user_gen,
> _ctrl_int64, NULL);
> + dev->int32Q16 = v4l2_ctrl_new_custom(hdl_user_gen,
> _ctrl_int32Q16, NULL);
> + dev->int64Q63 = v4l2_ctrl_new_custom(hdl_user_gen,
> _ctrl_int64Q63, NULL);
> dev->boolean = v4l2_ctrl_new_custom(hdl_user_gen,
> _ctrl_boolean, NULL);
>
Re: [PATCH v10 13/14] media: imx-asrc: Add memory to memory driver
On Tue, Nov 21, 2023 at 5:20 PM Hans Verkuil wrote:
>
> On 21/11/2023 08:37, Shengjiu Wang wrote:
> > Implement the ASRC memory to memory function using
> > the v4l2 framework, user can use this function with
> > v4l2 ioctl interface.
> >
> > User send the output and capture buffer to driver and
> > driver store the converted data to the capture buffer.
> >
> > This feature can be shared by ASRC and EASRC drivers
> >
> > Signed-off-by: Shengjiu Wang
> > ---
> > drivers/media/platform/nxp/Kconfig| 13 +
> > drivers/media/platform/nxp/Makefile |1 +
> > drivers/media/platform/nxp/imx-asrc.c | 1264 +
> > 3 files changed, 1278 insertions(+)
> > create mode 100644 drivers/media/platform/nxp/imx-asrc.c
> >
>
>
>
> > +static const struct v4l2_ctrl_config asrc_src_rate_off_control = {
> > + .ops = _m2m_ctrl_ops,
> > + .id = V4L2_CID_M2M_AUDIO_SOURCE_RATE_OFFSET,
> > + .name = "Audio Source Sample Rate Offset",
> > + .type = V4L2_CTRL_TYPE_INTEGER64,
>
> Do you need this to be INTEGER64? If the actual number of bits
> of the fixed point value that the hardware uses fits in 32 bits,
> then you can just use the INTEGER type.
>
> > + .min = 0xFF00,
> > + .max = 0x7f,
> > + .def = 0,
> > + .step = 1,
> > + .flags = V4L2_CTRL_FLAG_UPDATE,
> > + .fraction_bits = 32,
>
> Can't you use the actual number of fraction bits that the hardware
> uses? I can't imagine that it is actually 32 bits, it is almost
> certainly less.
>
>From the ratio point view, it is 44bits. maximum 39 fractional bits.
> I do think that we need a helper function to fill in the min/max values.
what's the helper function look like? Where can I find an example?
best regards
wang shengjiu
>
> Regards,
>
> Hans
>
> > +};
> > +
> > +static const struct v4l2_ctrl_config asrc_dst_rate_off_control = {
> > + .ops = _m2m_ctrl_ops,
> > + .id = V4L2_CID_M2M_AUDIO_DEST_RATE_OFFSET,
> > + .name = "Audio Dest Sample Rate Offset",
> > + .type = V4L2_CTRL_TYPE_INTEGER64,
> > + .min = 0xFF00,
> > + .max = 0x7f,
> > + .def = 0,
> > + .step = 1,
> > + .flags = V4L2_CTRL_FLAG_UPDATE,
> > + .fraction_bits = 32,
> > +};
>
Re: [PATCH v10 00/14] Add audio support in v4l2 framework
On Tue, Nov 21, 2023 at 5:22 PM Hans Verkuil wrote:
>
> On 21/11/2023 08:37, Shengjiu Wang wrote:
> > Audio signal processing also has the requirement for memory to
> > memory similar as Video.
> >
> > This asrc memory to memory (memory ->asrc->memory) case is a non
> > real time use case.
> >
> > User fills the input buffer to the asrc module, after conversion, then asrc
> > sends back the output buffer to user. So it is not a traditional ALSA
> > playback
> > and capture case.
> >
> > It is a specific use case, there is no reference in current kernel.
> > v4l2 memory to memory is the closed implementation, v4l2 current
> > support video, image, radio, tuner, touch devices, so it is not
> > complicated to add support for this specific audio case.
> >
> > Because we had implemented the "memory -> asrc ->i2s device-> codec"
> > use case in ALSA. Now the "memory->asrc->memory" needs
> > to reuse the code in asrc driver, so the first 3 patches is for refining
> > the code to make it can be shared by the "memory->asrc->memory"
> > driver.
> >
> > The main change is in the v4l2 side, A /dev/vl4-audioX will be created,
> > user applications only use the ioctl of v4l2 framework.
> >
> > Other change is to add memory to memory support for two kinds of i.MX ASRC
> > module.
> >
> > changes in v10
> > - remove FIXED_POINT type
> > - change code base on media: v4l2-ctrls: add support for fraction_bits
> > - fix issue reported by kernel test robot
> > - remove module_alias
>
> Note that I still need a patch for vivid adding a fixed point test control.
>
> I think I want two controls: one INTEGER Q16 and one INTEGER64 Q63 (a nice
> corner case).
>
Not sure if we can do like this:
diff --git a/drivers/media/test-drivers/vivid/vivid-core.h
b/drivers/media/test-drivers/vivid/vivid-core.h
index cfb8e66083f6..def8cf6c30c1 100644
--- a/drivers/media/test-drivers/vivid/vivid-core.h
+++ b/drivers/media/test-drivers/vivid/vivid-core.h
@@ -222,6 +222,8 @@ struct vivid_dev {
struct v4l2_ctrl*boolean;
struct v4l2_ctrl*int32;
struct v4l2_ctrl*int64;
+ struct v4l2_ctrl*int32Q16;
+ struct v4l2_ctrl*int64Q63;
struct v4l2_ctrl*menu;
struct v4l2_ctrl*string;
struct v4l2_ctrl*bitmask;
diff --git a/drivers/media/test-drivers/vivid/vivid-ctrls.c
b/drivers/media/test-drivers/vivid/vivid-ctrls.c
index f2b20e25a7a4..c912b6776775 100644
--- a/drivers/media/test-drivers/vivid/vivid-ctrls.c
+++ b/drivers/media/test-drivers/vivid/vivid-ctrls.c
@@ -182,6 +182,28 @@ static const struct v4l2_ctrl_config vivid_ctrl_int64 = {
.step = 1,
};
+static const struct v4l2_ctrl_config vivid_ctrl_int32Q16 = {
+ .ops = _user_gen_ctrl_ops,
+ .id = VIVID_CID_INTEGER,
+ .name = "Integer 32 Bits Q16",
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .min = 0x8000ULL,
+ .max = 0x7fff,
+ .step = 1,
+ .fraction_bits = 16,
+};
+
+static const struct v4l2_ctrl_config vivid_ctrl_int64Q63 = {
+ .ops = _user_gen_ctrl_ops,
+ .id = VIVID_CID_INTEGER64,
+ .name = "Integer 64 Bits Q63",
+ .type = V4L2_CTRL_TYPE_INTEGER64,
+ .min = 0x8000ULL,
+ .max = 0x7fffLL,
+ .step = 1,
+ .fraction_bits = 63,
+};
+
static const struct v4l2_ctrl_config vivid_ctrl_u32_array = {
.ops = _user_gen_ctrl_ops,
.id = VIVID_CID_U32_ARRAY,
@@ -1670,6 +1692,8 @@ int vivid_create_controls(struct vivid_dev *dev,
bool show_ccs_cap,
dev->button = v4l2_ctrl_new_custom(hdl_user_gen,
_ctrl_button, NULL);
dev->int32 = v4l2_ctrl_new_custom(hdl_user_gen,
_ctrl_int32, NULL);
dev->int64 = v4l2_ctrl_new_custom(hdl_user_gen,
_ctrl_int64, NULL);
+ dev->int32Q16 = v4l2_ctrl_new_custom(hdl_user_gen,
_ctrl_int32Q16, NULL);
+ dev->int64Q63 = v4l2_ctrl_new_custom(hdl_user_gen,
_ctrl_int64Q63, NULL);
dev->boolean = v4l2_ctrl_new_custom(hdl_user_gen,
_ctrl_boolean, NULL);
dev->menu = v4l2_ctrl_new_custom(hdl_user_gen, _ctrl_menu, NULL);
dev->string = v4l2_ctrl_new_custom(hdl_user_gen,
_ctrl_string, NULL);
(END)
> Regards,
>
> Hans
>
> >
> > changes in v9:
> > - add MEDIA_ENT_F_PROC_AUDIO_RESAMPLER.
> > - add MEDIA_INTF_T_V4L_AUDIO
> > - add media controller support
> > - refine the vim2m-audio to support 8k<->16k conversion.
> >
> > changes in v8:
> > - refine V4L2_CAP_AUDIO_M2M to be 0x0008
> > - update doc for FIXED_POINT
> > - address comments for imx-asrc
> >
> > changes in v7:
> > - add acked-by from Mark
> > - separate commit for fixed point, m2m audio class, audio rate controls
> > - use INTEGER_MENU for rate, FIXED_POINT for rate offset
> > - remove used fmts
> > - address other comments for Hans
> >
> > changes in v6:
> > - use m2m_prepare/m2m_unprepare/m2m_start/m2m_stop to replace
> >
Re: [PATCH] powerpc: add crtsavres.o to always-y instead of extra-y
"Nicholas Piggin" writes:
> On Tue Nov 21, 2023 at 9:23 AM AEST, Masahiro Yamada wrote:
>> crtsavres.o is linked to modules. However, as explained in commit
>> d0e628cd817f ("kbuild: doc: clarify the difference between extra-y
>> and always-y"), 'make modules' does not build extra-y.
>>
>> For example, the following command fails:
>>
>> $ make ARCH=powerpc LLVM=1 KBUILD_MODPOST_WARN=1 mrproper ps3_defconfig
>> modules
>> [snip]
>> LD [M] arch/powerpc/platforms/cell/spufs/spufs.ko
>> ld.lld: error: cannot open arch/powerpc/lib/crtsavres.o: No such file or
>> directory
>> make[3]: *** [scripts/Makefile.modfinal:56:
>> arch/powerpc/platforms/cell/spufs/spufs.ko] Error 1
>> make[2]: *** [Makefile:1844: modules] Error 2
>> make[1]: *** [/home/masahiro/workspace/linux-kbuild/Makefile:350:
>> __build_one_by_one] Error 2
>> make: *** [Makefile:234: __sub-make] Error 2
>>
>
> Thanks. Is this the correct Fixes tag?
>
> Fixes: d0e628cd817f ("powerpc/64: Do not link crtsavres.o in vmlinux")
>
I am finding a different commit ID:
commit baa25b571a168aff5a13bfdc973f1229e2b12b63
Author: Nicholas Piggin
Date: Fri May 12 01:56:49 2017 +1000
powerpc/64: Do not link crtsavres.o in vmlinux
The 64-bit linker creates save/restore functions on demand with final
links, so vmlinux does not require crtsavres.o.
-aneesh
[PATCH 11/17] tty: hvc_console: use flexible array for outbuf
This means:
* move outbuf to the end of struct hvc_struct and convert from pointer
to flexible array (the structure is smaller now)
* use struct_size() at the allocation site
* align outbuf in the struct instead of ALIGN() at kzalloc()
And apart from the above, use u8 instead of char (which are the same
thanks to -funsigned-char). The former is now preferred over the latter.
It makes the code easier to understand.
Signed-off-by: Jiri Slaby (SUSE)
Cc: linuxppc-dev@lists.ozlabs.org
---
drivers/tty/hvc/hvc_console.c | 4 +---
drivers/tty/hvc/hvc_console.h | 2 +-
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 959fae54ca39..93b613e1f176 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -922,8 +922,7 @@ struct hvc_struct *hvc_alloc(uint32_t vtermno, int data,
return ERR_PTR(err);
}
- hp = kzalloc(ALIGN(sizeof(*hp), sizeof(long)) + outbuf_size,
- GFP_KERNEL);
+ hp = kzalloc(struct_size(hp, outbuf, outbuf_size), GFP_KERNEL);
if (!hp)
return ERR_PTR(-ENOMEM);
@@ -931,7 +930,6 @@ struct hvc_struct *hvc_alloc(uint32_t vtermno, int data,
hp->data = data;
hp->ops = ops;
hp->outbuf_size = outbuf_size;
- hp->outbuf = &((char *)hp)[ALIGN(sizeof(*hp), sizeof(long))];
tty_port_init(>port);
hp->port.ops = _port_ops;
diff --git a/drivers/tty/hvc/hvc_console.h b/drivers/tty/hvc/hvc_console.h
index 9668f821db01..b718714bf399 100644
--- a/drivers/tty/hvc/hvc_console.h
+++ b/drivers/tty/hvc/hvc_console.h
@@ -37,7 +37,6 @@ struct hvc_struct {
spinlock_t lock;
int index;
int do_wakeup;
- char *outbuf;
int outbuf_size;
int n_outbuf;
uint32_t vtermno;
@@ -48,6 +47,7 @@ struct hvc_struct {
struct work_struct tty_resize;
struct list_head next;
unsigned long flags;
+ u8 outbuf[] __aligned(sizeof(long));
};
/* implemented by a low level driver */
--
2.42.1
[PATCH 07/17] tty: ehv_bytecha: use memcpy_and_pad() in local_ev_byte_channel_send()
There is a helper for memcpy(buffer)+memset(the_rest). Use it for
simplicity.
And add a comment why we are doing the copy in the first place.
Signed-off-by: Jiri Slaby (SUSE)
Cc: Laurentiu Tudor
Cc: linuxppc-dev@lists.ozlabs.org
---
drivers/tty/ehv_bytechan.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/ehv_bytechan.c b/drivers/tty/ehv_bytechan.c
index a067628e01c8..cc9f4338da60 100644
--- a/drivers/tty/ehv_bytechan.c
+++ b/drivers/tty/ehv_bytechan.c
@@ -143,9 +143,12 @@ static unsigned int local_ev_byte_channel_send(unsigned
int handle,
char buffer[EV_BYTE_CHANNEL_MAX_BYTES];
unsigned int c = *count;
+ /*
+* ev_byte_channel_send() expects at least EV_BYTE_CHANNEL_MAX_BYTES
+* (16 B) in the buffer. Fake it using a local buffer if needed.
+*/
if (c < sizeof(buffer)) {
- memcpy(buffer, p, c);
- memset([c], 0, sizeof(buffer) - c);
+ memcpy_and_pad(buffer, sizeof(buffer), p, c, 0);
p = buffer;
}
return ev_byte_channel_send(handle, count, p);
--
2.42.1
[PATCH 00/17] tty: small cleanups and fixes
This is a series to fix/clean up some obvious issues I revealed during u8+size_t conversions (to be posted later). Cc: "David S. Miller" Cc: Eric Dumazet Cc: Ivan Kokshaysky Cc: Jakub Kicinski Cc: Jan Kara Cc: Laurentiu Tudor Cc: linux-al...@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-...@vger.kernel.org Cc: Matt Turner Cc: net...@vger.kernel.org Cc: Paolo Abeni Cc: Richard Henderson Jiri Slaby (SUSE) (17): tty: deprecate tty_write_message() tty: remove unneeded mbz from tiocsti() tty: fix tty_operations types in documentation tty: move locking docs out of Returns for functions in tty.h tty: amiserial: return from receive_chars() without goto tty: amiserial: use bool and rename overrun flag in receive_chars() tty: ehv_bytecha: use memcpy_and_pad() in local_ev_byte_channel_send() tty: goldfish: drop unneeded temporary variables tty: hso: don't emit load/unload info to the log tty: hso: don't initialize global serial_table tty: hvc_console: use flexible array for outbuf tty: nozomi: remove unused debugging DUMP() tty: srmcons: use 'buf' directly in srmcons_do_write() tty: srmcons: use 'count' directly in srmcons_do_write() tty: srmcons: make srmcons_do_write() return void tty: srmcons: switch need_cr to bool tty: srmcons: make 'str_cr' const and non-array arch/alpha/kernel/srmcons.c | 29 + drivers/net/usb/hso.c | 11 --- drivers/tty/amiserial.c | 10 -- drivers/tty/ehv_bytechan.c| 7 +-- drivers/tty/goldfish.c| 7 ++- drivers/tty/hvc/hvc_console.c | 4 +--- drivers/tty/hvc/hvc_console.h | 2 +- drivers/tty/nozomi.c | 18 -- drivers/tty/tty_io.c | 8 ++-- include/linux/tty.h | 12 +++- include/linux/tty_driver.h| 5 ++--- 11 files changed, 41 insertions(+), 72 deletions(-) -- 2.42.1
Re: [PATCH v10 00/14] Add audio support in v4l2 framework
On 21/11/2023 08:37, Shengjiu Wang wrote: > Audio signal processing also has the requirement for memory to > memory similar as Video. > > This asrc memory to memory (memory ->asrc->memory) case is a non > real time use case. > > User fills the input buffer to the asrc module, after conversion, then asrc > sends back the output buffer to user. So it is not a traditional ALSA playback > and capture case. > > It is a specific use case, there is no reference in current kernel. > v4l2 memory to memory is the closed implementation, v4l2 current > support video, image, radio, tuner, touch devices, so it is not > complicated to add support for this specific audio case. > > Because we had implemented the "memory -> asrc ->i2s device-> codec" > use case in ALSA. Now the "memory->asrc->memory" needs > to reuse the code in asrc driver, so the first 3 patches is for refining > the code to make it can be shared by the "memory->asrc->memory" > driver. > > The main change is in the v4l2 side, A /dev/vl4-audioX will be created, > user applications only use the ioctl of v4l2 framework. > > Other change is to add memory to memory support for two kinds of i.MX ASRC > module. > > changes in v10 > - remove FIXED_POINT type > - change code base on media: v4l2-ctrls: add support for fraction_bits > - fix issue reported by kernel test robot > - remove module_alias Note that I still need a patch for vivid adding a fixed point test control. I think I want two controls: one INTEGER Q16 and one INTEGER64 Q63 (a nice corner case). Regards, Hans > > changes in v9: > - add MEDIA_ENT_F_PROC_AUDIO_RESAMPLER. > - add MEDIA_INTF_T_V4L_AUDIO > - add media controller support > - refine the vim2m-audio to support 8k<->16k conversion. > > changes in v8: > - refine V4L2_CAP_AUDIO_M2M to be 0x0008 > - update doc for FIXED_POINT > - address comments for imx-asrc > > changes in v7: > - add acked-by from Mark > - separate commit for fixed point, m2m audio class, audio rate controls > - use INTEGER_MENU for rate, FIXED_POINT for rate offset > - remove used fmts > - address other comments for Hans > > changes in v6: > - use m2m_prepare/m2m_unprepare/m2m_start/m2m_stop to replace > m2m_start_part_one/m2m_stop_part_one, m2m_start_part_two/m2m_stop_part_two. > - change V4L2_CTRL_TYPE_ASRC_RATE to V4L2_CTRL_TYPE_FIXED_POINT > - fix warning by kernel test rebot > - remove some unused format V4L2_AUDIO_FMT_XX > - Get SNDRV_PCM_FORMAT from V4L2_AUDIO_FMT in driver. > - rename audm2m to viaudm2m. > > changes in v5: > - remove V4L2_AUDIO_FMT_LPCM > - define audio pixel format like V4L2_AUDIO_FMT_S8... > - remove rate and format in struct v4l2_audio_format. > - Add V4L2_CID_ASRC_SOURCE_RATE and V4L2_CID_ASRC_DEST_RATE controls > - updata document accordingly. > > changes in v4: > - update document style > - separate V4L2_AUDIO_FMT_LPCM and V4L2_CAP_AUDIO_M2M in separate commit > > changes in v3: > - Modify documents for adding audio m2m support > - Add audio virtual m2m driver > - Defined V4L2_AUDIO_FMT_LPCM format type for audio. > - Defined V4L2_CAP_AUDIO_M2M capability type for audio m2m case. > - with modification in v4l-utils, pass v4l2-compliance test. > > changes in v2: > - decouple the implementation in v4l2 and ALSA > - implement the memory to memory driver as a platfrom driver > and move it to driver/media > - move fsl_asrc_common.h to include/sound folder > > Shengjiu Wang (14): > ASoC: fsl_asrc: define functions for memory to memory usage > ASoC: fsl_easrc: define functions for memory to memory usage > ASoC: fsl_asrc: move fsl_asrc_common.h to include/sound > ASoC: fsl_asrc: register m2m platform device > ASoC: fsl_easrc: register m2m platform device > media: uapi: Add V4L2_CAP_AUDIO_M2M capability flag > media: v4l2: Add audio capture and output support > media: uapi: Define audio sample format fourcc type > media: uapi: Add V4L2_CTRL_CLASS_M2M_AUDIO > media: uapi: Add audio rate controls support > media: uapi: Declare interface types for Audio > media: uapi: Add an entity type for audio resampler > media: imx-asrc: Add memory to memory driver > media: vim2m-audio: add virtual driver for audio memory to memory > > .../media/mediactl/media-types.rst| 11 + > .../userspace-api/media/v4l/buffer.rst|6 + > .../userspace-api/media/v4l/common.rst|1 + > .../media/v4l/dev-audio-mem2mem.rst | 71 + > .../userspace-api/media/v4l/devices.rst |1 + > .../media/v4l/ext-ctrls-audio-m2m.rst | 41 + > .../userspace-api/media/v4l/pixfmt-audio.rst | 87 ++ > .../userspace-api/media/v4l/pixfmt.rst|1 + > .../media/v4l/vidioc-enum-fmt.rst |2 + > .../media/v4l/vidioc-g-ext-ctrls.rst |4 + > .../userspace-api/media/v4l/vidioc-g-fmt.rst |4 + > .../media/v4l/vidioc-querycap.rst |3 + > .../media/videodev2.h.rst.exceptions |3 + >
Re: [PATCH v10 13/14] media: imx-asrc: Add memory to memory driver
On 21/11/2023 08:37, Shengjiu Wang wrote:
> Implement the ASRC memory to memory function using
> the v4l2 framework, user can use this function with
> v4l2 ioctl interface.
>
> User send the output and capture buffer to driver and
> driver store the converted data to the capture buffer.
>
> This feature can be shared by ASRC and EASRC drivers
>
> Signed-off-by: Shengjiu Wang
> ---
> drivers/media/platform/nxp/Kconfig| 13 +
> drivers/media/platform/nxp/Makefile |1 +
> drivers/media/platform/nxp/imx-asrc.c | 1264 +
> 3 files changed, 1278 insertions(+)
> create mode 100644 drivers/media/platform/nxp/imx-asrc.c
>
> +static const struct v4l2_ctrl_config asrc_src_rate_off_control = {
> + .ops = _m2m_ctrl_ops,
> + .id = V4L2_CID_M2M_AUDIO_SOURCE_RATE_OFFSET,
> + .name = "Audio Source Sample Rate Offset",
> + .type = V4L2_CTRL_TYPE_INTEGER64,
Do you need this to be INTEGER64? If the actual number of bits
of the fixed point value that the hardware uses fits in 32 bits,
then you can just use the INTEGER type.
> + .min = 0xFF00,
> + .max = 0x7f,
> + .def = 0,
> + .step = 1,
> + .flags = V4L2_CTRL_FLAG_UPDATE,
> + .fraction_bits = 32,
Can't you use the actual number of fraction bits that the hardware
uses? I can't imagine that it is actually 32 bits, it is almost
certainly less.
I do think that we need a helper function to fill in the min/max values.
Regards,
Hans
> +};
> +
> +static const struct v4l2_ctrl_config asrc_dst_rate_off_control = {
> + .ops = _m2m_ctrl_ops,
> + .id = V4L2_CID_M2M_AUDIO_DEST_RATE_OFFSET,
> + .name = "Audio Dest Sample Rate Offset",
> + .type = V4L2_CTRL_TYPE_INTEGER64,
> + .min = 0xFF00,
> + .max = 0x7f,
> + .def = 0,
> + .step = 1,
> + .flags = V4L2_CTRL_FLAG_UPDATE,
> + .fraction_bits = 32,
> +};
Re: [PATCH v4 4/5] tty: Add SBI debug console support to HVC SBI driver
On Sun, Nov 19, 2023 at 11:16 PM Jiri Slaby wrote:
>
> On 18. 11. 23, 4:38, Anup Patel wrote:
> > diff --git a/drivers/tty/hvc/hvc_riscv_sbi.c
> > b/drivers/tty/hvc/hvc_riscv_sbi.c
> > index 31f53fa77e4a..697c981221b5 100644
> > --- a/drivers/tty/hvc/hvc_riscv_sbi.c
> > +++ b/drivers/tty/hvc/hvc_riscv_sbi.c
> ...
> > -static int __init hvc_sbi_console_init(void)
> > +static int hvc_sbi_dbcn_tty_get(uint32_t vtermno, char *buf, int count)
> > {
> > - hvc_instantiate(0, 0, _sbi_ops);
> > + phys_addr_t pa;
> > +
> > + if (is_vmalloc_addr(buf)) {
>
> I wonder, where does this buf come from, so that you have to check for
> vmalloc?
>
When VMAP_STCK is enabled, stack allocation depends on the vmalloc.
That's why we have to if the buf is allocated using vmalloc.
> > + pa = page_to_phys(vmalloc_to_page(buf)) + offset_in_page(buf);
> > + if (PAGE_SIZE < (offset_in_page(buf) + count))
>
> Am I the only one who would prefer:
>if (count + offset_in_page(buf) > PAGE_SIZE)
> ?
>
> > + count = PAGE_SIZE - offset_in_page(buf);
> > + } else {
> > + pa = __pa(buf);
> > + }
> > +
> > + return sbi_debug_console_read(count, pa);
> > +}
>
>
> thanks,
> --
> js
> suse labs
>
Re: Potential config regression after 89cde455 ("kexec: consolidate kexec and crash options into kernel/Kconfig.kexec")
On Tue, Nov 21, 2023 at 1:50 AM Baoquan He wrote:
>
> Eric DeVolder's Oracle mail address is not available anymore, add his
> current mail address he told me.
Thank you!
> On 11/20/23 at 10:52pm, Ignat Korchagin wrote:
> > Good day!
> >
> > We have recently started to evaluate Linux 6.6 and noticed that we
> > cannot disable CONFIG_KEXEC anymore, but keep CONFIG_CRASH_DUMP
> > enabled. It seems to be related to commit 89cde455 ("kexec:
> > consolidate kexec and crash options into kernel/Kconfig.kexec"), where
> > a CONFIG_KEXEC dependency was added to CONFIG_CRASH_DUMP.
> >
> > In our current kernel (Linux 6.1) we only enable CONFIG_KEXEC_FILE
> > with enforced signature check to support the kernel crash dumping
> > functionality and would like to keep CONFIG_KEXEC disabled for
> > security reasons [1].
> >
> > I was reading the long commit message, but the reason for adding
> > CONFIG_KEXEC as a dependency for CONFIG_CRASH_DUMP evaded me. And I
> > believe from the implementation perspective CONFIG_KEXEC_FILE should
> > suffice here (as we successfully used it for crashdumps on Linux 6.1).
> >
> > Is there a reason for adding this dependency or is it just an
> > oversight? Would some solution of requiring either CONFIG_KEXEC or
> > CONFIG_KEXEC_FILE work here?
>
> I searched the patch history, found Eric didn't add the dependency on
> CONFIG_KEXEC at the beginning. Later a linux-next building failure with
> randconfig was reported, in there CONFIG_CRASH_DUMP enabled, while
> CONFIG_KEXEC is disabled. Finally Eric added the KEXEC dependency for
> CRASH_DUMP. Please see below link for more details:
>
> https://lore.kernel.org/all/3e8eecd1-a277-2cfb-690e-5de2eb7b9...@oracle.com/T/#u
Thank you for digging this up. However I'm still confused, because
this is exactly how we configure Linux 6.1 (although we do have
CONFIG_KEXEC_FILE enabled) and we don't have any problems. I believe
we did not investigate this issue properly.
> And besides, the newly added CONFIG_CRASH_HOTPLUG also needs
> CONFIG_KEXEC if the elfcorehdr is allowed to be manipulated when
> cpu/memory hotplug hapened.
This still feels like a regression to me: any crash dump support
should be independent of KEXEC syscalls being present. While probably
the common case (including us) that the crashing kernel and recovery
kernel are the same, they don't have to be. We need kexec syscall in
the crashing kernel, but crashdump support in the recovery kernel (but
the recovery kernel not having the kexec syscalls should be totally
fine). If we do require some code definitions from kexec - at most we
should put them under CONFIG_KEXEC_CORE.
> Thanks
> Baoquan
>
Re: [PATCH v4 09/13] powerpc/pseries: Add papr-vpd character driver for VPD retrieval
Hello,
On Fri, Nov 17, 2023 at 11:14:27PM -0600, Nathan Lynch via B4 Relay wrote:
> From: Nathan Lynch
>
> PowerVM LPARs may retrieve Vital Product Data (VPD) for system
> components using the ibm,get-vpd RTAS function.
>
> We can expose this to user space with a /dev/papr-vpd character
> device, where the programming model is:
>
> struct papr_location_code plc = { .str = "", }; /* obtain all VPD */
> int devfd = open("/dev/papr-vpd", O_RDONLY);
> int vpdfd = ioctl(devfd, PAPR_VPD_CREATE_HANDLE, );
> size_t size = lseek(vpdfd, 0, SEEK_END);
> char *buf = malloc(size);
> pread(devfd, buf, size, 0);
>
> When a file descriptor is obtained from ioctl(PAPR_VPD_CREATE_HANDLE),
> the file contains the result of a complete ibm,get-vpd sequence. The
> file contents are immutable from the POV of user space. To get a new
> view of the VPD, the client must create a new handle.
>
> This design choice insulates user space from most of the complexities
> that ibm,get-vpd brings:
>
> * ibm,get-vpd must be called more than once to obtain complete
> results.
>
> * Only one ibm,get-vpd call sequence should be in progress at a time;
> interleaved sequences will disrupt each other. Callers must have a
> protocol for serializing their use of the function.
>
> * A call sequence in progress may receive a "VPD changed, try again"
> status, requiring the client to abandon the sequence and start
> over.
>
> The memory required for the VPD buffers seems acceptable, around 20KB
> for all VPD on one of my systems. And the value of the
> /rtas/ibm,vpd-size DT property (the estimated maximum size of VPD) is
> consistently 300KB across various systems I've checked.
>
> I've implemented support for this new ABI in the rtas_get_vpd()
> function in librtas, which the vpdupdate command currently uses to
> populate its VPD database. I've verified that an unmodified vpdupdate
> binary generates an identical database when using a librtas.so that
> prefers the new ABI.
>
> Note that the driver needs to serialize its call sequences with legacy
> sys_rtas(ibm,get-vpd) callers, so it exposes its internal lock for
> sys_rtas.
>
> Signed-off-by: Nathan Lynch
> ---
> Documentation/userspace-api/ioctl/ioctl-number.rst | 2 +
> arch/powerpc/include/uapi/asm/papr-vpd.h | 22 +
> arch/powerpc/platforms/pseries/Makefile| 1 +
> arch/powerpc/platforms/pseries/papr-vpd.c | 536
> +
> 4 files changed, 561 insertions(+)
> diff --git a/arch/powerpc/platforms/pseries/Makefile
> b/arch/powerpc/platforms/pseries/Makefile
> index 1476c5e4433c..f936962a2946 100644
> --- a/arch/powerpc/platforms/pseries/Makefile
> +++ b/arch/powerpc/platforms/pseries/Makefile
> @@ -4,6 +4,7 @@ ccflags-$(CONFIG_PPC_PSERIES_DEBUG) += -DDEBUG
>
> obj-y:= lpar.o hvCall.o nvram.o reconfig.o \
> of_helpers.o rtas-work-area.o papr-sysparm.o \
> +papr-vpd.o \
> setup.o iommu.o event_sources.o ras.o \
> firmware.o power.o dlpar.o mobility.o rng.o \
> pci.o pci_dlpar.o eeh_pseries.o msi.o \
> diff --git a/arch/powerpc/platforms/pseries/papr-vpd.c
> b/arch/powerpc/platforms/pseries/papr-vpd.c
> new file mode 100644
> index ..2bc52301a402
> --- /dev/null
> +++ b/arch/powerpc/platforms/pseries/papr-vpd.c
> @@ -0,0 +1,536 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#define pr_fmt(fmt) "papr-vpd: " fmt
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
...
> +/**
> + * papr_vpd_retrieve() - Return the VPD for a location code.
> + * @loc_code: Location code that defines the scope of VPD to return.
> + *
> + * Run VPD sequences against @loc_code until a blob is successfully
> + * instantiated, or a hard error is encountered, or a fatal signal is
> + * pending.
> + *
> + * Context: May sleep.
> + * Return: A fully populated VPD blob when successful. Encoded error
> + * pointer otherwise.
> + */
> +static const struct vpd_blob *papr_vpd_retrieve(const struct
> papr_location_code *loc_code)
> +{
> + const struct vpd_blob *blob;
> +
> + /*
> + * EAGAIN means the sequence errored with a -4 (VPD changed)
> + * status from ibm,get-vpd, and we should attempt a new
> + * sequence. PAPR+ R1–7.3.20–5 indicates that this should be a
> + * transient condition, not something that happens
> + * continuously. But we'll stop trying on a fatal signal.
> + */
> + do {
> + blob = papr_vpd_run_sequence(loc_code);
> + if (!IS_ERR(blob)) /* Success. */
> + break;
> + if (PTR_ERR(blob) != -EAGAIN) /* Hard error. */
> + break;
> + pr_info_ratelimited("VPD changed during retrieval,
[PATCH v10 14/14] media: vim2m-audio: add virtual driver for audio memory to memory
Audio memory to memory virtual driver use video memory to memory
virtual driver vim2m.c as example. The main difference is
device type is VFL_TYPE_AUDIO and device cap type is V4L2_CAP_AUDIO_M2M.
The device_run function is a dummy function, which is simply
copy the data from input buffer to output buffer.
Signed-off-by: Shengjiu Wang
---
drivers/media/test-drivers/Kconfig | 11 +
drivers/media/test-drivers/Makefile | 1 +
drivers/media/test-drivers/vim2m-audio.c | 799 +++
3 files changed, 811 insertions(+)
create mode 100644 drivers/media/test-drivers/vim2m-audio.c
diff --git a/drivers/media/test-drivers/Kconfig
b/drivers/media/test-drivers/Kconfig
index 459b433e9fae..55f8af6ee4e2 100644
--- a/drivers/media/test-drivers/Kconfig
+++ b/drivers/media/test-drivers/Kconfig
@@ -17,6 +17,17 @@ config VIDEO_VIM2M
This is a virtual test device for the memory-to-memory driver
framework.
+config VIDEO_VIM2M_AUDIO
+ tristate "Virtual Memory-to-Memory Driver For Audio"
+ depends on VIDEO_DEV
+ select VIDEOBUF2_VMALLOC
+ select V4L2_MEM2MEM_DEV
+ select MEDIA_CONTROLLER
+ select MEDIA_CONTROLLER_REQUEST_API
+ help
+ This is a virtual audio test device for the memory-to-memory driver
+ framework.
+
source "drivers/media/test-drivers/vicodec/Kconfig"
source "drivers/media/test-drivers/vimc/Kconfig"
source "drivers/media/test-drivers/vivid/Kconfig"
diff --git a/drivers/media/test-drivers/Makefile
b/drivers/media/test-drivers/Makefile
index 740714a4584d..0c61c9ada3e1 100644
--- a/drivers/media/test-drivers/Makefile
+++ b/drivers/media/test-drivers/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_DVB_VIDTV) += vidtv/
obj-$(CONFIG_VIDEO_VICODEC) += vicodec/
obj-$(CONFIG_VIDEO_VIM2M) += vim2m.o
+obj-$(CONFIG_VIDEO_VIM2M_AUDIO) += vim2m-audio.o
obj-$(CONFIG_VIDEO_VIMC) += vimc/
obj-$(CONFIG_VIDEO_VIVID) += vivid/
obj-$(CONFIG_VIDEO_VISL) += visl/
diff --git a/drivers/media/test-drivers/vim2m-audio.c
b/drivers/media/test-drivers/vim2m-audio.c
new file mode 100644
index ..72806ada8628
--- /dev/null
+++ b/drivers/media/test-drivers/vim2m-audio.c
@@ -0,0 +1,799 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * A virtual v4l2-mem2mem example for audio device.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+MODULE_DESCRIPTION("Virtual device for audio mem2mem testing");
+MODULE_LICENSE("GPL");
+
+static unsigned int debug;
+module_param(debug, uint, 0644);
+MODULE_PARM_DESC(debug, "debug level");
+
+#define MEM2MEM_NAME "vim2m-audio"
+
+#define dprintk(dev, lvl, fmt, arg...) \
+ v4l2_dbg(lvl, debug, &(dev)->v4l2_dev, "%s: " fmt, __func__, ## arg)
+
+#define SAMPLE_NUM 4096
+
+static void audm2m_dev_release(struct device *dev)
+{}
+
+static struct platform_device audm2m_pdev = {
+ .name = MEM2MEM_NAME,
+ .dev.release= audm2m_dev_release,
+};
+
+static u32 formats[] = {
+ V4L2_AUDIO_FMT_S16_LE,
+};
+
+#define NUM_FORMATS ARRAY_SIZE(formats)
+
+/* Per-queue, driver-specific private data */
+struct audm2m_q_data {
+ unsigned intrate;
+ unsigned intchannels;
+ unsigned intbuffersize;
+ unsigned intsequence;
+ u32 fourcc;
+};
+
+enum {
+ V4L2_M2M_SRC = 0,
+ V4L2_M2M_DST = 1,
+};
+
+static snd_pcm_format_t find_format(u32 fourcc)
+{
+ snd_pcm_format_t fmt;
+ unsigned int k;
+
+ for (k = 0; k < NUM_FORMATS; k++) {
+ if (formats[k] == fourcc)
+ break;
+ }
+
+ if (k == NUM_FORMATS)
+ return 0;
+
+ fmt = v4l2_fourcc_to_audfmt(formats[k]);
+
+ return fmt;
+}
+
+struct audm2m_dev {
+ struct v4l2_device v4l2_dev;
+ struct video_device vfd;
+
+ struct mutexdev_mutex;
+
+ struct v4l2_m2m_dev *m2m_dev;
+#ifdef CONFIG_MEDIA_CONTROLLER
+ struct media_device mdev;
+#endif
+};
+
+struct audm2m_ctx {
+ struct v4l2_fh fh;
+ struct v4l2_ctrl_handlerctrl_handler;
+ struct audm2m_dev *dev;
+
+ struct mutexvb_mutex;
+
+ /* Source and destination queue data */
+ struct audm2m_q_data q_data[2];
+};
+
+static inline struct audm2m_ctx *file2ctx(struct file *file)
+{
+ return container_of(file->private_data, struct audm2m_ctx, fh);
+}
+
+static struct audm2m_q_data *get_q_data(struct audm2m_ctx *ctx,
+ enum v4l2_buf_type type)
+{
+ if (type == V4L2_BUF_TYPE_AUDIO_OUTPUT)
+ return >q_data[V4L2_M2M_SRC];
+ return >q_data[V4L2_M2M_DST];
+}
+
+static const char *type_name(enum v4l2_buf_type type)
+{
+ if (type == V4L2_BUF_TYPE_AUDIO_OUTPUT)
+ return "Output";
+ return
[PATCH v10 13/14] media: imx-asrc: Add memory to memory driver
Implement the ASRC memory to memory function using
the v4l2 framework, user can use this function with
v4l2 ioctl interface.
User send the output and capture buffer to driver and
driver store the converted data to the capture buffer.
This feature can be shared by ASRC and EASRC drivers
Signed-off-by: Shengjiu Wang
---
drivers/media/platform/nxp/Kconfig| 13 +
drivers/media/platform/nxp/Makefile |1 +
drivers/media/platform/nxp/imx-asrc.c | 1264 +
3 files changed, 1278 insertions(+)
create mode 100644 drivers/media/platform/nxp/imx-asrc.c
diff --git a/drivers/media/platform/nxp/Kconfig
b/drivers/media/platform/nxp/Kconfig
index 40e3436669e2..8d0ca335601f 100644
--- a/drivers/media/platform/nxp/Kconfig
+++ b/drivers/media/platform/nxp/Kconfig
@@ -67,3 +67,16 @@ config VIDEO_MX2_EMMAPRP
source "drivers/media/platform/nxp/dw100/Kconfig"
source "drivers/media/platform/nxp/imx-jpeg/Kconfig"
+
+config VIDEO_IMX_ASRC
+ tristate "NXP i.MX ASRC M2M support"
+ depends on V4L_MEM2MEM_DRIVERS
+ depends on MEDIA_SUPPORT
+ select VIDEOBUF2_DMA_CONTIG
+ select V4L2_MEM2MEM_DEV
+ select MEDIA_CONTROLLER
+ help
+ Say Y if you want to add ASRC M2M support for NXP CPUs.
+ It is a complement for ASRC M2P and ASRC P2M features.
+ This option is only useful for out-of-tree drivers since
+ in-tree drivers select it automatically.
diff --git a/drivers/media/platform/nxp/Makefile
b/drivers/media/platform/nxp/Makefile
index 4d90eb713652..1325675e34f5 100644
--- a/drivers/media/platform/nxp/Makefile
+++ b/drivers/media/platform/nxp/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_VIDEO_IMX8MQ_MIPI_CSI2) += imx8mq-mipi-csi2.o
obj-$(CONFIG_VIDEO_IMX_MIPI_CSIS) += imx-mipi-csis.o
obj-$(CONFIG_VIDEO_IMX_PXP) += imx-pxp.o
obj-$(CONFIG_VIDEO_MX2_EMMAPRP) += mx2_emmaprp.o
+obj-$(CONFIG_VIDEO_IMX_ASRC) += imx-asrc.o
diff --git a/drivers/media/platform/nxp/imx-asrc.c
b/drivers/media/platform/nxp/imx-asrc.c
new file mode 100644
index ..9ce7ef6f9059
--- /dev/null
+++ b/drivers/media/platform/nxp/imx-asrc.c
@@ -0,0 +1,1264 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2014-2016 Freescale Semiconductor, Inc.
+// Copyright (C) 2019-2023 NXP
+//
+// Freescale ASRC Memory to Memory (M2M) driver
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define V4L_CAP OUT
+#define V4L_OUT IN
+
+#define ASRC_xPUT_DMA_CALLBACK(dir) \
+ (((dir) == V4L_OUT) ? asrc_input_dma_callback \
+ : asrc_output_dma_callback)
+
+#define DIR_STR(dir) (dir) == V4L_OUT ? "out" : "cap"
+
+/* Maximum output and capture buffer size */
+#define ASRC_M2M_BUFFER_SIZE (512 * 1024)
+
+/* Maximum output and capture period size */
+#define ASRC_M2M_PERIOD_SIZE (48 * 1024)
+
+struct asrc_pair_m2m {
+ struct fsl_asrc_pair *pair;
+ struct asrc_m2m *m2m;
+ struct v4l2_fh fh;
+ struct v4l2_ctrl_handler ctrl_handler;
+ int channels[2];
+ unsigned int sequence[2];
+ s64 src_rate_off_prev; /* Q31.32 */
+ s64 dst_rate_off_prev; /* Q31.32 */
+ s64 src_rate_off_cur; /* Q31.32 */
+ s64 dst_rate_off_cur; /* Q31.32 */
+};
+
+struct asrc_m2m {
+ struct fsl_asrc_m2m_pdata pdata;
+ struct v4l2_device v4l2_dev;
+ struct v4l2_m2m_dev *m2m_dev;
+ struct video_device *dec_vdev;
+ struct mutex mlock; /* v4l2 ioctls serialization */
+ struct platform_device *pdev;
+#ifdef CONFIG_MEDIA_CONTROLLER
+ struct media_device mdev;
+#endif
+};
+
+static u32 formats[] = {
+ V4L2_AUDIO_FMT_S8,
+ V4L2_AUDIO_FMT_S16_LE,
+ V4L2_AUDIO_FMT_U16_LE,
+ V4L2_AUDIO_FMT_S24_LE,
+ V4L2_AUDIO_FMT_S24_3LE,
+ V4L2_AUDIO_FMT_U24_LE,
+ V4L2_AUDIO_FMT_U24_3LE,
+ V4L2_AUDIO_FMT_S32_LE,
+ V4L2_AUDIO_FMT_U32_LE,
+ V4L2_AUDIO_FMT_S20_3LE,
+ V4L2_AUDIO_FMT_U20_3LE,
+ V4L2_AUDIO_FMT_FLOAT_LE,
+ V4L2_AUDIO_FMT_IEC958_SUBFRAME_LE,
+};
+
+#define NUM_FORMATS ARRAY_SIZE(formats)
+
+static const s64 asrc_v1_m2m_rates[] = {
+ 5512, 8000, 11025, 12000, 16000,
+ 22050, 24000, 32000, 44100,
+ 48000, 64000, 88200, 96000,
+ 128000, 176400, 192000,
+};
+
+static const s64 asrc_v2_m2m_rates[] = {
+ 8000, 11025, 12000, 16000,
+ 22050, 24000, 32000, 44100,
+ 48000, 64000, 88200, 96000,
+ 128000, 176400, 192000, 256000,
+ 352800, 384000, 705600, 768000,
+};
+
+static u32 find_fourcc(snd_pcm_format_t format)
+{
+ snd_pcm_format_t fmt;
+ unsigned int k;
+
+ for (k = 0; k < NUM_FORMATS; k++) {
+ fmt = v4l2_fourcc_to_audfmt(formats[k]);
+ if (fmt == format)
+ return formats[k];
+ }
+
+ return 0;
+}
+
+static snd_pcm_format_t find_format(u32 fourcc)
+{
+ unsigned int k;
+
[PATCH v10 12/14] media: uapi: Add an entity type for audio resampler
Add and document a media entity type for audio resampler.
It is MEDIA_ENT_F_PROC_AUDIO_RESAMPLER.
Signed-off-by: Shengjiu Wang
---
Documentation/userspace-api/media/mediactl/media-types.rst | 6 ++
include/uapi/linux/media.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/Documentation/userspace-api/media/mediactl/media-types.rst
b/Documentation/userspace-api/media/mediactl/media-types.rst
index f0880aea41d6..abbe515dad76 100644
--- a/Documentation/userspace-api/media/mediactl/media-types.rst
+++ b/Documentation/userspace-api/media/mediactl/media-types.rst
@@ -40,6 +40,7 @@ Types and flags used to represent the media graph elements
.. _MEDIA-ENT-F-PROC-VIDEO-ENCODER:
.. _MEDIA-ENT-F-PROC-VIDEO-DECODER:
.. _MEDIA-ENT-F-PROC-VIDEO-ISP:
+.. _MEDIA-ENT-F-PROC-AUDIO-RESAMPLER:
.. _MEDIA-ENT-F-VID-MUX:
.. _MEDIA-ENT-F-VID-IF-BRIDGE:
.. _MEDIA-ENT-F-DV-DECODER:
@@ -208,6 +209,11 @@ Types and flags used to represent the media graph elements
combination of custom V4L2 controls and IOCTLs, and parameters
supplied in a metadata buffer.
+* - ``MEDIA_ENT_F_PROC_AUDIO_RESAMPLER``
+ - An Audio Resampler device. An entity capable of
+ resampling a audio stream from one sample rate to another sample
+ rate. Must have one sink pad and at least one source pad.
+
* - ``MEDIA_ENT_F_VID_MUX``
- Video multiplexer. An entity capable of multiplexing must have at
least two sink pads and one source pad, and must pass the video
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 9ff6dec7393a..a8266eaa8042 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -125,6 +125,7 @@ struct media_device_info {
#define MEDIA_ENT_F_PROC_VIDEO_ENCODER (MEDIA_ENT_F_BASE + 0x4007)
#define MEDIA_ENT_F_PROC_VIDEO_DECODER (MEDIA_ENT_F_BASE + 0x4008)
#define MEDIA_ENT_F_PROC_VIDEO_ISP (MEDIA_ENT_F_BASE + 0x4009)
+#define MEDIA_ENT_F_PROC_AUDIO_RESAMPLER (MEDIA_ENT_F_BASE + 0x400a)
/*
* Switch and bridge entity functions
--
2.34.1
[PATCH v10 11/14] media: uapi: Declare interface types for Audio
Declare the interface types that will be used by Audio.
The type is MEDIA_INTF_T_V4L_AUDIO.
Signed-off-by: Shengjiu Wang
---
.../userspace-api/media/mediactl/media-types.rst| 5 +
drivers/media/v4l2-core/v4l2-dev.c | 4
drivers/media/v4l2-core/v4l2-mem2mem.c | 13 +
include/uapi/linux/media.h | 1 +
4 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/Documentation/userspace-api/media/mediactl/media-types.rst
b/Documentation/userspace-api/media/mediactl/media-types.rst
index 0ffeece1e0c8..f0880aea41d6 100644
--- a/Documentation/userspace-api/media/mediactl/media-types.rst
+++ b/Documentation/userspace-api/media/mediactl/media-types.rst
@@ -265,6 +265,7 @@ Types and flags used to represent the media graph elements
.. _MEDIA-INTF-T-V4L-SUBDEV:
.. _MEDIA-INTF-T-V4L-SWRADIO:
.. _MEDIA-INTF-T-V4L-TOUCH:
+.. _MEDIA-INTF-T-V4L-AUDIO:
.. _MEDIA-INTF-T-ALSA-PCM-CAPTURE:
.. _MEDIA-INTF-T-ALSA-PCM-PLAYBACK:
.. _MEDIA-INTF-T-ALSA-CONTROL:
@@ -322,6 +323,10 @@ Types and flags used to represent the media graph elements
- Device node interface for Touch device (V4L)
- typically, /dev/v4l-touch?
+* - ``MEDIA_INTF_T_V4L_AUDIO``
+ - Device node interface for Audio device (V4L)
+ - typically, /dev/v4l-audio?
+
* - ``MEDIA_INTF_T_ALSA_PCM_CAPTURE``
- Device node interface for ALSA PCM Capture
- typically, /dev/snd/pcmC?D?c
diff --git a/drivers/media/v4l2-core/v4l2-dev.c
b/drivers/media/v4l2-core/v4l2-dev.c
index b92c760b611a..c3a7d974db26 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -842,6 +842,10 @@ static int video_register_media_controller(struct
video_device *vdev)
intf_type = MEDIA_INTF_T_V4L_SUBDEV;
/* Entity will be created via v4l2_device_register_subdev() */
break;
+ case VFL_TYPE_AUDIO:
+ intf_type = MEDIA_INTF_T_V4L_AUDIO;
+ /* Entity will be created via v4l2_device_register_subdev() */
+ break;
default:
return 0;
}
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 0cc30397fbad..bf41d112b742 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -1134,10 +1134,15 @@ int v4l2_m2m_register_media_controller(struct
v4l2_m2m_dev *m2m_dev,
if (ret)
goto err_rm_links0;
- /* Create video interface */
- m2m_dev->intf_devnode = media_devnode_create(mdev,
- MEDIA_INTF_T_V4L_VIDEO, 0,
- VIDEO_MAJOR, vdev->minor);
+ if (vdev->vfl_type == VFL_TYPE_AUDIO)
+ m2m_dev->intf_devnode = media_devnode_create(mdev,
+ MEDIA_INTF_T_V4L_AUDIO, 0,
+ VIDEO_MAJOR, vdev->minor);
+ else
+ /* Create video interface */
+ m2m_dev->intf_devnode = media_devnode_create(mdev,
+ MEDIA_INTF_T_V4L_VIDEO, 0,
+ VIDEO_MAJOR, vdev->minor);
if (!m2m_dev->intf_devnode) {
ret = -ENOMEM;
goto err_rm_links1;
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 1c80b1d6bbaf..9ff6dec7393a 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -260,6 +260,7 @@ struct media_links_enum {
#define MEDIA_INTF_T_V4L_SUBDEV(MEDIA_INTF_T_V4L_BASE
+ 3)
#define MEDIA_INTF_T_V4L_SWRADIO (MEDIA_INTF_T_V4L_BASE + 4)
#define MEDIA_INTF_T_V4L_TOUCH (MEDIA_INTF_T_V4L_BASE + 5)
+#define MEDIA_INTF_T_V4L_AUDIO (MEDIA_INTF_T_V4L_BASE + 6)
#define MEDIA_INTF_T_ALSA_BASE 0x0300
#define MEDIA_INTF_T_ALSA_PCM_CAPTURE (MEDIA_INTF_T_ALSA_BASE)
--
2.34.1
[PATCH v10 10/14] media: uapi: Add audio rate controls support
Add V4L2_CID_M2M_AUDIO_SOURCE_RATE and V4L2_CID_M2M_AUDIO_DEST_RATE
new IDs for rate control.
Add V4L2_CID_M2M_AUDIO_SOURCE_RATE_OFFSET and
V4L2_CID_M2M_AUDIO_DEST_RATE_OFFSET for clock drift.
Signed-off-by: Shengjiu Wang
---
.../media/v4l/ext-ctrls-audio-m2m.rst | 20 +++
drivers/media/v4l2-core/v4l2-ctrls-defs.c | 6 ++
include/uapi/linux/v4l2-controls.h| 5 +
3 files changed, 31 insertions(+)
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-audio-m2m.rst
b/Documentation/userspace-api/media/v4l/ext-ctrls-audio-m2m.rst
index 82d2ecedbfee..a3c06fbb91b9 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-audio-m2m.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-audio-m2m.rst
@@ -19,3 +19,23 @@ Audio M2M Control IDs
The Audio M2M class descriptor. Calling
:ref:`VIDIOC_QUERYCTRL` for this control will
return a description of this control class.
+
+.. _v4l2-audio-asrc:
+
+``V4L2_CID_M2M_AUDIO_SOURCE_RATE (integer menu)``
+Sets the audio source sample rate, unit is Hz
+
+``V4L2_CID_M2M_AUDIO_DEST_RATE (integer menu)``
+Sets the audio destination sample rate, unit is Hz
+
+``V4L2_CID_M2M_AUDIO_SOURCE_RATE_OFFSET (fixed point)``
+Sets the offset from the audio source sample rate, unit is Hz.
+The offset compensates for any clock drift. The actual source audio sample
+rate is the ideal source audio sample rate from
+``V4L2_CID_M2M_AUDIO_SOURCE_RATE`` plus this fixed point offset.
+
+``V4L2_CID_M2M_AUDIO_DEST_RATE_OFFSET (fixed point)``
+Sets the offset from the audio dest sample rate, unit is Hz.
+The offset compensates for any clock drift. The actual dest audio sample
+rate is the ideal source audio sample rate from
+``V4L2_CID_M2M_AUDIO_DEST_RATE`` plus this fixed point offset.
diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
index 2a85ea3dc92f..4e606d7fd971 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
@@ -1245,6 +1245,8 @@ const char *v4l2_ctrl_get_name(u32 id)
/* Audio M2M controls */
case V4L2_CID_M2M_AUDIO_CLASS: return "Audio M2M Controls";
+ case V4L2_CID_M2M_AUDIO_SOURCE_RATE:return "Audio Source Sample
Rate";
+ case V4L2_CID_M2M_AUDIO_DEST_RATE: return "Audio Dest Sample Rate";
default:
return NULL;
}
@@ -1606,6 +1608,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_COLORIMETRY_HDR10_MASTERING_DISPLAY:
*type = V4L2_CTRL_TYPE_HDR10_MASTERING_DISPLAY;
break;
+ case V4L2_CID_M2M_AUDIO_SOURCE_RATE:
+ case V4L2_CID_M2M_AUDIO_DEST_RATE:
+ *type = V4L2_CTRL_TYPE_INTEGER_MENU;
+ break;
default:
*type = V4L2_CTRL_TYPE_INTEGER;
break;
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 7d318065a33d..493b59f20a35 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -3489,6 +3489,11 @@ struct v4l2_ctrl_av1_film_grain {
#define V4L2_CID_M2M_AUDIO_CLASS_BASE (V4L2_CTRL_CLASS_M2M_AUDIO | 0x900)
#define V4L2_CID_M2M_AUDIO_CLASS (V4L2_CTRL_CLASS_M2M_AUDIO | 1)
+#define V4L2_CID_M2M_AUDIO_SOURCE_RATE (V4L2_CID_M2M_AUDIO_CLASS_BASE + 0)
+#define V4L2_CID_M2M_AUDIO_DEST_RATE (V4L2_CID_M2M_AUDIO_CLASS_BASE + 1)
+#define V4L2_CID_M2M_AUDIO_SOURCE_RATE_OFFSET (V4L2_CID_M2M_AUDIO_CLASS_BASE
+ 2)
+#define V4L2_CID_M2M_AUDIO_DEST_RATE_OFFSET(V4L2_CID_M2M_AUDIO_CLASS_BASE
+ 3)
+
/* MPEG-compression definitions kept for backwards compatibility */
#ifndef __KERNEL__
#define V4L2_CTRL_CLASS_MPEGV4L2_CTRL_CLASS_CODEC
--
2.34.1
[PATCH v10 09/14] media: uapi: Add V4L2_CTRL_CLASS_M2M_AUDIO
The Audio M2M class includes controls for audio memory-to-memory
use cases. The controls can be used for audio codecs, audio
preprocessing, audio postprocessing.
Signed-off-by: Shengjiu Wang
---
.../userspace-api/media/v4l/common.rst| 1 +
.../media/v4l/ext-ctrls-audio-m2m.rst | 21 +++
.../media/v4l/vidioc-g-ext-ctrls.rst | 4
drivers/media/v4l2-core/v4l2-ctrls-defs.c | 4
include/uapi/linux/v4l2-controls.h| 4
5 files changed, 34 insertions(+)
create mode 100644
Documentation/userspace-api/media/v4l/ext-ctrls-audio-m2m.rst
diff --git a/Documentation/userspace-api/media/v4l/common.rst
b/Documentation/userspace-api/media/v4l/common.rst
index ea0435182e44..d5366e96a596 100644
--- a/Documentation/userspace-api/media/v4l/common.rst
+++ b/Documentation/userspace-api/media/v4l/common.rst
@@ -52,6 +52,7 @@ applicable to all devices.
ext-ctrls-fm-rx
ext-ctrls-detect
ext-ctrls-colorimetry
+ext-ctrls-audio-m2m
fourcc
format
planar-apis
diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-audio-m2m.rst
b/Documentation/userspace-api/media/v4l/ext-ctrls-audio-m2m.rst
new file mode 100644
index ..82d2ecedbfee
--- /dev/null
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-audio-m2m.rst
@@ -0,0 +1,21 @@
+.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+
+.. _audiom2m-controls:
+
+***
+Audio M2M Control Reference
+***
+
+The Audio M2M class includes controls for audio memory-to-memory
+use cases. The controls can be used for audio codecs, audio
+preprocessing, audio postprocessing.
+
+Audio M2M Control IDs
+---
+
+.. _audiom2m-control-id:
+
+``V4L2_CID_M2M_AUDIO_CLASS (class)``
+The Audio M2M class descriptor. Calling
+:ref:`VIDIOC_QUERYCTRL` for this control will
+return a description of this control class.
diff --git a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst
b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst
index f9f73530a6be..e8475f9fd2cf 100644
--- a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst
+++ b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst
@@ -480,6 +480,10 @@ still cause this situation.
- 0xa5
- The class containing colorimetry controls. These controls are
described in :ref:`colorimetry-controls`.
+* - ``V4L2_CTRL_CLASS_M2M_AUDIO``
+ - 0xa6
+ - The class containing audio m2m controls. These controls are
+ described in :ref:`audiom2m-controls`.
Return Value
diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
index 8696eb1cdd61..2a85ea3dc92f 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
@@ -1242,6 +1242,9 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_COLORIMETRY_CLASS:return "Colorimetry Controls";
case V4L2_CID_COLORIMETRY_HDR10_CLL_INFO: return "HDR10
Content Light Info";
case V4L2_CID_COLORIMETRY_HDR10_MASTERING_DISPLAY: return "HDR10
Mastering Display";
+
+ /* Audio M2M controls */
+ case V4L2_CID_M2M_AUDIO_CLASS: return "Audio M2M Controls";
default:
return NULL;
}
@@ -1451,6 +1454,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_DETECT_CLASS:
case V4L2_CID_CODEC_STATELESS_CLASS:
case V4L2_CID_COLORIMETRY_CLASS:
+ case V4L2_CID_M2M_AUDIO_CLASS:
*type = V4L2_CTRL_TYPE_CTRL_CLASS;
/* You can neither read nor write these */
*flags |= V4L2_CTRL_FLAG_READ_ONLY | V4L2_CTRL_FLAG_WRITE_ONLY;
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 68db66d4aae8..7d318065a33d 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -30,6 +30,7 @@
#define V4L2_CTRL_CLASS_DETECT 0x00a3 /* Detection controls */
#define V4L2_CTRL_CLASS_CODEC_STATELESS 0x00a4 /* Stateless codecs
controls */
#define V4L2_CTRL_CLASS_COLORIMETRY0x00a5 /* Colorimetry controls
*/
+#define V4L2_CTRL_CLASS_M2M_AUDIO 0x00a6 /* Audio M2M controls */
/* User-class control IDs */
@@ -3485,6 +3486,9 @@ struct v4l2_ctrl_av1_film_grain {
__u8 reserved[4];
};
+#define V4L2_CID_M2M_AUDIO_CLASS_BASE (V4L2_CTRL_CLASS_M2M_AUDIO | 0x900)
+#define V4L2_CID_M2M_AUDIO_CLASS (V4L2_CTRL_CLASS_M2M_AUDIO | 1)
+
/* MPEG-compression definitions kept for backwards compatibility */
#ifndef __KERNEL__
#define V4L2_CTRL_CLASS_MPEGV4L2_CTRL_CLASS_CODEC
--
2.34.1
[PATCH v10 08/14] media: uapi: Define audio sample format fourcc type
The audio sample format definition is from alsa,
the header file is include/uapi/sound/asound.h, but
don't include this header file directly, because in
user space, there is another copy in alsa-lib.
There will be conflict in userspace for include
videodev2.h & asound.h and asoundlib.h
Here still use the fourcc format.
Signed-off-by: Shengjiu Wang
---
.../userspace-api/media/v4l/pixfmt-audio.rst | 87 +++
.../userspace-api/media/v4l/pixfmt.rst| 1 +
drivers/media/v4l2-core/v4l2-ioctl.c | 13 +++
include/uapi/linux/videodev2.h| 23 +
4 files changed, 124 insertions(+)
create mode 100644 Documentation/userspace-api/media/v4l/pixfmt-audio.rst
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-audio.rst
b/Documentation/userspace-api/media/v4l/pixfmt-audio.rst
new file mode 100644
index ..04b4a7fbd8f4
--- /dev/null
+++ b/Documentation/userspace-api/media/v4l/pixfmt-audio.rst
@@ -0,0 +1,87 @@
+.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+
+.. _pixfmt-audio:
+
+*
+Audio Formats
+*
+
+These formats are used for :ref:`audiomem2mem` interface only.
+
+.. tabularcolumns:: |p{5.8cm}|p{1.2cm}|p{10.3cm}|
+
+.. cssclass:: longtable
+
+.. flat-table:: Audio Format
+:header-rows: 1
+:stub-columns: 0
+:widths: 3 1 4
+
+* - Identifier
+ - Code
+ - Details
+* .. _V4L2-AUDIO-FMT-S8:
+
+ - ``V4L2_AUDIO_FMT_S8``
+ - 'S8'
+ - Corresponds to SNDRV_PCM_FORMAT_S8 in ALSA
+* .. _V4L2-AUDIO-FMT-S16-LE:
+
+ - ``V4L2_AUDIO_FMT_S16_LE``
+ - 'S16_LE'
+ - Corresponds to SNDRV_PCM_FORMAT_S16_LE in ALSA
+* .. _V4L2-AUDIO-FMT-U16-LE:
+
+ - ``V4L2_AUDIO_FMT_U16_LE``
+ - 'U16_LE'
+ - Corresponds to SNDRV_PCM_FORMAT_U16_LE in ALSA
+* .. _V4L2-AUDIO-FMT-S24-LE:
+
+ - ``V4L2_AUDIO_FMT_S24_LE``
+ - 'S24_LE'
+ - Corresponds to SNDRV_PCM_FORMAT_S24_LE in ALSA
+* .. _V4L2-AUDIO-FMT-U24-LE:
+
+ - ``V4L2_AUDIO_FMT_U24_LE``
+ - 'U24_LE'
+ - Corresponds to SNDRV_PCM_FORMAT_U24_LE in ALSA
+* .. _V4L2-AUDIO-FMT-S32-LE:
+
+ - ``V4L2_AUDIO_FMT_S32_LE``
+ - 'S32_LE'
+ - Corresponds to SNDRV_PCM_FORMAT_S32_LE in ALSA
+* .. _V4L2-AUDIO-FMT-U32-LE:
+
+ - ``V4L2_AUDIO_FMT_U32_LE``
+ - 'U32_LE'
+ - Corresponds to SNDRV_PCM_FORMAT_U32_LE in ALSA
+* .. _V4L2-AUDIO-FMT-FLOAT-LE:
+
+ - ``V4L2_AUDIO_FMT_FLOAT_LE``
+ - 'FLOAT_LE'
+ - Corresponds to SNDRV_PCM_FORMAT_FLOAT_LE in ALSA
+* .. _V4L2-AUDIO-FMT-IEC958-SUBFRAME-LE:
+
+ - ``V4L2_AUDIO_FMT_IEC958_SUBFRAME_LE``
+ - 'IEC958_SUBFRAME_LE'
+ - Corresponds to SNDRV_PCM_FORMAT_IEC958_SUBFRAME_LE in ALSA
+* .. _V4L2-AUDIO-FMT-S24-3LE:
+
+ - ``V4L2_AUDIO_FMT_S24_3LE``
+ - 'S24_3LE'
+ - Corresponds to SNDRV_PCM_FORMAT_S24_3LE in ALSA
+* .. _V4L2-AUDIO-FMT-U24-3LE:
+
+ - ``V4L2_AUDIO_FMT_U24_3LE``
+ - 'U24_3LE'
+ - Corresponds to SNDRV_PCM_FORMAT_U24_3LE in ALSA
+* .. _V4L2-AUDIO-FMT-S20-3LE:
+
+ - ``V4L2_AUDIO_FMT_S20_3LE``
+ - 'S20_3LE'
+ - Corresponds to SNDRV_PCM_FORMAT_S24_3LE in ALSA
+* .. _V4L2-AUDIO-FMT-U20-3LE:
+
+ - ``V4L2_AUDIO_FMT_U20_3LE``
+ - 'U20_3LE'
+ - Corresponds to SNDRV_PCM_FORMAT_U20_3LE in ALSA
diff --git a/Documentation/userspace-api/media/v4l/pixfmt.rst
b/Documentation/userspace-api/media/v4l/pixfmt.rst
index 11dab4a90630..2eb6fdd3b43d 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt.rst
@@ -36,3 +36,4 @@ see also :ref:`VIDIOC_G_FBUF `.)
colorspaces
colorspaces-defs
colorspaces-details
+pixfmt-audio
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 1bb03794922a..c86633b82038 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1471,6 +1471,19 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_Y210: descr = "10-bit YUYV Packed"; break;
case V4L2_PIX_FMT_Y212: descr = "12-bit YUYV Packed"; break;
case V4L2_PIX_FMT_Y216: descr = "16-bit YUYV Packed"; break;
+ case V4L2_AUDIO_FMT_S8: descr = "8-bit Signed"; break;
+ case V4L2_AUDIO_FMT_S16_LE: descr = "16-bit Signed LE"; break;
+ case V4L2_AUDIO_FMT_U16_LE: descr = "16-bit Unsigned LE";
break;
+ case V4L2_AUDIO_FMT_S24_LE: descr = "24(32)-bit Signed LE";
break;
+ case V4L2_AUDIO_FMT_U24_LE: descr = "24(32)-bit Unsigned
LE"; break;
+ case V4L2_AUDIO_FMT_S32_LE: descr = "32-bit Signed LE";
break;
+ case V4L2_AUDIO_FMT_U32_LE: descr = "32-bit Unsigned LE";
break;
+ case V4L2_AUDIO_FMT_FLOAT_LE: descr = "32-bit Float LE";
break;
+ case V4L2_AUDIO_FMT_IEC958_SUBFRAME_LE: descr =
[PATCH v10 07/14] media: v4l2: Add audio capture and output support
Audio signal processing has the requirement for memory to
memory similar as Video.
This patch is to add this support in v4l2 framework, defined
new buffer type V4L2_BUF_TYPE_AUDIO_CAPTURE and
V4L2_BUF_TYPE_AUDIO_OUTPUT, defined new format v4l2_audio_format
for audio case usage.
The created audio device is named "/dev/v4l-audioX".
Signed-off-by: Shengjiu Wang
---
.../userspace-api/media/v4l/buffer.rst| 6 ++
.../media/v4l/dev-audio-mem2mem.rst | 71 +++
.../userspace-api/media/v4l/devices.rst | 1 +
.../media/v4l/vidioc-enum-fmt.rst | 2 +
.../userspace-api/media/v4l/vidioc-g-fmt.rst | 4 ++
.../media/videodev2.h.rst.exceptions | 2 +
.../media/common/videobuf2/videobuf2-v4l2.c | 4 ++
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 9 +++
drivers/media/v4l2-core/v4l2-dev.c| 17 +
drivers/media/v4l2-core/v4l2-ioctl.c | 53 ++
include/media/v4l2-dev.h | 2 +
include/media/v4l2-ioctl.h| 34 +
include/uapi/linux/videodev2.h| 17 +
13 files changed, 222 insertions(+)
create mode 100644 Documentation/userspace-api/media/v4l/dev-audio-mem2mem.rst
diff --git a/Documentation/userspace-api/media/v4l/buffer.rst
b/Documentation/userspace-api/media/v4l/buffer.rst
index 52bbee81c080..a3754ca6f0d6 100644
--- a/Documentation/userspace-api/media/v4l/buffer.rst
+++ b/Documentation/userspace-api/media/v4l/buffer.rst
@@ -438,6 +438,12 @@ enum v4l2_buf_type
* - ``V4L2_BUF_TYPE_META_OUTPUT``
- 14
- Buffer for metadata output, see :ref:`metadata`.
+* - ``V4L2_BUF_TYPE_AUDIO_CAPTURE``
+ - 15
+ - Buffer for audio capture, see :ref:`audio`.
+* - ``V4L2_BUF_TYPE_AUDIO_OUTPUT``
+ - 16
+ - Buffer for audio output, see :ref:`audio`.
.. _buffer-flags:
diff --git a/Documentation/userspace-api/media/v4l/dev-audio-mem2mem.rst
b/Documentation/userspace-api/media/v4l/dev-audio-mem2mem.rst
new file mode 100644
index ..68faecfe3a02
--- /dev/null
+++ b/Documentation/userspace-api/media/v4l/dev-audio-mem2mem.rst
@@ -0,0 +1,71 @@
+.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+
+.. _audiomem2mem:
+
+
+Audio Memory-To-Memory Interface
+
+
+An audio memory-to-memory device can compress, decompress, transform, or
+otherwise convert audio data from one format into another format, in memory.
+Such memory-to-memory devices set the ``V4L2_CAP_AUDIO_M2M`` capability.
+Examples of memory-to-memory devices are audio codecs, audio preprocessing,
+audio postprocessing.
+
+A memory-to-memory audio node supports both output (sending audio frames from
+memory to the hardware) and capture (receiving the processed audio frames
+from the hardware into memory) stream I/O. An application will have to
+setup the stream I/O for both sides and finally call
+:ref:`VIDIOC_STREAMON ` for both capture and output to
+start the hardware.
+
+Memory-to-memory devices function as a shared resource: you can
+open the audio node multiple times, each application setting up their
+own properties that are local to the file handle, and each can use
+it independently from the others. The driver will arbitrate access to
+the hardware and reprogram it whenever another file handler gets access.
+
+Audio memory-to-memory devices are accessed through character device
+special files named ``/dev/v4l-audio``
+
+Querying Capabilities
+=
+
+Device nodes supporting the audio memory-to-memory interface set the
+``V4L2_CAP_AUDIO_M2M`` flag in the ``device_caps`` field of the
+:c:type:`v4l2_capability` structure returned by the :c:func:`VIDIOC_QUERYCAP`
+ioctl.
+
+Data Format Negotiation
+===
+
+The audio device uses the :ref:`format` ioctls to select the capture format.
+The audio buffer content format is bound to that selected format. In addition
+to the basic :ref:`format` ioctls, the :c:func:`VIDIOC_ENUM_FMT` ioctl must be
+supported as well.
+
+To use the :ref:`format` ioctls applications set the ``type`` field of the
+:c:type:`v4l2_format` structure to ``V4L2_BUF_TYPE_AUDIO_CAPTURE`` or to
+``V4L2_BUF_TYPE_AUDIO_OUTPUT``. Both drivers and applications must set the
+remainder of the :c:type:`v4l2_format` structure to 0.
+
+.. c:type:: v4l2_audio_format
+
+.. tabularcolumns:: |p{1.4cm}|p{2.4cm}|p{13.5cm}|
+
+.. flat-table:: struct v4l2_audio_format
+:header-rows: 0
+:stub-columns: 0
+:widths: 1 1 2
+
+* - __u32
+ - ``pixelformat``
+ - The sample format, set by the application. see :ref:`pixfmt-audio`
+* - __u32
+ - ``channels``
+ - The channel number, set by the application. channel number range is
+[1, 32].
+* - __u32
+ - ``buffersize``
+ - Maximum buffer size in bytes required for data. The value is set by the
+driver.
diff --git
[PATCH v10 06/14] media: uapi: Add V4L2_CAP_AUDIO_M2M capability flag
V4L2_CAP_AUDIO_M2M is similar to V4L2_CAP_VIDEO_M2M flag.
It is used for audio memory to memory case.
Signed-off-by: Shengjiu Wang
---
Documentation/userspace-api/media/v4l/vidioc-querycap.rst| 3 +++
Documentation/userspace-api/media/videodev2.h.rst.exceptions | 1 +
include/uapi/linux/videodev2.h | 1 +
3 files changed, 5 insertions(+)
diff --git a/Documentation/userspace-api/media/v4l/vidioc-querycap.rst
b/Documentation/userspace-api/media/v4l/vidioc-querycap.rst
index 6c57b8428356..1c0d97bf192a 100644
--- a/Documentation/userspace-api/media/v4l/vidioc-querycap.rst
+++ b/Documentation/userspace-api/media/v4l/vidioc-querycap.rst
@@ -173,6 +173,9 @@ specification the ioctl returns an ``EINVAL`` error code.
interface. A video overlay device typically stores captured images
directly in the video memory of a graphics card, with hardware
clipping and scaling.
+* - ``V4L2_CAP_AUDIO_M2M``
+ - 0x0008
+ - The device supports the audio Memory-To-Memory interface.
* - ``V4L2_CAP_VBI_CAPTURE``
- 0x0010
- The device supports the :ref:`Raw VBI Capture `
diff --git a/Documentation/userspace-api/media/videodev2.h.rst.exceptions
b/Documentation/userspace-api/media/videodev2.h.rst.exceptions
index 3e58aac4ef0b..da6d0b8e4c2c 100644
--- a/Documentation/userspace-api/media/videodev2.h.rst.exceptions
+++ b/Documentation/userspace-api/media/videodev2.h.rst.exceptions
@@ -197,6 +197,7 @@ replace define V4L2_CAP_META_OUTPUT device-capabilities
replace define V4L2_CAP_DEVICE_CAPS device-capabilities
replace define V4L2_CAP_TOUCH device-capabilities
replace define V4L2_CAP_IO_MC device-capabilities
+replace define V4L2_CAP_AUDIO_M2M device-capabilities
# V4L2 pix flags
replace define V4L2_PIX_FMT_PRIV_MAGIC :c:type:`v4l2_pix_format`
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 3813212a5cd3..eb5911719734 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -473,6 +473,7 @@ struct v4l2_capability {
#define V4L2_CAP_VIDEO_CAPTURE 0x0001 /* Is a video capture
device */
#define V4L2_CAP_VIDEO_OUTPUT 0x0002 /* Is a video output device
*/
#define V4L2_CAP_VIDEO_OVERLAY 0x0004 /* Can do video overlay */
+#define V4L2_CAP_AUDIO_M2M 0x0008 /* audio memory to memory */
#define V4L2_CAP_VBI_CAPTURE 0x0010 /* Is a raw VBI capture
device */
#define V4L2_CAP_VBI_OUTPUT0x0020 /* Is a raw VBI output
device */
#define V4L2_CAP_SLICED_VBI_CAPTURE0x0040 /* Is a sliced VBI capture
device */
--
2.34.1
[PATCH v10 04/14] ASoC: fsl_asrc: register m2m platform device
Register m2m platform device, that user can
use M2M feature.
Defined platform data structure and platform
driver name.
Signed-off-by: Shengjiu Wang
Acked-by: Mark Brown
---
include/sound/fsl_asrc_common.h | 23 +++
sound/soc/fsl/fsl_asrc.c| 18 ++
2 files changed, 41 insertions(+)
diff --git a/include/sound/fsl_asrc_common.h b/include/sound/fsl_asrc_common.h
index 3b53d366182f..c709b8906929 100644
--- a/include/sound/fsl_asrc_common.h
+++ b/include/sound/fsl_asrc_common.h
@@ -71,6 +71,7 @@ struct fsl_asrc_pair {
* @dma_params_rx: DMA parameters for receive channel
* @dma_params_tx: DMA parameters for transmit channel
* @pdev: platform device pointer
+ * @m2m_pdev: m2m platform device pointer
* @regmap: regmap handler
* @paddr: physical address to the base address of registers
* @mem_clk: clock source to access register
@@ -103,6 +104,7 @@ struct fsl_asrc {
struct snd_dmaengine_dai_dma_data dma_params_rx;
struct snd_dmaengine_dai_dma_data dma_params_tx;
struct platform_device *pdev;
+ struct platform_device *m2m_pdev;
struct regmap *regmap;
unsigned long paddr;
struct clk *mem_clk;
@@ -139,6 +141,27 @@ struct fsl_asrc {
void *private;
};
+/**
+ * struct fsl_asrc_m2m_pdata - platform data
+ * @asrc: pointer to struct fsl_asrc
+ * @fmt_in: input sample format
+ * @fmt_out: output sample format
+ * @chan_min: minimum channel number
+ * @chan_max: maximum channel number
+ * @rate_min: minimum rate
+ * @rate_max: maximum rete
+ */
+struct fsl_asrc_m2m_pdata {
+ struct fsl_asrc *asrc;
+ u64 fmt_in;
+ u64 fmt_out;
+ int chan_min;
+ int chan_max;
+ int rate_min;
+ int rate_max;
+};
+
+#define M2M_DRV_NAME "fsl_asrc_m2m"
#define DRV_NAME "fsl-asrc-dai"
extern struct snd_soc_component_driver fsl_asrc_component;
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index 7d8643ee0ba0..5ecb5d869607 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -1187,6 +1187,7 @@ static int fsl_asrc_runtime_suspend(struct device *dev);
static int fsl_asrc_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
+ struct fsl_asrc_m2m_pdata m2m_pdata;
struct fsl_asrc_priv *asrc_priv;
struct fsl_asrc *asrc;
struct resource *res;
@@ -1368,6 +1369,18 @@ static int fsl_asrc_probe(struct platform_device *pdev)
goto err_pm_get_sync;
}
+ m2m_pdata.asrc = asrc;
+ m2m_pdata.fmt_in = FSL_ASRC_FORMATS;
+ m2m_pdata.fmt_out = FSL_ASRC_FORMATS | SNDRV_PCM_FMTBIT_S8;
+ m2m_pdata.rate_min = 5512;
+ m2m_pdata.rate_max = 192000;
+ m2m_pdata.chan_min = 1;
+ m2m_pdata.chan_max = 10;
+ asrc->m2m_pdev = platform_device_register_data(>dev,
+ M2M_DRV_NAME,
+ PLATFORM_DEVID_AUTO,
+ _pdata,
+ sizeof(m2m_pdata));
return 0;
err_pm_get_sync:
@@ -1380,6 +1393,11 @@ static int fsl_asrc_probe(struct platform_device *pdev)
static void fsl_asrc_remove(struct platform_device *pdev)
{
+ struct fsl_asrc *asrc = dev_get_drvdata(>dev);
+
+ if (asrc->m2m_pdev && !IS_ERR(asrc->m2m_pdev))
+ platform_device_unregister(asrc->m2m_pdev);
+
pm_runtime_disable(>dev);
if (!pm_runtime_status_suspended(>dev))
fsl_asrc_runtime_suspend(>dev);
--
2.34.1
[PATCH v10 05/14] ASoC: fsl_easrc: register m2m platform device
Register m2m platform device,that user can
use M2M feature.
Signed-off-by: Shengjiu Wang
Acked-by: Mark Brown
---
sound/soc/fsl/fsl_easrc.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/sound/soc/fsl/fsl_easrc.c b/sound/soc/fsl/fsl_easrc.c
index cf7ad30a323b..ccbf45c7abf4 100644
--- a/sound/soc/fsl/fsl_easrc.c
+++ b/sound/soc/fsl/fsl_easrc.c
@@ -2075,6 +2075,7 @@ MODULE_DEVICE_TABLE(of, fsl_easrc_dt_ids);
static int fsl_easrc_probe(struct platform_device *pdev)
{
struct fsl_easrc_priv *easrc_priv;
+ struct fsl_asrc_m2m_pdata m2m_pdata;
struct device *dev = >dev;
struct fsl_asrc *easrc;
struct resource *res;
@@ -2190,6 +2191,19 @@ static int fsl_easrc_probe(struct platform_device *pdev)
goto err_pm_disable;
}
+ m2m_pdata.asrc = easrc;
+ m2m_pdata.fmt_in = FSL_EASRC_FORMATS;
+ m2m_pdata.fmt_out = FSL_EASRC_FORMATS |
SNDRV_PCM_FMTBIT_IEC958_SUBFRAME_LE;
+ m2m_pdata.rate_min = 8000;
+ m2m_pdata.rate_max = 768000;
+ m2m_pdata.chan_min = 1;
+ m2m_pdata.chan_max = 32;
+ easrc->m2m_pdev = platform_device_register_data(>dev,
+ M2M_DRV_NAME,
+ PLATFORM_DEVID_AUTO,
+ _pdata,
+ sizeof(m2m_pdata));
+
return 0;
err_pm_disable:
@@ -2199,6 +2213,11 @@ static int fsl_easrc_probe(struct platform_device *pdev)
static void fsl_easrc_remove(struct platform_device *pdev)
{
+ struct fsl_asrc *easrc = dev_get_drvdata(>dev);
+
+ if (easrc->m2m_pdev && !IS_ERR(easrc->m2m_pdev))
+ platform_device_unregister(easrc->m2m_pdev);
+
pm_runtime_disable(>dev);
}
--
2.34.1
[PATCH v10 03/14] ASoC: fsl_asrc: move fsl_asrc_common.h to include/sound
Move fsl_asrc_common.h to include/sound that it can be
included from other drivers.
Signed-off-by: Shengjiu Wang
Acked-by: Mark Brown
---
{sound/soc/fsl => include/sound}/fsl_asrc_common.h | 0
sound/soc/fsl/fsl_asrc.h | 2 +-
sound/soc/fsl/fsl_asrc_dma.c | 2 +-
sound/soc/fsl/fsl_easrc.h | 2 +-
4 files changed, 3 insertions(+), 3 deletions(-)
rename {sound/soc/fsl => include/sound}/fsl_asrc_common.h (100%)
diff --git a/sound/soc/fsl/fsl_asrc_common.h b/include/sound/fsl_asrc_common.h
similarity index 100%
rename from sound/soc/fsl/fsl_asrc_common.h
rename to include/sound/fsl_asrc_common.h
diff --git a/sound/soc/fsl/fsl_asrc.h b/sound/soc/fsl/fsl_asrc.h
index 1c492eb237f5..66544624de7b 100644
--- a/sound/soc/fsl/fsl_asrc.h
+++ b/sound/soc/fsl/fsl_asrc.h
@@ -10,7 +10,7 @@
#ifndef _FSL_ASRC_H
#define _FSL_ASRC_H
-#include "fsl_asrc_common.h"
+#include
#define ASRC_M2M_INPUTFIFO_WML 0x4
#define ASRC_M2M_OUTPUTFIFO_WML0x2
diff --git a/sound/soc/fsl/fsl_asrc_dma.c b/sound/soc/fsl/fsl_asrc_dma.c
index f501f47242fb..f067bf1ecea7 100644
--- a/sound/soc/fsl/fsl_asrc_dma.c
+++ b/sound/soc/fsl/fsl_asrc_dma.c
@@ -12,7 +12,7 @@
#include
#include
-#include "fsl_asrc_common.h"
+#include
#define FSL_ASRC_DMABUF_SIZE (256 * 1024)
diff --git a/sound/soc/fsl/fsl_easrc.h b/sound/soc/fsl/fsl_easrc.h
index c9f770862662..a24e540876a4 100644
--- a/sound/soc/fsl/fsl_easrc.h
+++ b/sound/soc/fsl/fsl_easrc.h
@@ -9,7 +9,7 @@
#include
#include
-#include "fsl_asrc_common.h"
+#include
/* EASRC Register Map */
--
2.34.1
[PATCH v10 01/14] ASoC: fsl_asrc: define functions for memory to memory usage
ASRC can be used on memory to memory case, define several
functions for m2m usage.
m2m_prepare: prepare for the start step
m2m_start: the start step
m2m_unprepare: unprepare for stop step, optional
m2m_stop: stop step
m2m_check_format: check format is supported or not
m2m_calc_out_len: calculate output length according to input length
m2m_get_maxburst: burst size for dma
m2m_pair_suspend: suspend function of pair, optional.
m2m_pair_resume: resume function of pair
get_output_fifo_size: get remaining data size in FIFO
Signed-off-by: Shengjiu Wang
Acked-by: Mark Brown
---
sound/soc/fsl/fsl_asrc.c| 126
sound/soc/fsl/fsl_asrc.h| 2 +
sound/soc/fsl/fsl_asrc_common.h | 37 ++
3 files changed, 165 insertions(+)
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index b793263291dc..7d8643ee0ba0 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -1063,6 +1063,124 @@ static int fsl_asrc_get_fifo_addr(u8 dir, enum
asrc_pair_index index)
return REG_ASRDx(dir, index);
}
+/* Get sample numbers in FIFO */
+static unsigned int fsl_asrc_get_output_fifo_size(struct fsl_asrc_pair *pair)
+{
+ struct fsl_asrc *asrc = pair->asrc;
+ enum asrc_pair_index index = pair->index;
+ u32 val;
+
+ regmap_read(asrc->regmap, REG_ASRFST(index), );
+
+ val &= ASRFSTi_OUTPUT_FIFO_MASK;
+
+ return val >> ASRFSTi_OUTPUT_FIFO_SHIFT;
+}
+
+static int fsl_asrc_m2m_prepare(struct fsl_asrc_pair *pair)
+{
+ struct fsl_asrc_pair_priv *pair_priv = pair->private;
+ struct fsl_asrc *asrc = pair->asrc;
+ struct device *dev = >pdev->dev;
+ struct asrc_config config;
+ int ret;
+
+ /* fill config */
+ config.pair = pair->index;
+ config.channel_num = pair->channels;
+ config.input_sample_rate = pair->rate[IN];
+ config.output_sample_rate = pair->rate[OUT];
+ config.input_format = pair->sample_format[IN];
+ config.output_format = pair->sample_format[OUT];
+ config.inclk = INCLK_NONE;
+ config.outclk = OUTCLK_ASRCK1_CLK;
+
+ pair_priv->config =
+ ret = fsl_asrc_config_pair(pair, true);
+ if (ret) {
+ dev_err(dev, "failed to config pair: %d\n", ret);
+ return ret;
+ }
+
+ pair->first_convert = 1;
+
+ return 0;
+}
+
+static int fsl_asrc_m2m_start(struct fsl_asrc_pair *pair)
+{
+ if (pair->first_convert) {
+ fsl_asrc_start_pair(pair);
+ pair->first_convert = 0;
+ }
+ /*
+* Clear DMA request during the stall state of ASRC:
+* During STALL state, the remaining in input fifo would never be
+* smaller than the input threshold while the output fifo would not
+* be bigger than output one. Thus the DMA request would be cleared.
+*/
+ fsl_asrc_set_watermarks(pair, ASRC_FIFO_THRESHOLD_MIN,
+ ASRC_FIFO_THRESHOLD_MAX);
+
+ /* Update the real input threshold to raise DMA request */
+ fsl_asrc_set_watermarks(pair, ASRC_M2M_INPUTFIFO_WML,
+ ASRC_M2M_OUTPUTFIFO_WML);
+
+ return 0;
+}
+
+static int fsl_asrc_m2m_stop(struct fsl_asrc_pair *pair)
+{
+ if (!pair->first_convert) {
+ fsl_asrc_stop_pair(pair);
+ pair->first_convert = 1;
+ }
+
+ return 0;
+}
+
+/* calculate capture data length according to output data length and sample
rate */
+static int fsl_asrc_m2m_calc_out_len(struct fsl_asrc_pair *pair, int
input_buffer_length)
+{
+ unsigned int in_width, out_width;
+ unsigned int channels = pair->channels;
+ unsigned int in_samples, out_samples;
+ unsigned int out_length;
+
+ in_width = snd_pcm_format_physical_width(pair->sample_format[IN]) / 8;
+ out_width = snd_pcm_format_physical_width(pair->sample_format[OUT]) / 8;
+
+ in_samples = input_buffer_length / in_width / channels;
+ out_samples = pair->rate[OUT] * in_samples / pair->rate[IN];
+ out_length = (out_samples - ASRC_OUTPUT_LAST_SAMPLE) * out_width *
channels;
+
+ return out_length;
+}
+
+static int fsl_asrc_m2m_get_maxburst(u8 dir, struct fsl_asrc_pair *pair)
+{
+ struct fsl_asrc *asrc = pair->asrc;
+ struct fsl_asrc_priv *asrc_priv = asrc->private;
+ int wml = (dir == IN) ? ASRC_M2M_INPUTFIFO_WML :
ASRC_M2M_OUTPUTFIFO_WML;
+
+ if (!asrc_priv->soc->use_edma)
+ return wml * pair->channels;
+ else
+ return 1;
+}
+
+static int fsl_asrc_m2m_pair_resume(struct fsl_asrc_pair *pair)
+{
+ struct fsl_asrc *asrc = pair->asrc;
+ int i;
+
+ for (i = 0; i < pair->channels * 4; i++)
+ regmap_write(asrc->regmap, REG_ASRDI(pair->index), 0);
+
+ pair->first_convert = 1;
+ return 0;
+}
+
static int fsl_asrc_runtime_resume(struct device *dev);
static int
[PATCH v10 02/14] ASoC: fsl_easrc: define functions for memory to memory usage
ASRC can be used on memory to memory case, define several
functions for m2m usage and export them as function pointer.
Signed-off-by: Shengjiu Wang
Acked-by: Mark Brown
---
sound/soc/fsl/fsl_easrc.c | 214 ++
sound/soc/fsl/fsl_easrc.h | 4 +
2 files changed, 218 insertions(+)
diff --git a/sound/soc/fsl/fsl_easrc.c b/sound/soc/fsl/fsl_easrc.c
index ec53bda46a46..cf7ad30a323b 100644
--- a/sound/soc/fsl/fsl_easrc.c
+++ b/sound/soc/fsl/fsl_easrc.c
@@ -1861,6 +1861,211 @@ static int fsl_easrc_get_fifo_addr(u8 dir, enum
asrc_pair_index index)
return REG_EASRC_FIFO(dir, index);
}
+/* Get sample numbers in FIFO */
+static unsigned int fsl_easrc_get_output_fifo_size(struct fsl_asrc_pair *pair)
+{
+ struct fsl_asrc *asrc = pair->asrc;
+ enum asrc_pair_index index = pair->index;
+ u32 val;
+
+ regmap_read(asrc->regmap, REG_EASRC_SFS(index), );
+ val &= EASRC_SFS_NSGO_MASK;
+
+ return val >> EASRC_SFS_NSGO_SHIFT;
+}
+
+static int fsl_easrc_m2m_prepare(struct fsl_asrc_pair *pair)
+{
+ struct fsl_easrc_ctx_priv *ctx_priv = pair->private;
+ struct fsl_asrc *asrc = pair->asrc;
+ struct device *dev = >pdev->dev;
+ int ret;
+
+ ctx_priv->in_params.sample_rate = pair->rate[IN];
+ ctx_priv->in_params.sample_format = pair->sample_format[IN];
+ ctx_priv->out_params.sample_rate = pair->rate[OUT];
+ ctx_priv->out_params.sample_format = pair->sample_format[OUT];
+
+ ctx_priv->in_params.fifo_wtmk = FSL_EASRC_INPUTFIFO_WML;
+ ctx_priv->out_params.fifo_wtmk = FSL_EASRC_OUTPUTFIFO_WML;
+ /* Fill the right half of the re-sampler with zeros */
+ ctx_priv->rs_init_mode = 0x2;
+ /* Zero fill the right half of the prefilter */
+ ctx_priv->pf_init_mode = 0x2;
+
+ ret = fsl_easrc_set_ctx_format(pair,
+ _priv->in_params.sample_format,
+ _priv->out_params.sample_format);
+ if (ret) {
+ dev_err(dev, "failed to set context format: %d\n", ret);
+ return ret;
+ }
+
+ ret = fsl_easrc_config_context(asrc, pair->index);
+ if (ret) {
+ dev_err(dev, "failed to config context %d\n", ret);
+ return ret;
+ }
+
+ ctx_priv->in_params.iterations = 1;
+ ctx_priv->in_params.group_len = pair->channels;
+ ctx_priv->in_params.access_len = pair->channels;
+ ctx_priv->out_params.iterations = 1;
+ ctx_priv->out_params.group_len = pair->channels;
+ ctx_priv->out_params.access_len = pair->channels;
+
+ ret = fsl_easrc_set_ctx_organziation(pair);
+ if (ret) {
+ dev_err(dev, "failed to set fifo organization\n");
+ return ret;
+ }
+
+ /* The context start flag */
+ pair->first_convert = 1;
+ return 0;
+}
+
+static int fsl_easrc_m2m_start(struct fsl_asrc_pair *pair)
+{
+ /* start context once */
+ if (pair->first_convert) {
+ fsl_easrc_start_context(pair);
+ pair->first_convert = 0;
+ }
+
+ return 0;
+}
+
+static int fsl_easrc_m2m_stop(struct fsl_asrc_pair *pair)
+{
+ /* Stop pair/context */
+ if (!pair->first_convert) {
+ fsl_easrc_stop_context(pair);
+ pair->first_convert = 1;
+ }
+
+ return 0;
+}
+
+/* calculate capture data length according to output data length and sample
rate */
+static int fsl_easrc_m2m_calc_out_len(struct fsl_asrc_pair *pair, int
input_buffer_length)
+{
+ struct fsl_asrc *easrc = pair->asrc;
+ struct fsl_easrc_priv *easrc_priv = easrc->private;
+ struct fsl_easrc_ctx_priv *ctx_priv = pair->private;
+ unsigned int in_rate = ctx_priv->in_params.norm_rate;
+ unsigned int out_rate = ctx_priv->out_params.norm_rate;
+ unsigned int channels = pair->channels;
+ unsigned int in_samples, out_samples;
+ unsigned int in_width, out_width;
+ unsigned int out_length;
+ unsigned int frac_bits;
+ u64 val1, val2;
+
+ switch (easrc_priv->rs_num_taps) {
+ case EASRC_RS_32_TAPS:
+ /* integer bits = 5; */
+ frac_bits = 39;
+ break;
+ case EASRC_RS_64_TAPS:
+ /* integer bits = 6; */
+ frac_bits = 38;
+ break;
+ case EASRC_RS_128_TAPS:
+ /* integer bits = 7; */
+ frac_bits = 37;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ val1 = (u64)in_rate << frac_bits;
+ do_div(val1, out_rate);
+ val1 += (s64)ctx_priv->ratio_mod << (frac_bits - 31);
+
+ in_width =
snd_pcm_format_physical_width(ctx_priv->in_params.sample_format) / 8;
+ out_width =
snd_pcm_format_physical_width(ctx_priv->out_params.sample_format) / 8;
+
+ ctx_priv->in_filled_len += input_buffer_length;
+
[PATCH v10 00/14] Add audio support in v4l2 framework
Audio signal processing also has the requirement for memory to memory similar as Video. This asrc memory to memory (memory ->asrc->memory) case is a non real time use case. User fills the input buffer to the asrc module, after conversion, then asrc sends back the output buffer to user. So it is not a traditional ALSA playback and capture case. It is a specific use case, there is no reference in current kernel. v4l2 memory to memory is the closed implementation, v4l2 current support video, image, radio, tuner, touch devices, so it is not complicated to add support for this specific audio case. Because we had implemented the "memory -> asrc ->i2s device-> codec" use case in ALSA. Now the "memory->asrc->memory" needs to reuse the code in asrc driver, so the first 3 patches is for refining the code to make it can be shared by the "memory->asrc->memory" driver. The main change is in the v4l2 side, A /dev/vl4-audioX will be created, user applications only use the ioctl of v4l2 framework. Other change is to add memory to memory support for two kinds of i.MX ASRC module. changes in v10 - remove FIXED_POINT type - change code base on media: v4l2-ctrls: add support for fraction_bits - fix issue reported by kernel test robot - remove module_alias changes in v9: - add MEDIA_ENT_F_PROC_AUDIO_RESAMPLER. - add MEDIA_INTF_T_V4L_AUDIO - add media controller support - refine the vim2m-audio to support 8k<->16k conversion. changes in v8: - refine V4L2_CAP_AUDIO_M2M to be 0x0008 - update doc for FIXED_POINT - address comments for imx-asrc changes in v7: - add acked-by from Mark - separate commit for fixed point, m2m audio class, audio rate controls - use INTEGER_MENU for rate, FIXED_POINT for rate offset - remove used fmts - address other comments for Hans changes in v6: - use m2m_prepare/m2m_unprepare/m2m_start/m2m_stop to replace m2m_start_part_one/m2m_stop_part_one, m2m_start_part_two/m2m_stop_part_two. - change V4L2_CTRL_TYPE_ASRC_RATE to V4L2_CTRL_TYPE_FIXED_POINT - fix warning by kernel test rebot - remove some unused format V4L2_AUDIO_FMT_XX - Get SNDRV_PCM_FORMAT from V4L2_AUDIO_FMT in driver. - rename audm2m to viaudm2m. changes in v5: - remove V4L2_AUDIO_FMT_LPCM - define audio pixel format like V4L2_AUDIO_FMT_S8... - remove rate and format in struct v4l2_audio_format. - Add V4L2_CID_ASRC_SOURCE_RATE and V4L2_CID_ASRC_DEST_RATE controls - updata document accordingly. changes in v4: - update document style - separate V4L2_AUDIO_FMT_LPCM and V4L2_CAP_AUDIO_M2M in separate commit changes in v3: - Modify documents for adding audio m2m support - Add audio virtual m2m driver - Defined V4L2_AUDIO_FMT_LPCM format type for audio. - Defined V4L2_CAP_AUDIO_M2M capability type for audio m2m case. - with modification in v4l-utils, pass v4l2-compliance test. changes in v2: - decouple the implementation in v4l2 and ALSA - implement the memory to memory driver as a platfrom driver and move it to driver/media - move fsl_asrc_common.h to include/sound folder Shengjiu Wang (14): ASoC: fsl_asrc: define functions for memory to memory usage ASoC: fsl_easrc: define functions for memory to memory usage ASoC: fsl_asrc: move fsl_asrc_common.h to include/sound ASoC: fsl_asrc: register m2m platform device ASoC: fsl_easrc: register m2m platform device media: uapi: Add V4L2_CAP_AUDIO_M2M capability flag media: v4l2: Add audio capture and output support media: uapi: Define audio sample format fourcc type media: uapi: Add V4L2_CTRL_CLASS_M2M_AUDIO media: uapi: Add audio rate controls support media: uapi: Declare interface types for Audio media: uapi: Add an entity type for audio resampler media: imx-asrc: Add memory to memory driver media: vim2m-audio: add virtual driver for audio memory to memory .../media/mediactl/media-types.rst| 11 + .../userspace-api/media/v4l/buffer.rst|6 + .../userspace-api/media/v4l/common.rst|1 + .../media/v4l/dev-audio-mem2mem.rst | 71 + .../userspace-api/media/v4l/devices.rst |1 + .../media/v4l/ext-ctrls-audio-m2m.rst | 41 + .../userspace-api/media/v4l/pixfmt-audio.rst | 87 ++ .../userspace-api/media/v4l/pixfmt.rst|1 + .../media/v4l/vidioc-enum-fmt.rst |2 + .../media/v4l/vidioc-g-ext-ctrls.rst |4 + .../userspace-api/media/v4l/vidioc-g-fmt.rst |4 + .../media/v4l/vidioc-querycap.rst |3 + .../media/videodev2.h.rst.exceptions |3 + .../media/common/videobuf2/videobuf2-v4l2.c |4 + drivers/media/platform/nxp/Kconfig| 13 + drivers/media/platform/nxp/Makefile |1 + drivers/media/platform/nxp/imx-asrc.c | 1264 + drivers/media/test-drivers/Kconfig| 11 + drivers/media/test-drivers/Makefile |1 + drivers/media/test-drivers/vim2m-audio.c | 799 +++ drivers/media/v4l2-core/v4l2-compat-ioctl32.c |9 +
