From: olivier.moysan@st.com (Olivier MOYSAN)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 2/2] ASoC: select sysclk clock from mlck clock provider in wm8994 driver
Date: Wed, 20 Dec 2017 12:42:10 +0000 [thread overview]
Message-ID: <c51bf5a8-27f7-6d76-f4fb-c8884387bdca@st.com> (raw)
In-Reply-To: <20171219093506.GD8563@sirena.org.uk>
Hello Mark,
On 12/19/2017 10:35 AM, Mark Brown wrote:
> On Fri, Dec 15, 2017 at 03:15:22PM +0000, Olivier MOYSAN wrote:
>
>> You are right. wm8994 allows to select either MCLK for each AIF.
>> From this point of view, the current patch is too limiting.
>> MCLK information in DT allows to enforce MCLK use, but an additionnal
>> information is required to determine AIF MCLK assignment.
>> Available properties in codec DAI node, such as clocks property, cannot
>> help here.
>
>> Maybe a DAPM linked to a control is a better way to select AIF source,
>> When source is not provided by clk_id in wm8994_set_dai_sysclk().
>> In this case, wm8994_set_dai_sysclk() would only have to check
>> if clock source is not already set.
>
>> Please let me know if this option sounds better to you.
>
> What are you trying to accomplish here? You appear to be trying to move
> the system clocking configuration from the machine driver to the CODEC
> which is not how things are supposed to work.
>
As a generic machine, simple or audio graph cards are not able to manage
codec clock muxing.
If we exclude the management of muxing through codec controls,
the remaining solution is to handle it fully through clock framework.
The current patch only supports a limited range of muxing capabilities
of the codec.
To have a full management of the muxing, I think it is necessary to add
a device tree node for each codec interface and to define an aif clock
in these nodes.
Then parent clock assignment of these aif clocks would allow to handle
the muxing.
Please, let me known if is this the right direction for you.
BRs
olivier
next prev parent reply other threads:[~2017-12-20 12:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-14 16:53 [RFC PATCH 0/2] select master clock in wm8994 driver based on DT clocks configuration Olivier Moysan
2017-12-14 16:53 ` [RFC PATCH 1/2] ASoC: add support of mclk clock providers in wm8894 driver Olivier Moysan
[not found] ` <20171214173025.GL9788@sirena.org.uk>
2017-12-15 11:51 ` Charles Keepax
2017-12-14 16:53 ` [RFC PATCH 2/2] ASoC: select sysclk clock from mlck clock provider in wm8994 driver Olivier Moysan
[not found] ` <20171214173624.GM9788@sirena.org.uk>
2017-12-15 11:46 ` Charles Keepax
2017-12-15 15:15 ` Olivier MOYSAN
2017-12-19 9:35 ` Mark Brown
2017-12-20 12:42 ` Olivier MOYSAN [this message]
[not found] ` <20171220155000.GD17890@sirena.org.uk>
2017-12-21 10:51 ` Olivier MOYSAN
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=c51bf5a8-27f7-6d76-f4fb-c8884387bdca@st.com \
--to=olivier.moysan@st.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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).