* [PATCH 0/8] mfd: Batch together MFD related patches
From: Lee Jones @ 2012-11-05 15:10 UTC (permalink / raw)
To: linux-arm-kernel
Hi Sam,
I know you've been busy giving NFC presentations at ELC, but ... :)
All these patches have been on the list in various other patch-sets
for some time and have been reviewed by some key people already. All
other patches from the patch-sets have been taken, so I thought I'd
batch these up for easy review/acceptance.
Documentation/devicetree/bindings/mfd/stmpe.txt | 25 ++++
drivers/mfd/ab8500-core.c | 98 ++++-----------
drivers/mfd/db8500-prcmu.c | 8 +-
drivers/mfd/stmpe.c | 151 ++++++++++++++++-------
include/linux/mfd/stmpe.h | 2 +
5 files changed, 160 insertions(+), 124 deletions(-)
^ permalink raw reply
* [PATCH 1/8] mfd: ab8500-core: Remove unused ab8500-gpio IRQ ranges
From: Lee Jones @ 2012-11-05 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352128236-11554-1-git-send-email-lee.jones@linaro.org>
The IRQ ranges provided in ab8500-core to be passed on to the
ab8500-gpio driver are not only redundant, but they are also
causing a warning in the boot log. These IRQ ranges, like any
other MFD related IRQ resource are passed though MFD core for
automatic conversion to virtual IRQs; however, MFD core does
not support IRQ mapping of IRQ ranges. Let's just remove them.
Cc: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/ab8500-core.c | 36 ------------------------------------
1 file changed, 36 deletions(-)
diff --git a/drivers/mfd/ab8500-core.c b/drivers/mfd/ab8500-core.c
index 1667c77..e7197fe 100644
--- a/drivers/mfd/ab8500-core.c
+++ b/drivers/mfd/ab8500-core.c
@@ -591,38 +591,6 @@ int ab8500_suspend(struct ab8500 *ab8500)
return 0;
}
-/* AB8500 GPIO Resources */
-static struct resource __devinitdata ab8500_gpio_resources[] = {
- {
- .name = "GPIO_INT6",
- .start = AB8500_INT_GPIO6R,
- .end = AB8500_INT_GPIO41F,
- .flags = IORESOURCE_IRQ,
- }
-};
-
-/* AB9540 GPIO Resources */
-static struct resource __devinitdata ab9540_gpio_resources[] = {
- {
- .name = "GPIO_INT6",
- .start = AB8500_INT_GPIO6R,
- .end = AB8500_INT_GPIO41F,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = "GPIO_INT14",
- .start = AB9540_INT_GPIO50R,
- .end = AB9540_INT_GPIO54R,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = "GPIO_INT15",
- .start = AB9540_INT_GPIO50F,
- .end = AB9540_INT_GPIO54F,
- .flags = IORESOURCE_IRQ,
- }
-};
-
static struct resource __devinitdata ab8500_gpadc_resources[] = {
{
.name = "HW_CONV_END",
@@ -1065,8 +1033,6 @@ static struct mfd_cell __devinitdata ab8500_devs[] = {
{
.name = "ab8500-gpio",
.of_compatible = "stericsson,ab8500-gpio",
- .num_resources = ARRAY_SIZE(ab8500_gpio_resources),
- .resources = ab8500_gpio_resources,
},
{
.name = "ab8500-usb",
@@ -1083,8 +1049,6 @@ static struct mfd_cell __devinitdata ab8500_devs[] = {
static struct mfd_cell __devinitdata ab9540_devs[] = {
{
.name = "ab8500-gpio",
- .num_resources = ARRAY_SIZE(ab9540_gpio_resources),
- .resources = ab9540_gpio_resources,
},
{
.name = "ab9540-usb",
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/8] mfd: Prevent STMPE from abusing mfd_add_devices' irq_base parameter
From: Lee Jones @ 2012-11-05 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352128236-11554-1-git-send-email-lee.jones@linaro.org>
Originally IRQ incrementers were provided in some template resource
structures for keypad and touchscreen devices. These were passed as
IORESOURCE_IRQs to MFD core in the usual way. The true device IRQs
were instead added to the irq_base when mfd_add_devices was invoked.
This is clearly an abuse of the call, and does not scale when IRQ
Domains are brought into play. Before we can provide the STMPE with
its own IRQ Domain we must first fix this. This patche keeps most
of the driver's structure, keeping the template strategy. However,
instead of providing the IRQ as an increment to irq_base, we
dynamically populate the IORESOURCE_IRQ with the correct device IRQ.
Cc: Samuel Ortiz <sameo@linux.intel.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/stmpe.c | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/mfd/stmpe.c b/drivers/mfd/stmpe.c
index c94f521..ad13cb0 100644
--- a/drivers/mfd/stmpe.c
+++ b/drivers/mfd/stmpe.c
@@ -310,14 +310,10 @@ static struct mfd_cell stmpe_gpio_cell_noirq = {
static struct resource stmpe_keypad_resources[] = {
{
.name = "KEYPAD",
- .start = 0,
- .end = 0,
.flags = IORESOURCE_IRQ,
},
{
.name = "KEYPAD_OVER",
- .start = 1,
- .end = 1,
.flags = IORESOURCE_IRQ,
},
};
@@ -397,14 +393,10 @@ static struct stmpe_variant_info stmpe801_noirq = {
static struct resource stmpe_ts_resources[] = {
{
.name = "TOUCH_DET",
- .start = 0,
- .end = 0,
.flags = IORESOURCE_IRQ,
},
{
.name = "FIFO_TH",
- .start = 1,
- .end = 1,
.flags = IORESOURCE_IRQ,
},
};
@@ -959,10 +951,10 @@ static int __devinit stmpe_chip_init(struct stmpe *stmpe)
}
static int __devinit stmpe_add_device(struct stmpe *stmpe,
- struct mfd_cell *cell, int irq)
+ struct mfd_cell *cell)
{
return mfd_add_devices(stmpe->dev, stmpe->pdata->id, cell, 1,
- NULL, stmpe->irq_base + irq, NULL);
+ NULL, stmpe->irq_base, NULL);
}
static int __devinit stmpe_devices_init(struct stmpe *stmpe)
@@ -970,7 +962,7 @@ static int __devinit stmpe_devices_init(struct stmpe *stmpe)
struct stmpe_variant_info *variant = stmpe->variant;
unsigned int platform_blocks = stmpe->pdata->blocks;
int ret = -EINVAL;
- int i;
+ int i, j;
for (i = 0; i < variant->num_blocks; i++) {
struct stmpe_variant_block *block = &variant->blocks[i];
@@ -978,8 +970,17 @@ static int __devinit stmpe_devices_init(struct stmpe *stmpe)
if (!(platform_blocks & block->block))
continue;
+ for (j = 0; j < block->cell->num_resources; j++) {
+ struct resource *res =
+ (struct resource *) &block->cell->resources[j];
+
+ /* Dynamically fill in a variant's IRQ. */
+ if (res->flags & IORESOURCE_IRQ)
+ res->start = res->end = block->irq + j;
+ }
+
platform_blocks &= ~block->block;
- ret = stmpe_add_device(stmpe, block->cell, block->irq);
+ ret = stmpe_add_device(stmpe, block->cell);
if (ret)
return ret;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/8] mfd: Provide the STMPE driver with its own IRQ domain
From: Lee Jones @ 2012-11-05 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352128236-11554-1-git-send-email-lee.jones@linaro.org>
The STMPE driver is yet another IRQ controller which requires its
own IRQ domain. So, we provide it with one.
Cc: Samuel Ortiz <sameo@linux.intel.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/stmpe.c | 82 +++++++++++++++++++++++++++------------------
include/linux/mfd/stmpe.h | 2 ++
2 files changed, 52 insertions(+), 32 deletions(-)
diff --git a/drivers/mfd/stmpe.c b/drivers/mfd/stmpe.c
index ad13cb0..5c8d8f2 100644
--- a/drivers/mfd/stmpe.c
+++ b/drivers/mfd/stmpe.c
@@ -12,6 +12,7 @@
#include <linux/kernel.h>
#include <linux/interrupt.h>
#include <linux/irq.h>
+#include <linux/irqdomain.h>
#include <linux/pm.h>
#include <linux/slab.h>
#include <linux/mfd/core.h>
@@ -757,7 +758,9 @@ static irqreturn_t stmpe_irq(int irq, void *data)
int i;
if (variant->id_val == STMPE801_ID) {
- handle_nested_irq(stmpe->irq_base);
+ int base = irq_create_mapping(stmpe->domain, 0);
+
+ handle_nested_irq(base);
return IRQ_HANDLED;
}
@@ -778,8 +781,9 @@ static irqreturn_t stmpe_irq(int irq, void *data)
while (status) {
int bit = __ffs(status);
int line = bank * 8 + bit;
+ int nestedirq = irq_create_mapping(stmpe->domain, line);
- handle_nested_irq(stmpe->irq_base + line);
+ handle_nested_irq(nestedirq);
status &= ~(1 << bit);
}
@@ -820,7 +824,7 @@ static void stmpe_irq_sync_unlock(struct irq_data *data)
static void stmpe_irq_mask(struct irq_data *data)
{
struct stmpe *stmpe = irq_data_get_irq_chip_data(data);
- int offset = data->irq - stmpe->irq_base;
+ int offset = data->hwirq;
int regoffset = offset / 8;
int mask = 1 << (offset % 8);
@@ -830,7 +834,7 @@ static void stmpe_irq_mask(struct irq_data *data)
static void stmpe_irq_unmask(struct irq_data *data)
{
struct stmpe *stmpe = irq_data_get_irq_chip_data(data);
- int offset = data->irq - stmpe->irq_base;
+ int offset = data->hwirq;
int regoffset = offset / 8;
int mask = 1 << (offset % 8);
@@ -845,43 +849,62 @@ static struct irq_chip stmpe_irq_chip = {
.irq_unmask = stmpe_irq_unmask,
};
-static int __devinit stmpe_irq_init(struct stmpe *stmpe)
+static int stmpe_irq_map(struct irq_domain *d, unsigned int virq,
+ irq_hw_number_t hwirq)
{
+ struct stmpe *stmpe = d->host_data;
struct irq_chip *chip = NULL;
- int num_irqs = stmpe->variant->num_irqs;
- int base = stmpe->irq_base;
- int irq;
if (stmpe->variant->id_val != STMPE801_ID)
chip = &stmpe_irq_chip;
- for (irq = base; irq < base + num_irqs; irq++) {
- irq_set_chip_data(irq, stmpe);
- irq_set_chip_and_handler(irq, chip, handle_edge_irq);
- irq_set_nested_thread(irq, 1);
+ irq_set_chip_data(virq, stmpe);
+ irq_set_chip_and_handler(virq, chip, handle_edge_irq);
+ irq_set_nested_thread(virq, 1);
#ifdef CONFIG_ARM
- set_irq_flags(irq, IRQF_VALID);
+ set_irq_flags(virq, IRQF_VALID);
#else
- irq_set_noprobe(irq);
+ irq_set_noprobe(virq);
#endif
- }
return 0;
}
-static void stmpe_irq_remove(struct stmpe *stmpe)
+static void stmpe_irq_unmap(struct irq_domain *d, unsigned int virq)
{
- int num_irqs = stmpe->variant->num_irqs;
- int base = stmpe->irq_base;
- int irq;
-
- for (irq = base; irq < base + num_irqs; irq++) {
#ifdef CONFIG_ARM
- set_irq_flags(irq, 0);
+ set_irq_flags(virq, 0);
#endif
- irq_set_chip_and_handler(irq, NULL, NULL);
- irq_set_chip_data(irq, NULL);
+ irq_set_chip_and_handler(virq, NULL, NULL);
+ irq_set_chip_data(virq, NULL);
+}
+
+static struct irq_domain_ops stmpe_irq_ops = {
+ .map = stmpe_irq_map,
+ .unmap = stmpe_irq_unmap,
+ .xlate = irq_domain_xlate_twocell,
+};
+
+static int __devinit stmpe_irq_init(struct stmpe *stmpe)
+{
+ int base = stmpe->irq_base;
+ int num_irqs = stmpe->variant->num_irqs;
+
+ if (base) {
+ stmpe->domain = irq_domain_add_legacy(
+ NULL, num_irqs, base, 0, &stmpe_irq_ops, stmpe);
+ }
+ else {
+ stmpe->domain = irq_domain_add_linear(
+ NULL, num_irqs, &stmpe_irq_ops, stmpe);
+ }
+
+ if (!stmpe->domain) {
+ dev_err(stmpe->dev, "Failed to create irqdomain\n");
+ return -ENOSYS;
}
+
+ return 0;
}
static int __devinit stmpe_chip_init(struct stmpe *stmpe)
@@ -954,7 +977,7 @@ static int __devinit stmpe_add_device(struct stmpe *stmpe,
struct mfd_cell *cell)
{
return mfd_add_devices(stmpe->dev, stmpe->pdata->id, cell, 1,
- NULL, stmpe->irq_base, NULL);
+ NULL, stmpe->irq_base, stmpe->domain);
}
static int __devinit stmpe_devices_init(struct stmpe *stmpe)
@@ -1067,7 +1090,7 @@ int __devinit stmpe_probe(struct stmpe_client_info *ci, int partnum)
if (ret) {
dev_err(stmpe->dev, "failed to request IRQ: %d\n",
ret);
- goto out_removeirq;
+ goto free_gpio;
}
}
@@ -1083,9 +1106,6 @@ out_removedevs:
mfd_remove_devices(stmpe->dev);
if (stmpe->irq >= 0)
free_irq(stmpe->irq, stmpe);
-out_removeirq:
- if (stmpe->irq >= 0)
- stmpe_irq_remove(stmpe);
free_gpio:
if (pdata->irq_over_gpio)
gpio_free(pdata->irq_gpio);
@@ -1098,10 +1118,8 @@ int stmpe_remove(struct stmpe *stmpe)
{
mfd_remove_devices(stmpe->dev);
- if (stmpe->irq >= 0) {
+ if (stmpe->irq >= 0)
free_irq(stmpe->irq, stmpe);
- stmpe_irq_remove(stmpe);
- }
if (stmpe->pdata->irq_over_gpio)
gpio_free(stmpe->pdata->irq_gpio);
diff --git a/include/linux/mfd/stmpe.h b/include/linux/mfd/stmpe.h
index f8d5b4d..15dac79 100644
--- a/include/linux/mfd/stmpe.h
+++ b/include/linux/mfd/stmpe.h
@@ -62,6 +62,7 @@ struct stmpe_client_info;
* @lock: lock protecting I/O operations
* @irq_lock: IRQ bus lock
* @dev: device, mostly for dev_dbg()
+ * @irq_domain: IRQ domain
* @client: client - i2c or spi
* @ci: client specific information
* @partnum: part number
@@ -79,6 +80,7 @@ struct stmpe {
struct mutex lock;
struct mutex irq_lock;
struct device *dev;
+ struct irq_domain *domain;
void *client;
struct stmpe_client_info *ci;
enum stmpe_partnum partnum;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/8] mfd: Correct copy and paste mistake in stmpe
From: Lee Jones @ 2012-11-05 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352128236-11554-1-git-send-email-lee.jones@linaro.org>
When specifying IRQ numbers for the stmpe1601, IRQ defines for the
stmpe24xx were used instead. Fortunately, the defined numbers are
the same, hence why it survived testing. This fix is merely an
aesthetic one.
Cc: Samuel Ortiz <sameo@linux.intel.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/stmpe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/stmpe.c b/drivers/mfd/stmpe.c
index 5c8d8f2..e50ebdf 100644
--- a/drivers/mfd/stmpe.c
+++ b/drivers/mfd/stmpe.c
@@ -519,12 +519,12 @@ static const u8 stmpe1601_regs[] = {
static struct stmpe_variant_block stmpe1601_blocks[] = {
{
.cell = &stmpe_gpio_cell,
- .irq = STMPE24XX_IRQ_GPIOC,
+ .irq = STMPE1601_IRQ_GPIOC,
.block = STMPE_BLOCK_GPIO,
},
{
.cell = &stmpe_keypad_cell,
- .irq = STMPE24XX_IRQ_KEYPAD,
+ .irq = STMPE1601_IRQ_KEYPAD,
.block = STMPE_BLOCK_KEYPAD,
},
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 5/8] mfd: Enable the STMPE MFD for Device Tree
From: Lee Jones @ 2012-11-05 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352128236-11554-1-git-send-email-lee.jones@linaro.org>
This patch allows the STMPE Multi-Functional Device to be correctly
initialised when booting with Device Tree support enabled. Its
children are specified by the addition of subordinate devices to the
STMPE node in the Device Tree file.
Cc: Samuel Ortiz <sameo@linux.intel.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/stmpe.c | 48 ++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 42 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/stmpe.c b/drivers/mfd/stmpe.c
index e50ebdf..ba157d4 100644
--- a/drivers/mfd/stmpe.c
+++ b/drivers/mfd/stmpe.c
@@ -885,18 +885,19 @@ static struct irq_domain_ops stmpe_irq_ops = {
.xlate = irq_domain_xlate_twocell,
};
-static int __devinit stmpe_irq_init(struct stmpe *stmpe)
+static int __devinit stmpe_irq_init(struct stmpe *stmpe,
+ struct device_node *np)
{
int base = stmpe->irq_base;
int num_irqs = stmpe->variant->num_irqs;
if (base) {
stmpe->domain = irq_domain_add_legacy(
- NULL, num_irqs, base, 0, &stmpe_irq_ops, stmpe);
+ np, num_irqs, base, 0, &stmpe_irq_ops, stmpe);
}
else {
stmpe->domain = irq_domain_add_linear(
- NULL, num_irqs, &stmpe_irq_ops, stmpe);
+ np, num_irqs, &stmpe_irq_ops, stmpe);
}
if (!stmpe->domain) {
@@ -1016,15 +1017,50 @@ static int __devinit stmpe_devices_init(struct stmpe *stmpe)
return ret;
}
+void __devinit stmpe_of_probe(struct stmpe_platform_data *pdata,
+ struct device_node *np)
+{
+ struct device_node *child;
+
+ of_property_read_u32(np, "st,autosleep-timeout",
+ &pdata->autosleep_timeout);
+
+ pdata->autosleep = (pdata->autosleep_timeout) ? true : false;
+
+ for_each_child_of_node(np, child) {
+ if (!strcmp(child->name, "stmpe_gpio")) {
+ pdata->blocks |= STMPE_BLOCK_GPIO;
+ }
+ if (!strcmp(child->name, "stmpe_keypad")) {
+ pdata->blocks |= STMPE_BLOCK_KEYPAD;
+ }
+ if (!strcmp(child->name, "stmpe_touchscreen")) {
+ pdata->blocks |= STMPE_BLOCK_TOUCHSCREEN;
+ }
+ if (!strcmp(child->name, "stmpe_adc")) {
+ pdata->blocks |= STMPE_BLOCK_ADC;
+ }
+ }
+}
+
/* Called from client specific probe routines */
int __devinit stmpe_probe(struct stmpe_client_info *ci, int partnum)
{
struct stmpe_platform_data *pdata = dev_get_platdata(ci->dev);
+ struct device_node *np = ci->dev->of_node;
struct stmpe *stmpe;
int ret;
- if (!pdata)
- return -EINVAL;
+ if (!pdata) {
+ if (np) {
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ stmpe_of_probe(pdata, np);
+ } else
+ return -EINVAL;
+ }
stmpe = kzalloc(sizeof(struct stmpe), GFP_KERNEL);
if (!stmpe)
@@ -1080,7 +1116,7 @@ int __devinit stmpe_probe(struct stmpe_client_info *ci, int partnum)
goto free_gpio;
if (stmpe->irq >= 0) {
- ret = stmpe_irq_init(stmpe);
+ ret = stmpe_irq_init(stmpe, np);
if (ret)
goto free_gpio;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 6/8] Documentation: Describe bindings for STMPE Multi-Functional Device driver
From: Lee Jones @ 2012-11-05 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352128236-11554-1-git-send-email-lee.jones@linaro.org>
Here we add the required documentation for the STMPE Multi-Functional
Device (MFD) Device Tree bindings. It describes all of the bindings
currently supported by the driver.
Cc: Samuel Ortiz <sameo@linux.intel.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
Documentation/devicetree/bindings/mfd/stmpe.txt | 25 +++++++++++++++++++++++
1 file changed, 25 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/stmpe.txt
diff --git a/Documentation/devicetree/bindings/mfd/stmpe.txt b/Documentation/devicetree/bindings/mfd/stmpe.txt
new file mode 100644
index 0000000..8f0aeda
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/stmpe.txt
@@ -0,0 +1,25 @@
+* STMPE Multi-Functional Device
+
+Required properties:
+ - compatible : "st,stmpe[811|1601|2401|2403]"
+ - reg : I2C address of the device
+
+Optional properties:
+ - interrupts : The interrupt outputs from the controller
+ - interrupt-controller : Marks the device node as an interrupt controller
+ - interrupt-parent : Specifies which IRQ controller we're connected to
+ - i2c-client-wake : Marks the input device as wakable
+ - st,autosleep-timeout : Valid entries (ms); 4, 16, 32, 64, 128, 256, 512 and 1024
+
+Example:
+
+ stmpe1601: stmpe1601 at 40 {
+ compatible = "st,stmpe1601";
+ reg = <0x40>;
+ interrupts = <26 0x4>;
+ interrupt-parent = <&gpio6>;
+ interrupt-controller;
+
+ i2c-client-wake;
+ st,autosleep-timeout = <1024>;
+ };
--
1.7.9.5
^ permalink raw reply related
* [PATCH 7/8] mfd: ab8500-core: Use devm_* memory/IRQ and allocation/free routines
From: Lee Jones @ 2012-11-05 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352128236-11554-1-git-send-email-lee.jones@linaro.org>
It is better to use devm_* calls, as they allow for easier
and more automatic clean-up. Resources are device allocated,
so when a device is freed, so are all associated resources.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/ab8500-core.c | 62 ++++++++++++++++++---------------------------
1 file changed, 24 insertions(+), 38 deletions(-)
diff --git a/drivers/mfd/ab8500-core.c b/drivers/mfd/ab8500-core.c
index e7197fe..2a69dc2 100644
--- a/drivers/mfd/ab8500-core.c
+++ b/drivers/mfd/ab8500-core.c
@@ -1233,7 +1233,7 @@ static int __devinit ab8500_probe(struct platform_device *pdev)
int i;
u8 value;
- ab8500 = kzalloc(sizeof *ab8500, GFP_KERNEL);
+ ab8500 = devm_kzalloc(&pdev->dev, sizeof *ab8500, GFP_KERNEL);
if (!ab8500)
return -ENOMEM;
@@ -1243,10 +1243,8 @@ static int __devinit ab8500_probe(struct platform_device *pdev)
ab8500->dev = &pdev->dev;
resource = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!resource) {
- ret = -ENODEV;
- goto out_free_ab8500;
- }
+ if (!resource)
+ return -ENODEV;
ab8500->irq = resource->start;
@@ -1269,7 +1267,7 @@ static int __devinit ab8500_probe(struct platform_device *pdev)
ret = get_register_interruptible(ab8500, AB8500_MISC,
AB8500_IC_NAME_REG, &value);
if (ret < 0)
- goto out_free_ab8500;
+ return ret;
ab8500->version = value;
}
@@ -1277,7 +1275,7 @@ static int __devinit ab8500_probe(struct platform_device *pdev)
ret = get_register_interruptible(ab8500, AB8500_MISC,
AB8500_REV_REG, &value);
if (ret < 0)
- goto out_free_ab8500;
+ return ret;
ab8500->chip_id = value;
@@ -1294,14 +1292,13 @@ static int __devinit ab8500_probe(struct platform_device *pdev)
ab8500->mask_size = AB8500_NUM_IRQ_REGS;
ab8500->irq_reg_offset = ab8500_irq_regoffset;
}
- ab8500->mask = kzalloc(ab8500->mask_size, GFP_KERNEL);
+ ab8500->mask = devm_kzalloc(&pdev->dev, ab8500->mask_size, GFP_KERNEL);
if (!ab8500->mask)
return -ENOMEM;
- ab8500->oldmask = kzalloc(ab8500->mask_size, GFP_KERNEL);
- if (!ab8500->oldmask) {
- ret = -ENOMEM;
- goto out_freemask;
- }
+ ab8500->oldmask = devm_kzalloc(&pdev->dev, ab8500->mask_size, GFP_KERNEL);
+ if (!ab8500->oldmask)
+ return -ENOMEM;
+
/*
* ab8500 has switched off due to (SWITCH_OFF_STATUS):
* 0x01 Swoff bit programming
@@ -1355,37 +1352,37 @@ static int __devinit ab8500_probe(struct platform_device *pdev)
ret = abx500_register_ops(ab8500->dev, &ab8500_ops);
if (ret)
- goto out_freeoldmask;
+ return ret;
for (i = 0; i < ab8500->mask_size; i++)
ab8500->mask[i] = ab8500->oldmask[i] = 0xff;
ret = ab8500_irq_init(ab8500, np);
if (ret)
- goto out_freeoldmask;
+ return ret;
/* Activate this feature only in ab9540 */
/* till tests are done on ab8500 1p2 or later*/
if (is_ab9540(ab8500)) {
- ret = request_threaded_irq(ab8500->irq, NULL,
- ab8500_hierarchical_irq,
- IRQF_ONESHOT | IRQF_NO_SUSPEND,
- "ab8500", ab8500);
+ ret = devm_request_threaded_irq(&pdev->dev, ab8500->irq, NULL,
+ ab8500_hierarchical_irq,
+ IRQF_ONESHOT | IRQF_NO_SUSPEND,
+ "ab8500", ab8500);
}
else {
- ret = request_threaded_irq(ab8500->irq, NULL,
- ab8500_irq,
- IRQF_ONESHOT | IRQF_NO_SUSPEND,
- "ab8500", ab8500);
+ ret = devm_request_threaded_irq(&pdev->dev, ab8500->irq, NULL,
+ ab8500_irq,
+ IRQF_ONESHOT | IRQF_NO_SUSPEND,
+ "ab8500", ab8500);
if (ret)
- goto out_freeoldmask;
+ return ret;
}
ret = mfd_add_devices(ab8500->dev, 0, abx500_common_devs,
ARRAY_SIZE(abx500_common_devs), NULL,
ab8500->irq_base, ab8500->domain);
if (ret)
- goto out_freeirq;
+ return ret;
if (is_ab9540(ab8500))
ret = mfd_add_devices(ab8500->dev, 0, ab9540_devs,
@@ -1396,14 +1393,14 @@ static int __devinit ab8500_probe(struct platform_device *pdev)
ARRAY_SIZE(ab8500_devs), NULL,
ab8500->irq_base, ab8500->domain);
if (ret)
- goto out_freeirq;
+ return ret;
if (is_ab9540(ab8500) || is_ab8505(ab8500))
ret = mfd_add_devices(ab8500->dev, 0, ab9540_ab8505_devs,
ARRAY_SIZE(ab9540_ab8505_devs), NULL,
ab8500->irq_base, ab8500->domain);
if (ret)
- goto out_freeirq;
+ return ret;
if (!no_bm) {
/* Add battery management devices */
@@ -1424,17 +1421,6 @@ static int __devinit ab8500_probe(struct platform_device *pdev)
dev_err(ab8500->dev, "error creating sysfs entries\n");
return ret;
-
-out_freeirq:
- free_irq(ab8500->irq, ab8500);
-out_freeoldmask:
- kfree(ab8500->oldmask);
-out_freemask:
- kfree(ab8500->mask);
-out_free_ab8500:
- kfree(ab8500);
-
- return ret;
}
static int __devexit ab8500_remove(struct platform_device *pdev)
--
1.7.9.5
^ permalink raw reply related
* [PATCH 8/8] mfd: Differentiate between u8500 and u9540 TCDM address mapping
From: Lee Jones @ 2012-11-05 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352128236-11554-1-git-send-email-lee.jones@linaro.org>
The TCDM mappings are quite different from u8500 to u9540. If these
aren't correctly specified for a given board, it will fail to boot.
Here we add the correct TCDM base for the u9540.
Please note that although this patch allows us to boot the u9540,
it doesn't provide us with full enablement. For that, another
patch-set will follow which completely re-vamps the way the PRCMU
is passed TCDM mappings.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/db8500-prcmu.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
index e91a6e6..70898c9 100644
--- a/drivers/mfd/db8500-prcmu.c
+++ b/drivers/mfd/db8500-prcmu.c
@@ -2757,7 +2757,7 @@ static int db8500_irq_init(struct device_node *np)
void __init db8500_prcmu_early_init(void)
{
- if (cpu_is_u8500v2()) {
+ if (cpu_is_u8500v2() || cpu_is_u9540()) {
void *tcpm_base = ioremap_nocache(U8500_PRCMU_TCPM_BASE, SZ_4K);
if (tcpm_base != NULL) {
@@ -2775,7 +2775,11 @@ void __init db8500_prcmu_early_init(void)
iounmap(tcpm_base);
}
- tcdm_base = __io_address(U8500_PRCMU_TCDM_BASE);
+ if (cpu_is_u9540())
+ tcdm_base = ioremap_nocache(U8500_PRCMU_TCDM_BASE,
+ SZ_4K + SZ_8K) + SZ_8K;
+ else
+ tcdm_base = __io_address(U8500_PRCMU_TCDM_BASE);
} else {
pr_err("prcmu: Unsupported chip version\n");
BUG();
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 02/11] clk: davinci - add PSC clock driver
From: Murali Karicheri @ 2012-11-05 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50950908.1060302@ti.com>
On 11/03/2012 08:07 AM, Sekhar Nori wrote:
> On 10/25/2012 9:41 PM, Murali Karicheri wrote:
>> This is the driver for the Power Sleep Controller (PSC) hardware
>> found on DM SoCs as well Keystone SoCs (c6x). This driver borrowed
>> code from arch/arm/mach-davinci/psc.c and implemented the driver
>> as per common clock provider API. The PSC module is responsible for
>> enabling/disabling the Power Domain and Clock domain for different IPs
>> present in the SoC. The driver is configured through the clock data
>> passed to the driver through struct clk_psc_data.
>>
>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>> ---
>> +/**
>> + * struct clk_psc - DaVinci PSC clock driver data
>> + *
>> + * @hw: clk_hw for the psc
>> + * @psc_data: Driver specific data
>> + */
>> +struct clk_psc {
>> + struct clk_hw hw;
>> + struct clk_psc_data *psc_data;
>> + spinlock_t *lock;
> Unused member? I don't see this being used.
OK. Will remove.
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* [PATCH v3 03/11] clk: davinci - common clk utilities to init clk driver
From: Murali Karicheri @ 2012-11-05 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50950F7E.2080309@ti.com>
On 11/03/2012 08:35 AM, Sekhar Nori wrote:
> On 10/25/2012 9:41 PM, Murali Karicheri wrote:
>> This is the common clk driver initialization functions for DaVinci
>> SoCs and other SoCs that uses similar hardware architecture.
>> clock.h also defines struct types for clock definitions in a SoC
>> and clock data type for configuring clk-mux. The initialization
>> functions are used by clock initialization code in a specific
>> platform/SoC.
>>
>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>> ---
>> drivers/clk/davinci/clock.c | 112 +++++++++++++++++++++++++++++++++++++++++++
>> drivers/clk/davinci/clock.h | 80 +++++++++++++++++++++++++++++++
>> 2 files changed, 192 insertions(+)
>> create mode 100644 drivers/clk/davinci/clock.c
>> create mode 100644 drivers/clk/davinci/clock.h
>>
>> diff --git a/drivers/clk/davinci/clock.c b/drivers/clk/davinci/clock.c
>> new file mode 100644
>> index 0000000..ad02149
>> --- /dev/null
>> +++ b/drivers/clk/davinci/clock.c
>> @@ -0,0 +1,112 @@
>> +/*
>> + * clock.c - davinci clock initialization functions for various clocks
>> + *
>> + * Copyright (C) 2006-2012 Texas Instruments.
>> + * Copyright (C) 2008-2009 Deep Root Systems, LLC
>> + *
>> + * 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; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +#include <linux/init.h>
>> +#include <linux/clk-provider.h>
>> +#include <linux/clkdev.h>
>> +#include <linux/io.h>
>> +#include <linux/slab.h>
>> +
>> +#include "clk-pll.h"
>> +#include "clk-psc.h"
>> +#include "clk-div.h"
>> +#include "clock.h"
>> +
>> +static DEFINE_SPINLOCK(_lock);
>> +
>> +#ifdef CONFIG_CLK_DAVINCI_PLL
>> +struct clk *davinci_pll_clk(const char *name, const char *parent,
>> + u32 phys_pllm, u32 phys_prediv, u32 phys_postdiv,
>> + struct clk_pll_data *pll_data)
>> +{
>> + struct clk *clkp = NULL;
>> +
>> + pll_data->reg_pllm = ioremap(phys_pllm, 4);
>> + if (WARN_ON(!pll_data->reg_pllm))
>> + return clkp;
> I would prefer ERR_PTR(-ENOMEM) here. Same comment applies to other
> instances elsewhere in the patch.
>
>> diff --git a/drivers/clk/davinci/clock.h b/drivers/clk/davinci/clock.h
>> new file mode 100644
>> index 0000000..73204b8
>> --- /dev/null
>> +++ b/drivers/clk/davinci/clock.h
>> @@ -0,0 +1,80 @@
>> +/*
>> + * TI DaVinci Clock definitions - Contains Macros and Types used for
>> + * defining various clocks on a DaVinci SoC
>> + *
>> + * Copyright (C) 2012 Texas Instruments
>> + *
>> + * 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.
>> + *
>> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
>> + * kind, whether express or implied; without even the implied warranty
>> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +#ifndef __DAVINCI_CLOCK_H
>> +#define __DAVINCI_CLOCK_H
>> +
>> +#include <linux/types.h>
>> +
>> +/* general flags: */
>> +#define ALWAYS_ENABLED BIT(0)
> This is not used in this patch. Can you add the define along with its
> usage so it is immediately clear why you need it?
This is used on the next patch as this adds a bunch of utilities or
types for the platform specific clock code. Do you want to combine this
patch with 05/11? It will become a bigger patch then? Is that fine.
IMO, this is a logical group that can be a standalone patch than
combining with 05/11.
>> +/**
>> + * struct davinci_clk - struct for defining DaVinci clocks for a SoC.
>> + *
>> + * @name: name of the clock
>> + * @parent: name of parent clock
>> + * @flags: General flags for all drivers used by platform clock init code
>> + * @data: data specific to a clock used by the driver
>> + * @dev_id: dev_id used to look up this clock. If this is NULL
>> + * clock name is used for lookup.
>> + */
>> +struct davinci_clk {
>> + const char *name;
>> + const char *parent;
>> + u32 flags;
>> + void *data;
>> + char *dev_id;
> Similarly dont see this being used as well.
For this and previous one, check lpsc_clk() macro usage. dev_id is used
where a specific device id is used to look up
the clk as is done for davinci_emac.1, davinci_mmc.0 etc.
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* [PATCH V2] ARM: PMU: fix runtime PM enable
From: Tony Lindgren @ 2012-11-05 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026100312.GF20914@mudshark.cambridge.arm.com>
* Will Deacon <will.deacon@arm.com> [121026 03:04]:
> On Thu, Oct 25, 2012 at 09:23:18PM +0100, Jon Hunter wrote:
> > Commit 7be2958 (ARM: PMU: Add runtime PM Support) updated the ARM PMU code to
> > use runtime PM which was prototyped and validated on the OMAP devices. In this
> > commit, there is no call pm_runtime_enable() and for OMAP devices
> > pm_runtime_enable() is currently being called from the OMAP PMU code when the
> > PMU device is created. However, there are two problems with this:
> >
> > 1. For any other ARM device wishing to use runtime PM for PMU they will need
> > to call pm_runtime_enable() for runtime PM to work.
> > 2. When booting with device-tree and using device-tree to create the PMU
> > device, pm_runtime_enable() needs to be called from within the ARM PERF
> > driver as we are no longer calling any device specific code to create the
> > device. Hence, PMU does not work on OMAP devices that use the runtime PM
> > callbacks when using device-tree to create the PMU device.
> >
> > Therefore, call pm_runtime_enable() directly from the ARM PMU driver when
> > registering the device. For platforms that do not use runtime PM,
> > pm_runtime_enable() does nothing and for platforms that do use runtime PM but
> > may not require it specifically for PMU, this will just add a little overhead
> > when initialising and uninitialising the PMU device.
> >
> > Tested with PERF on OMAP2420, OMAP3430 and OMAP4460.
> >
> > V2 changes:
> > - Call pm_runtime_enable() unconditionally on registering the PMU device.
> >
> > Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> > ---
>
> Cheers Jon! Looks a bit weird without the matching pm_runtime_disable, but
> we don't really have anywhere to put that since the PMU is not deregistered.
>
> Can we split this patch into two (even smaller!) patches so that I can take
> the perf part and the omap bit can go to Tony?
The omap bit looks OK for me to queue via perf:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH 3/3] ARM: OMAP: Remove plat-omap/common.c
From: Tony Lindgren @ 2012-11-05 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50977319.9070902@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [121105 00:06]:
> On 2012-11-02 20:54, Tony Lindgren wrote:
> >> * Santosh Shilimkar <santosh.shilimkar@ti.com> [121102 01:56]:
> >>> On Friday 02 November 2012 02:19 PM, Tomi Valkeinen wrote:
> >>>> On 2012-11-02 08:38, Santosh Shilimkar wrote:
> >>>>>
> >>>>> Lets not move this in DMA code since the above is really related
> >>>>> to frame buffer. It reserves more DMA area for dma_alloc_coherent()
> >>>>> etc than default 2 MB. Infact, we should no longer need this with
> >>>>> CMA and memblock in place.
> >>>>>
> >>>>> Tomi,
> >>>>> Can we not get rid of the above memory reservation ?
> >>>>
> >>>> Yes, I think so. This one is only used for the old omapfb, i.e. omap1,
> >>>> and I have no means to test it out, though. But below is a patch to
> >>>> remove it. I also attached the patch, as it looks like thunderbird wants
> >>>> to reformat the pasted patch... I'll remove the
> >>>> CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE from the omapfb driver's Kconfig file
> >>>> in my tree later.
> >
> > Hmm actually, is it safe to remove for omap1, or should we
> > still keep it around for omap1?
>
> Why wouldn't it be safe? Do you mean that CMA doesn't work on omap1,
> or...? I'm no expert on CMA, but as far as I can see with it's ARM
> generic stuff.
Just wondering after your comment "This one is only used for the old
omapfb, i.e. omap1". But sounds like it should no longer be needed
there either if I parse that right.
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: decompressor: clear SCTLR.A bit for v7 cores
From: Russell King - ARM Linux @ 2012-11-05 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105130255.GD2005@linaro.org>
On Mon, Nov 05, 2012 at 01:02:55PM +0000, Dave Martin wrote:
> Why not allow unaligned accesses in the decompressor, though, both
> for v6 and v7?
EXACTLY.
^ permalink raw reply
* [PATCH v3 05/11] clk: davinci - add dm644x clock initialization
From: Murali Karicheri @ 2012-11-05 15:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50951C81.5050501@ti.com>
On 11/03/2012 09:30 AM, Sekhar Nori wrote:
> On 10/25/2012 9:41 PM, Murali Karicheri wrote:
>> This patch adds dm644x clock initialization code that consists of
>> clocks data for various clocks and clock register callouts to
>> various clock drivers. It uses following clk drivers for this
>>
>> 1. clk-fixed-rate - for ref clock
>> 2. clk-mux - for mux at the input and output of main pll
>> 3. davinci specific clk-pll for main pll clock
>> 4. davinci specific clk-div for pll divider clock
>> 5. clk-fixed-factor for fixed factor clock such as auxclk
>> 6. davinci specific clk-psc for psc clocks
>>
>> This patch also moves all of the PLL and PSC register definitions
>> from clock.h and psc.h under davinci to the clk/davinci folder so
>> that various soc specific clock initialization code can share these
>> definitions.
> Except this patch does not move the defines, it creates a copy of them
> (which is bad since you quickly lose track of which is the correct
> copy). Is this done to avoid including mach/ header files here?
Yes.
> It will
> actually be better to include the mach/ files here as a temporary
> solution and then remove the include mach/ files once all the SoCs have
> been converted over.
I was thinking we are not allowed to include mach/* header files in
driver files. But most of the clk drivers
such clk-imx28, spear6xx_clock.c. versatile/clk-integrator.c etc are
including mach/ headers. One issue is that the definitions in pll.h are
re-usable across other machines falling under c6x and Keystone (new
device we are working on) as well. Where do we keep includes that can be
re-used across different architectures? include/linux/platform_data/ ? I
see clk-integrator.h, clk-nomadik.h and clk-u300 sitting there. So I
suggest moving any header files that defines utility functions, register
definitions across different architectures to
include/linux/platform_data. Candidate files would be clock.h, pll.h,
clk-psc.h, clk-pll.h and clk-div.h. This way these can be used across
the above machines that use the above architectures. Can we do this in
my next version? This way we don't have to make another move later. All
these CLK IPs are re-used across multiple architectures and make perfect
sense to me to move to the above folder.
>
>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>> ---
>> drivers/clk/davinci/dm644x-clock.c | 304 ++++++++++++++++++++++++++++++++++++
>> drivers/clk/davinci/pll.h | 83 ++++++++++
>> drivers/clk/davinci/psc.h | 215 +++++++++++++++++++++++++
>> 3 files changed, 602 insertions(+)
>> create mode 100644 drivers/clk/davinci/dm644x-clock.c
>> create mode 100644 drivers/clk/davinci/pll.h
>> create mode 100644 drivers/clk/davinci/psc.h
>>
>> +/* all clocks available in DM644x SoCs */
>> +enum dm644x_clk {
>> + clkin, oscin, ref_clk_mux, pll1, pll1_plldiv_clk_mux, auxclk,
>> + clk_pll1_sysclk1, clk_pll1_sysclk2, clk_pll1_sysclk3, clk_pll1_sysclk4,
>> + clk_pll1_sysclk5, clk_pll1_sysclkbp, pll2, pll2_plldiv_clk_mux,
>> + clk_pll2_sysclk1, clk_pll2_sysclk2, clk_pll2_sysclkbp, dsp, arm, vicp,
>> + vpss_master, vpss_slave, uart0, uart1, uart2, emac, i2c, ide, asp,
>> + mmcsd, spi, gpio, usb, vlynq, aemif, pwm0, pwm1, pwm2, timer0, timer1,
>> + timer2, clk_max
>> +};
>> +
>> +static struct davinci_clk *psc_clocks[] = {
>> + &clk_dsp, &clk_arm, &clk_vicp, &clk_vpss_master, &clk_vpss_slave,
>> + &clk_uart0, &clk_uart1, &clk_uart2, &clk_emac, &clk_i2c, &clk_ide,
>> + &clk_asp0, &clk_mmcsd, &clk_spi, &clk_gpio, &clk_usb, &clk_vlynq,
>> + &clk_aemif, &clk_pwm0, &clk_pwm1, &clk_pwm2, &clk_timer0, &clk_timer1,
>> + &clk_timer2
>> +};
> You rely on perfect order between this array and dm644x_clk enum above.
> Can you initialize this array using the enum as the index so that it is
> clear. Current method is too error prone.
Ok. Will do.
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* [PATCH v3 10/11] ARM: davinci - migrate to common clock
From: Murali Karicheri @ 2012-11-05 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50966861.4040500@ti.com>
On 11/04/2012 08:06 AM, Sekhar Nori wrote:
> On 10/25/2012 9:41 PM, Murali Karicheri wrote:
>> Currently migrate only DM644x as this is being reviewed. Once all
>> platforms are migrated, the Makefile will be cleaned up to remove
>> obsoleted files clock.o and psc.o
>>
>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>> ---
>> arch/arm/Kconfig | 1 +
>> arch/arm/mach-davinci/Kconfig | 2 ++
>> arch/arm/mach-davinci/Makefile | 11 ++++++++++-
>> 3 files changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index c5f9ae5..4611987 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -967,6 +967,7 @@ config ARCH_DAVINCI
>> select ARCH_REQUIRE_GPIOLIB
>> select ZONE_DMA
>> select HAVE_IDE
>> + select COMMON_CLK
>> select CLKDEV_LOOKUP
>> select GENERIC_ALLOCATOR
>> select GENERIC_IRQ_CHIP
> This list has to be sorted. Russell has a patch which fixed this all
> across arch/arm/* which got merged for v3.7. This patch does not apply
> to v3.7-rc3 anymore due to the same reason.
>
> Thanks,
> Sekhar
>
Ok. Will do.
^ permalink raw reply
* [PATCH 3/3] ARM: OMAP: Remove plat-omap/common.c
From: Tomi Valkeinen @ 2012-11-05 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105153632.GH4953@atomide.com>
On 2012-11-05 17:36, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [121105 00:06]:
>> On 2012-11-02 20:54, Tony Lindgren wrote:
>>>> * Santosh Shilimkar <santosh.shilimkar@ti.com> [121102 01:56]:
>>>>> On Friday 02 November 2012 02:19 PM, Tomi Valkeinen wrote:
>>>>>> On 2012-11-02 08:38, Santosh Shilimkar wrote:
>>>>>>>
>>>>>>> Lets not move this in DMA code since the above is really related
>>>>>>> to frame buffer. It reserves more DMA area for dma_alloc_coherent()
>>>>>>> etc than default 2 MB. Infact, we should no longer need this with
>>>>>>> CMA and memblock in place.
>>>>>>>
>>>>>>> Tomi,
>>>>>>> Can we not get rid of the above memory reservation ?
>>>>>>
>>>>>> Yes, I think so. This one is only used for the old omapfb, i.e. omap1,
>>>>>> and I have no means to test it out, though. But below is a patch to
>>>>>> remove it. I also attached the patch, as it looks like thunderbird wants
>>>>>> to reformat the pasted patch... I'll remove the
>>>>>> CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE from the omapfb driver's Kconfig file
>>>>>> in my tree later.
>>>
>>> Hmm actually, is it safe to remove for omap1, or should we
>>> still keep it around for omap1?
>>
>> Why wouldn't it be safe? Do you mean that CMA doesn't work on omap1,
>> or...? I'm no expert on CMA, but as far as I can see with it's ARM
>> generic stuff.
>
> Just wondering after your comment "This one is only used for the old
> omapfb, i.e. omap1". But sounds like it should no longer be needed
> there either if I parse that right.
I meant that the code that was moved in the patch "Remove
plat-omap/common.c" is only compiled and ran on omap1, when the old
omapfb has been enabled in the Kconfig. It's not used on omap2+.
old omapfb uses dma_alloc_*() to allocate memory, so if CMA works on
omap1, I think this code in question can be removed, as done in my patch.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121105/72bf2fc7/attachment.sig>
^ permalink raw reply
* [PATCH 1/2] ARM: i.MX27: Add platform support for IRAM.
From: Javier Martin @ 2012-11-05 15:59 UTC (permalink / raw)
To: linux-arm-kernel
Add support for IRAM to i.MX27 non-DT platforms using
iram_init() function.
Signed-off-by: Javier Martin <javier.martin@vista-silicon.com>
---
arch/arm/mach-imx/mm-imx27.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-imx/mm-imx27.c b/arch/arm/mach-imx/mm-imx27.c
index e7e24af..fd2416d 100644
--- a/arch/arm/mach-imx/mm-imx27.c
+++ b/arch/arm/mach-imx/mm-imx27.c
@@ -27,6 +27,7 @@
#include <asm/pgtable.h>
#include <asm/mach/map.h>
#include <mach/iomux-v1.h>
+#include <mach/iram.h>
/* MX27 memory map definition */
static struct map_desc imx27_io_desc[] __initdata = {
@@ -94,4 +95,6 @@ void __init imx27_soc_init(void)
/* imx27 has the imx21 type audmux */
platform_device_register_simple("imx21-audmux", 0, imx27_audmux_res,
ARRAY_SIZE(imx27_audmux_res));
+ /* imx27 has an iram of 46080 bytes size */
+ iram_init(MX27_IRAM_BASE_ADDR, 46080);
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] media: coda: Use iram_alloc() for codadx6 too.
From: Javier Martin @ 2012-11-05 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352131185-12079-1-git-send-email-javier.martin@vista-silicon.com>
Use this helper function instead of hardcoding the
physical address of the IRAM in the i.MX27.
Signed-off-by: Javier Martin <javier.martin@vista-silicon.com>
---
drivers/media/video/Kconfig | 2 +-
drivers/media/video/coda.c | 18 ++++++++++--------
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index ecab6ef..0b5f785 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1229,7 +1229,7 @@ config VIDEO_CODA
depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MXC
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
- select IRAM_ALLOC if SOC_IMX53
+ select IRAM_ALLOC
---help---
Coda is a range of video codec IPs that supports
H.264, MPEG-4, and other video formats.
diff --git a/drivers/media/video/coda.c b/drivers/media/video/coda.c
index 7febcd9..96ecb3f 100644
--- a/drivers/media/video/coda.c
+++ b/drivers/media/video/coda.c
@@ -43,6 +43,7 @@
#define CODA_PARA_BUF_SIZE (10 * 1024)
#define CODA_ISRAM_SIZE (2048 * 2)
#define CODA7_IRAM_SIZE 0x14000 /* 81920 bytes */
+#define CODADX6_IRAM_SIZE 45056
#define CODA_MAX_FRAMEBUFFERS 2
@@ -1919,6 +1920,8 @@ static int __devinit coda_probe(struct platform_device *pdev)
const struct of_device_id *of_id =
of_match_device(of_match_ptr(coda_dt_ids), &pdev->dev);
const struct platform_device_id *pdev_id;
+ void __iomem *iram_vaddr;
+ unsigned long iram_size;
struct coda_dev *dev;
struct resource *res;
int ret, irq;
@@ -2016,16 +2019,15 @@ static int __devinit coda_probe(struct platform_device *pdev)
}
if (dev->devtype->product == CODA_DX6) {
- dev->iram_paddr = 0xffff4c00;
+ iram_size = CODADX6_IRAM_SIZE;
} else {
- void __iomem *iram_vaddr;
+ iram_size = CODA7_IRAM_SIZE;
+ }
- iram_vaddr = iram_alloc(CODA7_IRAM_SIZE,
- &dev->iram_paddr);
- if (!iram_vaddr) {
- dev_err(&pdev->dev, "unable to alloc iram\n");
- return -ENOMEM;
- }
+ iram_vaddr = iram_alloc(iram_size, &dev->iram_paddr);
+ if (!iram_vaddr) {
+ dev_err(&pdev->dev, "unable to alloc iram\n");
+ return -ENOMEM;
}
platform_set_drvdata(pdev, dev);
--
1.7.9.5
^ permalink raw reply related
* scheduler clock for MXS [Was: Re: Wakeup latency measured with SCHED_TRACER depends on HZ]
From: Stanislav Meduna @ 2012-11-05 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105134655.GB27260@S2100-06.ap.freescale.net>
On 05.11.2012 14:46, Shawn Guo wrote:
>>> From my quick testing on imx23 with printk timestamp, it's not OK,
>>> so we may need to leave imx23 out there.
>>
> I should say it's practically not OK since it wraps in such a short
> period. But it actually works as expected.
>
>> Hmm, does it wrap after 2 seconds?
>
> Yes, it does wrap after ~2 seconds.
This is weird. AFAIK the printk should be using sched_clock(),
which is a weak symbol overridden in arch/arm/kernel/sched_clock.c
and it should take care of the extension to never-ever-wrapping
64-bit timestamp. Looks that it does not and if it does not,
I think there is more to be worried of than just printk timestamps.
I don't see anything wrong with the code; bumping the 64-bit
part so that it is no more than wrap time away should take
place in sched_clock_timer which is called at 90% of the
time interval.
BTW this patch deserves IMHO looking at
https://patchwork.kernel.org/patch/1193631/
but it is probably not the problem here.
In case it matters I'm working with the current 3.4 with
RT patches (none of them touches arch/arm/mach-mxs) - sorry
not to mention it earlier, I forgot to write it again after
I included additional mailing lists to the discussion.
Regards
--
Stano
^ permalink raw reply
* [PATCH 3/3] ARM: OMAP: Remove plat-omap/common.c
From: Tony Lindgren @ 2012-11-05 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5097DFD9.5030800@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [121105 07:50]:
> On 2012-11-05 17:36, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [121105 00:06]:
> >> On 2012-11-02 20:54, Tony Lindgren wrote:
> >>>> * Santosh Shilimkar <santosh.shilimkar@ti.com> [121102 01:56]:
> >>>>> On Friday 02 November 2012 02:19 PM, Tomi Valkeinen wrote:
> >>>>>> On 2012-11-02 08:38, Santosh Shilimkar wrote:
> >>>>>>>
> >>>>>>> Lets not move this in DMA code since the above is really related
> >>>>>>> to frame buffer. It reserves more DMA area for dma_alloc_coherent()
> >>>>>>> etc than default 2 MB. Infact, we should no longer need this with
> >>>>>>> CMA and memblock in place.
> >>>>>>>
> >>>>>>> Tomi,
> >>>>>>> Can we not get rid of the above memory reservation ?
> >>>>>>
> >>>>>> Yes, I think so. This one is only used for the old omapfb, i.e. omap1,
> >>>>>> and I have no means to test it out, though. But below is a patch to
> >>>>>> remove it. I also attached the patch, as it looks like thunderbird wants
> >>>>>> to reformat the pasted patch... I'll remove the
> >>>>>> CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE from the omapfb driver's Kconfig file
> >>>>>> in my tree later.
> >>>
> >>> Hmm actually, is it safe to remove for omap1, or should we
> >>> still keep it around for omap1?
> >>
> >> Why wouldn't it be safe? Do you mean that CMA doesn't work on omap1,
> >> or...? I'm no expert on CMA, but as far as I can see with it's ARM
> >> generic stuff.
> >
> > Just wondering after your comment "This one is only used for the old
> > omapfb, i.e. omap1". But sounds like it should no longer be needed
> > there either if I parse that right.
>
> I meant that the code that was moved in the patch "Remove
> plat-omap/common.c" is only compiled and ran on omap1, when the old
> omapfb has been enabled in the Kconfig. It's not used on omap2+.
>
> old omapfb uses dma_alloc_*() to allocate memory, so if CMA works on
> omap1, I think this code in question can be removed, as done in my patch.
OK thanks for clarifying it.
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: decompressor: clear SCTLR.A bit for v7 cores
From: Nicolas Pitre @ 2012-11-05 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121105153917.GG28327@n2100.arm.linux.org.uk>
On Mon, 5 Nov 2012, Russell King - ARM Linux wrote:
> On Mon, Nov 05, 2012 at 01:02:55PM +0000, Dave Martin wrote:
> > Why not allow unaligned accesses in the decompressor, though, both
> > for v6 and v7?
>
> EXACTLY.
I have no objections to that. In fact, I made a remark to this effect
in my initial review of this patch. Whether or not gcc does take
advantage of this hardware ability in the end is orthogonal.
Nicolas
^ permalink raw reply
* [PATCH 1/8] mfd: ab8500-core: Remove unused ab8500-gpio IRQ ranges
From: Arnd Bergmann @ 2012-11-05 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352128236-11554-2-git-send-email-lee.jones@linaro.org>
On Monday 05 November 2012, Lee Jones wrote:
> The IRQ ranges provided in ab8500-core to be passed on to the
> ab8500-gpio driver are not only redundant, but they are also
> causing a warning in the boot log. These IRQ ranges, like any
> other MFD related IRQ resource are passed though MFD core for
> automatic conversion to virtual IRQs; however, MFD core does
> not support IRQ mapping of IRQ ranges. Let's just remove them.
>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH v3 06/11] clk: davinci - add build infrastructure for DaVinci clock drivers
From: Murali Karicheri @ 2012-11-05 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50966ED8.6070404@ti.com>
On 11/04/2012 08:34 AM, Sekhar Nori wrote:
> On 10/25/2012 9:41 PM, Murali Karicheri wrote:
>> This updates clk Makefile and Kconfig to integrate the DaVinci specific
>> clock drivers. Also add new Kconfig and Makefile for these drivers.
>>
>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
> As mentioned before, this should be folded into previous patches which
> actually add the particular functionality.
Yes. Agreed.,
>> ---
>> drivers/clk/Kconfig | 2 ++
>> drivers/clk/Makefile | 1 +
>> drivers/clk/davinci/Kconfig | 44 ++++++++++++++++++++++++++++++++++++++++++
>> drivers/clk/davinci/Makefile | 5 +++++
>> 4 files changed, 52 insertions(+)
>> create mode 100644 drivers/clk/davinci/Kconfig
>> create mode 100644 drivers/clk/davinci/Makefile
>>
>> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
>> index 7f0b5ca..1ad2ab0 100644
>> --- a/drivers/clk/Kconfig
>> +++ b/drivers/clk/Kconfig
>> @@ -33,6 +33,8 @@ config COMMON_CLK_DEBUG
>> clk_flags, clk_prepare_count, clk_enable_count &
>> clk_notifier_count.
>>
>> +source "drivers/clk/davinci/Kconfig"
>> +
>> config COMMON_CLK_WM831X
>> tristate "Clock driver for WM831x/2x PMICs"
>> depends on MFD_WM831X
>> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
>> index 5869ea3..b127b6f 100644
>> --- a/drivers/clk/Makefile
>> +++ b/drivers/clk/Makefile
>> @@ -10,6 +10,7 @@ obj-$(CONFIG_ARCH_SOCFPGA) += socfpga/
>> obj-$(CONFIG_PLAT_SPEAR) += spear/
>> obj-$(CONFIG_ARCH_U300) += clk-u300.o
>> obj-$(CONFIG_ARCH_INTEGRATOR) += versatile/
>> +obj-$(CONFIG_DAVINCI_CLKS) += davinci/
>>
>> # Chip specific
>> obj-$(CONFIG_COMMON_CLK_WM831X) += clk-wm831x.o
>> diff --git a/drivers/clk/davinci/Kconfig b/drivers/clk/davinci/Kconfig
>> new file mode 100644
>> index 0000000..e53bbc3
>> --- /dev/null
>> +++ b/drivers/clk/davinci/Kconfig
>> @@ -0,0 +1,44 @@
>> +menu "TI DaVinci Clock drivers"
>> + depends on COMMON_CLK
>> +
>> +config CLK_DAVINCI_PSC
>> + bool "TI DaVici PSC clock driver"
>> + default n
>> + ---help---
>> + Selects clock driver for DaVinci PSC clocks. This clock
>> + hardware is found on TI DaVinci SoCs and other SoCs that
>> + uses this hardware IP. This hardware has a local power
>> + sleep control module that gate the clock to the IP.
>> +
>> +config CLK_DAVINCI_PLL
>> + bool "DaVici main PLL clock"
>> + ---help---
>> + Selects clock driver for DaVinci main PLL. This clock
>> + hardware is found on TI DaVinci SoCs. This typically has
>> + a multiplier, a pre divider and post driver. Some of the
>> + SoCs has the the dividers fixed, and others have it
>> + programmable
>> +
>> +config CLK_DAVINCI_PLLDIV
>> + bool "DaVici PLL divider clock"
>> + ---help---
>> + Selects clock driver for DaVinci PLL divider. This clock
>> + hardware is found on TI DaVinci SoCs. This typically has
>> + a divider and an enable bit to bypass or enable the
>> + divider.
>> +
>> +config DAVINCI_CLKS
>> + bool "TI DaVinci common clocks"
>> + default n
>> + select CLK_DAVINCI_PSC
>> + select CLK_DAVINCI_PLLDIV
>> + ---help---
>> + Selects common clock drivers for DaVinci. These clocks
>> + are re-used across many TI SoCs that are based on DaVinci and
>> + Keystone (c6x) families. This config option is used to select
>> + the common clock driver for DaVinci based SoCs. SoCs specific
>> + Kconfig option needs to select the driver for clocks specific
>> + to the SoC.
>> +
>> +endmenu
> I wonder if all these configurations are really required. For complete
> clock functionality you anyway require all this functionality so I
> wonder why anyone would not select any of these. And to differentiate
> between architecture changes, conditional build based on architecture
> can be used:
I know this is a grey area I need to improve and had a discussion with
Mike sometime back. Are you also suggesting including davinci folder
unconditionally under drivers/clk/Makefile? I think it will work. And
then in clk/davinci/Makefile we can include on a per architecture basis.
But I am not sure if calling the folder as davinci make sense and these
drivers are used on non DaVinci architectures as well. I had initially
named it as "ti" to include all ti drivers. But Mike had commented that
current directory structure use platform/arch name instead of vendor
name. Also OMAP is going to move the clk drivers to this folder soon. So
for now, davinci may be used to house all of the non OMAP drivers. Later
we can re-visit this as needed (wouldn't be that hard to do this within
the clk driver folder later). We can keep the davinci folder name and
unconditionally include it in clk/Makefile.
clk/Makefile
add
obj-y += davinci/
clk/davinci/Makefile
obj-$(CONFIG_ARCH_DAVINCI) += clk-pll.o clk-div.o clk-psc.o clock.o
obj-$(CONFIG_ARCH_KEYSTONE) += clk-pll-keystone.o clk-div.o clk-psc.o clock.o
obj-$(CONFIG_ARCH_DAVINCI_DM644x) += clk-dm644x.o
obj-$(CONFIG_ARCH_DAVINCI_DM355) += clk-dm355.o
This way I can remove these config options. Are you okay with this?
>
> obj-$(CONFIG_ARCH_DAVINCI) += clk-pll.o
> obj-$(CONFIG_ARCH_KEYSTONE) += clk-pll-keystone.o
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* [PATCH v2] leds: leds-gpio: adopt pinctrl support
From: Tony Lindgren @ 2012-11-05 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdY_db3ju4LVnoR=0Wq8TFUxa48jNFGhvGM-3uSrmGZVew@mail.gmail.com>
* Linus Walleij <linus.walleij@linaro.org> [121104 09:39]:
> On Tue, Oct 30, 2012 at 3:12 PM, AnilKumar, Chimata <anilkumar@ti.com> wrote:
> > I have two options now
> > - add only default states for now, I can add reset of
> > the state details once suspend/resume is supported.
> > - add same values in all the states, modify those once
> > suspend/resume is added for AM335x.
>
> The OMAP maintainer gets to choose how this is to be done,
> it's none of my business :-)
Either way is fine with me as long as the changes have been
tested and you don't have to redo things once you have
suspend and resume working.
Regards,
Tony
^ 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