Hi Joerg,
> -Original Message-
> From: Shameerali Kolothum Thodi
> Sent: Monday, January 29, 2018 4:42 PM
> To: 'Will Deacon' ; Joerg Roedel
> Cc: lorenzo.pieral...@arm.com; robin.mur...@arm.com;
> marc.zyng...@arm.com; j...@8bytes.org; John Garry
> ; xuwei (O) ; Guohanjun
> (Hanjun Guo)
On 1/30/2018 1:12 AM, Rob Herring wrote:
On Fri, Jan 19, 2018 at 05:13:42PM +0530, Vivek Gautam wrote:
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
On 19/01/18 11:43, Vivek Gautam wrote:
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_runt
Adding Jean and the IOMMU list as well.
Am 31.01.2018 um 13:43 schrieb Oded Gabbay:
On Tue, Jan 30, 2018 at 6:53 PM, Felix Kuehling wrote:
[SNIP]
There was some discussion last year about a generic PASID allocator in
the iommu subsystem:
https://lists.linuxfoundation.org/pipermail/iommu/2017-
On 19/01/18 11:43, Vivek Gautam wrote:
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-b
On 19/01/18 11:43, Vivek Gautam wrote:
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 smm
Hi Christian,
On 31/01/18 13:04, Christian König wrote:
> Adding Jean and the IOMMU list as well.
>
> Am 31.01.2018 um 13:43 schrieb Oded Gabbay:
>> On Tue, Jan 30, 2018 at 6:53 PM, Felix Kuehling
>> wrote:
>>> [SNIP]
>> There was some discussion last year about a generic PASID allocator in
>>
On Wed, Jan 31, 2018 at 1:52 AM, Tomasz Figa wrote:
> Hi Rob,
>
> On Wed, Jan 31, 2018 at 2:05 AM, Rob Herring wrote:
>> On Wed, Jan 24, 2018 at 06:35:11PM +0800, Jeffy Chen wrote:
>>> From: Tomasz Figa
>>>
>>> Current code relies on master driver enabling necessary clocks before
>>> IOMMU is ac
Hi Suravee,
On 31/01/18 01:48, Suravee Suthikulpanit wrote:
Currently, iommu_unmap and iommu_unmap_fast return unmapped
pages with size_t. However, the actual value returned could
be error codes (< 0), which can be misinterpreted as large
number of unmapped pages. Therefore, change the return t
Hi,
I'm enabling the ARM SMMU-500 on an ARM64 A53. I'm hitting a data abort
in the probe functions because I'm accessing the registers in EL1 mode.
Linux starts in EL2 mode but drops down to EL1 mode by the time it
reaches the arm-smmu probe function.
Is there something else I need to add t
On 31 January 2018 at 22:09, Thor Thayer wrote:
> Hi,
>
> I'm enabling the ARM SMMU-500 on an ARM64 A53. I'm hitting a data abort in
> the probe functions because I'm accessing the registers in EL1 mode.
>
Why do you think the fact that you are running at EL1 is causing the data abort?
> Linux s
From: Eric Dumazet
Some devices (like mlx4) try hard to allocate memory on selected
NUMA node, but it turns out intel_alloc_coherent() is not NUMA
aware yet.
Note that dma_generic_alloc_coherent() in arch/x86/kernel/pci-dma.c
gets this right.
Signed-off-by: Eric Dumazet
Cc: Benjamin Serebrin
Hi Ard,
On 01/31/2018 04:21 PM, Ard Biesheuvel wrote:
On 31 January 2018 at 22:09, Thor Thayer wrote:
Hi,
I'm enabling the ARM SMMU-500 on an ARM64 A53. I'm hitting a data abort in
the probe functions because I'm accessing the registers in EL1 mode.
Why do you think the fact that you are r
> On 31 Jan 2018, at 23:31, Thor Thayer wrote:
>
> Hi Ard,
>
>> On 01/31/2018 04:21 PM, Ard Biesheuvel wrote:
>>> On 31 January 2018 at 22:09, Thor Thayer
>>> wrote:
>>> Hi,
>>>
>>> I'm enabling the ARM SMMU-500 on an ARM64 A53. I'm hitting a data abort in
>>> the probe functions because I'
On Wed, 2018-01-31 at 14:45 -0800, Eric Dumazet wrote:
> From: Eric Dumazet
>
> Some devices (like mlx4) try hard to allocate memory on selected
> NUMA node, but it turns out intel_alloc_coherent() is not NUMA
> aware yet.
>
> Note that dma_generic_alloc_coherent() in arch/x86/kernel/pci-dma.c
>
Hi Robin,
On 2/1/18 1:02 AM, Robin Murphy wrote:
Hi Suravee,
On 31/01/18 01:48, Suravee Suthikulpanit wrote:
Currently, iommu_unmap and iommu_unmap_fast return unmapped
pages with size_t. However, the actual value returned could
be error codes (< 0), which can be misinterpreted as large
numbe
On 1/31/2018 5:53 PM, Robin Murphy wrote:
On 19/01/18 11:43, Vivek Gautam wrote:
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 t
From: Eric Dumazet
Some devices (like mlx4) try hard to allocate memory on selected
NUMA node, but it turns out intel_alloc_coherent() is not NUMA
aware yet.
Note that dma_generic_alloc_coherent() in arch/x86/kernel/pci-dma.c
gets this right.
Signed-off-by: Eric Dumazet
Cc: Benjamin Serebrin
18 matches
Mail list logo
