* [PATCH v4 3/4] gpio/tegra: Convert to a platform device
From: Stephen Warren @ 2011-10-11 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318371375-4083-1-git-send-email-swarren@nvidia.com>
v3: Make regs variable static. Remove empty init of tegra_gpio_banks.
v2: Retrieve IRQ and memory addresses from resources instead of hard-
coding them. Add back initialization of tegra_gpio_chip.of_node.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
gpio fixup
---
drivers/gpio/gpio-tegra.c | 143 ++++++++++++++++++++++++++++++---------------
1 files changed, 95 insertions(+), 48 deletions(-)
diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c
index 6b65207..4cb59ed 100644
--- a/drivers/gpio/gpio-tegra.c
+++ b/drivers/gpio/gpio-tegra.c
@@ -20,10 +20,11 @@
#include <linux/init.h>
#include <linux/irq.h>
#include <linux/interrupt.h>
-
#include <linux/io.h>
#include <linux/gpio.h>
#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/module.h>
#include <asm/mach/irq.h>
@@ -35,9 +36,7 @@
#define GPIO_PORT(x) (((x) >> 3) & 0x3)
#define GPIO_BIT(x) ((x) & 0x7)
-#define GPIO_REG(x) (IO_TO_VIRT(TEGRA_GPIO_BASE) + \
- GPIO_BANK(x) * 0x80 + \
- GPIO_PORT(x) * 4)
+#define GPIO_REG(x) (GPIO_BANK(x) * 0x80 + GPIO_PORT(x) * 4)
#define GPIO_CNF(x) (GPIO_REG(x) + 0x00)
#define GPIO_OE(x) (GPIO_REG(x) + 0x10)
@@ -76,15 +75,18 @@ struct tegra_gpio_bank {
};
-static struct tegra_gpio_bank tegra_gpio_banks[] = {
- {.bank = 0, .irq = INT_GPIO1},
- {.bank = 1, .irq = INT_GPIO2},
- {.bank = 2, .irq = INT_GPIO3},
- {.bank = 3, .irq = INT_GPIO4},
- {.bank = 4, .irq = INT_GPIO5},
- {.bank = 5, .irq = INT_GPIO6},
- {.bank = 6, .irq = INT_GPIO7},
-};
+static void __iomem *regs;
+static struct tegra_gpio_bank tegra_gpio_banks[7];
+
+static inline void tegra_gpio_writel(u32 val, u32 reg)
+{
+ __raw_writel(val, regs + reg);
+}
+
+static inline u32 tegra_gpio_readl(u32 reg)
+{
+ return __raw_readl(regs + reg);
+}
static int tegra_gpio_compose(int bank, int port, int bit)
{
@@ -98,7 +100,7 @@ static void tegra_gpio_mask_write(u32 reg, int gpio, int value)
val = 0x100 << GPIO_BIT(gpio);
if (value)
val |= 1 << GPIO_BIT(gpio);
- __raw_writel(val, reg);
+ tegra_gpio_writel(val, reg);
}
void tegra_gpio_enable(int gpio)
@@ -118,7 +120,7 @@ static void tegra_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
static int tegra_gpio_get(struct gpio_chip *chip, unsigned offset)
{
- return (__raw_readl(GPIO_IN(offset)) >> GPIO_BIT(offset)) & 0x1;
+ return (tegra_gpio_readl(GPIO_IN(offset)) >> GPIO_BIT(offset)) & 0x1;
}
static int tegra_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
@@ -155,7 +157,7 @@ static void tegra_gpio_irq_ack(struct irq_data *d)
{
int gpio = d->irq - INT_GPIO_BASE;
- __raw_writel(1 << GPIO_BIT(gpio), GPIO_INT_CLR(gpio));
+ tegra_gpio_writel(1 << GPIO_BIT(gpio), GPIO_INT_CLR(gpio));
}
static void tegra_gpio_irq_mask(struct irq_data *d)
@@ -208,10 +210,10 @@ static int tegra_gpio_irq_set_type(struct irq_data *d, unsigned int type)
spin_lock_irqsave(&bank->lvl_lock[port], flags);
- val = __raw_readl(GPIO_INT_LVL(gpio));
+ val = tegra_gpio_readl(GPIO_INT_LVL(gpio));
val &= ~(GPIO_INT_LVL_MASK << GPIO_BIT(gpio));
val |= lvl_type << GPIO_BIT(gpio);
- __raw_writel(val, GPIO_INT_LVL(gpio));
+ tegra_gpio_writel(val, GPIO_INT_LVL(gpio));
spin_unlock_irqrestore(&bank->lvl_lock[port], flags);
@@ -237,12 +239,12 @@ static void tegra_gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
for (port = 0; port < 4; port++) {
int gpio = tegra_gpio_compose(bank->bank, port, 0);
- unsigned long sta = __raw_readl(GPIO_INT_STA(gpio)) &
- __raw_readl(GPIO_INT_ENB(gpio));
- u32 lvl = __raw_readl(GPIO_INT_LVL(gpio));
+ unsigned long sta = tegra_gpio_readl(GPIO_INT_STA(gpio)) &
+ tegra_gpio_readl(GPIO_INT_ENB(gpio));
+ u32 lvl = tegra_gpio_readl(GPIO_INT_LVL(gpio));
for_each_set_bit(pin, &sta, 8) {
- __raw_writel(1 << pin, GPIO_INT_CLR(gpio));
+ tegra_gpio_writel(1 << pin, GPIO_INT_CLR(gpio));
/* if gpio is edge triggered, clear condition
* before executing the hander so that we don't
@@ -276,11 +278,11 @@ void tegra_gpio_resume(void)
for (p = 0; p < ARRAY_SIZE(bank->oe); p++) {
unsigned int gpio = (b<<5) | (p<<3);
- __raw_writel(bank->cnf[p], GPIO_CNF(gpio));
- __raw_writel(bank->out[p], GPIO_OUT(gpio));
- __raw_writel(bank->oe[p], GPIO_OE(gpio));
- __raw_writel(bank->int_lvl[p], GPIO_INT_LVL(gpio));
- __raw_writel(bank->int_enb[p], GPIO_INT_ENB(gpio));
+ tegra_gpio_writel(bank->cnf[p], GPIO_CNF(gpio));
+ tegra_gpio_writel(bank->out[p], GPIO_OUT(gpio));
+ tegra_gpio_writel(bank->oe[p], GPIO_OE(gpio));
+ tegra_gpio_writel(bank->int_lvl[p], GPIO_INT_LVL(gpio));
+ tegra_gpio_writel(bank->int_enb[p], GPIO_INT_ENB(gpio));
}
}
@@ -299,11 +301,11 @@ void tegra_gpio_suspend(void)
for (p = 0; p < ARRAY_SIZE(bank->oe); p++) {
unsigned int gpio = (b<<5) | (p<<3);
- bank->cnf[p] = __raw_readl(GPIO_CNF(gpio));
- bank->out[p] = __raw_readl(GPIO_OUT(gpio));
- bank->oe[p] = __raw_readl(GPIO_OE(gpio));
- bank->int_enb[p] = __raw_readl(GPIO_INT_ENB(gpio));
- bank->int_lvl[p] = __raw_readl(GPIO_INT_LVL(gpio));
+ bank->cnf[p] = tegra_gpio_readl(GPIO_CNF(gpio));
+ bank->out[p] = tegra_gpio_readl(GPIO_OUT(gpio));
+ bank->oe[p] = tegra_gpio_readl(GPIO_OE(gpio));
+ bank->int_enb[p] = tegra_gpio_readl(GPIO_INT_ENB(gpio));
+ bank->int_lvl[p] = tegra_gpio_readl(GPIO_INT_LVL(gpio));
}
}
local_irq_restore(flags);
@@ -333,28 +335,55 @@ static struct irq_chip tegra_gpio_irq_chip = {
*/
static struct lock_class_key gpio_lock_class;
-static int __init tegra_gpio_init(void)
+static int __init tegra_gpio_probe(struct platform_device *pdev)
{
+ struct resource *res;
struct tegra_gpio_bank *bank;
int gpio;
int i;
int j;
+ for (i = 0; i < ARRAY_SIZE(tegra_gpio_banks); i++) {
+ res = platform_get_resource(pdev, IORESOURCE_IRQ, i);
+ if (!res) {
+ dev_err(&pdev->dev, "Missing IRQ resource\n");
+ return -ENODEV;
+ }
+
+ bank = &tegra_gpio_banks[i];
+ bank->bank = i;
+ bank->irq = res->start;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(&pdev->dev, "Missing MEM resource\n");
+ return -ENODEV;
+ }
+
+ if (!devm_request_mem_region(&pdev->dev, res->start,
+ resource_size(res),
+ dev_name(&pdev->dev))) {
+ dev_err(&pdev->dev, "Couldn't request MEM resource\n");
+ return -ENODEV;
+ }
+
+ regs = devm_ioremap(&pdev->dev, res->start, resource_size(res));
+ if (!regs) {
+ dev_err(&pdev->dev, "Couldn't ioremap regs\n");
+ return -ENODEV;
+ }
+
for (i = 0; i < 7; i++) {
for (j = 0; j < 4; j++) {
int gpio = tegra_gpio_compose(i, j, 0);
- __raw_writel(0x00, GPIO_INT_ENB(gpio));
+ tegra_gpio_writel(0x00, GPIO_INT_ENB(gpio));
}
}
#ifdef CONFIG_OF_GPIO
- /*
- * This isn't ideal, but it gets things hooked up until this
- * driver is converted into a platform_device
- */
- tegra_gpio_chip.of_node = of_find_compatible_node(NULL, NULL,
- "nvidia,tegra20-gpio");
-#endif /* CONFIG_OF_GPIO */
+ tegra_gpio_chip.of_node = pdev->dev.of_node;
+#endif
gpiochip_add(&tegra_gpio_chip);
@@ -384,6 +413,24 @@ static int __init tegra_gpio_init(void)
return 0;
}
+static struct of_device_id tegra_gpio_of_match[] __devinitdata = {
+ { .compatible = "nvidia,tegra20-gpio", },
+ { },
+};
+
+static struct platform_driver tegra_gpio_driver = {
+ .driver = {
+ .name = "tegra-gpio",
+ .owner = THIS_MODULE,
+ .of_match_table = tegra_gpio_of_match,
+ },
+ .probe = tegra_gpio_probe,
+};
+
+static int __init tegra_gpio_init(void)
+{
+ return platform_driver_register(&tegra_gpio_driver);
+}
postcore_initcall(tegra_gpio_init);
void __init tegra_gpio_config(struct tegra_gpio_table *table, int num)
@@ -416,13 +463,13 @@ static int dbg_gpio_show(struct seq_file *s, void *unused)
seq_printf(s,
"%d:%d %02x %02x %02x %02x %02x %02x %06x\n",
i, j,
- __raw_readl(GPIO_CNF(gpio)),
- __raw_readl(GPIO_OE(gpio)),
- __raw_readl(GPIO_OUT(gpio)),
- __raw_readl(GPIO_IN(gpio)),
- __raw_readl(GPIO_INT_STA(gpio)),
- __raw_readl(GPIO_INT_ENB(gpio)),
- __raw_readl(GPIO_INT_LVL(gpio)));
+ tegra_gpio_readl(GPIO_CNF(gpio)),
+ tegra_gpio_readl(GPIO_OE(gpio)),
+ tegra_gpio_readl(GPIO_OUT(gpio)),
+ tegra_gpio_readl(GPIO_IN(gpio)),
+ tegra_gpio_readl(GPIO_INT_STA(gpio)),
+ tegra_gpio_readl(GPIO_INT_ENB(gpio)),
+ tegra_gpio_readl(GPIO_INT_LVL(gpio)));
}
}
return 0;
--
1.7.0.4
^ permalink raw reply related
* [PATCH v4 4/4] arm/tegra: Convert pinmux driver to a platform device
From: Stephen Warren @ 2011-10-11 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318371375-4083-1-git-send-email-swarren@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
arch/arm/mach-tegra/pinmux.c | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-tegra/pinmux.c b/arch/arm/mach-tegra/pinmux.c
index f80d507..46b9d87 100644
--- a/arch/arm/mach-tegra/pinmux.c
+++ b/arch/arm/mach-tegra/pinmux.c
@@ -20,6 +20,7 @@
#include <linux/errno.h>
#include <linux/spinlock.h>
#include <linux/io.h>
+#include <linux/platform_device.h>
#include <mach/iomap.h>
#include <mach/pinmux.h>
@@ -665,6 +666,31 @@ void tegra_pinmux_config_pullupdown_table(const struct tegra_pingroup_config *co
}
}
+static int __init tegra_pinmux_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static struct of_device_id tegra_pinmux_of_match[] __devinitdata = {
+ { .compatible = "nvidia,tegra20-pinmux", },
+ { },
+};
+
+static struct platform_driver tegra_pinmux_driver = {
+ .driver = {
+ .name = "tegra-pinmux",
+ .owner = THIS_MODULE,
+ .of_match_table = tegra_pinmux_of_match,
+ },
+ .probe = tegra_pinmux_probe,
+};
+
+static int __init tegra_pinmux_init(void)
+{
+ return platform_driver_register(&tegra_pinmux_driver);
+}
+postcore_initcall(tegra_pinmux_init);
+
#ifdef CONFIG_DEBUG_FS
#include <linux/debugfs.h>
--
1.7.0.4
^ permalink raw reply related
* [PATCH] arm/tegra: pinmux: ioremap registers
From: Stephen Warren @ 2011-10-11 23:22 UTC (permalink / raw)
To: linux-arm-kernel
Use ioremap to obtain access to registers instead of using static
mappings. This reduces the number of users of the static mappings, which
will eventually allow them to be removed.
Note that on Tegra30, the number of register "spaces" will decrease to 2,
and the packing of specific bits into registers will change significantly.
That's why this change adds the "*_space" fields to the pingroup tables,
rather than implementing some more hard-coded scheme.
Also, completely remove the implementation of suspend/resume; Tegra doesn't
yet support suspend/resume, and the implementation is complex for the
general pinmux driver:
* Not all registers are used within each space, so we probably shouldn't
just iterate over every register in the space, and save/restore it,
since that would mean touching undefined registers.
* Registers are shared between pingroups, so we can't simply iterate over
each pingroup, and save/restore the registers it uses.
It'd probably be best have probe() calculate a bitmask of actually-used
registers for each space, and have suspend/resume iterate over those
bitmaps.
Oh, and Real Soon Now, I should be looking into converting this driver to
the new pinmux/pinctrl subsystem, so I didn't want to put too much work
into the current incarnation.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
arch/arm/mach-tegra/include/mach/pinmux.h | 4 +
arch/arm/mach-tegra/pinmux-t2-tables.c | 76 +++-------------
arch/arm/mach-tegra/pinmux.c | 137 ++++++++++++++++++++++-------
3 files changed, 123 insertions(+), 94 deletions(-)
diff --git a/arch/arm/mach-tegra/include/mach/pinmux.h b/arch/arm/mach-tegra/include/mach/pinmux.h
index defd877..741147f 100644
--- a/arch/arm/mach-tegra/include/mach/pinmux.h
+++ b/arch/arm/mach-tegra/include/mach/pinmux.h
@@ -199,6 +199,7 @@ struct tegra_drive_pingroup_config {
struct tegra_drive_pingroup_desc {
const char *name;
+ s16 reg_space;
s16 reg;
};
@@ -207,6 +208,9 @@ struct tegra_pingroup_desc {
int funcs[4];
int func_safe;
int vddio;
+ s16 tri_space; /* Register space the tri_reg exists within */
+ s16 mux_space; /* Register space the mux_reg exists within */
+ s16 pupd_space; /* Register space the pupd_reg exists within */
s16 tri_reg; /* offset into the TRISTATE_REG_* register bank */
s16 mux_reg; /* offset into the PIN_MUX_CTL_* register bank */
s16 pupd_reg; /* offset into the PULL_UPDOWN_REG_* register bank */
diff --git a/arch/arm/mach-tegra/pinmux-t2-tables.c b/arch/arm/mach-tegra/pinmux-t2-tables.c
index a475367..42795ec 100644
--- a/arch/arm/mach-tegra/pinmux-t2-tables.c
+++ b/arch/arm/mach-tegra/pinmux-t2-tables.c
@@ -31,10 +31,16 @@
#include <mach/pinmux.h>
#include <mach/suspend.h>
+#define TRISTATE_REG_A 0x14
+#define PIN_MUX_CTL_REG_A 0x80
+#define PULLUPDOWN_REG_A 0xa0
+#define PINGROUP_REG_A 0x868
+
#define DRIVE_PINGROUP(pg_name, r) \
[TEGRA_DRIVE_PINGROUP_ ## pg_name] = { \
.name = #pg_name, \
- .reg = r \
+ .reg_space = 3, \
+ .reg = ((r) - PINGROUP_REG_A) \
}
const struct tegra_drive_pingroup_desc tegra_soc_drive_pingroups[TEGRA_MAX_DRIVE_PINGROUP] = {
@@ -90,11 +96,14 @@ const struct tegra_drive_pingroup_desc tegra_soc_drive_pingroups[TEGRA_MAX_DRIVE
TEGRA_MUX_ ## f3, \
}, \
.func_safe = TEGRA_MUX_ ## f_safe, \
- .tri_reg = tri_r, \
+ .tri_space = 0, \
+ .tri_reg = ((tri_r) - TRISTATE_REG_A), \
.tri_bit = tri_b, \
- .mux_reg = mux_r, \
+ .mux_space = 1, \
+ .mux_reg = ((mux_r) - PIN_MUX_CTL_REG_A), \
.mux_bit = mux_b, \
- .pupd_reg = pupd_r, \
+ .pupd_space = 2, \
+ .pupd_reg = ((pupd_r) - PULLUPDOWN_REG_A), \
.pupd_bit = pupd_b, \
}
@@ -217,62 +226,3 @@ const struct tegra_pingroup_desc tegra_soc_pingroups[TEGRA_MAX_PINGROUP] = {
PINGROUP(XM2C, DDR, RSVD, RSVD, RSVD, RSVD, RSVD, -1, -1, -1, -1, 0xA8, 30),
PINGROUP(XM2D, DDR, RSVD, RSVD, RSVD, RSVD, RSVD, -1, -1, -1, -1, 0xA8, 28),
};
-
-#ifdef CONFIG_PM
-#define TRISTATE_REG_A 0x14
-#define TRISTATE_REG_NUM 4
-#define PIN_MUX_CTL_REG_A 0x80
-#define PIN_MUX_CTL_REG_NUM 8
-#define PULLUPDOWN_REG_A 0xa0
-#define PULLUPDOWN_REG_NUM 5
-
-static u32 pinmux_reg[TRISTATE_REG_NUM + PIN_MUX_CTL_REG_NUM +
- PULLUPDOWN_REG_NUM +
- ARRAY_SIZE(tegra_soc_drive_pingroups)];
-
-static inline unsigned long pg_readl(unsigned long offset)
-{
- return readl(IO_TO_VIRT(TEGRA_APB_MISC_BASE + offset));
-}
-
-static inline void pg_writel(unsigned long value, unsigned long offset)
-{
- writel(value, IO_TO_VIRT(TEGRA_APB_MISC_BASE + offset));
-}
-
-void tegra_pinmux_suspend(void)
-{
- unsigned int i;
- u32 *ctx = pinmux_reg;
-
- for (i = 0; i < PIN_MUX_CTL_REG_NUM; i++)
- *ctx++ = pg_readl(PIN_MUX_CTL_REG_A + i*4);
-
- for (i = 0; i < PULLUPDOWN_REG_NUM; i++)
- *ctx++ = pg_readl(PULLUPDOWN_REG_A + i*4);
-
- for (i = 0; i < TRISTATE_REG_NUM; i++)
- *ctx++ = pg_readl(TRISTATE_REG_A + i*4);
-
- for (i = 0; i < ARRAY_SIZE(tegra_soc_drive_pingroups); i++)
- *ctx++ = pg_readl(tegra_soc_drive_pingroups[i].reg);
-}
-
-void tegra_pinmux_resume(void)
-{
- unsigned int i;
- u32 *ctx = pinmux_reg;
-
- for (i = 0; i < PIN_MUX_CTL_REG_NUM; i++)
- pg_writel(*ctx++, PIN_MUX_CTL_REG_A + i*4);
-
- for (i = 0; i < PULLUPDOWN_REG_NUM; i++)
- pg_writel(*ctx++, PULLUPDOWN_REG_A + i*4);
-
- for (i = 0; i < TRISTATE_REG_NUM; i++)
- pg_writel(*ctx++, TRISTATE_REG_A + i*4);
-
- for (i = 0; i < ARRAY_SIZE(tegra_soc_drive_pingroups); i++)
- pg_writel(*ctx++, tegra_soc_drive_pingroups[i].reg);
-}
-#endif
diff --git a/arch/arm/mach-tegra/pinmux.c b/arch/arm/mach-tegra/pinmux.c
index 46b9d87..99c2751 100644
--- a/arch/arm/mach-tegra/pinmux.c
+++ b/arch/arm/mach-tegra/pinmux.c
@@ -170,15 +170,17 @@ static const char *pupd_name(unsigned long val)
}
}
+static int nspaces;
+static void __iomem **regs;
-static inline unsigned long pg_readl(unsigned long offset)
+static inline u32 pg_readl(u32 reg, u32 space)
{
- return readl(IO_TO_VIRT(TEGRA_APB_MISC_BASE + offset));
+ return readl(regs[space] + reg);
}
-static inline void pg_writel(unsigned long value, unsigned long offset)
+static inline void pg_writel(u32 val, u32 reg, u32 space)
{
- writel(value, IO_TO_VIRT(TEGRA_APB_MISC_BASE + offset));
+ writel(val, regs[space] + reg);
}
static int tegra_pinmux_set_func(const struct tegra_pingroup_config *config)
@@ -218,10 +220,10 @@ static int tegra_pinmux_set_func(const struct tegra_pingroup_config *config)
spin_lock_irqsave(&mux_lock, flags);
- reg = pg_readl(pingroups[pg].mux_reg);
+ reg = pg_readl(pingroups[pg].mux_reg, pingroups[pg].mux_space);
reg &= ~(0x3 << pingroups[pg].mux_bit);
reg |= mux << pingroups[pg].mux_bit;
- pg_writel(reg, pingroups[pg].mux_reg);
+ pg_writel(reg, pingroups[pg].mux_reg, pingroups[pg].mux_space);
spin_unlock_irqrestore(&mux_lock, flags);
@@ -242,11 +244,11 @@ int tegra_pinmux_set_tristate(enum tegra_pingroup pg,
spin_lock_irqsave(&mux_lock, flags);
- reg = pg_readl(pingroups[pg].tri_reg);
+ reg = pg_readl(pingroups[pg].tri_reg, pingroups[pg].tri_space);
reg &= ~(0x1 << pingroups[pg].tri_bit);
if (tristate)
reg |= 1 << pingroups[pg].tri_bit;
- pg_writel(reg, pingroups[pg].tri_reg);
+ pg_writel(reg, pingroups[pg].tri_reg, pingroups[pg].tri_space);
spin_unlock_irqrestore(&mux_lock, flags);
@@ -273,10 +275,10 @@ int tegra_pinmux_set_pullupdown(enum tegra_pingroup pg,
spin_lock_irqsave(&mux_lock, flags);
- reg = pg_readl(pingroups[pg].pupd_reg);
+ reg = pg_readl(pingroups[pg].pupd_reg, pingroups[pg].pupd_space);
reg &= ~(0x3 << pingroups[pg].pupd_bit);
reg |= pupd << pingroups[pg].pupd_bit;
- pg_writel(reg, pingroups[pg].pupd_reg);
+ pg_writel(reg, pingroups[pg].pupd_reg, pingroups[pg].pupd_space);
spin_unlock_irqrestore(&mux_lock, flags);
@@ -363,12 +365,12 @@ static int tegra_drive_pinmux_set_hsm(enum tegra_drive_pingroup pg,
spin_lock_irqsave(&mux_lock, flags);
- reg = pg_readl(drive_pingroups[pg].reg);
+ reg = pg_readl(drive_pingroups[pg].reg, drive_pingroups[pg].reg_space);
if (hsm == TEGRA_HSM_ENABLE)
reg |= (1 << 2);
else
reg &= ~(1 << 2);
- pg_writel(reg, drive_pingroups[pg].reg);
+ pg_writel(reg, drive_pingroups[pg].reg, drive_pingroups[pg].reg_space);
spin_unlock_irqrestore(&mux_lock, flags);
@@ -388,12 +390,12 @@ static int tegra_drive_pinmux_set_schmitt(enum tegra_drive_pingroup pg,
spin_lock_irqsave(&mux_lock, flags);
- reg = pg_readl(drive_pingroups[pg].reg);
+ reg = pg_readl(drive_pingroups[pg].reg, drive_pingroups[pg].reg_space);
if (schmitt == TEGRA_SCHMITT_ENABLE)
reg |= (1 << 3);
else
reg &= ~(1 << 3);
- pg_writel(reg, drive_pingroups[pg].reg);
+ pg_writel(reg, drive_pingroups[pg].reg, drive_pingroups[pg].reg_space);
spin_unlock_irqrestore(&mux_lock, flags);
@@ -413,10 +415,10 @@ static int tegra_drive_pinmux_set_drive(enum tegra_drive_pingroup pg,
spin_lock_irqsave(&mux_lock, flags);
- reg = pg_readl(drive_pingroups[pg].reg);
+ reg = pg_readl(drive_pingroups[pg].reg, drive_pingroups[pg].reg_space);
reg &= ~(0x3 << 4);
reg |= drive << 4;
- pg_writel(reg, drive_pingroups[pg].reg);
+ pg_writel(reg, drive_pingroups[pg].reg, drive_pingroups[pg].reg_space);
spin_unlock_irqrestore(&mux_lock, flags);
@@ -436,10 +438,10 @@ static int tegra_drive_pinmux_set_pull_down(enum tegra_drive_pingroup pg,
spin_lock_irqsave(&mux_lock, flags);
- reg = pg_readl(drive_pingroups[pg].reg);
+ reg = pg_readl(drive_pingroups[pg].reg, drive_pingroups[pg].reg_space);
reg &= ~(0x1f << 12);
reg |= pull_down << 12;
- pg_writel(reg, drive_pingroups[pg].reg);
+ pg_writel(reg, drive_pingroups[pg].reg, drive_pingroups[pg].reg_space);
spin_unlock_irqrestore(&mux_lock, flags);
@@ -459,10 +461,10 @@ static int tegra_drive_pinmux_set_pull_up(enum tegra_drive_pingroup pg,
spin_lock_irqsave(&mux_lock, flags);
- reg = pg_readl(drive_pingroups[pg].reg);
+ reg = pg_readl(drive_pingroups[pg].reg, drive_pingroups[pg].reg_space);
reg &= ~(0x1f << 12);
reg |= pull_up << 12;
- pg_writel(reg, drive_pingroups[pg].reg);
+ pg_writel(reg, drive_pingroups[pg].reg, drive_pingroups[pg].reg_space);
spin_unlock_irqrestore(&mux_lock, flags);
@@ -482,10 +484,10 @@ static int tegra_drive_pinmux_set_slew_rising(enum tegra_drive_pingroup pg,
spin_lock_irqsave(&mux_lock, flags);
- reg = pg_readl(drive_pingroups[pg].reg);
+ reg = pg_readl(drive_pingroups[pg].reg, drive_pingroups[pg].reg_space);
reg &= ~(0x3 << 28);
reg |= slew_rising << 28;
- pg_writel(reg, drive_pingroups[pg].reg);
+ pg_writel(reg, drive_pingroups[pg].reg, drive_pingroups[pg].reg_space);
spin_unlock_irqrestore(&mux_lock, flags);
@@ -505,10 +507,10 @@ static int tegra_drive_pinmux_set_slew_falling(enum tegra_drive_pingroup pg,
spin_lock_irqsave(&mux_lock, flags);
- reg = pg_readl(drive_pingroups[pg].reg);
+ reg = pg_readl(drive_pingroups[pg].reg, drive_pingroups[pg].reg_space);
reg &= ~(0x3 << 30);
reg |= slew_falling << 30;
- pg_writel(reg, drive_pingroups[pg].reg);
+ pg_writel(reg, drive_pingroups[pg].reg, drive_pingroups[pg].reg_space);
spin_unlock_irqrestore(&mux_lock, flags);
@@ -668,6 +670,74 @@ void tegra_pinmux_config_pullupdown_table(const struct tegra_pingroup_config *co
static int __init tegra_pinmux_probe(struct platform_device *pdev)
{
+ struct resource *res;
+ int i;
+ int config_bad = 0;
+
+ for (i = 0; ; i++) {
+ res = platform_get_resource(pdev, IORESOURCE_MEM, i);
+ if (!res)
+ break;
+ }
+ nspaces = i;
+
+ for (i = 0; i < TEGRA_MAX_PINGROUP; i++) {
+ if (pingroups[i].tri_space >= nspaces) {
+ dev_err(&pdev->dev, "pingroup %d: bad tri_space\n", i);
+ config_bad = 1;
+ }
+
+ if (pingroups[i].mux_space >= nspaces) {
+ dev_err(&pdev->dev, "pingroup %d: bad mux_space\n", i);
+ config_bad = 1;
+ }
+
+ if (pingroups[i].pupd_space >= nspaces) {
+ dev_err(&pdev->dev, "pingroup %d: bad pupd_space\n", i);
+ config_bad = 1;
+ }
+ }
+
+ for (i = 0; i < TEGRA_MAX_DRIVE_PINGROUP; i++) {
+ if (drive_pingroups[i].reg_space >= nspaces) {
+ dev_err(&pdev->dev,
+ "drive pingroup %d: bad reg_space\n", i);
+ config_bad = 1;
+ }
+ }
+
+ if (config_bad)
+ return -ENODEV;
+
+ regs = devm_kzalloc(&pdev->dev, nspaces * sizeof(*regs), GFP_KERNEL);
+ if (!regs) {
+ dev_err(&pdev->dev, "Can't alloc regs pointer\n");
+ return -ENODEV;
+ }
+
+ for (i = 0; i < nspaces; i++) {
+ res = platform_get_resource(pdev, IORESOURCE_MEM, i);
+ if (!res) {
+ dev_err(&pdev->dev, "Missing MEM resource\n");
+ return -ENODEV;
+ }
+
+ if (!devm_request_mem_region(&pdev->dev, res->start,
+ resource_size(res),
+ dev_name(&pdev->dev))) {
+ dev_err(&pdev->dev,
+ "Couldn't request MEM resource %d\n", i);
+ return -ENODEV;
+ }
+
+ regs[i] = devm_ioremap(&pdev->dev, res->start,
+ resource_size(res));
+ if (!regs) {
+ dev_err(&pdev->dev, "Couldn't ioremap regs %d\n", i);
+ return -ENODEV;
+ }
+ }
+
return 0;
}
@@ -710,6 +780,7 @@ static int dbg_pinmux_show(struct seq_file *s, void *unused)
int len;
for (i = 0; i < TEGRA_MAX_PINGROUP; i++) {
+ unsigned long reg;
unsigned long tri;
unsigned long mux;
unsigned long pupd;
@@ -722,8 +793,9 @@ static int dbg_pinmux_show(struct seq_file *s, void *unused)
seq_printf(s, "TEGRA_MUX_NONE");
len = strlen("NONE");
} else {
- mux = (pg_readl(pingroups[i].mux_reg) >>
- pingroups[i].mux_bit) & 0x3;
+ reg = pg_readl(pingroups[i].mux_reg,
+ pingroups[i].mux_space);
+ mux = (reg >> pingroups[i].mux_bit) & 0x3;
if (pingroups[i].funcs[mux] == TEGRA_MUX_RSVD) {
seq_printf(s, "TEGRA_MUX_RSVD%1lu", mux+1);
len = 5;
@@ -739,8 +811,9 @@ static int dbg_pinmux_show(struct seq_file *s, void *unused)
seq_printf(s, "TEGRA_PUPD_NORMAL");
len = strlen("NORMAL");
} else {
- pupd = (pg_readl(pingroups[i].pupd_reg) >>
- pingroups[i].pupd_bit) & 0x3;
+ reg = pg_readl(pingroups[i].pupd_reg,
+ pingroups[i].pupd_space);
+ pupd = (reg >> pingroups[i].pupd_bit) & 0x3;
seq_printf(s, "TEGRA_PUPD_%s", pupd_name(pupd));
len = strlen(pupd_name(pupd));
}
@@ -749,8 +822,9 @@ static int dbg_pinmux_show(struct seq_file *s, void *unused)
if (pingroups[i].tri_reg < 0) {
seq_printf(s, "TEGRA_TRI_NORMAL");
} else {
- tri = (pg_readl(pingroups[i].tri_reg) >>
- pingroups[i].tri_bit) & 0x1;
+ reg = pg_readl(pingroups[i].tri_reg,
+ pingroups[i].tri_space);
+ tri = (reg >> pingroups[i].tri_bit) & 0x1;
seq_printf(s, "TEGRA_TRI_%s", tri_name(tri));
}
@@ -785,7 +859,8 @@ static int dbg_drive_pinmux_show(struct seq_file *s, void *unused)
dbg_pad_field(s, 7 - len);
- reg = pg_readl(drive_pingroups[i].reg);
+ reg = pg_readl(drive_pingroups[i].reg,
+ drive_pingroups[i].reg_space);
if (HSM_EN(reg)) {
seq_printf(s, "TEGRA_HSM_ENABLE");
len = 16;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/7] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY
From: Tony Lindgren @ 2011-10-11 23:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111011134048.28b9b19b@queued.net>
* Andres Salomon <dilinger@queued.net> [111011 14:11]:
> On Fri, 07 Oct 2011 12:45:43 -0700
> Tony Lindgren <tony@atomide.com> wrote:
>
> > This allows mapping external memory such as SRAM for use.
> >
> > This is needed for some small chunks of code, such as reprogramming
> > SDRAM memory source clocks that can't be executed in SDRAM. Other
> > use cases include some PM related code.
>
>
> Acked-by: Andres Salomon <dilinger@queued.net>
>
> Looks good to me, thanks for doing this. I only have one very minor
> quibble below, which could be addressed in a later patch..
> > +void __iomem *
> > +__arm_ioremap_exec(unsigned long phys_addr, size_t size, int cached)
>
> I'd rather see this as 'bool cached', so it's clear we're talking
> about a simple boolean (rather than bits).
Sure, thanks, updated version below. Will also update the patch in
Russell's patch system.
Tony
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ioremap-exec.patch
Type: text/x-diff
Size: 1937 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111011/a970586f/attachment-0001.bin>
^ permalink raw reply
* [GIT PULL] DEBUG_LL platform updates for 3.2
From: Nicolas Pitre @ 2011-10-12 0:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2414781.rlNqTThJUN@wuerfel>
On Tue, 11 Oct 2011, Arnd Bergmann wrote:
> I've stuck them into the arm-soc tree for now, so we get linux-next
> coverage, but I won't send them to Linus this way because then we
> would get the same commits twice in the history.
Could you please do the same with the following:
git://git.linaro.org/people/nico/linux.git mach_memory_h
Russell pulled it at some point, and dropped it due to concerns about
repeated conflict resolutions (or so I presume). I just did a test
merge between your for-next branch and the above and that looked trivial
enough.
Nicolas
^ permalink raw reply
* [PATCH] arm/tegra: pinmux: ioremap registers
From: Olof Johansson @ 2011-10-12 0:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318375320-21138-1-git-send-email-swarren@nvidia.com>
Hi,
Overall this looks pretty good, with a couple of nits below.
I'm not super-happy with all the opencoding of the reg / access passing into
pg_readl/writel, but adding new helpers for all 4 kinds is also kind of
verbose.
On Tue, Oct 11, 2011 at 05:22:00PM -0600, Stephen Warren wrote:
> diff --git a/arch/arm/mach-tegra/include/mach/pinmux.h b/arch/arm/mach-tegra/include/mach/pinmux.h
> index defd877..741147f 100644
> --- a/arch/arm/mach-tegra/include/mach/pinmux.h
> +++ b/arch/arm/mach-tegra/include/mach/pinmux.h
> @@ -199,6 +199,7 @@ struct tegra_drive_pingroup_config {
>
> struct tegra_drive_pingroup_desc {
> const char *name;
> + s16 reg_space;
> s16 reg;
> };
>
> @@ -207,6 +208,9 @@ struct tegra_pingroup_desc {
> int funcs[4];
> int func_safe;
> int vddio;
> + s16 tri_space; /* Register space the tri_reg exists within */
> + s16 mux_space; /* Register space the mux_reg exists within */
> + s16 pupd_space; /* Register space the pupd_reg exists within */
> s16 tri_reg; /* offset into the TRISTATE_REG_* register bank */
> s16 mux_reg; /* offset into the PIN_MUX_CTL_* register bank */
> s16 pupd_reg; /* offset into the PULL_UPDOWN_REG_* register bank */
'space' is really 'bank number' here, with *_reg is the offset into that bank,
right? Calling it a register bank seems to go with the pre-existing language
in the driver a bit more.
[...]
> diff --git a/arch/arm/mach-tegra/pinmux.c b/arch/arm/mach-tegra/pinmux.c
> index 46b9d87..99c2751 100644
> --- a/arch/arm/mach-tegra/pinmux.c
> +++ b/arch/arm/mach-tegra/pinmux.c
> @@ -170,15 +170,17 @@ static const char *pupd_name(unsigned long val)
> }
> }
>
> +static int nspaces;
> +static void __iomem **regs;
>
> -static inline unsigned long pg_readl(unsigned long offset)
> +static inline u32 pg_readl(u32 reg, u32 space)
> {
> - return readl(IO_TO_VIRT(TEGRA_APB_MISC_BASE + offset));
> + return readl(regs[space] + reg);
> }
>
> -static inline void pg_writel(unsigned long value, unsigned long offset)
> +static inline void pg_writel(u32 val, u32 reg, u32 space)
> {
> - writel(value, IO_TO_VIRT(TEGRA_APB_MISC_BASE + offset));
> + writel(val, regs[space] + reg);
> }
For both of these, having the space (bank) before the offset into the bank seems
a bit more logical, imho.
-Olof
^ permalink raw reply
* [Linaro-mm-sig] [PATCH 1/2] ARM: initial proof-of-concept IOMMU mapper for DMA-mapping
From: Krishna Reddy @ 2011-10-12 1:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <401E54CE964CD94BAE1EB4A729C7087E3722519A1F@HQMAIL04.nvidia.com>
>>It looks that You have simplified arm_iommu_map_sg() function too much.
>>The main advantage of the iommu is to map scattered memory pages into
>>contiguous dma address space. DMA-mapping is allowed to merge consecutive
>>entries in the scatter list if hardware supports that.
>>http://article.gmane.org/gmane.linux.kernel/1128416
>I would update arm_iommu_map_sg() back to coalesce the sg list.
>>MMC drivers seem to be aware of coalescing the SG entries together as they are using dma_sg_len().
I have updated the arm_iommu_map_sg() back to coalesce and fixed the issues with it. During testing, I found out that mmc host driver doesn't support buffers bigger than 64K. To get the device working, I had to break the sg entries coalesce when dma_length is about to go beyond 64KB. Looks like Mmc host driver(sdhci.c) need to be fixed to handle buffers bigger than 64KB. Should the clients be forced to handle bigger buffers or is there any better way to handle these kind of issues?
--
nvpublic
^ permalink raw reply
* [PATCH v3 6/7] ARM: pxa: move gpio-pxa.h into include directory
From: Haojian Zhuang @ 2011-10-12 2:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3002440.xxjcQDzptB@wuerfel>
On Wed, Oct 12, 2011 at 4:42 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 11 October 2011 21:51:28 Linus Walleij wrote:
>> 2011/10/11 Haojian Zhuang <haojian.zhuang@marvell.com>:
>>
>> > Merge the gpio-pxa.h in arch-pxa and arch-mmp. Move the new gpio-pxa.h
>> > into include directory.
>> (...)
>> > ?arch/arm/plat-pxa/include/plat/gpio-pxa.h ?| ? 80 ---------------------------
>> > ?drivers/gpio/gpio-pxa.c ? ? ? ? ? ? ? ? ? ?| ? 42 ++++++++++++++-
>> > ?include/linux/gpio-pxa.h ? ? ? ? ? ? ? ? ? | ? 81 ++++++++++++++++++++++++++++
>>
>> This seems like a fully valid merge of common pxa GPIO include
>> files. And I guess if both are not using plat-pxa it cannot reside
>> in <plat/gpio-pxa.h>?
>>
>> Grant: shall this be <linux/gpio-pxa.h> or <linux/gpio/pxa.h> or so?
>
> Hmm, more fundamentally, does this even need to be a header file?
>
> Most of the header file looks like it should not be visible in the entire
> kernel, so better move as much as possible into the gpio-pxa.c file.
> I'm not sure how much remains in the end, but that should probably
> determine the location (drivers/gpio/gpio-pxa.h, asm/gpio-pxa.h
> or linux/gpio-pxa.h). In general, everything should be as local
> as possible.
>
> One more thing regarding the contents of the header:
>
>> +/* GPIO Pin Level Registers */
>> +#define PXA_GPLR(x) ?(*(volatile u32 *)(pxa_gpio_regs.gplr ? \
>> + ? ? ? ? ? ? ? ? ? ? + PXA_BANK_OFF((x >> 5))))
>> +/* GPIO Pin Direction Registers */
>> +#define PXA_GPDR(x) ?(*(volatile u32 *)(pxa_gpio_regs.gpdr ? \
>> + ? ? ? ? ? ? ? ? ? ? + PXA_BANK_OFF((x >> 5))))
>
> When these get m> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
oved into the driver itself, it's probably a good
> idea to turn these into proper accessors, something like
>
> enum pxa_gpio_reg {
> ? ? ? ?GPLR,
> ? ? ? ?GPDR,
> ? ? ? ?GPSR,
> ? ? ? ?GPCR,
> ? ? ? ?GRER,
> ? ? ? ?GFER,
> ? ? ? ?GEDR,
> };
> static void __iomem *pxa_gpio_reg_base;
> static inline u32 pxa_gpio_read(unsigned int bank, enum pxa_gpio_reg reg)
> {
> ? ? ? ?unsigned offset = (bank < 3) ? bank << 2 : 0x100 + ((bank - 3) << 2);
> ? ? ? ?return readl_relaxed(pxa_gpio_reg_base + offset + 12 * reg);
> }
> static inline void pxa_gpio_write(unsigned int bank, unsigned int reg, u32 val)
> {
> ? ? ? ?unsigned offset = (bank < 3) ? bank << 2 : 0x100 + ((bank - 3) << 2);
> ? ? ? ?return writel_relaxed(val, pxa_gpio_reg_base + offset + 12 * reg);
> }
>
> That should let you get rid of most of the macros and the incorrect
> 'volatile' access.
>
> ? ? ? ?Arnd
>
It sounds good. I'll fix it.
Thanks
Haojian
^ permalink raw reply
* [RFC/PATCH 3/7] ARM: ARM11 MPCore: {clean, flush}_pmd_entry are not preempt safe
From: George G. Davis @ 2011-10-12 2:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111011095314.GA23848@arm.com>
On Oct 11, 2011, at 5:53 AM, Catalin Marinas wrote:
> On Fri, Oct 07, 2011 at 03:38:37AM +0100, gdavis at mvista.com wrote:
>> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
>> index 594d677..3c8253f 100644
>> --- a/arch/arm/mm/mmu.c
>> +++ b/arch/arm/mm/mmu.c
>> @@ -567,12 +567,24 @@ static void __init alloc_init_section(pud_t *pud, unsigned long addr,
>> if (addr & SECTION_SIZE)
>> pmd++;
>>
>> + if (cache_ops_need_broadcast())
>> + preempt_disable();
>> do {
>> *pmd = __pmd(phys | type->prot_sect);
>> phys += SECTION_SIZE;
>> } while (pmd++, addr += SECTION_SIZE, addr != end);
>>
>> + /* FIXME: Multiple PMD entries may be written above
>> + * but only one cache line, up to 8 PMDs depending
>> + * on the alignment of this mapping, is flushed below.
>> + * IFF this mapping spans >8MiB, then only the first
>> + * 8MiB worth of entries will be flushed. Entries
>> + * above the 8MiB limit will not be flushed if I
>> + * read this correctly.
>> + */
>> flush_pmd_entry(p);
>> + if (cache_ops_need_broadcast())
>> + preempt_enable();
>
> My reading of the create_mapping() code is that alloc_init_pud() and
> alloc_init_section() are called with a 2MB range only (that's 2
> entries) given by pgd_addr_end().
You're correct of course. I initially stuck that FIXME note in there more as
a reminder to review it more carefully. Alas, in my haste, I submitted as-is
w/o checking parameter bounds passed from callers which do as you
say, so it's never more than 2MiB in size. Thanks for the feedback.
I'll remove that note.
--
Regards,
George
>
> --
> Catalin
^ permalink raw reply
* [PATCH v6 09/10] ARM: S5PC100: Modify platform data for pl330 driver
From: Boojin Kim @ 2011-10-12 3:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318270538-30450-10-git-send-email-thomas.abraham@linaro.org>
Thomas Abraham wrote:
> Sent: Tuesday, October 11, 2011 3:16 AM
> To: linux-arm-kernel at lists.infradead.org
> Cc: linux-samsung-soc at vger.kernel.org; kgene.kim at samsung.com;
> vinod.koul at intel.com; Jassi Brar; Boojin Kim
> Subject: [PATCH v6 09/10] ARM: S5PC100: Modify platform data for pl330
> driver
>
> With the 'struct dma_pl330_peri' removed, the platfrom data for dma
> driver can be simplified to a simple list of peripheral request ids.
>
> Cc: Jassi Brar <jassisinghbrar@gmail.com>
> Cc: Boojin Kim <boojin.kim@samsung.com>
> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
> ---
> arch/arm/mach-s5pc100/dma.c | 247 ++++++++++++-----------------------
> --------
> 1 files changed, 69 insertions(+), 178 deletions(-)
>
Looks good to me.
Acked-by: Boojin Kim <boojin.kim@samsung.com>
> diff --git a/arch/arm/mach-s5pc100/dma.c b/arch/arm/mach-s5pc100/dma.c
> index 065a087..8dfdc76 100644
> --- a/arch/arm/mach-s5pc100/dma.c
> +++ b/arch/arm/mach-s5pc100/dma.c
> @@ -35,100 +35,42 @@
>
> static u64 dma_dmamask = DMA_BIT_MASK(32);
>
^ permalink raw reply
* [PATCH v6 10/10] ARM: S5PV210: Modify platform data for pl330 driver
From: Boojin Kim @ 2011-10-12 3:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318270538-30450-11-git-send-email-thomas.abraham@linaro.org>
Thomas Abraham wrote:
> Sent: Tuesday, October 11, 2011 3:16 AM
> To: linux-arm-kernel at lists.infradead.org
> Cc: linux-samsung-soc at vger.kernel.org; kgene.kim at samsung.com;
> vinod.koul at intel.com; Jassi Brar; Boojin Kim
> Subject: [PATCH v6 10/10] ARM: S5PV210: Modify platform data for pl330
> driver
>
> With the 'struct dma_pl330_peri' removed, the platfrom data for dma
> driver can be simplified to a simple list of peripheral request ids.
>
> Cc: Jassi Brar <jassisinghbrar@gmail.com>
> Cc: Boojin Kim <boojin.kim@samsung.com>
> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
> ---
> arch/arm/mach-s5pv210/dma.c | 241 ++++++++++++-----------------------
> -------
> 1 files changed, 69 insertions(+), 172 deletions(-)
>
Looks good to me.
Acked-by: Boojin Kim <boojin.kim@samsung.com>
^ permalink raw reply
* [PATCH v6 02/10] DMA: PL330: Infer transfer direction from transfer request instead of platform data
From: Boojin Kim @ 2011-10-12 4:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318270538-30450-3-git-send-email-thomas.abraham@linaro.org>
Thomas Abraham wrote:
> Sent: Tuesday, October 11, 2011 3:16 AM
> To: linux-arm-kernel at lists.infradead.org
> Cc: linux-samsung-soc at vger.kernel.org; kgene.kim at samsung.com;
> vinod.koul at intel.com; Jassi Brar; Boojin Kim
> Subject: [PATCH v6 02/10] DMA: PL330: Infer transfer direction from
> transfer request instead of platform data
>
> The transfer direction for a channel can be inferred from the transfer
> request and the need for specifying transfer direction in platfrom
> data
> can be eliminated. So the structure definition 'struct dma_pl330_peri'
> is no longer required.
>
> The channel's private data is set to point to a channel id specified
> in
> the platform data (instead of an instance of type 'struct
> dma_pl330_peri').
> The filter function is correspondingly modified to match the channel
> id.
>
> With the 'struct dma_pl330_peri' removed from platform data, the dma
> controller transfer capabilities cannot be inferred any more. Hence,
> the dma controller capabilities is specified using platform data.
>
> Cc: Jassi Brar <jassisinghbrar@gmail.com>
> Cc: Boojin Kim <boojin.kim@samsung.com>
> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
> Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> drivers/dma/pl330.c | 65 +++++++++++---------------------------
> ------
> include/linux/amba/pl330.h | 13 ++-------
> 2 files changed, 19 insertions(+), 59 deletions(-)
>
Looks good to me.
Acked-by: Boojin Kim <boojin.kim@samsung.com>
^ permalink raw reply
* [PATCH v6 04/10] DMA: PL330: Add device tree support
From: Boojin Kim @ 2011-10-12 4:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318270538-30450-5-git-send-email-thomas.abraham@linaro.org>
Thomas Abraham wrote:
> Sent: Tuesday, October 11, 2011 3:16 AM
> To: linux-arm-kernel at lists.infradead.org
> Cc: linux-samsung-soc at vger.kernel.org; kgene.kim at samsung.com;
> vinod.koul at intel.com; Jassi Brar; Boojin Kim
> Subject: [PATCH v6 04/10] DMA: PL330: Add device tree support
>
> For PL330 dma controllers instantiated from device tree, the channel
> lookup is based on phandle of the dma controller and dma request id
> specified by the client node. During probe, the private data of each
> channel of the controller is set to point to the device node of the
> dma controller. The 'chan_id' of the each channel is used as the
> dma request id.
>
> Client driver requesting dma channels specify the phandle of the
> dma controller and the request id. The pl330 filter function
> converts the phandle to the device node pointer and matches that
> with channel's private data. If a match is found, the request id
> from the client node and the 'chan_id' of the channel is matched.
> A channel is found if both the values match.
>
> Cc: Jassi Brar <jassisinghbrar@gmail.com>
> Cc: Boojin Kim <boojin.kim@samsung.com>
> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
> Reviewed-by: Rob Herring <rob.herring@calxeda.com>
> Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
Looks good to me.
Acked-by: Boojin Kim <boojin.kim@samsung.com>
^ permalink raw reply
* [PATCH v6 09/10] ARM: S5PC100: Modify platform data for pl330 driver
From: Anca Emanuel @ 2011-10-12 4:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318270538-30450-10-git-send-email-thomas.abraham@linaro.org>
On Mon, Oct 10, 2011 at 9:15 PM, Thomas Abraham
<thomas.abraham@linaro.org> wrote:
<spnip>
> +u8 pdma1_peri[] = {
> + ? ? ? DMACH_UART0_RX,
> + ? ? ? DMACH_UART0_TX,
> + ? ? ? DMACH_UART1_RX,
> + ? ? ? DMACH_UART1_TX,
> + ? ? ? DMACH_UART2_RX,
> + ? ? ? DMACH_UART2_TX,
> + ? ? ? DMACH_UART3_RX,
> + ? ? ? DMACH_UART3_TX,
> + ? ? ? DMACH_IRDA,
> + ? ? ? DMACH_I2S0_RX,
> + ? ? ? DMACH_I2S0_TX,
> + ? ? ? DMACH_I2S0S_TX,
> + ? ? ? DMACH_I2S1_RX,
> + ? ? ? DMACH_I2S1_TX,
> + ? ? ? DMACH_I2S2_RX,
> + ? ? ? DMACH_I2S2_TX,
> + ? ? ? DMACH_SPI0_RX,
> + ? ? ? DMACH_SPI0_TX,
> + ? ? ? DMACH_SPI1_RX,
> + ? ? ? DMACH_SPI1_TX,
> + ? ? ? DMACH_SPI2_RX,
> + ? ? ? DMACH_SPI2_TX,
> + ? ? ? DMACH_PCM0_RX,
> + ? ? ? DMACH_PCM1_TX,
typo ? DMACH_PCM0_TX
> + ? ? ? DMACH_PCM1_RX,
> + ? ? ? DMACH_PCM1_TX,
> + ? ? ? DMACH_MSM_REQ0,
> + ? ? ? DMACH_MSM_REQ1,
> + ? ? ? DMACH_MSM_REQ2,
> + ? ? ? DMACH_MSM_REQ3,
> ?};
^ permalink raw reply
* [PATCH v6 09/10] ARM: S5PC100: Modify platform data for pl330 driver
From: Thomas Abraham @ 2011-10-12 4:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJL_dMvX-_ZpvJOUuD28RnoQpz6GFYiTvsWidfy3yeiu3Q04bA@mail.gmail.com>
Hi Anca,
On 12 October 2011 09:41, Anca Emanuel <anca.emanuel@gmail.com> wrote:
> On Mon, Oct 10, 2011 at 9:15 PM, Thomas Abraham
> <thomas.abraham@linaro.org> wrote:
> <spnip>
>
>> +u8 pdma1_peri[] = {
>> + ? ? ? DMACH_UART0_RX,
>> + ? ? ? DMACH_UART0_TX,
>> + ? ? ? DMACH_UART1_RX,
>> + ? ? ? DMACH_UART1_TX,
>> + ? ? ? DMACH_UART2_RX,
>> + ? ? ? DMACH_UART2_TX,
>> + ? ? ? DMACH_UART3_RX,
>> + ? ? ? DMACH_UART3_TX,
>> + ? ? ? DMACH_IRDA,
>> + ? ? ? DMACH_I2S0_RX,
>> + ? ? ? DMACH_I2S0_TX,
>> + ? ? ? DMACH_I2S0S_TX,
>> + ? ? ? DMACH_I2S1_RX,
>> + ? ? ? DMACH_I2S1_TX,
>> + ? ? ? DMACH_I2S2_RX,
>> + ? ? ? DMACH_I2S2_TX,
>> + ? ? ? DMACH_SPI0_RX,
>> + ? ? ? DMACH_SPI0_TX,
>> + ? ? ? DMACH_SPI1_RX,
>> + ? ? ? DMACH_SPI1_TX,
>> + ? ? ? DMACH_SPI2_RX,
>> + ? ? ? DMACH_SPI2_TX,
>> + ? ? ? DMACH_PCM0_RX,
>> + ? ? ? DMACH_PCM1_TX,
>
> typo ? ?DMACH_PCM0_TX
Yes. That is a mistake. I cross-checked others with the user manual
and they are fine.
Thanks for pointing this out.
Regards,
Thomas.
>
>> + ? ? ? DMACH_PCM1_RX,
>> + ? ? ? DMACH_PCM1_TX,
>> + ? ? ? DMACH_MSM_REQ0,
>> + ? ? ? DMACH_MSM_REQ1,
>> + ? ? ? DMACH_MSM_REQ2,
>> + ? ? ? DMACH_MSM_REQ3,
>> ?};
>
^ permalink raw reply
* [PATCH v6 09/10] ARM: S5PC100: Modify platform data for pl330 driver
From: Kukjin Kim @ 2011-10-12 4:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJuYYwSj4D1bMbUtaPe=33GrS=e1_7+POHRWCb8Yzgpv8_Muzg@mail.gmail.com>
Thomas Abraham wrote:
>
> Hi Anca,
>
> On 12 October 2011 09:41, Anca Emanuel <anca.emanuel@gmail.com> wrote:
> > On Mon, Oct 10, 2011 at 9:15 PM, Thomas Abraham
> > <thomas.abraham@linaro.org> wrote:
> > <spnip>
> >
> >> +u8 pdma1_peri[] = {
> >> + ? ? ? DMACH_UART0_RX,
> >> + ? ? ? DMACH_UART0_TX,
> >> + ? ? ? DMACH_UART1_RX,
> >> + ? ? ? DMACH_UART1_TX,
> >> + ? ? ? DMACH_UART2_RX,
> >> + ? ? ? DMACH_UART2_TX,
> >> + ? ? ? DMACH_UART3_RX,
> >> + ? ? ? DMACH_UART3_TX,
> >> + ? ? ? DMACH_IRDA,
> >> + ? ? ? DMACH_I2S0_RX,
> >> + ? ? ? DMACH_I2S0_TX,
> >> + ? ? ? DMACH_I2S0S_TX,
> >> + ? ? ? DMACH_I2S1_RX,
> >> + ? ? ? DMACH_I2S1_TX,
> >> + ? ? ? DMACH_I2S2_RX,
> >> + ? ? ? DMACH_I2S2_TX,
> >> + ? ? ? DMACH_SPI0_RX,
> >> + ? ? ? DMACH_SPI0_TX,
> >> + ? ? ? DMACH_SPI1_RX,
> >> + ? ? ? DMACH_SPI1_TX,
> >> + ? ? ? DMACH_SPI2_RX,
> >> + ? ? ? DMACH_SPI2_TX,
> >> + ? ? ? DMACH_PCM0_RX,
> >> + ? ? ? DMACH_PCM1_TX,
> >
> > typo ? ?DMACH_PCM0_TX
>
> Yes. That is a mistake. I cross-checked others with the user manual
> and they are fine.
>
OK, I think you don't need to re-send because I can fix it when I apply.
It would be helpful to me if you could check your patches again :)
If any problems, please let me know.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
> Thanks for pointing this out.
>
> >
> >> + ? ? ? DMACH_PCM1_RX,
> >> + ? ? ? DMACH_PCM1_TX,
> >> + ? ? ? DMACH_MSM_REQ0,
> >> + ? ? ? DMACH_MSM_REQ1,
> >> + ? ? ? DMACH_MSM_REQ2,
> >> + ? ? ? DMACH_MSM_REQ3,
> >> ?};
> >
^ permalink raw reply
* [PATCH v6 00/10] Add device tree support for PL330 dma controller driver
From: Kukjin Kim @ 2011-10-12 5:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318351780.1546.358.camel@vkoul-udesk3>
Vinod Koul wrote:
>
> On Tue, 2011-10-11 at 21:06 +0900, Kukjin Kim wrote:
> > Thomas Abraham wrote:
> >
> > Hi,
> >
> > Looks ok to me and if required,
> > Acked-by: Kukjin Kim <kgene.kim@samsung.com>
> >
> > And I hope since this includes many changes of arch/arm/Samsung stuff, this
> > would be sent to upstream via Samsung tree after ack from Vinod for dma
> > stuff.
> Sure, looks fine to me
> Acked-by: Vinod Koul <vinod.koul@intel.com>
>
Hi Vinod,
OK, I will apply this series to send to upstream via Samsung tree. If you need branch to apply in your tree, please let me know.
As a note, Boojin Kim will test this series based on boards with -next of Samsung tree before sending to upstream even though I know Thomas tested and it works fine :)
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH 5/7] ARM: EXYNOS4: Add support external GIC
From: Kukjin Kim @ 2011-10-12 5:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E944508.4050202@arm.com>
Marc Zyngier wrote:
>
> Hi Changwan,
>
> On 11/10/11 13:22, Changhwan Youn wrote:
> >> Kukjin, could you please comment on the presence of a common memory
> >> region for the distributor? This seem quite odd...
> >
> > Some registers in Distributor are banked for PPI and SGI support (banked
> interrupts).
> > The register for pending and enable status of these interrupts are
> > banked.
>
> Right, that explains it then.
>
> > Marc, I think the approach in your patch is much better than mine if it
doesn't hurt
> > the performance of other platforms which use the common gic code.
>
> It probably doesn't hurt the general case too much (I expect a bit more
> pressure on the d-cache because of the per-cpu stuff, but nothing to be
> too worried about).
>
> > I'll re-work the exynos4 interrupt code based on your patch though
> > I'm not sure that it's possible to be merged in merge window.
>
> My main concern at the moment is that mainline is broken as far as
> EXYNOS4 is concerned (there's a race with the EOI hook), so that should
> get fixed first.
>
Hi Marc,
OK. I agree with Will and your opinions and I think Changhwan can fix it as
per your suggestion, but he needs fixed/updated regarding gic codes to avoid
re-work and conflicts with others. So it would be better to us if he could
fix it after merging your patches even probably at the end of upcoming merge
window. I hope he can do it before v3.2-rc1.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* [PATCH v6 00/10] Add device tree support for PL330 dma controller driver
From: Vinod Koul @ 2011-10-12 5:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <063701cc889c$3e10dcf0$ba3296d0$%kim@samsung.com>
On Wed, 2011-10-12 at 14:03 +0900, Kukjin Kim wrote:
> Vinod Koul wrote:
> >
> > On Tue, 2011-10-11 at 21:06 +0900, Kukjin Kim wrote:
> > > Thomas Abraham wrote:
> > >
> > > Hi,
> > >
> > > Looks ok to me and if required,
> > > Acked-by: Kukjin Kim <kgene.kim@samsung.com>
> > >
> > > And I hope since this includes many changes of arch/arm/Samsung stuff, this
> > > would be sent to upstream via Samsung tree after ack from Vinod for dma
> > > stuff.
> > Sure, looks fine to me
> > Acked-by: Vinod Koul <vinod.koul@intel.com>
> >
> Hi Vinod,
>
> OK, I will apply this series to send to upstream via Samsung tree. If
> you need branch to apply in your tree, please let me know.
If you send to linus and there are no dependencies then I don't need to
do anything...
--
~Vinod
^ permalink raw reply
* [PATCH V3 3/3] ARM: SAMSUNG: Add lookup of sdhci-s3c clocks using generic names
From: Rajeshwari Birje @ 2011-10-12 5:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201110111122.08241.heiko@sntech.de>
Hi Heiko,
As mentioned in the cover-letter, these patches are based on UART
clkdev patches, hence you need to apply the same before applying these
patches.
I have made these patches on top of the For-next branch of Kgene's
tree, following is the url for the same:
git://github.com/kgene/linux-samsung.git
Regarding the issue:
> this would lead to the hsmmc1 hclk being registered twice, as it is already
> registered in plat-s3c24xx/clock-2443.c .
Will correct the issue and resend the patch.
Regards,
Rajeshwari Shinde.
On Tue, Oct 11, 2011 at 2:52 PM, Heiko St?bner <heiko@sntech.de> wrote:
> Hi,
>
> somehow this did not apply against linux-next for me:
>
> error: patch failed: arch/arm/mach-exynos4/clock.c:1250
> error: arch/arm/mach-exynos4/clock.c: patch does not apply
> error: patch failed: arch/arm/mach-s3c64xx/clock.c:697
> error: arch/arm/mach-s3c64xx/clock.c: patch does not apply
> error: patch failed: arch/arm/mach-s5pc100/clock.c:1099
> error: arch/arm/mach-s5pc100/clock.c: patch does not apply
> error: patch failed: arch/arm/mach-s5pv210/clock.c:1030
> error: arch/arm/mach-s5pv210/clock.c: patch does not apply
>
> and:
>
> Am Dienstag, 11. Oktober 2011, 10:15:07 schrieb Rajeshwari Shinde:
>> Add support for lookup of sdhci-s3c controller clocks using generic names
>> for s3c2416, s3c64xx, s5pc100, s5pv210 and exynos4 SoC's.
> [...]
>> @@ -125,6 +124,14 @@ static struct clk hsmmc0_clk = {
>> ? ? ? .ctrlbit ? ? ? ?= S3C2416_HCLKCON_HSMMC0,
>> ?};
>>
>> +static struct clk hsmmc1_clk = {
>> + ? ? .name ? ? ? ? ? = "hsmmc",
>> + ? ? .devname ? ? ? ?= "s3c-sdhci.1",
>> + ? ? .parent ? ? ? ? = &clk_h,
>> + ? ? .enable ? ? ? ? = s3c2443_clkcon_enable_h,
>> + ? ? .ctrlbit ? ? ? ?= S3C2443_HCLKCON_HSMMC,
>> +};
>> +
> this would lead to the hsmmc1 hclk being registered twice, as it is already
> registered in plat-s3c24xx/clock-2443.c .
>
> How about the following, which also adds the lookup for the s3c2443-specific
> hsmmc-sclk.
>
> Heiko
>
> diff --git a/arch/arm/mach-s3c2416/clock.c b/arch/arm/mach-s3c2416/clock.c
> index 72b7c62..0b0b7c2 100644
> --- a/arch/arm/mach-s3c2416/clock.c
> +++ b/arch/arm/mach-s3c2416/clock.c
> @@ -82,39 +82,38 @@ static struct clksrc_clk hsmmc_div[] = {
> ? ? ? ?},
> ?};
>
> -static struct clksrc_clk hsmmc_mux[] = {
> - ? ? ? [0] = {
> - ? ? ? ? ? ? ? .clk ? ?= {
> - ? ? ? ? ? ? ? ? ? ? ? .name ? = "hsmmc-if",
> - ? ? ? ? ? ? ? ? ? ? ? .devname ? ? ? ?= "s3c-sdhci.0",
> - ? ? ? ? ? ? ? ? ? ? ? .ctrlbit = (1 << 6),
> - ? ? ? ? ? ? ? ? ? ? ? .enable = s3c2443_clkcon_enable_s,
> - ? ? ? ? ? ? ? },
> - ? ? ? ? ? ? ? .sources = &(struct clksrc_sources) {
> - ? ? ? ? ? ? ? ? ? ? ? .nr_sources = 2,
> - ? ? ? ? ? ? ? ? ? ? ? .sources = (struct clk *[]) {
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [0] = &hsmmc_div[0].clk,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [1] = NULL, /* to fix */
> - ? ? ? ? ? ? ? ? ? ? ? },
> - ? ? ? ? ? ? ? },
> - ? ? ? ? ? ? ? .reg_src = { .reg = S3C2443_CLKSRC, .size = 1, .shift = 16 },
> +static struct clksrc_clk hsmmc_mux0 = {
> + ? ? ? .clk ? ?= {
> + ? ? ? ? ? ? ? .name ? = "hsmmc-if",
> + ? ? ? ? ? ? ? .devname ? ? ? ?= "s3c-sdhci.0",
> + ? ? ? ? ? ? ? .ctrlbit = (1 << 6),
> + ? ? ? ? ? ? ? .enable = s3c2443_clkcon_enable_s,
> ? ? ? ?},
> - ? ? ? [1] = {
> - ? ? ? ? ? ? ? .clk ? ?= {
> - ? ? ? ? ? ? ? ? ? ? ? .name ? = "hsmmc-if",
> - ? ? ? ? ? ? ? ? ? ? ? .devname ? ? ? ?= "s3c-sdhci.1",
> - ? ? ? ? ? ? ? ? ? ? ? .ctrlbit = (1 << 12),
> - ? ? ? ? ? ? ? ? ? ? ? .enable = s3c2443_clkcon_enable_s,
> + ? ? ? .sources = &(struct clksrc_sources) {
> + ? ? ? ? ? ? ? .nr_sources = 2,
> + ? ? ? ? ? ? ? .sources = (struct clk * []) {
> + ? ? ? ? ? ? ? ? ? ? ? [0] = &hsmmc_div[0].clk,
> + ? ? ? ? ? ? ? ? ? ? ? [1] = NULL, /* to fix */
> ? ? ? ? ? ? ? ?},
> - ? ? ? ? ? ? ? .sources = &(struct clksrc_sources) {
> - ? ? ? ? ? ? ? ? ? ? ? .nr_sources = 2,
> - ? ? ? ? ? ? ? ? ? ? ? .sources = (struct clk *[]) {
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [0] = &hsmmc_div[1].clk,
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [1] = NULL, /* to fix */
> - ? ? ? ? ? ? ? ? ? ? ? },
> + ? ? ? },
> + ? ? ? .reg_src = { .reg = S3C2443_CLKSRC, .size = 1, .shift = 16 },
> +};
> +
> +static struct clksrc_clk hsmmc_mux1 = {
> + ? ? ? .clk ? ?= {
> + ? ? ? ? ? ? ? .name ? = "hsmmc-if",
> + ? ? ? ? ? ? ? .devname ? ? ? ?= "s3c-sdhci.1",
> + ? ? ? ? ? ? ? .ctrlbit = (1 << 12),
> + ? ? ? ? ? ? ? .enable = s3c2443_clkcon_enable_s,
> + ? ? ? },
> + ? ? ? .sources = &(struct clksrc_sources) {
> + ? ? ? ? ? ? ? .nr_sources = 2,
> + ? ? ? ? ? ? ? .sources = (struct clk * []) {
> + ? ? ? ? ? ? ? ? ? ? ? [0] = &hsmmc_div[1].clk,
> + ? ? ? ? ? ? ? ? ? ? ? [1] = NULL, /* to fix */
> ? ? ? ? ? ? ? ?},
> - ? ? ? ? ? ? ? .reg_src = { .reg = S3C2443_CLKSRC, .size = 1, .shift = 17 },
> ? ? ? ?},
> + ? ? ? .reg_src = { .reg = S3C2443_CLKSRC, .size = 1, .shift = 17 },
> ?};
>
> ?static struct clk hsmmc0_clk = {
> @@ -137,14 +136,19 @@ void __init_or_cpufreq s3c2416_setup_clocks(void)
> ? ? ? ?s3c2443_common_setup_clocks(s3c2416_get_pll, s3c2416_fclk_div);
> ?}
>
> -
> ?static struct clksrc_clk *clksrcs[] __initdata = {
> ? ? ? ?&hsspi_eplldiv,
> ? ? ? ?&hsspi_mux,
> ? ? ? ?&hsmmc_div[0],
> ? ? ? ?&hsmmc_div[1],
> - ? ? ? &hsmmc_mux[0],
> - ? ? ? &hsmmc_mux[1],
> + ? ? ? &hsmmc_mux0,
> + ? ? ? &hsmmc_mux1,
> +};
> +
> +static struct clk_lookup s3c2416_clk_lookup[] = {
> + ? ? ? CLKDEV_INIT("s3c-sdhci.0", "mmc_busclk.0", &hsmmc0_clk),
> + ? ? ? CLKDEV_INIT("s3c-sdhci.0", "mmc_busclk.2", &hsmmc_mux0.clk),
> + ? ? ? CLKDEV_INIT("s3c-sdhci.1", "mmc_busclk.2", &hsmmc_mux1.clk),
> ?};
>
> ?void __init s3c2416_init_clocks(int xtal)
> @@ -164,6 +168,7 @@ void __init s3c2416_init_clocks(int xtal)
> ? ? ? ? ? ? ? ?s3c_register_clksrc(clksrcs[ptr], 1);
>
> ? ? ? ?s3c24xx_register_clock(&hsmmc0_clk);
> + ? ? ? clkdev_add_table(s3c2416_clk_lookup, ARRAY_SIZE(s3c2416_clk_lookup));
>
> ? ? ? ?s3c_pwmclk_init();
>
> diff --git a/arch/arm/mach-s3c2443/clock.c b/arch/arm/mach-s3c2443/clock.c
> index cd51d04..38ca7df 100644
> --- a/arch/arm/mach-s3c2443/clock.c
> +++ b/arch/arm/mach-s3c2443/clock.c
> @@ -275,6 +275,8 @@ void __init_or_cpufreq s3c2443_setup_clocks(void)
> ? ? ? ?s3c2443_common_setup_clocks(s3c2443_get_mpll, s3c2443_fclk_div);
> ?}
>
> +static struct clk_lookup hsmmc_lookup = CLKDEV_INIT("s3c-sdhci.1", "mmc_busclk.2", &clk_hsmmc);
> +
> ?void __init s3c2443_init_clocks(int xtal)
> ?{
> ? ? ? ?unsigned long epllcon = __raw_readl(S3C2443_EPLLCON);
> @@ -292,6 +294,8 @@ void __init s3c2443_init_clocks(int xtal)
> ? ? ? ?for (ptr = 0; ptr < ARRAY_SIZE(clksrcs); ptr++)
> ? ? ? ? ? ? ? ?s3c_register_clksrc(clksrcs[ptr], 1);
>
> + ? ? ? clkdev_add(&hsmmc_lookup);
> +
> ? ? ? ?/* register clocks from clock array */
>
> ? ? ? ?s3c_register_clocks(init_clocks, ARRAY_SIZE(init_clocks));
> diff --git a/arch/arm/plat-s3c24xx/s3c2443-clock.c b/arch/arm/plat-s3c24xx/s3c2443-clock.c
> index 07a4c81..6997819 100644
> --- a/arch/arm/plat-s3c24xx/s3c2443-clock.c
> +++ b/arch/arm/plat-s3c24xx/s3c2443-clock.c
> @@ -307,11 +307,6 @@ static struct clk init_clocks[] = {
> ? ? ? ? ? ? ? ?.enable ? ? ? ? = s3c2443_clkcon_enable_h,
> ? ? ? ? ? ? ? ?.ctrlbit ? ? ? ?= S3C2443_HCLKCON_DMA5,
> ? ? ? ?}, {
> - ? ? ? ? ? ? ? .name ? ? ? ? ? = "hsmmc",
> - ? ? ? ? ? ? ? .parent ? ? ? ? = &clk_h,
> - ? ? ? ? ? ? ? .enable ? ? ? ? = s3c2443_clkcon_enable_h,
> - ? ? ? ? ? ? ? .ctrlbit ? ? ? ?= S3C2443_HCLKCON_HSMMC,
> - ? ? ? }, {
> ? ? ? ? ? ? ? ?.name ? ? ? ? ? = "gpio",
> ? ? ? ? ? ? ? ?.parent ? ? ? ? = &clk_p,
> ? ? ? ? ? ? ? ?.enable ? ? ? ? = s3c2443_clkcon_enable_p,
> @@ -393,6 +388,14 @@ static struct clk init_clocks[] = {
> ? ? ? ?}
> ?};
>
> +static struct clk hsmmc1_clk = {
> + ? ? ? .name ? ? ? ? ? = "hsmmc",
> + ? ? ? .devname ? ? ? ?= "s3c-sdhci.1",
> + ? ? ? .parent ? ? ? ? = &clk_h,
> + ? ? ? .enable ? ? ? ? = s3c2443_clkcon_enable_h,
> + ? ? ? .ctrlbit ? ? ? ?= S3C2443_HCLKCON_HSMMC,
> +};
> +
> ?static inline unsigned long s3c2443_get_hdiv(unsigned long clkcon0)
> ?{
> ? ? ? ?clkcon0 &= S3C2443_CLKDIV0_HCLKDIV_MASK;
> @@ -469,6 +472,8 @@ static struct clksrc_clk *clksrcs[] __initdata = {
> ? ? ? ?&clk_msysclk,
> ?};
>
> +static struct clk_lookup hsmmc_lookup = CLKDEV_INIT("s3c-sdhci.1", "mmc_busclk.0", &hsmmc1_clk);
> +
> ?void __init s3c2443_common_init_clocks(int xtal, pll_fn get_mpll,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? fdiv_fn get_fdiv)
> ?{
> @@ -490,6 +495,9 @@ void __init s3c2443_common_init_clocks(int xtal, pll_fn get_mpll,
> ? ? ? ?s3c_register_clksrc(clksrc_clks, ARRAY_SIZE(clksrc_clks));
> ? ? ? ?s3c_register_clocks(init_clocks, ARRAY_SIZE(init_clocks));
>
> + ? ? ? s3c24xx_register_clock(&hsmmc1_clk);
> + ? ? ? clkdev_add(&hsmmc_lookup);
> +
> ? ? ? ?/* See s3c2443/etc notes on disabling clocks at init time */
> ? ? ? ?s3c_register_clocks(init_clocks_off, ARRAY_SIZE(init_clocks_off));
> ? ? ? ?s3c_disable_clocks(init_clocks_off, ARRAY_SIZE(init_clocks_off));
> --
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" 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 v6 03/10] ARM: EXYNOS4: Modify platform data for pl330 driver
From: Thomas Abraham @ 2011-10-12 5:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318270538-30450-4-git-send-email-thomas.abraham@linaro.org>
Dear Mr. Kim,
On 10 October 2011 23:45, Thomas Abraham <thomas.abraham@linaro.org> wrote:
> With the 'struct dma_pl330_peri' removed, the platfrom data for dma
> driver can be simplified to a simple list of peripheral request ids.
>
> Cc: Jassi Brar <jassisinghbrar@gmail.com>
> Cc: Boojin Kim <boojin.kim@samsung.com>
> Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> ?arch/arm/mach-exynos4/dma.c | ?223 ++++++++++++-------------------------------
> ?1 files changed, 62 insertions(+), 161 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/dma.c b/arch/arm/mach-exynos4/dma.c
> index 9667c61..c3c0d17 100644
> --- a/arch/arm/mach-exynos4/dma.c
> +++ b/arch/arm/mach-exynos4/dma.c
> @@ -35,95 +35,40 @@
>
> ?static u64 dma_dmamask = DMA_BIT_MASK(32);
>
> -struct dma_pl330_peri pdma0_peri[28] = {
> - ? ? ? {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_PCM0_RX,
> - ? ? ? ? ? ? ? .rqtype = DEVTOMEM,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_PCM0_TX,
> - ? ? ? ? ? ? ? .rqtype = MEMTODEV,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_PCM2_RX,
> - ? ? ? ? ? ? ? .rqtype = DEVTOMEM,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_PCM2_TX,
> - ? ? ? ? ? ? ? .rqtype = MEMTODEV,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_MSM_REQ0,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_MSM_REQ2,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_SPI0_RX,
> - ? ? ? ? ? ? ? .rqtype = DEVTOMEM,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_SPI0_TX,
> - ? ? ? ? ? ? ? .rqtype = MEMTODEV,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_SPI2_RX,
> - ? ? ? ? ? ? ? .rqtype = DEVTOMEM,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_SPI2_TX,
> - ? ? ? ? ? ? ? .rqtype = MEMTODEV,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_I2S0S_TX,
> - ? ? ? ? ? ? ? .rqtype = MEMTODEV,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_I2S0_RX,
> - ? ? ? ? ? ? ? .rqtype = DEVTOMEM,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_I2S0_TX,
> - ? ? ? ? ? ? ? .rqtype = MEMTODEV,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_UART0_RX,
> - ? ? ? ? ? ? ? .rqtype = DEVTOMEM,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_UART0_TX,
> - ? ? ? ? ? ? ? .rqtype = MEMTODEV,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_UART2_RX,
> - ? ? ? ? ? ? ? .rqtype = DEVTOMEM,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_UART2_TX,
> - ? ? ? ? ? ? ? .rqtype = MEMTODEV,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_UART4_RX,
> - ? ? ? ? ? ? ? .rqtype = DEVTOMEM,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_UART4_TX,
> - ? ? ? ? ? ? ? .rqtype = MEMTODEV,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_SLIMBUS0_RX,
> - ? ? ? ? ? ? ? .rqtype = DEVTOMEM,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_SLIMBUS0_TX,
> - ? ? ? ? ? ? ? .rqtype = MEMTODEV,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_SLIMBUS2_RX,
> - ? ? ? ? ? ? ? .rqtype = DEVTOMEM,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_SLIMBUS2_TX,
> - ? ? ? ? ? ? ? .rqtype = MEMTODEV,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_SLIMBUS4_RX,
> - ? ? ? ? ? ? ? .rqtype = DEVTOMEM,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_SLIMBUS4_TX,
> - ? ? ? ? ? ? ? .rqtype = MEMTODEV,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_AC97_MICIN,
> - ? ? ? ? ? ? ? .rqtype = DEVTOMEM,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_AC97_PCMIN,
> - ? ? ? ? ? ? ? .rqtype = DEVTOMEM,
> - ? ? ? }, {
> - ? ? ? ? ? ? ? .peri_id = (u8)DMACH_AC97_PCMOUT,
> - ? ? ? ? ? ? ? .rqtype = MEMTODEV,
> - ? ? ? },
> +u8 pdma0_peri[] = {
> + ? ? ? DMACH_PCM0_RX,
> + ? ? ? DMACH_PCM0_TX,
> + ? ? ? DMACH_PCM2_RX,
> + ? ? ? DMACH_PCM2_TX,
> + ? ? ? DMACH_MSM_REQ0,
> + ? ? ? DMACH_MSM_REQ2,
> + ? ? ? DMACH_SPI0_RX,
> + ? ? ? DMACH_SPI0_TX,
> + ? ? ? DMACH_SPI2_RX,
> + ? ? ? DMACH_SPI2_TX,
> + ? ? ? DMACH_I2S0S_TX,
> + ? ? ? DMACH_I2S0_RX,
> + ? ? ? DMACH_I2S0_TX,
As you have suggested, I have rechecked the platform data for all s5p
platforms in this patchset. Here, DMACH_I2S2_RX (event id 13) and
DMACH_I2S2_TX (event id 14) of DMAC[0] are missing as per the
exynos4210 user manual. But these where missing in the original code
as well which this patch modified. If possible, could you please let
me know if DMACH_I2S2_RX and DMACH_I2S2_TX are indeed event id 13 and
14 in DMAC[0].
I have rechecked the other s5p platform data for dmac (s5p64x0,
s5pc100, s5pv210). Apart from the typo pointed out by Anca for
s5pc100, there are no other issues.
Thanks,
Thomas.
> + ? ? ? DMACH_UART0_RX,
> + ? ? ? DMACH_UART0_TX,
> + ? ? ? DMACH_UART2_RX,
> + ? ? ? DMACH_UART2_TX,
> + ? ? ? DMACH_UART4_RX,
> + ? ? ? DMACH_UART4_TX,
> + ? ? ? DMACH_SLIMBUS0_RX,
> + ? ? ? DMACH_SLIMBUS0_TX,
> + ? ? ? DMACH_SLIMBUS2_RX,
> + ? ? ? DMACH_SLIMBUS2_TX,
> + ? ? ? DMACH_SLIMBUS4_RX,
> + ? ? ? DMACH_SLIMBUS4_TX,
> + ? ? ? DMACH_AC97_MICIN,
> + ? ? ? DMACH_AC97_PCMIN,
> + ? ? ? DMACH_AC97_PCMOUT,
> ?};
>
> ?struct dma_pl330_platdata exynos4_pdma0_pdata = {
> ? ? ? ?.nr_valid_peri = ARRAY_SIZE(pdma0_peri),
> - ? ? ? .peri = pdma0_peri,
> + ? ? ? .peri_id = pdma0_peri,
> ?};
>
[...]
^ permalink raw reply
* [Linaro-mm-sig] [PATCH 1/2] ARM: initial proof-of-concept IOMMU mapper for DMA-mapping
From: Marek Szyprowski @ 2011-10-12 5:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <401E54CE964CD94BAE1EB4A729C7087E3722519BF4@HQMAIL04.nvidia.com>
Hello,
On Wednesday, October 12, 2011 3:35 AM Krishna Reddy wrote:
> >>It looks that You have simplified arm_iommu_map_sg() function too much.
> >>The main advantage of the iommu is to map scattered memory pages into
> >>contiguous dma address space. DMA-mapping is allowed to merge consecutive
> >>entries in the scatter list if hardware supports that.
> >>http://article.gmane.org/gmane.linux.kernel/1128416
> >I would update arm_iommu_map_sg() back to coalesce the sg list.
> >>MMC drivers seem to be aware of coalescing the SG entries together as they are using
> dma_sg_len().
>
> I have updated the arm_iommu_map_sg() back to coalesce and fixed the issues with it. During
> testing, I found out that mmc host driver doesn't support buffers bigger than 64K. To get the
> device working, I had to break the sg entries coalesce when dma_length is about to go beyond
> 64KB. Looks like Mmc host driver(sdhci.c) need to be fixed to handle buffers bigger than 64KB.
> Should the clients be forced to handle bigger buffers or is there any better way to handle
> these kind of issues?
There is struct device_dma_parameters *dma_parms member of struct device. You can specify
maximum segment size for the dma_map_sg function. This will of course complicate this function
even more...
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
^ permalink raw reply
* [RFC/PATCH 5/7] ARM: Move get_thread_info macro definition to <asm/assembler.h>
From: gdavis at mvista.com @ 2011-10-12 6:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111011095639.GB23848@arm.com>
On Tue, Oct 11, 2011 at 10:56:39AM +0100, Catalin Marinas wrote:
> On Fri, Oct 07, 2011 at 03:38:39AM +0100, gdavis at mvista.com wrote:
> > diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
> > index 29035e8..78397d0 100644
> > --- a/arch/arm/include/asm/assembler.h
> > +++ b/arch/arm/include/asm/assembler.h
> > @@ -23,6 +23,19 @@
> > #include <asm/ptrace.h>
> > #include <asm/domain.h>
> >
> > +#ifndef CONFIG_THUMB2_KERNEL
> > + .macro get_thread_info, rd
> > + mov \rd, sp, lsr #13
> > + mov \rd, \rd, lsl #13
> > + .endm
> > +#else /* CONFIG_THUMB2_KERNEL */
> > + .macro get_thread_info, rd
> > + mov \rd, sp
> > + lsr \rd, \rd, #13
> > + mov \rd, \rd, lsl #13
> > + .endm
> > +#endif /* !CONFIG_THUMB2_KERNEL */
>
> We could even write some preempt_enable and preempt_disable asm macros,
> I think it would simplify the code in the other files.
Like so (based on above patch and not even compile tested):
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 78397d0..eaf4939 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -36,6 +36,20 @@
.endm
#endif /* !CONFIG_THUMB2_KERNEL */
+ .macro preempt_disable, tsk, cnt
+ get_thread_info \tsk
+ ldr \cnt, [\tsk, #TI_PREEMPT]
+ add \cnt, \cnt, #1
+ str \cnt, [\tsk, #TI_PREEMPT]
+ .endm
+
+ .macro preempt_enable, tsk, cnt
+ get_thread_info \tsk
+ ldr \cnt, [\tsk, #TI_PREEMPT]
+ sub \cnt, \cnt, #1
+ str \cnt, [\tsk, #TI_PREEMPT]
+ .endm
+
/*
* Endian independent macros for shifting bytes within registers.
*/
Not as efficient as it could be but I imagine the macros could
be written to support optional load of \tsk and/or optional \tmp
parameters to cover other common cases.
--
Regards,
George
>
> --
> Catalin
^ permalink raw reply related
* [PATCH 4/5] gpiolib: handle deferral probe error
From: G, Manjunath Kondaiah @ 2011-10-12 6:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACxGe6tmjQGw77NMNYLWJHMAtmF9fk_9HnHtbrMhzkKEC1HG=Q@mail.gmail.com>
On Fri, Oct 07, 2011 at 04:09:38PM -0600, Grant Likely wrote:
> On Fri, Oct 7, 2011 at 4:06 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > On Fri, 07 Oct 2011 10:33:09 +0500
> > "G, Manjunath Kondaiah" <manjugk@ti.com> wrote:
> >
> >>
> >> The gpio library should return -EPROBE_DEFER in gpio_request
> >> if gpio driver is not ready.
> >
> > Why not use the perfectly good existing error codes we have for this ?
> >
> > We have EAGAIN and EUNATCH both of which look sensible.
>
> I want a distinct error code for probe deferral so that a) it doesn't
> overlap with something a driver is already doing, and b) so that all
> the users can be found again at a later date.
>
> That said, I'm not in agreement with this patch. It is fine for gpio
> lib to have a code that means the pin doesn't exist (yet), but the
> device driver needs to be the one to decide whether or not it is
> appropriate to use probe deferral.
During gpio_request, driver gpio_request is not available. How can we expect
driver to request deferred probe in this case?
-M
^ permalink raw reply
* [PATCH 1/5] drivercore: add new error value for deferred probe
From: G, Manjunath Kondaiah @ 2011-10-12 6:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111010010656.GA16537@kroah.com>
On Sun, Oct 09, 2011 at 06:06:56PM -0700, Greg KH wrote:
> On Sun, Oct 09, 2011 at 04:59:31PM -0600, Grant Likely wrote:
> > On Fri, Oct 7, 2011 at 6:12 PM, Greg KH <greg@kroah.com> wrote:
> > > On Fri, Oct 07, 2011 at 07:28:33PM -0400, Valdis.Kletnieks at vt.edu wrote:
> > >> On Fri, 07 Oct 2011 16:12:45 MDT, Grant Likely said:
> > >> > On Fri, Oct 7, 2011 at 12:43 AM, Greg KH <greg@kroah.com> wrote:
> > >> > > On Fri, Oct 07, 2011 at 10:33:06AM +0500, G, Manjunath Kondaiah wrote:
> > >>
> > >> > >> +#define EPROBE_DEFER 517 ? ? /* restart probe again after some time */
> > >> > >
> > >> > > Can we really do this?
> > >>
> > >> > According to Arnd, yes this is okay.
> > >>
> > >> > > ?Isn't this some user/kernel api here?
> > >>
> > >> > > What's wrong with just "overloading" on top of an existing error code?
> > >> > > Surely one of the other 516 types could be used here, right?
> > >>
> > >> > overloading makes it really hard to find the users at a later date.
> > >>
> > >> Would proposing '#define EPROBE_DEFER EAGAIN' be acceptable to everybody? That
> > >> would allow overloading EAGAIN, but still make it easy to tell the usages apart
> > >> if we need to separate them later...
> > >
> > > Yes, please do that, it is what USB does for it's internal error code
> > > handling.
> >
> > Really? When we've only currently used approximately 2^9 of a 2^31
> > numberspace? I'm fine with making sure that the number doesn't show
> > up in the userspace headers, but it makes no sense to overload the
> > #defines. Particularly so in this case where it isn't feasible to
> > audit every driver to figure out what probe might possibly return. It
> > is well within the realm of possibility that existing drivers are
> > already returning -EAGAIN.
>
> I doubt they are, but you are right, it's really hard to tell.
>
> > Besides; linux/errno.h *already* has linux-internal error codes that
> > do not get exported out to userspace. There is an #ifdef __KERNEL__
> > block around ERESTARTSYS through EIOCBRETRY which is filtered out when
> > exporting headers. I can't see any possible reason why we wouldn't
> > add Linux internal error codes here.
>
> As long as it stays internal, that's fine, I was worried that this would
> be exported to userspace.
>
> Alan, still object to this?
I hope no one has objections to use EPROBE_DEFER
-M
^ 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