In the commit 05f80300dc8b, the iommu framework has supposed all the
iommu drivers have their owner iommu-group, it get rid of the FIXME
workarounds while the group is NULL. But the flow of Mediatek M4U gen1
looks a bit trick that it will hang at this case:
From: Markus Elfring
Date: Fri, 19 Jan 2018 22:22:38 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/iommu/ipmmu-vmsa.c | 4 +---
1 file changed, 1 insertion(+), 3
From: Markus Elfring
Date: Fri, 19 Jan 2018 21:44:31 +0100
Omit extra messages for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/iommu/tegra-gart.c | 8 ++--
1 file changed, 2 insertions(+)
Hi Jean-Philippe,
On 19/01/18 17:21, Jean-Philippe Brucker wrote:
> On 16/01/18 23:26, Auger Eric wrote:
> [...]
>>> + switch (mem->subtype) {
>>> + case VIRTIO_IOMMU_RESV_MEM_T_MSI:
>>> + region = iommu_alloc_resv_region(addr, size, prot,
>>> +
On 16/01/18 23:26, Auger Eric wrote:
[...]
>> +switch (mem->subtype) {
>> +case VIRTIO_IOMMU_RESV_MEM_T_MSI:
>> +region = iommu_alloc_resv_region(addr, size, prot,
>> + IOMMU_RESV_MSI);
> if (!region)
> return -ENOMEM;
>> +
On 2018-01-19 05:27, Jean-Philippe Brucker wrote:
Hi Sinan,
On 19/01/18 04:52, Sinan Kaya wrote:
Hi Jean-Philippe,
On 10/6/2017 9:31 AM, Jean-Philippe Brucker wrote:
/**
+ * iommu_process_bind_device - Bind a process address space to a
device
+ * @dev: the device
+ * @task: the process to
While handling the concerned iommu, there should not be a
need to power control the drm devices from iommu interface.
If these drm devices need to be powered around this time,
the respective drivers should take care of this.
Replace the pm_runtime_get/put_sync() with
pm_runtime_get/put_suppliers()
The device link allows the pm framework to tie the supplier and
consumer. So, whenever the consumer is powered-on the supplier
is powered-on first.
There are however cases in which the consumer wants to power-on
the supplier, but not itself.
E.g., A Graphics or multimedia driver wants to power-on
From: Sricharan R
Finally add the device link between the master device and
smmu, so that the smmu gets runtime enabled/disabled only when the
master needs it. This is done from add_device callback which gets
called once when the master is added to the smmu.
Signed-off-by: Sricharan R
---
driv
qcom,smmu-v2 is an arm,smmu-v2 implementation with specific
clock and power requirements. This smmu core is used with
multiple masters on msm8996, viz. mdss, video, etc.
Add bindings for the same.
Signed-off-by: Vivek Gautam
---
.../devicetree/bindings/iommu/arm,smmu.txt | 43 +++
From: Sricharan R
The smmu device probe/remove and add/remove master device callbacks
gets called when the smmu is not linked to its master, that is without
the context of the master device. So calling runtime apis in those places
separately.
Signed-off-by: Sricharan R
[vivek: Cleanup pm runtim
From: Sricharan R
The smmu needs to be functional only when the respective
master's using it are active. The device_link feature
helps to track such functional dependencies, so that the
iommu gets powered when the master device enables itself
using pm_runtime. So by adapting the smmu driver for
r
This series provides the support for turning on the arm-smmu's
clocks/power domains using runtime pm. This is done using the
recently introduced device links patches, which lets the smmu's
runtime to follow the master's runtime pm, so the smmu remains
powered only when the masters use it.
It also
Hi Sinan,
On 19/01/18 04:52, Sinan Kaya wrote:
> Hi Jean-Philippe,
>
> On 10/6/2017 9:31 AM, Jean-Philippe Brucker wrote:
>> /**
>> + * iommu_process_bind_device - Bind a process address space to a device
>> + * @dev: the device
>> + * @task: the process to bind
>> + * @pasid: valid address wher
14 matches
Mail list logo
