Hi,
On Tue, Feb 18, 2020 at 10:14 AM Andre Przywara wrote:
>
> On Tue, 18 Feb 2020 11:13:10 -0600
> Rob Herring wrote:
>
> Hi,
>
> > Calxeda has been defunct for 6 years now. Use of Calxeda servers carried
> > on for some time afterwards primarily as distro builders for 32-bit ARM.
> > AFAIK,
Hi Krishna,
On Wed, Oct 31, 2018 at 04:43:45PM -0700, Krishna Reddy wrote:
> NVIDIA's Xavier (Tegra194) SOC has three ARM SMMU(MMU-500) instances.
> Two of the SMMU instances are used to interleave IOVA accesses across them.
> The IOVA accesses from HW devices are interleaved across these two
On Fri, Aug 24, 2018 at 04:06:33PM +0100, Marc Zyngier wrote:
> This small series addresses a couple of runtime PM issues I've spotted
> while running 4.18 on a Chromebook Plus (kevin, rk3399) platform, and
> specifically doing kexec.
>
> In order to avoid making a complete mess of the IOMMU
be
disabled at boot time with "iommu.passthrough=off" or "iommu=nopt".
Also corrected iommu=pt documentation for IA-64, since it has no code that
parses iommu= at all.
Signed-off-by: Olof Johansson
---
Chances since v1:
- Added analogous behavior for Intel/AMD
- A
On Fri, Jul 20, 2018 at 5:16 AM, Joerg Roedel wrote:
> Hi Olof,
>
> On Wed, Jul 11, 2018 at 01:59:35PM -0700, Olof Johansson wrote:
>> +config IOMMU_DEFAULT_PASSTHROUGH
>> + bool "IOMMU passthrough by default"
>> + depends on IOMMU_API
>>
While we could print it at setup time, this is an easier way to match
each device to their default IOMMU allocation type.
Signed-off-by: Olof Johansson
---
drivers/iommu/iommu.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers
This allows the default behavior to be controlled by a kernel config
option instead of changing the commandline for the kernel to include
"iommu.passthrough=on" on machines where this is desired.
Signed-off-by: Olof Johansson
---
drivers/iommu/Kconfig | 10 ++
drivers/iommu/io
On Wed, Jan 28, 2015 at 01:25:35AM +0100, Heiko Stübner wrote:
Hi Arnd, Olof,
Am Freitag, 23. Januar 2015, 16:21:49 schrieb Laurent Pinchart:
Commit 4bb25789ed28228a (arm: dma-mapping: plumb our iommu mapping ops
into arch_setup_dma_ops) moved the setting of the DMA operations from
On Mon, Dec 1, 2014 at 8:57 AM, Will Deacon will.dea...@arm.com wrote:
Hello again,
This is version 6 of the patches previously posted here:
RFCv1:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/283023.html
RFCv2:
Hi,
On Mon, Oct 13, 2014 at 3:33 AM, Thierry Reding
thierry.red...@gmail.com wrote:
[...]
diff --git a/drivers/memory/tegra/tegra-mc.c b/drivers/memory/tegra/tegra-mc.c
new file mode 100644
index ..0f0c8be096d0
--- /dev/null
+++ b/drivers/memory/tegra/tegra-mc.c
@@ -0,0 +1,1061
Hi,
Oh, a few more comments:
On Mon, Oct 13, 2014 at 3:33 AM, Thierry Reding
thierry.red...@gmail.com wrote:
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index c32d31981be3..1c932e7e7b8d 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -12,4 +12,5 @@
On Thu, Jul 31, 2014 at 5:04 AM, Joerg Roedel j...@8bytes.org wrote:
On Thu, Jul 31, 2014 at 12:43:03PM +0200, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
This commit introduces a generic device tree binding for IOMMU devices.
Only a very minimal subset is described here,
On Thu, Jul 31, 2014 at 9:36 AM, Joerg Roedel j...@8bytes.org wrote:
On Thu, Jul 31, 2014 at 08:38:47AM -0700, Olof Johansson wrote:
Applied, thanks everyone.
Really?
Gee, thanks for giving people a chance to reply with acks. It's
considered polite to do so when there has been
Hi,
On Wed, Jul 30, 2014 at 8:26 AM, Mark Rutland mark.rutl...@arm.com wrote:
Hi Thierry,
This looks sane to me.
I just have a few questions below which are hopefully simple/stupid.
On Fri, Jul 04, 2014 at 04:29:17PM +0100, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
On Wed, Jul 30, 2014 at 6:33 AM, Joerg Roedel j...@8bytes.org wrote:
On Wed, Jul 30, 2014 at 03:23:50PM +0200, Thierry Reding wrote:
I think there weren't any comments left for me to address and I've
mostly been waiting for Joerg to pick it up.
Joerg, can you take this through the iommu tree
On Mon, Feb 10, 2014 at 10:21 PM, Kukjin Kim kgene@gmail.com wrote:
Just adding KyongHo Cho.
If he can fixup for this time, it would be best solution because he knows
well than others, I think.
It's not so much a matter of fixup for this time, it's a about
having ownership of the driver,
-by: Olof Johansson o...@lixom.net
---
drivers/iommu/Kconfig| 21 -
drivers/iommu/Makefile |1 -
drivers/iommu/exynos-iommu.c | 1035 --
3 files changed, 1057 deletions(-)
delete mode 100644 drivers/iommu/exynos-iommu.c
diff --git
Hi,
2013/9/29 Cho KyongHo pullip@samsung.com:
Ah, I remember that this is merged.
I agreed to merge this patch because iommu driver need to be completely
changed.
Whenever I change exynos-iommu driver, synchronizing samsung-next and
iommu-next
branches is a big challenge.
Thus I
specifically for variables of type phys_addr_t.
Signed-off-by: Thierry Reding tred...@nvidia.com
Acked-by: Olof Johansson o...@lixom.net
Olof has been sending patches to fix up similar issues, but I couldn't
find one that fixes these warnings. If Olof sent a patch for this and I
missed
19 matches
Mail list logo
