Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

4 participants
3252 discussions

Re: [PATCH v2 11/14] drm/mediatek: Rename files "mtk_drm_plane.c" to "mtk_plane.c"

by AngeloGioacchino Del Regno

Il 19/03/24 08:02, Shawn Sung ha scritto: > From: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> > > Rename files mtk_drm_plane.c to mtk_plane.c and > modify the Makefile accordingly. > > Signed-off-by: Hsiao Chien Sung <shawn.sung(a)mediatek.corp-partner.google.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com>

1 year, 10 months

Re: [PATCH 12/18] ASoC: codecs: mt6357: add MT6357 codec

by Mark Brown

On Fri, Mar 15, 2024 at 06:36:19PM +0100, Alexandre Mergnat wrote: > On 15/03/2024 16:15, Mark Brown wrote: > > On Fri, Mar 15, 2024 at 04:05:21PM +0100, Alexandre Mergnat wrote: > > > > In the register. You only need to reset the gain to -40dB at the start > > > > of the ramp. > > > Sorry but I don't understand your logic, I'm not able to implement it... > > > If I'm at -10dB and doing a ramp to reach -40dB, next time I will read the > > > register the value will be -40dB. > > After we've done the ramp and turned the amplifier off we can just > > restore the desired value? The hardware is not going to care what the > > volume is while it's not enabled. > If you do that, HP will be enabled at the saved gain, and after that you > will do the ramp. To avoid pop, the driver should be rewrite to: So reset the volume to -40dB prior to turning the amplifier on... > Read gain in the reg and save it locally > Set -40dB in the reg > Enable HP > Do ramp ...as you yourself suggest? > > > AFAII from the comment in the code, it's done to avoid the "pop noises". > > Yes, that's the usual reason to ramp gains. Though if you've just > > copied the code without checking that it's needed it's possible that > > this is something that's been fixed in current hardware. > I did the test at 24dB with and without the "pop filter". Isn't big but I > ear the pop at the start of the record without the "pop filter". OK, it probably is still doing something then. > To be clear, the algo/behavior of this code is an implementation based on > the 6k+ lines downstream code for this specific audio codec. But the > shape/style is based on upstreamed drivers like mt6358.c. The Mediatek code has a bunch of issues, I wouldn't read too much into something being present in the code.

1 year, 10 months

Re: [PATCH 12/18] ASoC: codecs: mt6357: add MT6357 codec

by Mark Brown

On Fri, Mar 15, 2024 at 04:05:21PM +0100, Alexandre Mergnat wrote: > On 15/03/2024 15:30, Mark Brown wrote: > > > Let me know, when you change de gain to do a ramp down (start from user gain > > > to gain=-40db), next time for the ramp up, how/where do you find the user > > > gain ? > > In the register. You only need to reset the gain to -40dB at the start > > of the ramp. > Sorry but I don't understand your logic, I'm not able to implement it... > If I'm at -10dB and doing a ramp to reach -40dB, next time I will read the > register the value will be -40dB. After we've done the ramp and turned the amplifier off we can just restore the desired value? The hardware is not going to care what the volume is while it's not enabled. > This implementation is also done in other MTK audio codec drivers. Perhaps they should be updated too? > > > When microphone isn't capturing, the gain read back from the register is > > > 0dB. I've put some logs in my code and do capture to show how it works: > > Is this a property of the hardware or a property of your driver? > At the end of the capture, the gain is set to 0dB by the driver. > At the start of the capture, the gain is set to the setup gain. So that's a property of the driver then? > AFAII from the comment in the code, it's done to avoid the "pop noises". Yes, that's the usual reason to ramp gains. Though if you've just copied the code without checking that it's needed it's possible that this is something that's been fixed in current hardware.

1 year, 10 months

Re: [PATCH 00/18] Add audio support for the MediaTek Genio 350-evk board

by Mark Brown

On Tue, Mar 12, 2024 at 09:58:05AM +0100, Alexandre Mergnat wrote: > I'm a bit lost for mixer-test and pcm-test. > Currently, I cross-compile the alsa lib project to be able to build the > tests and put it on my board. > I can execute it, but I still have 2 issues: > 1) I've a lot of missing module in my environment (Encode.so, Encode.pm, > Symbol.pm, IO/Handle.pm, ...). AFAII, I've to cross compile the missing perl > modules and install them in the rootfs These tests are both simple C programs... > 2) I don't know how to configure pcm-test.conf & > Lenovo_ThinkPad_P1_Gen2.conf (or new file to match with my board). The configuration is optional. > My test cmd: > ./run_kselftest.sh -c alsa Just run the programs directly. I'm only asking for the output from two of them anyway.

1 year, 10 months

Re: [PATCH 12/18] ASoC: codecs: mt6357: add MT6357 codec

