[V4,2/7] clk: bcm2835: clamp clock divider to highest integer only

Commit Message

Martin Sperl Jan. 15, 2016, 2:21 p.m. UTC

From: Martin Sperl <[e-mail]>

The clock divider calculation right now clamps the
divider to the highest possible fractional divider.
So typically (BIT(div_int_bits) - 1) + 4095 / 4096.

As the fractional clock divider is alterating between
(Fosc / div_int) and (Fosc / (div_int + 1))
the divider will overflow for the (div_int + 1) case.
As with the "underflow" case we have seen for (div < 2),
we can assume that the same applies on the upper limit
as well.

So this patch will instead clamp to the divider to the
max of (BIT(div_int_bits) - 1)

Signed-off-by: Martin Sperl <[e-mail]>
---
 drivers/clk/bcm/clk-bcm2835.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Eric Anholt Feb. 1, 2016, 11:19 p.m. UTC | #1

[e-mail] writes:

> From: Martin Sperl <[e-mail]>
>
> The clock divider calculation right now clamps the
> divider to the highest possible fractional divider.
> So typically (BIT(div_int_bits) - 1) + 4095 / 4096.
>
> As the fractional clock divider is alterating between
> (Fosc / div_int) and (Fosc / (div_int + 1))
> the divider will overflow for the (div_int + 1) case.
> As with the "underflow" case we have seen for (div < 2),
> we can assume that the same applies on the upper limit
> as well.
>
> So this patch will instead clamp to the divider to the
> max of (BIT(div_int_bits) - 1)

Looks like this restriction might be necessary, though it's not quite
spelled out in the docs.

This also needs to be conditional on it being a MASH clock, and the
limit on the divider changes in the same way based on the mash number as
for the minimum.

Martin Sperl Feb. 8, 2016, 12:20 p.m. UTC | #2

On 02.02.2016 00:19, Eric Anholt wrote:
> [e-mail] writes:
>
>> From: Martin Sperl <[e-mail]>
>>
>> The clock divider calculation right now clamps the
>> divider to the highest possible fractional divider.
>> So typically (BIT(div_int_bits) - 1) + 4095 / 4096.
>>
>> As the fractional clock divider is alterating between
>> (Fosc / div_int) and (Fosc / (div_int + 1))
>> the divider will overflow for the (div_int + 1) case.
>> As with the "underflow" case we have seen for (div < 2),
>> we can assume that the same applies on the upper limit
>> as well.
>>
>> So this patch will instead clamp to the divider to the
>> max of (BIT(div_int_bits) - 1)
>
> Looks like this restriction might be necessary, though it's not quite
> spelled out in the docs.
>
> This also needs to be conditional on it being a MASH clock, and the
> limit on the divider changes in the same way based on the mash number as
> for the minimum.
>
See:
[PATCH V4 7/7] clk: bcm2835: apply limits on dividers to MASH mode.
That "downgrades" to lower mash values in case we are out of range.
Also note that it applies to MASH=1 as well.

If the other (non mash-supported) clocks support this "better" (if it 
works), then we can make that change only apply to mash enabled clocks.
But so far I doubt it works correctly so I have applied those limits to
all clocks.

Patch

diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index 10e97b7..3d6490f 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -1182,9 +1182,9 @@  static u32 bcm2835_clock_choose_div(struct clk_hw *hw,
 	/* divider must be >= 2 */
 	div = max_t(u32, div, (2 << CM_DIV_FRAC_BITS));
 
-	/* clamp to max divider allowed */
+	/* clamp to max divider allowed - max is integer divider */
 	div = min_t(u32, div, GENMASK(data->int_bits + CM_DIV_FRAC_BITS - 1,
-				      CM_DIV_FRAC_BITS - data->frac_bits));
+				      CM_DIV_FRAC_BITS));
 
 	return div;
 }