diff mbox

[1/2] clk: divider: Add CLK_DIVIDER_EVEN flag support

Message ID 1522906699-127765-1-git-send-email-shawn.lin@rock-chips.com (mailing list archive)
State Changes Requested, archived
Headers show

Commit Message

Shawn Lin April 5, 2018, 5:38 a.m. UTC
CLK_DIVIDER_EVEN is used for clock divders that should only
use even number in the div field.

Two clock divder should consider to use this flag
(1) The divder is physically only support even div number to
generate 50% duty cycle clock rate.
(2) The divder's clock consumer request it to use even div number
to generate the most closest requested rate for whatever reason.

In some platforms, for instance Rockchip, the eMMC/SDIO/SDMMC should
request divder to use even number when working at a high throughput
speed mode reliably. However, that wasn't guaranteed by clock framework.
So the previous tricky is to carefully assign magic clock rate to their
parents as well as consumer's clock rate when requesting. That works
bad in practice if folks change the parents clock rate or the clock
hierarchy randomly. That also work bad if the consumer's clock rate
came from the DT, which is changed so fraquent for different boards.

To make it's less prone to make mistake and to make it really respect
the fact that the divder should use even number to the div field, we
need the clock framework's help. Now we have CLK_DIVIDER_POWER_OF_TWO,
which could guarantee the div field is even number, however, obviously
it skips the even numbers which is the power of 2, but maybe which is
the best div to generate closest clock rate for consumer.

Look at the examples here when doing some random test on Rockchip's
platforms, by changing the requested clock rate from DT, namely
assigning different max-frquency for MMC node,

when the mmc host driver requests 80MHz with CLK_DIVIDER_POWER_OF_TWO
flag for the clock divder, it shows the final clock rate is 61.44Mhz

pll_vpll0		1		1 983039999     0   0
   vpll0		4		4 983039999     0   0
     clk_emmc_div       1		1 122880000     0   0
	clk_emmc	1		1 122880000     0   0
	  emmc_sample	0		0  61440000	0 155
	  emmc_drv	0		0  61440000	0 180

With this patch and add CLK_DIVIDER_EVEN flag for clk_emmc_div, we get
the final clock rate, 67.7376MHz.

pll_vpll1               1		1 812851199	0   0
   vpll1                2		2 812851199     0   0
     clk_emmc_div       1		1 135475200     0   0
	clk_emmc	1		1 135475200     0   0
	  emmc_sample   0		0  67737600     0 113
	  emmc_drv	0		0  67737600	0 180

Apprently 67737600 is better than 61440000 when requesting 80MHz.
Of course, we could have more case that worsen the gap between
the desired rate and the actual rate if using CLK_DIVIDER_POWER_OF_TWO.

So this introduces CLK_DIVIDER_EVEN flag for clock framework to make
the best in this process.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
---

 drivers/clk/clk-divider.c    | 9 +++++++++
 include/linux/clk-provider.h | 3 +++
 2 files changed, 12 insertions(+)

Comments

Heiko Stübner April 5, 2018, 1:30 p.m. UTC | #1
Hi Shawn,

Am Donnerstag, 5. April 2018, 07:38:18 CEST schrieb Shawn Lin:
> CLK_DIVIDER_EVEN is used for clock divders that should only
> use even number in the div field.
> 
> Two clock divder should consider to use this flag
> (1) The divder is physically only support even div number to
> generate 50% duty cycle clock rate.
> (2) The divder's clock consumer request it to use even div number
> to generate the most closest requested rate for whatever reason.
> 
> In some platforms, for instance Rockchip, the eMMC/SDIO/SDMMC should
> request divder to use even number when working at a high throughput
> speed mode reliably. However, that wasn't guaranteed by clock framework.
> So the previous tricky is to carefully assign magic clock rate to their
> parents as well as consumer's clock rate when requesting. That works
> bad in practice if folks change the parents clock rate or the clock
> hierarchy randomly. That also work bad if the consumer's clock rate
> came from the DT, which is changed so fraquent for different boards.
> 
> To make it's less prone to make mistake and to make it really respect
> the fact that the divder should use even number to the div field, we
> need the clock framework's help. Now we have CLK_DIVIDER_POWER_OF_TWO,
> which could guarantee the div field is even number, however, obviously
> it skips the even numbers which is the power of 2, but maybe which is
> the best div to generate closest clock rate for consumer.

