Re: [PATCH 05/11] ST SPEAr: Added clock framework for SPEAr platform and machines

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Linus Walleij
Date: Thursday, March 11, 2010 - 12:00 am

2010/3/3 Viresh KUMAR <viresh.kumar@st.com>:



I don't understand one bit of this. What happens if the RESET_TO_ENABLE
flag is set for the clock? The exact same bit is &-masked and then
immediately |:ed to 1 again. Then it is written to the register. Practical
effect: absolutely none.

Is there a writel(val, clk->en_reg); missing from the unlikely() execution
path?


Same issue here...


Isnt if (++clk.>usage_count == 1) easier to understand, or is it just me?
BTW doing this:
clk->usage_count++;
if (clk->usage_count == 1)
will not use more memory, the compiler optimize this, so choose the
version you think is most readable. If you think this is very readable, by
all means keep it.


Same readability issue here.


Why will the clk_set_parent() call fail if there are *no* users of the clock?
Should it not be the other way around? Or what am I misunderstanding here?


What about -ENODEV or so? (I don't know what people typically
use for clocks that don't exist.)


I understand (I think) how speed change can propagate through the clocks.
However I think it will be hard to notify users that the clock rate has changed,
because there is nothing in the clk framework that supports that. If you have
drivers with dynamic clocks, do you have any plans on how you will
notify drivers?

OMAP uses CPUfreq but that is really about the CPU. As it happens, all
their clk:s always change frequency at the same operating points as the
CPU. So they can have pre/post calls from CPUfreq in their code, but
this will not work with things like PrimeCells where other users of the cell
may not have operating points correlated with CPU operating points.

(I'm not requesting you to solve this problem, more to be aware of it.)


This looks far to generic to be hidden in some weird special architecture.
And I *think* the preferred way to encode frequencies in the kernel is raw
Hertz measure with all the extra zeroes.

Doing
.foo = MHZ *48;

Is a bit awkward, don't you think it's better to do:
#define MHZ(f)  f * 1000000
.foo = MHZ(48);

If you absolutely want to do this, I would suggest to add the KHZ and MHZ
macros to some global kernel file but I honestly cannot say which one.
Perhaps inlcude/linux/clk.h?


Yours,
Linus Walleij
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [PATCH 05/11] ST SPEAr: Added clock framework for SPEA ..., Linus Walleij, (Thu Mar 11, 12:00 am)
Re: [PATCH 05/11] ST SPEAr: Added clock framework for SPEA ..., Russell King - ARM Linux, (Thu Mar 11, 3:28 am)