by Mark Brown

On Fri, Mar 15, 2024 at 12:01:12PM +0100, Alexandre Mergnat wrote: > On 13/03/2024 18:23, Mark Brown wrote: > > On Tue, Mar 12, 2024 at 07:03:25PM +0100, Alexandre Mergnat wrote: > > > Actually you must save the values because the gain selected by the user will > > > be override to do a ramp => volume_ramp(.....): > > > - When you switch on the HP, you start from gain=-40db to final_gain > > > (selected by user). > > > - When you switch off the HP, you start from final_gain (selected by user) > > > to gain=-40db. > > You can just read the value back when you need to do a ramp? > You can't. Because you will read -40db when HP isn't playing sound. That is > why the gain is saved into the struct. > Let me know, when you change de gain to do a ramp down (start from user gain > to gain=-40db), next time for the ramp up, how/where do you find the user > gain ? In the register. You only need to reset the gain to -40dB at the start of the ramp. > > > Also, the microphone's gain change when it's enabled/disabled. > > I don't understand what this means? > When microphone isn't capturing, the gain read back from the register is > 0dB. I've put some logs in my code and do capture to show how it works: Is this a property of the hardware or a property of your driver? > > > > > + /* ul channel swap */ > > > > > + SOC_SINGLE("UL LR Swap", MT6357_AFE_UL_DL_CON0, AFE_UL_LR_SWAP_SFT, 1, 0), > > > > On/off controls should end in Switch. > > > Sorry, I don't understand your comment. Can you reword it please ? > > See control-names.rst. Run mixer-test on a card with this driver and > > fix all the issues it reports. > Ok the name is the issue for you AFAII. > This control isn't for on/off but swap Left and Right. > From the codec documentation: > "Swaps audio UL L/R channel before UL SRC" > This control is overkill, I will remove it This is turning the swapping on and off.

1 year, 10 months

Re: [PATCH 12/18] ASoC: codecs: mt6357: add MT6357 codec

by Mark Brown

On Wed, Mar 13, 2024 at 06:11:50PM +0100, Alexandre Mergnat wrote: > On 26/02/2024 17:09, Mark Brown wrote: > > > index 000000000000..13e95c227114 > > > --- /dev/null > > > +++ b/sound/soc/codecs/mt6357.c > > > @@ -0,0 +1,1805 @@ > > > +// SPDX-License-Identifier: GPL-2.0 > > > +/* > > > + * MT6357 ALSA SoC audio codec driver > > Please use a C++ comment for the whole comment to make it clearer that > > this is intentional. > If I do that, the checkpatch raise a warning: > WARNING: Improper SPDX comment style for > 'sound/soc/mediatek/mt8365/mt8365-afe-clk.c', please use '//' instead > #22: FILE: sound/soc/mediatek/mt8365/mt8365-afe-clk.c:1: > +/* SPDX-License-Identifier: GPL-2.0 That's not a C++ comment so checkpatch is correctly warning?

1 year, 10 months

Re: [PATCH 12/18] ASoC: codecs: mt6357: add MT6357 codec

by Mark Brown

On Tue, Mar 12, 2024 at 07:03:25PM +0100, Alexandre Mergnat wrote: > On 26/02/2024 17:09, Mark Brown wrote: > > > + case MT6357_ZCD_CON2: > > > + regmap_read(priv->regmap, MT6357_ZCD_CON2, &reg); > > > + priv->ana_gain[ANALOG_VOLUME_HPOUTL] = > > > + (reg & AUD_HPL_GAIN_MASK) >> AUD_HPL_GAIN_SFT; > > > + priv->ana_gain[ANALOG_VOLUME_HPOUTR] = > > > + (reg & AUD_HPR_GAIN_MASK) >> AUD_HPR_GAIN_SFT; > > > + break; > > It would probably be less code and would definitely be clearer and > > simpler to just read the values when we need them rather than constatly > > keeping a cache separate to the register cache. > Actually you must save the values because the gain selected by the user will > be override to do a ramp => volume_ramp(.....): > - When you switch on the HP, you start from gain=-40db to final_gain > (selected by user). > - When you switch off the HP, you start from final_gain (selected by user) > to gain=-40db. You can just read the value back when you need to do a ramp? > Also, the microphone's gain change when it's enabled/disabled. I don't understand what this means? > > > + /* ul channel swap */ > > > + SOC_SINGLE("UL LR Swap", MT6357_AFE_UL_DL_CON0, AFE_UL_LR_SWAP_SFT, 1, 0), > > On/off controls should end in Switch. > Sorry, I don't understand your comment. Can you reword it please ? See control-names.rst. Run mixer-test on a card with this driver and fix all the issues it reports. > > > +static int hslo_mux_map_value[] = { > > > + 0x0, 0x1, 0x2, 0x3, > > > +}; > > Why not just use a normal mux here, there's no missing values or > > reordering? Similarly for other muxes. > I've dug into some other codecs and it's done like that, but I've probably > misunderstood something. > The only bad thing I see is enum is missing currently: > > enum { > PGA_MUX_OPEN = 0, > PGA_MUX_DACR, > PGA_MUX_PB, > PGA_MUX_TM, > PGA_MUX_MASK = 0x3, > }; The whole thing with explicitly specfying the mapping is just completely redundant, you may as well remove it.