I think there is a slight misunderstanding here, CLK_DIVIDER_POWER_OF_TWO
means "2 raised to the value read from the hardware register", so describes
a hardware property, while your CLK_DIVIDER_EVEN describes needed special
handling due to some hardware necessity.

That is not meant to nack your change, but just to point out that you can
also have CLK_DIVIDER_POWER_OF_TWO | CLK_DIVIDER_EVEN, which is
relevant for the uneven 2^0 = 1 case and should be taken in to account.


Heiko

--
To unsubscribe from this list: send the line "unsubscribe linux-clk" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Shawn Lin April 5, 2018, 2:47 p.m. UTC | #2
Hi Heiko,

On 2018/4/5 21:30, Heiko Stuebner wrote:
> Hi Shawn,
> 
> Am Donnerstag, 5. April 2018, 07:38:18 CEST schrieb Shawn Lin:
>> CLK_DIVIDER_EVEN is used for clock divders that should only
>> use even number in the div field.
>>
>> Two clock divder should consider to use this flag
>> (1) The divder is physically only support even div number to
>> generate 50% duty cycle clock rate.
>> (2) The divder's clock consumer request it to use even div number
>> to generate the most closest requested rate for whatever reason.
>>
>> In some platforms, for instance Rockchip, the eMMC/SDIO/SDMMC should
>> request divder to use even number when working at a high throughput
>> speed mode reliably. However, that wasn't guaranteed by clock framework.
>> So the previous tricky is to carefully assign magic clock rate to their
>> parents as well as consumer's clock rate when requesting. That works
>> bad in practice if folks change the parents clock rate or the clock
>> hierarchy randomly. That also work bad if the consumer's clock rate
>> came from the DT, which is changed so fraquent for different boards.
>>
>> To make it's less prone to make mistake and to make it really respect
>> the fact that the divder should use even number to the div field, we
>> need the clock framework's help. Now we have CLK_DIVIDER_POWER_OF_TWO,
>> which could guarantee the div field is even number, however, obviously
>> it skips the even numbers which is the power of 2, but maybe which is
>> the best div to generate closest clock rate for consumer.
> 
> I think there is a slight misunderstanding here, CLK_DIVIDER_POWER_OF_TWO
> means "2 raised to the value read from the hardware register", so describes
> a hardware property, while your CLK_DIVIDER_EVEN describes needed special
> handling due to some hardware necessity >
> That is not meant to nack your change, but just to point out that you can
> also have CLK_DIVIDER_POWER_OF_TWO | CLK_DIVIDER_EVEN, which is
> relevant for the uneven 2^0 = 1 case and should be taken in to account.

Ahh, really good catch, and I always forgot 1 is the power of 2.

More or less, it's a hardware property for Rockchip as these divders
only hardwired to specific controllers which always request even div
field, even if the div field could be odd number physcially. But yes,
the common case wouldn't be that, and another combination would be
CLK_DIVIDER_EVEN | CLK_DIVIDER_ONE_BASED?

