[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20151105121730.GY12910@localhost>
Date: Thu, 5 Nov 2015 17:47:30 +0530
From: Vinod Koul <vinod.koul@...el.com>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: Kevin Hilman <khilman@...nel.org>,
Jon Hunter <jonathanh@...dia.com>,
Laxman Dewangan <ldewangan@...dia.com>,
Stephen Warren <swarren@...dotorg.org>,
Thierry Reding <thierry.reding@...il.com>,
Alexandre Courbot <gnurou@...il.com>,
dmaengine@...r.kernel.org, linux-tegra@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/6] dmaengine: tegra-apb: Correct runtime-pm usage
On Thu, Nov 05, 2015 at 03:15:18AM +0100, Rafael J. Wysocki wrote:
> > > + Rafael
> > >
> > > This is contrariry to what I see, If my driver is runtime suspended and on
> > > suspend, it gets runtime resumed and then suspended
> >
> > Since I was late to the thread, can you explain what kind of driver and
> > on what bus type you're seeing this behavior?
> >
> > It could be that your bus-type is doing something, but I don't think it
> > should be the PM core.
>
> Right.
>
> Bus types do that, the core doesn't. The ACPI PM domain does that too
> for some devices.
>
> So Vinod, more details, please.
Okay relooking at core I do think that runtime resume should not be invoked
while suspending, as core seems to call pm_runtime_get_noresume() but I am
still missing something here..
I do see this behaviour (runtime resume on suspend) on Intel audio drivers
which are PCI devices, is PCI or ACPI doing some magic here.
I have seen this as consistent behavior and actually an irritant, as we used
to download firmware in resume patch, but then we end up thrashing the
controller while going to suspend!
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists