From: "Rafael J. Wysocki"
If the device has no links to suppliers that should be used for
runtime PM (links with DEVICE_LINK_PM_RUNTIME set), there is no
reason to walk the list of suppliers for that device during
runtime suspend and resume.
Add a simple mechanism to detect that case and possibl
Set proper link state if link is created between already probed supplier
device and to be probed consumer device.
Signed-off-by: Marek Szyprowski
---
drivers/base/core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 4e77853
From: "Rafael J. Wysocki"
Make the device suspend/resume part of the core system
suspend/resume code use device links to ensure that supplier
and consumer devices will be suspended and resumed in the right
order in case of async suspend/resume.
The idea, roughly, is to use dpm_wait() to wait for
From: "Rafael J. Wysocki"
Currently, there is a problem with handling cases where functional
dependencies between devices are involved.
What I mean by a "functional dependency" is when the driver of device
B needs both device A and its driver to be present and functional to
be able to work. Thi
This patch fixes endless recursion, which happends when device has
more than one link.
Signed-off-by: Marek Szyprowski
---
drivers/base/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 215cd44de761..4e778539b750 100644
-
Hello,
This patch series finally implements proper runtime PM support in Exynos
IOMMU driver. This has been achieved by using device links, which lets
SYSMMU controller's runtime PM to follow master's device runtime PM (the
device which actually performs DMA transaction). The main idea
behind this
This patch uses recently introduced device links to track the runtime pm
state of the master's device. This way each SYSMMU controller is runtime
active its master's device is active and can save/restore its state
instead of being enabled all the time. This way SYSMMU controllers no
longer prevents
Remove excessive, useless debug about skipping TLB invalidation, which
is a normal situation when more aggressive power management is enabled.
Signed-off-by: Marek Szyprowski
---
drivers/iommu/exynos-iommu.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/iommu/exynos-iommu.c b/dri
From: "Rafael J. Wysocki"
Modify the runtime PM framework to use device links to ensure that
supplier devices will not be suspended if any of their consumer
devices are active.
The idea is to reference count suppliers on the consumer's resume
and drop references to them on its suspend. The info
When devices are being runtime resumed during the system PM transition to
suspend state, the link suppliers might be already resumed and
have runtime pm disabled. This is normal case. This patch adds special
support for such case. Simple call to pm_runtime_get_syncreturns error
when device has runt
From: "Rafael J. Wysocki"
Add an internal wrapper around __device_release_driver() that will
acquire device locks and do the necessary checks before calling it.
The next patch will make use of it.
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Marek Szyprowski
---
drivers/base/dd.c | 30 +++
Hi Rafael,
On 2016-06-08 19:18, Rafael J. Wysocki wrote:
On Wed, Jun 8, 2016 at 12:25 PM, Marek Szyprowski
wrote:
From: Krzysztof Kozlowski
Allow drivers registering for certain runtime PM events of other
devices. Some drivers in power domain are more or less coupled. When one
driver is sus
Hi,
I only applied these patch series on lastest 4.7-rc3, is there any patches I
missed?
According to my test, it seems can not work. The problem is:
[0.916536] Call trace:
[0.918967] [] dump_backtrace+0x0/0x1ac
[0.924361] [] show_stack+0x14/0x1c
[0.929384] [] dump_stack+0x8c/0xac
On Wed, Jun 15, 2016 at 01:39:21PM +0200, Joerg Roedel wrote:
>On Tue, May 24, 2016 at 11:06:55PM +, Wei Yang wrote:
>> Hi, Joerg
>>
>> Not sure whether you think this calculation is correct.
>>
>> If I missed something for this " + 1" in your formula, I am glad to hear your
>> explanation. S
I have applied your patch to 4.7.0-rc3 mainline kernel and the machine
successfully boots with intel_iommu=on. Thank you so much for your time and
effort.
Please find the attached dmesg of successful boot with iommu enabled.
[0.00] Linux version 4.7.0-rc3-8d8a5ff (dhiru1602@ScaRage) (gcc
On 06/15/2016 08:17 AM, Tom Lendacky wrote:
> On 06/13/2016 08:51 AM, Matt Fleming wrote:
>> On Thu, 09 Jun, at 01:33:30PM, Tom Lendacky wrote:
>>>
[...]
>>
>>> I'll look further into this, but I saw that this area of virtual memory
>>> was mapped un-encrypted and after freeing the boot services
On Thu, Jun 16, 2016 at 10:26:20AM +0400, Dheeraj CVR wrote:
> I have added some debugging code to see where exactly the hang happens. The
> set_root_entry call works fine without any issues as you have expected.
> However, the hang happens when calling flush_context.
>
> flush_context -> qi_flus
Hi Russell,
I was wondering if you have time to look at this series?
Especially patch 4/6 which you had some good review comments on in v7.
On 2016-06-07 09:54:07 +0200, Niklas Söderlund wrote:
> Hi,
>
> This series tries to solve the problem with DMA with device registers
> (MMIO registers) tha
18 matches
Mail list logo
