Re: [RFC PATCH 00/11] Removing Calxeda platform support
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, those systems have been retired in favor of 32-bit VMs on 64-bit > > hosts. > > > > The other use of Calxeda Midway I'm aware of was testing 32-bit ARM KVM > > support as there are few or no other systems with enough RAM and LPAE. Now > > 32-bit KVM host support is getting removed[1]. > > > > While it's not much maintenance to support, I don't care to convert the > > Calxeda DT bindings to schema nor fix any resulting errors in the dts files > > (which already don't exactly match what's shipping in firmware). > > While every kernel maintainer seems always happy to take patches with a > negative diffstat, I wonder if this is really justification enough to remove > a perfectly working platform. I don't really know about any active users, but > experience tells that some platforms really are used for quite a long time, > even if they are somewhat obscure. N900 or Netwinder, anyone? One of the only ways we know to confirm whether there are active users or not, is to propose removing a platform. The good news is that if/when you do, and someone cares enough about it to want to keep it alive, they should also have access to hardware and can help out in maintaining it and keeping it in a working state. For some hardware platforms, at some point in time it no longer makes sense to keep the latest kernel available on them, especially if maintainers and others no longer have easy access to hardware and resources/time to keep it functional. It's really more about "If you care about this enough to keep it going, please speak up and help out". > So to not give the impression that actually *everyone* (from that small > subset of people actively reading the kernel list) is happy with that, I > think that having support for at least Midway would be useful. On the one > hand it's a decent LPAE platform (with memory actually exceeding 4GB), and on > the other hand it's something with capable I/O (SATA) and networking, so one > can actually stress test the system. Which is the reason I was using that for > KVM testing, but even with that probably going away now there remain still > some use cases, and be it for general ARM(32) testing. How many bugs have you found on this platform that you would not have on a more popular one? And, how many of those bugs only affected this platform, i.e. just adding onto the support burden without positive impact to the broader community? > I don't particularly care about the more optional parts like EDAC, cpuidle, > or cpufreq, but I wonder if keeping in at least the rather small SATA and > XGMAC drivers and basic platform support is feasible. At what point are you better off just running under QEMU/virtualization? > If YAML DT bindings are used as an excuse, I am more than happy to convert > those over. > > And if anyone has any particular gripes with some code, maybe there is a way > to fix that instead of removing it? I was always wondering if we could get > rid of the mach-highbank directory, for instance. I think most of it is > Highbank (Cortex-A9) related. Again, how do you fix it if nobody has signed up for maintaining and keeping it working? Doing blind changes that might or might not work is not a way to keep a platform supported. Just because code is removed, it doesn't mean it can't be reintroduced when someone comes along and wants to do that. Look at some of the recent additions of old OLPC hardware support, for example. But there's a difference between this and keeping the code around hoping that someone will care about it. It's not lost, and it's easy to bring back. -Olof ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 0/5] Add Tegra194 Dual ARM SMMU driver
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 SMMU > instances > and they need to be programmed identical. > > The existing ARM SMMU driver can't be used in its current form for > programming the > two SMMU instances identically. But, most of the code can be shared between > ARM SMMU > driver and Tegra194 SMMU driver. > Page fault handling and TLB sync operations need to know about specific > instance > of SMMU for correct fault handling and optimal TLB sync wait. Rest of the > code doesn't > need to know about number of SMMU instances. Based on this fact, The patch > series here > rearranges the arm-smmu.c code to allow sharing most of the ARM SMMU > programming/iommu_ops > code between ARM SMMU driver and Tegra194 SMMU driver and transparently > handles programming of two SMMU instances. Based on what I can see, it seems that you're trying to describe two pieces of hardware with only one device in the DT. That seems like an odd choice. Also, it seems like all three SMMUs share the same interrupt line? That's somewhat suboptimal IMHO, but harder to change. Why not instantiate both of them and create a reference between then such that the TLB and sync ops are done on both of them in the native driver? I.e. two arm_smmu structs and a pointer between then (i.e. add a "next shared smmu" pointer in the struct arm_smmu). As long as devices only references one of them, locking only that one should provide suitable protection as well. Seems like a simpler approach than adding a new layer to the driver, but maybe I am missing some complexity here? -Olof ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 0/4] iommu/rockchip: Runtime PM fixes
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 code, Heiko has > requested that all RK platforms would select CONFIG_PM, which > simplifies a lot of things. I've kept 32 and 64bit patches separate, > but feel free to squash them into on if that's more convenient. > > Note that even with these patches, kexec is still fairly broken on > rk3399, as the VOP is never turned off (see [1] for a fix). > > [1] https://www.spinics.net/lists/arm-kernel/msg670229.html > > * From v1: > - Collected RBs from Heiko > - Added two patches forcing CONFIG_PM on all Rockchip platforms at > Heiko's request, following the example set by Tegra platforms. Thanks, applied to our next/late branch which I plan to send in tomorrow. -Olof ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu: Add config option to set passthrough as default
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" or "iommu=pt" on machines where this is desired.
Likewise, for machines where this config option is enabled, it can 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
- Added iommu=nopt for x86 and updated docs
Documentation/admin-guide/kernel-parameters.txt | 3 ++-
arch/x86/kernel/pci-dma.c | 8
drivers/iommu/Kconfig | 11 +++
drivers/iommu/iommu.c | 4
4 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index c9dbdf1009f1..4c822aa50f13 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1744,7 +1744,8 @@
merge
nomerge
soft
- pt [x86, IA-64]
+ pt [x86]
+ nopt[x86]
nobypass[PPC/POWERNV]
Disable IOMMU bypass, using IOMMU for PCI devices.
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index ab5d9dd668d2..0acb135de7fb 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -40,8 +40,14 @@ int iommu_detected __read_mostly = 0;
* devices and allow every device to access to whole physical memory. This is
* useful if a user wants to use an IOMMU only for KVM device assignment to
* guests and not for driver dma translation.
+ * It is also possible to disable by default in kernel config, and enable with
+ * iommu=nopt at boot time.
*/
+#ifdef CONFIG_IOMMU_DEFAULT_PASSTHROUGH
+int iommu_pass_through __read_mostly = 1;
+#else
int iommu_pass_through __read_mostly;
+#endif
extern struct iommu_table_entry __iommu_table[], __iommu_table_end[];
@@ -135,6 +141,8 @@ static __init int iommu_setup(char *p)
#endif
if (!strncmp(p, "pt", 2))
iommu_pass_through = 1;
+ if (!strncmp(p, "nopt", 4))
+ iommu_pass_through = 0;
gart_parse_options(p);
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 568ae81b0e99..1813319c8342 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -70,6 +70,17 @@ config IOMMU_DEBUGFS
debug/iommu directory, and then populate a subdirectory with
entries as required.
+config IOMMU_DEFAULT_PASSTHROUGH
+ bool "IOMMU passthrough by default"
+ depends on IOMMU_API
+help
+ Enable passthrough by default, removing the need to pass in
+ iommu.passthrough=on or iommu=pt through command line. If this
+ is enabled, you can still disable with iommu.passthrough=off
+ or iommu=nopt depending on the architecture.
+
+ If unsure, say N here.
+
config IOMMU_IOVA
tristate
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index d227b864a109..6f8f59684def 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -36,7 +36,11 @@
static struct kset *iommu_group_kset;
static DEFINE_IDA(iommu_group_ida);
+#ifdef CONFIG_IOMMU_DEFAULT_PASSTHROUGH
+static unsigned int iommu_def_domain_type = IOMMU_DOMAIN_IDENTITY;
+#else
static unsigned int iommu_def_domain_type = IOMMU_DOMAIN_DMA;
+#endif
struct iommu_callback_data {
const struct iommu_ops *ops;
--
2.11.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/2] iommu: Add config option to set passthrough as default
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 >> +help >> + Enable passthrough by default (removing the need to pass in >> + iommu.passthrough=on through command line). If this is enabled, >> + you can still disable with iommu.passthrough=off >> + >> + If unsure, say N here. >> + > > The patch is a good start, but the description above indicates that it > affects all IOMMU driver, which it does not. Please make the Intel and > AMD IOMMU drivers also take this option into account. It looks like it should make the AMD driver should honor it, since it uses the generic infrastructure for domain types? But it also shares iommu_pass_through variable usage with Intel, so if I change it over there it'll be covered for sure. One unfortunate thing here is the divergence in command line options between arm64 and x86. I'll add a 'iommu=nopt' on x86 so it can be turned off at runtime if enabled in config, but it'd be nice to also have it adhere to the .passthrough options. That's a larger topic than just this specific patch though. Posting new patch shortly. -Olof ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 2/2] iommu: add sysfs attribyte for domain type
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/iommu/iommu.c
index ab8fc54467e0..53164107620c 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -298,11 +298,39 @@ static ssize_t iommu_group_show_resv_regions(struct
iommu_group *group,
return (str - buf);
}
+static ssize_t iommu_group_show_type(struct iommu_group *group,
+char *buf)
+{
+ char *type = "unknown\n";
+
+ if (group->default_domain) {
+ switch (group->default_domain->type) {
+ case IOMMU_DOMAIN_BLOCKED:
+ type = "blocked\n";
+ break;
+ case IOMMU_DOMAIN_IDENTITY:
+ type = "identity\n";
+ break;
+ case IOMMU_DOMAIN_UNMANAGED:
+ type = "unmanaged\n";
+ break;
+ case IOMMU_DOMAIN_DMA:
+ type = "DMA";
+ break;
+ }
+ }
+ strcpy(buf, type);
+
+ return strlen(type);
+}
+
static IOMMU_GROUP_ATTR(name, S_IRUGO, iommu_group_show_name, NULL);
static IOMMU_GROUP_ATTR(reserved_regions, 0444,
iommu_group_show_resv_regions, NULL);
+static IOMMU_GROUP_ATTR(type, 0444, iommu_group_show_type, NULL);
+
static void iommu_group_release(struct kobject *kobj)
{
struct iommu_group *group = to_iommu_group(kobj);
@@ -384,6 +412,10 @@ struct iommu_group *iommu_group_alloc(void)
if (ret)
return ERR_PTR(ret);
+ ret = iommu_group_create_file(group, &iommu_group_attr_type);
+ if (ret)
+ return ERR_PTR(ret);
+
pr_debug("Allocated group %d\n", group->id);
return group;
--
2.11.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 1/2] iommu: Add config option to set passthrough as default
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/iommu.c | 4
2 files changed, 14 insertions(+)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 689ffe538370..a9bb1a5b5e43 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -60,6 +60,16 @@ config IOMMU_IO_PGTABLE_ARMV7S_SELFTEST
endmenu
+config IOMMU_DEFAULT_PASSTHROUGH
+ bool "IOMMU passthrough by default"
+ depends on IOMMU_API
+help
+ Enable passthrough by default (removing the need to pass in
+ iommu.passthrough=on through command line). If this is enabled,
+ you can still disable with iommu.passthrough=off
+
+ If unsure, say N here.
+
config IOMMU_IOVA
tristate
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 63b37563db7e..ab8fc54467e0 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -36,7 +36,11 @@
static struct kset *iommu_group_kset;
static DEFINE_IDA(iommu_group_ida);
+#ifdef CONFIG_IOMMU_DEFAULT_PASSTHROUGH
+static unsigned int iommu_def_domain_type = IOMMU_DOMAIN_IDENTITY;
+#else
static unsigned int iommu_def_domain_type = IOMMU_DOMAIN_DMA;
+#endif
struct iommu_callback_data {
const struct iommu_ops *ops;
--
2.11.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH URGENT] arm: dma-mapping: Set DMA IOMMU ops in arm_iommu_attach_device()
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
> > arm_iommu_attach_device() to arch_setup_dma_ops() where the DMA
> > operations to be used are selected based on whether the device is
> > connected to an IOMMU. However, the IOMMU detection scheme requires the
> > IOMMU driver to be ported to the new IOMMU of_xlate API. As no driver
> > has been ported yet, this effectively breaks all IOMMU ARM users that
> > depend on the IOMMU being handled transparently by the DMA mapping API.
> >
> > Fix this by restoring the setting of DMA IOMMU ops in
> > arm_iommu_attach_device() and splitting the rest of the function into a
> > new internal __arm_iommu_attach_device() function, called by
> > arch_setup_dma_ops().
> >
> > Signed-off-by: Laurent Pinchart
>
> in the original submission a...@kernel.org was not included, but it looks
> like
> the patch should go through arm-soc.
>
> We have two tags
> Acked-by: Will Deacon
> Tested-by: Heiko Stuebner
>
> Can you find the original patch somehow or should it be resend to include
> a...@kernel.org ?
The patch was posted on a list that I am subscribed to, so it popped up in
the same thread this time. I've applied it to fixes for 3.19.
Thanks,
-Olof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v6 0/8] Introduce automatic DMA configuration for IOMMU masters
On Mon, Dec 1, 2014 at 8:57 AM, Will Deacon 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: > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/283752.html > RFCv3: > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/287031.html > RFCv4: > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/302711.html > v5: > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/307213.html > > The only change since v5 is the addition of acks from various maintainers. > > Now that the ARM bits have rmk's ack and the IOMMU bits have joro's ack, > I think this is good for merging via the arm-soc tree. > > Please let me know if a pull request would be preferable. Hi, Yes, please collect the acks from the discussion in the last day or so and send a pull request (and include Robin's patch, obviously). -Olof ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 05/12] memory: Add NVIDIA Tegra memory controller support
Hi, Oh, a few more comments: On Mon, Oct 13, 2014 at 3:33 AM, Thierry Reding 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 @@ obj-$(CONFIG_FSL_CORENET_CF) += fsl-corenet-cf.o > obj-$(CONFIG_FSL_IFC) += fsl_ifc.o > obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o > obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o > -obj-$(CONFIG_TEGRA30_MC) += tegra30-mc.o > + > +obj-$(CONFIG_ARCH_TEGRA) += tegra/ > diff --git a/drivers/memory/tegra/Makefile b/drivers/memory/tegra/Makefile > new file mode 100644 > index ..51b9e8fcde1b > --- /dev/null > +++ b/drivers/memory/tegra/Makefile > @@ -0,0 +1,5 @@ > +obj-y = tegra-mc.o > +obj-$(CONFIG_ARCH_TEGRA_3x_SOC)+= tegra30-mc.o > +obj-$(CONFIG_ARCH_TEGRA_114_SOC) += tegra114-mc.o > +obj-$(CONFIG_ARCH_TEGRA_124_SOC) += tegra124-mc.o > +obj-$(CONFIG_ARCH_TEGRA_132_SOC) += tegra124-mc.o You'll need a Kconfig and not just a makefile -- there are definitely dependencies on this driver (IOMMU in particular). Also, the problem of having a global enable bit that is only under control of TrustZone FW is a big problem -- if the bit is not set, the driver will not work (and the machine will crash). I think you'll need to come up with a way to detect that in the driver. I don't have a good idea of how it can be done though. -Olof ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 05/12] memory: Add NVIDIA Tegra memory controller support
Hi,
On Mon, Oct 13, 2014 at 3:33 AM, Thierry Reding
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 @@
> +/*
> + * Copyright (C) 2014 NVIDIA CORPORATION. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
You need a linux/mm.h in here (on 64-bit).
> +#include
> +#include
> +#include
> +#include
[...]
> diff --git a/drivers/memory/tegra/tegra124-mc.c
> b/drivers/memory/tegra/tegra124-mc.c
> new file mode 100644
> index ..db31c96fc288
> --- /dev/null
> +++ b/drivers/memory/tegra/tegra124-mc.c
[...]
> @@ -0,0 +1,1028 @@
> +/*
> + * Copyright (C) 2014 NVIDIA CORPORATION. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +
> +#include
> +
> +#include
> +
> +#include "tegra-mc.h"
> +
> +static const struct tegra_mc_client tegra124_mc_clients[] = {
> + {
> + .id = 0x00,
> + .name = "ptcr",
> + .swgroup = TEGRA_SWGROUP_PTC,
> + }, {
> + .id = 0x01,
> + .name = "display0a",
> + .swgroup = TEGRA_SWGROUP_DC,
> + .smmu = {
> + .reg = 0x228,
> + .bit = 1,
> + },
> + .latency = {
> + .reg = 0x2e8,
> + .shift = 0,
> + .mask = 0xff,
> + .def = 0xc2,
> + },
> + }, {
These are very verbose tables. Having a macro for the initializers
could help density a lot.
> +#ifdef CONFIG_ARCH_TEGRA_132_SOC
> +static void tegra132_flush_dcache(struct page *page, unsigned long offset,
> + size_t size)
> +{
> + void *virt = page_address(page) + offset;
> +
> + __flush_dcache_area(virt, size);
> +}
> +
> +static const struct tegra_smmu_ops tegra132_smmu_ops = {
> + .flush_dcache = tegra132_flush_dcache,
> +};
> +
> +static const struct tegra_smmu_soc tegra132_smmu_soc = {
> + .groups = tegra124_smmu_groups,
> + .num_groups = ARRAY_SIZE(tegra124_smmu_groups),
> + .clients = tegra124_mc_clients,
> + .num_clients = ARRAY_SIZE(tegra124_mc_clients),
> + .swgroups = tegra124_swgroups,
> + .num_swgroups = ARRAY_SIZE(tegra124_swgroups),
> + .supports_round_robin_arbitration = true,
> + .supports_request_limit = true,
> + .num_address_bits = 34,
> + .num_asids = 128,
> + .ops = &tegra132_smmu_ops,
> +};
> +
> +const struct tegra_mc_soc tegra132_mc_soc = {
> + .clients = tegra124_mc_clients,
> + .num_clients = ARRAY_SIZE(tegra124_mc_clients),
> + .atom_size = 32,
> + .smmu = &tegra132_smmu_soc,
> +};
> +#endif /* CONFIG_ARCH_TEGRA_132_SOC */
This won't compile -- several of the tegra132_smmu_soc members are no
longer valid. In particular:
groups
num_groups
supports_round_robin_arbitration
supports_request_limit
-Olof
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings
On Thu, Jul 31, 2014 at 9:36 AM, Joerg Roedel 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 outstanding questions. > > Its not pushed yet, I can still make changes. Do you have any objections > or an Ack? No outstanding objections. We have some things to amend with later but that's perfectly fine: Reviewed-by: Olof Johansson -Olof ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5] devicetree: Add generic IOMMU device tree bindings
On Thu, Jul 31, 2014 at 5:04 AM, Joerg Roedel wrote: > On Thu, Jul 31, 2014 at 12:43:03PM +0200, Thierry Reding wrote: >> From: Thierry Reding >> >> This commit introduces a generic device tree binding for IOMMU devices. >> Only a very minimal subset is described here, but it is enough to cover >> the requirements of both the Exynos System MMU and Tegra SMMU as >> discussed here: >> >> https://lkml.org/lkml/2014/4/27/346 >> >> Acked-by: Will Deacon >> Reviewed-by: Arnd Bergmann >> Acked-by: Rob Herring >> Signed-off-by: Thierry Reding > > 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 outstanding questions. -Olof ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4] devicetree: Add generic IOMMU device tree bindings
On Wed, Jul 30, 2014 at 6:33 AM, Joerg Roedel 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 for 3.17? Will acked >> this, but perhaps you were waiting for an ACK from the device tree >> bindings maintainers? >> >> Will, perhaps you can get Pawel or Mark to look at this? >> >> Arnd, I'm sure if we had your Acked-by that would go a long way too. > > Yes, as Arnd requested this generic binding it would be good to have his > Acked-by before proceeding. Arnd? Arnd is on vacation now, unfortunately. I've read up on the history and the current proposal from Thierry looks sane to me. As discussed, there might be a need for some common helpers to walk the tree and figure out things. There's also the possibility that the IOMMU at init time actually modifies and configures the stream IDs for the clients, but that again is an implementation detail and not something that affects the binding per se. I'm not giving my Ack now since I want to make sure there are no disagreements on my separate reply from a minute ago, but I expect you'll have it once we've had that round trip of comments. :) -Olof ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4] devicetree: Add generic IOMMU device tree bindings
Hi, On Wed, Jul 30, 2014 at 8:26 AM, Mark Rutland 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 >> >> This commit introduces a generic device tree binding for IOMMU devices. >> Only a very minimal subset is described here, but it is enough to cover >> the requirements of both the Exynos System MMU and Tegra SMMU as >> discussed here: >> >> https://lkml.org/lkml/2014/4/27/346 >> >> Signed-off-by: Thierry Reding >> --- >> Changes in v4: >> - clarify that disabling an IOMMU DT node may not disable translation >> - be more explicit that examples are only examples >> - add multi-ID master example >> >> Changes in v3: >> - use #iommu-cells instead of #address-cells/#size-cells >> - drop optional iommu-names property >> >> Changes in v2: >> - add notes about "dma-ranges" property (drop note from commit message) >> - document priorities of "iommus" property vs. "dma-ranges" property >> - drop #iommu-cells in favour of #address-cells and #size-cells >> - remove multiple-master device example >> >> Documentation/devicetree/bindings/iommu/iommu.txt | 172 >> ++ >> 1 file changed, 172 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/iommu/iommu.txt >> >> diff --git a/Documentation/devicetree/bindings/iommu/iommu.txt >> b/Documentation/devicetree/bindings/iommu/iommu.txt >> new file mode 100644 >> index ..464a81eaaf61 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/iommu/iommu.txt >> @@ -0,0 +1,172 @@ >> +This document describes the generic device tree binding for IOMMUs and their >> +master(s). >> + >> + >> +IOMMU device node: >> +== >> + >> +An IOMMU can provide the following services: >> + >> +* Remap address space to allow devices to access physical memory ranges that >> + they otherwise wouldn't be capable of accessing. >> + >> + Example: 32-bit DMA to 64-bit physical addresses >> + >> +* Implement scatter-gather at page level granularity so that the device does >> + not have to. >> + >> +* Provide system protection against "rogue" DMA by forcing all accesses to >> go >> + through the IOMMU and faulting when encountering accesses to unmapped >> + address regions. >> + >> +* Provide address space isolation between multiple contexts. >> + >> + Example: Virtualization >> + >> +Device nodes compatible with this binding represent hardware with some of >> the >> +above capabilities. >> + >> +IOMMUs can be single-master or multiple-master. Single-master IOMMU devices >> +typically have a fixed association to the master device, whereas multiple- >> +master IOMMU devices can translate accesses from more than one master. >> + >> +The device tree node of the IOMMU device's parent bus must contain a valid >> +"dma-ranges" property that describes how the physical address space of the >> +IOMMU maps to memory. An empty "dma-ranges" property means that there is a >> +1:1 mapping from IOMMU to memory. >> + >> +Required properties: >> + >> +- #iommu-cells: The number of cells in an IOMMU specifier needed to encode >> an >> + address. >> + >> +The meaning of the IOMMU specifier is defined by the device tree binding of >> +the specific IOMMU. Below are a few examples of typical use-cases: >> + >> +- #iommu-cells = <0>: Single master IOMMU devices are not configurable and >> + therefore no additional information needs to be encoded in the specifier. >> + This may also apply to multiple master IOMMU devices that do not allow the >> + association of masters to be configured. Note that an IOMMU can by design >> + be multi-master yet only expose a single master in a given configuration. >> + In such cases the number of cells will usually be 1 as in the next case. >> +- #iommu-cells = <1>: Multiple master IOMMU devices may need to be >> configured >> + in order to enable translation for a given master. In such cases the >> single >> + address cell corresponds to the master device's ID. In some cases more >> than >> + one cell can be required to represent a single master ID. >> +- #iommu-cells = <4>: Some IOMMU devices allow the DMA window for masters to >> + be configured. The first cell of the address in this may contain the >> master >> + device's ID for example, while the second cell could contain the start of >> + the DMA window for the given device. The length of the DMA window is given >> + by the third and fourth cells. >> + >> +Note that these are merely examples and real-world use-cases may use >> different >> +definitions to represent their individual needs. Always refer to the >> specific >> +IOMMU binding for the exact meaning of the cells that make up the specifier. >> + >> + >> +IOMMU master node: >> +== >> + >> +Devices that access memory through an IOMMU are called masters. A device can >> +have multiple
Re: [PATCH] iommu/exynos: Remove driver
On Mon, Feb 10, 2014 at 10:21 PM, Kukjin Kim 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, making sure it works (and keeps working if there is related development). The posted patches have not been followed through on and the result is a broken driver. :( I definitely appreciate his expertise, and we should make sure that he gets to review the code, but if someone else is able to spend time on reworking the driver (or rewriting a newer one) and maintaining it longer-term, then we should not stop them from doing so. And there is no reason to keep broken stale code in the kernel meanwhile. -Olof ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] iommu/exynos: Remove driver
The driver has been unbuildable due to unfulfilled dependencies since 3.11, and even if enabled it won't build due to build breakage. Emails about status on this have gone unanswered, and fixes seem to have been abandoned. It's obvious that nobody cares about it, so let's remove it. Signed-off-by: Olof Johansson --- 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 a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index 79bbc21..b893367 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -176,27 +176,6 @@ config TEGRA_IOMMU_SMMU space through the SMMU (System Memory Management Unit) hardware included on Tegra SoCs. -config EXYNOS_IOMMU - bool "Exynos IOMMU Support" - depends on ARCH_EXYNOS && EXYNOS_DEV_SYSMMU - select IOMMU_API - help - Support for the IOMMU(System MMU) of Samsung Exynos application - processor family. This enables H/W multimedia accellerators to see - non-linear physical memory chunks as a linear memory in their - address spaces - - If unsure, say N here. - -config EXYNOS_IOMMU_DEBUG - bool "Debugging log for Exynos IOMMU" - depends on EXYNOS_IOMMU - help - Select this to see the detailed log message that shows what - happens in the IOMMU driver - - Say N unless you need kernel log message for IOMMU debugging - config SHMOBILE_IPMMU bool diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile index 5d58bf1..de6c909 100644 --- a/drivers/iommu/Makefile +++ b/drivers/iommu/Makefile @@ -14,7 +14,6 @@ obj-$(CONFIG_OMAP_IOVMM) += omap-iovmm.o obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o obj-$(CONFIG_TEGRA_IOMMU_GART) += tegra-gart.o obj-$(CONFIG_TEGRA_IOMMU_SMMU) += tegra-smmu.o -obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o obj-$(CONFIG_SHMOBILE_IOMMU) += shmobile-iommu.o obj-$(CONFIG_SHMOBILE_IPMMU) += shmobile-ipmmu.o obj-$(CONFIG_FSL_PAMU) += fsl_pamu.o fsl_pamu_domain.o diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c deleted file mode 100644 index 0740189..000 --- a/drivers/iommu/exynos-iommu.c +++ /dev/null @@ -1,1035 +0,0 @@ -/* linux/drivers/iommu/exynos_iommu.c - * - * Copyright (c) 2011 Samsung Electronics Co., Ltd. - * http://www.samsung.com - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - */ - -#ifdef CONFIG_EXYNOS_IOMMU_DEBUG -#define DEBUG -#endif - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -#include -#include - -#include - -/* We does not consider super section mapping (16MB) */ -#define SECT_ORDER 20 -#define LPAGE_ORDER 16 -#define SPAGE_ORDER 12 - -#define SECT_SIZE (1 << SECT_ORDER) -#define LPAGE_SIZE (1 << LPAGE_ORDER) -#define SPAGE_SIZE (1 << SPAGE_ORDER) - -#define SECT_MASK (~(SECT_SIZE - 1)) -#define LPAGE_MASK (~(LPAGE_SIZE - 1)) -#define SPAGE_MASK (~(SPAGE_SIZE - 1)) - -#define lv1ent_fault(sent) (((*(sent) & 3) == 0) || ((*(sent) & 3) == 3)) -#define lv1ent_page(sent) ((*(sent) & 3) == 1) -#define lv1ent_section(sent) ((*(sent) & 3) == 2) - -#define lv2ent_fault(pent) ((*(pent) & 3) == 0) -#define lv2ent_small(pent) ((*(pent) & 2) == 2) -#define lv2ent_large(pent) ((*(pent) & 3) == 1) - -#define section_phys(sent) (*(sent) & SECT_MASK) -#define section_offs(iova) ((iova) & 0xF) -#define lpage_phys(pent) (*(pent) & LPAGE_MASK) -#define lpage_offs(iova) ((iova) & 0x) -#define spage_phys(pent) (*(pent) & SPAGE_MASK) -#define spage_offs(iova) ((iova) & 0xFFF) - -#define lv1ent_offset(iova) ((iova) >> SECT_ORDER) -#define lv2ent_offset(iova) (((iova) & 0xFF000) >> SPAGE_ORDER) - -#define NUM_LV1ENTRIES 4096 -#define NUM_LV2ENTRIES 256 - -#define LV2TABLE_SIZE (NUM_LV2ENTRIES * sizeof(long)) - -#define SPAGES_PER_LPAGE (LPAGE_SIZE / SPAGE_SIZE) - -#define lv2table_base(sent) (*(sent) & 0xFC00) - -#define mk_lv1ent_sect(pa) ((pa) | 2) -#define mk_lv1ent_page(pa) ((pa) | 1) -#define mk_lv2ent_lpage(pa) ((pa) | 1) -#define mk_lv2ent_spage(pa) ((pa) | 2) - -#define CTRL_ENABLE0x5 -#define CTRL_BLOCK 0x7 -#define CTRL_DISABLE 0x0 - -#define REG_MMU_CTRL 0x000 -#define REG_MMU_CFG0x004 -#define REG_MMU_STATUS 0x008 -#define REG_MMU_FLUSH 0x00C -#define REG_MMU_FLUSH_ENTRY0x010 -#define REG_PT_BASE_ADDR 0x014 -#define REG_INT_STATUS 0x018 -#define REG_INT_CLEAR 0x01C - -#define REG_PAGE_FAULT_ADDR
Re: [PATCH v6 07/12] ARM: EXYNOS: remove system mmu initialization from exynos tree
Hi, 2013/9/29 Cho KyongHo : > 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 decided to remove dependencies to samsung-next branch. > But I didn't know that the rest of the new driver is not merged soon. :( > I am sorry about that. > > new patch (v10) will be posted soon. Will the v10 patch set be incremental based on v6? How have you tested v10 on mainline? Thanks, -Olof ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/tegra: Print phys_addr_t using %pa
On Tue, Sep 17, 2013 at 1:19 AM, Thierry Reding wrote: > When enabling LPAE on ARM, phys_addr_t becomes 64 bits wide and printing > a variable of that type using a simple %x format specifier causes the > compiler to complain. Change the format specifier to %pa, which is used > specifically for variables of type phys_addr_t. > > Signed-off-by: Thierry Reding Acked-by: Olof Johansson > 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 it, please ignore. Nope, I hadn't seen these ones since I was only looking at multi_v7_defconfig at the time, and these are only enabled with tegra_defconfig at the moment. -Olof ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
