lkml.org 
[lkml]   [2011]   [Sep]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RFC PATCH v3] drivercore: Add driver probe deferral mechanism
    On Thu, Sep 22, 2011 at 2:29 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
    > Definitely what is needed for some of the x86 SoC stuff and would let us
    > rip out some of the special case magic for the SCU discovery.
    >
    > First thing that strikes me is driver_bound kicks the processing queue
    > again. That seems odd - surely this isn't needed because any driver that
    > does initialise this time and may allow something else to get going will
    > queue the kick itself. Thus this seems to just add overhead.
    >
    > It all looks a bit O(N²) if we don't expect the drivers that might
    > trigger something else binding to just say 'hey I'm one of the
    > troublemakers'

    The way I read it, absolute worst case is when every device but one
    depends on another device. In that case I believe it will be
    O(Nlog(N)). (Every device gets probed on the first pass, but only the
    last one gets probed. Then it goes through N-1 devices to the result
    of only 1 more device getting probed, then N-2, etc.). Actual usage
    won't be anywhere near that complexity because there tends to be a
    small number of devices on these SoCs that a lot of other devices
    depend on, so I expect that there will be somewhere on the order of
    3-4 passes for the typical embedded SoCs that I've seen.

    driver_bound is used to kick off the process because anytime a new
    device becomes active (bound to a driver), there is a high likelyhood
    that one of the devices in the pending list can now be probed.
    However, the re-probing is performed in a workqueue to make sure that
    it is somewhat serialized to prevent the *entire* pending list to be
    processed for every driver_bound() call. Instead, by kicking a
    workqueue, it guarantees that all the pending items are retried, but
    kicking the workqueue 6 times doesn't mean that the list is going to
    be processed 6 times.

    In other words, driver_bound will kick off the process, but it doesn't
    actually do the re-probing work.

    g.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-09-22 23:21    [W:3.533 / U:0.056 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site