Hi Morimoto-san,
On Fri, Sep 14, 2018 at 2:53 AM Kuninori Morimoto
wrote:
> > > Before 6c92d5a2744e2761 patch, driver will forcibly ignore
> > > non-SSI modules, and try to use PIO mode.
> > > I'm not sure it is "kindly support" or "overkill support".
> > >
> > > After this patch, it needs DMA, o
> From: Jerome Glisse
> Sent: Thursday, September 13, 2018 10:52 PM
>
[...]
> AFAIK, on x86 and PPC at least, all PCIE devices are in the same group
> by default at boot or at least all devices behind the same bridge.
the group thing reflects physical hierarchy limitation, not changed
cross boot.
On Thu, Sep 13, 2018 at 10:51:50AM -0400, Jerome Glisse wrote:
> Date: Thu, 13 Sep 2018 10:51:50 -0400
> From: Jerome Glisse
> To: Kenneth Lee
> CC: Kenneth Lee , Alex Williamson
> , Herbert Xu ,
> k...@vger.kernel.org, Jonathan Corbet , Greg Kroah-Hartman
> , Zaibo Xu ,
> linux-...@vger.kern
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Friday, September 14, 2018 10:47 AM
>
> Hi,
>
> On 09/13/2018 01:54 AM, Jean-Philippe Brucker wrote:
> > On 12/09/2018 03:42, Lu Baolu wrote:
> >> Hi,
> >>
> >> On 09/11/2018 12:22 AM, Jean-Philippe Brucker wrote:
> >>> Hi,
> >>>
> >>> On
Hi,
On 09/13/2018 01:54 AM, Jean-Philippe Brucker wrote:
On 12/09/2018 03:42, Lu Baolu wrote:
Hi,
On 09/11/2018 12:22 AM, Jean-Philippe Brucker wrote:
Hi,
On 30/08/2018 05:09, Lu Baolu wrote:
Below APIs are introduced in the IOMMU glue for device drivers to use
the finer granularity transla
Hi Geert
> > ...which is in fact the exact same problem that the IOMMU code has -
> > might it make sense to give of_dma_request_slave_channel() similar
> > (optional?) driver_deferred_probe_check_state() logic, i.e. "if my DMAC
> > driver's not shown up by this point, assume it's not built-in a
Hi Geert
> > Before 6c92d5a2744e2761 patch, driver will forcibly ignore
> > non-SSI modules, and try to use PIO mode.
> > I'm not sure it is "kindly support" or "overkill support".
> >
> > After this patch, it needs DMA, otherwise, probe will be failed.
> > DT shouldn't have non-SSI modules if y
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Thursday, September 13, 2018 11:03 PM
>
> On 13/09/2018 01:19, Tian, Kevin wrote:
> >>> This is proposed for architectures which support finer granularity
> >>> second level translation with no impact on architectures whi
On Thu, Sep 13, 2018 at 04:03:01PM +0100, Jean-Philippe Brucker wrote:
> On 13/09/2018 01:19, Tian, Kevin wrote:
> >>> This is proposed for architectures which support finer granularity
> >>> second level translation with no impact on architectures which only
> >>> support Source ID or the similar
All we need is to wire up .flush_iotlb_all properly and implement the
domain attribute, and iommu-dma and io-pgtable-arm will do the rest for
us. Rather than bother implementing it for v7s format for the highly
unlikely chance of that being relevant, we can simply hide the
non-strict flag from io-p
From: Zhen Lei
Add a bootup option to make the system manager can choose which mode to
be used. The default mode is strict.
Signed-off-by: Zhen Lei
[rm: make it a generic iommu-dma feature]
Signed-off-by: Robin Murphy
---
.../admin-guide/kernel-parameters.txt | 13 +
driv
From: Zhen Lei
Dynamically choose strict or non-strict mode for page table config based
on the iommu domain type.
Signed-off-by: Zhen Lei
[rm: convert to domain attribute]
Signed-off-by: Robin Murphy
---
drivers/iommu/arm-smmu-v3.c | 33 +++--
1 file changed, 27 in
Since this might become a repeated idiom in drivers, let's add a tidy
encapsulation from the outset.
Signed-off-by: Robin Murphy
---
drivers/iommu/io-pgtable.c | 9 +
drivers/iommu/io-pgtable.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/drivers/iommu/io-pgtable.c b/drivers/io
From: Zhen Lei
1. Save the related domain pointer in struct iommu_dma_cookie, make iovad
capable call domain->ops->flush_iotlb_all to flush TLB.
2. During the iommu domain initialization phase, base on domain->non_strict
field to check whether non-strict mode is supported or not. If so, cal
From: Zhen Lei
To support non-strict mode, now we only TLBI and sync for strict mode,
except for non-leaf invalidations since page table updates themselves
must always be synchronous.
To save having to reason about it too much, make sure the invalidation
in arm_lpae_split_blk_unmap() just perfor
Hi all,
Since we'd like to get this polished up and merged and Leizhen has other
commitments, here's v6 of the previous series[1] wherein I address all
my own feedback :)
The principal change is that I've inverted things slightly such that
it's now a generic domain attribute controlled by iommu-d
From: Zhen Lei
.flush_iotlb_all is currently stubbed to arm_smmu_iotlb_sync() since the
only time it would ever need to actually do anything is for callers
doing their own explicit batching, e.g.:
iommu_unmap_fast(domain, ...);
iommu_unmap_fast(domain, ...);
iommu_iotlb_f
The generic fallback of arch_teardown_dma_ops() clears the dma_ops
pointer but the ARM specific version does not. Rename the generic one,
so it can be called from ARM specific one, too. This will ensure
consistent behaviour.
Signed-off-by: Wolfram Sang
---
arch/arm/mm/dma-mapping.c | 6 +++---
While sanitizig the pointer for dma_ops on teardown, do the same for
dma_parms, too. Rename the function to have a more generic name.
Signed-off-by: Wolfram Sang
---
arch/arm/mm/dma-mapping.c | 2 +-
include/linux/dma-mapping.h | 5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff
Update the comment because we don't set the pointer to NULL anymore.
Also use the correct pointer name 'dma_ops' instead of 'dma_map_ops'.
Fixes: 1874619a7df4 ("ARM: dma-mapping: Set proper DMA ops in
arm_iommu_detach_device()")
Signed-off-by: Wolfram Sang
---
arch/arm/mm/dma-mapping.c | 2 +-
When working with dma_set_max_seg_size(), I noticed issues with a
dangling dma_parms pointer. I saw Christoph just worked on handling
something similar for the dma_ops pointer, too. I came up with three
patches on top of Christoph's work which I send out for discussion here:
Patch 1 fixes a meanwh
On 13/09/2018 01:19, Tian, Kevin wrote:
>>> This is proposed for architectures which support finer granularity
>>> second level translation with no impact on architectures which only
>>> support Source ID or the similar granularity.
>>
>> Just to be clear, in this paragraph you're only referring to
On Thu, Sep 13, 2018 at 04:32:32PM +0800, Kenneth Lee wrote:
> On Tue, Sep 11, 2018 at 09:40:14AM -0400, Jerome Glisse wrote:
> > On Tue, Sep 11, 2018 at 02:40:43PM +0800, Kenneth Lee wrote:
> > > On Mon, Sep 10, 2018 at 11:33:59PM -0400, Jerome Glisse wrote:
> > > > On Tue, Sep 11, 2018 at 10:42:0
On 13/09/18 14:15, Geert Uytterhoeven wrote:
Currently the type-1 IOMMU instantiation depends on "ARM_SMMU ||
ARM_SMMU_V3", while it applies to other ARM/ARM64 platforms with an
IOMMU (e.g. Renesas VMSA-compatible IPMMUs).
Instead of extending the list of IOMMU types on ARM platforms, replace
th
Currently the type-1 IOMMU instantiation depends on "ARM_SMMU ||
ARM_SMMU_V3", while it applies to other ARM/ARM64 platforms with an
IOMMU (e.g. Renesas VMSA-compatible IPMMUs).
Instead of extending the list of IOMMU types on ARM platforms, replace
the list by "ARM || ARM64", like other architectu
Hi Robin,
On Thu, Sep 13, 2018 at 12:12 PM Robin Murphy wrote:
> On 13/09/18 10:00, Geert Uytterhoeven wrote:
> [...]
> > The main issue is that if of_dma_find_controller() fails, a DMA slave driver
> > cannot distinguish between dmac not yet probed successfully, and dmac
> > driver not present.
On 13/09/18 10:00, Geert Uytterhoeven wrote:
[...]
The main issue is that if of_dma_find_controller() fails, a DMA slave driver
cannot distinguish between dmac not yet probed successfully, and dmac
driver not present.
...which is in fact the exact same problem that the IOMMU code has -
might i
Hi Mark,
On Wed, Sep 12, 2018 at 5:51 PM Mark Brown wrote:
> On Tue, Sep 11, 2018 at 11:43:47AM +0200, Geert Uytterhoeven wrote:
> > So it seems the audio DMAC is deferred a second time, before the iommu
> > driver
> > probed.
>
> Shouldn't there be at least one more round of deferred probe trig
Hi Morimoto-san,
On Thu, Sep 13, 2018 at 7:48 AM Kuninori Morimoto
wrote:
> > > -
> > > commit ac6bbf0cdf4206c517ac9789814c23e372ebce4d
> > > Author: Rob Herring
> > > Date: Mon Jul 9 09:41:52 2018 -0600
> > >
> > > iommu: Remove IOMMU_OF
On Tue, Sep 11, 2018 at 09:40:14AM -0400, Jerome Glisse wrote:
> Date: Tue, 11 Sep 2018 09:40:14 -0400
> From: Jerome Glisse
> To: Kenneth Lee
> CC: Kenneth Lee , Alex Williamson
> , Herbert Xu ,
> k...@vger.kernel.org, Jonathan Corbet , Greg Kroah-Hartman
> , Zaibo Xu ,
> linux-...@vger.kern
> From: Christian König
> Sent: Friday, September 7, 2018 4:56 PM
>
> 5. It would be nice to have to allocate multiple PASIDs for the same
> process address space.
> E.g. some teams at AMD want to use a separate GPU address space
> for their userspace client library. I'm still trying to a
> From: Jacob Pan [mailto:jacob.jun@linux.intel.com]
> Sent: Saturday, September 8, 2018 5:25 AM
> > > iommu-sva expects everywhere that the device has an iommu_domain,
> > > it's the first thing we check on entry. Bypassing all of this would
> > > call idr_alloc() directly, and wouldn't have a
32 matches
Mail list logo
