| Message ID | 1614276364-13655-4-git-send-email-spujar@nvidia.com |
|---|---|
| State | New |
| Headers | show |
| Series | Flexible sysclk/pll configuration | expand |
On Thu, Feb 25, 2021 at 12:06 PM Sameer Pujar <spujar@nvidia.com> wrote: > > ASoC core provides callbacks snd_soc_dai_set_sysclk() and > snd_soc_dai_set_pll() for system clock (sysclk) and pll configurations > respectively. Add bindings for flexible sysclk or pll configurations > which can be driven from CPU/Codec DAI or endpoint subnode from DT. > This in turn helps to avoid hard codings in driver and makes it more > generic. > > Also add system-clock related bindings, "system-clock-direction-out" > and "system-clock-frequency", which are already supported. This all looks like duplication of what the clock binding can provide. We don't need 2 ways to describe clocks in DT. Rob
On 3/2/2021 7:40 AM, Rob Herring wrote: > External email: Use caution opening links or attachments > > > On Thu, Feb 25, 2021 at 12:06 PM Sameer Pujar <spujar@nvidia.com> wrote: >> ASoC core provides callbacks snd_soc_dai_set_sysclk() and >> snd_soc_dai_set_pll() for system clock (sysclk) and pll configurations >> respectively. Add bindings for flexible sysclk or pll configurations >> which can be driven from CPU/Codec DAI or endpoint subnode from DT. >> This in turn helps to avoid hard codings in driver and makes it more >> generic. >> >> Also add system-clock related bindings, "system-clock-direction-out" >> and "system-clock-frequency", which are already supported. > This all looks like duplication of what the clock binding can provide. > We don't need 2 ways to describe clocks in DT. This was targetted for external audio codecs. Their internal clock management is not exposed with the clock framework. Instead ASoC provides callbacks to set this up on Codec side. There are many references where this is followed with some hardcoded settings in the drivers. Are you suggesting to instead expose codec internal clocks and manage via generic clock bindings? Would this mean each codec driver has to implement these clock APIs (for ex: set_rate()) and program registers accordingly? For a platform, different audio cards can be plugged in. In that case, each codec has to be updated to follow this. Wouldn't it be simpler to use available ASoC callbacks?
On Tue, Mar 02, 2021 at 12:33:04PM +0530, Sameer Pujar wrote: > This was targetted for external audio codecs. Their internal clock > management is not exposed with the clock framework. Instead ASoC provides > callbacks to set this up on Codec side. There are many references where this > is followed with some hardcoded settings in the drivers. > Are you suggesting to instead expose codec internal clocks and manage via > generic clock bindings? Would this mean each codec driver has to implement > these clock APIs (for ex: set_rate()) and program registers accordingly? Yes, that's what we should be doing. > For a platform, different audio cards can be plugged in. In that case, each > codec has to be updated to follow this. Wouldn't it be simpler to use > available ASoC callbacks? If we want to use standard DT to describe things we need to use standard bindings to do it.
diff --git a/Documentation/devicetree/bindings/sound/audio-graph-port.yaml b/Documentation/devicetree/bindings/sound/audio-graph-port.yaml index 766e910..4f50291 100644 --- a/Documentation/devicetree/bindings/sound/audio-graph-port.yaml +++ b/Documentation/devicetree/bindings/sound/audio-graph-port.yaml @@ -71,6 +71,77 @@ properties: description: CPU to Codec rate channels. $ref: /schemas/types.yaml#/definitions/uint32 + system-clock-frequency: + description: | + Specify system clock (sysclk) frequency for CPU or Codec + component. Or if a clock is specified in the CPU or Codec + device node and a scaling factor is given with "mclk-fs", + sysclk will be calculated as a multiple of stream sample + rate and "mclk-fs". The rate is updated when stream starts. + $ref: /schemas/types.yaml#/definitions/uint32 + + system-clock-direction-out: + description: | + Specifies clock direction as "out" on initialization. It + is useful for some CPUs with fixed clocks. + $ref: /schemas/types.yaml#/definitions/flag + + system-clock-id: + description: | + CPU or Codec component may have multiple clocks. A specific + clock may have to be configured. In such cases the clock + ID needs to be specified. + $ref: /schemas/types.yaml#/definitions/uint32 + + system-clock-source: + description: | + CPU or Codec component may have multiple sources for its + system clock (sysclk). In such cases the sysclk source + needs to be specified. + $ref: /schemas/types.yaml#/definitions/uint32 + + pll-id: + description: | + Specify PLL that needs to be configured. This is useful + when the CPU or Codec component has multiple PLLs. + $ref: /schemas/types.yaml#/definitions/uint32 + + pll-source: + description: | + When PLL has multiple reference clock sources, the exact + source needs to be specified for the required configuration. + $ref: /schemas/types.yaml#/definitions/uint32 + + pll-input-reference: + description: | + Specify how to calculate input frequency for the PLL. + Depending on the identifier, input frequency can be + calculated at runtime. For example if I2S bit clock is used + as reference, rate depends on actual PCM parameters (rate, + channels and bits) during an audio session. If a fixed rate + is used, then "pll-input-frequency" can be used instead. + $ref: /schemas/types.yaml#/definitions/uint32 + const: 2 + + pll-input-frequency: + description: Specify fixed input frequency + $ref: /schemas/types.yaml#/definitions/uint32 + + pll-output-reference: + description: | + Specify how to calculate output frequency for the PLL. + Depending on the identifier, output frequency can be + calculated at runtime. If output clock is used for MCLK purpose, + then it may depend on "mclk-fs" scale factor. In such cases it + needs to be calculated at runtime. If a fixed output frequency + is needed, then "pll-output-frequency" can be used instead. + $ref: /schemas/types.yaml#/definitions/uint32 + const: 1 + + pll-output-frequency: + description: Specify fixed output frequency + $ref: /schemas/types.yaml#/definitions/uint32 + ports: description: multi OF-Graph subnode type: object
ASoC core provides callbacks snd_soc_dai_set_sysclk() and snd_soc_dai_set_pll() for system clock (sysclk) and pll configurations respectively. Add bindings for flexible sysclk or pll configurations which can be driven from CPU/Codec DAI or endpoint subnode from DT. This in turn helps to avoid hard codings in driver and makes it more generic. Also add system-clock related bindings, "system-clock-direction-out" and "system-clock-frequency", which are already supported. Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Cc: Rob Herring <robh@kernel.org> Signed-off-by: Sameer Pujar <spujar@nvidia.com> --- .../bindings/sound/audio-graph-port.yaml | 71 ++++++++++++++++++++++ 1 file changed, 71 insertions(+)