From: Bo Shen <voice.shen@atmel.com>
To: Mark Brown <broonie@kernel.org>, Manuel Lauss <manuel.lauss@gmail.com>
Cc: Manuel Lauss <manuel.lauss@googlemail.com>,
Liam Girdwood <lrg@slimlogic.co.uk>,
Richard Purdie <richard@openedhand.com>,
patches@opensource.wolfsonmicro.com, linux-sound@vger.kernel.org,
alsa-devel <alsa-devel@alsa-project.org>,
linux-arm-kernel@lists.infradead.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] ASoC: wm8731: let codec to manage clock by itself
Date: Wed, 4 Feb 2015 11:45:29 +0800 [thread overview]
Message-ID: <54D195D9.4090101@atmel.com> (raw)
In-Reply-To: <20150203162128.GP21293@sirena.org.uk>
Hi Mark,
On 02/04/2015 12:21 AM, Mark Brown wrote:
> On Tue, Feb 03, 2015 at 03:40:45PM +0100, Manuel Lauss wrote:
>> On Tue, Feb 3, 2015 at 1:44 PM, Mark Brown <broonie@kernel.org> wrote:
>
>>>> + wm8731->mclk = devm_clk_get(&spi->dev, "mclk");
>>>> + if (IS_ERR(wm8731->mclk)) {
>>>> + wm8731->mclk = NULL;
>>>> + dev_warn(&spi->dev, "assuming static MCLK\n");
>>>> + }
>
>>> This is broken for both deferred probe and in the case where the clock
>>> API genuinely returns a NULL clock. Other than that it's the kind of
>>> thing that we've done for some other drivers, though it's not good to
>>> have to do this. Check them for correct behaviour.
>
>> Hm, so the only option is to create the simples possible 12MHz clk object?
>
> Well, that's the best option in general. You can get away with just
> making sure that -EPROBE_DEFER is handled and that IS_ERR() is used to
> check for an invalid clock but if you can define a clock that's even
> better (and should be pretty painless), we're going to want to do that
> transition at some point.
Do you mean I send my RFC patch as the formal patch, and let other
boards which use the wm8731 to add clk object, am I right?
Best Regards,
Bo Shen
WARNING: multiple messages have this Message-ID (diff)
From: Bo Shen <voice.shen@atmel.com>
To: Mark Brown <broonie@kernel.org>, Manuel Lauss <manuel.lauss@gmail.com>
Cc: Manuel Lauss <manuel.lauss@googlemail.com>,
Liam Girdwood <lrg@slimlogic.co.uk>,
Richard Purdie <richard@openedhand.com>,
patches@opensource.wolfsonmicro.com, linux-sound@vger.kernel.org,
alsa-devel <alsa-devel@alsa-project.org>,
linux-arm-kernel@lists.infradead.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] ASoC: wm8731: let codec to manage clock by itself
Date: Wed, 04 Feb 2015 03:45:29 +0000 [thread overview]
Message-ID: <54D195D9.4090101@atmel.com> (raw)
In-Reply-To: <20150203162128.GP21293@sirena.org.uk>
Hi Mark,
On 02/04/2015 12:21 AM, Mark Brown wrote:
> On Tue, Feb 03, 2015 at 03:40:45PM +0100, Manuel Lauss wrote:
>> On Tue, Feb 3, 2015 at 1:44 PM, Mark Brown <broonie@kernel.org> wrote:
>
>>>> + wm8731->mclk = devm_clk_get(&spi->dev, "mclk");
>>>> + if (IS_ERR(wm8731->mclk)) {
>>>> + wm8731->mclk = NULL;
>>>> + dev_warn(&spi->dev, "assuming static MCLK\n");
>>>> + }
>
>>> This is broken for both deferred probe and in the case where the clock
>>> API genuinely returns a NULL clock. Other than that it's the kind of
>>> thing that we've done for some other drivers, though it's not good to
>>> have to do this. Check them for correct behaviour.
>
>> Hm, so the only option is to create the simples possible 12MHz clk object?
>
> Well, that's the best option in general. You can get away with just
> making sure that -EPROBE_DEFER is handled and that IS_ERR() is used to
> check for an invalid clock but if you can define a clock that's even
> better (and should be pretty painless), we're going to want to do that
> transition at some point.
Do you mean I send my RFC patch as the formal patch, and let other
boards which use the wm8731 to add clk object, am I right?
Best Regards,
Bo Shen
WARNING: multiple messages have this Message-ID (diff)
From: voice.shen@atmel.com (Bo Shen)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] ASoC: wm8731: let codec to manage clock by itself
Date: Wed, 4 Feb 2015 11:45:29 +0800 [thread overview]
Message-ID: <54D195D9.4090101@atmel.com> (raw)
In-Reply-To: <20150203162128.GP21293@sirena.org.uk>
Hi Mark,
On 02/04/2015 12:21 AM, Mark Brown wrote:
> On Tue, Feb 03, 2015 at 03:40:45PM +0100, Manuel Lauss wrote:
>> On Tue, Feb 3, 2015 at 1:44 PM, Mark Brown <broonie@kernel.org> wrote:
>
>>>> + wm8731->mclk = devm_clk_get(&spi->dev, "mclk");
>>>> + if (IS_ERR(wm8731->mclk)) {
>>>> + wm8731->mclk = NULL;
>>>> + dev_warn(&spi->dev, "assuming static MCLK\n");
>>>> + }
>
>>> This is broken for both deferred probe and in the case where the clock
>>> API genuinely returns a NULL clock. Other than that it's the kind of
>>> thing that we've done for some other drivers, though it's not good to
>>> have to do this. Check them for correct behaviour.
>
>> Hm, so the only option is to create the simples possible 12MHz clk object?
>
> Well, that's the best option in general. You can get away with just
> making sure that -EPROBE_DEFER is handled and that IS_ERR() is used to
> check for an invalid clock but if you can define a clock that's even
> better (and should be pretty painless), we're going to want to do that
> transition at some point.
Do you mean I send my RFC patch as the formal patch, and let other
boards which use the wm8731 to add clk object, am I right?
Best Regards,
Bo Shen
WARNING: multiple messages have this Message-ID (diff)
From: Bo Shen <voice.shen@atmel.com>
To: Mark Brown <broonie@kernel.org>, Manuel Lauss <manuel.lauss@gmail.com>
Cc: Manuel Lauss <manuel.lauss@googlemail.com>,
Liam Girdwood <lrg@slimlogic.co.uk>,
Richard Purdie <richard@openedhand.com>,
<patches@opensource.wolfsonmicro.com>,
<linux-sound@vger.kernel.org>,
alsa-devel <alsa-devel@alsa-project.org>,
<linux-arm-kernel@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] ASoC: wm8731: let codec to manage clock by itself
Date: Wed, 4 Feb 2015 11:45:29 +0800 [thread overview]
Message-ID: <54D195D9.4090101@atmel.com> (raw)
In-Reply-To: <20150203162128.GP21293@sirena.org.uk>
Hi Mark,
On 02/04/2015 12:21 AM, Mark Brown wrote:
> On Tue, Feb 03, 2015 at 03:40:45PM +0100, Manuel Lauss wrote:
>> On Tue, Feb 3, 2015 at 1:44 PM, Mark Brown <broonie@kernel.org> wrote:
>
>>>> + wm8731->mclk = devm_clk_get(&spi->dev, "mclk");
>>>> + if (IS_ERR(wm8731->mclk)) {
>>>> + wm8731->mclk = NULL;
>>>> + dev_warn(&spi->dev, "assuming static MCLK\n");
>>>> + }
>
>>> This is broken for both deferred probe and in the case where the clock
>>> API genuinely returns a NULL clock. Other than that it's the kind of
>>> thing that we've done for some other drivers, though it's not good to
>>> have to do this. Check them for correct behaviour.
>
>> Hm, so the only option is to create the simples possible 12MHz clk object?
>
> Well, that's the best option in general. You can get away with just
> making sure that -EPROBE_DEFER is handled and that IS_ERR() is used to
> check for an invalid clock but if you can define a clock that's even
> better (and should be pretty painless), we're going to want to do that
> transition at some point.
Do you mean I send my RFC patch as the formal patch, and let other
boards which use the wm8731 to add clk object, am I right?
Best Regards,
Bo Shen
next prev parent reply other threads:[~2015-02-04 3:45 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-03 3:33 [RFC PATCH] ASoC: wm8731: let codec to manage clock by itself Bo Shen
2015-02-03 3:33 ` Bo Shen
2015-02-03 3:33 ` Bo Shen
2015-02-03 3:33 ` Bo Shen
2015-02-03 7:54 ` Manuel Lauss
2015-02-03 7:54 ` Manuel Lauss
2015-02-03 7:54 ` Manuel Lauss
2015-02-03 12:44 ` Mark Brown
2015-02-03 12:44 ` Mark Brown
2015-02-03 12:44 ` Mark Brown
2015-02-03 12:44 ` Mark Brown
2015-02-03 14:40 ` Manuel Lauss
2015-02-03 14:40 ` Manuel Lauss
2015-02-03 14:40 ` Manuel Lauss
2015-02-03 14:40 ` Manuel Lauss
2015-02-03 16:21 ` Mark Brown
2015-02-03 16:21 ` Mark Brown
2015-02-03 16:21 ` Mark Brown
2015-02-03 16:21 ` Mark Brown
2015-02-04 3:45 ` Bo Shen [this message]
2015-02-04 3:45 ` Bo Shen
2015-02-04 3:45 ` Bo Shen
2015-02-04 3:45 ` Bo Shen
2015-02-04 11:13 ` Mark Brown
2015-02-04 11:13 ` Mark Brown
2015-02-04 11:13 ` Mark Brown
2015-02-03 16:53 ` [alsa-devel] " Lars-Peter Clausen
2015-02-03 16:53 ` Lars-Peter Clausen
2015-02-03 16:53 ` Lars-Peter Clausen
2015-02-03 17:17 ` Russell King - ARM Linux
2015-02-03 17:17 ` Russell King - ARM Linux
2015-02-03 17:17 ` Russell King - ARM Linux
2015-02-03 17:26 ` Lars-Peter Clausen
2015-02-03 17:26 ` Lars-Peter Clausen
2015-02-03 17:26 ` Lars-Peter Clausen
2015-02-03 17:49 ` Lars-Peter Clausen
2015-02-03 17:49 ` Lars-Peter Clausen
2015-02-03 17:49 ` Lars-Peter Clausen
-- strict thread matches above, loose matches on Subject: below --
2015-03-12 2:17 Songjun Wu
2015-03-12 2:17 ` Songjun Wu
2015-03-16 14:53 ` Charles Keepax
2015-03-16 15:01 ` Mark Brown
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=54D195D9.4090101@atmel.com \
--to=voice.shen@atmel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=lrg@slimlogic.co.uk \
--cc=manuel.lauss@gmail.com \
--cc=manuel.lauss@googlemail.com \
--cc=patches@opensource.wolfsonmicro.com \
--cc=richard@openedhand.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.