From: Krzysztof Kozlowski <krzk@kernel.org>
To: Sameer Pujar <spujar@nvidia.com>,
broonie@kernel.org, lgirdwood@gmail.com, robh+dt@kernel.org,
krzk+dt@kernel.org, perex@perex.cz, tiwai@suse.com,
peter.ujfalusi@linux.intel.com,
pierre-louis.bossart@linux.intel.com
Cc: oder_chiou@realtek.com, thierry.reding@gmail.com,
jonathanh@nvidia.com, alsa-devel@alsa-project.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-tegra@vger.kernel.org
Subject: Re: [RFC PATCH v2 3/6] ASoC: dt-bindings: Extend clock bindings of rt5659
Date: Mon, 28 Mar 2022 10:07:47 +0200 [thread overview]
Message-ID: <5e4e11b5-02b8-e03e-2924-c9f2882921be@kernel.org> (raw)
In-Reply-To: <53d77f33-27e8-3446-d758-3e545eea2db4@nvidia.com>
On 28/03/2022 09:58, Sameer Pujar wrote:
>
> On 28-03-2022 12:36, Krzysztof Kozlowski wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> On 28/03/2022 08:14, Sameer Pujar wrote:
>>> The rt5658 or rt5659 CODEC system clock (SYSCLK) can be derived from
>>> various clock sources. For example it can be derived either from master
>>> clock (MCLK) or by internal PLL. The internal PLL again can take input
>>> clock references from bit clocks (BCLKs) and MCLK. To enable a flexible
>>> clocking configuration the DT binding is extended here.
>>>
>>> It makes use of standard clock bindings and sets up the clock relation
>>> via DT.
>>>
>>> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
>>> Cc: Oder Chiou <oder_chiou@realtek.com>
>>> ---
>>> .../devicetree/bindings/sound/realtek,rt5659.yaml | 53 ++++++++++++++++++++--
>>> 1 file changed, 49 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/sound/realtek,rt5659.yaml b/Documentation/devicetree/bindings/sound/realtek,rt5659.yaml
>>> index b0485b8..0c2f3cb 100644
>>> --- a/Documentation/devicetree/bindings/sound/realtek,rt5659.yaml
>>> +++ b/Documentation/devicetree/bindings/sound/realtek,rt5659.yaml
>>> @@ -29,12 +29,28 @@ properties:
>>> maxItems: 1
>>>
>>> clocks:
>>> - items:
>>> - - description: Master clock (MCLK) to the CODEC
>>> + description: |
>>> + CODEC can receive multiple clock inputs like Master
>>> + clock (MCLK), I2S bit clocks (BCLK1, BCLK2, BCLK3,
>>> + BCLK4). The CODEC SYSCLK can be generated from MCLK
>>> + or internal PLL. In turn PLL can reference from MCLK
>>> + and BCLKs.
>>>
>>> clock-names:
>>> - items:
>>> - - const: mclk
>>> + description: |
>>> + The clock names can be combination of following:
>>> + "mclk" : Master clock
>>> + "pll_ref" : Reference to CODEC PLL clock
>>> + "sysclk" : CODEC SYSCLK
>>> + "^bclk[1-4]$" : Bit clocks to CODEC
>> No, that does not look correct. You allow anything as clock input (even
>> 20 clocks, different names, any order). That's not how DT schema should
>> work and that's not how hardware looks like.
>
>>
>> Usually the clock inputs are always there which also you mentioned in
>> description - "multiple clock inputs". All these clocks should be
>> expected, unless really the wires (physical wires) can be left disconnected.
>
> The CODEC can receive multiple clocks but all the input clocks need not
> be present or connected always. If a specific configuration is needed
> and platform supports such an input, then all these inputs can be added.
> I don't know how to define this detail in the schema. If I make all of
> them expected, then binding check throws errors. If I were to list all
> the possible combinations, the list is going to be big (not sure if this
> would be OK?).
Thanks for explanation. Please differentiate between these two:
1. clock inputs connected, but unused (not needed for driver or for
particular use case),
2. clock inputs really not connected.
For the 1. above, such clock inputs should still be listed in the
bindings and DTS. For the 2. above, such clocks should actually not be
there. How to achieve this depends on number of your combinations. IOW,
how many clocks are physically optional. For some small number of
variations this can be:
oneOf:
- const: mclk
- items:
- const: mclk
- enum:
- bclk1
- bclk2
- bclk3
- bclk4
- items:
- const: mclk
- const: pll_ref
- enum:
- bclk1
- bclk2
- bclk3
- bclk4
For a total flexibility that any clock input can be disconnected, this
should be a list of enums I guess (with minItems). However please find
the clocks always connected and include them if possible in a fixed way
(like this oneOf above).
Best regards,
Krzysztof
next prev parent reply other threads:[~2022-03-28 8:07 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-28 6:14 [RFC PATCH v2 0/6] Flexible codec clock configuration Sameer Pujar
2022-03-28 6:14 ` [RFC PATCH v2 1/6] ASoC: dt-bindings: Convert rt5659 bindings to YAML schema Sameer Pujar
2022-03-28 7:02 ` Krzysztof Kozlowski
2022-03-28 12:51 ` Rob Herring
2022-03-28 13:26 ` Sameer Pujar
2022-03-28 6:14 ` [RFC PATCH v2 2/6] ASoC: dt-bindings: Add audio-graph-port bindings to rt5659 Sameer Pujar
2022-03-28 7:03 ` Krzysztof Kozlowski
2022-03-28 7:58 ` Sameer Pujar
2022-03-28 6:14 ` [RFC PATCH v2 3/6] ASoC: dt-bindings: Extend clock bindings of rt5659 Sameer Pujar
2022-03-28 7:06 ` Krzysztof Kozlowski
2022-03-28 7:58 ` Sameer Pujar
2022-03-28 8:07 ` Krzysztof Kozlowski [this message]
2022-03-28 13:19 ` Sameer Pujar
2022-03-28 13:28 ` Krzysztof Kozlowski
2022-03-29 8:27 ` Sameer Pujar
2022-03-28 6:14 ` [RFC PATCH v2 4/6] ASoC: soc-pcm: tweak DPCM BE hw_param() call order Sameer Pujar
2022-03-28 15:11 ` Amadeusz Sławiński
2022-03-29 8:28 ` Sameer Pujar
2022-03-28 15:29 ` Ranjani Sridharan
2022-03-29 8:31 ` Sameer Pujar
2022-03-28 6:14 ` [RFC PATCH v2 5/6] ASoC: rt5659: Expose internal clock relationships Sameer Pujar
2022-03-28 6:14 ` [RFC PATCH v2 6/6] ASoC: tegra: Get clock rate in consumer mode Sameer Pujar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5e4e11b5-02b8-e03e-2924-c9f2882921be@kernel.org \
--to=krzk@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jonathanh@nvidia.com \
--cc=krzk+dt@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=oder_chiou@realtek.com \
--cc=perex@perex.cz \
--cc=peter.ujfalusi@linux.intel.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=robh+dt@kernel.org \
--cc=spujar@nvidia.com \
--cc=thierry.reding@gmail.com \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).