[Ksummit-discuss] [TECH TOPIC] PM dependencies

Shuah Khan shuahkhan at gmail.com
Mon May 12 17:51:54 UTC 2014


On Mon, May 12, 2014 at 11:43 AM, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
> Hello,
>
> On modern systems many PM dependencies don't follow the Linux kernel device
> model based on parent-child relationships from a control bus point of view.
> For instance a GPU will need the IOMMU that services its memory requests to be
> powered on to perform DMA operations.
>
> Ad-hoc solutions with subsystem-specific or even driver-specific APIs have
> been implemented (see omap_iommu_save_ctx and omap_iommu_restore_ctx in
> include/linux/omap-iommu.h for instance, that push the burden of saving and
> restoring the IOMMU registers to bus master drivers), but they make automatic
> handling of hardware resources difficult. In the IOMMU case again, the goal is
> to hide IOMMU handling inside the DMA mapping API and make its usage
> completely transparent to bus master drivers in most of the cases. An IOMMU-
> specific API to explicitly control IOMMU power from the bus master driver
> would make that goal impossible to reach.
>
> The problem is not limited to IOMMUs. We have similar dependencies at
> suspend/resume time with camera interfaces for instance, where two completely
> unrelated device in the Linux device hierarchy (a camera interface platform
> device in the SoC and an I2C camera sensor) need to be suspended and resumed
> in a controlled order. I'm sure many more use cases exist.

We discussed this topic briefly at the Media Mini-summit.  I looking
into similar
use-cases in media devices. Suspend/resume of a tuner for example should only
be done once as opposed multiple times by drivers that think they have exclusive
access to the tuner on a media device.

I am interested in this discussion and would like to participate.
Requesting nomination.

-- 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