> 
> 
> Heiko
> 
> 
> 
>
Stephen Boyd April 6, 2018, 9:13 p.m. UTC | #3
Quoting Shawn Lin (2018-04-05 07:47:41)
> Hi Heiko,
> 
> On 2018/4/5 21:30, Heiko Stuebner wrote:
> > Hi Shawn,
> > 
> > Am Donnerstag, 5. April 2018, 07:38:18 CEST schrieb Shawn Lin:
> >> CLK_DIVIDER_EVEN is used for clock divders that should only
> >> use even number in the div field.
> >>
> >> Two clock divder should consider to use this flag
> >> (1) The divder is physically only support even div number to
> >> generate 50% duty cycle clock rate.
> >> (2) The divder's clock consumer request it to use even div number
> >> to generate the most closest requested rate for whatever reason.
> >>
> >> In some platforms, for instance Rockchip, the eMMC/SDIO/SDMMC should
> >> request divder to use even number when working at a high throughput
> >> speed mode reliably. However, that wasn't guaranteed by clock framework.
> >> So the previous tricky is to carefully assign magic clock rate to their
> >> parents as well as consumer's clock rate when requesting. That works
> >> bad in practice if folks change the parents clock rate or the clock
> >> hierarchy randomly. That also work bad if the consumer's clock rate
> >> came from the DT, which is changed so fraquent for different boards.
> >>
> >> To make it's less prone to make mistake and to make it really respect
> >> the fact that the divder should use even number to the div field, we
> >> need the clock framework's help. Now we have CLK_DIVIDER_POWER_OF_TWO,
> >> which could guarantee the div field is even number, however, obviously
> >> it skips the even numbers which is the power of 2, but maybe which is
> >> the best div to generate closest clock rate for consumer.
> > 
> > I think there is a slight misunderstanding here, CLK_DIVIDER_POWER_OF_TWO
> > means "2 raised to the value read from the hardware register", so describes
> > a hardware property, while your CLK_DIVIDER_EVEN describes needed special
> > handling due to some hardware necessity >
> > That is not meant to nack your change, but just to point out that you can
> > also have CLK_DIVIDER_POWER_OF_TWO | CLK_DIVIDER_EVEN, which is
> > relevant for the uneven 2^0 = 1 case and should be taken in to account.
> 
> Ahh, really good catch, and I always forgot 1 is the power of 2.
> 
> More or less, it's a hardware property for Rockchip as these divders
> only hardwired to specific controllers which always request even div
> field, even if the div field could be odd number physcially. But yes,
> the common case wouldn't be that, and another combination would be
> CLK_DIVIDER_EVEN | CLK_DIVIDER_ONE_BASED?
> 

Maybe you can use a table of divider values? That is a simple escape
hatch for this sort of thing and doesn't require adding another flag to
the divider code to handle this.

Otherwise it would be good to handle these combinations of flags as
well. We're only up to 7 flags so it isn't too bad yet.
--
To unsubscribe from this list: send the line "unsubscribe linux-clk" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Shawn Lin April 8, 2018, 1:58 a.m. UTC | #4
Hi Stephen,

On 2018/4/7 5:13, Stephen Boyd wrote:
> Quoting Shawn Lin (2018-04-05 07:47:41)
>> Hi Heiko,
>>
>> On 2018/4/5 21:30, Heiko Stuebner wrote:
>>> Hi Shawn,
>>>
>>> Am Donnerstag, 5. April 2018, 07:38:18 CEST schrieb Shawn Lin:
>>>> CLK_DIVIDER_EVEN is used for clock divders that should only
>>>> use even number in the div field.
>>>>
>>>> Two clock divder should consider to use this flag
>>>> (1) The divder is physically only support even div number to
>>>> generate 50% duty cycle clock rate.
>>>> (2) The divder's clock consumer request it to use even div number
>>>> to generate the most closest requested rate for whatever reason.
>>>>
>>>> In some platforms, for instance Rockchip, the eMMC/SDIO/SDMMC should
>>>> request divder to use even number when working at a high throughput
>>>> speed mode reliably. However, that wasn't guaranteed by clock framework.
>>>> So the previous tricky is to carefully assign magic clock rate to their
>>>> parents as well as consumer's clock rate when requesting. That works
>>>> bad in practice if folks change the parents clock rate or the clock
>>>> hierarchy randomly. That also work bad if the consumer's clock rate
>>>> came from the DT, which is changed so fraquent for different boards.
>>>>
>>>> To make it's less prone to make mistake and to make it really respect
>>>> the fact that the divder should use even number to the div field, we
>>>> need the clock framework's help. Now we have CLK_DIVIDER_POWER_OF_TWO,
>>>> which could guarantee the div field is even number, however, obviously
>>>> it skips the even numbers which is the power of 2, but maybe which is
>>>> the best div to generate closest clock rate for consumer.
>>>
>>> I think there is a slight misunderstanding here, CLK_DIVIDER_POWER_OF_TWO
>>> means "2 raised to the value read from the hardware register", so describes
>>> a hardware property, while your CLK_DIVIDER_EVEN describes needed special
>>> handling due to some hardware necessity >
>>> That is not meant to nack your change, but just to point out that you can
>>> also have CLK_DIVIDER_POWER_OF_TWO | CLK_DIVIDER_EVEN, which is
>>> relevant for the uneven 2^0 = 1 case and should be taken in to account.
>>
>> Ahh, really good catch, and I always forgot 1 is the power of 2.
>>
>> More or less, it's a hardware property for Rockchip as these divders
>> only hardwired to specific controllers which always request even div
>> field, even if the div field could be odd number physcially. But yes,
>> the common case wouldn't be that, and another combination would be
>> CLK_DIVIDER_EVEN | CLK_DIVIDER_ONE_BASED?
>>
> 
> Maybe you can use a table of divider values? That is a simple escape
> hatch for this sort of thing and doesn't require adding another flag to
> the divider code to handle this.

