lkml.org 
[lkml]   [2011]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 1/7] clk: Add a generic clock infrastructure
    On Mon, Oct 03, 2011 at 10:24:52AM -0500, Rob Herring wrote:
    > On 10/03/2011 09:25 AM, Mark Brown wrote:

    > > This isn't in any way specific to clocks, right now the likely solution
    > > looks to be Grant's changes for retrying probe() as new devices come on
    > > line. With that devices can return a code from their probe() which
    > > tells the driver core that they couldn't get all the resources they need
    > > and that it should retry the probe() if more devices come on-line.

    > Except SOC clocks are initialized very early before timers are up and
    > there can be a very high number of dependencies (every clock except
    > fixed clocks). With the driver probe retry, retrying is the exception,
    > not the rule.

    > Retrying would require every caller to maintain a list of clks to
    > retry. With 2 stages, you can move that into the core clock code.

    They don't need to maintain a list of clocks to retry, they need to
    unwind when probe() fails. But yes.

    > There are not typically a large number of board-level/driver created
    > clocks, so ensuring correct register order is not really a problem. In
    > cases where there is a cross-driver dependency, the probe retry is a
    > good solution.

    I dunno, I get the impression that some of this is due to the current
    limitations of the clock API rather than due to a lack of clocks -
    perhaps that's specific to the applications I look at, though.
    applications


    \
     
     \ /
      Last update: 2011-10-03 18:33    [W:3.133 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site