lkml.org 
[lkml]   [2017]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 46/58] clocksource/drivers: Add a new driver for the Atmel ARM TC blocks
    On Thu, 8 Jun 2017 10:40:26 +0200
    Daniel Lezcano <daniel.lezcano@linaro.org> 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 ;-)).

    \
     
     \ /
      Last update: 2017-06-12 01:24    [W:4.869 / U:0.304 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site