From: Martin Fuzzey <mfuzzey@parkeon.com>
To: Timur Tabi <timur@tabi.org>
Cc: alsa-devel@alsa-project.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] Sound: sgtl5000 Allow codec clock frequency to be set.
Date: Thu, 21 Mar 2013 18:46:17 +0100 [thread overview]
Message-ID: <514B4769.30109@parkeon.com> (raw)
In-Reply-To: <CAOZdJXXv=O3vmSCJ1ojhis+Fn7FJ7yhd2wVt10m77Cixbew2BA@mail.gmail.com>
On 21/03/13 17:11, Timur Tabi wrote:
> On Thu, Mar 21, 2013 at 3:39 AM, Martin Fuzzey <mfuzzey@parkeon.com> wrote:
>
>> With this patch and that DT example the frequency of clock 162 will be _set_
>> to 20MHz
> Does that mean that it ignores the ' clocks' parameter?
No, in this case the clocks parameter must contain the phandle of a clock
whose rate is configurable.
> If clock-frequency is omitted the binding is still correct (hence the
> optional) but the frequency of clock 162 would not be modified.
>
> In the documentation I wrote "If both a clock and clock-frequency are
> provided the clock's rate will be set. " maybe this is not clear enough?
> It's not clear what it will be set *to*.
It will be set to the frequency specified by the clock-frquency attribute.
Would
"If both a clock and clock-frequency are provided clock must support
the set_rate operation and its frequency will be set to the value specified
by clock-frequency" be better?
The possible configurations and their use cases are:
1) only 'clocks' specified
clock points to a clock specified in the DT which already has an
appropriate frequency and is
configured by some other means external to the sgtl5000 driver
(bootloader, board setup code, or just a fixed rate clock)
2) only 'clock-frequency' specified
The chip is assumed to be clocked by a signal having the given
frequency, which may even be generated by a clock unknown to linux.
This could actually be represented as a special case of 1) by defining a
fixed-rate clock in the DT.
3) Both 'clocks' and 'clock-frequency' specified
The chip is assumed to be clocked by a rate programmable clock defined
in the clock tree.
clk_set_rate() will be called for this clock to set its rate to that
specified by clock-frequency
Cases 1 and 2 exist in the current code, this patch adds support for case 3.
Prior to commit 81e8e4926167ab32593bbb915b45a42024ca1020 "ASoC: fsl: add
sgtl5000 clock support for imx-sgtl5000"
only case 2 was supported
This explains why 2 is not implemented as a special case of 1)
plain 'clock-frequency' was supported before the driver learnt how to
get a clock from the DT
Regards,
Martin
WARNING: multiple messages have this Message-ID (diff)
From: mfuzzey@parkeon.com (Martin Fuzzey)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] Sound: sgtl5000 Allow codec clock frequency to be set.
Date: Thu, 21 Mar 2013 18:46:17 +0100 [thread overview]
Message-ID: <514B4769.30109@parkeon.com> (raw)
In-Reply-To: <CAOZdJXXv=O3vmSCJ1ojhis+Fn7FJ7yhd2wVt10m77Cixbew2BA@mail.gmail.com>
On 21/03/13 17:11, Timur Tabi wrote:
> On Thu, Mar 21, 2013 at 3:39 AM, Martin Fuzzey <mfuzzey@parkeon.com> wrote:
>
>> With this patch and that DT example the frequency of clock 162 will be _set_
>> to 20MHz
> Does that mean that it ignores the ' clocks' parameter?
No, in this case the clocks parameter must contain the phandle of a clock
whose rate is configurable.
> If clock-frequency is omitted the binding is still correct (hence the
> optional) but the frequency of clock 162 would not be modified.
>
> In the documentation I wrote "If both a clock and clock-frequency are
> provided the clock's rate will be set. " maybe this is not clear enough?
> It's not clear what it will be set *to*.
It will be set to the frequency specified by the clock-frquency attribute.
Would
"If both a clock and clock-frequency are provided clock must support
the set_rate operation and its frequency will be set to the value specified
by clock-frequency" be better?
The possible configurations and their use cases are:
1) only 'clocks' specified
clock points to a clock specified in the DT which already has an
appropriate frequency and is
configured by some other means external to the sgtl5000 driver
(bootloader, board setup code, or just a fixed rate clock)
2) only 'clock-frequency' specified
The chip is assumed to be clocked by a signal having the given
frequency, which may even be generated by a clock unknown to linux.
This could actually be represented as a special case of 1) by defining a
fixed-rate clock in the DT.
3) Both 'clocks' and 'clock-frequency' specified
The chip is assumed to be clocked by a rate programmable clock defined
in the clock tree.
clk_set_rate() will be called for this clock to set its rate to that
specified by clock-frequency
Cases 1 and 2 exist in the current code, this patch adds support for case 3.
Prior to commit 81e8e4926167ab32593bbb915b45a42024ca1020 "ASoC: fsl: add
sgtl5000 clock support for imx-sgtl5000"
only case 2 was supported
This explains why 2 is not implemented as a special case of 1)
plain 'clock-frequency' was supported before the driver learnt how to
get a clock from the DT
Regards,
Martin
next prev parent reply other threads:[~2013-03-21 17:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-19 17:03 [PATCH] Sound: sgtl5000 Allow codec clock frequency to be set Martin Fuzzey
2013-03-19 17:03 ` Martin Fuzzey
2013-03-21 1:35 ` Timur Tabi
2013-03-21 1:35 ` Timur Tabi
2013-03-21 8:39 ` Martin Fuzzey
2013-03-21 8:39 ` Martin Fuzzey
2013-03-21 16:11 ` Timur Tabi
2013-03-21 16:11 ` Timur Tabi
2013-03-21 17:46 ` Martin Fuzzey [this message]
2013-03-21 17:46 ` Martin Fuzzey
2013-03-21 17:52 ` Timur Tabi
2013-03-21 17:52 ` Timur Tabi
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=514B4769.30109@parkeon.com \
--to=mfuzzey@parkeon.com \
--cc=alsa-devel@alsa-project.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=timur@tabi.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 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.