On Thu, 8 Jun 2017 10:40:26 +0200 Daniel Lezcano <daniel.lezcano@xxxxxxxxxx> wrote: > > > > > > 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 ;-)). -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
