[Ksummit-discuss] [TECH TOPIC] PM dependencies

Shuah Khan shuahkhan at gmail.com
Tue May 13 14:26:09 UTC 2014


On Tue, May 13, 2014 at 4:31 AM, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
> On Tuesday 13 May 2014 09:43:05 Daniel Vetter wrote:
>> On Tue, May 13, 2014 at 12:07 AM, Mark Brown <broonie at kernel.org> 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.
>
> One of the issues is that we need API(s) to take/release those references. In
> some cases the depender doesn't have direct access to the dependee, like in
> the IOMMU case where the DMA mapping API hides the IOMMU. One of the questions
> here is whether this kind of problems should be solved with ad-hoc solutions
> (for instance adding PM support to the DMA mapping API in this specific case),
> or in a more generic fashion. Answering that will require a comprehensive list
> of use cases to detect common patterns.
>
>> I guess some helpers to grab/drop runtime PM references on all parts
>> of a componentized device should resolve this?
>
> That could help in some cases, but there might be ordering issues.

Can we use pm domains concept to solve the problem? As it exists
today, it probably
can't support loosely associated devices, however, could it be
extended to support
handling device groups that don't necessarily share power source and/or clock.

I started looking at this as a way to solve media device PM issues,
however I haven't
had a chance to experiment with this idea.

-- Shuah
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss


More information about the Ksummit-discuss mailing list