On Thu, 8 Jun 2017 10:40:26 +0200
Daniel Lezcano [off-list ref] wrote:

quoted

quoted

Alexandre, Boris, have a look at https://www.spinics.net/lists/arm-kernel/msg572652.html

That will tell you the story.  

Then we're in a deadlock situation here. I'm tired of hearing this kind
of argument "DT is only supposed to describe HW, not configuration, bla
bla". The truth is, we already have plenty of bindings that do not
strictly describe HW.

A simple example: ECC configuration on NAND devices. This is clearly a
configuration thing, the NAND controller is usually able to support
several kind of strength+ECC-block-size config, but we are able to
overload this with the nand-ecc-xxx properties. Another example, still
MTD related: MTD partitions, this is purely a software configuration,
still we allow users to pass this information in the DT. You want
another one? What about the linux,code and linux,input-type properties
described here [1]?

So please, let's not use these "this is not decribing HW" or "this is
linux specific" arguments every time someone tries to encode something
that can be considered a configuration detail.

Let's be pragmatic. How you want to use your timer counter blocks (I'm
talking about atmel TCBs) is clearly board specific. Whether you want
to use the PIT for your clocksource or use one or 2 channels of a TCB
at a specific resolution is again board specific. We need a solution to
assign timer channels to a linux function, and I'm not convinced
passing this information through the command line makes much more sense
than specifying it in the DT (and it's definitely less intuitive, since
you have to reference something defined in the DT from the cmdline).

Now, in his review, Mark says:

"
To me it sounds like what we need is Linux infrastructure that allows
one to register a device as having both clockevent/clocksource
functionality.

That way, we can choose to do something sane at boot time, and if the
user really wants specific devices used in specific ways, they can
request that.
"

Does that mean that, after adding this "HW timer" infrastructure, we
would have a standard way to assign a function to a specific timer
block from the DT? How is this different from what I suggest below
(note the linux, prefix on my linux,timer-function property, which
clearly shows that this is Linux specific)?  

I like the 'chosen' approach with the nodes you are proposing below. Thanks for
the constructive suggestion. The binding description matches perfectly what we
are trying to achieve.

Actually, this is Alexandre who initially suggested the chosen
approach (I thought it was important to mention that ;-)).