[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3922440.p7KFeqxHrO@avalon>
Date: Sat, 20 Dec 2014 21:01:06 +0200
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: Kevin Hilman <khilman@...nel.org>,
Tomasz Figa <tfiga@...omium.org>,
Ulf Hansson <ulf.hansson@...aro.org>,
"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
iommu@...ts.linux-foundation.org, Len Brown <len.brown@...el.com>,
Pavel Machek <pavel@....cz>, Heiko Stuebner <heiko@...ech.de>,
Joerg Roedel <joro@...tes.org>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Sylwester Nawrocki <s.nawrocki@...sung.com>,
Daniel Kurtz <djkurtz@...omium.org>
Subject: Re: [RFC PATCH 2/2] iommu: rockchip: Handle system-wide and runtime PM
Hi Kevin,
On Friday 19 December 2014 03:27:35 Rafael J. Wysocki wrote:
> On Thursday, December 18, 2014 11:28:58 PM Laurent Pinchart wrote:
> > Hi Kevin,
>
> [cut]
>
>>>>> It would be better to be able to reference count the DMA engine from
>>>>> the bus master IMO and arguably you can use the runtime PM framework
>>>>> for that. Namely, give bus masters someting like
>>>>>
>>>>> pm_runtime_get_my_DMA_engine(bus_master_device)
>>>>> pm_runtime_put_my_DMA_engine(bus_master_device)
>>>>>
>>>>> and let them call these as they see fit.
>>>>
>>>> Please note that we're not talking about DMA engines here, but about
>>>> IOMMUs. DMA is involved through the DMA mapping API which hides the
>>>> IOMMU completely from the bus master drivers, not the DMA engine API.
>>>>
>>>> Exposing the IOMMU is something we want to avoid, but DMA mapping
>>>> start/stop operations could certainly be implemented.
>>>
>>> The problem with that is it only solves the IOMMU problem. We have a
>>> more generic PM dependency problem of which this IOMMU example is only a
>>> subset, so I think we need a more generic solution.
>>
>> I agree that a more generic solution is needed at least to support ACPI
>> _DEP, but that might not be optimal in the IOMMU use case as explained
>> above.
>
> Well, since we need it anyway, why don't we implement it and then figure out
> if anything more specific needs to be done for the IOMMU case?
Patches are welcome ;-)
--
Regards,
Laurent Pinchart
--
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