lkml.org 
[lkml]   [2017]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM
    [...]

    >> The only related PM thing, that shall be the decision of the driver,
    >> is whether it wants to enable runtime PM or not, during ->probe().
    >
    >
    > So do you want to create the links during the DMAengine driver probe? How do
    > you
    > plan to find all the client devices? Please note that you really want to
    > create
    > links to devices which will really use the DMA engine calls. Some client
    > drivers might decide in runtime weather to use DMA engine or not, depending
    > on
    > other data.

    I don't have great plan, just wanted to share my thoughts around the
    problems we want to solve.

    [...]

    >>
    >> If we could set up the device link already at device initialization,
    >> it should also be possible to avoid getting -EPROBE_DEFER for dma
    >> client drivers when requesting their dma channels.
    >
    >
    > At the first glance this sounds like an ultimate solution for all problems,
    > but I don't think that device links can be used this way. If I get it right,
    > you would like to create links on client device initialization, preferably
    > somewhere in the kernel driver core. This will be handled somehow by a
    > completely generic code, which will create a link each pair of devices,
    > which are connected by a phandle. Is this what you meant? Please note that
    > that time no driver for both client and provider are probed. IMHO that
    > doesn't look like a right generic approach
    >
    > How that code will know get following information:
    > 1. is it really needed to create a link for given device pair?
    > 2. what link flags should it use?
    > 3. what about circular dependencies?
    > 4. what about runtime optional dependencies?
    > 5. what about non-dt platforms? acpi?
    >

    To give a good answer of these questions, I need to spend more time
    investigating.

    However, from a top-level point of view, I think the device links
    seems like the perfect match for solving the runtime/system PM
    problems.

    No matter whether we can set up the links at device initialization
    time, driver probe or whatever time.

    > This looks like another newer ending story of "how can we avoid deferred
    > probe
    > in a generic way". IMHO we should first solve the problem of irq-safe
    > runtime
    > PM in DMA engine drivers first. I proposed how it can be done with device
    > links.
    > With no changes in the client API. Later if one decide to extend the client
    > API
    > in a way it will allow other runtime PM implementation - I see no problem to
    > convert pl330 driver to the new approach, but for the time being - this
    > would
    > be the easiest way to get it really functional.

    Agree, let's drop the deferred probe topic from the discussions - it's
    just going to be overwhelming. :-)

    [...]

    >> So besides solving the irq-safe issue for dma driver, using the
    >> device-links has additionally two advantages. I already mentioned the
    >> -EPROBE_DEFER issue above.
    >
    >
    > Not really. IMHO device links can be properly established once both drivers
    > are probed...

    Okay.

    >
    >>
    >> The second thing, is the runtime/system PM relations we get for free
    >> by using the links. In other words, the dma driver/core don't need to
    >> care about dealing with pm_runtime_get|put() as that would be managed
    >> by the dma client driver.
    >
    >
    > IMHO there might be drivers which don't want to use device links based
    > runtime
    > PM in favor of irq-safe PM or something else. This should be really left to
    > drivers.

    Okay.

    Kind regards
    Uffe

    \
     
     \ /
      Last update: 2017-02-13 16:11    [W:5.013 / U:0.704 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site