[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <74d0deb30803270229h1244c5bfr5ca521dbb87b0583@mail.gmail.com>
Date: Thu, 27 Mar 2008 10:29:27 +0100
From: "pHilipp Zabel" <philipp.zabel@...il.com>
To: "Russell King" <rmk+lkml@....linux.org.uk>
Cc: "Haavard Skinnemoen" <haavard.skinnemoen@...el.com>,
Dmitry <dbaryshkov@...il.com>, linux-kernel@...r.kernel.org,
akpm@...ux-foundation.org, hskinnemoen@...el.com,
domen.puncer@...argo.com, lethal@...ux-sh.org, tony@...mide.com,
paul@...an.com
Subject: Re: [PATCH 1/3] Clocklib: add generic framework for managing clocks.
On Thu, Mar 27, 2008 at 10:18 AM, Russell King
<rmk+lkml@....linux.org.uk> wrote:
> On Thu, Mar 27, 2008 at 10:06:23AM +0100, Haavard Skinnemoen wrote:
> > > + int users;
> >
> > Reference counting, probably need that too.
> >
> > > + unsigned long rate;
> >
> > This one is redundant. Use getrate() instead.
>
> ... which means a separate getrate() functions for every clock. Not really
> practical for PXA.
struct pxa_clk {
struct clk generic_clk;
int rate;
int delay;
}
unsigned long pxa_clk_getrate (struct clk *clk)
{
return container_of(clk, struct pxa_clk, generic_clk)->rate;
}
> > > + int delay;
> >
> > Huh? A delay after enabling the clock? Why can't the enable() hook do
> > that if it's really necessary?
>
> ... which means a separate enable() function for each clock. The delay
> there has not a lot to do with the actual register you're frobbing, but
> the resy of the SoC. So, again, not really practical for PXA.
int pxa_clk_mode(struct clk *clk, bool enabled)
{
if (enabled)
udelay(container_of(clk, struct pxa_clk, generic_clk)->delay);
generic_clk_mode(clk, enabled);
}
> The result for PXA is a tradeoff between reducing the data size and
> increasing the text size, or increasing the data size and keeping
> the existing data size.
Wouldn't something like the above work without increasing text size too much?
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists