lkml.org 
[lkml]   [2013]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH v2 0/3] clk: implement remuxing during set_rate
    Date
    Quoting James Hogan (2013-04-19 09:28:21)
    > This patchset adds support for automatic selection of the best parent
    > for a clock mux, i.e. the one which can provide the closest clock rate
    > to that requested. It can be controlled by a new CLK_SET_RATE_REMUX flag
    > so that it doesn't happen unless explicitly allowed.
    >

    I'm not sure about the new flag. One of my regrets during the early
    development of the common struct clk is the CLK_SET_RATE_PARENT flag.
    In hindsight I would have preferred to make parent-propagation of rate
    changes the default behavior, and instead provide a flag to prevent that
    behavior, such as CLK_SET_RATE_NO_PROPAGATE.

    One reason for this is the difficulty some have had with setting flags
    from DT bindings. Another reason is that a core goal of the framework
    is to remove topology info from drivers; having to set a flag explicitly
    on each clock to propagate rate changes is an impediment to that goal.

    So perhaps CLK_SET_RATE_REMUX is a similar situation. What do you think
    about making remuxing the default and providing a flag to prevent it?
    And also we can assume for the immediate future that users of
    .determine_rate WANT to remux, since .round_rate won't do it. Though
    eventually it might be wise to convert all users of .round_rate over to
    .determine_rate and deprecate .round_rate entirely.

    Regards,
    Mike

    > This works by way of adding a new op, determine_rate, similar to
    > round_rate but with an extra parameter to allow the clock driver to
    > optionally select a different parent clock. This is used in
    > clk_calc_new_rates to decide whether to initiate a set_parent operation.
    >
    > Changes in v2:
    >
    > I've moved the mux determine_rate implementation into a core helper, but
    > I haven't pushed it fully into the core, as I think it just wouldn't
    > work correctly for more complex clocks, e.g. if you (theoretically) had
    > a combined mux and divide, you'd want to intercept the determine_rate
    > and ask for a larger rate from the parent clocks, then return the
    > divided rate. This should be possible by wrapping the mux determine_rate
    > helper.
    >
    > Patch 1 still exports the __clk_get_parent_by_index as it seems like it
    > might be a useful thing for clock implementations to have access to if
    > they ever wanted to do something more fancy with changing clock parents.
    >
    > I haven't made any attempt to implement the atomic set_parent+set_rate
    > as I don't have hardware that could take proper advantage of it, but it
    > shouldn't be too difficult for others to implement if they wanted since
    > they're fairly close to one another (in clk_change_rate()).
    >
    > * switched to using new determine_rate op rather than adding an argument
    > to round_rate.
    > * moved mux implementation into a single helper which should be usable
    > from more complex clocks which can mux.
    > * rewrite main implementation so that no changes are made until after
    > the PRE notifications have been sent, and in a way that should ensure
    > correct notifications without duplicates, and I think should be safe
    > in the event of a notification failing.
    > * various tidy ups and fixes.
    >
    > James Hogan (3):
    > clk: abstract parent cache
    > clk: add support for clock reparent on set_rate
    > clk: clk-mux: implement remuxing on set_rate
    >
    > Documentation/clk.txt | 4 +
    > drivers/clk/clk-mux.c | 1 +
    > drivers/clk/clk.c | 216 +++++++++++++++++++++++++++++++++----------
    > include/linux/clk-private.h | 2 +
    > include/linux/clk-provider.h | 12 +++
    > 5 files changed, 185 insertions(+), 50 deletions(-)
    >
    > --
    > 1.8.1.2


    \
     
     \ /
      Last update: 2013-05-13 22:41    [W:2.827 / U:0.196 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site