1 year, 10 months

[PATCH] drm/shmem-helper: Remove duplicate include

by Jiapeng Chong

./drivers/gpu/drm/drm_gem_shmem_helper.c: linux/module.h is included more than once. Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4567 Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- drivers/gpu/drm/drm_gem_shmem_helper.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c index 4ea6507a77e5..f401df26facf 100644 --- a/drivers/gpu/drm/drm_gem_shmem_helper.c +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c @@ -10,7 +10,6 @@ #include <linux/shmem_fs.h> #include <linux/slab.h> #include <linux/vmalloc.h> -#include <linux/module.h> #ifdef CONFIG_X86 #include <asm/set_memory.h> -- 2.20.1.7.g153144c

1 year, 10 months

Re: [PATCH 12/18] ASoC: codecs: mt6357: add MT6357 codec

by AngeloGioacchino Del Regno

Il 12/03/24 15:50, Alexandre Mergnat ha scritto: > > > On 26/02/2024 16:25, AngeloGioacchino Del Regno wrote: >>> + if (enable) { >>> + /* set gpio mosi mode */ >>> + regmap_write(priv->regmap, MT6357_GPIO_MODE2_CLR, GPIO_MODE2_CLEAR_ALL); >>> + regmap_write(priv->regmap, MT6357_GPIO_MODE2_SET, >>> GPIO8_MODE_SET_AUD_CLK_MOSI | >>> + GPIO9_MODE_SET_AUD_DAT_MOSI0 | >>> + GPIO10_MODE_SET_AUD_DAT_MOSI1 | >>> + GPIO11_MODE_SET_AUD_SYNC_MOSI); >> >> Are you sure that you need to write to MODE2_SET *and* to MODE2?! > > This is downstream code and these registers aren't in my documentation. > I've removed the MODE2_SET write and test the audio: it's still working. > > So I will keep the spurious write removed for v2. :) > Usually, MediaTek registers are laid out like "REG" being R/legacy-W and "REG_SET/CLR" for setting and clearing bits in "REG" internally, and that might account for internal latencies and such. Can you please try to remove the MODE2 write instead of the MODE2_SET one and check if that works? You're already using the SETCLR way when manipulating registers in here, so I would confidently expect that to work. Cheers, Angelo

1 year, 10 months

[PATCH v8 0/6] iio: new DMABUF based API

by Paul Cercueil

Hi Jonathan, Here's the final(tm) version of the IIO DMABUF patchset. This v8 fixes the remaining few issues that Christian reported. I also updated the documentation patch as there has been changes to index.rst. This was based on next-20240308. Changelog: - [3/6]: - Fix swapped fence direction - Simplify fence wait mechanism - Remove "Buffer closed with active transfers" print, as it was dead code - Un-export iio_buffer_dmabuf_{get,put}. They are not used anywhere else so they can even be static. - Prevent attaching already-attached DMABUFs - [6/6]: Renamed dmabuf_api.rst -> iio_dmabuf_api.rst, and updated index.rst whose format changed in iio/togreg. Cheers, -Paul Paul Cercueil (6): dmaengine: Add API function dmaengine_prep_peripheral_dma_vec() dmaengine: dma-axi-dmac: Implement device_prep_peripheral_dma_vec iio: core: Add new DMABUF interface infrastructure iio: buffer-dma: Enable support for DMABUFs iio: buffer-dmaengine: Support new DMABUF based userspace API Documentation: iio: Document high-speed DMABUF based API Documentation/iio/iio_dmabuf_api.rst | 54 ++ Documentation/iio/index.rst | 1 + drivers/dma/dma-axi-dmac.c | 40 ++ drivers/iio/buffer/industrialio-buffer-dma.c | 181 ++++++- .../buffer/industrialio-buffer-dmaengine.c | 59 ++- drivers/iio/industrialio-buffer.c | 462 ++++++++++++++++++ include/linux/dmaengine.h | 27 + include/linux/iio/buffer-dma.h | 31 ++ include/linux/iio/buffer_impl.h | 30 ++ include/uapi/linux/iio/buffer.h | 22 + 10 files changed, 890 insertions(+), 17 deletions(-) create mode 100644 Documentation/iio/iio_dmabuf_api.rst -- 2.43.0

1 year, 10 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig