From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTP id 4D7F826 for ; Thu, 22 May 2014 00:02:39 +0000 (UTC) Received: from v094114.home.net.pl (v094114.home.net.pl [79.96.170.134]) by smtp1.linuxfoundation.org (Postfix) with SMTP id 305371FAA6 for ; Thu, 22 May 2014 00:02:37 +0000 (UTC) From: "Rafael J. Wysocki" To: Kevin Hilman Date: Thu, 22 May 2014 02:19:35 +0200 Message-ID: <6638836.llWl1tdgvD@vostro.rjw.lan> In-Reply-To: <7hwqdgqtg5.fsf@paris.lan> References: <1872038.43ncqEMWSx@avalon> <6546269.8BCSq47QAR@avalon> <7hwqdgqtg5.fsf@paris.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Cc: ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [TECH TOPIC] PM dependencies List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tuesday, May 20, 2014 09:57:14 AM Kevin Hilman wrote: > Laurent Pinchart writes: > > > On Wednesday 14 May 2014 00:34:56 Rafael J. Wysocki wrote: > >> On Wednesday, May 14, 2014 12:27:47 AM Rafael J. Wysocki wrote: > >> > On Monday, May 12, 2014 11:07:29 PM Mark Brown wrote: > >> > > On Mon, May 12, 2014 at 11:16:57PM +0200, Tomasz Figa wrote: > >> > > > On 12.05.2014 22:31, Mark Brown wrote: > >> > > > > It also solves the system suspend dependencies. Why don't the > >> > > > > runtime PM dependencies just work with reference counting? > >> > > > > >> > > > Runtime PM dependencies work with reference counting just fine, but > >> > > > only for topologies matching Linux driver model, e.g. devices with > >> > > > exactly one device they depend on, e.g. SPI controller and SPI devices > >> > > > on the bus driven by it. Add there an IOMMU and other various strange > >> > > > things that should be transparent to the drivers and it stops working. > >> > > > >> > > There's no reason why runtime PM references have to follow the topology > >> > > - you do get a default reference count up to any parent (though we break > >> > > that sometimes, as is the case with SPI controllers being suspended even > >> > > though the devices below them are active) but there's nothing stopping > >> > > references being taken outside the topology. > >> > > >> > Precisely. > >> > >> BTW, I guess that the problem is resume and specifically the fact that if > >> a child device resumes, the parent will also resume automatically, but the > >> other devices the child may depend on will not (the child's resume may need > >> to resume them directly). > >> > >> But I'm not sure why that is a problem, so can anyone please share some > >> details? > > > > Here are two real life examples. > > > > 1. IOMMU and bus master > > > > Bus master devices connected to an IOMMU need the IOMMU to be powered on in > > order to access memory. In order to save power the IOMMU should of course be > > powered off as much as possible. > > > > The tricky part here comes from the fact that the IOMMU is hidden behind the > > DMA API. The bus master driver can't manage the IOMMU power state eplicitly by > > taking/releasing references to the IOMMU device. > > > > This could easily be solved in an ad-hoc fashion by extending the DMA mapping > > API, but I'm wondering whether similar issues wouldn't benefit from a common > > solution (I'm not sure yet what all the similar issues are, hence the topic > > proposal to try and gather use cases). > > I'll continue to beat the runtime PM drum... What about async system suspend/resume, then? > This would also easily be solved if the bus master device, the IOMMU and > the dmaengine (or the platform-specific dma driver) were all using > runtime PM. e.g. bus master device is a user of dmaengine, which is a > user of the IOMMU. If all are using runtime PM, the fact that a device > is "in use", means runtime PM would keep them active when needed. In > this example, it wouldn't matter that the bus master device doesn't know > about the IOMMU. It suffices that the dmaengine driver knows about the > IOMMU. That requires it to be able to say "now I'm not using you any more" whenever the device in question suspend and "now I'm going to use you again" when that device resumes. Does something like that happen today? There are more weird cases still. For example, we have the _DEP object in ACPI that basically says "this device depends on that one" and there may be no other relationship between the two whatsoever. How are we supposed to implement this within the existing frameworks? Rafael