Hi,
>On 2017-02-01 13:52, Lorenzo Pieralisi wrote:
>>
>> I debugged the issue and Nate's fix is correct, the fact that you
>> can't it hit it with mainline is just a matter of timing because it has
>> to do with the CTX pointer value (we OR it with the existing value), so
>> it may work or not dep
On 02/03/2017 03:01 AM, Nate Watterson wrote:
On 2017-02-01 13:52, Lorenzo Pieralisi wrote:
I debugged the issue and Nate's fix is correct, the fact that you
can't it hit it with mainline is just a matter of timing because it has
to do with the CTX pointer value (we OR it with the existing valu
On 2017-02-01 13:52, Lorenzo Pieralisi wrote:
I debugged the issue and Nate's fix is correct, the fact that you
can't it hit it with mainline is just a matter of timing because it has
to do with the CTX pointer value (we OR it with the existing value), so
it may work or not depending on how the
Hi Robin,
On Thu, Feb 2, 2017 at 2:15 PM, Robin Murphy wrote:
> On 31/01/17 11:12, Geert Uytterhoeven wrote:
>> Add support for allocating physically contiguous DMA buffers on arm64
>> systems with an IOMMU. This can be useful when two or more devices
>> with different memory requirements are in
Hi,
On Thu, Feb 02, 2017 at 10:40:18PM +0530, Sricharan R wrote:
> +- clock-names:Should be a pair of "smmu_iface_clk" and "smmu_bus_clk"
> + required for smmu's register group access and interface
> + clk for the smmu's underlying bus access.
> +
> +- clocks:
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
---
drivers/iommu/arm-smmu.c | 45 ++
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
---
drivers/iommu/arm-smmu.c
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 symmu's
runtime to follow the master's runtime pm, so the smmu remains
powered only when the masters use it.
Took so
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
runtime pm, above sai
On Wed, Feb 1, 2017 at 11:10 PM, Sricharan wrote:
> Hi Rob,
>
>>On Wed, Feb 1, 2017 at 10:23 AM, Rob Clark wrote:
>>> Before the driver is probed, arm_smmu_add_device() helpfully attaches
>>> an IOMMU_DOMAIN_DMA domain. Which ofc does not support stalling, and
>>> when the driver later attaches
On Thu, Feb 02, 2017 at 09:15:19PM +0530, Sricharan wrote:
> Hi Rob,
>
> >-Original Message-
> >From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
> >On Behalf Of Rob Clark
> >Sent: Thursday, February 02, 2017 8:33 PM
> >To: Joerg Roedel
> >Cc: Will Deacon ; iom
Hi Rob,
>-Original Message-
>From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
>On Behalf Of Rob Clark
>Sent: Thursday, February 02, 2017 8:33 PM
>To: Joerg Roedel
>Cc: Will Deacon ; iommu@lists.linux-foundation.org;
>Sricharan ; linux-arm-
>ker...@lists.infra
On Thu, Feb 02, 2017 at 10:02:50AM -0500, Rob Clark wrote:
> On Thu, Jan 26, 2017 at 12:18 PM, Joerg Roedel wrote:
> > On Tue, Jan 24, 2017 at 08:42:23PM +0530, Sricharan wrote:
> >> Thanks for this series. We had a case with the GPU.
> >> The GPU's iommu was setup by kernel and the GPU
> >> also
On Thu, Jan 26, 2017 at 12:18 PM, Joerg Roedel wrote:
> On Tue, Jan 24, 2017 at 08:42:23PM +0530, Sricharan wrote:
>> Thanks for this series. We had a case with the GPU.
>> The GPU's iommu was setup by kernel and the GPU
>> also does dynamic updates for on-the-fly switching between
>> process page
The mediatek IOMMU driver enables some drivers that it does not directly
rely on, and that causes a warning for build testing:
warning: (MTK_IOMMU_V1) selects COMMON_CLK_MT2701_VDECSYS which has unmet
direct dependencies (COMMON_CLK && COMMON_CLK_MT2701)
warning: (MTK_IOMMU_V1) selects COMMON_CLK
Hi Geert,
On 31/01/17 11:12, Geert Uytterhoeven wrote:
> Add support for allocating physically contiguous DMA buffers on arm64
> systems with an IOMMU. This can be useful when two or more devices
> with different memory requirements are involved in buffer sharing.
>
> Note that as this uses the
On Wed, Feb 1, 2017 at 11:10 PM, Sricharan wrote:
> Hi Rob,
>
>>On Wed, Feb 1, 2017 at 10:23 AM, Rob Clark wrote:
>>> Before the driver is probed, arm_smmu_add_device() helpfully attaches
>>> an IOMMU_DOMAIN_DMA domain. Which ofc does not support stalling, and
>>> when the driver later attaches
17 matches
Mail list logo