The very first thought of adding clk_div_table is to support irregular
div calculation/limitation, but even number is rather common, regular
and symmetrical one. So I'm inclined to add it support.

> 
> Otherwise it would be good to handle these combinations of flags as
> well. We're only up to 7 flags so it isn't too bad yet.

Yep. After thinking more, I think we only need to handle div of 1
to avoid combination of CLK_DIVIDER_POWER_OF_TWO | CLK_DIVIDER_EVEN
suggested by Heiko. The others are just fine and not need to bother
with CLK_DIVIDER_EVEN, even with combination.

> 
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-clk" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index b6234a5..97f7b94 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -161,6 +161,8 @@  static bool _is_valid_div(const struct clk_div_table *table, unsigned int div,
 {
 	if (flags & CLK_DIVIDER_POWER_OF_TWO)
 		return is_power_of_2(div);
+	if (flags & CLK_DIVIDER_EVEN)
+		return !(div % 2);
 	if (table)
 		return _is_valid_table_div(table, div);
 	return true;
@@ -210,6 +212,8 @@  static int _div_round_up(const struct clk_div_table *table,
 
 	if (flags & CLK_DIVIDER_POWER_OF_TWO)
 		div = __roundup_pow_of_two(div);
+	if (flags & CLK_DIVIDER_EVEN)
+		div = !(div % 2) ? div : (div + 1);
 	if (table)
 		div = _round_up_table(table, div);
 
@@ -229,6 +233,9 @@  static int _div_round_closest(const struct clk_div_table *table,
 	if (flags & CLK_DIVIDER_POWER_OF_TWO) {
 		up = __roundup_pow_of_two(up);
 		down = __rounddown_pow_of_two(down);
+	} else if (flags & CLK_DIVIDER_EVEN) {
+		up = !(up % 2) ? up : (up + 1);
+		down = !(down % 2) ? down : (down - 1);
 	} else if (table) {
 		up = _round_up_table(table, up);
 		down = _round_down_table(table, down);
@@ -266,6 +273,8 @@  static int _next_div(const struct clk_div_table *table, int div,
 
 	if (flags & CLK_DIVIDER_POWER_OF_TWO)
 		return __roundup_pow_of_two(div);
+	if (flags & CLK_DIVIDER_EVEN)
+		return !(div % 2) ? div : (div + 1);
 	if (table)
 		return _round_up_table(table, div);
 
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 210a890..7c59611 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -388,6 +388,8 @@  struct clk_div_table {
  * CLK_DIVIDER_MAX_AT_ZERO - For dividers which are like CLK_DIVIDER_ONE_BASED
  *	except when the value read from the register is zero, the divisor is
  *	2^width of the field.
+ * CLK_DIVIDER_EVEN - For the dividers which could only use even number in the
+ *	div field.
  */
 struct clk_divider {
 	struct clk_hw	hw;
@@ -409,6 +411,7 @@  struct clk_divider {
 #define CLK_DIVIDER_ROUND_CLOSEST	BIT(4)
 #define CLK_DIVIDER_READ_ONLY		BIT(5)
 #define CLK_DIVIDER_MAX_AT_ZERO		BIT(6)
+#define CLK_DIVIDER_EVEN		BIT(7)
 
 extern const struct clk_ops clk_divider_ops;
 extern const struct clk_ops clk_divider_ro_ops;