* [PATCH] pinctrl/nomadik: debugfs display of other alternate-C functions
From: Linus Walleij @ 2012-10-15 9:04 UTC (permalink / raw)
To: linux-arm-kernel
From: Jean-Nicolas Graux <jean-nicolas.graux@stericsson.com>
In pinctrl debug pins file, enable display of AltCx functions.
Signed-off-by: Jean-Nicolas Graux <jean-nicolas.graux@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/pinctrl/pinctrl-nomadik.c | 45 +++++++++++++++++++++++++++++++++++----
1 file changed, 41 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-nomadik.c b/drivers/pinctrl/pinctrl-nomadik.c
index 2bf6049..0a712c2 100644
--- a/drivers/pinctrl/pinctrl-nomadik.c
+++ b/drivers/pinctrl/pinctrl-nomadik.c
@@ -658,6 +658,35 @@ int nmk_gpio_set_mode(int gpio, int gpio_mode)
}
EXPORT_SYMBOL(nmk_gpio_set_mode);
+static int nmk_prcm_gpiocr_get_mode(struct pinctrl_dev *pctldev, int gpio)
+{
+ int i;
+ u16 reg;
+ u8 bit;
+ struct nmk_pinctrl *npct = pinctrl_dev_get_drvdata(pctldev);
+ const struct prcm_gpiocr_altcx_pin_desc *pin_desc;
+ const u16 *gpiocr_regs;
+
+ for (i = 0; i < npct->soc->npins_altcx; i++) {
+ if (npct->soc->altcx_pins[i].pin == gpio)
+ break;
+ }
+ if (i == npct->soc->npins_altcx)
+ return NMK_GPIO_ALT_C;
+
+ pin_desc = npct->soc->altcx_pins + i;
+ gpiocr_regs = npct->soc->prcm_gpiocr_registers;
+ for (i = 0; i < PRCM_IDX_GPIOCR_ALTC_MAX; i++) {
+ if (pin_desc->altcx[i].used == true) {
+ reg = gpiocr_regs[pin_desc->altcx[i].reg_index];
+ bit = pin_desc->altcx[i].control_bit;
+ if (prcmu_read(reg) & BIT(bit))
+ return NMK_GPIO_ALT_C+i+1;
+ }
+ }
+ return NMK_GPIO_ALT_C;
+}
+
int nmk_gpio_get_mode(int gpio)
{
struct nmk_gpio_chip *nmk_chip;
@@ -1046,8 +1075,9 @@ static int nmk_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
#include <linux/seq_file.h>
-static void nmk_gpio_dbg_show_one(struct seq_file *s, struct gpio_chip *chip,
- unsigned offset, unsigned gpio)
+static void nmk_gpio_dbg_show_one(struct seq_file *s,
+ struct pinctrl_dev *pctldev, struct gpio_chip *chip,
+ unsigned offset, unsigned gpio)
{
const char *label = gpiochip_is_requested(chip, offset);
struct nmk_gpio_chip *nmk_chip =
@@ -1061,12 +1091,18 @@ static void nmk_gpio_dbg_show_one(struct seq_file *s, struct gpio_chip *chip,
[NMK_GPIO_ALT_A] = "altA",
[NMK_GPIO_ALT_B] = "altB",
[NMK_GPIO_ALT_C] = "altC",
+ [NMK_GPIO_ALT_C+1] = "altC1",
+ [NMK_GPIO_ALT_C+2] = "altC2",
+ [NMK_GPIO_ALT_C+3] = "altC3",
+ [NMK_GPIO_ALT_C+4] = "altC4",
};
clk_enable(nmk_chip->clk);
is_out = !!(readl(nmk_chip->addr + NMK_GPIO_DIR) & bit);
pull = !(readl(nmk_chip->addr + NMK_GPIO_PDIS) & bit);
mode = nmk_gpio_get_mode(gpio);
+ if ((mode == NMK_GPIO_ALT_C) && pctldev)
+ mode = nmk_prcm_gpiocr_get_mode(pctldev, gpio);
seq_printf(s, " gpio-%-3d (%-20.20s) %s %s %s %s",
gpio, label ?: "(none)",
@@ -1110,13 +1146,14 @@ static void nmk_gpio_dbg_show(struct seq_file *s, struct gpio_chip *chip)
unsigned gpio = chip->base;
for (i = 0; i < chip->ngpio; i++, gpio++) {
- nmk_gpio_dbg_show_one(s, chip, i, gpio);
+ nmk_gpio_dbg_show_one(s, NULL, chip, i, gpio);
seq_printf(s, "\n");
}
}
#else
static inline void nmk_gpio_dbg_show_one(struct seq_file *s,
+ struct pinctrl_dev *pctldev,
struct gpio_chip *chip,
unsigned offset, unsigned gpio)
{
@@ -1454,7 +1491,7 @@ static void nmk_pin_dbg_show(struct pinctrl_dev *pctldev, struct seq_file *s,
return;
}
chip = range->gc;
- nmk_gpio_dbg_show_one(s, chip, offset - chip->base, offset);
+ nmk_gpio_dbg_show_one(s, pctldev, chip, offset - chip->base, offset);
}
static struct pinctrl_ops nmk_pinctrl_ops = {
--
1.7.11.3
^ permalink raw reply related
* [PATCH] ARM: dts: imx6q-arm2: move NANDF_CS pins out of 'hog'
From: Shawn Guo @ 2012-10-15 8:48 UTC (permalink / raw)
To: linux-arm-kernel
Commit 9e3c0066 (ARM: dts: imx6q-arm2: add pinctrl for uart and enet)
defines NANDF_CS pins as gpio in 'hog', assuming these two pins are
always used by usdhc3 in gpio mode as card-detection and
write-protection on ARM2 board. But it's not true. These pins are
shared by usdhc3 and gpmi-nand. We should have the pins functional
for gpmi-nand when usdhc3 is disabled.
Move the pins out of 'hog', so that pins only work in gpio mode as CD
and WP when usdhc3 is enabled, and otherwise they are available for
gpmi-nand.
Reported-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
Huang,
Please help test the patch to see if it fixes your problem, thanks.
Shawn
arch/arm/boot/dts/imx6q-arm2.dts | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6q-arm2.dts b/arch/arm/boot/dts/imx6q-arm2.dts
index 15df4c1..5bfa02a 100644
--- a/arch/arm/boot/dts/imx6q-arm2.dts
+++ b/arch/arm/boot/dts/imx6q-arm2.dts
@@ -37,6 +37,13 @@
pinctrl_hog: hoggrp {
fsl,pins = <
176 0x80000000 /* MX6Q_PAD_EIM_D25__GPIO_3_25 */
+ >;
+ };
+ };
+
+ arm2 {
+ pinctrl_usdhc3_arm2: usdhc3grp-arm2 {
+ fsl,pins = <
1363 0x80000000 /* MX6Q_PAD_NANDF_CS0__GPIO_6_11 */
1369 0x80000000 /* MX6Q_PAD_NANDF_CS1__GPIO_6_14 */
>;
@@ -58,7 +65,8 @@
wp-gpios = <&gpio6 14 0>;
vmmc-supply = <®_3p3v>;
pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_usdhc3_1>;
+ pinctrl-0 = <&pinctrl_usdhc3_1
+ &pinctrl_usdhc3_arm2>;
status = "okay";
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 2/2] ARM: mach-shmobile: sh7372: Add IPMMU device
From: Hideki EIRAKU @ 2012-10-15 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350290093-998-1-git-send-email-hdk@igel.co.jp>
This patch adds an IPMMU device and notifies the IPMMU driver which
devices are connected via the IPMMU module. All devices connected to the main
memory bus via the IPMMU module MUST be registered when SHMOBILE_IPMMU and
SHMOBILE_IOMMU are enabled because physical address cannot be used
while the IPMMU module's MMU function is enabled.
Signed-off-by: Hideki EIRAKU <hdk@igel.co.jp>
---
arch/arm/mach-shmobile/board-ap4evb.c | 5 +++++
arch/arm/mach-shmobile/board-mackerel.c | 5 +++++
arch/arm/mach-shmobile/setup-sh7372.c | 26 ++++++++++++++++++++++++++
3 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-ap4evb.c b/arch/arm/mach-shmobile/board-ap4evb.c
index 790dc68..7006abb 100644
--- a/arch/arm/mach-shmobile/board-ap4evb.c
+++ b/arch/arm/mach-shmobile/board-ap4evb.c
@@ -61,6 +61,7 @@
#include <mach/common.h>
#include <mach/irqs.h>
#include <mach/sh7372.h>
+#include <mach/ipmmu.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -1459,6 +1460,10 @@ static void __init ap4evb_init(void)
sh7372_add_standard_devices();
+ ipmmu_add_device(&lcdc_device.dev);
+ ipmmu_add_device(&lcdc1_device.dev);
+ ipmmu_add_device(&ceu_device.dev);
+
/* HDMI */
gpio_request(GPIO_FN_HDMI_HPD, NULL);
gpio_request(GPIO_FN_HDMI_CEC, NULL);
diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c
index 0c27c81..1c34520 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -60,6 +60,7 @@
#include <mach/common.h>
#include <mach/irqs.h>
#include <mach/sh7372.h>
+#include <mach/ipmmu.h>
#include <asm/mach/arch.h>
#include <asm/mach-types.h>
@@ -1640,6 +1641,10 @@ static void __init mackerel_init(void)
sh7372_add_standard_devices();
+ ipmmu_add_device(&lcdc_device.dev);
+ ipmmu_add_device(&hdmi_lcdc_device.dev);
+ ipmmu_add_device(&ceu_device.dev);
+
platform_add_devices(mackerel_devices, ARRAY_SIZE(mackerel_devices));
rmobile_add_devices_to_domains(domain_devices,
diff --git a/arch/arm/mach-shmobile/setup-sh7372.c b/arch/arm/mach-shmobile/setup-sh7372.c
index a07954f..aadb769 100644
--- a/arch/arm/mach-shmobile/setup-sh7372.c
+++ b/arch/arm/mach-shmobile/setup-sh7372.c
@@ -38,6 +38,7 @@
#include <mach/irqs.h>
#include <mach/sh7372.h>
#include <mach/common.h>
+#include <mach/ipmmu.h>
#include <asm/mach/map.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -968,6 +969,23 @@ static struct platform_device spu1_device = {
.num_resources = ARRAY_SIZE(spu1_resources),
};
+/* IPMMUI (an IPMMU module for ICB/LMB) */
+static struct resource ipmmu_resources[] = {
+ [0] = {
+ .name = "IPMMUI",
+ .start = 0xfe951000,
+ .end = 0xfe9510ff,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device ipmmu_device = {
+ .name = "ipmmu",
+ .id = -1,
+ .resource = ipmmu_resources,
+ .num_resources = ARRAY_SIZE(ipmmu_resources),
+};
+
static struct platform_device *sh7372_early_devices[] __initdata = {
&scif0_device,
&scif1_device,
@@ -979,6 +997,7 @@ static struct platform_device *sh7372_early_devices[] __initdata = {
&cmt2_device,
&tmu00_device,
&tmu01_device,
+ &ipmmu_device,
};
static struct platform_device *sh7372_late_devices[] __initdata = {
@@ -1033,6 +1052,13 @@ void __init sh7372_add_standard_devices(void)
platform_add_devices(sh7372_early_devices,
ARRAY_SIZE(sh7372_early_devices));
+ ipmmu_add_device(&vpu_device.dev);
+ ipmmu_add_device(&jpu_device.dev);
+ ipmmu_add_device(&veu0_device.dev);
+ ipmmu_add_device(&veu1_device.dev);
+ ipmmu_add_device(&veu2_device.dev);
+ ipmmu_add_device(&veu3_device.dev);
+
platform_add_devices(sh7372_late_devices,
ARRAY_SIZE(sh7372_late_devices));
--
1.7.0.4
^ permalink raw reply related
* [PATCH v4 1/2] iommu/shmobile: Add iommu driver for Renesas IPMMU modules
From: Hideki EIRAKU @ 2012-10-15 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350290093-998-1-git-send-email-hdk@igel.co.jp>
This is the Renesas IPMMU driver and IOMMU API implementation.
The IPMMU module supports the MMU function and the PMB function. The
MMU function provides address translation by pagetable compatible with
ARMv6. The PMB function provides address translation including
tile-linear translation. This patch implements the MMU function.
The iommu driver does not register a platform driver directly because:
- the register space of the MMU function and the PMB function
have a common register (used for settings flush), so they should ideally
have a way to appropriately share this register.
- the MMU function uses the IOMMU API while the PMB function does not.
- the two functions may be used independently.
Signed-off-by: Hideki EIRAKU <hdk@igel.co.jp>
---
arch/arm/mach-shmobile/Kconfig | 6 +
arch/arm/mach-shmobile/Makefile | 3 +
arch/arm/mach-shmobile/include/mach/ipmmu.h | 16 ++
arch/arm/mach-shmobile/ipmmu.c | 150 ++++++++++++
drivers/iommu/Kconfig | 56 +++++
drivers/iommu/Makefile | 1 +
drivers/iommu/shmobile-iommu.c | 352 +++++++++++++++++++++++++++
7 files changed, 584 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-shmobile/include/mach/ipmmu.h
create mode 100644 arch/arm/mach-shmobile/ipmmu.c
create mode 100644 drivers/iommu/shmobile-iommu.c
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 8ae100c..de69ab3 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -210,6 +210,12 @@ endmenu
config SH_CLK_CPG
bool
+config SHMOBILE_IPMMU
+ bool
+
+config SHMOBILE_IPMMU_TLB
+ bool
+
source "drivers/sh/Kconfig"
endif
diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index fe2c97c..4ffba9d 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -60,3 +60,6 @@ obj-$(CONFIG_MACH_KZM9G) += board-kzm9g.o
# Framework support
obj-$(CONFIG_SMP) += $(smp-y)
obj-$(CONFIG_GENERIC_GPIO) += $(pfc-y)
+
+# IPMMU/IPMMUI
+obj-$(CONFIG_SHMOBILE_IPMMU) += ipmmu.o
diff --git a/arch/arm/mach-shmobile/include/mach/ipmmu.h b/arch/arm/mach-shmobile/include/mach/ipmmu.h
new file mode 100644
index 0000000..ede2f0b
--- /dev/null
+++ b/arch/arm/mach-shmobile/include/mach/ipmmu.h
@@ -0,0 +1,16 @@
+#ifdef CONFIG_SHMOBILE_IPMMU_TLB
+void ipmmu_tlb_flush(struct device *ipmmu_dev);
+void ipmmu_tlb_set(struct device *ipmmu_dev, unsigned long phys, int size,
+ int asid);
+void ipmmu_add_device(struct device *dev);
+int ipmmu_iommu_init(struct device *dev);
+#else
+static inline void ipmmu_add_device(struct device *dev)
+{
+}
+
+static int ipmmu_iommu_init(struct device *dev)
+{
+ return -EINVAL;
+}
+#endif
diff --git a/arch/arm/mach-shmobile/ipmmu.c b/arch/arm/mach-shmobile/ipmmu.c
new file mode 100644
index 0000000..72cacb9
--- /dev/null
+++ b/arch/arm/mach-shmobile/ipmmu.c
@@ -0,0 +1,150 @@
+/*
+ * IPMMU/IPMMUI
+ * Copyright (C) 2012 Hideki EIRAKU
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#include <linux/platform_device.h>
+#include <linux/io.h>
+#include <linux/err.h>
+#include <linux/export.h>
+#include <linux/slab.h>
+#include <mach/ipmmu.h>
+
+#define IMCTR1 0x000
+#define IMCTR2 0x004
+#define IMASID 0x010
+#define IMTTBR 0x014
+#define IMTTBCR 0x018
+
+#define IMCTR1_TLBEN (1 << 0)
+#define IMCTR1_FLUSH (1 << 1)
+
+struct ipmmu_priv {
+ void __iomem *ipmmu_base;
+ int tlb_enabled;
+ struct mutex flush_lock;
+};
+
+static void ipmmu_reg_write(struct ipmmu_priv *priv, unsigned long reg_off,
+ unsigned long data)
+{
+ iowrite32(data, priv->ipmmu_base + reg_off);
+}
+
+void ipmmu_tlb_flush(struct device *dev)
+{
+ struct ipmmu_priv *priv;
+
+ if (!dev)
+ return;
+ priv = dev_get_drvdata(dev);
+ mutex_lock(&priv->flush_lock);
+ if (priv->tlb_enabled)
+ ipmmu_reg_write(priv, IMCTR1, IMCTR1_FLUSH | IMCTR1_TLBEN);
+ else
+ ipmmu_reg_write(priv, IMCTR1, IMCTR1_FLUSH);
+ mutex_unlock(&priv->flush_lock);
+}
+
+void ipmmu_tlb_set(struct device *dev, unsigned long phys, int size, int asid)
+{
+ struct ipmmu_priv *priv;
+
+ if (!dev)
+ return;
+ priv = dev_get_drvdata(dev);
+ mutex_lock(&priv->flush_lock);
+ switch (size) {
+ default:
+ priv->tlb_enabled = 0;
+ break;
+ case 0x2000:
+ ipmmu_reg_write(priv, IMTTBCR, 1);
+ priv->tlb_enabled = 1;
+ break;
+ case 0x1000:
+ ipmmu_reg_write(priv, IMTTBCR, 2);
+ priv->tlb_enabled = 1;
+ break;
+ case 0x800:
+ ipmmu_reg_write(priv, IMTTBCR, 3);
+ priv->tlb_enabled = 1;
+ break;
+ case 0x400:
+ ipmmu_reg_write(priv, IMTTBCR, 4);
+ priv->tlb_enabled = 1;
+ break;
+ case 0x200:
+ ipmmu_reg_write(priv, IMTTBCR, 5);
+ priv->tlb_enabled = 1;
+ break;
+ case 0x100:
+ ipmmu_reg_write(priv, IMTTBCR, 6);
+ priv->tlb_enabled = 1;
+ break;
+ case 0x80:
+ ipmmu_reg_write(priv, IMTTBCR, 7);
+ priv->tlb_enabled = 1;
+ break;
+ }
+ ipmmu_reg_write(priv, IMTTBR, phys);
+ ipmmu_reg_write(priv, IMASID, asid);
+ mutex_unlock(&priv->flush_lock);
+}
+
+static int __devinit ipmmu_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ struct ipmmu_priv *priv;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(&pdev->dev, "cannot get platform resources\n");
+ return -ENOENT;
+ }
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv) {
+ dev_err(&pdev->dev, "cannot allocate device data\n");
+ return -ENOMEM;
+ }
+ mutex_init(&priv->flush_lock);
+ priv->ipmmu_base = ioremap_nocache(res->start, resource_size(res));
+ if (!priv->ipmmu_base) {
+ dev_err(&pdev->dev, "ioremap_nocache failed\n");
+ kfree(priv);
+ return -ENOMEM;
+ }
+ platform_set_drvdata(pdev, priv);
+ ipmmu_reg_write(priv, IMCTR1, 0x0); /* disable TLB */
+ ipmmu_reg_write(priv, IMCTR2, 0x0); /* disable PMB */
+ ipmmu_iommu_init(&pdev->dev);
+ return 0;
+}
+
+static struct platform_driver ipmmu_driver = {
+ .probe = ipmmu_probe,
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = "ipmmu",
+ },
+};
+
+static int __init ipmmu_init(void)
+{
+ return platform_driver_register(&ipmmu_driver);
+}
+subsys_initcall(ipmmu_init);
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index e39f9db..265829f 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -187,4 +187,60 @@ config EXYNOS_IOMMU_DEBUG
Say N unless you need kernel log message for IOMMU debugging
+config SHMOBILE_IOMMU
+ bool "IOMMU for Renesas IPMMU/IPMMUI"
+ default n
+ select IOMMU_API
+ select ARM_DMA_USE_IOMMU
+ select SHMOBILE_IPMMU
+ select SHMOBILE_IPMMU_TLB
+
+choice
+ prompt "IPMMU/IPMMUI address space size"
+ default SHMOBILE_IOMMU_ADDRSIZE_2048MB
+ depends on SHMOBILE_IOMMU
+ help
+ This option sets IPMMU/IPMMUI address space size by
+ adjusting the 1st level page table size. The page table size
+ is calculated as follows:
+
+ page table size = number of page table entries * 4 bytes
+ number of page table entries = address space size / 1 MiB
+
+ For example, when the address space size is 2048 MiB, the
+ 1st level page table size is 8192 bytes.
+
+ config SHMOBILE_IOMMU_ADDRSIZE_2048MB
+ bool "2 GiB"
+
+ config SHMOBILE_IOMMU_ADDRSIZE_1024MB
+ bool "1 GiB"
+
+ config SHMOBILE_IOMMU_ADDRSIZE_512MB
+ bool "512 MiB"
+
+ config SHMOBILE_IOMMU_ADDRSIZE_256MB
+ bool "256 MiB"
+
+ config SHMOBILE_IOMMU_ADDRSIZE_128MB
+ bool "128 MiB"
+
+ config SHMOBILE_IOMMU_ADDRSIZE_64MB
+ bool "64 MiB"
+
+ config SHMOBILE_IOMMU_ADDRSIZE_32MB
+ bool "32 MiB"
+
+endchoice
+
+config SHMOBILE_IOMMU_L1SIZE
+ int
+ default 8192 if SHMOBILE_IOMMU_ADDRSIZE_2048MB
+ default 4096 if SHMOBILE_IOMMU_ADDRSIZE_1024MB
+ default 2048 if SHMOBILE_IOMMU_ADDRSIZE_512MB
+ default 1024 if SHMOBILE_IOMMU_ADDRSIZE_256MB
+ default 512 if SHMOBILE_IOMMU_ADDRSIZE_128MB
+ default 256 if SHMOBILE_IOMMU_ADDRSIZE_64MB
+ default 128 if SHMOBILE_IOMMU_ADDRSIZE_32MB
+
endif # IOMMU_SUPPORT
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 14a4d5f..62cf917 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -12,3 +12,4 @@ 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
diff --git a/drivers/iommu/shmobile-iommu.c b/drivers/iommu/shmobile-iommu.c
new file mode 100644
index 0000000..bbbf1bc
--- /dev/null
+++ b/drivers/iommu/shmobile-iommu.c
@@ -0,0 +1,352 @@
+/*
+ * IOMMU for IPMMU/IPMMUI
+ * Copyright (C) 2012 Hideki EIRAKU
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#include <linux/io.h>
+#include <linux/dmapool.h>
+#include <linux/slab.h>
+#include <linux/platform_device.h>
+#include <linux/iommu.h>
+#include <linux/dma-mapping.h>
+#include <mach/ipmmu.h>
+#include <asm/dma-iommu.h>
+
+#define L1_SIZE CONFIG_SHMOBILE_IOMMU_L1SIZE
+#define L1_LEN (L1_SIZE / 4)
+#define L1_ALIGN L1_SIZE
+#define L2_SIZE 0x400
+#define L2_LEN (L2_SIZE / 4)
+#define L2_ALIGN L2_SIZE
+
+struct shmobile_iommu_priv_pgtable {
+ uint32_t *pgtable;
+ dma_addr_t handle;
+};
+
+struct shmobile_iommu_priv {
+ struct shmobile_iommu_priv_pgtable l1, l2[L1_LEN];
+ spinlock_t map_lock;
+ atomic_t active;
+};
+
+static struct dma_iommu_mapping *iommu_mapping;
+static struct device *ipmmu_devices;
+static struct dma_pool *l1pool, *l2pool;
+static spinlock_t lock;
+static DEFINE_SPINLOCK(lock_add);
+static struct shmobile_iommu_priv *attached;
+static int num_attached_devices;
+static struct device *ipmmu_access_device;
+
+static int shmobile_iommu_domain_init(struct iommu_domain *domain)
+{
+ struct shmobile_iommu_priv *priv;
+ int i;
+
+ priv = kmalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+ priv->l1.pgtable = dma_pool_alloc(l1pool, GFP_KERNEL,
+ &priv->l1.handle);
+ if (!priv->l1.pgtable) {
+ kfree(priv);
+ return -ENOMEM;
+ }
+ for (i = 0; i < L1_LEN; i++)
+ priv->l2[i].pgtable = NULL;
+ memset(priv->l1.pgtable, 0, L1_SIZE);
+ spin_lock_init(&priv->map_lock);
+ atomic_set(&priv->active, 0);
+ domain->priv = priv;
+ return 0;
+}
+
+static void shmobile_iommu_domain_destroy(struct iommu_domain *domain)
+{
+ struct shmobile_iommu_priv *priv = domain->priv;
+ int i;
+
+ for (i = 0; i < L1_LEN; i++) {
+ if (priv->l2[i].pgtable)
+ dma_pool_free(l2pool, priv->l2[i].pgtable,
+ priv->l2[i].handle);
+ }
+ dma_pool_free(l1pool, priv->l1.pgtable, priv->l1.handle);
+ kfree(priv);
+ domain->priv = NULL;
+}
+
+static int shmobile_iommu_attach_device(struct iommu_domain *domain,
+ struct device *dev)
+{
+ struct shmobile_iommu_priv *priv = domain->priv;
+ int ret = -EBUSY;
+
+ spin_lock(&lock);
+ if (attached != priv) {
+ if (attached)
+ goto err;
+ atomic_set(&priv->active, 1);
+ ipmmu_tlb_set(ipmmu_access_device, priv->l1.handle, L1_SIZE,
+ 0);
+ wmb();
+ ipmmu_tlb_flush(ipmmu_access_device);
+ attached = priv;
+ num_attached_devices = 0;
+ }
+ num_attached_devices++;
+ ret = 0;
+err:
+ spin_unlock(&lock);
+ return ret;
+}
+
+static void shmobile_iommu_detach_device(struct iommu_domain *domain,
+ struct device *dev)
+{
+ struct shmobile_iommu_priv *priv = domain->priv;
+
+ spin_lock(&lock);
+ atomic_set(&priv->active, 0);
+ num_attached_devices--;
+ if (!num_attached_devices) {
+ ipmmu_tlb_set(ipmmu_access_device, 0, 0, 0);
+ ipmmu_tlb_flush(ipmmu_access_device);
+ attached = NULL;
+ }
+ spin_unlock(&lock);
+}
+
+static int
+l2alloc(struct shmobile_iommu_priv *priv, unsigned int l1index)
+{
+ if (!priv->l2[l1index].pgtable) {
+ priv->l2[l1index].pgtable = dma_pool_alloc(l2pool, GFP_KERNEL,
+ &priv->l2[l1index].handle);
+ if (!priv->l2[l1index].pgtable)
+ return -ENOMEM;
+ memset(priv->l2[l1index].pgtable, 0, L2_SIZE);
+ }
+ priv->l1.pgtable[l1index] = priv->l2[l1index].handle | 0x1;
+ return 0;
+}
+
+static void
+l2realfree(struct shmobile_iommu_priv_pgtable *l2)
+{
+ if (l2->pgtable)
+ dma_pool_free(l2pool, l2->pgtable, l2->handle);
+}
+
+static int
+l2free(struct shmobile_iommu_priv *priv, unsigned int l1index,
+ struct shmobile_iommu_priv_pgtable *l2)
+{
+ priv->l1.pgtable[l1index] = 0;
+ if (priv->l2[l1index].pgtable) {
+ *l2 = priv->l2[l1index];
+ priv->l2[l1index].pgtable = NULL;
+ }
+ return 0;
+}
+
+static int shmobile_iommu_map(struct iommu_domain *domain, unsigned long iova,
+ phys_addr_t paddr, size_t size, int prot)
+{
+ struct shmobile_iommu_priv_pgtable l2 = { .pgtable = NULL };
+ struct shmobile_iommu_priv *priv = domain->priv;
+ unsigned int l1index, l2index, i;
+ int ret;
+
+ l1index = iova >> 20;
+ switch (size) {
+ case 0x1000:
+ l2index = (iova >> 12) & 0xff;
+ spin_lock(&priv->map_lock);
+ ret = l2alloc(priv, l1index);
+ if (!ret)
+ priv->l2[l1index].pgtable[l2index] = paddr | 0xff2;
+ spin_unlock(&priv->map_lock);
+ break;
+ case 0x10000:
+ l2index = (iova >> 12) & 0xf0;
+ spin_lock(&priv->map_lock);
+ ret = l2alloc(priv, l1index);
+ if (!ret) {
+ for (i = 0; i < 0x10; i++)
+ priv->l2[l1index].pgtable[l2index + i] =
+ paddr | 0xff1;
+ }
+ spin_unlock(&priv->map_lock);
+ break;
+ case 0x100000:
+ spin_lock(&priv->map_lock);
+ l2free(priv, l1index, &l2);
+ priv->l1.pgtable[l1index] = paddr | 0xc02;
+ spin_unlock(&priv->map_lock);
+ ret = 0;
+ break;
+ default:
+ ret = -EINVAL;
+ }
+ if (!ret && atomic_read(&priv->active)) {
+ wmb();
+ ipmmu_tlb_flush(ipmmu_access_device);
+ l2realfree(&l2);
+ }
+ return ret;
+}
+
+static size_t shmobile_iommu_unmap(struct iommu_domain *domain,
+ unsigned long iova, size_t size)
+{
+ struct shmobile_iommu_priv_pgtable l2 = { .pgtable = NULL };
+ struct shmobile_iommu_priv *priv = domain->priv;
+ unsigned int l1index, l2index, i;
+ uint32_t l2entry = 0;
+ size_t ret = 0;
+
+ l1index = iova >> 20;
+ if (!(iova & 0xFFFFF) && size >= 0x100000) {
+ spin_lock(&priv->map_lock);
+ l2free(priv, l1index, &l2);
+ spin_unlock(&priv->map_lock);
+ ret = 0x100000;
+ goto done;
+ }
+ l2index = (iova >> 12) & 0xff;
+ spin_lock(&priv->map_lock);
+ if (priv->l2[l1index].pgtable)
+ l2entry = priv->l2[l1index].pgtable[l2index];
+ switch (l2entry & 3) {
+ case 1:
+ if (l2index & 0xf)
+ break;
+ for (i = 0; i < 0x10; i++)
+ priv->l2[l1index].pgtable[l2index + i] = 0;
+ ret = 0x10000;
+ break;
+ case 2:
+ priv->l2[l1index].pgtable[l2index] = 0;
+ ret = 0x1000;
+ break;
+ }
+ spin_unlock(&priv->map_lock);
+done:
+ if (ret && atomic_read(&priv->active)) {
+ wmb();
+ ipmmu_tlb_flush(ipmmu_access_device);
+ l2realfree(&l2);
+ }
+ return ret;
+}
+
+static phys_addr_t shmobile_iommu_iova_to_phys(struct iommu_domain *domain,
+ unsigned long iova)
+{
+ struct shmobile_iommu_priv *priv = domain->priv;
+ uint32_t l1entry = 0, l2entry = 0;
+ unsigned int l1index, l2index;
+
+ l1index = iova >> 20;
+ l2index = (iova >> 12) & 0xff;
+ spin_lock(&priv->map_lock);
+ if (priv->l2[l1index].pgtable)
+ l2entry = priv->l2[l1index].pgtable[l2index];
+ else
+ l1entry = priv->l1.pgtable[l1index];
+ spin_unlock(&priv->map_lock);
+ switch (l2entry & 3) {
+ case 1:
+ return (l2entry & ~0xffff) | (iova & 0xffff);
+ case 2:
+ return (l2entry & ~0xfff) | (iova & 0xfff);
+ default:
+ if ((l1entry & 3) == 2)
+ return (l1entry & ~0xfffff) | (iova & 0xfffff);
+ return 0;
+ }
+}
+
+static struct iommu_ops shmobile_iommu_ops = {
+ .domain_init = shmobile_iommu_domain_init,
+ .domain_destroy = shmobile_iommu_domain_destroy,
+ .attach_dev = shmobile_iommu_attach_device,
+ .detach_dev = shmobile_iommu_detach_device,
+ .map = shmobile_iommu_map,
+ .unmap = shmobile_iommu_unmap,
+ .iova_to_phys = shmobile_iommu_iova_to_phys,
+ .pgsize_bitmap = 0x111000,
+};
+
+static int shmobile_iommu_attach_all_devices(void)
+{
+ struct device *dev;
+ int ret = 0;
+
+ spin_lock(&lock_add);
+ iommu_mapping = arm_iommu_create_mapping(&platform_bus_type, 0x0,
+ L1_LEN << 20, 0);
+ if (IS_ERR_OR_NULL(iommu_mapping)) {
+ ret = PTR_ERR(iommu_mapping);
+ goto err;
+ }
+ for (dev = ipmmu_devices; dev; dev = dev->archdata.iommu) {
+ if (arm_iommu_attach_device(dev, iommu_mapping))
+ pr_err("arm_iommu_attach_device failed\n");
+ }
+err:
+ spin_unlock(&lock_add);
+ return 0;
+}
+
+void ipmmu_add_device(struct device *dev)
+{
+ spin_lock(&lock_add);
+ dev->archdata.iommu = ipmmu_devices;
+ ipmmu_devices = dev;
+ if (!IS_ERR_OR_NULL(iommu_mapping)) {
+ if (arm_iommu_attach_device(dev, iommu_mapping))
+ pr_err("arm_iommu_attach_device failed\n");
+ }
+ spin_unlock(&lock_add);
+}
+
+int ipmmu_iommu_init(struct device *dev)
+{
+ dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
+ l1pool = dma_pool_create("shmobile-iommu-pgtable1", dev,
+ L1_SIZE, L1_ALIGN, 0);
+ if (!l1pool)
+ goto nomem_pool1;
+ l2pool = dma_pool_create("shmobile-iommu-pgtable2", dev,
+ L2_SIZE, L2_ALIGN, 0);
+ if (!l2pool)
+ goto nomem_pool2;
+ spin_lock_init(&lock);
+ attached = NULL;
+ ipmmu_access_device = dev;
+ bus_set_iommu(&platform_bus_type, &shmobile_iommu_ops);
+ if (shmobile_iommu_attach_all_devices())
+ pr_err("shmobile_iommu_attach_all_devices failed\n");
+ return 0;
+nomem_pool2:
+ dma_pool_destroy(l1pool);
+nomem_pool1:
+ return -ENOMEM;
+}
--
1.7.0.4
^ permalink raw reply related
* [PATCH v4 0/2] Renesas IPMMU driver for sh7372
From: Hideki EIRAKU @ 2012-10-15 8:34 UTC (permalink / raw)
To: linux-arm-kernel
This is the Renesas IPMMU driver, IOMMU API implementation and IPMMU
device support for sh7372 (AP4EVB and Mackerel).
The IPMMU module supports the MMU function and the PMB function. The
MMU function provides address translation by pagetable compatible with
ARMv6. The PMB function provides address translation including
tile-linear translation. This is implementation of the MMU function.
v4:
- Rebased on 3.7-rc1.
- Use address space size instead of page table size in config.
- Use Kconfig default value instead of #ifdef-#define-#endif.
v3:
- Rebased on 3.6-rc5.
- Simplify configs. SHMOBILE_IPMMU is now selected by setting
SHMOBILE_IOMMU.
- Remove weak symbols.
- Use drvdata to store private driver data.
- Make a function for writing to a register of IPMMU.
- Add a lock to accessing the tlb_enabled member.
- Make unmap work correctly with size larger than map size.
- Free L2 page table when 1MiB page is mapped or unmapped.
- Add VEU devices as IP blocks on the ICB.
v2:
- Rebased on v3.6-rc1.
- Make variable names clear.
- Page table size can now be selected by config.
Hideki EIRAKU (2):
iommu/shmobile: Add iommu driver for Renesas IPMMU modules
ARM: mach-shmobile: sh7372: Add IPMMU device
arch/arm/mach-shmobile/Kconfig | 6 +
arch/arm/mach-shmobile/Makefile | 3 +
arch/arm/mach-shmobile/board-ap4evb.c | 5 +
arch/arm/mach-shmobile/board-mackerel.c | 5 +
arch/arm/mach-shmobile/include/mach/ipmmu.h | 16 ++
arch/arm/mach-shmobile/ipmmu.c | 150 ++++++++++++
arch/arm/mach-shmobile/setup-sh7372.c | 26 ++
drivers/iommu/Kconfig | 56 +++++
drivers/iommu/Makefile | 1 +
drivers/iommu/shmobile-iommu.c | 352 +++++++++++++++++++++++++++
10 files changed, 620 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-shmobile/include/mach/ipmmu.h
create mode 100644 arch/arm/mach-shmobile/ipmmu.c
create mode 100644 drivers/iommu/shmobile-iommu.c
^ permalink raw reply
* [PATCH 4/6] ARM: S3C2410: I2C driver polling mode support
From: Heiko Stübner @ 2012-10-15 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349783332-18467-5-git-send-email-vasanthananthan@gmail.com>
Am Dienstag, 9. Oktober 2012, 13:48:50 schrieb Vasanth Ananthan:
> This patch adds polling mode support for i2c s3c-2410 driver.
> The I2C_SATAPHY controller lacks an interrupt line but the s3c-2410 driver
> is interrupt driven. Hence this support is required for functioning
> of the I2C_SATAPHY controller.
>
> Signed-off-by: Vasanth Ananthan <vasanth.a@samsung.com>
> ---
> drivers/i2c/busses/i2c-s3c2410.c | 84
> +++++++++++++++++++++++++++++--------- 1 files changed, 65 insertions(+),
> 19 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-s3c2410.c
> b/drivers/i2c/busses/i2c-s3c2410.c index 5ae3b02..699b530 100644
> --- a/drivers/i2c/busses/i2c-s3c2410.c
> +++ b/drivers/i2c/busses/i2c-s3c2410.c
[...]
> @@ -102,10 +103,14 @@ static struct platform_device_id s3c24xx_driver_ids[]
> = { };
> MODULE_DEVICE_TABLE(platform, s3c24xx_driver_ids);
>
> +static int i2c_s3c_irq_nextbyte(struct s3c24xx_i2c *i2c, unsigned long
> iicstat); +
> #ifdef CONFIG_OF
> static const struct of_device_id s3c24xx_i2c_match[] = {
> { .compatible = "samsung,s3c2410-i2c", .data = (void *)0 },
> { .compatible = "samsung,s3c2440-i2c", .data = (void *)QUIRK_S3C2440 },
> + { .compatible = "samsung,s3c2440-sataphy-i2c",
> + .data = (void *)(QUIRK_S3C2440|QUIRK_SATAPHY|QUIRK_NO_GPIO) },
> { .compatible = "samsung,s3c2440-hdmiphy-i2c",
> .data = (void *)(QUIRK_S3C2440 | QUIRK_HDMIPHY | QUIRK_NO_GPIO) },
> {},
Out of curiosity, why is it called s3c2440-sataphy-i2c when it's an exynos
specific component?
Heiko
^ permalink raw reply
* [PATCH v2] i2c: change the id to let the i2c-gpio work
From: Nicolas Ferre @ 2012-10-15 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507BC8BC.8000608@atmel.com>
On 10/15/2012 10:26 AM, Bo Shen :
> Hi Nicolas,
>
> On 10/15/2012 16:12, Nicolas Ferre wrote:
>> On 10/15/2012 04:09 AM, Bo Shen :
>>> Hi Joachim Eastwood,
>>>
>>> On 10/13/2012 1:42, Joachim Eastwood wrote:
>>>> Hi Bo Shen,
>>>>
>>>> On Fri, Oct 12, 2012 at 11:42 AM, Bo Shen <voice.shen@atmel.com> wrote:
>>>>> The i2c-gpio driver will turn the platform device ID to busnum.
>>>>> When using platfrom device ID as -1, it means dynamically assigned
>>>>> the busnum. When writing code, we need to make sure the busnum,
>>>>> and call i2c_register_board_info(int busnum, ...) to register device
>>>>> if using -1, we do not know the value of busnum.
>>>>>
>>>>> In order to solve this issue, set the platform device ID as a fix
>>>>> number
>>>>> Here using 0 to match the busnum used in i2c_regsiter_board_info().
>>>>
>>>> I have been bitten by this myself on RM9200.
>>>>
>>>>> Signed-off-by: Bo Shen <voice.shen@atmel.com>
>>>>> ---
>>>>> Change since v1
>>>>> Make the commit message more clear
>>>>> ---
>>>>> arch/arm/mach-at91/at91sam9260_devices.c | 2 +-
>>>>
>>>> This pattern exist in at91rm9200_devices.c, at91sam9261_devices.c,
>>>> at91sam9263_devices.c and at91sam9rl_devices.c you might want to fix
>>>> them as well.
>>>
>>> Thanks for your information.
>>> After I test these boards, I will send patches to fix them, while not in
>>> this patch.
>>
>> I am in favor of doing a comprehensive patch series that covers all
>> aspects of this issue:
>> - each boards
>> - both i2c-gpio and i2c-at91 cases
>
> May I need to submit this patch as a series? One patch for one board,
> and cover i2c-gpio and i2c-at91 cases.
> e.g:
> [patch 1/x] i2c: change id to let i2c-gpio work on at91rm200ek
> [patch 2/x] i2c: change id to let i2c-gpio work on at91sam9261ek
> ...
>
> or
>
> Just one patch, cover all these boards and i2c-gpio and i2c-at91?
Neither of the altenatives ;-)
I would have done:
1 for i2c-gpio covering all boards impacted
1 for i2c-at91 covering all boards impacted...
Bye,
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 3/4] ARM: AT91: Add AT91RM9200 support to DT board
From: Nicolas Ferre @ 2012-10-15 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGhQ9VyNqsU8pnMaxOEu7bkzv_LizG+d9Vw-ODW72muTPQ9Qtg@mail.gmail.com>
On 10/14/2012 06:39 PM, Joachim Eastwood :
> On Sun, Oct 14, 2012 at 4:54 PM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
>> On 19:08 Fri 12 Oct , Joachim Eastwood wrote:
>>> On Fri, Oct 12, 2012 at 6:27 PM, Jean-Christophe PLAGNIOL-VILLARD
>>> <plagnioj@jcrosoft.com> wrote:
>>>> On 17:28 Fri 12 Oct , ludovic.desroches wrote:
>>>>> Le 10/12/2012 04:22 PM, Jean-Christophe PLAGNIOL-VILLARD a ?crit :
>>>>>> On 00:05 Fri 12 Oct , Joachim Eastwood wrote:
>>>>>>> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
>>>>>>> ---
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> This patch has some potential issues.
>>>>>>> Before this patch board-dt would fail building when only AT91RM9200 was enabled because at91sam926x_timer symbol would be missing. This patch uses the at91rm9200_timer which
>>>>>>> will fail if AT91RM9200 is not enabled.
>>>>>> this need work with ot wtihout rm9200
>>>
>>> btw, to solve the build issue with board-dt in mainline now we need to
>>> add a select CONFIG_SOC_AT91SAM9 to config MACH_AT91SAM_DT.
>>>
>>>>>>>
>>>>>>> Any thoughts on solving this? As mention above this bug exists in mainline now.
>>>>>> duplicate the board-dt with one for rm9200 only
>>>>>> as rm9200 ans sam9 are 2 distict familly
>>>>>
>>>>> Why not adding a new machine descriptor for rm9200 in order to
>>>>> prevent file duplication?
>>>> because the soc are different and can only be compile if the timer is enable
>>>> and I do not want to enable the rm9200 timer on sam9 so instead of a ifdef i
>>>> the board-dt create a new board is better as we have a 50 lines file
>>>>
>>>> with different board_compat and different machine descriptor
>>>
>>> I am okey with either approach, but I would like to hear what Nicolas
>>> Ferre has to say since he is the on the one that added board-dt. It
>>> would be nice to have everything in one board DT file, but I
>>> understand your concern with the RM9200 timer.
>>>
>>> We will also bump into this again on AT91X40 I guess.
>> simple on x40 forget about it the x40 is no MMU only SoC
>>
>> so you can not enable it by default as the all other at91 are use with MMU
>>
>> I did the necessary to make the board-dt nearly empty and the same for all the
>> sam9 but the board-dt is sam9 only and need to be keeped this way
>>
>> Nico will tell you the same
>
> okay. I'll make the necessary changes to the patch set.
Well, even if did not see the advantage of a new board-dt specifically
for rm9200 (and armv4 and armv5 may share the same zImage in the
future...), I understand the fact that compiling the rm9200 timer for a
sam9 machine is a bit surprising.
So I have a pretty mixed feelings about that, but I will not go against
Jean-Christophe nor you Joachim: so continue in this path, we will be
able to merge all board-*-dt later if needed anyway...
Bye,
--
Nicolas Ferre
^ permalink raw reply
* [PATCH v2] i2c: change the id to let the i2c-gpio work
From: Bo Shen @ 2012-10-15 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507BC57B.8050607@atmel.com>
Hi Nicolas,
On 10/15/2012 16:12, Nicolas Ferre wrote:
> On 10/15/2012 04:09 AM, Bo Shen :
>> Hi Joachim Eastwood,
>>
>> On 10/13/2012 1:42, Joachim Eastwood wrote:
>>> Hi Bo Shen,
>>>
>>> On Fri, Oct 12, 2012 at 11:42 AM, Bo Shen <voice.shen@atmel.com> wrote:
>>>> The i2c-gpio driver will turn the platform device ID to busnum.
>>>> When using platfrom device ID as -1, it means dynamically assigned
>>>> the busnum. When writing code, we need to make sure the busnum,
>>>> and call i2c_register_board_info(int busnum, ...) to register device
>>>> if using -1, we do not know the value of busnum.
>>>>
>>>> In order to solve this issue, set the platform device ID as a fix number
>>>> Here using 0 to match the busnum used in i2c_regsiter_board_info().
>>>
>>> I have been bitten by this myself on RM9200.
>>>
>>>> Signed-off-by: Bo Shen <voice.shen@atmel.com>
>>>> ---
>>>> Change since v1
>>>> Make the commit message more clear
>>>> ---
>>>> arch/arm/mach-at91/at91sam9260_devices.c | 2 +-
>>>
>>> This pattern exist in at91rm9200_devices.c, at91sam9261_devices.c,
>>> at91sam9263_devices.c and at91sam9rl_devices.c you might want to fix
>>> them as well.
>>
>> Thanks for your information.
>> After I test these boards, I will send patches to fix them, while not in
>> this patch.
>
> I am in favor of doing a comprehensive patch series that covers all
> aspects of this issue:
> - each boards
> - both i2c-gpio and i2c-at91 cases
May I need to submit this patch as a series? One patch for one board,
and cover i2c-gpio and i2c-at91 cases.
e.g:
[patch 1/x] i2c: change id to let i2c-gpio work on at91rm200ek
[patch 2/x] i2c: change id to let i2c-gpio work on at91sam9261ek
...
or
Just one patch, cover all these boards and i2c-gpio and i2c-at91?
> Bye,
>
^ permalink raw reply
* [PATCH 3/4] ARM: AT91: Add AT91RM9200 support to DT board
From: Nicolas Ferre @ 2012-10-15 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121014145407.GN12801@game.jcrosoft.org>
On 10/14/2012 04:54 PM, Jean-Christophe PLAGNIOL-VILLARD :
> On 19:08 Fri 12 Oct , Joachim Eastwood wrote:
>> On Fri, Oct 12, 2012 at 6:27 PM, Jean-Christophe PLAGNIOL-VILLARD
>> <plagnioj@jcrosoft.com> wrote:
>>> On 17:28 Fri 12 Oct , ludovic.desroches wrote:
>>>> Le 10/12/2012 04:22 PM, Jean-Christophe PLAGNIOL-VILLARD a ?crit :
>>>>> On 00:05 Fri 12 Oct , Joachim Eastwood wrote:
>>>>>> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
>>>>>> ---
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> This patch has some potential issues.
>>>>>> Before this patch board-dt would fail building when only AT91RM9200 was enabled because at91sam926x_timer symbol would be missing. This patch uses the at91rm9200_timer which
>>>>>> will fail if AT91RM9200 is not enabled.
>>>>> this need work with ot wtihout rm9200
>>
>> btw, to solve the build issue with board-dt in mainline now we need to
>> add a select CONFIG_SOC_AT91SAM9 to config MACH_AT91SAM_DT.
>>
>>>>>>
>>>>>> Any thoughts on solving this? As mention above this bug exists in mainline now.
>>>>> duplicate the board-dt with one for rm9200 only
>>>>> as rm9200 ans sam9 are 2 distict familly
>>>>
>>>> Why not adding a new machine descriptor for rm9200 in order to
>>>> prevent file duplication?
>>> because the soc are different and can only be compile if the timer is enable
>>> and I do not want to enable the rm9200 timer on sam9 so instead of a ifdef i
>>> the board-dt create a new board is better as we have a 50 lines file
>>>
>>> with different board_compat and different machine descriptor
>>
>> I am okey with either approach, but I would like to hear what Nicolas
>> Ferre has to say since he is the on the one that added board-dt. It
>> would be nice to have everything in one board DT file, but I
>> understand your concern with the RM9200 timer.
>>
>> We will also bump into this again on AT91X40 I guess.
> simple on x40 forget about it the x40 is no MMU only SoC
>
> so you can not enable it by default as the all other at91 are use with MMU
>
> I did the necessary to make the board-dt nearly empty and the same for all the
> sam9 but the board-dt is sam9 only and need to be keeped this way
>
> Nico will tell you the same
Please, do not speak instead of me!
And even if I often agree with you, it is far from being automatic ;-)
Bye,
--
Nicolas Ferre
^ permalink raw reply
* [PATCH v2] i2c: change the id to let the i2c-gpio work
From: Nicolas Ferre @ 2012-10-15 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507B7066.4060802@atmel.com>
On 10/15/2012 04:09 AM, Bo Shen :
> Hi Joachim Eastwood,
>
> On 10/13/2012 1:42, Joachim Eastwood wrote:
>> Hi Bo Shen,
>>
>> On Fri, Oct 12, 2012 at 11:42 AM, Bo Shen <voice.shen@atmel.com> wrote:
>>> The i2c-gpio driver will turn the platform device ID to busnum.
>>> When using platfrom device ID as -1, it means dynamically assigned
>>> the busnum. When writing code, we need to make sure the busnum,
>>> and call i2c_register_board_info(int busnum, ...) to register device
>>> if using -1, we do not know the value of busnum.
>>>
>>> In order to solve this issue, set the platform device ID as a fix number
>>> Here using 0 to match the busnum used in i2c_regsiter_board_info().
>>
>> I have been bitten by this myself on RM9200.
>>
>>> Signed-off-by: Bo Shen <voice.shen@atmel.com>
>>> ---
>>> Change since v1
>>> Make the commit message more clear
>>> ---
>>> arch/arm/mach-at91/at91sam9260_devices.c | 2 +-
>>
>> This pattern exist in at91rm9200_devices.c, at91sam9261_devices.c,
>> at91sam9263_devices.c and at91sam9rl_devices.c you might want to fix
>> them as well.
>
> Thanks for your information.
> After I test these boards, I will send patches to fix them, while not in
> this patch.
I am in favor of doing a comprehensive patch series that covers all
aspects of this issue:
- each boards
- both i2c-gpio and i2c-at91 cases
Bye,
--
Nicolas Ferre
^ permalink raw reply
* dts: question about how to configure PIO used as i2c irq
From: Nicolas Ferre @ 2012-10-15 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121015055720.GQ12801@game.jcrosoft.org>
On 10/15/2012 07:57 AM, Jean-Christophe PLAGNIOL-VILLARD :
> On 10:53 Mon 15 Oct , Bo Shen wrote:
>> Hi All,
>> When moving atmel qt1070 linux driver with DT support. The atmel
>> qt1070 is an I2C device. I meet the following questions.
>>
>> The qt1070 DT node
>> --<--------------
>> qt1070: keyboard at 1b {
>> compatible = "atmel,qt1070";
>> reg = <0x1b>;
>> interrupt-parent = <&pioA>;
>> interrupts = <7 0x0>;
>> };
>> -->--------------
>>
>> DT will parse this node and map irq, the i2c_client->irq. This can
>> be used directly in atmel qt1070 driver. However, the PIO which used
>> as irq need configure as a PIO input. Now, we can not use
>> irq_to_gpio() function to convert irq to gpio. So, if we can not
>> configure this gpio.
>>
>> If we configure the pio in board-dt.c, I think this is not a good
>> place. For example, if the kernel image support multiplatform, while
>> on these platform, using different pio for qt1070, so this will
>> cause only one platform can use qt1070.
>>
>> So, for this question, how should I solve it? Would you please
>> give me some advice?
> I already reply you in private 4 times
Yes, but maybe it is because it was not well explained, or not developed
to the proper extend... So, please do not make these remarks: if the
conversation was private, it is not necessary to recall that here. Maybe
Voice is looking for help from someone else?
> you have only 2 choice pass the gpio and manage in c
> or configure the gpio as input in the xlate or map of the gpio drivers and the
> mux via pinctrl
Can you please develop a bit more: which xlate? How to tell the gpio
driver about the map? Can you provide an example?
Bye,
--
Nicolas Ferre
^ permalink raw reply
* dma_alloc_coherent fails in framebuffer
From: Tony Prisk @ 2012-10-15 8:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1822826.6oRYLvbneG@flatron>
On Mon, 2012-10-15 at 08:42 +0200, Tomasz Figa wrote:
> Hi Tony,
>
> On Monday 15 of October 2012 11:26:31 Tony Prisk wrote:
> > On Mon, 2012-10-15 at 09:34 +1300, Tony Prisk wrote:
> > > On Sun, 2012-10-14 at 18:28 +1300, Tony Prisk wrote:
> > > > Up until 07 Oct, drivers/video/wm8505-fb.c was working fine, but on
> > > > the
> > > > 11 Oct when I did another pull from linus all of a sudden
> > > > dma_alloc_coherent is failing to allocate the framebuffer any
> > > > longer.
> > > >
> > > > I did a quick look back and found this:
> > > >
> > > > ARM: add coherent dma ops
> > > >
> > > > arch_is_coherent is problematic as it is a global symbol. This
> > > > doesn't work for multi-platform kernels or platforms which can
> > > > support
> > > > per device coherent DMA.
> > > >
> > > > This adds arm_coherent_dma_ops to be used for devices which
> > > > connected
> > > > coherently (i.e. to the ACP port on Cortex-A9 or A15). The
> > > > arm_dma_ops
> > > > are modified at boot when arch_is_coherent is true.
> > > >
> > > > Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> > > > Cc: Russell King <linux@arm.linux.org.uk>
> > > > Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> > > > Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > > >
> > > >
> > > > This is the only patch lately that I could find (not that I would
> > > > claim
> > > > to be any good at finding things) that is related to the problem.
> > > > Could
> > > > it have caused the allocations to fail?
> > > >
> > > > Regards
> > > > Tony P
> > >
> > > Have done a bit more digging and found the cause - not Rob's patch so
> > > apologies.
> > >
> > > The cause of the regression is this patch:
> > >
> > > From f40d1e42bb988d2a26e8e111ea4c4c7bac819b7e Mon Sep 17 00:00:00 2001
> > > From: Mel Gorman <mgorman@suse.de>
> > > Date: Mon, 8 Oct 2012 16:32:36 -0700
> > > Subject: [PATCH 2/3] mm: compaction: acquire the zone->lock as late as
> > >
> > > possible
> > >
> > > Up until then, the framebuffer allocation with dma_alloc_coherent(...)
> > > was fine. From this patch onwards, allocations fail.
> > >
> > > I don't know how this patch would effect CMA allocations, but it seems
> > > to be causing the issue (or at least, it's caused an error in
> > > arch-vt8500 to become visible).
> > >
> > > Perhaps someone who understand -mm could explain the best way to
> > > troubleshoot the cause of this problem?
> > >
> > >
> > > Regards
> > > Tony P
> > >
> > >
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel at lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
> > Have done a bit more testing..
> >
> > Disabling Memory Compaction makes no difference.
> > Disabling CMA fixes/hides the problem. ?!?!?!
>
> Could you post your kernel log when it isn't working?
>
> Do you have the default CMA reserved pool in Kconfig set big enough to
> serve this allocation?
>
> I'm not sure what kind of allocation this framebuffer driver does, but if
> it needs to allocate memory from atomic context then possibly this patch
> series has something to do with it:
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/182697/focus=182699
>
> CC'ing Marek Szyprowski <m.szyprowski@samsung.com>
>
> Best regards,
> Tomasz Figa
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
I set CMA to 16MB (and also tried 32MB) in Kconfig, but it made no
difference. The framebuffer is only trying to allocate ~1.5MB via
dma_alloc_coherent().
I haven't captured a kernel log, but will do.
Thanks for the feedback.
Regards
Tony P
^ permalink raw reply
* [PATCH 1/1] MTD: atmel_nand: use devm_xxx gpio kzalloc, gpio and ioremap
From: Nicolas Ferre @ 2012-10-15 7:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350129982-12106-1-git-send-email-plagnioj@jcrosoft.com>
On 10/13/2012 02:06 PM, Jean-Christophe PLAGNIOL-VILLARD :
> this will allow to simply the error and remove path
>
> Cc: linux-mtd at lists.infradead.org
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Please also add Josh to the Cc list: he has made a great effort
supporting this driver and I guess that he is interested by this rework...
> ---
> drivers/mtd/nand/atmel_nand.c | 163 ++++++++++++++---------------------------
> 1 file changed, 54 insertions(+), 109 deletions(-)
>
> diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
> index 92623ac..2b43656 100644
> --- a/drivers/mtd/nand/atmel_nand.c
> +++ b/drivers/mtd/nand/atmel_nand.c
> @@ -364,43 +364,33 @@ static void __devinit __iomem *pmecc_get_alpha_to(struct atmel_nand_host *host)
> table_size * sizeof(int16_t);
> }
>
> -static void pmecc_data_free(struct atmel_nand_host *host)
> -{
> - kfree(host->pmecc_partial_syn);
> - kfree(host->pmecc_si);
> - kfree(host->pmecc_lmu);
> - kfree(host->pmecc_smu);
> - kfree(host->pmecc_mu);
> - kfree(host->pmecc_dmu);
> - kfree(host->pmecc_delta);
> -}
> -
> static int __devinit pmecc_data_alloc(struct atmel_nand_host *host)
> {
> const int cap = host->pmecc_corr_cap;
> + int size;
> +
> + size = (2 * cap + 1) * sizeof(int16_t);
> + host->pmecc_partial_syn = devm_kzalloc(host->dev, size, GFP_KERNEL);
> + host->pmecc_si = devm_kzalloc(host->dev, size, GFP_KERNEL);
> + host->pmecc_lmu = devm_kzalloc(host->dev,
> + (cap + 1) * sizeof(int16_t), GFP_KERNEL);
> + host->pmecc_smu = devm_kzalloc(host->dev,
> + (cap + 2) * (2 * cap + 1) * sizeof(int16_t), GFP_KERNEL);
> + size = (cap + 1) * sizeof(int);
> + host->pmecc_mu = devm_kzalloc(host->dev, size, GFP_KERNEL);
> + host->pmecc_dmu = devm_kzalloc(host->dev, size, GFP_KERNEL);
> + host->pmecc_delta = devm_kzalloc(host->dev, size, GFP_KERNEL);
> +
> + if (!host->pmecc_partial_syn ||
> + !host->pmecc_si ||
> + !host->pmecc_lmu ||
> + !host->pmecc_smu ||
> + !host->pmecc_mu ||
> + !host->pmecc_dmu ||
> + !host->pmecc_delta)
> + return -ENOMEM;
>
> - host->pmecc_partial_syn = kzalloc((2 * cap + 1) * sizeof(int16_t),
> - GFP_KERNEL);
> - host->pmecc_si = kzalloc((2 * cap + 1) * sizeof(int16_t), GFP_KERNEL);
> - host->pmecc_lmu = kzalloc((cap + 1) * sizeof(int16_t), GFP_KERNEL);
> - host->pmecc_smu = kzalloc((cap + 2) * (2 * cap + 1) * sizeof(int16_t),
> - GFP_KERNEL);
> - host->pmecc_mu = kzalloc((cap + 1) * sizeof(int), GFP_KERNEL);
> - host->pmecc_dmu = kzalloc((cap + 1) * sizeof(int), GFP_KERNEL);
> - host->pmecc_delta = kzalloc((cap + 1) * sizeof(int), GFP_KERNEL);
> -
> - if (host->pmecc_partial_syn &&
> - host->pmecc_si &&
> - host->pmecc_lmu &&
> - host->pmecc_smu &&
> - host->pmecc_mu &&
> - host->pmecc_dmu &&
> - host->pmecc_delta)
> - return 0;
> -
> - /* error happened */
> - pmecc_data_free(host);
> - return -ENOMEM;
> + return 0;
> }
>
> static void pmecc_gen_syndrome(struct mtd_info *mtd, int sector)
> @@ -923,27 +913,25 @@ static int __init atmel_pmecc_nand_init_params(struct platform_device *pdev,
> return 0;
> }
>
> - host->ecc = ioremap(regs->start, resource_size(regs));
> + host->ecc = devm_request_and_ioremap(&pdev->dev, regs);
> if (host->ecc == NULL) {
> dev_err(host->dev, "ioremap failed\n");
> err_no = -EIO;
> - goto err_pmecc_ioremap;
> + goto err;
> }
>
> regs_pmerr = platform_get_resource(pdev, IORESOURCE_MEM, 2);
> regs_rom = platform_get_resource(pdev, IORESOURCE_MEM, 3);
> if (regs_pmerr && regs_rom) {
> - host->pmerrloc_base = ioremap(regs_pmerr->start,
> - resource_size(regs_pmerr));
> - host->pmecc_rom_base = ioremap(regs_rom->start,
> - resource_size(regs_rom));
> + host->pmerrloc_base = devm_request_and_ioremap(&pdev->dev, regs_pmerr);
> + host->pmecc_rom_base = devm_request_and_ioremap(&pdev->dev, regs_rom);
> }
>
> if (!host->pmerrloc_base || !host->pmecc_rom_base) {
> dev_err(host->dev,
> "Can not get I/O resource for PMECC ERRLOC controller or ROM!\n");
> err_no = -EIO;
> - goto err_pmloc_ioremap;
> + goto err;
> }
>
> /* ECC is calculated for the whole page (1 step) */
> @@ -968,7 +956,7 @@ static int __init atmel_pmecc_nand_init_params(struct platform_device *pdev,
> if (nand_chip->ecc.bytes > mtd->oobsize - 2) {
> dev_err(host->dev, "No room for ECC bytes\n");
> err_no = -EINVAL;
> - goto err_no_ecc_room;
> + goto err;
> }
> pmecc_config_ecc_layout(&atmel_pmecc_oobinfo,
> mtd->oobsize,
> @@ -993,7 +981,7 @@ static int __init atmel_pmecc_nand_init_params(struct platform_device *pdev,
> if (err_no) {
> dev_err(host->dev,
> "Cannot allocate memory for PMECC computation!\n");
> - goto err_pmecc_data_alloc;
> + goto err;
> }
>
> nand_chip->ecc.read_page = atmel_nand_pmecc_read_page;
> @@ -1003,15 +991,7 @@ static int __init atmel_pmecc_nand_init_params(struct platform_device *pdev,
>
> return 0;
>
> -err_pmecc_data_alloc:
> -err_no_ecc_room:
> -err_pmloc_ioremap:
> - iounmap(host->ecc);
> - if (host->pmerrloc_base)
> - iounmap(host->pmerrloc_base);
> - if (host->pmecc_rom_base)
> - iounmap(host->pmecc_rom_base);
> -err_pmecc_ioremap:
> +err:
> return err_no;
> }
>
> @@ -1315,7 +1295,7 @@ static int __init atmel_hw_nand_init_params(struct platform_device *pdev,
> return 0;
> }
>
> - host->ecc = ioremap(regs->start, resource_size(regs));
> + host->ecc = devm_request_and_ioremap(&pdev->dev, regs);
> if (host->ecc == NULL) {
> dev_err(host->dev, "ioremap failed\n");
> return -EIO;
> @@ -1380,20 +1360,19 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
> }
>
> /* Allocate memory for the device structure (and zero it) */
> - host = kzalloc(sizeof(struct atmel_nand_host), GFP_KERNEL);
> + host = devm_kzalloc(&pdev->dev, sizeof(*host), GFP_KERNEL);
> if (!host) {
> printk(KERN_ERR "atmel_nand: failed to allocate device structure.\n");
> return -ENOMEM;
> }
>
> - host->io_phys = (dma_addr_t)mem->start;
> -
> - host->io_base = ioremap(mem->start, resource_size(mem));
> + host->io_base = devm_request_and_ioremap(&pdev->dev, mem);
> if (host->io_base == NULL) {
> printk(KERN_ERR "atmel_nand: ioremap failed\n");
> res = -EIO;
> goto err_nand_ioremap;
> }
> + host->io_phys = (dma_addr_t)mem->start;
>
> mtd = &host->mtd;
> nand_chip = &host->nand_chip;
> @@ -1401,7 +1380,7 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
> if (pdev->dev.of_node) {
> res = atmel_of_init_port(host, pdev->dev.of_node);
> if (res)
> - goto err_ecc_ioremap;
> + goto err_nand_ioremap;
> } else {
> memcpy(&host->board, pdev->dev.platform_data,
> sizeof(struct atmel_nand_data));
> @@ -1420,44 +1399,42 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
> if (IS_ERR(pinctrl)) {
> dev_err(host->dev, "Failed to request pinctrl\n");
> res = PTR_ERR(pinctrl);
> - goto err_ecc_ioremap;
> + goto err_nand_ioremap;
> }
>
> if (gpio_is_valid(host->board.rdy_pin)) {
> - res = gpio_request(host->board.rdy_pin, "nand_rdy");
> + res = devm_gpio_request(&pdev->dev,
> + host->board.rdy_pin, "nand_rdy");
> if (res < 0) {
> dev_err(&pdev->dev,
> - "can't request rdy gpio %d\n",
> - host->board.rdy_pin);
> - goto err_ecc_ioremap;
> + "can't request rdy gpio %d\n", host->board.rdy_pin);
> + goto err_nand_ioremap;
> }
>
> res = gpio_direction_input(host->board.rdy_pin);
> if (res < 0) {
> dev_err(&pdev->dev,
> - "can't request input direction rdy gpio %d\n",
> - host->board.rdy_pin);
> - goto err_ecc_ioremap;
> + "can't request input direction rdy gpio %d\n", host->board.rdy_pin);
Why do you modify the log message presentation: it was okay before?
Moreover, it is not related to the topic of the patch...
> + goto err_nand_ioremap;
> }
>
> nand_chip->dev_ready = atmel_nand_device_ready;
> }
>
> if (gpio_is_valid(host->board.enable_pin)) {
> - res = gpio_request(host->board.enable_pin, "nand_enable");
> + res = devm_gpio_request(&pdev->dev,
> + host->board.enable_pin, "nand_enable");
> if (res < 0) {
> dev_err(&pdev->dev,
> - "can't request enable gpio %d\n",
> - host->board.enable_pin);
> - goto err_ecc_ioremap;
> + "can't request enable gpio %d\n", host->board.enable_pin);
Ditto.
> + goto err_nand_ioremap;
> }
>
> res = gpio_direction_output(host->board.enable_pin, 1);
> if (res < 0) {
> dev_err(&pdev->dev,
> - "can't request output direction enable gpio %d\n",
> - host->board.enable_pin);
> - goto err_ecc_ioremap;
> + "can't request output direction enable gpio %d\n", host->board.enable_pin);
Ditto.
> + goto err_nand_ioremap;
> }
> }
>
> @@ -1474,19 +1451,18 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
> atmel_nand_enable(host);
>
> if (gpio_is_valid(host->board.det_pin)) {
> - res = gpio_request(host->board.det_pin, "nand_det");
> + res = devm_gpio_request(&pdev->dev,
> + host->board.det_pin, "nand_det");
> if (res < 0) {
> dev_err(&pdev->dev,
> - "can't request det gpio %d\n",
> - host->board.det_pin);
> + "can't request det gpio %d\n", host->board.det_pin);
Ditto.
> goto err_no_card;
> }
>
> res = gpio_direction_input(host->board.det_pin);
> if (res < 0) {
> dev_err(&pdev->dev,
> - "can't request input direction det gpio %d\n",
> - host->board.det_pin);
> + "can't request input direction det gpio %d\n", host->board.det_pin);
Ditto.
> goto err_no_card;
> }
>
> @@ -1552,16 +1528,8 @@ static int __init atmel_nand_probe(struct platform_device *pdev)
> return res;
>
> err_scan_tail:
> - if (host->has_pmecc && host->nand_chip.ecc.mode == NAND_ECC_HW) {
> + if (host->has_pmecc && host->nand_chip.ecc.mode == NAND_ECC_HW)
> pmecc_writel(host->ecc, CTRL, PMECC_CTRL_DISABLE);
> - pmecc_data_free(host);
> - }
> - if (host->ecc)
> - iounmap(host->ecc);
> - if (host->pmerrloc_base)
> - iounmap(host->pmerrloc_base);
> - if (host->pmecc_rom_base)
> - iounmap(host->pmecc_rom_base);
> err_hw_ecc:
> err_scan_ident:
> err_no_card:
> @@ -1569,10 +1537,7 @@ err_no_card:
> platform_set_drvdata(pdev, NULL);
> if (host->dma_chan)
> dma_release_channel(host->dma_chan);
> -err_ecc_ioremap:
> - iounmap(host->io_base);
> err_nand_ioremap:
> - kfree(host);
> return res;
> }
>
> @@ -1592,31 +1557,11 @@ static int __exit atmel_nand_remove(struct platform_device *pdev)
> pmecc_writel(host->ecc, CTRL, PMECC_CTRL_DISABLE);
> pmerrloc_writel(host->pmerrloc_base, ELDIS,
> PMERRLOC_DISABLE);
> - pmecc_data_free(host);
> }
>
> - if (gpio_is_valid(host->board.det_pin))
> - gpio_free(host->board.det_pin);
> -
> - if (gpio_is_valid(host->board.enable_pin))
> - gpio_free(host->board.enable_pin);
> -
> - if (gpio_is_valid(host->board.rdy_pin))
> - gpio_free(host->board.rdy_pin);
> -
> - if (host->ecc)
> - iounmap(host->ecc);
> - if (host->pmecc_rom_base)
> - iounmap(host->pmecc_rom_base);
> - if (host->pmerrloc_base)
> - iounmap(host->pmerrloc_base);
> -
> if (host->dma_chan)
> dma_release_channel(host->dma_chan);
>
> - iounmap(host->io_base);
> - kfree(host);
> -
> return 0;
> }
Otherwise, looks good.
Bye,
--
Nicolas Ferre
^ permalink raw reply
* [PATCH 7/7] ARM: tegra30: cpuidle: add LP2 driver for CPU0
From: Joseph Lo @ 2012-10-15 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507885D4.10604@wwwdotorg.org>
On Sat, 2012-10-13 at 05:04 +0800, Stephen Warren wrote:
> On 10/12/2012 01:07 AM, Joseph Lo wrote:
> > On Fri, 2012-10-12 at 00:37 +0800, Stephen Warren wrote:
> >> On 10/11/2012 05:24 AM, Joseph Lo wrote:
> >>> On Wed, 2012-10-10 at 06:49 +0800, Stephen Warren wrote:
> >>>> On 10/08/2012 04:26 AM, Joseph Lo wrote:
> >>>>> The cpuidle LP2 is a power gating idle mode. It support power gating
> >>>>> vdd_cpu rail after all cpu cores in LP2. For Tegra30, the CPU0 must
> >>>>> be last one to go into LP2. We need to take care and make sure whole
> >>>>> secondary CPUs were in LP2 by checking CPU and power gate status.
> >>>>> After that, the CPU0 can go into LP2 safely. Then power gating the
> >>>>> CPU rail.
> >>>>
> >>>>> diff --git a/arch/arm/mach-tegra/cpuidle-tegra30.c b/arch/arm/mach-tegra/cpuidle-tegra30.c
> >> b) If CPUn can't trigger rail-gating, then when CPUn is the last to
> >> enter LP2 of the whole complex, it needs to IPI to CPU0 to tell it to
> >> rail-gate, and simply power-gate itself. I believe this IPI interaction
> >> is exactly what coupled cpuidle is about, isn't it?
> >
> > Yes, indeed. Actually, I had tried the coupled cpuidle on Tegra20. I
> > knew it a lot. But I met issues when porting it. It looks like a race
> > condition and becomes a dead lock caused by IPI missing. Anyway, we can
> > talk about it more detail when I try to upstream the coupled cpuidle
> > support for Tegra later.
>
> Hmm. That sounds a little churny. Why can't we just use coupled cpuidle
> right from the start if the plan is to use it eventually anyway? From
> other comments, it sounds like you even already have the code basically
> working, but just need to iron out a bug or two?
Stephen,
Even though we have plan to use coupled cpuidle, I still prefer to go
with the LP2 driver first. Then adding one more patch to support coupled
cpuidle based on LP2 driver. This is good for history. And if there is
any issue, it's more easy to roll back to the stable one.
There is still one thing you should know. Because we are planning to
upstream "CPUquiet" framework that is a CPU auto hotplug mechanism. It
will auto hotplug the CPUs depends on the system is busy or not. So when
system is idle, there will be only one CPU online (i.e, CPU0). The
secondary CPUs will all be hot plugged (i.e, offline and power gate). We
need to think about do we still need coupled cpuidle on Tegra30 if we
are going to use "CPUquiet".
And Yes, I already had a work version on Tegra20 but I need to iron out
the IPI missing issue first. The LP2 driver of Tegra20 also not yet be
upstreamed.
Thanks,
Joseph
^ permalink raw reply
* [PATCH v2] i2c: i2c-gpio: fix name issue when i2c gpio node GT 1
From: Bo Shen @ 2012-10-15 7:51 UTC (permalink / raw)
To: linux-arm-kernel
When i2c-gpio node number is greater than 1, the name for each is same
So add the patch to fix it.
The adap->name printing information is add by myself
without this patch the log information is as following
---<8---
adap->name = i2c-gpio-1
i2c-gpio i2c.2: using pins 30 (SDA) and 31 (SCL)
adap->name = i2c-gpio-1
i2c-gpio i2c.3: using pins 64 (SDA) and 65 (SCL)
--->8---
with this patch, the log information is as following
---<8---
adap->name = i2c.2
i2c-gpio i2c.2: using pins 30 (SDA) and 31 (SCL)
adap->name = i2c.3
i2c-gpio i2c.3: using pins 64 (SDA) and 65 (SCL)
--->8---
Signed-off-by: Bo Shen <voice.shen@atmel.com>
---
drivers/i2c/busses/i2c-gpio.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
index e62d2d9..257299a 100644
--- a/drivers/i2c/busses/i2c-gpio.c
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -184,7 +184,11 @@ static int __devinit i2c_gpio_probe(struct platform_device *pdev)
bit_data->data = pdata;
adap->owner = THIS_MODULE;
- snprintf(adap->name, sizeof(adap->name), "i2c-gpio%d", pdev->id);
+ if (pdev->dev.of_node)
+ strlcpy(adap->name, dev_name(&pdev->dev), sizeof(adap->name));
+ else
+ snprintf(adap->name, sizeof(adap->name), "i2c-gpio%d", pdev->id);
+
adap->algo_data = bit_data;
adap->class = I2C_CLASS_HWMON | I2C_CLASS_SPD;
adap->dev.parent = &pdev->dev;
--
1.7.9.5
^ permalink raw reply related
* [PATCH V2 2/3] dmaengine: dw_dmac: Enhance device tree support
From: Andy Shevchenko @ 2012-10-15 7:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpo=20mwje+9AVgs7b-_DshyRO2DZ=Nacjm7vFAhed=Wkqg@mail.gmail.com>
On Mon, 2012-10-15 at 08:59 +0530, Viresh Kumar wrote:
> On 12 October 2012 20:28, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >> + if (last_dw) {
> >> + if ((last_bus_id == param) && (last_dw == dw))
> >> + return false;
> >> + }
> > Just came to my mind.
> > dw can't be NULL, can't it?
> > Then
> > if (last_dw) {
> > ...
> > }
> > is unneeded.
>
> Fixup for this:
>
> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> index d72c26f..764c159 100644
> --- a/drivers/dma/dw_dmac.c
> +++ b/drivers/dma/dw_dmac.c
> @@ -1196,11 +1196,8 @@ bool dw_dma_generic_filter(struct dma_chan
> *chan, void *param)
> * failure. If dw and param are same, i.e. trying on same dw with
> * different channel, return false.
> */
> - if (last_dw) {
> - if ((last_bus_id == param) && (last_dw == dw))
> - return false;
> - }
> -
> + if ((last_dw == dw) && (last_bus_id == param))
> + return false;
> /*
> * Return true:
> * - If dw_dma's platform data is not filled with slave info, then all
Good.
So, have my
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
for this patch.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH] i2c: i2c-gpio: fix issue when DT node greater than 1
From: Bo Shen @ 2012-10-15 7:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121015084920.75d4aa53@endymion.delvare>
Hi Jean Delvare,
On 10/15/2012 14:49, Jean Delvare wrote:
> On Mon, 15 Oct 2012 10:59:19 +0800, Bo Shen wrote:
>> On 10/10/2012 10:54, Bo Shen wrote:
>>> On 9/19/2012 23:54, Jean Delvare wrote:
>>>> On Wed, 19 Sep 2012 09:28:04 -0600, Stephen Warren wrote:
>>>>> The problematic code appears to be:
>>>>>
>>>>> snprintf(adap->name, sizeof(adap->name), "i2c-gpio%d", pdev->id);
>>>>>
>>>>> Instead, I think that should be something more like:
>>>>>
>>>>> adap->name = dev_name(&pdev->dev);
>>>>
>>>> strlcpy(adap->name, dev_name(&pdev->dev), sizeof(adap->name))
>> >> if anything, as adap->name is a buffer, not a pointer.
>>>
>>> I am sorry for late. I have tested with DT, it works.
>>>
>>> Please send this patch to fix the issue.
>>> Thanks.
>>
>> Ping?
>>
>> Will you send this patch?
>
> Which patch, please? On September 18th, you sent a first version.
> Stephen Warren asked you for a change, but you never sent version two
> of the patch including the requested change. So don't be surprised if
> your patch never got applied.
>
I am sorry. I take a long vacation, so, I didnot send out version two.
>> Or, I send this patch and add your S.O.B, which do you prefer?
>
> I prefer that you send patch v2 and let the interested parties review
> and apply it. Do not add S-o-B for anyone else, ever.
OK. I will send out v2 as soon as possible.
>
> Note that i2c-gpio is normally handled by Wolfram Sang, not me.
Thanks for your information.
BRs,
Bo Shen
^ permalink raw reply
* [PATCH] i2c: omap: revert "i2c: omap: switch to threaded IRQ support"
From: Felipe Balbi @ 2012-10-15 7:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210150148080.16624@utopia.booyaka.com>
Hi,
On Mon, Oct 15, 2012 at 01:51:08AM +0000, Paul Walmsley wrote:
>
> Commit 3b2f8f82dad7d1f79cdc8fc05bd1c94baf109bde ("i2c: omap: switch to
> threaded IRQ support") causes communication with I2C devices to fail
> after system suspend/resume on all OMAP3 devices:
>
> ...
> [ 40.228576] PM: noirq resume of devices complete after 3.723 msecs
> [ 40.233184] PM: early resume of devices complete after 3.173 msecs
> [ 40.242736] [sched_delayed] sched: RT throttling activated
> [ 41.235046] omap_i2c omap_i2c.1: controller timed out
instead of just reverting the patch, I'd rather try to figure out why
controller times out in that situation.
It should make no difference if you're running an IRQ thread or not.
Do you have any extra debugging information which might help figuring
out what the issue really is ?
If the thread is actually at fault, then we need to add IRQF_NO_THREAD
to the IRQ flags, otherwise same issue will appear if we boot with
"threadirqs" kernel parameter.
> [ 41.235351] twl: i2c_read failed to transfer all messages
> [ 41.235382] omap_hsmmc omap_hsmmc.0: could not set regulator OCR (-110)
> [ 41.396453] mmc0: error -110 during resume (card was removed?)
> [ 42.391754] omap_i2c omap_i2c.1: controller timed out
> [ 42.391876] twl: i2c_write failed to transfer all messages
> [ 42.391906] twl_rtc: Could not write TWLregister F - error -110
> [ 43.391326] omap_i2c omap_i2c.1: controller timed out
> [ 43.391479] twl: i2c_read failed to transfer all messages
> [ 43.391510] twl_rtc: Could not read TWLregister D - error -110
> [ 43.391540] twl_rtc twl_rtc: twl_rtc_read_time: reading CTRL_REG, error -110
> [ 43.392364] PM: resume of devices complete after 3158.935 msecs
>
> When the root filesystem is on MMC, as in the above example, the
> card's voltage regulator is not re-enabled and the filesystem becomes
> inaccessible after resume.
but it fails because I2C times out and I'd like to understand why,
before just reverting the patch.
> Fix by reverting the conversion to a threaded IRQ handler.
>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> Cc: Felipe Balbi <balbi@ti.com>
> Cc: Shubhrajyoti D <shubhrajyoti@ti.com>
> Cc: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Ben Dooks <ben-linux@fluff.org>
> ---
> drivers/i2c/busses/i2c-omap.c | 44 +++++++----------------------------------
> 1 file changed, 7 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index db31eae..e001c2a 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -180,7 +180,6 @@ enum {
> #define I2C_OMAP_ERRATA_I462 (1 << 1)
>
> struct omap_i2c_dev {
> - spinlock_t lock; /* IRQ synchronization */
> struct device *dev;
> void __iomem *base; /* virtual */
> int irq;
> @@ -865,35 +864,13 @@ static int omap_i2c_transmit_data(struct omap_i2c_dev *dev, u8 num_bytes,
> }
>
> static irqreturn_t
> -omap_i2c_isr(int irq, void *dev_id)
> +omap_i2c_isr(int this_irq, void *dev_id)
> {
> struct omap_i2c_dev *dev = dev_id;
> - irqreturn_t ret = IRQ_HANDLED;
> - u16 mask;
> - u16 stat;
> -
> - spin_lock(&dev->lock);
> - mask = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
> - stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
> -
> - if (stat & mask)
> - ret = IRQ_WAKE_THREAD;
> -
> - spin_unlock(&dev->lock);
> -
> - return ret;
> -}
> -
> -static irqreturn_t
> -omap_i2c_isr_thread(int this_irq, void *dev_id)
> -{
> - struct omap_i2c_dev *dev = dev_id;
> - unsigned long flags;
> u16 bits;
> u16 stat;
> int err = 0, count = 0;
>
> - spin_lock_irqsave(&dev->lock, flags);
> do {
> bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
> stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
> @@ -907,7 +884,7 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
>
> if (!stat) {
> /* my work here is done */
> - goto out;
> + return IRQ_HANDLED;
> }
>
> dev_dbg(dev->dev, "IRQ (ISR = 0x%04x)\n", stat);
> @@ -1016,8 +993,6 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
> omap_i2c_complete_cmd(dev, err);
>
> out:
> - spin_unlock_irqrestore(&dev->lock, flags);
> -
> return IRQ_HANDLED;
> }
>
> @@ -1062,6 +1037,7 @@ omap_i2c_probe(struct platform_device *pdev)
> pdev->dev.platform_data;
> struct device_node *node = pdev->dev.of_node;
> const struct of_device_id *match;
> + irq_handler_t isr;
> int irq;
> int r;
>
> @@ -1110,8 +1086,6 @@ omap_i2c_probe(struct platform_device *pdev)
> dev->dev = &pdev->dev;
> dev->irq = irq;
>
> - spin_lock_init(&dev->lock);
> -
> platform_set_drvdata(pdev, dev);
> init_completion(&dev->cmd_complete);
>
> @@ -1166,14 +1140,10 @@ omap_i2c_probe(struct platform_device *pdev)
> /* reset ASAP, clearing any IRQs */
> omap_i2c_init(dev);
>
> - if (dev->rev < OMAP_I2C_OMAP1_REV_2)
> - r = devm_request_irq(&pdev->dev, dev->irq, omap_i2c_omap1_isr,
> - IRQF_NO_SUSPEND, pdev->name, dev);
> - else
> - r = devm_request_threaded_irq(&pdev->dev, dev->irq,
> - omap_i2c_isr, omap_i2c_isr_thread,
> - IRQF_NO_SUSPEND | IRQF_ONESHOT,
> - pdev->name, dev);
> + isr = (dev->rev < OMAP_I2C_OMAP1_REV_2) ? omap_i2c_omap1_isr :
> + omap_i2c_isr;
> + r = devm_request_irq(&pdev->dev, dev->irq, isr, IRQF_NO_SUSPEND,
> + pdev->name, dev);
>
> if (r) {
> dev_err(dev->dev, "failure requesting irq %i\n", dev->irq);
> --
> 1.7.10.4
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121015/ccf946a3/attachment-0001.sig>
^ permalink raw reply
* [PATCH 1/5] ARM: AT91: Fix build failure on board-dt
From: Joachim Eastwood @ 2012-10-15 7:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121015055941.GS12801@game.jcrosoft.org>
On Mon, Oct 15, 2012 at 7:59 AM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> On 23:46 Sun 14 Oct , Joachim Eastwood wrote:
>> We need CONFIG_SOC_AT91SAM9 to get the at91sam926x_timer
>> symbol used in board-dt.
> as I said before you can not do a select you need to do a depends
>
> as you will have no clock as you select no SoC
Yes, the board-dt will not boot without a SoC.
Changing it to depend will hide board-dt until you choose a SoC I
assume this is the behavior we want then.
I'll change both patches to use depend in Kconfig.
regards
Joachim Eastwood
> Best Regards,
> J.
^ permalink raw reply
* [PATCH 5/5] ARM: AT91: Add AT91RM9200 device tree
From: Joachim Eastwood @ 2012-10-15 7:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121015060302.GT12801@game.jcrosoft.org>
On Mon, Oct 15, 2012 at 8:03 AM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
<snip patch>
> I do not yet check the pin I'll do it later
>
> but look ok
>
> please a board so we can test it the rm9200ek at least
I can add it, but I don't have any of the Atmel RM9200 dev kits so I
can't test it.
The testing I have done so far has been with a custom board which I'll
add later as noted in the series description.
regards
Joachim Eastwood
> Best Regards,
> J.
^ permalink raw reply
* [PATCH] i2c: i2c-gpio: fix issue when DT node greater than 1
From: Jean Delvare @ 2012-10-15 6:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507B7C07.3070702@atmel.com>
On Mon, 15 Oct 2012 10:59:19 +0800, Bo Shen wrote:
> On 10/10/2012 10:54, Bo Shen wrote:
> > On 9/19/2012 23:54, Jean Delvare wrote:
> >> On Wed, 19 Sep 2012 09:28:04 -0600, Stephen Warren wrote:
> >>> The problematic code appears to be:
> >>>
> >>> snprintf(adap->name, sizeof(adap->name), "i2c-gpio%d", pdev->id);
> >>>
> >>> Instead, I think that should be something more like:
> >>>
> >>> adap->name = dev_name(&pdev->dev);
> >>
> >> strlcpy(adap->name, dev_name(&pdev->dev), sizeof(adap->name))
> >> if anything, as adap->name is a buffer, not a pointer.
> >
> > I am sorry for late. I have tested with DT, it works.
> >
> > Please send this patch to fix the issue.
> > Thanks.
>
> Ping?
>
> Will you send this patch?
Which patch, please? On September 18th, you sent a first version.
Stephen Warren asked you for a change, but you never sent version two
of the patch including the requested change. So don't be surprised if
your patch never got applied.
> Or, I send this patch and add your S.O.B, which do you prefer?
I prefer that you send patch v2 and let the interested parties review
and apply it. Do not add S-o-B for anyone else, ever.
Note that i2c-gpio is normally handled by Wolfram Sang, not me.
--
Jean Delvare
^ permalink raw reply
* dma_alloc_coherent fails in framebuffer
From: Tomasz Figa @ 2012-10-15 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350253591.13440.1.camel@gitbox>
Hi Tony,
On Monday 15 of October 2012 11:26:31 Tony Prisk wrote:
> On Mon, 2012-10-15 at 09:34 +1300, Tony Prisk wrote:
> > On Sun, 2012-10-14 at 18:28 +1300, Tony Prisk wrote:
> > > Up until 07 Oct, drivers/video/wm8505-fb.c was working fine, but on
> > > the
> > > 11 Oct when I did another pull from linus all of a sudden
> > > dma_alloc_coherent is failing to allocate the framebuffer any
> > > longer.
> > >
> > > I did a quick look back and found this:
> > >
> > > ARM: add coherent dma ops
> > >
> > > arch_is_coherent is problematic as it is a global symbol. This
> > > doesn't work for multi-platform kernels or platforms which can
> > > support
> > > per device coherent DMA.
> > >
> > > This adds arm_coherent_dma_ops to be used for devices which
> > > connected
> > > coherently (i.e. to the ACP port on Cortex-A9 or A15). The
> > > arm_dma_ops
> > > are modified at boot when arch_is_coherent is true.
> > >
> > > Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> > > Cc: Russell King <linux@arm.linux.org.uk>
> > > Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> > > Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > >
> > >
> > > This is the only patch lately that I could find (not that I would
> > > claim
> > > to be any good at finding things) that is related to the problem.
> > > Could
> > > it have caused the allocations to fail?
> > >
> > > Regards
> > > Tony P
> >
> > Have done a bit more digging and found the cause - not Rob's patch so
> > apologies.
> >
> > The cause of the regression is this patch:
> >
> > From f40d1e42bb988d2a26e8e111ea4c4c7bac819b7e Mon Sep 17 00:00:00 2001
> > From: Mel Gorman <mgorman@suse.de>
> > Date: Mon, 8 Oct 2012 16:32:36 -0700
> > Subject: [PATCH 2/3] mm: compaction: acquire the zone->lock as late as
> >
> > possible
> >
> > Up until then, the framebuffer allocation with dma_alloc_coherent(...)
> > was fine. From this patch onwards, allocations fail.
> >
> > I don't know how this patch would effect CMA allocations, but it seems
> > to be causing the issue (or at least, it's caused an error in
> > arch-vt8500 to become visible).
> >
> > Perhaps someone who understand -mm could explain the best way to
> > troubleshoot the cause of this problem?
> >
> >
> > Regards
> > Tony P
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> Have done a bit more testing..
>
> Disabling Memory Compaction makes no difference.
> Disabling CMA fixes/hides the problem. ?!?!?!
Could you post your kernel log when it isn't working?
Do you have the default CMA reserved pool in Kconfig set big enough to
serve this allocation?
I'm not sure what kind of allocation this framebuffer driver does, but if
it needs to allocate memory from atomic context then possibly this patch
series has something to do with it:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/182697/focus=182699
CC'ing Marek Szyprowski <m.szyprowski@samsung.com>
Best regards,
Tomasz Figa
^ permalink raw reply
* [PATCH v2] i2c: change the id to let the i2c-gpio work
From: ludovic.desroches @ 2012-10-15 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507B7066.4060802@atmel.com>
Le 10/15/2012 04:09 AM, Bo Shen a ?crit :
> Hi Joachim Eastwood,
>
> On 10/13/2012 1:42, Joachim Eastwood wrote:
>> Hi Bo Shen,
>>
>> On Fri, Oct 12, 2012 at 11:42 AM, Bo Shen <voice.shen@atmel.com> wrote:
>>> The i2c-gpio driver will turn the platform device ID to busnum.
>>> When using platfrom device ID as -1, it means dynamically assigned
>>> the busnum. When writing code, we need to make sure the busnum,
>>> and call i2c_register_board_info(int busnum, ...) to register device
>>> if using -1, we do not know the value of busnum.
>>>
>>> In order to solve this issue, set the platform device ID as a fix number
>>> Here using 0 to match the busnum used in i2c_regsiter_board_info().
>>
>> I have been bitten by this myself on RM9200.
>>
>>> Signed-off-by: Bo Shen <voice.shen@atmel.com>
>>> ---
>>> Change since v1
>>> Make the commit message more clear
>>> ---
>>> arch/arm/mach-at91/at91sam9260_devices.c | 2 +-
>>
>> This pattern exist in at91rm9200_devices.c, at91sam9261_devices.c,
>> at91sam9263_devices.c and at91sam9rl_devices.c you might want to fix
>> them as well.
>
> Thanks for your information.
> After I test these boards, I will send patches to fix them, while not in
> this patch.
>
>>
>> I assume we have the same problem if CONFIG_I2C_AT91 is set?
>> See further down in at91sam9260_devices.c we have another: ".id = -1,"
>
> Maybe Nikolaus Voss will deal with this case.
>
Yes the problem is the same, I have encountered it and solved it in the
same way but I was thinking there was a better way to correct it than
removing dynamic id assignment.
Since setting the id to a fix value is acceptable this change can be
done also when using i2c-at91.
>>
>> regards
>> Joachim Eastwood
>>
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/mach-at91/at91sam9260_devices.c
>>> b/arch/arm/mach-at91/at91sam9260_devices.c
>>> index 0f24cfb..805ef95 100644
>>> --- a/arch/arm/mach-at91/at91sam9260_devices.c
>>> +++ b/arch/arm/mach-at91/at91sam9260_devices.c
>>> @@ -389,7 +389,7 @@ static struct i2c_gpio_platform_data pdata = {
>>>
>>> static struct platform_device at91sam9260_twi_device = {
>>> .name = "i2c-gpio",
>>> - .id = -1,
>>> + .id = 0,
>>> .dev.platform_data = &pdata,
>>> };
>>>
>>> --
>>> 1.7.9.5
>>>
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* [PATCH 4/5] ARM: AT91: Add AT91RM9200 DT board
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-15 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350251199-28065-5-git-send-email-manabian@gmail.com>
On 23:46 Sun 14 Oct , Joachim Eastwood wrote:
> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
> ---
> arch/arm/mach-at91/Kconfig | 8 +++++
> arch/arm/mach-at91/Makefile | 1 +
> arch/arm/mach-at91/board-rm9200-dt.c | 59 ++++++++++++++++++++++++++++++++++++
> arch/arm/mach-at91/generic.h | 1 +
> arch/arm/mach-at91/setup.c | 14 +++++++++
> 5 files changed, 83 insertions(+)
> create mode 100644 arch/arm/mach-at91/board-rm9200-dt.c
>
> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
> index d9b0546..3f45906 100644
> --- a/arch/arm/mach-at91/Kconfig
> +++ b/arch/arm/mach-at91/Kconfig
> @@ -505,6 +505,14 @@ endif
>
> comment "Generic Board Type"
>
> +config MACH_AT91RM9200_DT
> + bool "Atmel AT91RM9200 Evaluation Kits with device-tree support"
> + select SOC_AT91RM9200
depends on
> + select USE_OF
> + help
> + Select this if you want to experiment device-tree with
> + an Atmel RM9200 Evaluation Kit.
> +
Best Regards,
J.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox