linux-kernel - [RFC PATCH v2 0/6] Flexible codec clock configuration

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1648448050-15237-1-git-send-email-spujar@nvidia.com>
Date:   Mon, 28 Mar 2022 11:44:04 +0530
From:   Sameer Pujar <spujar@...dia.com>
To:     <broonie@...nel.org>, <lgirdwood@...il.com>, <robh+dt@...nel.org>,
        <krzk+dt@...nel.org>, <perex@...ex.cz>, <tiwai@...e.com>,
        <peter.ujfalusi@...ux.intel.com>,
        <pierre-louis.bossart@...ux.intel.com>
CC:     <oder_chiou@...ltek.com>, <thierry.reding@...il.com>,
        <jonathanh@...dia.com>, <alsa-devel@...a-project.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-tegra@...r.kernel.org>, Sameer Pujar <spujar@...dia.com>
Subject: [RFC PATCH v2 0/6] Flexible codec clock configuration

Typically the codec drivers require setting up of Sysclk. Sometimes
presence of internal PLL can provide more options of Sysclk configuration.
Presently ASoC provides callbacks set_sysclk() and set_pll() in such
cases. However it comes with following limitations considering generic
machine drivers (simple-card or audio-graph-card):

 1. The Sysclk source needs to be passed to set_sysclk() callback.
    Presently simple-card or audio-graph-card card rely on default
    source value (which is 0). If any other source needs to be used,
    it is currently not possible.

 2. The same would be true for codec PLL configuration as well, though
    simple-card or audio-graph-card don't have support yet for the PLL
    configuration.


Earlier attempt[0] to address above was not felt suitable. The suggestion
was to use standard clock based bindings instead.

This RFC series takes RT5659 as a reference and exposes clock relationships
via DT. **This is not in the final shape yet**, but I wanted to get some
valuable feedback to understand if the idea is right. If this appears fine,
this can be extended to other codecs (wherever necessary).

This does not completely remove the need of set_sysclk() callback because
the clock requirement (MCLK * fs) would come from the machine driver. But
machine driver need not worry about Sysclk source. It would be internally
managed by Codec via DT clock relationships.


[0] https://patchwork.kernel.org/project/alsa-devel/list/?series=438531&archive=both&state=*


Changelog:
==========

  v1 -> v2:
  ---------
    * New patch added to convert rt5659 binding doc to YAML format
    * New patch added to document audio-graph-port binding for rt5659
    * New patch added to document clock binding enhancement for rt5659

Sameer Pujar (6):
  ASoC: dt-bindings: Convert rt5659 bindings to YAML schema
  ASoC: dt-bindings: Add audio-graph-port bindings to rt5659
  ASoC: dt-bindings: Extend clock bindings of rt5659
  ASoC: soc-pcm: tweak DPCM BE hw_param() call order
  ASoC: rt5659: Expose internal clock relationships
  ASoC: tegra: Get clock rate in consumer mode

 .../devicetree/bindings/sound/realtek,rt5659.yaml  | 179 +++++++++++++++
 Documentation/devicetree/bindings/sound/rt5659.txt |  89 --------
 sound/soc/codecs/rt5659.c                          | 248 ++++++++++++++++++++-
 sound/soc/codecs/rt5659.h                          |   9 +
 sound/soc/soc-pcm.c                                |  60 ++++-
 sound/soc/tegra/tegra210_i2s.c                     |  25 ++-
 6 files changed, 503 insertions(+), 107 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/sound/realtek,rt5659.yaml
 delete mode 100644 Documentation/devicetree/bindings/sound/rt5659.txt

-- 
2.7.4