Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

3 participants
2908 discussions

[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, 4 months

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

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

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

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

by Mark Brown

On Mon, Feb 26, 2024 at 03:01:38PM +0100, Alexandre Mergnat wrote: > This serie aim to add the following audio support for the Genio 350-evk: > - Playback > - 2ch Headset Jack (Earphone) > - 1ch Line-out Jack (Speaker) > - 8ch HDMI Tx > - Capture > - 1ch DMIC (On-board Digital Microphone) > - 1ch AMIC (On-board Analogic Microphone) > - 1ch Headset Jack (External Analogic Microphone) > > Of course, HDMI playback need the MT8365 display patches [1] and a DTS > change documented in "mediatek,mt8365-mt6357.yaml". Given the number of custom controls here could you please post the output of mixer-test and pcm-test from a system with this driver running next time you post, this will help with review since it checks a bunch of things around the new controls.

1 year, 4 months

Re: [PATCH 02/18] ASoC: dt-bindings: mediatek,mt8365-mt6357: Add audio sound card document

by AngeloGioacchino Del Regno

Il 27/02/24 11:23, Alexandre Mergnat ha scritto: > > > On 26/02/2024 16:30, AngeloGioacchino Del Regno wrote: >> Il 26/02/24 15:01, Alexandre Mergnat ha scritto: >>> Add soundcard bindings for the MT8365 SoC with the MT6357 audio codec. >>> >>> Signed-off-by: Alexandre Mergnat <amergnat(a)baylibre.com> >>> --- >>> .../bindings/sound/mediatek,mt8365-mt6357.yaml | 127 +++++++++++++++++++++ >>> 1 file changed, 127 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8365-mt6357.yaml >>> b/Documentation/devicetree/bindings/sound/mediatek,mt8365-mt6357.yaml >>> new file mode 100644 >>> index 000000000000..f469611ec6b6 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/sound/mediatek,mt8365-mt6357.yaml >>> @@ -0,0 +1,127 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/sound/mediatek,mt8365-mt6357.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: Mediatek MT8365 sound card with MT6357 sound codec. >>> + >>> +maintainers: >>> + - Alexandre Mergnat <amergnat(a)baylibre.com> >>> + >>> +description: >>> + This binding describes the MT8365 sound card. >>> + >>> +properties: >>> + compatible: >>> + const: mediatek,mt8365-mt6357 >>> + >>> + mediatek,hp-pull-down: >>> + description: >>> + Earphone driver positive output stage short to the >>> + audio reference ground. >>> + Default value is false. >>> + type: boolean >>> + >>> + mediatek,micbias0-microvolt: >>> + description: | >> >> description: Selects MIC Bias 0 output voltage >> >>> + Selects MIC Bias 0 output voltage. >>> + [1.7v, 1.8v, 1.9v, 2.0v, 2.1v, 2.5v, 2.6v, 2.7v] >>> + enum: [0, 1, 2, 3, 4, 5, 6, 7] >> >> No, you don't say 0 1 2 3 4 to a property that says "microvolt", that's simply >> wrong. >> >> mediatek,micbias0-microvolt = <2100000>; >> >> ...so you want a binding that says >> enum: [ 1700000, 1800000, this, that, 2700000] >> > > Is it correct if I put "description: Selects MIC Bias 0 output voltage index" ? > No, it's still not correct. You have to pass microvolt values. The driver will then transform the microvolt values to the index and subsequently write the index value to the hardware registers. The bindings shall be generic, in the sense that they shall not express hardware register values... and this is especially true when we have a value that *does* actually have means to be expressed in common units. Besides, in the cases in which there's no common units involved, the values most probably won't be suited for devicetree//bindings, so those would be hardcoded in the driver as platform data. This is not the case, so, please keep this property but specify microvolts in the bindings (and obviously in devicetree). >>> + >>> + mediatek,micbias1-microvolt: >>> + description: | >>> + Selects MIC Bias 1 output voltage. >>> + [1.7v, 1.8v, 1.9v, 2.0v, 2.1v, 2.5v, 2.6v, 2.7v] >>> + enum: [0, 1, 2, 3, 4, 5, 6, 7] >> >> same here. >> >>> + >>> + mediatek,platform: >>> + $ref: /schemas/types.yaml#/definitions/phandle >>> + description: The phandle of MT8365 ASoC platform. >>> + >>> + pinctrl-names: >>> + minItems: 1 >>> + items: >>> + - const: aud_default >>> + - const: aud_dmic >>> + - const: aud_miso_off >>> + - const: aud_miso_on >>> + - const: aud_mosi_off >>> + - const: aud_mosi_on >>> + >>> + vaud28-supply: >>> + description: >>> + 2.8 volt supply for the audio codec >>> + >>> +patternProperties: >>> + "^dai-link-[0-9]+$": >>> + type: object >>> + description: >>> + Container for dai-link level properties and CODEC sub-nodes. >>> + >>> + properties: >>> + codec: >>> + type: object >>> + description: Holds subnode which indicates codec dai. >>> + >>> + properties: >>> + sound-dai: >>> + maxItems: 1 >>> + description: phandle of the codec DAI >>> + >>> + additionalProperties: false >>> + >>> + link-name: >>> + description: >>> + This property corresponds to the name of the BE dai-link to which >>> + we are going to update parameters in this node. >>> + items: >>> + const: 2ND I2S BE >>> + >>> + sound-dai: >>> + maxItems: 1 >>> + description: phandle of the CPU DAI >>> + >>> + additionalProperties: false >>> + >>> + required: >>> + - link-name >>> + - sound-dai >>> + >>> +additionalProperties: false >>> + >>> +required: >>> + - compatible >>> + - mediatek,platform >>> + - pinctrl-names >>> + - vaud28-supply >>> + >>> +examples: >>> + - | >>> + sound { >>> + compatible = "mediatek,mt8365-mt6357"; >>> + mediatek,platform = <&afe>; >> >> Please: >> >> https://docs.kernel.org/devicetree/bindings/dts-coding-style.html > > Is it about the wrong pinctrl-names tab alignment ? > Also, 2ND I2S BE => 2ND_I2S_BE ? > Otherwise, I don't get it sorry. > ...as Krzysztof already clarified, won't repeat :-P Cheers! >> >> Regards, >> Angelo >> >>> + pinctrl-names = "aud_default", >>> + "aud_dmic", >>> + "aud_miso_off", >>> + "aud_miso_on", >>> + "aud_mosi_off", >>> + "aud_mosi_on"; >>> + pinctrl-0 = <&aud_default_pins>; >>> + pinctrl-1 = <&aud_dmic_pins>; >>> + pinctrl-2 = <&aud_miso_off_pins>; >>> + pinctrl-3 = <&aud_miso_on_pins>; >>> + pinctrl-4 = <&aud_mosi_off_pins>; >>> + pinctrl-5 = <&aud_mosi_on_pins>; >>> + vaud28-supply = <&mt6357_vaud28_reg>; >>> + >>> + /* hdmi interface */ >>> + dai-link-0 { >>> + sound-dai = <&afe>; >>> + link-name = "2ND I2S BE"; >>> + >>> + codec { >>> + sound-dai = <&it66121hdmitx>; >>> + }; >>> + }; >>> + }; >>> >> >

1 year, 4 months

Re: [PATCH 02/18] ASoC: dt-bindings: mediatek,mt8365-mt6357: Add audio sound card document

by Krzysztof Kozlowski

On 27/02/2024 11:23, Alexandre Mergnat wrote: >>> + >>> +examples: >>> + - | >>> + sound { >>> + compatible = "mediatek,mt8365-mt6357"; >>> + mediatek,platform = <&afe>; >> >> Please: >> >> https://docs.kernel.org/devicetree/bindings/dts-coding-style.html > > Is it about the wrong pinctrl-names tab alignment ? > Also, 2ND I2S BE => 2ND_I2S_BE ? > Otherwise, I don't get it sorry. Alignment of continued lines, order of properties. Best regards, Krzysztof

1 year, 4 months

Re: [PATCH 08/18] ASoC: mediatek: mt8365: Add DMIC DAI support

by Krzysztof Kozlowski

On 26/02/2024 15:01, Alexandre Mergnat wrote: > Add Digital Micro Device Audio Interface support for MT8365 SoC. > > Signed-off-by: Alexandre Mergnat <amergnat(a)baylibre.com> > + > +static int init_dmic_priv_data(struct mtk_base_afe *afe) > +{ > + struct mt8365_afe_private *afe_priv = afe->platform_priv; > + struct mt8365_dmic_data *dmic_priv; > + struct device_node *np = afe->dev->of_node; > + unsigned int temps[4]; > + int ret; > + > + dmic_priv = devm_kzalloc(afe->dev, sizeof(struct mt8365_dmic_data), > + GFP_KERNEL); You have very inconsistent style of coding. Some patches are done correctly, some repeast known issues. All over. This is sizeof(*). This comment (and all others) apply everywhere, just in case. Best regards, Krzysztof

1 year, 4 months

Re: [PATCH 03/18] dt-bindings: mfd: mediatek: Add codec property for MT6357 PMIC

by Krzysztof Kozlowski

On 26/02/2024 15:01, Alexandre Mergnat wrote: > Add the codec property along with the mt6357.c codec driver support. Describe the hardware, not the Linux drivers. There is no codec driver support in the bindings. https://elixir.bootlin.com/linux/v6.8-rc6/source/Documentation/devicetree/b… > > Signed-off-by: Alexandre Mergnat <amergnat(a)baylibre.com> > --- > Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml > index 37423c2e0fdf..d25a78070744 100644 > --- a/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml > +++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml > @@ -37,6 +37,17 @@ properties: > "#interrupt-cells": > const: 2 > > + codec: > + type: object > + unevaluatedProperties: false > + description: > + MT6357 sound codec. > + properties: > + compatible: > + const: mediatek,mt6357-sound > + required: > + - compatible No resources? Then no need for this node. We have it even documented (if my repeating every time is not enough)... https://elixir.bootlin.com/linux/v6.8-rc6/source/Documentation/devicetree/b… Best regards, Krzysztof

1 year, 4 months

Re: [PATCH 02/18] ASoC: dt-bindings: mediatek,mt8365-mt6357: Add audio sound card document

by Krzysztof Kozlowski

On 26/02/2024 15:01, Alexandre Mergnat wrote: > Add soundcard bindings for the MT8365 SoC with the MT6357 audio codec. > > Signed-off-by: Alexandre Mergnat <amergnat(a)baylibre.com> > --- > .../bindings/sound/mediatek,mt8365-mt6357.yaml | 127 +++++++++++++++++++++ > 1 file changed, 127 insertions(+) > > diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8365-mt6357.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8365-mt6357.yaml > new file mode 100644 > index 000000000000..f469611ec6b6 > --- /dev/null > +++ b/Documentation/devicetree/bindings/sound/mediatek,mt8365-mt6357.yaml > @@ -0,0 +1,127 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/sound/mediatek,mt8365-mt6357.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Mediatek MT8365 sound card with MT6357 sound codec. Drop full stop. This is title. > + > +maintainers: > + - Alexandre Mergnat <amergnat(a)baylibre.com> > + > +description: > + This binding describes the MT8365 sound card. Say something useful. There is no need to say that binding is a binding describing something. Or just drop it if this is obvious. > + > +properties: > + compatible: > + const: mediatek,mt8365-mt6357 > + > + mediatek,hp-pull-down: > + description: > + Earphone driver positive output stage short to the > + audio reference ground. > + Default value is false. That's obvious, isn't it? Drop. > + type: boolean > + > + mediatek,micbias0-microvolt: > + description: | > + Selects MIC Bias 0 output voltage. > + [1.7v, 1.8v, 1.9v, 2.0v, 2.1v, 2.5v, 2.6v, 2.7v] > + enum: [0, 1, 2, 3, 4, 5, 6, 7] 0 is 0V, not 1.7! That's total mess. You use here microvolts. Look at property name. > + > + mediatek,micbias1-microvolt: > + description: | > + Selects MIC Bias 1 output voltage. > + [1.7v, 1.8v, 1.9v, 2.0v, 2.1v, 2.5v, 2.6v, 2.7v] > + enum: [0, 1, 2, 3, 4, 5, 6, 7] > + > + mediatek,platform: > + $ref: /schemas/types.yaml#/definitions/phandle > + description: The phandle of MT8365 ASoC platform. > + > + pinctrl-names: > + minItems: 1 > + items: > + - const: aud_default Drop redundant parts. aud looks like block name. > + - const: aud_dmic > + - const: aud_miso_off > + - const: aud_miso_on > + - const: aud_mosi_off > + - const: aud_mosi_on > + > + vaud28-supply: > + description: > + 2.8 volt supply for the audio codec > + > +patternProperties: > + "^dai-link-[0-9]+$": > + type: object > + description: > + Container for dai-link level properties and CODEC sub-nodes. > + > + properties: > + codec: > + type: object > + description: Holds subnode which indicates codec dai. > + > + properties: > + sound-dai: > + maxItems: 1 > + description: phandle of the codec DAI > + > + additionalProperties: false > + > + link-name: > + description: > + This property corresponds to the name of the BE dai-link to which > + we are going to update parameters in this node. > + items: > + const: 2ND I2S BE > + > + sound-dai: > + maxItems: 1 > + description: phandle of the CPU DAI > + > + additionalProperties: false > + > + required: > + - link-name > + - sound-dai > + > +additionalProperties: false This goes after required: block. See example schema. > + > +required: > + - compatible > + - mediatek,platform > + - pinctrl-names > + - vaud28-supply > + Best regards, Krzysztof

1 year, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig