Re: [RFC PATCH 0/5] Flexible sysclk/pll configuration

[Sameer Pujar <spujar@nvidia.com>]

On 2/25/2021 11:35 PM, Sameer Pujar wrote:
> This series attempts to add flexible system clock (sysclk) and pll
> configuration for the DAI controller from simple card or audio graph
> card.
>
> Sysclk configuration
> ====================
>    Motivation:
>    -----------
>      The problem this tries to address is, some Codecs may have
>      multiple clocks and multiple sources for its sysclk. For example
>      sysclk may depend on MCLK provided by SoC or it may used an
>      internal pll. The simple card or audio graph card driver is
>      generic and can be used on multiple platforms. So if a platform
>      using this driver needs a generic configuration, then the Codec
>      specific stuff cannot be hardcoded in the driver. Hence it would
>      be better if the info is driven from DT, especially from a
>      Codec DAI or endpoint subnode.
>
>    Solution:
>    ---------
>      "system-clock-id" and "system-clock-source" DT properties can be
>      exposed for a flexible sysclk configuration. These properties
>      go into a Codec DAI or endpoint subnode.
>
>      Please note that other sysclk related properties like
>      "system-clock-frequency" and "system-clock-direction-out" are
>      already present.
>
>      Currently snd_soc_dai_set_sysclk() does not have an argument
>      for source. This series adds this additional field and updates
>      all the required drivers. This is needed because ideally sysclk
>      "clk_id" and "source" fields are different. Some drivers are
>      making use of "clk_id" field to program source information.
>      **May be this needs to be corrected going ahead**
>
>
> Pll configuration
> =================
>    Motivation:
>    -----------
>      Similar to sysclk configuration, pll configuration also needs
>      little more flexibility. If a Codec has internal pll and it
>      can be sourced from multiple clocks a specific configuration
>      may be required for a given platform.
>
>      Some of the cases are:
>        - MCLK (supplied by SoC) --> Codec pll -> Codec sysclk
>        - SoC I2S bit clock (BCLK) --> Codec pll -> Codec sysclk
>
>    Solution:
>    ---------
>      Approach is similar to what is done for extending sysclk
>      flexibility. Following DT properties are added to address the
>      same.
>
>        "pll-id"
>        "pll-source"
>        "pll-input-reference"
>        "pll-output-reference"
>        "pll-input-frequency"
>        "pll-output-frequency"
>
>      All these are optional properties. Simple card or audio graph
>      card drivers can use above info and call snd_soc_dai_set_pll()
>      for necessary configuration.
>
> Sameer Pujar (5):
>    ASoC: soc-component: Fix return value of snd_soc_component_set_pll()
>    ASoC: soc-dai: Add sysclk source to snd_soc_dai_set_sysclk()
>    ASoC: audio-graph-card: Add bindings for sysclk and pll
>    ASoC: simple-card-utils: Parse sysclk id and source
>    ASoC: simple-card-utils: Support pll configuration
>
>   .../bindings/sound/audio-graph-port.yaml           |  71 +++++++++
>   include/sound/simple_card_utils.h                  |  35 +++++
>   include/sound/soc-dai.h                            |   4 +-
>   sound/soc/amd/acp-da7219-max98357a.c               |   2 +-
>   sound/soc/amd/acp-rt5645.c                         |   2 +-
>   sound/soc/amd/acp3x-rt5682-max9836.c               |   4 +-
>   sound/soc/atmel/atmel_wm8904.c                     |   2 +-
>   sound/soc/atmel/mchp-i2s-mcc.c                     |   2 +-

[...]

>   sound/soc/ti/omap-mcbsp.c                          |   2 +-
>   sound/soc/ti/omap3pandora.c                        |   4 +-
>   sound/soc/ti/rx51.c                                |   2 +-
>   sound/soc/uniphier/aio-cpu.c                       |   4 +-
>   sound/soc/ux500/ux500_msp_dai.c                    |   2 +-
>   271 files changed, 639 insertions(+), 389 deletions(-)
>

Looks like I missed some files to update which make use of 
snd_soc_dai_set_sysclk(). I will try to fix that. Meanwhile please 
review if the idea is right here.