All of lore.kernel.org
 help / color / mirror / Atom feed
From: Timur Tabi <timur@tabi.org>
To: mfuzzey@parkeon.com
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 12:52:19 -0500	[thread overview]
Message-ID: <514B48D3.2010303@tabi.org> (raw)
In-Reply-To: <514B4769.30109@parkeon.com>

On 03/21/2013 12:46 PM, Martin Fuzzey wrote:
> 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?

Yes, that's much 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

This should all be in the binding document.

> 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

And this should be in the patch description.

-- 
Timur Tabi

WARNING: multiple messages have this Message-ID (diff)
From: timur@tabi.org (Timur Tabi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] Sound: sgtl5000 Allow codec clock frequency to be set.
Date: Thu, 21 Mar 2013 12:52:19 -0500	[thread overview]
Message-ID: <514B48D3.2010303@tabi.org> (raw)
In-Reply-To: <514B4769.30109@parkeon.com>

On 03/21/2013 12:46 PM, Martin Fuzzey wrote:
> 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?

Yes, that's much 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

This should all be in the binding document.

> 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

And this should be in the patch description.

-- 
Timur Tabi

  reply	other threads:[~2013-03-21 17:52 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
2013-03-21 17:46         ` Martin Fuzzey
2013-03-21 17:52         ` Timur Tabi [this message]
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=514B48D3.2010303@tabi.org \
    --to=timur@tabi.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mfuzzey@parkeon.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.