Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

16 participants
3178 discussions

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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 months

Re: [PATCH RESEND drm-misc 4/4] dma-buf: heaps: make dma_heap_class constant

by T.J. Mercier

On Tue, Mar 5, 2024 at 3:34 AM Ricardo B. Marliere <ricardo(a)marliere.net> wrote: > > Since commit 43a7206b0963 ("driver core: class: make class_register() take > a const *"), the driver core allows for struct class to be in read-only > memory, so move the dma_heap_class structure to be declared at build time > placing it into read-only memory, instead of having to be dynamically > allocated at boot time. > > Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > Suggested-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > Signed-off-by: Ricardo B. Marliere <ricardo(a)marliere.net> > --- > drivers/dma-buf/dma-heap.c | 26 ++++++++++++++------------ > 1 file changed, 14 insertions(+), 12 deletions(-) > > diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c > index 84ae708fafe7..bcca6a2bbce8 100644 > --- a/drivers/dma-buf/dma-heap.c > +++ b/drivers/dma-buf/dma-heap.c > @@ -43,10 +43,18 @@ struct dma_heap { > struct cdev heap_cdev; > }; > > +static char *dma_heap_devnode(const struct device *dev, umode_t *mode) > +{ > + return kasprintf(GFP_KERNEL, "dma_heap/%s", dev_name(dev)); > +} > + > static LIST_HEAD(heap_list); > static DEFINE_MUTEX(heap_list_lock); > static dev_t dma_heap_devt; > -static struct class *dma_heap_class; > +static struct class dma_heap_class = { > + .name = DEVNAME, > + .devnode = dma_heap_devnode, > +}; > static DEFINE_XARRAY_ALLOC(dma_heap_minors); > > static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len, > @@ -261,7 +269,7 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info) > goto err1; > } > > - dev_ret = device_create(dma_heap_class, > + dev_ret = device_create(&dma_heap_class, > NULL, > heap->heap_devt, > NULL, > @@ -291,7 +299,7 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info) > return heap; > > err3: > - device_destroy(dma_heap_class, heap->heap_devt); > + device_destroy(&dma_heap_class, heap->heap_devt); > err2: > cdev_del(&heap->heap_cdev); > err1: > @@ -301,11 +309,6 @@ struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info) > return err_ret; > } > > -static char *dma_heap_devnode(const struct device *dev, umode_t *mode) > -{ > - return kasprintf(GFP_KERNEL, "dma_heap/%s", dev_name(dev)); > -} > - > static int dma_heap_init(void) > { > int ret; > @@ -314,12 +317,11 @@ static int dma_heap_init(void) > if (ret) > return ret; > > - dma_heap_class = class_create(DEVNAME); > - if (IS_ERR(dma_heap_class)) { > + ret = class_register(&dma_heap_class); > + if (ret) { > unregister_chrdev_region(dma_heap_devt, NUM_HEAP_MINORS); > - return PTR_ERR(dma_heap_class); > + return ret; > } > - dma_heap_class->devnode = dma_heap_devnode; > > return 0; > } > > -- > 2.43.0 Reviewed-by: T.J. Mercier <tjmercier(a)google.com> Is this really a resend? I don't see anything on lore and I can't recall seeing this patch in my inbox before.

1 year, 8 months

Re: [PATCH RESEND drm-misc 4/4] dma-buf: heaps: make dma_heap_class constant

by T.J. Mercier

On Tue, Mar 5, 2024 at 10:02 AM Ricardo B. Marliere <ricardo(a)marliere.net> wrote: > > On 5 Mar 09:07, T.J. Mercier wrote: > > > > Reviewed-by: T.J. Mercier <tjmercier(a)google.com> > > > > Is this really a resend? I don't see anything on lore and I can't > > recall seeing this patch in my inbox before. > > Hi T.J. thanks for reviewing! > > I'm sorry about that, I sent the series only to Greg before but I > thought it had Cc'ed the lists as well. Then I realized it was sent > publicly only once. Double mistake :( > > Best regards, > - Ricardo. Cheers, glad I don't have to try to rework my email filters. :)

1 year, 8 months

Re: [PATCH] dma-buf: Add syntax highlighting to code listings in the document

by T.J. Mercier

On Thu, Jan 18, 2024 at 7:33 PM Tommy Chiang <ototot(a)chromium.org> wrote: > > This patch tries to improve the display of the code listing > on The Linux Kernel documentation website for dma-buf [1] . > > Originally, it appears that it was attempting to escape > the '*' character, but looks like it's not necessary (now), > so we are seeing something like '\*' on the webite. > > This patch removes these unnecessary backslashes and adds syntax > highlighting to improve the readability of the code listing. > > [1] https://docs.kernel.org/driver-api/dma-buf.html > > Signed-off-by: Tommy Chiang <ototot(a)chromium.org> > --- > drivers/dma-buf/dma-buf.c | 15 +++++++++------ > 1 file changed, 9 insertions(+), 6 deletions(-) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 8fe5aa67b167..e083a0ab06d7 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -1282,10 +1282,12 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_move_notify, DMA_BUF); > * vmap interface is introduced. Note that on very old 32-bit architectures > * vmalloc space might be limited and result in vmap calls failing. > * > - * Interfaces:: > + * Interfaces: > * > - * void \*dma_buf_vmap(struct dma_buf \*dmabuf, struct iosys_map \*map) > - * void dma_buf_vunmap(struct dma_buf \*dmabuf, struct iosys_map \*map) > + * .. code-block:: c > + * > + * void *dma_buf_vmap(struct dma_buf *dmabuf, struct iosys_map *map) > + * void dma_buf_vunmap(struct dma_buf *dmabuf, struct iosys_map *map) > * > * The vmap call can fail if there is no vmap support in the exporter, or if > * it runs out of vmalloc space. Note that the dma-buf layer keeps a reference > @@ -1342,10 +1344,11 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_move_notify, DMA_BUF); > * enough, since adding interfaces to intercept pagefaults and allow pte > * shootdowns would increase the complexity quite a bit. > * > - * Interface:: > + * Interface: > + * > + * .. code-block:: c > * > - * int dma_buf_mmap(struct dma_buf \*, struct vm_area_struct \*, > - * unsigned long); > + * int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *, unsigned long); > * > * If the importing subsystem simply provides a special-purpose mmap call to > * set up a mapping in userspace, calling do_mmap with &dma_buf.file will > -- > 2.43.0.381.gb435a96ce8-goog Reviewed-by: T.J. Mercier <tjmercier(a)google.com> The code block highlighting is nice.

1 year, 8 months

Re: [PATCH v2 2/2] net: ethernet: ti: am65-cpsw: Add minimal XDP support

by Andrew Lunn

> 3) From 2), am65_cpsw_alloc_skb() function removed and replaced by > netdev_alloc_skb_ip_align(), as used by the driver before -> res = 506 > Conclusion: Here is where the loss comes from. > IOW, My am65_cpsw_alloc_skb() function is not good. > > Initially, I mainly created this 'custom' am65_cpsw_alloc_skb() function > because I thought that none of XDP memory models could be used along > with netdev_alloc_skb_ip_align() function. Was I wrong ? > By creating this custom am65_cpsw_alloc_skb(), I also wanted to handle > the way headroom is reserved differently. What is special about your device? Why would netdev_alloc_skb_ip_align() not work? Andrew

1 year, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig