Linaro-mm-sig February 2024

linaro-mm-sig@lists.linaro.org

17 participants
45 discussions

[RFC PATCH] dma-buf/dma-fence: Use a successful read_trylock() annotation for dma_fence_begin_signalling()

by Thomas Hellström

Condsider the following call sequence: /* Upper layer */ dma_fence_begin_signalling(); lock(tainted_shared_lock); /* Driver callback */ dma_fence_begin_signalling(); ... The driver might here use a utility that is annotated as intended for the dma-fence signalling critical path. Now if the upper layer isn't correctly annotated yet for whatever reason, resulting in /* Upper layer */ lock(tainted_shared_lock); /* Driver callback */ dma_fence_begin_signalling(); We will receive a false lockdep locking order violation notification from dma_fence_begin_signalling(). However entering a dma-fence signalling critical section itself doesn't block and could not cause a deadlock. So use a successful read_trylock() annotation instead for dma_fence_begin_signalling(). That will make sure that the locking order is correctly registered in the first case, and doesn't register any locking order in the second case. The alternative is of course to make sure that the "Upper layer" is always correctly annotated. But experience shows that's not easily achievable in all cases. Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> --- drivers/dma-buf/dma-fence.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index f177c56269bb..17f632768ef9 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -308,8 +308,8 @@ bool dma_fence_begin_signalling(void) if (in_atomic()) return true; - /* ... and non-recursive readlock */ - lock_acquire(&dma_fence_lockdep_map, 0, 0, 1, 1, NULL, _RET_IP_); + /* ... and non-recursive successful read_trylock */ + lock_acquire(&dma_fence_lockdep_map, 0, 1, 1, 1, NULL, _RET_IP_); return false; } @@ -340,7 +340,7 @@ void __dma_fence_might_wait(void) lock_map_acquire(&dma_fence_lockdep_map); lock_map_release(&dma_fence_lockdep_map); if (tmp) - lock_acquire(&dma_fence_lockdep_map, 0, 0, 1, 1, NULL, _THIS_IP_); + lock_acquire(&dma_fence_lockdep_map, 0, 1, 1, 1, NULL, _THIS_IP_); } #endif -- 2.39.2

6 months, 2 weeks

[PATCH v4 0/7] dma-buf: heaps: Add restricted heap

by Yong Wu

The purpose of this patchset is for MediaTek secure video playback, and also to enable other potential uses of this in the future. The 'restricted dma-heap' will be used to allocate dma_buf objects that reference memory in the secure world that is inaccessible/unmappable by the non-secure (i.e. kernel/userspace) world. That memory will be used by the secure/ trusted world to store secure information (i.e. decrypted media content). The dma_bufs allocated from the kernel will be passed to V4L2 for video decoding (as input and output). They will also be used by the drm system for rendering of the content. This patchset adds two MediaTek restricted heaps and they will be used in v4l2[1] and drm[2]. 1) restricted_mtk_cm: secure chunk memory for MediaTek SVP (Secure Video Path). The buffer is reserved for the secure world after bootup and it is used for vcodec's ES/working buffer; 2) restricted_mtk_cma: secure CMA memory for MediaTek SVP. This buffer is dynamically reserved for the secure world and will be got when we start playing secure videos. Once the security video playing is complete, the CMA will be released. This heap is used for the vcodec's frame buffer. [1] https://lore.kernel.org/linux-mediatek/20231206081538.17056-1-yunfei.dong@m… [2] https://lore.kernel.org/all/20231223182932.27683-1-jason-jh.lin@mediatek.co… Change note: v4: 1) Rename the heap name from "secure" to "restricted". suggested from Simon/Pekka. There are still several "secure" string in MTK file since we use ARM platform in which we call this "secure world"/ "secure command". v3: https://lore.kernel.org/linux-mediatek/20231212024607.3681-1-yong.wu@mediat… 1) Separate the secure heap to a common file(secure_heap.c) and mtk special file (secure_heap_mtk.c), and put all the tee related code into our special file. 2) About dt-binding, Add "mediatek," prefix since this is Mediatek TEE firmware definition. 3) Remove the normal CMA heap which is a draft for qcom. Rebase on v6.7-rc1. v2: https://lore.kernel.org/linux-mediatek/20231111111559.8218-1-yong.wu@mediat… 1) Move John's patches into the vcodec patchset since they use the new dma heap interface directly. https://lore.kernel.org/linux-mediatek/20231106120423.23364-1-yunfei.dong@m… 2) Reword the dt-binding description. 3) Rename the heap name from mtk_svp to secure_mtk_cm. This means the current vcodec/DRM upstream code doesn't match this. 4) Add a normal CMA heap. currently it should be a draft version. 5) Regarding the UUID, I still use hard code, but put it in a private data which allow the others could set their own UUID. What's more, UUID is necessary for the session with TEE. If we don't have it, we can't communicate with the TEE, including the get_uuid interface, which tries to make uuid more generic, not working. If there is other way to make UUID more general, please free to tell me. v1: https://lore.kernel.org/linux-mediatek/20230911023038.30649-1-yong.wu@media… Base on v6.6-rc1. Yong Wu (7): dt-bindings: reserved-memory: Add mediatek,dynamic-restricted-region dma-buf: heaps: Initialize a restricted heap dma-buf: heaps: restricted_heap: Add private heap ops dma-buf: heaps: restricted_heap: Add dma_ops dma-buf: heaps: restricted_heap: Add MediaTek restricted heap and heap_init dma-buf: heaps: restricted_heap_mtk: Add TEE memory service call dma_buf: heaps: restricted_heap_mtk: Add a new CMA heap .../mediatek,dynamic-restricted-region.yaml | 43 +++ drivers/dma-buf/heaps/Kconfig | 16 + drivers/dma-buf/heaps/Makefile | 4 +- drivers/dma-buf/heaps/restricted_heap.c | 237 +++++++++++++ drivers/dma-buf/heaps/restricted_heap.h | 43 +++ drivers/dma-buf/heaps/restricted_heap_mtk.c | 322 ++++++++++++++++++ 6 files changed, 664 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/reserved-memory/mediatek,dynamic-restricted-region.yaml create mode 100644 drivers/dma-buf/heaps/restricted_heap.c create mode 100644 drivers/dma-buf/heaps/restricted_heap.h create mode 100644 drivers/dma-buf/heaps/restricted_heap_mtk.c -- 2.18.0

10 months, 3 weeks

[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

Re: (subset) [PATCH 13/18] mfd: mt6397-core: register mt6357 sound codec

by Lee Jones

On Mon, 26 Feb 2024 15:01:51 +0100, amergnat(a)baylibre.com wrote: > Add MT6357 codec entry in the MFD driver. > > Applied, thanks! [13/18] mfd: mt6397-core: register mt6357 sound codec commit: 79d98102a31ab777b4a6632d799ab2bc63654cf8 -- Lee Jones [李琼斯]

1 year, 1 month

[PATCH v2 0/3] Add GAMMA 12-bit LUT support for MT8188

by Jason-JH.Lin

From: Jason-jh Lin <jason-jh.lin(a)mediatek.corp-partner.google.com> Since MT8195 supports GAMMA 12-bit LUT after the landing of [1] series, we can now add support for MT8188. [1] MediaTek DDP GAMMA - 12-bit LUT support - https://patchwork.kernel.org/project/linux-mediatek/list/?series=792516 Change in v2: 1. Keep MT8195 compatible in the group of MT8183. 2. Move MT8195 compatible group to the end of items list. Jason-JH.Lin (3): dt-bindings: display: mediatek: gamma: Change MT8195 to single enum group dt-bindings: display: mediatek: gamma: Add support for MT8188 drm/mediatek: Add gamma support for MT8195 .../devicetree/bindings/display/mediatek/mediatek,gamma.yaml | 5 +++++ drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 ++ 2 files changed, 7 insertions(+) -- 2.18.0

1 year, 1 month

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

by Andrew Lunn

On Thu, Feb 29, 2024 at 05:19:44PM +0100, Julien Panis wrote: > On 2/27/24 00:18, Andrew Lunn wrote: > > > +static struct sk_buff *am65_cpsw_alloc_skb(struct net_device *ndev, unsigned int len) > > > +{ > > > + struct page *page; > > > + struct sk_buff *skb; > > > + > > > + page = dev_alloc_pages(0); > > You are likely to get better performance if you use the page_pool. > > > > When FEC added XDP support, the first set of changes was to make use > > of page_pool. That improved the drivers performance. Then XDP was > > added on top. Maybe you can follow that pattern. > > > > Andrew > > Hello Andrew, > > Thanks for this suggestion. I've been working on it over the last days. > I encountered issues and I begin to wonder if that's a good option for > this driver. Let me explain... I'm not a page pool expert, so hopefully those that are will jump in and help. > This device has 3 ports: > - Port0 is the host port (internal to the subsystem and referred as CPPI > in the driver). > - Port1 and 2 are the external ethernet ports. > Each port's RX FIFO has 1 queue. > > As mentioned in page_pool documentation: > https://docs.kernel.org/networking/page_pool.html > "The number of pools created MUST match the number of hardware > queues unless hardware restrictions make that impossible. This would > otherwise beat the purpose of page pool, which is allocate pages fast > from cache without locking." My guess is, this last bit is the important part. Locking. Do ports 1 and port 2 rx and tx run in parallel on different CPUs? Hence do you need locking? > So, for this driver I should use 2 page pools (for port1 and 2) if possible. Maybe, maybe not. It is not really the number of front panel interface which matters here. It is the number of entities which need buffers. > But, if I I replace any alloc_skb() with page_pool_alloc() in the original > driver, I will have to create only 1 page_pool. > This is visible in am65_cpsw_nuss_common_open(), which starts with: > "if (common->usage_count) return 0;" to ensure that subsequent code > will be executed only once even if the 2 interfaces are ndo_open'd. > IOW, skbs will be allocated for only 1 RX channel. I checked that behavior, > and that's the way it works. > This is because the host port (CPPI) has only 1 RX queue. This single > queue is used to get all the packets, from both Ports and 2 (port ID is > stored in each descriptor). So you have one entity which needs buffers. CPPI. It seems like Port1 and Port2 do not need buffers? So to me, you need one page pool. > So, because of this constraint, I ended up working on the "single > page pool" option. > > Questions: > 1) Is the behavior described above usual for ethernet switch devices ? This might be the first time page pool has been used by a switch? I would check the melanox and sparx5 driver and see if they use page pool. > 2) Given that I can't use a page pool for each HW queue, is it worth > using the page pool memory model ? > 3) Currently I use 2 xdp_rxq (one for port1 and another one for port2). > If an XDP program is attached to port1, my page pool dma parameter > will need to be DMA_BIDIRECTIONAL (because of XDP_TX). As a result, > even if there is no XDP program attached to port2, the setting for page > pool will need to be DMA_BIDIRECTIONAL instead of DMA_FROM_DEVICE. > In such situation, isn't it a problem for port2 ? > 4) Because of 1) and 2), will page pool performance really be better for > this driver ? You probably need to explain the TX architecture a bit. How are packets passed to the hardware? Is it again via a single CPPI entity? Or are there two entities? DMA_BIDIRECTIONAL and DMA_FROM_DEVICE is about cache flushing and invalidation. Before you pass a buffer to the hardware for it to receive into, you need to invalidate the cache. That means when the hardware gives the buffer back with a packet in it, there is a cache miss and it fetches the new data from memory. If that packet gets turned into an XDP_TX, you need to flush the cache to force any changes out of the cache and into memory. The DMA from memory then gets the up to date packet contents. My guess would be, always using DMA_BIDIRECTIONAL is fine, so long as your cache operations are correct. Turn on DMA_API_DEBUG and make sure it is happy. Andrew

1 year, 1 month

[PATCH 0/3] Add GAMMA 12-bit LUT support for MT8188

by Jason-JH.Lin

From: Jason-jh Lin <jason-jh.lin(a)mediatek.corp-partner.google.com> Since MT8195 supports GAMMA 12-bit LUT after the landing of [1] series, we can now add support for MT8188. [1] MediaTek DDP GAMMA - 12-bit LUT support - https://patchwork.kernel.org/project/linux-mediatek/list/?series=792516 Jason-JH.Lin (3): dt-bindings: display: mediatek: gamma: Change MT8195 to single enum group dt-bindings: display: mediatek: gamma: Add support for MT8188 drm/mediatek: Add gamma support for MT8195 .../bindings/display/mediatek/mediatek,gamma.yaml | 6 +++++- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 ++ 2 files changed, 7 insertions(+), 1 deletion(-) -- 2.18.0

1 year, 1 month

Re: ECC memory semantics for heaps

by John Stultz

On Wed, Feb 28, 2024 at 7:24 AM Maxime Ripard <mripard(a)redhat.com> wrote: > > I'm currently working on a platform that seems to have togglable RAM ECC > support. Enabling ECC reduces the memory capacity and memory bandwidth, > so while it's a good idea to protect most of the system, it's not worth > it for things like framebuffers that won't really be affected by a > bitflip. > > It's currently setup by enabling ECC on the entire memory, and then > having a region of memory where ECC is disabled and where we're supposed > to allocate from for allocations that don't need it. > > My first thought to support this was to create a reserved memory region > for the !ECC memory, and to create a heap to allocate buffers from that > region. That would leave the system protected by ECC, while enabling > userspace to be nicer to the system by allocating buffers from the !ECC > region if it doesn't need it. > > However, this creates basically a new combination compared to the one we > already have (ie, physically contiguous vs virtually contiguous), and we > probably would want to throw in cacheable vs non-cacheable too. > > If we had to provide new heaps for each variation, we would have 8 heaps > (and 6 new ones), which could be fine I guess but would still increase > quite a lot the number of heaps we have so far. > > Is it something that would be a problem? If it is, do you see another > way to support those kind of allocations (like providing hints through > the ioctl maybe?)? So, the dma-buf heaps interface uses chardevs so that we can have a lot of flexibility in the types of heaps (and don't have the risk of bitmask exhaustion like ION had). So I don't see adding many differently named heaps as particularly problematic. That said, if there are truly generic properties (cacheable vs non-cachable is maybe one of those) which apply to most heaps, I'm open to making use of the flags. But I want to avoid having per-heap flags, it really needs to be a generic attribute. And I personally don't mind the idea of having things added as heaps initially, and potentially upgrading them to flags if needed (allowing heap drivers to optionally enumerate the old chardevs behind a config option for backwards compatibility). How common is the hardware that is going to provide this configurable ECC option, and will you really want the option on all of the heap types? Will there be any hardware constraint limitations caused by the ECC/!ECC flags? (ie: Devices that can't use !ECC allocated buffers?) If not, I wonder if it would make sense to have something more along the lines using a fcntl() like how F_SEAL_* is used with memfds? With some of the discussion around "restricted"/"secure" heaps that can change state, I've liked this idea of just allocating dmabufs from normal heaps and then using fcntl or something similar to modify properties of the buffer that are separate from the type of memory that is needed to be allocated to satisfy device constraints. thanks -john

1 year, 1 month

Re: [PATCH 01/18] ASoC: dt-bindings: mediatek,mt8365-afe: Add audio afe document

by AngeloGioacchino Del Regno

Il 28/02/24 10:57, Alexandre Mergnat ha scritto: > I think I got it. > > - mediatek,i2s-shared-clock: will be remove from DT > - mediatek,dmic-iir-on: will be remove from DT > - mediatek,dmic-irr-mode: will be remove from DT > - mediatek,dmic-two-wire-mode: rephrase description needed > > I've did abstraction (despite me) that IIR settings are runtime config because the > driver implement its usage like a one-time-setup -_-' > Yes but just one more thing I just noticed: `mediatek,dmic-two-wire-mode` - can we please rename this to `mediatek,dmic-mode` ? That'd be for consistency check mt6359.yaml and mt6358.txt mediatek,dmic-mode: $ref: /schemas/types.yaml#/definitions/uint32 description: | Indicates how many data pins are used to transmit two channels of PDM signal. 0 means two wires, 1 means one wire. Default value is 0. enum: - 0 # one wire - 1 # two wires Cheers, Angelo > Thanks for the explanations, that help. > > Regards, > Alexandre > > On 28/02/2024 08:28, Krzysztof Kozlowski wrote: >> On 27/02/2024 16:18, Alexandre Mergnat wrote: >>>> >>>>> + type: boolean >>>>> + >>>>> + mediatek,dmic-iir-on: >>>>> + description: >>>>> + Boolean which specifies whether the DMIC IIR is enabled. >>>>> + If this property is not present the IIR is disabled. >>>> >>>> "is enabled" or "enable it"? >>>> >>>> You described the desired Linux feature or behavior, not the actual >>>> hardware. The bindings are about the latter, so instead you need to >>>> rephrase the property and its description to match actual hardware >>>> capabilities/features/configuration etc. >>> >>> I will rephrase: >>> >>> True to enable the Infinite Impulse Response (IIR) filter >>> on the digital microphone inputs. >> >> I still don't know why this is DT-specific. You still tell driver what >> to do... >> >>> >>>> >>>>> + type: boolean >>>>> + >>>>> + mediatek,dmic-irr-mode: >>>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>>> + description: >>>>> + Selects stop band of IIR DC-removal filter. >>>>> + 0 = Software programmable custom coeff loaded by the driver. >>>> >>>> Bindings are for hardware, not drivers. Why is this a property of board DTS? >>> >>> Actually this is a hardware feature. Mode 1 t 5 are predefined filters. >>> Mode 0, the HW will read some "coef filter registers" to setup the >>> custom filter. the "coef filter regs" are written by the driver. >>> Currently the coef values are hardcoded in the driver. >> >> You don't get the point. Just because you choose some mode it does not >> mean is hardware feature for DT. Sampling frequency done by hardware is >> also "hardware feature", but do you put it to DT? No. >> >> Explain why this is board-specific, not runtime configuration. >> >>> >>>> >>>>> + 1 = 5Hz if 48KHz mode. >>>>> + 2 = 10Hz if 48KHz mode. >>>>> + 3 = 25Hz if 48KHz mode. >>>>> + 4 = 50Hz if 48KHz mode. >>>>> + 5 = 65Hz if 48KHz mode. >>>> >>>> Use proper unit suffixes - hz. >>>> >>>> >>>>> + enum: >>>>> + - 0 >>>>> + - 1 >>>>> + - 2 >>>>> + - 3 >>>>> + - 4 >>>>> + - 5 >>>>> + >>>>> + mediatek,dmic-two-wire-mode: >>>>> + description: >>>>> + Boolean which turns on digital microphone for two wire mode. >>>>> + If this property is not present the two wire mode is disabled. >>>> >>>> This looks like hardware property, but the naming looks like SW. Again >>>> you instruct what driver should do. Standard disclaimer: >>>> >>>> You described the desired Linux feature or behavior, not the actual >>>> hardware. The bindings are about the latter, so instead you need to >>>> rephrase the property and its description to match actual hardware >>>> capabilities/features/configuration etc. >>> >>> Actually this is a hardware feature. This is ALL I have to describe the >>> HW behavior from the datasheet: >>> " >>> bit name: ul_dmic_two_wire_ctl >>> Turns on digital microphone for two wire mode. >>> 0: Turn off >>> 1: Turn on >> >> That's rather suggestion it is not a description of hardware but you >> want driver to do something... >> >>> " >>> >>> On the board schematic, SoC and DMIC and linked by 3 pins: >>> - clk >>> - data0 >>> - data1 >>> >>> IMHO, "two-wire-mode" means the HW use 2 pins for data, and the SoC must >>> be aware of that by reading the register value written by the driver, >>> using the value found in the DTS. >> >> So this depends on type of connection of DMIC? Then rephrase description >> property like this. >> >>> >>> I don't get why you think it wouldn't be hardware behavior. >> >> Because telling what to write to the registers which is typical sign of >> people stuffing to DT whatever they need to configure the hardware. >> >>> >>> Rephrase description: >>> "True to enable the two wire mode of the digital microphone" >>> Is it better ? >> >> No, because again you describe some sort of mode. If you insist on such >> description, then my answer is: it's runtime, so not suitable for DT. >> Instead describe what is the hardware problem/configuration, e.g. "DMIC >> is connected with only CLK and DATA0, without third pin" etc. >> >>> >>> About the property name, "mediatek,dmic-two-wire-ctl" sound better for you ? >> >> To sound more like a register less like physical characteristic of the >> board? No. The name can stay, I don't have better ideas. >> >> >> Best regards, >> Krzysztof >> >

1 year, 1 month

Re: [PATCH 01/18] ASoC: dt-bindings: mediatek,mt8365-afe: Add audio afe document

by Krzysztof Kozlowski

On 27/02/2024 16:18, Alexandre Mergnat wrote: >> >>> + type: boolean >>> + >>> + mediatek,dmic-iir-on: >>> + description: >>> + Boolean which specifies whether the DMIC IIR is enabled. >>> + If this property is not present the IIR is disabled. >> >> "is enabled" or "enable it"? >> >> You described the desired Linux feature or behavior, not the actual >> hardware. The bindings are about the latter, so instead you need to >> rephrase the property and its description to match actual hardware >> capabilities/features/configuration etc. > > I will rephrase: > > True to enable the Infinite Impulse Response (IIR) filter > on the digital microphone inputs. I still don't know why this is DT-specific. You still tell driver what to do... > >> >>> + type: boolean >>> + >>> + mediatek,dmic-irr-mode: >>> + $ref: /schemas/types.yaml#/definitions/uint32 >>> + description: >>> + Selects stop band of IIR DC-removal filter. >>> + 0 = Software programmable custom coeff loaded by the driver. >> >> Bindings are for hardware, not drivers. Why is this a property of board DTS? > > Actually this is a hardware feature. Mode 1 t 5 are predefined filters. > Mode 0, the HW will read some "coef filter registers" to setup the > custom filter. the "coef filter regs" are written by the driver. > Currently the coef values are hardcoded in the driver. You don't get the point. Just because you choose some mode it does not mean is hardware feature for DT. Sampling frequency done by hardware is also "hardware feature", but do you put it to DT? No. Explain why this is board-specific, not runtime configuration. > >> >>> + 1 = 5Hz if 48KHz mode. >>> + 2 = 10Hz if 48KHz mode. >>> + 3 = 25Hz if 48KHz mode. >>> + 4 = 50Hz if 48KHz mode. >>> + 5 = 65Hz if 48KHz mode. >> >> Use proper unit suffixes - hz. >> >> >>> + enum: >>> + - 0 >>> + - 1 >>> + - 2 >>> + - 3 >>> + - 4 >>> + - 5 >>> + >>> + mediatek,dmic-two-wire-mode: >>> + description: >>> + Boolean which turns on digital microphone for two wire mode. >>> + If this property is not present the two wire mode is disabled. >> >> This looks like hardware property, but the naming looks like SW. Again >> you instruct what driver should do. Standard disclaimer: >> >> You described the desired Linux feature or behavior, not the actual >> hardware. The bindings are about the latter, so instead you need to >> rephrase the property and its description to match actual hardware >> capabilities/features/configuration etc. > > Actually this is a hardware feature. This is ALL I have to describe the > HW behavior from the datasheet: > " > bit name: ul_dmic_two_wire_ctl > Turns on digital microphone for two wire mode. > 0: Turn off > 1: Turn on That's rather suggestion it is not a description of hardware but you want driver to do something... > " > > On the board schematic, SoC and DMIC and linked by 3 pins: > - clk > - data0 > - data1 > > IMHO, "two-wire-mode" means the HW use 2 pins for data, and the SoC must > be aware of that by reading the register value written by the driver, > using the value found in the DTS. So this depends on type of connection of DMIC? Then rephrase description property like this. > > I don't get why you think it wouldn't be hardware behavior. Because telling what to write to the registers which is typical sign of people stuffing to DT whatever they need to configure the hardware. > > Rephrase description: > "True to enable the two wire mode of the digital microphone" > Is it better ? No, because again you describe some sort of mode. If you insist on such description, then my answer is: it's runtime, so not suitable for DT. Instead describe what is the hardware problem/configuration, e.g. "DMIC is connected with only CLK and DATA0, without third pin" etc. > > About the property name, "mediatek,dmic-two-wire-ctl" sound better for you ? To sound more like a register less like physical characteristic of the board? No. The name can stay, I don't have better ideas. Best regards, Krzysztof

1 year, 1 month

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig February 2024