Re: [RFC PATCH 2/3] clk: stm32: Add clock driver for STM32F4[23]xxx devices

From: Daniel Thompson
Date: Fri Jun 05 2015 - 05:36:37 EST


On 04/06/15 23:07, Stephen Boyd wrote:
On 05/22, Daniel Thompson wrote:
+
+#include <linux/clk.h>

Are you using this include?

+#include <linux/clkdev.h>

Are you using this include?

Not very much?

Turns out I was relying on these to get kzalloc() defined but there are better headers for me to use for that!


+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/clk-provider.h>
+#include <linux/spinlock.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+
+#include <linux/debugfs.h>

Are you using this include?

No (this is already gone in v2).


+static long clk_apb_mul_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *prate)
+{
+ struct clk_apb_mul *am = to_clk_apb_mul(hw);
+ unsigned long mult = 1;
+
+ if (readl(base + STM32F4_RCC_CFGR) & BIT(am->bit_idx))
+ mult *= 2;

Isn't this the same as mult = 2? I guess we could rely on the
compiler to figure out this one.

I'll fix this.


+
+ if (__clk_get_flags(hw->clk) & CLK_SET_RATE_PARENT) {
+ unsigned long best_parent = rate / mult;
+
+ *prate =
+ __clk_round_rate(__clk_get_parent(hw->clk), best_parent);
+ }
+
+ return *prate * mult;
+}
+
+static int clk_apb_mul_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{

Why don't we need to do anything here?

This clock cannot change its own rate. It is very nearly a fixed factor clock but with the additional quirk that the "fixed" factor changes depending upon the rate of the parent clock.

This is the same implementation as clk-fixed-factor. I concluded that it returns success because round rate should always result in the set rate for this clock being a nop.


+ return 0;
+}
+
+static struct clk_ops clk_apb_mul_factor_ops = {

const?

Makes sense...

You want a patch for clk-fixed-factor too?


+struct clk *clk_register_apb_mul(struct device *dev, const char *name,
+ const char *parent_name, unsigned long flags,
+ u8 bit_idx)
+{
+ struct clk_apb_mul *am;
+ struct clk_init_data init;
+ struct clk *clk;
+
+ am = kzalloc(sizeof(*am), GFP_KERNEL);
+ if (!am)
+ return ERR_PTR(-ENOMEM);
+
+ am->bit_idx = bit_idx;
+ am->hw.init = &init;
+
+ init.name = name;
+ init.ops = &clk_apb_mul_factor_ops;
+ init.flags = flags | CLK_IS_BASIC;

Is it basic?

Tough question.

The absence of this flag appears grants arch code permission to use secret backdoors to do "weird stuff" but making special assumptions about the type of the clock. This clock keeps its implementation private so noone outside the compilation unit can usefully cast it.

However, it also looks like only omap2 is the only platform that makes these special assumptions so when this code is run on STM32 there is nothing to actually consume the CLK_IS_BASIC flag at runtime.

In other words the flag is useless but, I think, also correctly applied.

I'd be happy to remove it if anyone disagrees with the guesswork above.

Alternatively, I could write a patch to *invert* CLK_IS_BASIC and rename it CLK_CASTABLE on the grounds that only the people doing "weird stuff" should have to care about this flag at all. Any interest in that?


+ init.parent_names = &parent_name;
+ init.num_parents = 1;
+
+ clk = clk_register(dev, &am->hw);
+
+ if (IS_ERR(clk))
+ kfree(am);
+
+ return clk;
+}
+
+static const char __initdata *sys_parents[] = { "hsi", NULL, "pll" };

__initdata goes after the []

Thanks. I'll fix this.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/