linux-kernel - Re: [PATCH v3 10/12] dt-bindings: mediatek: mt8188: add audio afe document

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ef251dd7c70a262c5144da3008ea7509f2a35a59.camel@mediatek.com>
Date:   Mon, 19 Dec 2022 05:35:30 +0000
From:   Trevor Wu (吳文良) <Trevor.Wu@...iatek.com>
To:     "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "krzysztof.kozlowski@...aro.org" <krzysztof.kozlowski@...aro.org>,
        "broonie@...nel.org" <broonie@...nel.org>,
        "p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
        "tiwai@...e.com" <tiwai@...e.com>,
        "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        "perex@...ex.cz" <perex@...ex.cz>
CC:     "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        "angelogioacchino.delregno@...labora.com" 
        <angelogioacchino.delregno@...labora.com>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
        Project_Global_Chrome_Upstream_Group 
        <Project_Global_Chrome_Upstream_Group@...iatek.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v3 10/12] dt-bindings: mediatek: mt8188: add audio afe
 document

On Wed, 2022-12-14 at 13:02 +0100, Krzysztof Kozlowski wrote:
> On 13/12/2022 16:06, Trevor Wu (吳文良) wrote:
> > On Mon, 2022-12-12 at 09:40 +0100, Krzysztof Kozlowski wrote:
> > > On 12/12/2022 03:43, Trevor Wu (吳文良) wrote:
> > > > > > 
> > > > > > > > +    uniqueItems: true
> > > > > > > > +    items:
> > > > > > > > +      minimum: 0
> > > > > > > > +      maximum: 15
> > > > > > > > +
> > > > > > > > +  "^mediatek,etdm-in[1-2]-mclk-always-on-rate-hz$":
> > > > > > > > +    description: Specify etdm in mclk output rate for
> > > > > > > > always
> > > > > > > > on
> > > > > > > > case.
> > > > > > > 
> > > > > > > How is it different than assigned-clock-rates?
> > > > > > > 
> > > > > > 
> > > > > > This includes clock enabling at init stage.
> > > > > 
> > > > > assigned-clock-rates are also at init stage. I asked what is
> > > > > different.
> > > > > 
> > > > 
> > > > If the property is used, there are three parts included in dai
> > > > driver
> > > > probe function.
> > > > 
> > > > 1. set clock parent (which APLL)
> > > > 2. set clock rate (MCLK rate)
> > > > 3. enable clock (MCLK On)
> > > > 
> > > > The first two parts can be done by existing dts clock
> > > > properties,
> > > > but
> > > > the last one can't.
> > > > When MCLK should be enabled at boot time and kept on, this
> > > > property
> > > > is used. That's why I say the property is designed for always-
> > > > on
> > > > case.
> > > 
> > > Heh, so the "always on case" means this property enables clock?
> > > How
> > > is
> > > this even DT property? That's not how clocks should be kept
> > > enabled.
> > > You
> > > need proper clock provider and consumer.
> > > 
> > > 
> > 
> > Hi Krzysztof,
> > 
> > Sorry, I don't know it is not appropriate to notify driver that the
> > clock should be ketp enabled after boot.
> > 
> > The original idea is that enabling this clock in the machine
> > driver,
> > but a property to inform machine driver is also required when the
> > machine driver is shared by different codec combination. And it's
> > easier to handle set_rate and set_parent in etdm dai driver, so I
> > put
> > the property here.
> > 
> > Do you mean if the clock consumer(audio codec or external DSP)
> > requries
> > the clock, the consumer should enable the clock by itself?
> 
> Yes, your clocks should have consumers and they keep the clock
> enabled
> when needed. Certain clocks can be marked as IGNORE or CRITICAL to
> keep
> enabled without consumers (or even when consumers disable), but
> that's
> still not a DT property.
> 
> 
Hi Krzysztof,

Got it. If the implementation is not suggested, I will drop the
property in V4 and ask consumer to use existing clock property with
clock control API instead when we have such case.

Thanks,
Trevor



>