Linux clock framework development
 help / color / mirror / Atom feed
From: Eric Anholt <eric@anholt.net>
To: Martin Sperl <kernel@martin.sperl.org>
Cc: Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@codeaurora.org>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Lee Jones <lee@kernel.org>,
	linux-clk@vger.kernel.org, linux-rpi-kernel@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 5/6] clk: bcm2835: correctly enable fractional clock support
Date: Mon, 29 Feb 2016 15:44:16 -0800	[thread overview]
Message-ID: <87lh63jd4f.fsf@eliezer.anholt.net> (raw)
In-Reply-To: <0ED2FB7F-B112-487B-B222-08E5FAEE27F9@martin.sperl.org>

[-- Attachment #1: Type: text/plain, Size: 2140 bytes --]

Martin Sperl <kernel@martin.sperl.org> writes:

>> On 29.02.2016, at 21:33, Eric Anholt <eric@anholt.net> wrote:
>> 
>> kernel@martin.sperl.org writes:
>> 
>>> From: Martin Sperl <kernel@martin.sperl.org>
>>> 
>>> The current driver calculates the clock divider with
>>> fractional support enabled.
>>> 
>>> But it does not enable fractional support in the
>>> control register itself resulting in an integer only divider,
>>> but in clk_set_rate responds back the fractionally divided
>>> clock frequency.
>>> 
>>> This patch enables fractional support in the control register
>>> whenever there is a fractional bit set in the requested clock divider.
>>> 
>>> Mash clock limits are are also handled for the PWM clock
>>> applying the correct divider limits (2 and max_int) applicable to
>>> basic fractional divider support (mash order of 1).
>>> 
>>> It also adds locking to protect the read/modify/write cycle of
>>> the register modification.
>>> 
>>> Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the
>>> audio domain clocks")
>>> 
>>> Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
>> 
>> Rewrite of the commit message:
>> 
>> The driver has been using fractional dividers for all clocks with
>> fractional bits.  However, MASH clocks (those used to drive audio) only
>> do fractional division when in MASH mode, which is used to push clock
>> jitter out of the audio band.  The PWM clock (used to drive i2s audio)
>> is the only MASH clock currently enabled in the driver.
>> 
>> Additional MASH modes are available that widen the frequency range, but
>> only 1-level MASH is used for now, until we characterize some better
>> policy.
>> 
>> Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the
>> audio domain clocks”)
>
> That is not 100% true - non mash modes have CM_FRAC and CM_FRAC = CM_MASH0
> so these map each other

Once again, trusting the docs turns out to be a bad idea.  You're right,
the non-MASH clocks *do* have a bit 9 to enable fractional mode.  Sigh.

So, this patch is:

Reviewed-by: Eric Anholt <eric@anholt.net>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

  reply	other threads:[~2016-02-29 23:44 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-29 11:39 [PATCH 0/6] clk: bcm2835: fixes clk-bcm2835 driver issues kernel
2016-02-29 11:39 ` [PATCH 1/6] clk: bcm2835: pll_off should only set CM_PLL_ANARST kernel
2016-02-29 20:03   ` Eric Anholt
2016-02-29 11:39 ` [PATCH 2/6] clk: bcm2835: add locking to pll*_on/off methods kernel
2016-02-29 20:06   ` Eric Anholt
2016-02-29 11:39 ` [PATCH 3/6] clk: bcm2835: enable clocks that have been enabled by firmware kernel
2016-02-29 20:09   ` Eric Anholt
2016-03-17 17:39     ` Eric Anholt
2016-03-17 18:13       ` Martin Sperl
2016-03-17 18:23         ` Eric Anholt
2016-04-26  7:48           ` Martin Sperl
2016-02-29 11:39 ` [PATCH 4/6] clk: bcm2835: divider value has to be 1 or more kernel
2016-02-29 20:11   ` Eric Anholt
2016-02-29 11:39 ` [PATCH 5/6] clk: bcm2835: correctly enable fractional clock support kernel
2016-02-29 20:33   ` Eric Anholt
2016-02-29 21:59     ` Martin Sperl
2016-02-29 23:44       ` Eric Anholt [this message]
2016-03-01  5:52         ` Martin Sperl
2016-02-29 11:39 ` [PATCH 6/6] clk: bcm2835: clean up coding style issues kernel
2016-02-29 20:20   ` Eric Anholt

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=87lh63jd4f.fsf@eliezer.anholt.net \
    --to=eric@anholt.net \
    --cc=kernel@martin.sperl.org \
    --cc=lee@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=mturquette@baylibre.com \
    --cc=sboyd@codeaurora.org \
    --cc=swarren@wwwdotorg.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