[PATCH 1/4] clocksource: pass DT node pointer to init functions

On 02/13/2013 11:33 AM, Michal Simek wrote:

2013/2/13 Rob Herring [off-list ref]:

quoted

On 02/13/2013 10:21 AM, Michal Simek wrote:

quoted

2013/2/7 Rob Herring [off-list ref]:

quoted

From: Rob Herring <redacted>

In cases where we have multiple nodes of the same type, we may need the
node pointer to know which node was matched. Passing the node pointer
also keeps the init function from having to match the node a 2nd time.

Signed-off-by: Rob Herring <redacted>
Cc: John Stultz <redacted>
Cc: Thomas Gleixner <redacted>
---
 drivers/clocksource/clksrc-of.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Tested-by: Michal Simek <redacted>

The rest is just the same as I have done. Any option to add these
patches to v3.9?

I would like to before we have more users to fix, but it will have to be
post rc1. If not, Arnd/Olof should be be able to provide a stable branch
for 3.10.

ok

I now see you were trying to get zynq changes in for 3.9. You could add
this patch to your pull request. As is, it is not dependent on some DT
code changes, but the subsequent patches are. I can send the rest after
rc1. It's a bit of a hack with the function call prototype, but nothing
actually breaks. I was going to combine as Arnd suggested, but either
way is probably fine.

quoted

quoted

Because I need these patches for zynq timer because we have two in the soc.
Is it OK to register several clock source and clockevent devices?

If it is 1 DT node, then that should be fine.

zynq is using two triple timer counter IP . There are also described by two
different DT nodes because there are separated and uses different baseaddresses.

Does it mean that if there are 2 DT nodes that it won't work?


One more thing. Is there any rule which should describe which timer should be
used for clockevent and for clocksource?

No. This is a common problem. A simple solution is a "linux,clockevent"
property, but I want to avoid that. Ultimately it is some feature of the
h/w that makes you choose. This could be it has an interrupt or not,
higher frequency, has timer compare pins, gets power gated, etc. So you
should describe enough of the h/w properties to make this decision. OMAP
is an example doing this with lots of timers with varying integration
level differences.

Rob

quoted

quoted

btw: there is still one issue because you can just setup only one
compatibility string.

You can have multiple CLOCKSOURCE_OF_DECLARE statements. The gic code
does this for irqchips.

Ok. Will look at it.

Thanks,
Michal