From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
To: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: broonie@kernel.org, lee.jones@linaro.org,
alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] mfd: arizona: Add gating of external MCLKn clocks
Date: Mon, 22 Aug 2016 10:22:33 +0100 [thread overview]
Message-ID: <20160822092233.GN21682@localhost.localdomain> (raw)
In-Reply-To: <1471627036-19465-1-git-send-email-s.nawrocki@samsung.com>
On Fri, Aug 19, 2016 at 07:17:16PM +0200, Sylwester Nawrocki wrote:
> This patch adds handling of the CODEC's external MCLK{1,2} clocks
> needed for board configurations where these clocks are not always on
> oscillators.
> The 32k source MCLKn clock is basically kept permanently enabled while
> the other MCLKn clock is being gated in the MFD's runtime suspend/resume
> callbacks.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
> I'm not sure it's a correct approach hence only an RFC patch.
> ---
Yeah I am not sure this is quite the correct approach, there are
quite a few corner cases that would not be covered well here. For
example an internally divided down 32k in which case both the 32k
and MCLK would come from the same pin, or using the 32k to feed
an FLL in which case we are trying to enable MCLK1 unnecessarily.
I think we could request the 32k clock source from this part
of the code, but without implementing clock drivers for the
chips internal clocking I think the main MCLK would need to be
requested from the machine driver for now.
On that note, I have been working on a patch chain that adds an
actual clock driver for the chip unfortunately this has been
delayed somewhat due to issues interfacing SPI backed clocks to
the clock framework. Krzysztof Kozlowski has sent a series that
appears to resolve these issues for me so hopefully once the
clock guys have had a look at that I can send my clock driver.
My current implementation mostly just implements the 32k clock
but we can start building that out to include the SYSCLKs and
FLLs etc. fairly quickly. The best thing might be to wait for
that and then build additional features onto that.
Let me know if you want to get an early look at that code.
Thanks,
Charles
next prev parent reply other threads:[~2016-08-22 9:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-19 17:17 [RFC PATCH] mfd: arizona: Add gating of external MCLKn clocks Sylwester Nawrocki
2016-08-22 9:22 ` Charles Keepax [this message]
2016-08-22 17:22 ` [alsa-devel] " Sylwester Nawrocki
2016-08-22 17:41 ` Mark Brown
2016-08-23 16:44 ` Sylwester Nawrocki
2016-08-23 16:28 ` Charles Keepax
2016-08-25 10:18 ` Sylwester Nawrocki
2016-08-25 13:02 ` Charles Keepax
2016-08-25 13:26 ` Sylwester Nawrocki
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=20160822092233.GN21682@localhost.localdomain \
--to=ckeepax@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=s.nawrocki@samsung.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).