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:
http://kernel.ubuntu.com/git?p=jk/dt/linux-2.6.git%3Ba=shortlog%3Bh=refs/hea... 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:
http://kernel.ubuntu.com/git?p=jk/dt/linux-2.6.git%3Ba=shortlog%3Bh=refs/hea... common-mx51
Cheers,
Jeremy