[lkml]   [2012]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] regulator: Provide a check for dummy regulator
    On Thu, Apr 19, 2012 at 03:21:37PM +0530, Jassi Brar wrote:
    > Usually changing the regulator output involves delays before/after the
    > operation.
    > There are consumer drivers shared by platforms, where some may
    > not really have a regulator in the path. Which causes the consumer
    > to unnecessarily (sometimes disruptively) incur delays for the
    > "dummy" regulator.

    This analysis doesn't sound quite right - if it's the dummy regulator
    then obviously these delays don't happen so presumably the cost is
    actually coming from the rdev mutex and recursion up the regulator tree
    - the basic overheads of calling into the regulator API.

    > Since the 'struct regulator' is opaque outside of the core,
    > provide a function to check if the given regulator is a dummy one.

    No, this isn't great from a usability and abstraction point of view.

    In usability terms this sort of performance optimisation is going to be
    desired by a wide range of drivers (and wouldn't hurt those that don't
    urgently need it) so we shouldn't force every user to open code the use
    of this information. Worse, the whole point of the dummy regulator is
    that it allows users to not worry about this sort of stuff so it'd mean
    that the dummy regulator was failing to perform its only function.

    In abstraction terms it's not the fact that it's a dummy regulator
    that's interesting here but rather the fact that the regulator doesn't
    have control the consumer can use and there's a whole raft of other
    reasons why that might be the case. The constraints may not permit
    status changes, or a real regulator may not physically support enable
    and disable operations (eg, if there's a GPIO for enable and it's tied
    on all the time). If there's a useful performance win for dummy
    regulators it'll apply equally well to all these other cases so we
    should't be special casing dummy regulators.

    I've just sent out an untested patch (you're CCed) which should give a
    substantial win for the enable/disable case which will hopefully address
    the issue for you. If you're concerned about voltage change rather than
    enable/disable I'd like to understand better exactly where the
    performance is going but we can certainly do a similar fast path for
    fixed voltage regulators. I'd be surprised if consumers that need to
    change voltages played nicely with the fixed voltage regulator while
    using it often enough for anyone to care about performance.

    I really don't understand why people are so keen to special case things
    like this in individual consumers, not sure what we can do to encourage
    more generic fixes. There was a guy from Qualcomm the other week who
    was absolutely insistent that we had to do some fragile special case
    stuff with supplies for similar reasons :(
    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2012-04-19 14:45    [W:0.029 / U:10.876 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site