lkml.org 
[lkml]   [2014]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v8 3/5] amba: Don't unprepare the clocks if device driver wants IRQ safe runtime PM
    From
    On 4 November 2014 14:59, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
    > On Tuesday, November 04, 2014 10:11:35 AM Ulf Hansson wrote:
    >> On 4 November 2014 02:57, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
    >> > On Monday, November 03, 2014 10:41:02 AM Alan Stern wrote:
    >> >> On Mon, 3 Nov 2014, Russell King - ARM Linux wrote:
    >> >>
    >> >> > That makes it pretty horrid from the point of view of having bus
    >> >> > management code, because we now have the management of the bus clock
    >> >> > split between the bus layer and the device driver.
    >> >> >
    >> >> > This is /really/ a problem for runtime PM. Runtime PM permits there
    >> >> > to be a bus layer involved - and runtime PM can also be coupled up
    >> >> > to PM domains as well. For all this stuff, the context which the
    >> >> > callbacks are called in depends on whether the driver itself has
    >> >> > marked the device as having IRQ-safe callbacks.
    >> >> >
    >> >> > That's fine, but the bus and PM domain level code then /really/ needs
    >> >> > to know what context they're being called in, so they know whether
    >> >> > they can sleep or not, or they must to be written to always use
    >> >> > non-sleeping functions so they work in both contexts. If we assume
    >> >> > the former, then that implies that the irq-safe flag must never change
    >> >> > state between a suspend and a resume.
    >> >>
    >> >> If a bus subsystem or PM domain is going to allow its drivers to choose
    >> >> between IRQ-safe and non-IRQ-safe runtime PM, then it is up to the
    >> >> subsystem to come up with a way for drivers to indicate their choice.
    >> >>
    >> >> I tend to agree with Rafael that testing dev->power.irq_safe should be
    >> >> good enough, with no real need for a wrapper. But the subsystem can
    >> >> use a different mechanism if it wants.
    >> >>
    >> >> Bear in mind, however, that once the irq_safe flag has been set, the
    >> >> runtime PM core offers no way to turn it off again.
    >> >
    >> > There is a problem with it, though. Say, a driver handles a device that
    >> > may or may not be in a power domain. Or in other words, the power domain
    >> > the device is in may or may not be always on. If the domain is always on,
    >> > the runtime PM callbacks are IRQ-safe (they depend on the driver only).
    >> > If it isn't, they may not be IRQ-safe. How's the driver going to decide
    >> > whether or not to set power.irq_safe?
    >>
    >> From my point of view; the decision whether the driver will set the
    >> IRQ safe flag is in principle a software design choice.
    >>
    >> Currently genpd isn't able to power off, if one of its devices are IRQ
    >> safe configured. That's a limitation in genpd which we need to fix and
    >> it's on my TODO list.
    >>
    >> My point is thus, I don't think the driver should care about PM
    >> domains at all regarding using the IRQ safe option. Does that make
    >> sense?
    >
    > Yes, it does, and that's the heart of the problem above. The driver should
    > not care about wherther or not the device is in a power domain, but it needs
    > to know that when deciding whether or not to set power.irq_safe. Catch 22.

    Why is it catch22? The problem is supposed to be fixed in the generic
    PM domain. How we do that is a different question.

    Until genpd get fixed, the driver can still keep using irq_safe if
    they want to. It will only lead to limitations if the device is
    attached to a genpd.

    Kind regards
    Uffe


    \
     
     \ /
      Last update: 2014-11-04 17:41    [W:8.367 / U:2.988 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site