Hi Joerg,
On 2020/3/2 23:08, Joerg Roedel wrote:
Hello Sai, Baolu,
On Sun, Feb 16, 2020 at 01:57:26PM -0800, Sai Praneeth Prakhya wrote:
Hence it will be helpful if there is some way to change the default
domain of a B:D.F dynamically. Since, linux iommu subsystem prefers to
deal at
From: Kai-Heng Feng
[ Upstream commit 3dfee47b215e49788cfc80e474820ea2e948c031 ]
Serious screen flickering when Stoney Ridge outputs to a 4K monitor.
Use identity-mapping and PCI ATS doesn't help this issue.
According to Alex Deucher, IOMMU isn't enabled on Windows, so let's do
the same here
From: Kai-Heng Feng
[ Upstream commit 3dfee47b215e49788cfc80e474820ea2e948c031 ]
Serious screen flickering when Stoney Ridge outputs to a 4K monitor.
Use identity-mapping and PCI ATS doesn't help this issue.
According to Alex Deucher, IOMMU isn't enabled on Windows, so let's do
the same here
Hi Robin,
On Fri, Feb 28, 2020 at 02:18:55PM +, Robin Murphy wrote:
> Since we ony support the TTB1 quirk for AArch64 contexts, and
> consequently only for 64-bit builds, the sign-extension aspect of the
> "are all bits above IAS consistent?" check should implicitly only apply
> to 64-bit
For ARCH=x86 (32 bit) when you set CONFIG_IOMMU_INTEL since c5a5dc4cbbf4
("iommu/vt-d: Don't switch off swiotlb if bounce page is used") there's
a dependency on CONFIG_SWIOTLB, which was not necessarily active before.
The init code for swiotlb in 'pci_swiotlb_detect_4gb()' compares
something
On Fri, Feb 28, 2020 at 06:25:36PM +0100, Jean-Philippe Brucker wrote:
> This solution isn't elegant nor foolproof, but is the best we can do at
> the moment and works with existing virtio-iommu implementations. It also
> enables an IOMMU for lightweight hypervisors that do not rely on
> firmware
On Mon, Mar 02, 2020 at 05:11:23PM +0100, Joerg Roedel wrote:
> On Mon, Mar 02, 2020 at 11:53:01AM +, Will Deacon wrote:
> > On Fri, Feb 28, 2020 at 02:18:55PM +, Robin Murphy wrote:
> > > Since we ony support the TTB1 quirk for AArch64 contexts, and
> > > consequently only for 64-bit
On Mon, Mar 02, 2020 at 11:53:01AM +, Will Deacon wrote:
> On Fri, Feb 28, 2020 at 02:18:55PM +, Robin Murphy wrote:
> > Since we ony support the TTB1 quirk for AArch64 contexts, and
> > consequently only for 64-bit builds, the sign-extension aspect of the
> > "are all bits above IAS
On Wed, Feb 26, 2020 at 12:30:06PM -0800, Yonghyun Hwang wrote:
> intel_iommu_iova_to_phys() has a bug when it translates an IOVA for a huge
> page onto its corresponding physical address. This commit fixes the bug by
> accomodating the level of page entry for the IOVA and adds IOVA's lower
>
On 24/02/2020 7:44 pm, Christoph Hellwig wrote:
Hi all,
this series provides support for remapping places uncached in-place in
the generic dma-direct code, and moves openrisc over from its own
in-place remapping scheme. The arm64 folks also had interest in such
a scheme to avoid problems with
On Thu, Feb 27, 2020 at 11:57:52AM +, Russell King wrote:
> On the LX2160A, there are lots (about 160) of IOMMU messages produced
> during boot; this is excessive. Reduce the severity of these messages
> to debug level.
No, these messages are a very useful tool when it comes to debugging
Hi Maxime,
On Thu, Feb 20, 2020 at 07:15:14PM +0100, Maxime Ripard wrote:
> +struct sun50i_iommu_domain {
> + struct iommu_domain domain;
> +
> + /* Number of devices attached to the domain */
> + refcount_t refcnt;
> +
> + /* Lock to modify the Directory Table */
> +
Hi Robin,
> -Original Message-
> From: Robin Murphy
> Sent: Friday, February 28, 2020 8:32 PM
>
> [ +Laurentiu ]
>
> Hi Russell,
>
> Thanks for sharing a log, now I properly understand what's up... further
> comments at the end (for context).
>
> On 28/02/2020 10:06 am, Russell King
Hello Sai, Baolu,
On Sun, Feb 16, 2020 at 01:57:26PM -0800, Sai Praneeth Prakhya wrote:
> Hence it will be helpful if there is some way to change the default
> domain of a B:D.F dynamically. Since, linux iommu subsystem prefers to
> deal at iommu_group level instead of B:D.F level, it might be
On Fri, Feb 28, 2020 at 02:18:55PM +, Robin Murphy wrote:
> Since we ony support the TTB1 quirk for AArch64 contexts, and
> consequently only for 64-bit builds, the sign-extension aspect of the
> "are all bits above IAS consistent?" check should implicitly only apply
> to 64-bit IOVAs. Change
Add a new platform data member in order to select which IVRP_PADDR
format is used by an SoC.
Signed-off-by: Fabien Parent
---
v2: new patch
---
drivers/iommu/mtk_iommu.c | 3 ++-
drivers/iommu/mtk_iommu.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git
Add support for the IOMMU on MT8167
Signed-off-by: Fabien Parent
---
V2:
* removed if based on m4u_plat, and using instead the new
has_legacy_ivrp_paddr member that was introduced in patch 2.
---
drivers/iommu/mtk_iommu.c | 9 +
drivers/iommu/mtk_iommu.h | 1 +
2 files
This commit adds IOMMU binding documentation for the MT8167 SoC.
Signed-off-by: Fabien Parent
Acked-by: Rob Herring
---
V2: no change
---
Documentation/devicetree/bindings/iommu/mediatek,iommu.txt | 1 +
1 file changed, 1 insertion(+)
diff --git
18 matches
Mail list logo
