RE: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
Hi Arnd, Any comments? Please reply when you see the email since we want this eSDHC issue to be fixed soon. All the patches are Freescale-specific and is to fix the eSDHC driver. Could we let them merged first if you were talking about a new way of abstracting getting SoC version. Thanks :) Best regards, Yangbo Lu > -Original Message- > From: Scott Wood [mailto:o...@buserror.net] > Sent: Wednesday, May 11, 2016 11:26 AM > To: Arnd Bergmann; linux-arm-ker...@lists.infradead.org > Cc: Yangbo Lu; linuxppc-...@lists.ozlabs.org; Mark Rutland; > devicet...@vger.kernel.org; ulf.hans...@linaro.org; Russell King; Bhupesh > Sharma; net...@vger.kernel.org; Joerg Roedel; Kumar Gala; linux- > m...@vger.kernel.org; linux-ker...@vger.kernel.org; Yang-Leo Li; > iommu@lists.linux-foundation.org; Rob Herring; linux-...@vger.kernel.org; > Claudiu Manoil; Santosh Shilimkar; Xiaobo Xie; linux-...@vger.kernel.org; > Qiang Zhao > Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for T4240- > R1.0-R2.0 > > On Thu, 2016-05-05 at 13:10 +0200, Arnd Bergmann wrote: > > On Thursday 05 May 2016 09:41:32 Yangbo Lu wrote: > > > > -Original Message- > > > > From: Arnd Bergmann [mailto:a...@arndb.de] > > > > Sent: Thursday, May 05, 2016 4:32 PM > > > > To: linuxppc-...@lists.ozlabs.org > > > > Cc: Yangbo Lu; linux-...@vger.kernel.org; > > > > devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > > > > linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; > > > > linux-...@vger.kernel.org; iommu@lists.linux- foundation.org; > > > > net...@vger.kernel.org; Mark Rutland; ulf.hans...@linaro.org; > > > > Russell King; Bhupesh Sharma; Joerg Roedel; Santosh Shilimkar; > > > > Yang-Leo Li; Scott Wood; Rob Herring; Claudiu Manoil; Kumar Gala; > > > > Xiaobo Xie; Qiang Zhao > > > > Subject: Re: [v10, 7/7] mmc: sdhci-of-esdhc: fix host version for > > > > T4240- > > > > R1.0-R2.0 > > > > > > > > On Thursday 05 May 2016 11:12:30 Yangbo Lu wrote: > > > > > IIRC, it is the same IP block as i.MX and Arnd's point is this > > > > > won't even compile on !PPC. It is things like this that prevent > > > > > sharing the driver. > > > > > > The whole point of using the MMIO SVR instead of the PPC SPR is so > > > that it will work on ARM... The guts driver should build on any > > > platform as long as OF is enabled, and if it doesn't find a node to > > > bind to it will return 0 for SVR, and the eSDHC driver will continue > > > (after printing an error that should be removed) without the ability > > > to test for errata based on SVR. > > > > It feels like a bad design to have to come up with a different method > > for each SoC type here when they all do the same thing and want to > > identify some variant of the chip to do device specific quirks. > > > > As far as I'm concerned, every driver in drivers/soc that needs to > > export a symbol to be used by a device driver is an indication that we > > don't have the right set of abstractions yet. There are cases that are > > not worth abstracting because the functionality is rather obscure and > > only a couple of drivers for one particular chip ever need it. > > > > Finding out the version of the SoC does not look like this case. > > I'm open to new ways of abstracting this, but can that please be > discussed after these patches are merged? This patchset is fixing a > problem, the existing abstraction is unappealing and not widely adopted, > a new abstraction is not ready, and we're only touching code for our > hardware. > > Oh, and the existing abstraction isn't even "existing". I don't see any > examples where soc_device is being used like this -- or even any way for > a driver (the one consuming the information, not the soc "driver") to get > a reference to the soc_device that's been registered short of searching > for the device object by name -- and you're asking for new functionality > in drivers/base/soc.c. > > > > > I think the first four patches take care of building for ARM, but > > > > the problem remains if you want to enable COMPILE_TEST as we need > > > > for certain automated checking. > > > > > > What specific problem is there with COMPILE_TEST? > > > > COMPILE_TEST is solvable here and the way it is implemented in this > > case (selecting FSL_GUTS from the driver) indeed looks like it works > > correctly, but it's still awkward that this means building the SoC > > specific ID stuff into the vmlinux binary for any driver that uses > > something like that for a particular SoC. > > Please keep in mind that this is a Freescale-specific driver... it's not > as if we're attaching this dependency to common SDHCI code. > > > > > > > > Dealing with Si revs is a common problem. We should have a > > > > > common solution. There is soc_device for this purpose. > > > > > > > > Exactly. The last time this came up, I think we agreed to > > > > implement a helper using glob_match() on the soc_device strings. > > > > Unfortunately this hasn't happened
[git pull] IOMMU Updates for Linux v4.7
Hi Linus, The following changes since commit 44549e8f5eea4e0a41b487b63e616cb089922b99: Linux 4.6-rc7 (2016-05-08 14:38:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-updates-v4.7 for you to fetch changes up to 6c0b43df74f900e7f31a49d1844f166df0f8afc6: Merge branches 'arm/io-pgtable', 'arm/rockchip', 'arm/omap', 'x86/vt-d', 'ppc/pamu', 'core' and 'x86/amd' into next (2016-05-09 19:39:17 +0200) IOMMU Updates for Linux v4.7 The updates include: * Rate limiting for the VT-d fault handler * Remove statistics code from the AMD IOMMU driver. It is unused and should be replaced by something more generic if needed * Per-domain pagesize-bitmaps in IOMMU core code to support systems with different types of IOMMUs * Support for ACPI devices in the AMD IOMMU driver * 4GB mode support for Mediatek IOMMU driver * ARM-SMMU updates from Will Deacon: - Support for 64k pages with SMMUv1 implementations (e.g MMU-401) - Remove open-coded 64-bit MMIO accessors - Initial support for 16-bit VMIDs, as supported by some ThunderX SMMU implementations - A couple of errata workarounds for silicon in the field * Various fixes here and there Alex Williamson (2): iommu/vt-d: Ratelimit fault handler iommu/vt-d: Improve fault handler error messages Andy Fleming (1): powerpc: Fix incorrect PPC32 PAMU dependency Cosmin-Gabriel Samoila (1): iommu/io-pgtable: Fix a brace coding style issue. Dan Carpenter (1): iommu/amd: Signedness bug in acpihid_device_group() Joerg Roedel (6): iommu/amd: Don't use IS_ERR_VALUE to check integer values iommu/amd: Move get_device_id() and friends to beginning of file Merge branch 'for-joerg/arm-smmu/updates' of git://git.kernel.org/.../will/linux into arm/smmu Merge branch 'arm/smmu' into core iommu/amd: Remove statistics code Merge branches 'arm/io-pgtable', 'arm/rockchip', 'arm/omap', 'x86/vt-d', 'ppc/pamu', 'core' and 'x86/amd' into next Michael S. Tsirkin (1): x86/vt-d: Fix comment for dma_pte_free_pagetable() Peng Fan (1): iommu/arm-smmu: Clear cache lock bit of ACR Robin Murphy (15): iommu: Add MMIO mapping type iommu/io-pgtable-arm: Support IOMMU_MMIO flag iommu/io-pgtable-arm-v7s: Support IOMMU_MMIO flag iommu/arm-smmu: Differentiate specific implementations iommu/arm-smmu: Convert ThunderX workaround to new method iommu/arm-smmu: Work around MMU-500 prefetch errata io-64-nonatomic: Add relaxed accessor variants iommu/arm-smmu: Tidy up 64-bit/atomic I/O accesses iommu/arm-smmu: Decouple context format from kernel config iommu/arm-smmu: Support SMMUv1 64KB supplement iommu/dma: Implement scatterlist segment merging iommu: of: enforce const-ness of struct iommu_ops iommu: Allow selecting page sizes per domain iommu/dma: Finish optimising higher-order allocations iommu/arm-smmu: Use per-domain page sizes. Suman Anna (4): iommu/omap: Remove iopgtable_clear_entry_all() from driver remove iommu/omap: Replace BUG() in iopgtable_store_entry_core() iommu/omap: Use WARN_ON for page table alignment check iommu/omap: Align code with open parenthesis Suravee Suthikulpanit (4): iommu/amd: Adding Extended Feature Register check for PC support iommu/amd: Modify ivhd_header structure to support type 11h and 40h iommu/amd: Use the most comprehensive IVHD type that the driver can support iommu/amd: Introduces ivrs_acpihid kernel parameter Tirumalesh Chalamarla (2): iommu/arm-smmu: Add support for 16 bit VMID iommu/arm-smmu: Workaround for ThunderX erratum #27704 Tomeu Vizoso (1): iommu/rockchip: Don't feed NULL res pointers to devres Wan Zongshun (5): iommu/amd: Add new map for storing IVHD dev entry type HID iommu/amd: Make call-sites of get_device_id aware of its return value iommu/amd: Add iommu support for ACPI HID devices iommu/amd: Manage iommu_group for ACPI HID devices iommu/amd: Set AMD iommu callbacks for amba bus Will Deacon (1): iommu: remove unused priv field from struct iommu_ops Yong Wu (2): iommu/io-pgtable: Add MTK 4GB mode in Short-descriptor iommu/mediatek: Add 4GB mode support Documentation/arm64/silicon-errata.txt | 2 + .../devicetree/bindings/iommu/arm,smmu.txt | 1 + Documentation/kernel-parameters.txt| 7 + arch/arm/include/asm/dma-mapping.h | 2 +- arch/arm/mm/dma-mapping.c | 6 +- arch/arm64/inclu
Re: [PATCHv6 3/8] dma-mapping: add dma_{map,unmap}_resource
On Thu, May 19, 2016 at 01:29:26PM +0200, Niklas Söderlund wrote: > Hi Konrad, > > Thanks for your feedback. > > On 2016-05-17 10:54:45 -0400, Konrad Rzeszutek Wilk wrote: > > > > > > -In some circumstances dma_map_single() and dma_map_page() will fail to > > > create > > > -a mapping. A driver can check for these errors by testing the returned > > > -DMA address with dma_mapping_error(). A non-zero return value means the > > > mapping > > > -could not be created and the driver should take appropriate action (e.g. > > > -reduce current DMA mapping usage or delay and try again later). > > > +In some circumstances dma_map_single(), dma_map_page() and > > > dma_map_resource() > > > +will fail to create a mapping. A driver can check for these errors by > > > testing > > > +the returned DMA address with dma_mapping_error(). A non-zero return > > > value > > > +means the mapping could not be created and the driver should take > > > appropriate > > > +action (e.g. reduce current DMA mapping usage or delay and try again > > > later). > > > > This looks like it belongs to another patch? > > No it is correct (at least intended to be in this patch). All it really > do is inject dma_map_resource() (which is added in this patch) as one of > the calls which return dma_addr_t should be checked for error using > dma_mapping_error(). But yes the change effect all lines in the > paragraph due to line wrapping. > > Hum or maybe I'm misunderstanding your question. I totally missed the 'dma_map_resource' in there and just read 'dma_mapping_error'! Thanks. > > -- > Regards, > Niklas Söderlund ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 2/5] iommu/mediatek: move the common struct into header file
From: Honghui Zhang
Move the struct defines of mtk iommu into a new header files for
common use.
Signed-off-by: Honghui Zhang
---
drivers/iommu/mtk_iommu.c | 62 +---
drivers/iommu/mtk_iommu.h | 90 +++
2 files changed, 91 insertions(+), 61 deletions(-)
create mode 100644 drivers/iommu/mtk_iommu.h
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index db74553..a6b7846 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -34,7 +34,7 @@
#include
#include
-#include "io-pgtable.h"
+#include "mtk_iommu.h"
#define REG_MMU_PT_BASE_ADDR 0x000
@@ -93,49 +93,8 @@
#define MTK_PROTECT_PA_ALIGN 128
-struct mtk_iommu_suspend_reg {
- u32 standard_axi_mode;
- u32 dcm_dis;
- u32 ctrl_reg;
- u32 int_control0;
- u32 int_main_control;
-};
-
-struct mtk_iommu_client_priv {
- struct list_headclient;
- unsigned intmtk_m4u_id;
- struct device *m4udev;
-};
-
-struct mtk_iommu_domain {
- spinlock_t pgtlock; /* lock for page table */
-
- struct io_pgtable_cfg cfg;
- struct io_pgtable_ops *iop;
-
- struct iommu_domain domain;
-};
-
-struct mtk_iommu_data {
- void __iomem*base;
- int irq;
- struct device *dev;
- struct clk *bclk;
- phys_addr_t protect_base; /* protect memory base */
- struct mtk_iommu_suspend_regreg;
- struct mtk_iommu_domain *m4u_dom;
- struct iommu_group *m4u_group;
- struct mtk_smi_iommusmi_imu; /* SMI larb iommu info */
- boolenable_4GB;
-};
-
static struct iommu_ops mtk_iommu_ops;
-static struct mtk_iommu_domain *to_mtk_domain(struct iommu_domain *dom)
-{
- return container_of(dom, struct mtk_iommu_domain, domain);
-}
-
static void mtk_iommu_tlb_flush_all(void *cookie)
{
struct mtk_iommu_data *data = cookie;
@@ -552,25 +511,6 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data
*data)
return 0;
}
-static int compare_of(struct device *dev, void *data)
-{
- return dev->of_node == data;
-}
-
-static int mtk_iommu_bind(struct device *dev)
-{
- struct mtk_iommu_data *data = dev_get_drvdata(dev);
-
- return component_bind_all(dev, &data->smi_imu);
-}
-
-static void mtk_iommu_unbind(struct device *dev)
-{
- struct mtk_iommu_data *data = dev_get_drvdata(dev);
-
- component_unbind_all(dev, &data->smi_imu);
-}
-
static const struct component_master_ops mtk_iommu_com_ops = {
.bind = mtk_iommu_bind,
.unbind = mtk_iommu_unbind,
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
new file mode 100644
index 000..5656355
--- /dev/null
+++ b/drivers/iommu/mtk_iommu.h
@@ -0,0 +1,90 @@
+/*
+ * Copyright (c) 2015-2016 MediaTek Inc.
+ * Author: Yong Wu
+ * : Honghui Zhang
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _MTK_IOMMU_H_
+#define _MTK_IOMMU_H_
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "io-pgtable.h"
+
+struct mtk_iommu_suspend_reg {
+ u32 standard_axi_mode;
+ u32 dcm_dis;
+ u32 ctrl_reg;
+ u32 int_control0;
+ u32 int_main_control;
+};
+
+struct mtk_iommu_client_priv {
+ struct list_headclient;
+ unsigned intmtk_m4u_id;
+ struct device *m4udev;
+};
+
+struct mtk_iommu_domain {
+ spinlock_t pgtlock; /* lock for page table */
+
+ struct io_pgtable_cfg cfg;
+ struct io_pgtable_ops *iop;
+
+ struct iommu_domain domain;
+};
+
+struct mtk_iommu_data {
+ void __iomem*base;
+ int irq;
+ struct device *dev;
+ struct clk *bclk;
+ phys_addr_t protect_base; /* protect memory base *
[PATCH 5/5] ARM: dts: mt2701: add iommu/smi dtsi node for mt2701
From: Honghui Zhang
Add the dtsi node of iommu and smi for mt2701.
Signed-off-by: Honghui Zhang
---
arch/arm/boot/dts/mt2701.dtsi | 51 +++
1 file changed, 51 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 42d5a37..363de0d 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include "skeleton64.dtsi"
#include "mt2701-pinfunc.h"
@@ -160,6 +161,16 @@
clock-names = "system-clk", "rtc-clk";
};
+ smi_common: smi@1000c000 {
+ compatible = "mediatek,mt2701-smi-common";
+ reg = <0 0x1000c000 0 0x1000>;
+ clocks = <&infracfg CLK_INFRA_SMI>,
+<&mmsys CLK_MM_SMI_COMMON>,
+<&infracfg CLK_INFRA_SMI>;
+ clock-names = "apb", "smi", "async";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
+ };
+
sysirq: interrupt-controller@10200100 {
compatible = "mediatek,mt2701-sysirq",
"mediatek,mt6577-sysirq";
@@ -169,6 +180,16 @@
reg = <0 0x10200100 0 0x1c>;
};
+ iommu: mmsys_iommu@10205000 {
+ compatible = "mediatek,mt2701-m4u";
+ reg = <0 0x10205000 0 0x1000>;
+ interrupts = ;
+ clocks = <&infracfg CLK_INFRA_M4U>;
+ clock-names = "bclk";
+ mediatek,larbs = <&larb0 &larb1 &larb2>;
+ #iommu-cells = <1>;
+ };
+
apmixedsys: syscon@10209000 {
compatible = "mediatek,mt2701-apmixedsys", "syscon";
reg = <0 0x10209000 0 0x1000>;
@@ -234,6 +255,16 @@
status = "disabled";
};
+ larb0: larb@1401 {
+ compatible = "mediatek,mt2701-smi-larb";
+ reg = <0 0x1401 0 0x1000>;
+ mediatek,smi = <&smi_common>;
+ clocks = <&mmsys CLK_MM_SMI_LARB0>,
+<&mmsys CLK_MM_SMI_LARB0>;
+ clock-names = "apb", "smi";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>;
+ };
+
imgsys: syscon@1500 {
compatible = "mediatek,mt2701-imgsys", "syscon";
reg = <0 0x1500 0 0x1000>;
@@ -241,6 +272,16 @@
status = "disabled";
};
+ larb2: larb@15001000 {
+ compatible = "mediatek,mt2701-smi-larb";
+ reg = <0 0x15001000 0 0x1000>;
+ mediatek,smi = <&smi_common>;
+ clocks = <&imgsys CLK_IMG_SMI_COMM>,
+<&imgsys CLK_IMG_SMI_COMM>;
+ clock-names = "apb", "smi";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
+ };
+
vdecsys: syscon@1600 {
compatible = "mediatek,mt2701-vdecsys", "syscon";
reg = <0 0x1600 0 0x1000>;
@@ -248,6 +289,16 @@
status = "disabled";
};
+ larb1: larb@1601 {
+ compatible = "mediatek,mt2701-smi-larb";
+ reg = <0 0x1601 0 0x1000>;
+ mediatek,smi = <&smi_common>;
+ clocks = <&vdecsys CLK_VDEC_CKGEN>,
+<&vdecsys CLK_VDEC_LARB>;
+ clock-names = "apb", "smi";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_VDEC>;
+ };
+
hifsys: syscon@1a00 {
compatible = "mediatek,mt2701-hifsys", "syscon";
reg = <0 0x1a00 0 0x1000>;
--
1.8.1.1.dirty
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 0/5] MT2701 iommu support
From: Honghui Zhang Mediatek's m4u(Multimedia Memory Management Unit) and SMI(Smart Multimedia Interface)have two generations HW. They basically sharing the same hardware block diagram, but have some difference as below: Generation one m4u only supports one layer, flat pagetable addressing, and only supports 4K size page mapping. While generation two m4u supports 2 levels of pagetable which uses the ARM short-descriptor translation table format for address translation. They have slight different register base and register offset. They have very different HW ports defines. Generaion one SMI has additional "async" clock which transform the smi clock into emi clock domain, this clock should be prepared and enabled for SMI generation one HW. The register which control the iommu need to translation the address or not for a particular port is located at smi ao base(smi always on register base) for generation one SMI HW, but located at each larb's register base for generation two HW. This patch set add mt2701 iommu support, it's based on 4.6-rc1 and James Liao's "Add clock support for Mediatek MT2701 v8[1]" and "Mediatek MT2701 SCPSYS power domain support v7[2]" patch. v2: -Fix syntax errors in dt-bindings. -Use dma_alloc/free_coherent to allocate pagetable memory and reduce the streaming DMA stuff. -Make the mtk_iommu_ops.pgsize_bitmap as ~0UL << MT2701_IOMMU_PAGE_SHIFT. -Use macro instead of variable to indicate the pagetable size. -Change some macro name from MTK_XXX to MT2701_XXX. v1: http://lists.infradead.org/pipermail/linux-mediatek/2016-May/005301.html -initial version [1] http://lists.infradead.org/pipermail/linux-mediatek/2016-May/005439.html [2] http://lists.infradead.org/pipermail/linux-mediatek/2016-May/005429.html Honghui Zhang (5): dt-bindings: mediatek: add descriptions for mediatek mt2701 iommu and smi iommu/mediatek: move the common struct into header file memory/mediatek: add support for mt2701 iommu/mediatek: add support for mtk iommu generation one HW ARM: dts: mt2701: add iommu/smi dtsi node for mt2701 .../devicetree/bindings/iommu/mediatek,iommu.txt | 13 +- .../memory-controllers/mediatek,smi-common.txt | 21 +- .../memory-controllers/mediatek,smi-larb.txt | 4 +- arch/arm/boot/dts/mt2701.dtsi | 51 ++ drivers/iommu/Kconfig | 19 + drivers/iommu/Makefile | 1 + drivers/iommu/mtk_iommu.c | 62 +- drivers/iommu/mtk_iommu.h | 93 +++ drivers/iommu/mtk_iommu_v1.c | 742 + drivers/memory/mtk-smi.c | 168 - include/dt-bindings/memory/mt2701-larb-port.h | 85 +++ 11 files changed, 1171 insertions(+), 88 deletions(-) create mode 100644 drivers/iommu/mtk_iommu.h create mode 100644 drivers/iommu/mtk_iommu_v1.c create mode 100644 include/dt-bindings/memory/mt2701-larb-port.h -- 1.8.1.1.dirty ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2 4/5] iommu/mediatek: add support for mtk iommu generation one HW
From: Honghui Zhang
Mediatek SoC's M4U has two generations of HW architcture. Generation one
uses flat, one layer pagetable, and was shipped with ARM architecture, it
only supports 4K size page mapping. MT2701 SoC uses this generation one
m4u HW. Generation two uses the ARM short-descriptor translation table
format for address translation, and was shipped with ARM64 architecture,
MT8173 uses this generation two m4u HW. All the two generation iommu HW
only have one iommu domain, and all its iommu clients share the same
iova address.
These two generation m4u HW have slit different register groups and
register offset, but most register names are the same. This patch add iommu
support for mediatek SoC mt2701.
Signed-off-by: Honghui Zhang
---
drivers/iommu/Kconfig| 19 ++
drivers/iommu/Makefile | 1 +
drivers/iommu/mtk_iommu.h| 3 +
drivers/iommu/mtk_iommu_v1.c | 742 +++
4 files changed, 765 insertions(+)
create mode 100644 drivers/iommu/mtk_iommu_v1.c
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index dd1dc39..2e17d70 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -354,4 +354,23 @@ config MTK_IOMMU
If unsure, say N here.
+config MTK_IOMMU_V1
+ bool "MTK IOMMU Version 1 (M4U gen1) Support"
+ depends on ARM || ARM64
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ select ARM_DMA_USE_IOMMU
+ select IOMMU_API
+ select IOMMU_DMA
+ select MEMORY
+ select MTK_SMI
+ select COMMON_CLK_MT2701_MMSYS
+ select COMMON_CLK_MT2701_IMGSYS
+ select COMMON_CLK_MT2701_VDECSYS
+ help
+ Support for the M4U on certain Mediatek SoCs. M4U generation 1 HW is
+ Multimedia Memory Managememt Unit. This option enables remapping of
+ DMA memory accesses for the multimedia subsystem.
+
+ if unsure, say N here.
+
endif # IOMMU_SUPPORT
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index c6edb31..778baf5 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_INTEL_IOMMU_SVM) += intel-svm.o
obj-$(CONFIG_IPMMU_VMSA) += ipmmu-vmsa.o
obj-$(CONFIG_IRQ_REMAP) += intel_irq_remapping.o irq_remapping.o
obj-$(CONFIG_MTK_IOMMU) += mtk_iommu.o
+obj-$(CONFIG_MTK_IOMMU_V1) += mtk_iommu_v1.o
obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o
obj-$(CONFIG_ROCKCHIP_IOMMU) += rockchip-iommu.o
diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
index 5656355..8d60f21 100644
--- a/drivers/iommu/mtk_iommu.h
+++ b/drivers/iommu/mtk_iommu.h
@@ -48,6 +48,9 @@ struct mtk_iommu_domain {
struct io_pgtable_ops *iop;
struct iommu_domain domain;
+ void*pgt_va;
+ dma_addr_t pgt_pa;
+ void*cookie;
};
struct mtk_iommu_data {
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
new file mode 100644
index 000..55023e1
--- /dev/null
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -0,0 +1,742 @@
+/*
+ * Copyright (c) 2015-2016 MediaTek Inc.
+ * Author: Yong Wu
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "mtk_iommu.h"
+
+#define REG_MMU_PT_BASE_ADDR 0x000
+
+#define F_ALL_INVLD0x2
+#define F_MMU_INV_RANGE0x1
+#define F_INVLD_EN0BIT(0)
+#define F_INVLD_EN1BIT(1)
+
+#define F_MMU_FAULT_VA_MSK 0xf000
+#define MTK_PROTECT_PA_ALIGN 128
+
+#define REG_MMU_CTRL_REG 0x210
+#define F_MMU_CTRL_COHERENT_EN BIT(8)
+#define REG_MMU_IVRP_PADDR 0x214
+#define REG_MMU_INT_CONTROL0x220
+#define F_INT_TRANSLATION_FAULTBIT(0)
+#define F_INT_MAIN_MULTI_HIT_FAULT BIT(1)
+#define F_INT_INVALID_PA_FAULT BIT(2)
+#define F_INT_ENTRY_REPLACEMENT_FAULT BIT(3)
+#define F_INT_TABLE_WALK_FAULT BIT(4)
+#define F_INT_TLB_MISS_FAULT BIT(5)
+#define F_INT_PFH_DMA_FIFO_OVERFLOWBIT(6)
+#define F_IN
[PATCH v2 1/5] dt-bindings: mediatek: add descriptions for mediatek mt2701 iommu and smi
From: Honghui Zhang
This patch defines the local arbitor port IDs for mediatek SoC MT2701 and
add descriptions of binding for mediatek generation one iommu and smi.
Signed-off-by: Honghui Zhang
---
.../devicetree/bindings/iommu/mediatek,iommu.txt | 13 +++-
.../memory-controllers/mediatek,smi-common.txt | 21 +-
.../memory-controllers/mediatek,smi-larb.txt | 4 +-
include/dt-bindings/memory/mt2701-larb-port.h | 85 ++
4 files changed, 115 insertions(+), 8 deletions(-)
create mode 100644 include/dt-bindings/memory/mt2701-larb-port.h
diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
index cd1b1cd..53c20ca 100644
--- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
@@ -1,7 +1,9 @@
* Mediatek IOMMU Architecture Implementation
- Some Mediatek SOCs contain a Multimedia Memory Management Unit (M4U) which
-uses the ARM Short-Descriptor translation table format for address translation.
+ Some Mediatek SOCs contain a Multimedia Memory Management Unit (M4U), and
+this M4U have two generations of HW architecture. Generation one uses flat
+pagetable, and only supports 4K size page mapping. Generation two uses the
+ARM Short-Descriptor translation table format for address translation.
About the M4U Hardware Block Diagram, please check below:
@@ -36,7 +38,9 @@ in each larb. Take a example, There are many ports like MC,
PP, VLD in the
video decode local arbiter, all these ports are according to the video HW.
Required properties:
-- compatible : must be "mediatek,mt8173-m4u".
+- compatible : must be one of the following string:
+ "mediatek,mt2701-m4u" for mt2701 which uses generation one m4u HW.
+ "mediatek,mt8173-m4u" for mt8173 which uses generation two m4u HW.
- reg : m4u register base and size.
- interrupts : the interrupt of m4u.
- clocks : must contain one entry for each clock-names.
@@ -46,7 +50,8 @@ Required properties:
according to the local arbiter index, like larb0, larb1, larb2...
- iommu-cells : must be 1. This is the mtk_m4u_id according to the HW.
Specifies the mtk_m4u_id as defined in
- dt-binding/memory/mt8173-larb-port.h.
+ dt-binding/memory/mt2701-larb-port.h for mt2701 and
+ dt-binding/memory/mt8173-larb-port.h for mt8173
Example:
iommu: iommu@10205000 {
diff --git
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
index 06a83ce..aa614b2 100644
---
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
+++
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
@@ -2,16 +2,31 @@ SMI (Smart Multimedia Interface) Common
The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
+Mediatek SMI have two generations of HW architecture, mt8173 uses the second
+generation of SMI HW while mt2701 uses the first generation HW of SMI.
+
+There's slight differences between the two SMI, for generation 2, the
+register which control the iommu port is at each larb's register base. But
+for generation 1, the register is at smi ao base(smi always on register
+base). Besides that, the smi async clock should be prepared and enabled for
+SMI generation 1 to transform the smi clock into emi clock domain, but that is
+not needed for SMI generation 2.
+
Required properties:
-- compatible : must be "mediatek,mt8173-smi-common"
+- compatible : must be one of :
+ "mediatek,mt2701-smi-common"
+ "mediatek,mt8173-smi-common"
- reg : the register and size of the SMI block.
- power-domains : a phandle to the power domain of this local arbiter.
- clocks : Must contain an entry for each entry in clock-names.
-- clock-names : must contain 2 entries, as follows:
+- clock-names : must contain 3 entries for generation 1 smi HW and 2 entries
+ for generation 2 smi HW as follows:
- "apb" : Advanced Peripheral Bus clock, It's the clock for setting
the register.
- "smi" : It's the clock for transfer data and command.
- They may be the same if both source clocks are the same.
+ They may be the same if both source clocks are the same.
+ - "async" : asynchronous clock, it help transform the smi clock into the emi
+ clock domain, this clock is only needed by generation 1 smi HW.
Example:
smi_common: smi@14022000 {
diff --git
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
index 55ff3b7..21277a5 100644
--- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
@@ -3,7 +3,9 @@ SMI (Smart Multimedia Interface) Local Ar
[PATCH v2 3/5] memory/mediatek: add support for mt2701
From: Honghui Zhang
Mediatek SMI has two generations of HW architecture, mt8173 uses the
second generation of SMI HW while mt2701 uses the first generation
HW of SMI.
There's slight differences between the two generations, for generation 2,
the register which control the iommu port access PA or IOVA is at each
larb's register base. But for generation 1, the register is at smi ao
base(smi always on register base).
Besides that, the smi async clock should be prepared and enabled for SMI
generation 1 HW to transform the smi clock into emi clock domain, but is
not needed for SMI generation 2.
This patch add SMI driver for mt2701 which use generation 1 SMI HW.
Signed-off-by: Honghui Zhang
---
drivers/memory/mtk-smi.c | 168 +--
1 file changed, 149 insertions(+), 19 deletions(-)
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
index 089091f..0a47382 100644
--- a/drivers/memory/mtk-smi.c
+++ b/drivers/memory/mtk-smi.c
@@ -21,19 +21,50 @@
#include
#include
#include
+#include
#define SMI_LARB_MMU_EN0xf00
+#define REG_SMI_SECUR_CON_BASE 0x5c0
+
+/* every register control 8 port, register offset 0x4 */
+#define REG_SMI_SECUR_CON_OFFSET(id) (((id) >> 3) << 2)
+#define REG_SMI_SECUR_CON_ADDR(id) \
+ (REG_SMI_SECUR_CON_BASE + REG_SMI_SECUR_CON_OFFSET(id))
+
+/*
+ * every port have 4 bit to control, bit[port + 3] control virtual or physical,
+ * bit[port + 2 : port + 1] control the domain, bit[port] control the security
+ * or non-security.
+ */
+#define SMI_SECUR_CON_VAL_MSK(id) (~(0xf << (((id) & 0x7) << 2)))
+#define SMI_SECUR_CON_VAL_VIRT(id) BITid) & 0x7) << 2) + 3)
+/* mt2701 domain should be set to 3 */
+#define SMI_SECUR_CON_VAL_DOMAIN(id) (0x3 << id) & 0x7) << 2) + 1))
+
+struct mtk_smi_larb_gen {
+ int port_in_larb[MTK_LARB_NR_MAX + 1];
+ void (*config_port)(struct device *);
+};
struct mtk_smi {
- struct device *dev;
- struct clk *clk_apb, *clk_smi;
+ struct device *dev;
+ struct clk *clk_apb, *clk_smi;
+ struct clk *clk_async; /*only needed by mt2701*/
+ void __iomem*smi_ao_base;
};
struct mtk_smi_larb { /* larb: local arbiter */
- struct mtk_smi smi;
- void __iomem*base;
- struct device *smi_common_dev;
- u32 *mmu;
+ struct mtk_smi smi;
+ void __iomem*base;
+ struct device *smi_common_dev;
+ const struct mtk_smi_larb_gen *larb_gen;
+ int larbid;
+ u32 *mmu;
+};
+
+enum mtk_smi_gen {
+ MTK_SMI_GEN1,
+ MTK_SMI_GEN2
};
static int mtk_smi_enable(const struct mtk_smi *smi)
@@ -71,6 +102,7 @@ static void mtk_smi_disable(const struct mtk_smi *smi)
int mtk_smi_larb_get(struct device *larbdev)
{
struct mtk_smi_larb *larb = dev_get_drvdata(larbdev);
+ const struct mtk_smi_larb_gen *larb_gen = larb->larb_gen;
struct mtk_smi *common = dev_get_drvdata(larb->smi_common_dev);
int ret;
@@ -87,8 +119,7 @@ int mtk_smi_larb_get(struct device *larbdev)
}
/* Configure the iommu info for this larb */
- writel(*larb->mmu, larb->base + SMI_LARB_MMU_EN);
-
+ larb_gen->config_port(larbdev);
return 0;
}
@@ -124,6 +155,45 @@ mtk_smi_larb_bind(struct device *dev, struct device
*master, void *data)
return -ENODEV;
}
+static void mtk_smi_larb_config_port(struct device *dev)
+{
+ struct mtk_smi_larb *larb = dev_get_drvdata(dev);
+
+ writel(*larb->mmu, larb->base + SMI_LARB_MMU_EN);
+}
+
+
+static void mtk_smi_larb_config_port_gen1(struct device *dev)
+{
+ struct mtk_smi_larb *larb = dev_get_drvdata(dev);
+ const struct mtk_smi_larb_gen *larb_gen = larb->larb_gen;
+ struct mtk_smi *common = dev_get_drvdata(larb->smi_common_dev);
+ int i, m4u_port_id, larb_port_num;
+ u32 sec_con_val, reg_val;
+
+ m4u_port_id = larb_gen->port_in_larb[larb->larbid];
+ larb_port_num = larb_gen->port_in_larb[larb->larbid + 1]
+ - larb_gen->port_in_larb[larb->larbid];
+
+ for (i = 0; i < larb_port_num; i++, m4u_port_id++) {
+ if (*larb->mmu & BIT(i)) {
+ /* bit[port + 3] controls the virtual or physical */
+ sec_con_val = SMI_SECUR_CON_VAL_VIRT(m4u_port_id);
+ } else {
+ /* do not need to enable m4u for this port */
+ continue;
+ }
+ reg_val = readl(common->smi_ao_base
+ + REG_SMI_SECUR_CON_ADDR(m4u_port_id));
+ reg_val &= SMI_SECUR_CON_VAL_MSK(m4u_port_id);
+ reg_val |= sec_con_val;
+ reg_val |= SMI_SECUR_CON_VAL_DOMA
Re: [PATCHv6 2/8] dma-debug: add support for resource mappings
On 19/05/16 12:21, Niklas Söderlund wrote:
Hi Konrad,
Thanks for your feedback.
On 2016-05-17 10:50:02 -0400, Konrad Rzeszutek Wilk wrote:
+void debug_dma_map_resource(struct device *dev, phys_addr_t addr, size_t size,
+ int direction, dma_addr_t dma_addr)
+{
+ struct dma_debug_entry *entry;
+
+ if (unlikely(dma_debug_disabled()))
+ return;
+
+ entry = dma_entry_alloc();
+ if (!entry)
+ return;
+
+ entry->type = dma_debug_resource;
+ entry->dev = dev;
+ entry->pfn = __phys_to_pfn(addr);
+ entry->offset= addr - PHYS_PFN(entry->pfn);
Is that right?
You are correct that should be:
entry->offset = addr - PFN_PHYS(entry->pfn);
Or even better:
entry->offset = addr - __pfn_to_phys(entry->pfn);
Better still, simply offset_in_page(addr) (as per dma_map_single()).
Robin.
I will address this and resend late next week, still hoping for some
more feedback.
__phys_to_pfn(addr) is PHYS_PFN(addr), so what you get here is
addr - PHYS_PFN(PHYS_PFN(addr)) ?
+ entry->size = size;
+ entry->dev_addr = dma_addr;
+ entry->direction = direction;
+ entry->map_err_type = MAP_ERR_NOT_CHECKED;
+
+ add_dma_entry(entry);
+}
+EXPORT_SYMBOL(debug_dma_map_resource);
+
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv6 3/8] dma-mapping: add dma_{map,unmap}_resource
Hi Konrad, Thanks for your feedback. On 2016-05-17 10:54:45 -0400, Konrad Rzeszutek Wilk wrote: > > > > -In some circumstances dma_map_single() and dma_map_page() will fail to > > create > > -a mapping. A driver can check for these errors by testing the returned > > -DMA address with dma_mapping_error(). A non-zero return value means the > > mapping > > -could not be created and the driver should take appropriate action (e.g. > > -reduce current DMA mapping usage or delay and try again later). > > +In some circumstances dma_map_single(), dma_map_page() and > > dma_map_resource() > > +will fail to create a mapping. A driver can check for these errors by > > testing > > +the returned DMA address with dma_mapping_error(). A non-zero return value > > +means the mapping could not be created and the driver should take > > appropriate > > +action (e.g. reduce current DMA mapping usage or delay and try again > > later). > > This looks like it belongs to another patch? No it is correct (at least intended to be in this patch). All it really do is inject dma_map_resource() (which is added in this patch) as one of the calls which return dma_addr_t should be checked for error using dma_mapping_error(). But yes the change effect all lines in the paragraph due to line wrapping. Hum or maybe I'm misunderstanding your question. -- Regards, Niklas Söderlund ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv6 2/8] dma-debug: add support for resource mappings
Hi Konrad,
Thanks for your feedback.
On 2016-05-17 10:50:02 -0400, Konrad Rzeszutek Wilk wrote:
> > +void debug_dma_map_resource(struct device *dev, phys_addr_t addr, size_t
> > size,
> > + int direction, dma_addr_t dma_addr)
> > +{
> > + struct dma_debug_entry *entry;
> > +
> > + if (unlikely(dma_debug_disabled()))
> > + return;
> > +
> > + entry = dma_entry_alloc();
> > + if (!entry)
> > + return;
> > +
> > + entry->type = dma_debug_resource;
> > + entry->dev = dev;
> > + entry->pfn = __phys_to_pfn(addr);
> > + entry->offset = addr - PHYS_PFN(entry->pfn);
>
> Is that right?
You are correct that should be:
entry->offset = addr - PFN_PHYS(entry->pfn);
Or even better:
entry->offset = addr - __pfn_to_phys(entry->pfn);
I will address this and resend late next week, still hoping for some
more feedback.
>
> __phys_to_pfn(addr) is PHYS_PFN(addr), so what you get here is
>
> addr - PHYS_PFN(PHYS_PFN(addr)) ?
>
>
> > + entry->size = size;
> > + entry->dev_addr = dma_addr;
> > + entry->direction= direction;
> > + entry->map_err_type = MAP_ERR_NOT_CHECKED;
> > +
> > + add_dma_entry(entry);
> > +}
> > +EXPORT_SYMBOL(debug_dma_map_resource);
> > +
--
Regards,
Niklas Söderlund
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
