On Fri, Aug 18, 2017 at 11:19:00AM +0800, Leizhen (ThunderTown) wrote:
>
>
> On 2017/8/17 22:36, Will Deacon wrote:
> > Thunder, Nate, Robin,
> >
> > On Mon, Jun 26, 2017 at 09:38:45PM +0800, Zhen Lei wrote:
> >> I described the optimization more detail in patch 1 and 2, and patch 3-5
> >> are
Hi Ashok,
On Tue, Aug 15, 2017 at 07:59:29AM -0700, Raj, Ashok wrote:
> I haven't received any update to this patchset..
>
> Could you help get this merged through your tree? we have tested this
> series internally.
The mm-notifier patch needs acks or rb from mm-developers before I can
merge th
On Thu, Aug 17, 2017 at 05:56:23PM +0100, Robin Murphy wrote:
> On 17/08/17 16:41, Joerg Roedel wrote:
> > Okay, so just to check I got it right: Drivers do the above to check
> > whether a device is managed by an IOMMU, and that crashes now because
> > the 'group == NULL' check was removed?
>
> I
On Thu, Aug 10, 2017 at 12:29:11AM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Add a struct iommu_device to each tegra-smmu and register it
> with the iommu-core. Also link devices added to the driver
> to their respective hardware iommus.
>
> Signed-off-by: Joerg Roedel
> ---
> driver
On Thu, Aug 10, 2017 at 12:29:12AM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Add a struct iommu_device to each tegra-gart and register it
> with the iommu-core. Also link devices added to the driver
> to their respective hardware iommus.
>
> Signed-off-by: Joerg Roedel
> ---
> driver
tree: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git x86/amd
head: 20b46dff13bd1d250dc968b318f0fac3c996b3fa
commit: 3ac3e5ee5ed56b07448f295902e44916eb6979fc [6/12] iommu/amd: Copy old
trans table from old kernel
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian
tree: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git x86/amd
head: 20b46dff13bd1d250dc968b318f0fac3c996b3fa
commit: 3ac3e5ee5ed56b07448f295902e44916eb6979fc [6/12] iommu/amd: Copy old
trans table from old kernel
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian
Hi Joerg,
On Thu, Aug 17, 2017 at 11:20:54PM +0200, Joerg Roedel wrote:
> On Thu, Aug 17, 2017 at 06:17:05PM +0100, Will Deacon wrote:
> > On Thu, Aug 17, 2017 at 06:50:40PM +0200, Joerg Roedel wrote:
> > > Problem currently is how to get this information from
> > > 'struct iommu_device' to 'struc
Hi Joerg,
It's been a quiet cycle on the SMMU front, but please pull these three
patches for 4.14. They're all in relation to power management and device
shutdown, which allows us to handle suspend/resume and kexec operations
gracefully.
Cheers,
Will
--->8
The following changes since commit aa
[+cc Robin]
This series looks fine to me as far as PCI is concerned, and I'd be
happy to take it via my tree given an ack from David for this IOMMU
piece. Alternatively, you can add my
Acked-by: Bjorn Helgaas
to the other patches if you want to take it via another tree.
Robin raised a questio
On 18/08/17 17:04, Bjorn Helgaas wrote:
> [+cc Robin]
>
> This series looks fine to me as far as PCI is concerned, and I'd be
> happy to take it via my tree given an ack from David for this IOMMU
> piece. Alternatively, you can add my
>
> Acked-by: Bjorn Helgaas
>
> to the other patches if you
CMD_SYNC already has a bit of special treatment here and there, but as
we're about to extend it with more functionality for completing outside
the CMDQ lock, things are going to get rather messy if we keep trying to
cram everything into a single generic command interface. Instead, let's
break out t
Hi all,
Waiting for the command queue to drain for CMD_SYNC completion is likely
a contention hotspot on high-core-count systems. If the SMMU is coherent
and supports MSIs, though, we can use this cool feature (as suggested by
the architecture, no less) to make syncs effectively non-blocking for
a
As an IRQ, the CMD_SYNC interrupt is not particularly useful, not least
because we often need to wait for sync completion within someone else's
IRQ handler anyway. However, when MSIs and coherent accesses are
supported, we can have a lot more fun by not using it as an interrupt at
all. Following th
The cmdq-sync interrupt is never going to be particularly useful, since
for stage 1 DMA at least we'll often need to wait for sync completion
within someone else's IRQ handler, thus have to implement polling
anyway. Beyond that, the overhead of taking an interrupt, then still
having to grovel aroun
From: Joerg Roedel
The variable amd_iommu_pre_enabled is used in non-init
code-paths, so remove the __initdata annotation.
Fixes: 3ac3e5ee5ed56 ('iommu/amd: Copy old trans table from old kernel')
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu_init.c | 2 +-
1 file changed, 1 insertion
From: Joerg Roedel
This was reported by the kbuild bot. The condition in which
entry would be used uninitialized can not happen, because
when there is no iommu this function would never be called.
But its no fast-path, so fix the warning anyway.
Reported-by: kbuild test robot
Signed-off-by: Joer
On Fri, Aug 18, 2017 at 04:19:48PM +0100, Will Deacon wrote:
> The following changes since commit aae4e7a8bc44722fe70d58920a36916b1043195e:
>
> Linux 4.13-rc4 (2017-08-06 18:44:49 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.
On 08/19/17 at 12:40am, Joerg Roedel wrote:
> From: Joerg Roedel
>
> This was reported by the kbuild bot. The condition in which
> entry would be used uninitialized can not happen, because
> when there is no iommu this function would never be called.
> But its no fast-path, so fix the warning any
19 matches
Mail list logo