On Wed, Jan 28, 2009 at 12:27:59PM -0700, Paul Walmsley wrote:
> The price paid is additional runtime memory consumption - 8 bytes per
> clock and 16 bytes per child clock - roughly 4.5KiB on OMAP3.
For OMAP3, that's 222 struct clks of which 182 are children, and indeed
222 * 8 + 182 * 16 gives about 4.5K. On OMAP2, it's 140 and 136,
giving 140 * 8 + 136 * 16 = 3.3K.
Moving struct clk_child into struct clk means that its clk and flags
members can be deleted, making it 8 bytes in size - effectively just
the list_head. We need a list_head for the 'children' as you have it.
So, that works out as 16 bytes per clock. That gives 3.5K on OMAP3
and 2.2K on OMAP2.
So, by taking that alternative approach, not only do you end up using
less memory, but you also don't have to have the overhead of your
custom memory bookkeeping.
The other change I'd suggest is that you have one function which deals
with setting the parent of a clock:
void clk_reparent(struct clk *child, struct clk *parent)
{
list_del_init(&child->sibling);
if (parent)
list_add(&child->sibling, &parent->children);
child->parent = parent;
/* now do the debugfs renaming to reattach the child
to the proper parent */
}
which is a lot simpler than your omap_clk_add_child() and omap_clk_del_child().
These should be in the _core_ OMAP clock code, not just in the OMAP2
clock code. OMAP1 has child clocks as well as OMAP2.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
