On 11/09/2016 09:10 AM, Radosław Pietrzyk wrote:
I would expect that VCO clock will force recalculation for all its
children if I am not mistaken.
Sure
BR
Gabriel.
2016-11-08 17:19 GMT+01:00 Gabriel Fernandez <gabriel.fernandez@xxxxxx>:
On 11/08/2016 09:52 AM, Radosław Pietrzyk wrote:
2016-11-08 9:35 GMT+01:00 Gabriel Fernandez <gabriel.fernandez@xxxxxx>:
Hi Radosław
Many thanks for reviewing.
On 11/07/2016 03:57 PM, Radosław Pietrzyk wrote:
+static struct clk_hw *clk_register_pll_div(const char *name,
+ const char *parent_name, unsigned long flags,
+ void __iomem *reg, u8 shift, u8 width,
+ u8 clk_divider_flags, const struct clk_div_table
*table,
+ struct clk_hw *pll_hw, spinlock_t *lock)
+{
+ struct stm32f4_pll_div *pll_div;
+ struct clk_hw *hw;
+ struct clk_init_data init;
+ int ret;
+
+ /* allocate the divider */
+ pll_div = kzalloc(sizeof(*pll_div), GFP_KERNEL);
+ if (!pll_div)
+ return ERR_PTR(-ENOMEM);
+
+ init.name = name;
+ init.ops = &stm32f4_pll_div_ops;
+ init.flags = flags;
Maybe it's worth to have CLK_SET_RATE_PARENT here and the VCO clock
should have CLK_SET_RATE_GATE flag and we can get rid of custom
divider ops.
I don't want to offer the possibility to change the vco clock through the
divisor of the pll (only by a boot-loader or by DT).
e.g. if i make a set rate on lcd-tft clock, i don't want to change the
SAI
frequencies.
I used same structure for internal divisors of the pll (p, q, r) and for
post divisors (plli2s-q-div, pllsai-q-div & pllsai-r-div).
That why the CLK_SET_RATE_PARENT flag is transmit by parameter.
These divisors are similar because we have to switch off the pll before
changing the rate.
But changing pll and lcd dividers only may not be enough for getting
very specific pixelclocks and that might require changing the VCO
frequency itself. The rest of the SAI tree should be recalculated
then.
I agree but it seems to be too much complicated to recalculate all PLL
divisors if we change the vco clock.
You mean to use Clock notifier callback ?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
