Add common interface for clock debug information

Yong Shen yong.shen at
Wed Nov 10 11:52:46 UTC 2010

Hi Jeremy,

It's nice to know that your clock update is coming soon. I would not waster
your time talking more in detail here now, since everything will be more
clear after your code comes out. Thanks again for sharing, and talk to you


On Wed, Nov 10, 2010 at 4:31 PM, Jeremy Kerr <jeremy.kerr at>wrote:

> Hi Yong,
> > This means that you have already forced each SOC to have a unified
> > 'struct clk', or at least force some fields inside the struct tp be
> unified,
> > right?
> > My understanding is that leaving 'struct clk' definition to SOC related
> > code is to give freedom for 'struct clk' definition to SOC vendors and
> > they can define their own 'struct clk' as they want. If 'struct clk' has
> > this much in common, why cannot we define it or define some common fields
> > in common code, say, <linux/clk.h> or <asm/clkdev.h>?
> This is what my 'common struct clk' changes do; the aim is to define struct
> clk only once, then allow platform-specific code to implement their own
> clocks
> by 'subclassing' this structure, as is done in many other places in the
> kernel.
> From the comments of the new struct clk (slightly reformatted):
> /**
>  * struct clk - hardware independent clock structure
>  * @clk_ops:            implementation-specific ops for this clock
>  * @enable_count:       count of clk_enable() calls active on this clock
>  * @mutex:              lock for enable/disable or other HW-specific ops
>  *
>  * The base clock object, used by drivers for hardware-independent
>  * manipulation of clock lines. This will be 'subclassed' by
> device-specific
>  * implementations, which add device-specific data to struct clk. For
> example:
>  *
>  *  struct clk_foo {
>  *      struct clk;
>  *      [device specific fields]
>  *  };
>  *
>  * The clock driver code will manage the device-specific data, and pass
>  * clk_foo.clk to the common clock code. The clock driver will be called
>  * through the @ops callbacks.
>  *
>  * The @enable_count and @mutex members are initialised when a clock is
>  * registered with the arch-specific clock management code; the clock
> driver
>  * code does not need to handle these.
>  */
> struct clk {
>        const struct clk_ops    *ops;
>        unsigned int                    enable_count;
>        struct mutex                    mutex;
> };
> So, the platform-specific code is free to define clocks as necessary, but
> we
> keep 'clk' as the structure that contains the platform-independent stuff.
> Patches at:
> common
> [I'm planning to update this tree soon, so it might be best to hold off for
> a
> couple of days if you're intending to work on this branch.]
> > tree-like clock information, which had been adopted by omap already. The
> > whole clock information is presented in a directory with many sub
> > directories and sub nodes and powerdebug will walk through the
> directories
> > to create tree-like output.
> Are you aiming to be file-level compatible with the omap debug information
> exported by the kernel?
> One flat file will give exactly the same functionality, but with less
> kernel
> code. The userspace utils can quite easily parse this file to reconstruct
> the
> full clock tree.
> > Can't wait to see that. Can I know a rough schedule of that? Since this
> is
> > a high priority task for me on the blueprints, I am keen to know more.
> > Maybe if you have draft code done, I can have test as soon as possible.
> I have some pending changes to do for the common clock code, I should have
> those done by tomorrow. After that, I'll work this example patch, so it
> should
> be done by early next week.
> However, this is only the clock infrastructure code, not the mx51-port of
> the
> common struct clk. The latter needs some updates for recent mx51 clock
> changes, and I don't have the capacity to do that at the moment. If you'd
> like
> to look at the original port, it's in my clk-common-mx51 branch:
> common-mx51
> Cheers,
> Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the linaro-dev mailing list