On Tue, 2015-06-23 at 16:06 +0200, Joerg Roedel wrote:
On Tue, Jun 23, 2015 at 02:31:30PM +0100, David Woodhouse wrote:
However, it's still fairly gratuitous for all non-broken hardware, and
will tend to hide hardware and driver bugs during testing of new
hardware.
I'd much rather see
On Sat, 2015-06-13 at 08:47 +0200, Joerg Roedel wrote:
Hi,
as David Woodhouse pointed out, my fixes and cleanups for
the original patch-set turned out to be a complete rewrite.
So to have a cleaner history of the feature and to make
backporting easier, here is a rewrite of my changes based
On Tue, Jun 23, 2015 at 02:31:30PM +0100, David Woodhouse wrote:
However, it's still fairly gratuitous for all non-broken hardware, and
will tend to hide hardware and driver bugs during testing of new
hardware.
I'd much rather see this limited to a blacklist of known-broken
devices, an
Patch 'fix ARM_SMMU_FEAT_TRANS_OPS condition' changed the check
for ARM_SMMU_FEAT_TRANS_OPS to be based on presence of stage1 check,
but used (id ID0_ATOSNS) instead of !(id ID0_ATOSNS).
Fix it here.
Signed-off-by: Sricharan R sricha...@codeaurora.org
---
drivers/iommu/arm-smmu.c | 2 +-
1
IOMMU entry for io xapic of legacy PCH has bus of 0xf0. I'm not sure why
bus 0xf0 instead of legacy bus 0? Second question if I have two PCH in the
system what bus# should I use for non-legacy PCH w/o encountering source-id
verification failure?
Please help?
This issue has already been fixed here :
http://www.spinics.net/lists/arm-kernel/msg424824.html
Regards,
Baptiste
On Tue, Jun 23, 2015 at 2:07 PM, Sricharan R sricha...@codeaurora.org wrote:
Patch 'fix ARM_SMMU_FEAT_TRANS_OPS condition' changed the check
for ARM_SMMU_FEAT_TRANS_OPS to be based
Hi Linus,
The IOMMU changes have conflicts this time with IRQ related patches
coming from the tip tree. Some of the IRQ patches there also touch the
Intel and AMD interrupt remapping code in drivers/iommu, which conflicts
with the Intel VT-d kdump fixes.
I attached my resolution of the conflicts
On Tue, Jun 23, 2015 at 2:24 AM, Joerg Roedel j...@8bytes.org wrote:
I attached my resolution of the conflicts to this pull-request and
compiled and run-time tested my resolution on an Intel VT-d and an
AMD IOMMU machine.
Hmm. My resolution doesn't look the same at all, but that could easily
