Hi Lukas,
On 2016-11-19 12:11, Lukas Wunner wrote:
On Tue, Nov 08, 2016 at 08:27:12AM +0100, Marek Szyprowski wrote:
On 2016-11-07 22:47, Luis R. Rodriguez wrote:
If so
why? If this issue is present also on systems that only use ACPI is
this possibly due to an ACPI firmware bug or the lack o
On Tue, Nov 08, 2016 at 08:27:12AM +0100, Marek Szyprowski wrote:
> On 2016-11-07 22:47, Luis R. Rodriguez wrote:
> > If so
> > why? If this issue is present also on systems that only use ACPI is
> > this possibly due to an ACPI firmware bug or the lack of some semantics
> > in ACPI to express ord
On Thu, Nov 10, 2016 at 12:56:14AM +0100, Rafael J. Wysocki wrote:
> The idea, roughly, is that if there is a single on/off switch acting
> on multiple devices, you can (a) set up a PM domain tracking all of
> those device's runtime PM invocations and (b) maintaining a reference
> counter of device
On Thu, Nov 10, 2016 at 1:12 AM, Luis R. Rodriguez wrote:
> On Thu, Nov 10, 2016 at 01:05:42AM +0100, Rafael J. Wysocki wrote:
>> On Thu, Nov 10, 2016 at 12:55 AM, Luis R. Rodriguez
>> wrote:
>> > On Tue, Nov 08, 2016 at 04:30:44PM +0100, Lukas Wunner wrote:
>> >> On Tue, Nov 08, 2016 at 08:27:1
On Thu, Nov 10, 2016 at 01:05:42AM +0100, Rafael J. Wysocki wrote:
> On Thu, Nov 10, 2016 at 12:55 AM, Luis R. Rodriguez wrote:
> > On Tue, Nov 08, 2016 at 04:30:44PM +0100, Lukas Wunner wrote:
> >> On Tue, Nov 08, 2016 at 08:27:12AM +0100, Marek Szyprowski wrote:
> >> > On 2016-11-07 22:47, Luis
On Thu, Nov 10, 2016 at 12:55 AM, Luis R. Rodriguez wrote:
> On Tue, Nov 08, 2016 at 04:30:44PM +0100, Lukas Wunner wrote:
>> On Tue, Nov 08, 2016 at 08:27:12AM +0100, Marek Szyprowski wrote:
>> > On 2016-11-07 22:47, Luis R. Rodriguez wrote:
>> > > Has there been any review of the existing simila
On Tue, Nov 8, 2016 at 4:30 PM, Lukas Wunner wrote:
> On Tue, Nov 08, 2016 at 08:27:12AM +0100, Marek Szyprowski wrote:
>> On 2016-11-07 22:47, Luis R. Rodriguez wrote:
>> > Has there been any review of the existing similar solutions out there
>> > such as the DRM / audio component framework? Woul
On Tue, Nov 08, 2016 at 04:30:44PM +0100, Lukas Wunner wrote:
> On Tue, Nov 08, 2016 at 08:27:12AM +0100, Marek Szyprowski wrote:
> > On 2016-11-07 22:47, Luis R. Rodriguez wrote:
> > > Has there been any review of the existing similar solutions out there
> > > such as the DRM / audio component fra
On Tue, Nov 08, 2016 at 08:27:12AM +0100, Marek Szyprowski wrote:
> On 2016-11-07 22:47, Luis R. Rodriguez wrote:
> > Has there been any review of the existing similar solutions out there
> > such as the DRM / audio component framework? Would that help ?
>
> Nope, none of that solution deals with
Hi Luis,
On 2016-11-07 22:47, Luis R. Rodriguez wrote:
On Thu, Oct 20, 2016 at 09:22:53AM +0200, Marek Szyprowski wrote:
This patch uses recently introduced device dependency links to track the
runtime pm state of the master's device. This way each SYSMMU controller
is set to runtime active on
On Thu, Oct 20, 2016 at 09:22:53AM +0200, Marek Szyprowski wrote:
> This patch uses recently introduced device dependency links to track the
> runtime pm state of the master's device. This way each SYSMMU controller
> is set to runtime active only when its master's device is active and can
> restor
Hi Marek,
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index 5e6d7bbf9b70..59b4f2ce4f5f 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -781,10 +781,6 @@ static void exynos_iommu_detach_device(struct
> i
Hi Sricharan,
On 2016-10-24 14:29, Sricharan wrote:
This patch uses recently introduced device dependency links to track the
runtime pm state of the master's device. This way each SYSMMU controller
is set to runtime active only when its master's device is active and can
restore or save its stat
Hi Marek,
>>> This patch uses recently introduced device dependency links to track the
>>> runtime pm state of the master's device. This way each SYSMMU controller
>>> is set to runtime active only when its master's device is active and can
>>> restore or save its state instead of being activated
Hi Sricharan,
On 2016-10-23 11:49, Sricharan wrote:
Hi Marek,
This patch uses recently introduced device dependency links to track the
runtime pm state of the master's device. This way each SYSMMU controller
is set to runtime active only when its master's device is active and can
restore or sa
Hi Marek,
>This patch uses recently introduced device dependency links to track the
>runtime pm state of the master's device. This way each SYSMMU controller
>is set to runtime active only when its master's device is active and can
>restore or save its state instead of being activated all the time
This patch uses recently introduced device dependency links to track the
runtime pm state of the master's device. This way each SYSMMU controller
is set to runtime active only when its master's device is active and can
restore or save its state instead of being activated all the time when
attached
17 matches
Mail list logo
